[docker in docker] Adds retries for docker daemon startup and cgroup nesting #669
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
samruddhikhandale
changed the title
|
Note: The failing test will be fixed with #661 |
joshspicer
approved these changes
Aug 24, 2023
@joshspicer **100 😛 |
This was referenced Aug 24, 2023
Docker-in-docker: Add retry mechanism into the docker init script (Failed to connect to Docker)
#634
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ref: #634 and #660
Updates in this PR -
sed: couldn't flush stdout: Device or resource errorswhich fails to start docker.25d2e80 adds retries to fix suchsederrorsonCreateCommandImportant Note:
/usr/local/share/docker-init.shwhich starts/retries dockerd is added to theentrypointcommand. This command runs in the background and is not a blocking script for the container startup. Since it's in the background,onCreateCommand/postCreateCommand/postStartCommandcould all start executing before docker is fully running. If it takes docker too long, that could introduce flakiness in those lifecycle scripts.Opened devcontainers/spec#299 which requests a new semantics to have "blocking" entrypoints that the CLI waits for. This way we can ensure that docker is already up and running for the mentioned ^ lifecycle scripts and is available in the container.