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.
