3 ms·

Never had any issues. We have 100+ build jobs running on Jenkins and most of them have some Testcontainer tests. These never collide if implemented correctly (r

Never had any issues. We have 100+ build jobs running on Jenkins and most of them have some Testcontainer tests. These never collide if implemented correctly (randomised ports with check for e.g.) even when run in parallel. On my machine running several docker dev environments it was also never an issue. Can you specify what issues you had? Also I am pretty sure the library does not work as you describe. Isn't it using the Docker Engine API? I could be mistaken, never checked the source code. Edit: Just checked the documentation. According to the docs it is using the Docker API.

btreecat 3y ago
> We have 100+ build jobs running on Jenkins and most of them have some Testcontainer tests. That's probably why you can and do use it, Jenkins. Jenkins let's you install w/e on the hosts where as more modern systems default context is a docker container or at least speak it natively. > Can you specify what issues you had? Some of my devs have coded tests containers into their ITs. These are the only pipelines we can't containerize, because test containers don't seem to work inside docker, and won't work in k8s either.
- razemio 3y ago
  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.

btreecat 3y ago

> We have 100+ build jobs running on Jenkins and most of them have some Testcontainer tests. That's probably why you can and do use it, Jenkins. Jenkins let's you install w/e on the hosts where as more modern systems default context is a docker container or at least speak it natively. > Can you specify what issues you had? Some of my devs have coded tests containers into their ITs. These are the only pipelines we can't containerize, because test containers don't seem to work inside docker, and won't work in k8s either.

razemio 3y ago
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.