testcontainers-java
testcontainers-java copied to clipboard
Feature Request: Remove Docker as a requirement
Request
Testcontainers to not require Docker.
Possible, high-level/conceptual solutions
- Run as a standalone project with no dependency on Docker being installed and it is able to run using some in-built container runtime - such as with containerd.
- Have interoperability with an alternative free & open-source dependency, such as containerd with lima nerdctl.
Context
Docker, Inc. has come out with the Docker Subscription Service Agreement which brings in changes for large organisations (either 250+ employees or earning over $10,000,000 annual revenue) to not be allowed to install Docker without paying for their new subscription service.
This essentially means that those organisations using Testcontainers will HAVE to pay for Docker to be able to continue to use Testcontainers.
Although there is an argument that those organisations should just pay up, if they can afford to pay 250+ people, or earn over $10,000,000 annually - I personally believe that libraries and frameworks such as Testcontainers should aim to be free and open-source to all and not be coupled to a proprietary & paid-for service.
Plus there is the added benefit of adding this functionality, which is that it would extend the versatility of the Testcontainers library.
I'm not aware of the level of technical coupling there is between Testcontainers and Docker, so I realise this could be a HUGE request, but I figured I'd submit it, since I couldn't find another GitHub issue with the request.
Hi! FYI Docker itself isn't going to be affected by the license change, you can proceed running your tests without Docker Desktop by using alternative approaches. We even did a quick research of the available options: https://www.atomicjar.com/2021/10/docker-on-windows-and-macos/
Ahhaaaa, cool find!
Though looking at the blog, since Docker Machine is deprecated, the only real stable and future-proof alternative is Minikube - which, as the blog indicates, is a greater barrier of entry into the Testcontainers library.
Would having Docker not as a requirement still be a possible feature for Testcontainers, or is there an intention to keep Testcontainers tied to Docker?
@Harmelodic unfortunately, there isn't anything that can fully replace Docker for what Testcontainers provides. There are indeed other options such as nerdctl, Podman, raw containerd, or even Kubernetes to some extent, and they work fine when one's need is to start a container, but Testcontainers is much more than that, including networking, image management, existing ecosystem of other technologies that rely on Docker API (eg LocalStack).
So there is no "low hanging fruit" option for decoupling Testcontainers from Docker API, especially if we want to keep Testcontainers as powerful as it is right now, and we are constantly evaluating alternatives and work with them (e.g. we are in contact with Podman's team to help them improve their Docker API layer, so that Podman can be used as a drop-in replacement to power Testcontainers-based tests)
Coooooool! 👌
Feel free to close this Issue then, if you deem it appropriate - or keep it open if you want to keep track of that Podman work as a Docker alternative.
You are able to run Lima using docker-engine in the QEMU VM, see here:
- https://github.com/lima-vm/lima/tree/master/examples
- https://github.com/lima-vm/lima/blob/master/examples/docker.yaml
You can then install docker, docker-compose, and the docker-credential-helpers in the hots OS.
We run testcontainers in our ci pipeline on kubernetes and kubernetes deprecated the dockershim support a while ago and encourage the use of alternative container runtimes such as containerd. This doesn't mean we can not use docker in kubernetes anymore, however it is not the default/standard anymore and requires extra effort to configure docker as the runtime. In the future it will be less and less comon to find docker in production environments and therefore makes it harder to use testcontainers in such environments.
Our organisation wants to remove support of "docker in docker" during the CI-CD pipeline, mostly for security reasons.
Are there plans or workarounds to run testcontainer tests without access to docker?
@lukaspestalozzi see https://www.testcontainers.cloud
I'd like to use TestContainers for my project to make Testing easier, however, they don't allow being relied on Docker. So I +1 to this request. By the way, I appreciate highly if you guys have recommendations for me with Integration Tests as using Testcontainers
+1 to this request since we are on beyond Kubernetes 1.24, we can't use docker as part of our CI integrations.
+1 to this request since we are on beyond Kubernetes 1.24, we can't use docker as part of our CI integrations.
Kubernetes 1.24 is a killer
+1 to this request because Rancher Desktop comes with containerd as the default engine (dockerd (moby) is there but is optional).
It would therefore be great if testcontainers had first-class support for containerd
I opened this issue and no longer use Docker Desktop, but instead switched to Podman. I wrote a little guide for anyone looking to do the same: https://harmelodic.com/blog/moving-from-docker-to-podman
Podman not "first-class" support in the same way, but Testcontainers seem to have updated their language in their General Container runtime requirements documentation to be:
To run Testcontainers-based tests, you need a Docker-API compatible container runtime, such as using Testcontainers Cloud or installing Docker locally.
They also include some documentation there on configuring other container runtimes, such as: Colima, Podman and Rancher Desktop.
Given all this, personally I feel my issue of "not requiring Docker" has been fulfilled, and the other container runtimes are supported enough for me. So, I'm closing this issue.
If you want "first-class" support where it Testcontainers "just works" automatically with a container runtime of your choice (no setup needed), then I suggest you open a separate GitHub issue to request for that. Though I suspect that won't be successful given Testcontainers is pushing their own Testcontainers Cloud and Testcontainer Desktop solution.