Spring boot demo app tried on localhost and successfully run the application. I even installed
gradle,jdk and other dependencies
easily on aws instance . Even though i ran ./gradlew bootRun of sample application successfully .
Like http:// localhost:8080 aws instane isn't working according to my path like http://myip:8080.
Let me know what exactly i am doing wrong with this and also to make sure i added custom tcp rule such as 8080 .
Besides adding custom tcp rule 8080, try to add the following rule into your security group.
Type: Custom ICMP Rule
Protocol: Echo Request
Port Range: N/A
Source: 0.0.0.0/0
And then try to ping YourIP in order to see if your EC2 machine can be reach from internet. If your EC2 ip is pingable, then I guess the reason why you cannot access http://myip:8080 is your spring boot failed to start in EC2.
You can ssh into your ec2 and investigate your jar. I don't know any clever method but my method is:
After ssh into the ec2 machine,
Find your jar name by ps -A -F . In my case I can find java -jar application.jar
Find your jar path by sudo find / -name application.jar . In my case I can find /var/app/current/application.jar
Then you can cd /var/app/current/ and java -jar application.jar . If you are lucky, you can find some hints from the spring boot log.
In order for this call to work there are a couple of prerequisites.I will try to make a short list, other things could arise depending on the environment.
Make sure the public IP address is the same as the one you know. This changes after each reboot. If you do not want this behavior you can use an elastic IP
The 8080 port is accessible from the Internet. Here are some steps to make sure this is the case: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/authorizing-access-to-an-instance.html
Related
I m using docker toolbox in Windows 7, and when I run a command like
'docker run -p 5000:5000 -d in28min/todo-rest-api-h2:1.0.0.RELEASE'
, it worked and app executed.
-- Here is shown that app started.
Besides 'docker container ls' command give me running port.
So, when I request to corresponding URL(http://localhost:5000/hello-world), it does not respond (This site can’t be reached). What can be a problem here? As far as I know, that '-p' command allows us to request. Thanks in advance
I found solution. It is because of 'docker-machine ip'. which is different in docker toolbox. Default docker-machine ip is 192.168.99.100, not localhost.
I am facing an issue running a docker image based on alpine linux that runs a java process (GoCD server). The java process itself tries to run some code to clone a git repository locally however I am getting a Couldn't resolve host exception. I tried to manually clone the git repo from within the container using 'git clone' and had no issue.
In addition, I am able to ping the domain from within the docker container by running ping my-service-url.com with no issues and also from the host machine with the same result. It seems java has some difficulties resolving the name but I am not sure how to fix it.
I tried creating a new image with RUN echo 'hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4' >> /etc/nsswitch.conf. I read in another question that would fix it but no luck. The whole Dockerfile looks like the following:
FROM gocd/gocd-server:v17.5.0
RUN echo 'hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4' >> /etc/nsswitch.conf
ADD json-config-plugin-0.2.jar /godata/plugins/external/json-config-plugin-0.2.jar
ENTRYPOINT ["/docker-entrypoint.sh"]
I am running on AWS ECS, ipv4 forwarding is set to 1 and network mode is bridge. I am running out of ideas.
I am experimenting with Docker for the first time, and am trying to get a Spring Boot web app to run inside a Docker container. I am building the app (which packages up into a self-contained jar) and then adding it to the Docker image (which is what I want).
You can find my SSCCE at this Bootup repo on GitHub, whose README has all the instructions to reproduce what I'm seeing. But basically:
I build the web app into a jar
Run docker build -t bootup . which succeeds
Run docker run -it -p 9200:9200 -d --name bootup bootup and then container seems to start up just fine, as is evidence by the docker ps output below
However, when I point a browser to http://localhost:9200, I get nothing
docker ps output:
CONTAINER ID IMAGE COMMAND CREATED
a8c4ee64a1bc bootup "/bin/sh -c 'java -ja" 2 days ago
STATUS PORTS NAMES
Up 12 seconds 0.0.0.0:9200->9200/tcp bootup
The web app is configured to run on port 9200, not the Java default of 8080. You can see this for yourself by running the app outside of docker (so, just locally on you host machine) by running ./gradlew clean build && java -jar build/libs/bootup.jar.
To my knowledge, there is no Firewall running on my host that would be blocking ports (I am on Mac 10.11.5 and verified that System Preferences >> Security & Privacy >> Firewall is turned off).
Can anyone spot where I'm going awry?
Updates:
I ran a curl, netstat and lsof on the host:
HOST:
curl http://localhost:9200
curl: (52) Empty reply from server
netstat -an | grep 9200
tcp6 0 0 ::1.9200 *.* LISTEN
tcp4 0 0 *.9200 *.* LISTEN
lsof -n -i4TCP:9200 | grep LISTEN
com.docke 2578 myuser 19u IPv4 <someHexNumber> 0t0 TCP *:wap-wsp (LISTEN)
And then docker exec'd into the container and ran another netstat:
CONTAINER:
netstat -an | grep 9200
bash: netstat: command not found
Update w/ photos:
Picture of my browser (Chrome) pointed to http://localhost:9200:
Picture of the source code at http://localhost:9200:
Picture of Chrome Developer Tools inspecting the page at http://localhost:9200:
Picture of the Network tab in Chrome Developer Tools:
What the heck is going on here?!?!? According to the source, the browser should be rendering my Well hello there, from Dockerland! message just fine. According to the actual browser page, it looks like there is a networking error. And according to Chrome Developer Tools, my app is returning all sorts of HTML/CSS/JS content that is not even remotely apart of my app (check out the source code, see for yourself)!!!
The Dockerfile doesn't expose 9200 to the daemon. Add
EXPOSE 9200
to the Dockerfile before ENTRYPOINT
Assuming you are using Docker Toolbox and not the beta ...
There is a 3 step process for exposing a port properly:
use EXPOSE 8080 where 8080 is just a port number in the Dockerfile
use -p 8080:8080 in your docker run command
Make sure that you setup port forwarding in Oracle Virtual Box so that the boot2docker machine is able to receive requests from port 8080.
This applies to both Windows and OSX where Docker Toolbox is being used. Linux doesn't use Oracle VirtualBox to run docker so those hosts do not need to do the third point
I ran your repo as-is on Docker 1.12 on OSX.
If you look carefully at your container startup:
2016-08-29 20:52:31.028 INFO 5 --- [ main] o.eclipse.jetty.server.ServerConnector : Started ServerConnector#47949d1a{HTTP/1.1}{0.0.0.0:8080}
2016-08-29 20:52:31.033 INFO 5 --- [ main] .s.b.c.e.j.JettyEmbeddedServletContainer : Jetty started on port(s) 8080 (http/1.1)
Although application.yml and Dockerfile both contain 9200, the application is starting on 8080
Going to add another answer here because I saw something related to the Github Repo that you posted:
So the repo is a spring boot repo with an application.yml file.
Your Dockerfile looks like this:
FROM openjdk:8
RUN mkdir /opt/bootup
ADD build/libs/bootup.jar /opt/bootup
WORKDIR /opt/bootup
EXPOSE 9200
ENTRYPOINT java -jar bootup.jar
Which is adding the built jar to the image. If my understanding is correct, the jar does not include application.yml because:
It is not part of the build (gradle would package the src/main only). It is sitting on the project root folder
It is not explicitly added to Docker
So therefore one can assume that your app is actually running on 8080 (the default) at the moment?
A couple of options that one could try:
Try exposing 8080 instead of 9200 (or expose both) and see if that makes a difference?
The entrypoint command can append the port --server.port=9200
The application.yml file should be added to the image (you might need to add an argument to reference it properly) [ADD application.yml /opt/bootup, after first ADD command]
Include the application.yml file in src/main/resources so that spring boot can pick it up automatically.
References
Spring Boot reference documentation on the order of loading for external configuration
Good News! (for MacOSx 10.15.7)
I found the same issue as you, and I was able to solve it by directly opening VirutalBox connection
Go here first:
changed to bridged then logged into the virtual machine within VirtualBox
And found the actual machine's adapter labeled:
eth0
after I noted the setting it was originally NAT so I changed to bridged and then
I was able to use its address vs. localhost.
After I used the public address I used:
curl -i [bridged_ip_address_here]:9200
it then worked flawlessly.
However I also noticed some firewalls and accessibility options that needed permission as well.
I pray this helps you.
I'm currently trying to implement mounting of hdfs to a local directory on ubuntu machine. I'm using hadoop-fuse-dfs package.
So, I'm executing this below command
ubuntu#dev:~$ hadoop-fuse-dfs dfs://localhost:8020 /mnt/hdfs
Output
INFO
/var/lib/jenkins/workspace/generic-package-ubuntu64-12-04/CDH4.5.0-Packaging-Hadoop-2013-11-20_14-31-53/hadoop-2.0.0+1518-1.cdh4.5.0.p0.24~precise/src/hadoop-hdfs-project/hadoop-hdfs/src/main/native/fuse-dfs/fuse_options.c:164
Adding FUSE arg /mnt/hdfs
But, when I try to access the mounted hdfs locally, I see the error message (please check the snapshot attached)
ls: cannot access /mnt/hdfs: No such file or directory
total 4.0K
d????????? ? ? ? ? ? hdfs
PS : I've already executed following commands, but still I get same output.
$ sudo adduser ubuntu fuse
$ sudo addgroup ubuntu fuse
Am I missing something ? Please suggest some workaround.
You need to use hostname instead of localhost. I faced the same issue, after changing localhost to hostname which is also defined in hosts file, it got fixed.
hadoop-fuse-dfs dfs://{hostname}:8020 /mnt/hdfs
According to Cloudera
In an HA deployment, use the HDFS nameservice instead of the NameNode URI; that is, use the value of dfs.nameservices in hdfs-site.xml.
This happens at least when hadoop-fuse-dfs can not connect to filesystem metadata operations running by default on port 8020 e.g. due to network configuration issues.
You can test from your host that connection works prior running hadoop-fuse-dfs e.g. by
telnet your-name-node 8020
GET /
I am developing web application using scala. Now it become rather big and I am going to split it to few separated services and glue it with nginx as reverse proxy.
While it was just a scala app it was able to distribute and run it as jar with few config files. But now there is nginx which usually installed as system app. What is the best way to work with nginx in portable manner, to have all app concentrated in one folder?
Should I have *.conf file with host and include reloading nginx in startup script?
Or maybe it will be usefull to have portable nginx binary?
This is for testing and experimental needs only. Production app deployed into server with preconfigured nginx.
Having used Nginx on Ubuntu quite a lot, I found that it is quite effective to keep .conf files with the project work, along with one or two shell scripts to install and configure them.
You didn't mention your OS, but I can share my experience with Ubuntu if that helps. This is more an OS admin topic than a Scala one per se.
For example, a script might symlink your scripts/myapp.conf file(s) something like this:
#!/bin/bash -e
cd $(dirname $0)
TGT=$PWD
cd /etc/nginx/sites-enabled
sudo rm -f myapp.conf
sudo ln -vs $TGT/scripts/myapp.conf myapp.conf
sudo service nginx reload
So you have separated services with nginx as reverse proxy in your production. And need to adapt nginx for test environment ?
If that is one or two machines setup, try not to overenginer setting, but just adapt nginx config manually (and scala server file) as needed (hostname, ports, path etc...).
Just my 2c.