-
Notifications
You must be signed in to change notification settings - Fork 595
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow dind images to include parameters in env variables #62
Conversation
This may enhance the user experience when using dind as part of a Continuous Integration environment.
(Meaning, I still agree with the rationale that led to the closure of #12 and #20, and so if this is something that's really necessary, a more compelling argument in favor of it is going to be necessary -- it is a major shortcoming of any Docker-consuming/Docker-including system if it allows for running images with modified parameters such as environment variables but not modifying the command of the container, and is a shortcoming which should be corrected in that system, not in every image that might be interesting to consume within that system.) |
Sorry for the late reply, I've been out. Thank you for the feedback. First and foremost, I do agree with you in that arbitrarity in such a matter should be, in general, a problem of the image-consuming sytem. However, Docker already has at least one setting whose preferred way (meaning that it overrides other settings) of configuration is an environment variable (and that is widely used, and actually recommended for example from Gitlab), which is the "DOCKER_DRIVER" environment variable to set the appropriate storage driver (overlay2/overlay/etc). (see daemon/daemon.go#L598) Having constrained images to do one thing and customizing them through the environment also seems to go with the spirit of most Docker images, whereby changing the CMD has a higher impact on the semantics of the operation carried out. But if one is to change certain configurations that should, according to the above (which is just my opinion, and you may of course disagree), go in an environment variable, such as, maybe, an HTTP proxy, or an alternate Docker Registry, we must instead change the CMD line. That also has a secondary effect: we must rely on the docker image to still provide the same ENTRYPOINT on upgrades, or we will have to change the CMD line accordingly. In opposition, environment varialbes have a much easier path to backwards-compatibility and deprecation, even if this image changes its ENTRYPOINT in the future. Other "daemon-like" images, such as databases tend to work in this very way. You don't usually change the CMD line, but instead alter the specific configurations via environment variables. I would understand adding specific variables, such as DOCKER_DNS, DOCKER_BIP or DOCKER_REGISTRY_MIRROR instead, if DOCKER_OPTS is too generic a variable. If there are points where you think I must be mistaken here, please let me know. |
FWIW I would very much appreciate going for specific env variables as eventually suggested, specifically DOCKER_REGISTRY_MIRROR was the one I was looking for. |
You can specify |
Hmm, I tried adding to command: which is passed, but still the docker0 has MTU 1500?!
|
Sorry for the silence. Note to future users: While the $ docker run --name dindy -d --rm --privileged docker:20.10-dind --mtu 1440
...
$ $ docker exec -it dindy sh
/ # docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
/ # ifconfig
docker0 Link encap:Ethernet HWaddr 02:42:6C:DE:38:F7
inet addr:172.18.0.1 Bcast:172.18.255.255 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:04
inet addr:172.17.0.4 Bcast:172.17.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:33 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5674 (5.5 KiB) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
/ # docker run -it --rm bash
Unable to find image 'bash:latest' locally
latest: Pulling from library/bash
339de151aab4: Pull complete
94a52eec71b5: Pull complete
15ab8d50c870: Pull complete
Digest: sha256:c523c636b722339f41b6a431b44588ab2f762c5de5ec3bd7964420ff982fb1d9
Status: Downloaded newer image for bash:latest
bash-5.1# ifconfig
eth0 Link encap:Ethernet HWaddr 02:42:AC:12:00:02
inet addr:172.18.0.2 Bcast:172.18.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1440 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
bash-5.1# |
This may enhance the user experience when using dind as part of a
Continuous Integration environment.