We are using docker compose to run our product locally (on dev machines) as multi-container stack. In order not to mess with port numbers, we create number of alias addresses ( on mac os x : ifconfig lo0 alias netmask 255.255.255.255 ) and than effectively bind each container to distinct IP address (alias). I wonder if something similar possible “inside” CircleCI… it looks like version 2.0 is very docker compose friendly… it would be amazing if we could run our existing docker compose setup inside CircleCI (so we can use it to do end-to-end testing)
I don’t understand your networking problem, but you don’t have to use the CircleCI container system - you can load Docker Compose and then use it how you would locally.
I do this in order to be able to run integration tests in a microservices environment in exactly the same way as I do locally.
It is very possible that I am thinking in a wrong way about this problem… what I want is to be able to do is to use CicrcleCI to build all artifacts required by our product, than start our docker-compose stack using these newly build artifacts and run some of end-to-end tests. In current form, our stack consists of 5 docker instances running number of REST APIs (using Tomcat), 1 docker instance running custom game server and few more docker instances running 2 MySQL DBs, Mongo and CMS… in “real life” most of these services exposed on port 8080… when we run our docker compose stack on local machines, we use bunch of alias addresses so we can keep using port 8080 without conflicts (each docker instance effectively gets own alias address). It is my understanding that I can run docker-compose stack in Circle (as of v 3.0)… but it is also my understanding that in the end all exposed ports end up been bind to the same interface… so I can not have more than one docker image exposing port 8080.
That’s correct for the way CircleCI merges CircleCI-level containers’ networking together. Anything listening on localhost in a primary build container or localhost in secondary containers are merged together on the same primary localhost. So, yes, one has to watch out for port clashes in this case.
However, that is not what happens for a real Docker Compose - each service/container gets its own IP. So, as I suggested, try installing Docker Compose in your primary build container, don’t use any secondary containers, and instead run all your images in a DC that you set up yourself.
If you mean Docker images, then yes, build them separately, push them to a registry, and then pull them in your DC build.
).