Docker - Unable to Access Service from Localhost - docker

I've created a Dockerfile which looks like this:
FROM openjdk:8-jdk
COPY . .
ENTRYPOINT ["/bin/graphdb"]
EXPOSE 7200
On doing docker run 34a1650b461d -p 127.0.0.1:7200:7200 I see my service running as shown in the terminal output - however when I go to localhost:7200 I keep seeing This site can’t be reached 127.0.0.1 refused to connect.
Could anyone explain what I'm missing?
Also fyi - when I do docker ps, under PORTS I see 7200/tcp.
I read this page and followed what was described but to no luck.
Any help appreciated.
Thanks.

For docker run the order of the parameters matter, so this:
docker run 34a1650b461d -p 7200:7200
Is not the same as:
docker run -p 7200:7200 34a1650b461d
In the first case you are passing the parameters -p 7200:7200 to your ENTRYPOINT command /bin/graphdb; whereas in the second case, you are passing -p 7200:7200 to docker run, which is what you wanted.
How to validate when ports are correctly forwarded?
You can validate this by running docker ps and checking the PORTS column:
$ docker run -d 34a1650b461d -p 7200:7200
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
03abc0b390ef mytest "/bin/graphdb -p 720…" 6 seconds ago Up 5 seconds 7200/tcp elegant_wescoff
Do you see how the COMMAND includes your -p? That's not what you wanted. So docker run was not interpreting that parameter at all. Also, you can see the PORTS column, which shows the port is exposed but not forwarded.
Whereas doing it like this:
$ docker run -d -p 7200:7200 34a1650b461d
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
03abc0b390ef mytest "/bin/graphdb" 6 seconds ago Up 5 seconds 0.0.0.0:7200->7200/tcp elegant_wescoff
You can see now that -p is not being passed to COMMAND and that the port is forwarded: 0.0.0.0:7200->7200/tcp.

Related

HTTP call to Logic App in a Docker Container

I've followed getting started with Logic Apps in a Container, in Azure Tips & Tricks #311, which worked OK. I also consulted Vinnie James, which is similar
The Logic App runs on receipt of a HTTP request, which - inside VS Code - is localhost, easily used from a browser
But when I go to the next step, to build an image and run it in Docker, I'm not at all clear how to to make a similar HTTP request; Docker is running on the same W10 machine, using WSL-2
Dockerfile (corrected):
FROM mcr.microsoft.com/azure-functions/dotnet:3.0.14492-appservice
ENV AzureWebJobsStorage=DefaultEndpointsProtocol=https;AccountName=XXX;AccountKey=XXX;EndpointSuffix=core.windows.net
ENV AzureWebJobsScriptRoot=/home/site/wwwroot \
AzureFunctionsJobHost__Logging__Console__IsEnabled=true \
FUNCTIONS_V2_COMPATIBILITY_MODE=true
ENV WEBSITE_HOSTNAME localhost
ENV WEBSITE_SITE_NAME testqueue1
ENV AZURE_FUNCTIONS_ENVIRONMENT Development
COPY . /home/site/wwwroot
Attempted Docker run: docker run -p 80:7071 image1
Response is HTTP request sent, awaiting response... No data received
This despite (very simple) Logic App issuing a 200 response immediately after trigger; looks like App is not initiated ...
First of all and regarding the answer in the comments: please just add the contents of the Dockerfile and the run command to the question, otherwise they're difficult to read.
Taking into account that you have the following Dockerfile:
FROM mcr.microsoft.com/azure-functions/node:3.0
ENV AzureWebJobsStorage DefaultEndpointsProtocol=https;AccountName=XXX;AccountKey=XXX;EndpointSuffix=core.windows.net
ENV AzureWebJobsScriptRoot=/home/site/wwwroot \
AzureFunctionsJobHost__Logging__Console__IsEnabled=true \
FUNCTIONS_V2_COMPATIBILITY_MODE=true
ENV WEBSITE_HOSTNAME localhost
ENV WEBSITE_SITE_NAME test1
ENV AZURE_FUNCTIONS_ENVIRONMENT Development
COPY . /home/site/wwwroot
and that you're running it with docker run -p 5000 image1
The main thing that I see here is that you're only indicating the containerPort but not the hostPort, so you're exposing a random port in the host.
If you do docker ps, you'll be able to see the port that you're forwarding. For example let's say that I have my image busybox and that I run it with docker run -it --rm -p 5000 busybox.
❯ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
05927642abfc busybox "sh" 6 seconds ago Up 5 seconds 0.0.0.0:51883->5000/tcp elated_gauss
As you can see, I'd have to access to the port 51883 in localhost to access to the port 5000 in the container.
On the other hand, if I run my container with: docker run -it --rm -p 5000:5000 busybox
❯ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c0aab9646d1a busybox "sh" 1 second ago Up 1 second 0.0.0.0:5000->5000/tcp busy_roentgen
Now I can access to the port 5000 of the container referring to the port 5000 on localhost.

Docker order of parameters results in exited container

The following command works and results in the container continuing to run
$ docker run --name mysql -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD=P#ssword1 mysql:5.7.31
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
fd096c5aa2f6 mysql:5.7.31 "docker-entrypoint.s…" 4 seconds ago **Up 3 seconds** 0.0.0.0:3306->3306/tcp, 33060/tcp mysql
If I change the placement of the port definition (put it at the end) the container exits immediately
$ docker run --name mysql -d -e MYSQL_ROOT_PASSWORD=P#ssword1 mysql:5.7.31 -p 3306:3306
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c723a5e63da0 mysql:5.7.31 "docker-entrypoint.s…" 2 seconds ago **Exited (1) 2 seconds ago** mysql
Can someone explain why this is? It seems at odd with just about every other application where the order of the command line options arguments is largely irrelevant. It is also very difficult for a new user to work out what is wrong and a poor experience.
Oddly too, if the -p 3306:3306 is omitted the container works.
The order of options is completely irrelevant. That said, the documentation clearly states that for docker run command options be must be specified before the name of the image, like in your first and third example.
In your second example -p 3306:3306 is after the image name and is therefore considered to be a command to be run inside the container. Since it's not a valid command, the container exits immediately.
Finally, you last example works, because exposing ports is not mandatory.

Wiremock Docker Container not using the supplied port (instead using 8080)

I am using WireMock Docker image and spinning off the container using it. I can verify the container is up and running but after looking at container logs, looks like it is still running on 8080? At least, I am not able to access Wiremock using localhost:9999/__admin
Create Wiremock container: docker run -d -p 9999:9999 my-registry.com/rodolpheche/wiremock --verbose
Verify container: docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7b9847734cd4 my-registry.com/rodolpheche/wiremock "/docker-entrypoint.…" 7 seconds ago Up 5 seconds 8080/tcp, 8443/tcp, 0.0.0.0:9999->9999/tcp elegant_elion
You need to run docker run -it --rm -p 9999:8080 rodolpheche/wiremock in order to run the Wiremock as clearly mentioned in the documentation. It will be accessible using this url: http://localhost:9999/__admin
This fixed my issue (appending --port 9999):
docker run -d -p 9999:9999 my-registry.com/rodolpheche/wiremock --verbose --port 9999

Unable to connect with container at address /0.0.0.0:9000

My container of play/scala application starts at [info] p.c.s.AkkaHttpServer - Listening for HTTP on /0.0.0.0:9000. But I am unable to connect to it from the browser. I am running the container on my windows machine after having build the image using Docker for Windows
The Dockerfile is
FROM openjdk:8
WORKDIR deploy
COPY target/universal/myapp-1.0.zip .
COPY conf/logback_dev.xml ./logback.xml
COPY conf/application_dev.conf ./application.conf
RUN unzip myapp-1.0.zip
RUN chmod +x myapp-1.0/bin/myapp
EXPOSE 9000
ENTRYPOINT myapp-1.0/bin/myapp -Dplay.http.secret.key=changemeplease -Dlogger.file=/deploy/logback.xml -Dconfig.file=/deploy/application.conf
I am starting the container as docker run myApp -p 9000:9000 -network="host" and also tried docker run myApp -p 9000:9000 -network="host"
UPDATE
this is interesting.
If I specify image name before port then the application isn't reachable
docker run myApp -p 9000:9000
In docker container ps -a, I see (no mapping of localhost:9000 to 9000)
C:\Users\manuc>docker container ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4d16547cd96d myApp "/bin/sh -c 'myApp…" 10 seconds ago Up 9 seconds 9000/tcp, 9042/tcp ecstatic_bell
but if I specify port before image name, then the application is reachable
docker run -p 9000:9000 myApp
In docker container ps -a, I see mapping of localhost:9000 -> 9000
C:\Users\manuc>docker container ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
24b571cc0057 myApp "/bin/sh -c 'MyApp…" 39 seconds ago Up 38 seconds 0.0.0.0:9000->9000/tcp, 9042/tcp silly_yalow
Things to do when your container is not behaving like you want:
Check if your application is running in your computer.
After you run your container, check if it is healthy with docker ps. If it is not healthy, the problem is usually in your application.
Ensure it is running without errors, check logs with docker logs <container-id>. If logs are ok, problem is usually in the container network configuration.
Ensure you can access your application with docker exec -it <container-id> bash. And try to access port with curl or wget. If it is not reachable problem can be in iptables, firewall, or your application.
If you can ensure all the steps above working as expected. The problem is in docker network configuration.
Docker network host only works in linux, not mac and windows. You can run container with docker run -p 9000:9000 myapp. Checkout documentation: https://docs.docker.com/network/host/#:~:text=The%20host%20networking%20driver%20only,the%20docker%20service%20create%20command.
General form of the docker run command is docker run [OPTIONS] IMAGE[:TAG|#DIGEST] [COMMAND] [ARG...] as you can see in documentation. You need to specify port options before image name.

Docker for Mac. docker run -d -p 80:80 --name webserver nginx shows another container with this name. but docker ps shows empty list

I am learning "Docker for Mac"
$ docker run -d -p 80:80 --name webserver nginx
docker: Error response from daemon: Conflict. The name "/webserver" is already in use by container 728da4a0a2852869c2fbfec3e3df3e575e8b4cd06cc751498d751fbaa75e8f1b. You have to remove (or rename) that container to be able to reuse that name..
But when I run
$ docker ps
It shows no containers listed.
But due to the previous error message tells me that there is this container 728da....
I removed that container
$ dockder rm 728da4a0a2852869c2fbfec3e3df3e575e8b4cd06cc751498d751fbaa75e8f1b
Now I run this statement again
$ docker run -d -p 80:80 --name webserver nginx
It is working fine this time.
And then I run $ docker ps, I can see this new container is listed
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
3ecc0412fd31 nginx "nginx -g 'daemon off" 19 seconds ago Up 17 seconds 0.0.0.0:80->80/tcp, 443/tcp webserver
Note:
I am using "Docker for Mac".
But I had "Docker Box" installed on the Mac before. I don't know if that is the invisible "webserver" container comes from.
As activatedgeek says in the comments, the container must have been stopped. docker ps -a shows stopped containers. Stopped containers still hold the name, along with the contents of their RW layer that shows any changes made to the RO image being used. You can reference containers by name or container id which can make typing and scripting easier. docker start webserver would have restarted the old container. docker rm webserver would remove a stopped container with that name.
You can also abbreviate the container id's to the shortest unique name to save typing or a long copy/paste. So in your example, docker rm 728d would also have removed the container.
The Docker Getting Started document asks the learners trying two statements first.
docker run hello-world
and
docker run -d -p 80:80 --name webserver nginx
I was wondering why I can run
docker run hello-world
many times but if I run
docker run -d -p 80:80 --name webserver nginx
the second time, I got the name conflicts error. Many beginners would be wondering too.
With your help and I did more search, now I understand
docker run hello-world,
we did not use --name, in this case, a random name was given so there will be no name conflicts error.
Thanks!

Resources