One of the main advantages of Docker is the isolated environment it brings, and I want to leverage that advantage in my continuous integration workflow.
A "normal" CI workflow goes something like this:
Poll repository for changes
Pull from repository
Install dependencies
Run tests
In a Dockerized workflow, it would be something like this:
Poll repository for changes
Pull from repository
Build docker image
Run docker image as container
Run tests
Kill docker container
My problem is with the "run tests" step: since Docker is an isolated environment, intuitively I would like to treat it as one; this means the preferred method of communication are sockets. However, this only works well in certain situations (a webapp, for example). When testing different kind of services (for example, a background service that only communicated with a database), a different approach would be required.
What is the best way to approach this problem? Is it a problem with my application's design, and should I design it in a more TDD, service-oriented way that always listens on some socket? Or should I just give up on isolation, and do something like this:
Poll repository for changes
Pull from repository
Build docker image
Run docker image as container
Open SSH session into container
Run tests
Kill docker container
SSH'ing into the container seems like an ugly solution to me, since it requires deep knowledge of the contents of the container, and thus break the isolation.
I would love to hear SO's different approaches to this problem.
