We have a robust Ansible suite for deploying many of our servers and we’re running into trouble using Drone because of its use of Docker. Ansible has support for Docker insofar that it can create and manage Docker images. However, this becomes a problem because those are created from Dockerfiles that duplicate what we’re already doing with Ansible.
For example, let’s say we have an application server that we deploy the application to and a build server that runs our CI. With something like Jenkins we can just use the same Ansible role on both to get them ready for the application. With Drone and Docker we need a base image of the server that Drone can start fresh each time the tests run. That means we have both an Ansible role and a Dockerfile that repeat how to create an application server. We could potentially get the Ansible script to create that Dockerfile through docker_image but we’d also have to update the Docker registry and a bunch of overhead to keep both in sync.
The obvious solution is just deploying entirely through Docker. While possible, it will take a lot of time to port everything over to a new architecture. There’s also a very sneaky reference to docker-dna around 18:15 of the video at http://www.ansible.com/docker. Is that the best way to go about this? I’m surprised there’s not more discussion about this, it seems pretty clutch for Ansible users who want to use Docker.
Re. docker-dna and Michael’s blog post - we started doing it like that for the same sort of reasons you mention (being able to share playbooks between provisioning “real” machines and buliding docker images), but then stopped because it didn’t work well with Docker’s image caching stuff. The playbook run ends up being a single layer in the image, so any change to the playbook, however small, meant a full re-build of that layer (and any subsequent ones). If you follow the “classic” Dockerfile usage, the steps in your playbook would be broken out into separate RUN statements, so you end up with finer-grained layers and therefore fewer rebuilt layers. (This is obvious if you know how Docker works, but it took me a while to figure out as I was learning Docker at the same time.)
That being said, I really did like having the ability to share playbooks. And using Ansible (or Chef or whatever) to build a docker image makes perfect sense - much less clunky than the current Dockerfile way. So if the above isn’t an issue for you then I would probably still go with it. My real hope is that the Docker people somehow make it easier to use Ansible etc. to build images, using image caching etc.
I don’t have a direct answer for your question, but maybe more of a question for you.
We use both ansible and Drone, however we don’t perform any server configuration on large scale on our Drone images. In fact we just use the stock Python 2.7 Drone image. This may be philosophical, but in my opinion, when you are testing your app in CI, you probably shouldn’t also be testing your infrastructure configuration. Our .drone.yml may install a few OS packages that are dependency of python modules, but it is generally only 1-3 packages that we install using a simple apt-get statement.
I don’t know what language you are using, but with our python apps we pretty much mock out every interaction that would either happen with local or remote systems, so that we are only testing our app. This largely means that the server configuration has no bearing or impact on our testing. All responses that come from modules and such that interact with the system come from mocked response fixtures. I guess this might not be possible based on the language and the testing functionality, but I am curious as to whether your testing strategy isn’t a proper fit.
So is it possible that your testing strategy might need to be re-thought?
Just throwing this out there in case it may help. If not, feel free to ignore. I see a few other people have responded a little more directly to your specific question.