As I have written in a previous blog, the DevOps Platform (aka ADOP) is an integration of open source tools that is designed to provide the tooling capability required for Continuous Delivery. Through the concept of cartridges (plug-ins),ADOP also makes it very easy to re-use automation.
In this blog I will describe an ADOP cartridge that I created as an easy way to experiment with Ansible. Of course there are many other ways of experimenting with Ansible, such as using vagrant. I chose to create an ADOP cartridge because ADOP is so easy to provision and predictable. If you have an ADOP instance running you will be able to experience Ansible doing various interesting things in under 15 minutes.
To try this for yourself:
To anyone only loosely familiar with ADOP, Docker and Ansible, I recognize that this blog could be hard to follow so here is a quick diagram of what is going on.
The Jenkins jobs in the cartridge
The jobs do the following things:
As the name suggests, this job just demonstrates how to install Ansible on Centos. It installs Ansible in a Docker container to keep things simple and easy to clean up. Having built a Docker image with Ansible installed, it tests the image just by running inside the container.
$ ansible --version
This job is a lot more interesting than the previous. As the name suggests, the job is designed to run some adhoc Ansible commands (which is one of the first things you’ll do when learning Ansible).
Since the purpose of Ansible is infrastructure automation, we first need to set up an environment to run commands against. My idea was to set up an environment of Docker containers pretending to be servers. In real life, I don’t think we would ever want Ansible configuring running Docker containers (we normally want Docker containers to be immutable and certainly don’t want them to have ssh access enabled). However, I felt it was a quick way to get started and create something repeatable and disposable.
The environment created resembles the diagram above. As you can see, we create two Docker containers (acting as servers) calling themselves web-node and one calling its self db-node. The images already contain a public key (the same one vagrant uses actually) so that they can be ssh’d to (once again not good practice with Docker containers, but needed so that we can treat them like servers and use Ansible). We then use an image which we refer to as the Ansible Control Container. We create this image by installing Ansible installation and adding an Ansible hosts file that tells Ansible how to connect to the db and web “nodes” using the same key mentioned above.
With the environment in place the job runs the following ad hoc Ansible commands:
By running the job and reading the console output, you can see Ansible in action and then update the job to learn more.
This job is identical to the job above in terms of setting up an environment to run Ansible. However, instead of having the hard-coded ad hoc Ansible commands listed above, it allows you to enter your own commands when running the job. By default it pings all nodes:
ansible all -m ping
This job is identical to the job above in terms of setting up an environment to run Ansible. However instead of passing in an ad hoc Ansible command, it lets you pass in an Ansible playbook to also run against the nodes. By default, the playbook that gets run installs Apache on the web nodes and PostgreSQL on the db node. Of course you can change this to run any playbook you like so long as it is set to run on a host expression that matches: web-node-1, web-node-2, and/or db-node (or “all”).
How the jobs 2-4 work
To understand exactly how jobs 2-4 work, the code is reasonably well commented and should be fairly readable. However, at a high-level, the following steps are run:
I hope this has been a useful read and has clarified a few things about Ansible, ADOP and Docker. If you find this useful please star the GitHub repo and or share a pull request!