Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

ssaavedra
Copy link

This may enhance the user experience when using dind as part of a
Continuous Integration environment.

This may enhance the user experience when using dind as part of a
Continuous Integration environment.
@tianon
Copy link
Member

tianon commented Jun 8, 2017

See also #12 and #20 where this has been proposed before. 👍

@tianon
Copy link
Member

tianon commented Jun 13, 2017

(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.)

@ssaavedra
Copy link
Author

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.

@yosifkit yosifkit mentioned this pull request Dec 1, 2017
@stefanotorresi
Copy link

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.

@yosifkit
Copy link
Member

yosifkit commented May 2, 2018

You can specify command on GitLab CI now: https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#available-settings-for-services so there is no need to use env vars to hack around their limitations.

@davidkarlsen
Copy link

Hmm, I tried adding to command: docker run --name test --rm --privileged docker:19.03.12-dind --mtu 1440

which is passed, but still the docker0 has MTU 1500?!

/usr/local/bin # ps xa
PID   USER     TIME  COMMAND
    1 root      0:00 dockerd --host=unix:///var/run/docker.sock --host=tcp://0.0.0.0:2376 --tlsverify --tlscacert /certs/server/ca.pem --tlscert /certs/server/cert.pem --tlskey /certs/server/key.pem --mtu 1440
   53 root      0:02 containerd --config /var/run/docker/containerd/containerd.toml --log-level info
  173 root      0:00 sh
  206 root      0:00 ps xa
/usr/local/bin # ifconfig 
docker0   Link encap:Ethernet  HWaddr 02:42:14:27:C6:0E  
          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:02  
          inet addr:172.17.0.2  Bcast:172.17.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:13 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:1046 (1.0 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)

@yosifkit
Copy link
Member

Sorry for the silence.

Note to future users: While the --mtu flag does not seem to apply to the docker0 bridge, it does apply to containers created by dockerd (on the default network):

$ 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# 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants