[Feature]: Enable Helm Charts usage

Module

New Module

Problem

I want to use TestContainers in a CI environment, that run on K8s. I’m using Jenkins, and I have no Docker runtime abilities - hence Testcontainers is unusable.

Solution

I’d like to have a module in testcontainers that will be similar to the testcontainers-docker-compose module, but for Helm Charts. This will make Testcontainers unusable to me, to an awesome library that will help me perform tests. Basic Helm charts support will let me create anything I will need - MongoDb, Kafka, anything, during my tests!

In my opinion, this feature can level up Testcontainers for many people.

Benefit

This will open the door for making Testcontainers an ultimate DevOps library, instead of a specific technology vendor-locked (for Docker) library.

Alternatives

Resolve this super important issue. https://github.com/testcontainers/testcontainers-java/issues/1135

Would you like to help contributing this feature?

Yes

[DRoppelt]

I want to use TestContainers in a CI environment, that run on K8s. I’m using Jenkins, and I have no Docker runtime abilities

I would like to point out that this not not quite as black&white. You can get docker to run in k8s by using a dind-rootless (dind=docker-in-docker) image as the container hosting the necessary daemon for testcontainers`.

see https://github.com/testcontainers/testcontainers-java/issues/1135#issuecomment-901833509 & https://github.com/testcontainers/testcontainers-java/issues/1135#issuecomment-904526644

If you are using the kubernetes plugin in Jenkins, you can setup following podspec:

• 2 containers, one is named jnlp (optional, as jenkins brings its own jnlp container if nothing is set). The other “dind-rootless”
  • the client, the one using the daemon to i.e. start docker containers, is the jnlp container
  • in my env we have custom jnlp containers anyways, so YMMV
• shared emptyDir on /certs, which allows the client to access the certs of the daemon. The daemon creates them on startup
• client: env DOCKER_HOST=tcp://localhost:2376 to change the port due to tls
• client: env DOCKER_TLS_VERIFY=1
• client: DOCKER_CERT_PATH=/certs/client so that it knows where to fetch the certs
• set a flag for elevated priviledges (not sure if it is on pod or container level)

Thats how I got it to run in my Jenkins environment. The started pod has 2 containers, the jnlp is where the CI happens (e.g. it is a jdk17 with some added tools) the second container hosts the docker daemon required for testcontainers. The 2 containers talk with each other via localhost. I can do docker build ..., docker run ... and use testcontainers via maven just like a regular local build. The setup might be condensed down to a simpler config, but a rootless container was necessary in my env. It has some restrictions (https://docs.docker.com/engine/security/rootless/), which, tbh, I do not understand but seem to be irrelevant for CI.

[kiview]

Thanks for raising the feature request @lynch19. However, Testcontainers by design requires a container runtime with a Docker compatible API and is based on multiple assumptions for the container runtime to share specific characteristics with Docker. We don’t see how your feature request fits into the current vision of Testcontainers.

I’m using Jenkins, and I have no Docker runtime abilities - hence Testcontainers is unusable.

Please note that Testcontainers does not require a Docker-compatible runtime to be present on the same host that executes the test. Testcontaners supports configuring a remote host and many users in the community have such setups in specific CI environments.

As a side note, you can use this Testcontainers module to test helm charts itself (running Kubernetes in Docker): https://github.com/dajudge/kindcontainer