4 ms·

Ah! That is not an issue of testcontainers. In our Jenkins every pipeline it dockerized and uses agents. So it is not running on the host directly. However it i

Ah! That is not an issue of testcontainers. In our Jenkins every pipeline it dockerized and uses agents. So it is not running on the host directly. However it is also not running dind (Docker in Docker). Instead it is important to use dood (docker out of docker), which is best practice anyway. Your CI needs to be configured once and all your problems should go away IF tests have randomised ports or even better also run in docker so that those ports do not need to be exposed on host level. Most of my colleagues however prefer not to use dev containers so randomised ports was the solution for us for now.

SOLAR_FIELDS 3y ago
Just as an example, Gitlab is (was?)kind of infamous about this - everything you do in gitlab for a long time was already in docker, so you by nature of running in gitlab were forced to do everything in DinD mode. They might have changed this in recent times.
- razemio 3y ago
  I think as long as you can expose the docker socket (should also be possible in gitlab) you can use dood. Dind has never worked out for me. Sooner or later there will be issues.
btreecat 3y ago
That's not a solution. This requires you to expose those host docker socket mounted into a guest container, which breaks some security mechanisms by preventing isolation from the host systems. Which also does not work on k8s. It does work in docker compose, but also isn't portable to places where the docker socket isn't available, eg hosted pipelines. Test containers seem to work well if you're not already properly using containers in your pipelines, and are not interested in deployment to k8s.
- razemio 3y ago
  Well for the environment you describe, there is no solution to this problem right? If you want to spawn test containers, you need a privileged container. At least I can not think of anyway to archive this without exposing the docker socket. You have to choose the right tooling for the right job.

SOLAR_FIELDS 3y ago

Just as an example, Gitlab is (was?)kind of infamous about this - everything you do in gitlab for a long time was already in docker, so you by nature of running in gitlab were forced to do everything in DinD mode. They might have changed this in recent times.

razemio 3y ago
I think as long as you can expose the docker socket (should also be possible in gitlab) you can use dood. Dind has never worked out for me. Sooner or later there will be issues.

btreecat 3y ago

That's not a solution. This requires you to expose those host docker socket mounted into a guest container, which breaks some security mechanisms by preventing isolation from the host systems. Which also does not work on k8s. It does work in docker compose, but also isn't portable to places where the docker socket isn't available, eg hosted pipelines. Test containers seem to work well if you're not already properly using containers in your pipelines, and are not interested in deployment to k8s.

razemio 3y ago
Well for the environment you describe, there is no solution to this problem right? If you want to spawn test containers, you need a privileged container. At least I can not think of anyway to archive this without exposing the docker socket. You have to choose the right tooling for the right job.