A developer's shortcut to getting started with Ansible

You’re a developer and you want to learn Ansible. You’re feeling anxious because everyone is talking about it, but you barely know how to list a directory in Linux! Don’t worry, because I am here to show you how to use your developer skills to learn Ansible and create some DevOps magic with a little help from Ansible Galaxy.

You’ve learned all the basics of Ansible, but say to yourself: what are the patterns? How do I use Ansible on a regular basis? How can I handle common tasks? I’m a newbie to Linux, where do I start…?

Quoting from the official Ansible Galaxy documentation:

Reusable. That’s the word IT people always (or should) care about. Roles in Ansible are a great way to reuse tasks that you always have to do when provisioning environments. I won’t go into “how to create a role” in this article, but if you’re interested, please take a look at the official docs for any questions you may have.

Instead, I’d like to bring your attention to Ansible Galaxy and how you can both reuse the community's work and contribute to it, while learning something great. Think of Galaxy as the GitHub for Ansible roles. There, you’ll find a wide variety of existing roles you can use to orchestrate your playbooks to do anything you need.

Ansible Galaxy can help you:

1. learn by example looking at the code other people have written and;

2. develop great playbooks by orchestrating roles that have been created by the community.

As an example, let’s take a look at a project I’m working on. Here, we are provisioning an environment to set up an ALM process. For that, I need to provision three servers: Jenkins for CI/CD, SonarSource for quality analysis and Nexus as an artifact repository.

Manually provisioning all three servers would require a lot of generic work that may take a lot of time and would not be easily repeatable in the future.  We don’t have that time, right? Take a deep breath, grab a cup of coffee and come learn with me.

Define what you need to do

First things first, map out everything you need to provision: a CentOS machine? NodeJs? Java? PHP? What else? What are the application’s requirements? Try to be as detailed as you can. Take your time to plan, you will save time in the end.

For this project, I need the aforementioned three servers: Jenkins, SonarSource and Nexus. At the same time, we need everything those services rely on: database server, JVM, web server, etc. All of these I know Ansible can provision for me.

Prepare your environment

Start by installing Ansible. After that, make sure Ansible Galaxy is on your path:

$ ansible-galaxy --version

You should see output like this:

ansible-galaxy 2.3.1.0
config file = /etc/ansible/ansible.cfg
configured module search path = Default w/o overrides
python version = 2.7.13 (default, Jun 26 2017, 10:20:05) [GCC 7.1.1 20170622 (Red Hat 7.1.1-3)]

Now configure your ANSIBLE_ROLES_PATH. This path is where Ansible Galaxy will save every role you install and where Ansible will look when resolving the imports from your playbook. The default path is /etc/ansible/roles. Make sure that the user installing the roles has write permissions on the directory. If you’re running on your own machine, make it yours:

$ sudo chown -R myuser:myuser /etc/ansible/roles

Then you should work on a virtual machine environment. For that, you could use Vagrant on top of libvirt.

And that’s it! You should have your environment set. For more detailed information about Ansible Galaxy installation and configuration, please check the docs.

Looking for roles that you need

Now that you have a plan and Ansible Galaxy configured in your environment, let’s search for the roles that we need to compose our playbook. This will allow us to provision all the three servers at once in a repeatable and reproducible way.

Remember, all you need to do is bring the required roles from the Galaxy repository and run them in an orchestrated fashion to accomplish what you need.

There are three ways to search for roles:

1 - Ansible Galaxy command line

$ ansible-galaxy search *jenkins*

You’ll see a list of roles filtered on the name you provide as an argument. It’s a simple and straightforward way to look for a role, but this is not my preferable method. The reason is that this list only provides the name and a short description for the role. It may be enough if what you are looking for isn’t popular, but like the example above, Jenkins will return a lot of options. How do you decide which to choose?

2 - Ansible Galaxy Web UI Search.

Go to the Ansible Galaxy website and start exploring or browsing for a role. Let’s use the same example as above and search for Jenkins. Click on "Browse Roles" and type "Jenkins" as the keyword (or just click here). You’ll see a nice interface and a sort function drop-down next to the keyword box. By selecting “Stargazers”, you can filter the most relevant and upvoted roles by the community. Most of the time it’s best to take the one with most stars or the one from the official vendor. For this example, the chosen role will be the Jeff Geerling one.

3 - Google it.

The mindset here is the same as #2, but now you may hit the GitHub repository instead of the Ansible Galaxy page. Note: it’s almost the same thing. Every Ansible Galaxy project is backed by a GitHub project. So, guess what? It’s open and you may contribute to them.

Now that we have our role(s) we can move forward and start using them.

Read the docs, explore their code

To get started read all available documentation provided by the project and pay close attention to the available extension points. Extension points are variables you can set to get the role to do what you need. A good example of this is Jeff Geerling’s Java role.

In this role, you can set the Java version you want to be installed by setting the java_packages variable.

Go ahead and install the role in your machine:

$ ansible-galaxy install geerlingguy.jenkins

You have to have an internet connection so Ansible can connect to the repository and download the role plus all the dependencies it needs. After the installation process, check that the role is installed on your system:

$ ansible-galaxy list

You should see the Jenkins role, including the version, and all the other dependencies it needs. Ansible Galaxy works like many others package managers: it makes things easy by downloading all other required dependencies. Remember the Ansible Role path we set in step #2? If you list the directory and you will see all of the available roles on your system.

If you want to understand what the role really does, start by exploring $ANSIBLE_ROLES_PATH/roles/geerlingguy.jenkins/tasks/main.yml.

The ‘tasks/main.yml’ is the typical starting point of a role and allows you to see what’s going on. Try to understand their code and figure out how the steps fit together. It’s a very nice exercise to learn by example and to absorb concepts which are difficult to convey in books or manuals.

Once you are comfortable with their code, explore the other dependencies so you understand how the pieces work together to make the role awesome.

Test it

It’s time to enter the arena and put some bytes to work for you. First, you have to create a project, so start small. In a new directory, create a tree like this one:

├── project.yml
├── group_vars
│   ├── all.yml
├── inventory.ini
├── meta
│   └── main.yml
├── requirements.yml

Let’s describe each file:

1 - project.yml: this will be the starting point of your project, you can rename it as you please. To start using the role we just installed, open the file and add:

- name: Deploy Jenkins CI
 hosts: jenkins_server
 remote_user: the_user
 become: yes

 roles:
   - geerlingguy.jenkins

Here, we are creating a task to just run the role. You give it a name, define a host and set the user which will run the process on the target machine. Please note that it is beyond the scope of this post to create a container or a virtual machine where the Ansible will run. I suggest Vagrant to do so.

2 - inventory.ini is the file to list the machines Ansible will provision. Read more about it here. Remember, the host property described in #1 should match the host created on this file:

[jenkins_server]
192.168.0.32

3 - group_vars/all.yml. Remember the "role’s extension points" I mentioned earlier? This file contains all the variables we need to configure the role to do what we want. Let’s define the java package you wish to install for Jenkins:

java_packages:
 - java-1.8.0-openjdk

For reference, this variable is mentioned in the geerlingguy.java role that is a dependency for geerlingguy.jenkins. Isn’t it cool how roles can stick together to do great things?

4 - meta/main.yml. In this file, we are going to list all the dependencies we need from the roles:

dependencies:
 - geerlingguy.jenkins

That way we can tell Ansible we need this role to perform our tasks.

5 - requirements.yml. Despite the name, this isn’t a required file for your project, but it’s very handy because we can list all the Ansible Galaxy roles that we need and download them with just one command line:

$ ansible-galaxy -r requirements.xml

Go ahead and start to provision. Your Jenkins server should be provisioned in your environment and you can start making CI/CD jobs.

The Bottom Line

Now it’s time to shine. Gather every role you are going to use on your project and start chaining them together for awesomeness. In a short time you’ll be creating your own roles, contributing to existing ones and creating your own reusable playbooks. Just to help you out, take a look at this project I created to provision all three servers for an ALM process. There, I orchestrated a simple playbook to create all three machines using three simple tasks: provision Jenkins, SonarSource and Nexus.

See you next time.

Ricardo Zanini is a TAM in the Latin America region. He has expertise in integration, middleware and software engineering. Ricardo has been studying software quality since his first professional years and today helps strategic customers achieve success with Red Hat Middleware products and quality processes. Find more posts by Ricardo Zanini at https://www.redhat.com/en/blog/authors/ricardo-zanini

A Red Hat Technical Account Manager (TAM) is a  specialized product expert who works collaboratively with IT organizations to strategically plan for successful deployments and help realize optimal performance and growth. The TAM is part of Red Hat’s world-class Customer Experience and Engagement organization and provides proactive advice and guidance to help you identify and address potential problems before they occur. Should a problem arise, your TAM will own the issue and engage the best resources to resolve it as quickly as possible with minimal disruption to your business.

Connect with TAMs at a Red Hat Convergence event near you! Red Hat Convergence is a free, invitation-only event offering technical users an opportunity to deepen their Red Hat product knowledge and discover new ways to apply open source technology to meet their business goals. These events travel to cities around the world to provide you with a convenient, local one-day experience to learn and connect with Red Hat experts and industry peers.