Why is Drupal for Docker returning an empty reply from server? - docker

I am somewhat new to Docker. I'm trying to get it set up on my machine, but I can't seem to connect from the host.
My run command
docker run -p 8080:80 drupal:9.1-php7.4-fpm-alpine3.13
Expected result
Based on the image documentation, I would expect to see some kind of default Drupal page on 8080.
Actual result
$ curl http://localhost:8080
curl: (52) Empty reply from server
In Firefox this renders as, "The connection was reset."
What I've tried
There are other questions that have similar symptoms, but the solutions don't seem to work for me.
One common suggestion is to curl to a different IP such as 0.0.0.0:8080. I'm a little skeptical because that conflicts with the image-specific instructions above, but tried it and didn't find evidence there's anything listening there. Also, when the container isn't running, I'm not able to connect to that URL at all, which is slightly different from not getting a response, so I think I'm on the right track with http://localhost:8080/
The other common suggestion is to make sure I'm binding a port outside the container, but in my case it's right there as -p 8080:80.

Always double-check that image tag, kids!
There are a ton of variants of the official docker image, and I accidentally pulled the wrong one. You'll notice the image tag inclues "ftm." I meant Apache. When I run an Apache version of the image, it works out of the box. Facepalm.
That'll do it!
I am leaving this here as a monument to my shame.

Related

Rsyslog can't start inside of a docker container

I've got a docker container running a service, and I need that service to send logs to rsyslog. It's an ubuntu image running a set of services in the container. However, the rsyslog service cannot start inside this container. I cannot determine why.
Running service rsyslog start (this image uses upstart, not systemd) returns only the output start: Job failed to start. There is no further information provided, even when I use --verbose.
Furthermore, there are no error logs from this failed startup process. Because rsyslog is the service that can't start, it's obviously not running, so nothing is getting logged. I'm not finding anything relevant in Upstart's logs either: /var/log/upstart/ only contains the logs of a few things that successfully started, as well as dmesg.log which simply contains dmesg: klogctl failed: Operation not permitted. which from what I can tell is because of a docker limitation that cannot really be fixed. And it's unknown if this is even related to the issue.
Here's the interesting bit: I have the exact same container running on a different host, and it's not suffering from this issue. Rsyslog is able to start and run in the container just fine on that host. So obviously the cause is some difference between the hosts. But I don't know where to begin with that: There are LOTS of differences between the hosts (the working one is my local windows system, the failing one is a virtual machine running in a cloud environment), so I wouldn't know where to even begin about which differences could cause this issue and which ones couldn't.
I've exhausted everything that I know to check. My only option left is to come to stackoverflow and ask for any ideas.
Two questions here, really:
Is there any way to get more information out of the failure to start? start itself is a binary file, not a script, so I can't open it up and edit it. I'm reliant solely on the output of that command, and it's not logging anything anywhere useful.
What could possibly be different between these two hosts that could cause this issue? Are there any smoking guns or obvious candidates to check?
Regarding the container itself, unfortunately it's a container provided by a third party that I'm simply modifying. I can't really change anything fundamental about the container, such as the fact that it's entrypoint is /sbin/init (which is a very bad practice for docker containers, and is the root cause of all of my troubles). This is also causing some issues with the docker logging driver, which is why I'm stuck using syslog as the logging solution instead.

Elastic Search Starts but unreachable

I'm just starting to work with Elastic Search and followed this article here
This article is quite straight forward and explains how to start elastic on docker. To test, I try to do
curl -X GET "localhost:9200/_cat/nodes?v=true&pretty"
Also, tried to just browse to http://localhost:9200 in a browser.
neither returns a response, they just hang for quite a while and nothing..
Also, ran a logstash docker that pointed to http://localhost:9200 and that exits because it doenst find elastic.
I've also tried both options in the article, i.e. single node and cluster, none seem to work or so it seems..
I'm new to elastic and not a docker expert either,
Please let me know if anyone has any idea of what's going on...
Thanks,
This had nothing to do with docker or elastic it turns out. I was running on a proxy network and that was making the defaults URL's unreachable. They became available after I disabled the proxy.

Access to internal infrastructure from Kubernetes

If I run Docker (Docker for Desktop, 2.0.0.3 on Windows 10), then access to internal infrastructure and containers is fine. I can easily do
docker pull internal.registry:5005/container:latest
But ones I enable Kubernetes there, I completely lose an access to internal infrastructure and [Errno 113] Host is unreachable in Kubernetes itself or connect: no route to host from Docker appears.
I have tried several ways, including switching of NAT from DockerNAT to Default Switch. That one doesn't work without restart and restart changes it back to DockerNAT, so, no luck here. This option also seems not to work.
let's start from the basics form the official documentation:
Please make sure you meet all the prerequisites and all other instructions were met.
Also you can use this guide. It has more info with details pointing to what might have gone wrong in your case.
If the above won't help, there are few other things to consider:
In case you are using a virtual machine, make sure that the IP you are referring to is the one of the docker-engines’ host and not the one on which the client is running.
Try to add tmpnginx in docker-compose.
Try to delete the pki directory in C:\programdata\DockerDesktop (first stop Docker, delete the dir and than start Docker). The directory will be recreated and k8s-app=kube-dns labels should work fine.
Please let me know if that helped.

Docker windows container DNS Cache and firewall

I have a Docker windows container and Linux container on a different node.
On windows, I opened ports in the firewall mentioned here: https://docs.docker.com/network/overlay/#operations-for-all-overlay-networks
(8 rules - 4 for in and 4 for out) but even then when I connect to the container on the windows host and try to ping the Linux container I receive "No such host is known" but after executing (inside the container):
Clear-DnsClientCache
everything starts to work.
I also removed the whole stack and tried to disable firewall and surprise - now everything works without clearing the DNS cache.
Once again I removed the stack and enabled the firewall - again I have to connect to the container and clear the cache to make it work.
Looks like there is something wrong in the firewall settings but what? I did not find any other ports which should be opened
Looks like I have just found an answer but I do not fully understand it. I have tried to open ports first 0-9999 then 0-5000 then 0-2500 etc and found out that I need to open port 1888 (tcp, in) to make the docker overlay network work immediately (I mean to be able to resolve services DNS names immediately) but I did not find anything about that on the internet. I have no idea why. Was I only one with that problem? Maybe this is not the correct solution? Could someone tell me why this port is needed and why Clear-DnsClientCache works even when 1888 is blocked?
Edit:
Looks like this solution was wrong. Now it just works once and then does not work and then once again works. I can remove and recreate the whole stack and it just works randomly.

Windows Docker NAT seems completely broken

I have a docker container that has the NAT mapping 0.0.0.0:9055->80/tcp. From what I can tell, this should mean I can go to http://localhost:9055/ on my host machine, and it will be redirected to port 80 on the running Docker image. However, when I try this it times out.
If I connect to the instance and run docker exec -i 52806ceaf166 "ipconfig" to see what the image's private IP is, I get 172.28.27.31. When I try going to http://172.28.27.31/ on the host machine, it works!
I'd like to get the NAT mapping working since that's what all the tools assume works (such as Visual Studio, Kitematic, etc) and plus I don't want to have to worry about which containers use which IPs. Is there a way to fix this? Thanks!
PS: I'm new to Docker (just installed it today) so if any more info is needed (settings, versions, etc) just let me know how to get them and I'll add them to the post.
Was looking at the Docker Image I'm using, and I think this is what I'm running into:
This is a known issue that'll be addressed in the near future. The work around is fairly easy though.
Update: This was fixed in a recent Windows patch available through Windows Update.

Resources