January 11, 2017
Using ADOP and Docker to learn Ansible
By: Mark Rendell

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:

  1. Spin up an ADOP instance.
  2. Load the Ansible 101 Cartridge (instructions).
  3. Run the jobs one-by-one and in each case read the console output.
  4. Re-run the jobs with different input parameters.

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:

  1. Ping all web nodes using the Ansible ping module: ansible web -m ping
  2. Gather facts about the db node using the Ansible setup module: ansible db -m setup
  3. Add a user to all web servers using the Ansible user module:  ansible web -b -m user -a “name=johnd comment=”John Doe” uid=1040″

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:

  1. Create the Ansible inventory (hosts) file that our Ansible Control Container will need so that it can connect (ssh) to our db and web “nodes” to control them.
  2. Build the Docker image for our Ansible Control Container (install Ansible like the first Jenkins job, and then add the inventory file).
  3. Create a Docker network for our pretend server containers and our Ansible Control Container to all run on.
  4. Create a Docker-compose file for our pretend servers environment.
  5. Use Docker-compose to create our pretend servers environment.
  6. Run the Ansible Control Container mounting in the Jenkins workspace if we want to run a local playbook file or if not just running the ad hoc Ansible command.


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!

Bonus: here is an ADOP Platform Extension for Ansible Tower.

Popular Tags

    More blogs on this topic


        Topics highlighted


        COMMENTS (0)




        Your Data Privacy

        By providing your e-mail address, you agree to the terms
        outlined in our privacy statement associated with
        commenting on the site. Your e-mail address will not be
        used for promotional marketing purposes.

        Retype the CAPTCHA code from the image
        Change the CAPTCHA codeSpeak the CAPTCHA code