Featured image for Ansible

Ansible is described as "simple IT automation." It's an agentless tool, meaning you don't have to install anything on the systems you are controlling. With Ansible, you can install software, configure system settings and features, and do all the things system administrators do. You know, the "operations" side of the team.

So why should you, a developer, care? You should. Let me explain.

What does Ansible do?

To put it in the simplest terms, Ansible lets you do things remotely that you would otherwise do at the command line. Specifically, it's used to install software and change system settings. It puts a machine into the state in which you want it to remain and keeps it there.

For example, you can install (and maintain) a given version of a library on a select group of servers across your organization. You might want Python 3.8 on all your Red Hat Enterprise Linux machines running in AWS. Ansible is perfect for that.

Maybe you want to make sure version 2 of your own software is installed on those servers. Again, Ansible does that.

You can even do nifty things like perform a rolling update across your virtual machines (VMs). Remove some of the servers from the load balancer pool, update to version 3 of your software (using our example), and return the servers to the load balancer pool. Then move on to the next batch of servers, and so on, until all of your servers are running version 3 of your application.

How Ansible can help developers

Ansible is a big deal for developers because you can easily configure and maintain machines with what Ansible calls "playbooks": easy-to-read, declarative statements that you can store in source control. Take a look at this example (copied from the Ansible Getting Started page) and you'll be able to mostly figure out what it does:

---
- name: Install nginx
  hosts: host.name.ip
  become: true

  tasks:
  - name: Add epel-release repo
    yum:
      name: epel-release
      state: present

  - name: Install nginx
    yum:
      name: nginx
      state: present

  - name: Insert Index Page
    template:
      src: index.html
      dest: /usr/share/nginx/html/index.html

  - name: Start NGiNX
    service:
      name: nginx
      state: started

I can think of four reasons why you, as a developer, should care about Ansible:

  1. You can use it to set up small environments.
  2. You can use it to make sure the correct prerequisites are installed.
  3. You can be a catalyst for real DevOps culture at work.
  4. You can use it for yourself.

1: You can use Ansible to set up small environments

Throughout my many years in enterprise software development, my colleagues and I often had the opportunity to carve out small networks of our own. We used these networks to install various packages and software, test different approaches, try new things... in short, play around.

Having Ansible on hand to create environments quickly is fantastic. It's often desirable to set things up, experiment, then tear everything down and start over. Nothing is more frustrating than deploying a solution and having it fail with the "But it runs on our machines" experience, only because an artifact on your machine wasn't included in the installation process. Ansible can solve that by easily enabling you to start from zero every time.

As a developer, I love the idea of completely starting over every time—as long as it is super easy. Thanks, Ansible.

2: You can use Ansible to make sure the correct prerequisites are installed

Sometimes breaking changes to libraries or runtimes (Python, anyone?) can, well, break your application. Because Ansible playbooks are easy to understand and change—it's YAML, after all—you can enforce the correct version of any library, runtime, software, etc. This relieves operations from this burden, which plays perfectly into my next point.

3: You can be a catalyst for real DevOps culture at work

DevOps is a culture and set of behaviors. It's not a spreadsheet or a piece of software you install. It's developers and operations working together to automate all the things. Having Infrastructure as Code is the basis. Allowing developers and operations to change that code, use version control, and trust one another—well, that's about as DevOps-y as you can get. The ability to pull down an Ansible playbook, run it, and test the results any time you want? That's huge. It is programming and system administration as one.

4: You can use Ansible for yourself

What if you were working on your laptop and you wanted to wipe it clean and start over? What if you could wipe it clean, pull a playbook from a network drive (or GitHub or a thumb drive or what-have-you), and use a tool to set up your machine?

With Ansible, you can do this over and over with the same results. You can repave your machine whenever you want without having to remember to run a script at the command line or install this and that.

In fact, as a developer, this might be your best use of Ansible and a great starting point for mastering it.

Ops, I did it again

So there it is. The old "DevOps" word again. We developers need to embrace it because it's not going away. Let's use this DevOps concept to everyone's advantage and promote cross-disciplinary skills, more Infrastructure as Code, and the ultimate goal: more stable systems. Something we all want.

Comments