docker-in-docker: Add an onCreateCommand to wait for Docker to be ready
#710
Conversation
…eady In my devcontainer, which runs as an unprivileged user, Docker was not running properly after the script started up. Editing the script to output more debug info (to make `docker info` not be quiet) showed it was outputting: > ERROR: permission denied while trying to connect to the Docker daemon > socket at unix:///var/run/docker.sock: Get > "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/info": dial unix > /var/run/docker.sock: connect: permission denied Further adding a `groups` call showed that the user was not in the `docker` group when we tried to call `docker info`. This made it always fail when run from the install script. The retry loop ran the maximum number of times, and we were left with several `defunct` (zombie) docker and containerd processes. Moving the checking to an `onCreateCommand` fixes this, as this runs fully as the user. Furthermore, this makes the user's commands, and the container's startup, block on Docker being available. This is beneficial, as it means that there won't be a time when you can use the dev container but Docker isn't there. We do still keep the retrying logic, and we signal between the `onCreateCommand` and the install script by creating a flag file.
|
@microsoft-github-policy-service agree company="Grafana Labs" |
There was a problem hiding this comment.
Hi 👋
Thank you for your interest in contributing this enhancement, we appreciate it. ✨
This change should work for creates, however, for resumes we still cannot guarantee that docker will be started. Instead, would you be willing to contribute a PR for devcontainers/spec#299? This should avoid adding onCreateCommand and should work for creates and resumes. Also, being a blocking entrypoint, we can ensure that docker is first started even before we run any other lifecycle commands. Hence, it should be a full proof solution.
Let me know what you think, happy to assist with the PR contribution for the cli repository.
|
Hey @samruddhikhandale. Thanks for the feedback. I can take a look at the other issue. I think features being able to have synchronous initialisation is certainly a better way to do this. I can't promise to have too much time to dedicate to it, though, so it might take a while. (Don't rely on me!) I also noticed that this PR isn't 100% reliable even for creation yet - it didn't work in Codespaces, for example. Maybe that's because I need to add it to |
In my devcontainer, which runs as an unprivileged user, Docker was not running properly after the script started up. Editing the script to output more debug info (to make
docker infonot be quiet) showed it was outputting:Further adding a
groupscall showed that the user was not in thedockergroup when we tried to calldocker info. This made it always fail when run from the install script. The retry loop ran the maximum number of times, and we were left with severaldefunct(zombie) docker and containerd processes.Moving the checking to an
onCreateCommandfixes this, as this runs fully as the user. Furthermore, this makes the user's commands, and the container's startup, block on Docker being available. This is beneficial, as it means that there won't be a time when you can use the dev container but Docker isn't there.We do still keep the retrying logic, and we signal between the
onCreateCommandand the install script by creating a flag file.