Docker support

[configurator]

The default image(s) should include some sort of docker support, so I can run docker build, as well as docker start to run either my own service (and expose ports as usual) or its requirements.

[svenefftinge]

That's unfortunately not possible to do as it would require running the workspace containers in privileged mode. But we should have a command line util that allows to build and run docker images externally as a service.

[dimensi0n]

Any news about this command line util ?

[jankeromnes]

@dimensi0n we haven't looked at implementing this yet, but now I'm thinking that maybe we could somehow interface a local docker CLI with our image-builder (since I can already make it build stuff by adding a Dockerfile to my .gitpod.yml, I don't see why I couldn't also do the same via an in-workspace docker CLI).

Maybe this could also somehow be a way to improve Gitpod's repository setup automation workflow (where currently I need to commit a Dockerfile, push it to a branch, manually create a new workspace for that branch, test it, and return to my first workspace to iterate in a relatively tedious way).

[JesterOrNot]

Just spitballing but could you install docker in the default Gitpod image and then add the gitpod user to the docker group? I think that it would allow users to test Dockerfiles from the command line.

[jankeromnes]

Thanks for the suggestion @JesterOrNot. Unfortunately, I believe that from a security standpoint, adding user gitpod to the docker group is akin to giving users sudo rights. See also #755.

However, maybe it's possible to install the docker CLI in the default Gitpod image, and configure it to use Gitpod's image-builder (you can already make it build anything by adding a Dockerfile to your project, so CLI would just be a more convenient access) instead of building containers locally (which would be docker-in-docker, and require some sort of risky security trade-offs).

[JesterOrNot]

Heres another idea you know google cloud shell? well there is a vscode extension that allows you to access it remotely it's free and has docker installed in it could we either set it up as a remote client or have the extension pre-installed?

[JesterOrNot]

Here is a repo with the Docker CLI installed in it can someone help me get it hooked up to the gitpod image builder? or maybe just send a PR
https://github.com/JesterOrNot/Gitpod-Docker

[jankeromnes]

Thanks a lot @JesterOrNot!

I'm not sure how to use Gitpod's image-builder API. @32leaves or @geropl do you have any insights here? (We're trying to make image-builder build a Dockerfile, not by committing to a repo and opening it in Gitpod, but by directly sending the Dockerfile to image-builder.)

[JesterOrNot]

Any updates per the status of this issue?

[meysholdt]

Hi @JesterOrNot ,

not much of an update, unfortunately, but more details to share.

The challenge here is that the standard docker daemon requires root privileges and in the Gitpod workspaces we don't have root privileges.

Things you could do:

1. bring-your-own-docker-engine. See here for an example. This means you run a docker engine on your own infrastructure and connect to it from a docker workspace.
2. Get Rootless Docker working. In theory this should work in GItpod, but in practice something doesn't work yet. The following Dockerfile from @geropl may by a good stating point:

USER gitpod

# Rootless Docker
# gets installed to /home/gitpod/bin
RUN curl -sSL https://get.docker.com/rootless | sh
# It requires the following env vars:
ENV XDG_RUNTIME_DIR=/tmp/docker-33333
ENV PATH=/home/gitpod/bin:$PATH
ENV DOCKER_HOST=unix:///tmp/docker-33333/docker.sock

Things the Gitpod team can be doing:
3. Allow triggering Gitpod's image builder form a workspace. However, even if we do this, this will never be a replacement for full docker support. It will only be to test if the dockerfile configured in .gitpod.yml works. And for security reasons, we can't allow docker run in the image builder.
4. Improve sandboxing of workspaces and allow root in workspaces.

But we don't have a time plan for this yet, so playing with option (1) and (2) will be well worth it.