I was doing a test where I installed Docker version 20.10.8, build 3967b7d to a machine that hadn't had Docker installed, and then deployed a .tar file of a Docker container to this new machine.
I then ran the Docker container, but did not include a "--network" parameter in the "docker run" command line, and when the dockerized app started, it was not able to resolve some hostnames that it uses, and I was seeing "UnknownHostException" exceptions in the dockerized app logs.
So, to get the dockerized app to run, I did the same "docker run" command, but this time, I included a "--network host" parameter. When the app started, it was then able to DNS resolve hostnames, and I didn't get the "UnknownHostException" exceptions anymore.
Subsequently, I did "docker stop", "docker rm" and then "docker run" commands multiple times for some other testing, but I wanted to try to investigate the "UnknownHostException" problem, so I eventually did "docker stop", "docker rm", and then "docker run" commands, BUT WITH NO "--network" parameter, and I was expecting to see the "UnknownHostException" again, but the "UnknownHostException" exceptions NO LONGER APPEARED, even though container was using Docker BRIDGE networking!!!
I've been trying to understand/figure out "Why?" for awhile but then I just checked in the /var/lib/containers/<LONG_STRING_OF_NUMBERS-LETTERS> and noticed that there was a "resolv.conf" in that directory, and found that the contents of that "resolv.conf" file were identical to the contents of the physical machine's /etc/resolv.conf!!
So I am theorizing that:
a) When I initially did the "docker run" with no "--network" parameter, that the "resolv.conf" inside the container was empty (or some default), then
b) When I did the "docker run" with "--network host", that Docker COPIED the physical /etc/resolv.conf to the container's "resolv.conf", BUT then
c) When I did "docker run" but WITHOUT any "--network" parameter (i.e., with bridge networking), the container's "resolv.conf" retained/persisted/didn't get cleared out.
Can anyone confirm if the above behavior is what is happening?
Also, as I mentioned earlier, I have been doing "docker stop" and "docker rm" before I do "docker run", but is there some other command (or parameter) that I should be using to prevent the container "resolv.conf" from persisting when switching from bridge mode, to host mode, and then back to bridge mode?
My apologies for the longish question, but I am trying to provide as clear an explanation of my question as I can.
Thanks in advance!!!
Jim
CodePudding user response:
Docker fully manages /etc/resolv.conf
inside your container, and most of the other details of the networking environment. If there's a resolv.conf
file in the image, it's hidden and unused. If you need to override the DNS resolver, there is a docker run --dns
option that can do that.
You should almost always invoke docker run
with a --net
matching the name of a network you've docker network create
d. Omitting the --net
option uses a first-generation Docker networking setup that's very limited; --net=host
completely disables Docker networking. The network itself does not have any DNS-related settings.
# does not need any options but does need to be created
docker network create a-network
docker run --net=a-network --dns=8.8.8.8 ...