Add Docker CLI to Docker image

[sixeyed]

Describe in detail the problem you had and how this PR fixes it

Run code-server in Docker, then browse and open a terminal. You have access to all the tools installed in the Docker image (e.g. git) but no app runtimes so you can't build or run anything. Adding the Docker CLI into the Docker image will let you mount the Docker engine from the host, and then you can do docker build and docker run.

Is there an open issue you can link to?

No. See this blog post for usage.

[nhooyr]

I'd say its better we just include a docker daemon within the container itself like https://hub.docker.com/_/docker

Almost all devs will want this so its a good idea to make it work by default.

[nhooyr]

But it would be unfortunate to make the container privileged.

[ericcollazo]

I'd say its better we just include a docker daemon within the container itself like https://hub.docker.com/_/docker

Almost all devs will want this so its a good idea to make it work by default.

You'd be better off mounting the docker daemon from the host machine.

Use the following option with a "docker run" command to mount the socket:

-v /var/run/docker.sock:/var/run/docker.sock

Example:

docker run -it -v /var/run/docker.sock:/var/run/docker.sock ubuntu:latest

[sixeyed]

dind is an option but adds a bunch of complication - and it means you start with an empty Docker build cache every time, whereas this option uses the build cache from the host.

[nhooyr]

dind is an option but adds a bunch of complication - and it means you start with an empty Docker build cache every time, whereas this option uses the build cache from the host.

That's fair but it won't be restarted often, at least it shouldn't be, and you can always have a custom image with the cache prepopulated.

The problem with mounting the socket is that volume mounts won't work at all anymore because the paths passed to the host docker daemon will be resolved from the perspective of the host, not the container.

[ericcollazo]

dind is an option but adds a bunch of complication - and it means you start with an empty Docker build cache every time, whereas this option uses the build cache from the host.

That's fair but it won't be restarted often, at least it shouldn't be, and you can always have a custom image with the cache prepopulated.

The problem with mounting the socket is that volume mounts won't work at all anymore because the paths passed to the host docker daemon will be resolved from the perspective of the host, not the container.

I don't believe that to be accurate. Mounting the socket just gives you access to the docker engine. Any other volumes mounted at "docker run" time will still work normally.

[nhooyr]

I don't believe that to be accurate. Mounting the socket just gives you access to the docker engine. Any other volumes mounted at "docker run" time will still work normally.

No they won't. Give it a shot.

[ericcollazo]

I don't believe that to be accurate. Mounting the socket just gives you access to the docker engine. Any other volumes mounted at "docker run" time will still work normally.

No they won't. Give it a shot.

Check this out.

https://forums.docker.com/t/how-can-i-run-docker-command-inside-a-docker-container/337

[sixeyed]

@nhooyr is right here - when you mount the socket, the docker CLI commands are running on the host, so it's the host's disk you're mapping if you try to map volumes. Confirmed this by running my fork:

docker container run \  
 -d -p 8443:8443 \
 -v /var/run/docker.sock:/var/run/docker.sock \
 --network code-server \
 sixeyed/code-server:1.621 \
 --allow-http --no-auth

When I create containers through the terminal in the Code browser window, the volume mount source is the host's filesystem.

But... The current image doesn't have the Docker CLI at all, so you can't run containers and this is an improvement :)

[nhooyr]

But... The current image doesn't have the Docker CLI at all, so you can't run containers and this is an improvement :)

Sort of. This is a very confusing nuance and users will definitely be pissed off after they spend 3 hours debugging it.

So, unfortunately this cannot be accepted in its current state. DIND is the only reasonable way to do this. Since almost every user will want access to a docker daemon, I think its a good idea to put it in the default image.

[nhooyr]

Actually never mind, can't be in the default image as then it requires that the container is privileged. Best we add another image like codercom/code-server:dind

[sixeyed]

Okay, I'll leave you guys to go the dind route :)