Ability to run "docker in docker"

[edeandrea]

Is your enhancement related to a problem? Please describe.

I'm working with Quarkus applications. Quarkus has this feature called DevServices. If my application requires a database, a Kafka broker, a Keycloak instance, or an Apicurio registry, when I run or test my Quarkus application (i.e. inner-loop development cycle) Quarkus can automatically spin up one of these containers for me and then shut it down when I shut down my application. Under the covers, Quarkus uses Testcontainers to do this.

This problem I'm having extends past Quarkus applications as well. Using Testcontainers directly (say in any other kind of Java application) I can satisfy many external dependencies that my application might need when running its tests (again, inner-loop development).

In Eclipse Che, this is impossible because there is no container runtime exposed to the workspace. I am not at all able to execute my test suite inside Eclipse Che.

Describe the solution you'd like

Ideally I'd like to just run mvn verify in my source tree (for a Java project) and have things just work. If my code uses Testcontainers, let Testcontainers do its "thing". If Quarkus, let Quarkus do its "thing".

Describe alternatives you've considered

Others have run into similar issues with things like Tekton, where as a step in the pipeline run they need to run mvn verify and have Testcontainers do its thing. They've solved that by using the docker-dind (docker-in-docker) image as a sidecar container and sharing the volume between the sidecar & "main" containers (see this great article that was written by someone who got this working in Tekton).

I tried to apply that same pattern to a CRW workspace using a sidecar image, mounting volumes, etc, but it doesn't work, probably because of privileged access/etc.

WIthout something like this it really is impossible to use Testcontainers to run my test suite or to even run a Quarkus application "locally" (inner-loop) within a CRW workspace.

[ibuziuk]

@l0rd @benoitf adding devex team
AFAIK we have not ever tried the case related to https://www.testcontainers.org/

[edeandrea]

Its VERY common amongst Java developers

[benoitf]

the biggest issue is that it requires privileged mode

[edeandrea]

It can be done, as my link to the article shows for doing it with Tekton. Not having this kind of thing, though, is going to make Che unusable for inner-loop development in the Java ecosystem, especially as we are trying to drive adoption of Quarkus. I'm not able to build workshops/demos using Quarkus on CRW to showcase features which differentiates it from other Java frameworks.

Also, think about when we build workshops for the field to deliver to customers (or as part of organized marketing events) - we heavily rely on CRW because it eliminates the local machine setup headaches. As Quarkus evolves and matures, CRW no longer is something we can use for showcasing how awesome Quarkus is and the developer productivity features it provides for the inner-loop development cycle.

[brootware]

This would be a great feature for writing dockerfiles also in Che.

[edeandrea]

What about running podman instead of docker in a container (testcontainers/testcontainers-java#2088 or containers/podman#7927)?

[l0rd]

@brootware @edeandrea we understand the value of this feature. But allowing arbitrary developers to run a pod with

securityContext:
    privileged: true

as in the Tekton example will fail on real world kubernetes clusters (c.f. https://snyk.io/blog/10-kubernetes-security-context-settings-you-should-understand/). For instance it won't work on Red Hat developer sandbox.

[edeandrea]

Circling back to this thread. If you take a look at quarkusio/quarkus#19132 (comment) you'll notice that this is possible on other platforms as well (i.e. gitpod, GitHub actions, etc). Now I'm not sure how they're accomplishing it, but they are exposing some way where the application can detect a docker daemon running.

This is the ultimate goal here and is something we're struggling to do with Eclipse Che.