Setting a MTU for dind is difficult

[neclimdul]

moby/moby#36659 isn't fixed for me yet, but assuming at some point it is setting the MTU is currently a bit tricky for the dind image in certain scenarios.

In my case I want to run dind as a service to GitLab CI builds running in Kubernetes. For that to work I need to control the MTU of the docker bridge and I have limited control of how the service is started. Basically only really able to specify environment and and image (not able to interact with entrypoint).

I think I have 2 options.

1. Extending the image and provide a mechanism for setting the MTU during startup using that image as a service.
2. Help this repo could have an environment variable for controlling the MTU.

If 2, I'm willing to do the work writing and testing a PR given some direction on what sort of approach would be ideal. Or just testing someone else's PR. :-D

[playworker]

Try this: https://hub.docker.com/r/lordgaav/dind-options/

Worked for me by setting DOCKER_OPTS: "--insecure-registry [snip] --mtu=1400" in my .gitlab-ci.yml, apologies if I misunderstood and this doesn't help :)

[yosifkit]

Duplicate of #102.

As a side note, 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.

[neclimdul]

useful trick thanks. #102 is closed(and I can't re-open it) so is it safe to assume the docker image isn't going to add a specific fix for this?

[yosifkit]

Is there something that we can do in the image? From #102 I had assumed that it was not something that could be fixed in the image.

Not sure why you can't re-open your own issue that you closed. 😕

[neclimdul]

oh you're right because I closed it. I don't github much and have never been able to re-open an issue before.

I don't know what was happening over there but I think it was a combination of it being hard to set for the container and some weird behaviors in how docker handles mtu.

I assume its possible to do --mtu=$DOCKER_MTU or similar in the entry point if that's a feature deemed useful enough. That's sort of the discussion I wanted to open up with this issue.

[yosifkit]

As far as adding special environment variables that are just passed as flags to dockerd see #12, #20, #62, and #96. There is no need to complicate the entrypoint for env vars when they can just be passed as flags to dockerd.

$ docker run ... docker:18.04-dind --storage-driver aufs --mtu=1450 --etc

[zioalex]

After some tentative ( "I became mad about it" ), I figured out how to do it. Though this is referred in multiple locations I could not find a a clear explanation.
To get this working I needed to change my docker:dind definition from

services:
  # include the docker-in-docker network service
  - docker:dind

To

services:
  # include the docker-in-docker network service
  - name: docker:dind
    command: ["--mtu=1300"]

To test it inside the Gitlab container you should get:

/ # docker network inspect bridge
[
    {
        "Name": "bridge",
...
...
...
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1300"
        },
        "Labels": {}
    }
]

I was mislead from the Gitlab documentation where the example show only the first version.

[hameno]

@yosifkit

As far as adding special environment variables that are just passed as flags to dockerd see #12, #20, #62, and #96. There is no need to complicate the entrypoint for env vars when they can just be passed as flags to dockerd.

$ docker run ... docker:18.04-dind --storage-driver aufs --mtu=1450 --etc

There is a big need for it: Being able to globally configure this with env variables in Gitlab CI so that not every project needs to adjust their gitlab-ci.yaml with the setup described by @zioalex