Spinning up two containers that need to communicate


#1

@rohara Our setup for integration testing requires 2 containers to be spun up while another one is built with Go and then spun up as a container. They must be able to communicate with each other. From what I’ve read here, is this not possible with executorType: docker but rather can only be accomplished through executorType: machine and then installing all required dependencies (Go, NodeJS)?

If that is the case, is there work being done to allow this? I much prefer executorType: docker.


Expose database containers port
#2

Can you provide more information about the two containers? You can’t build containers in executorType: docker, but with more information we might be able to figure out a way to use it.


#3

@Eric Our application is composed of three different docker containers that must be run with certain environment and volume flags with a shared network for communication. Each of these docker containers comes from a different repo. I’m trying to design the circle.yaml in a way that whatever repo is committed to, that is built using the usual Circle method while the other two are ran using docker run so I can run integration testing.

I’ve actually managed to get all three containers up and running on the CircleCI machine using executorType: docker. Additionally, the networking seems to work since I’ve changed the docker run parameters to utilize the Docker gateway rather than eth0.

Unfortunately while I really want to use the executorType: docker due to the increase in speed, it looks like from this discussion I’ll have to switch to executorType: machine. The docker run commands must use volume mounting from the host system to be able to work. Is this possibly something that is being worked on?


#4

Thanks for that additional detail. Your use case makes sense. I’m not aware of any plans to make host volume mounting work from within executorType: docker, but I’m asking around about that.

There’s another team dedicated to workflows, which is intended to give higher-level controls of builds. The idea with that is to eventually allow you to run different parts of your build (i.e. deploys, integration tests, dependency resolution) on different hardware. That project is still in very early stages, though.

In the mean time, this is less than ideal, but you could set up different repos for different chunks of work that you want done with executorType: docker and executorType: machine. For instance, your 3 repos could run non-integration tests with executorType: docker. If that passes, they would use the API to trigger a build of another repo with just a circle.yml configured to pull them all together and run in an executorType: machine.


#5