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

docker:dind 20.10 - docker tcp host cannot be overridden #292

Closed
acornax opened this issue Feb 9, 2021 · 10 comments
Closed

docker:dind 20.10 - docker tcp host cannot be overridden #292

acornax opened this issue Feb 9, 2021 · 10 comments
Labels
question Usability question, not directly related to an error with the image

Comments

@acornax
Copy link

acornax commented Feb 9, 2021

When using the docker:dind image, it's not possible to control which port it listens on when using its default entrypoint, because this is hardcoded: https://github.com/docker-library/docker/blob/master/20.10/dind/dockerd-entrypoint.sh#L120

We would like to be able to override this port, ideally by passing an environment variable to the dind container. I am happy to submit a pull request if that would be of interest.

In our specific use case we're upgrading the dind image we use to enable TLS, but we don't want to have to update every piece of old code to use tcp://0.0.0.0:2376. We'd rather it continue using tcp://0.0.0.0:2375.

@tianon
Copy link
Member

tianon commented Feb 9, 2021

The easiest method is probably going to be using --host tcp://0.0.0.0:2375 as your command:

$ docker run ... docker:dind --host tcp://0.0.0.0:2375
...
INFO[2021-02-09T22:45:02.518755151Z] API listen on /var/run/docker.sock           
INFO[2021-02-09T22:45:02.521987045Z] API listen on [::]:2376                      
INFO[2021-02-09T22:45:02.525054786Z] API listen on [::]:2375                      

@acornax
Copy link
Author

acornax commented Feb 9, 2021

Thanks for the response. That's good to know about.

Unfortunately, we're using gitlab, and we don't have an easy way to add extra arguments to everything that uses dind. We do have control over environment variables though, which is why I mentioned them.

@wglambert wglambert added the question Usability question, not directly related to an error with the image label Feb 10, 2021
@acornax
Copy link
Author

acornax commented Feb 11, 2021

Would you be open to having an environment variable for the port added? I can submit a PR.

@yosifkit
Copy link
Member

We are very hesitant to add extra environment variables at this time, especially for things that can already be accomplished through arguments to dockerd. Same rationale as #62 (comment) (and related to #12 and #20).

@acornax
Copy link
Author

acornax commented Feb 12, 2021

Thanks for providing your rationale.

The solution offered in #62 won't work for our purposes due to gitlab's limitations - it's only possible to set command arguments at the level of individual jobs.

For some context, this issue came up for us because the newest dind image broke all our builds, as when TLS is disabled the dind entrypoint doesn't provide the necessary flags to disable it. I'll raise a separate issue for this problem.

@acornax
Copy link
Author

acornax commented Feb 12, 2021

Our issue with disabling TLS is #294.

@fredcooke
Copy link

@tianon the --host tcp://0.0.0.0:2375 option you suggested simply opens a second port with TLS enabled, right?

Is it possible to enable both TLS on 2376 AND non-TLS on 2375 so as to provide the option to migrate without breaking the stragglers?

@tianon
Copy link
Member

tianon commented Oct 11, 2021

Unfortunately, I don't think Docker itself supports both TLS and non-TLS at the same time. 😞

@fredcooke
Copy link

Thanks @tianon - all good, we're on TLS now even though it's inside a single pod and on the local network of a single host. The slight inefficiency isn't noticeable so it doesn't matter. But I'd suggest that this is a valid and in fact probably common use case at least with Kube users (which is tending toward everyone these days) and that you should therefore not remove non-TLS and make it easier to get a non-broken-non-15second-obnoxious delay out of the thing for that valid use case where security of the connection makes almost no sense at all.

@tianon
Copy link
Member

tianon commented Oct 12, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Usability question, not directly related to an error with the image
Projects
None yet
Development

No branches or pull requests

5 participants