Ability to run "docker in docker"

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.

[l0rd]

@edeandrea not when we tested ~1 year ago. But it looks like things have changed and we need to have a look again (c.f. this issue and related OpenShift enhancement proposal.

[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.