Use DOCKER_SOCKET_PATH for pulling sibling container images
Nobody has claimed this yet.
- Dominant language
- Shell
- Stars
- 1.3k
- Forks
- 310
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 1
Description
Steps to Reproduce
- Enable sibling containers and set DOCKER_SOCKET_PATH to custom docker.sock
- Enable automatic sibling container pulling: SIBLING_CONTAINERS_PULL=true
- Start overleaf: bin/up
Expected Behaviour
Docker images should get pulled through the same docker.sock that will receive run commands for sibling containers.
Observed Behaviour
Images for sibling containers get pulled through the default docker.sock of the host system.
Context
Personally I don't like giving a container access to the hosts docker.sock, basically giving it access to other containers as well.
That's why I wanted to set up a docker in docker (DinD) setup, where I provide a separate docker.sock from the docker - docker container. This already works well, but I have to pull needed sibling container images manually inside the DinD container before I can use them in Overleaf.
Optionally (for my DinD case)
It would be great if the sibling image pulling could get timed somehow to make sure the docker.sock is available.
I don't know how doable this is, but maybe just polling the socket until it becomes available could be a good start.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with bin/up and trace the sibling-container image-pulling path used when SIBLING_CONTAINERS_PULL=true. Check how DOCKER_SOCKET_PATH is passed to pulls versus sibling-container run commands, then verify that images are pulled through the configured socket, including the DinD case if feasible.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, shell
- Domain
- devops, infrastructure
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100