Only Oteemo transforms business through acceleration, enablement, and adoption
Oteemo uniquely transforms teams and processes too
Why we’re different
Get to know us
Work with us
Automation, Infrastructure Automation
by Arka Chaudhuri | Jul 29, 2016
The journey to finding Ansible went as followed:
I sat at my desk with my head in my hands.
My task for the day was to uninstall agents of a popular configuration management tool from over a hundred virtual machines located in 17 data centers around the world — quickly, without stopping any other applications. I tried to figure out the easiest, most efficient way to automate this, my evening plans dissolving into a mist of frustration.
There was more bad news. These VMs were provisioned by many different admins over a long time, and many of the agents had stopped communicating with the central configuration management server. I had no idea where in each VM the agent was installed, or if it was installed with Rubygems or yum or rpm. The only access I had to the VMs was through ssh, with a single master private key that would let me in.
I began writing the shell script. Try yum remove first. If that doesn’t work try rpm -qa. If that doesn’t work, locate the agent and delete the file and folder. Oh, and don’t forget to remove the agent user while you’re at it. But wait, what if they installed it with Rubygems?
I felt like throwing up.
That is when I met Ansible. Here was a YAML-driven automation tool that used pure SSH and no agents! I dove in feet first.
Now Ansible had a different way of doing things. Instead of issuing commands, you describe what end result you want to see, and Ansible will…
So, instead of saying yum update , you would say yum: pkg=* state=latest. You describe the desired state of the target environment, and Ansible does all it can to bring it up to the desired state by using its modules.
That’s not how it began for me though.
To my shell-script addled brain, configuring a server needed a set of commands. Whether you type them in, or run them in a bash script, they were still a sequence of directions the OS had to follow. If the script is accidentally run twice on the same host, and you haven’t checked for that one last edge case, Murphy’s law could rub your face into the dirt.
In my rush to Ansibilize my half-complete shell script, I began writing my first playbook like this (we’ll call our agent agent-daemon here forward):
- hosts: all
- name: If yum found it, get rid of it with yum
shell: yum -y remove agent-daemon
- name: Do the rpm thang
shell: rpm -qa agent-daemon
…and so on.
After a few more lines of this I realized something: I was writing a shell script with Ansible! I wasn’t taking advantage of its modules, or even letting it do its most important job.
Besides running agentlessly through SSH, Ansible’s biggest benefit is something called idempotence. It makes only those changes to the environment that are necessary to bring the environment to compliance with the description in the playbook. So we can boil the first two tasks down to this:
yum: pkg=agent-daemon state=absent
In the snippet above I’m calling Ansible’s yum module and asking it to make sure that agent-daemon is absent from the system. I let Ansible figure out the commands it needs to run to make that happen. It just works. If agent-daemon doesn’t exist on the server, then Ansible won’t try to uninstall it.
Fortunately for me I landed upon Chris Fidao’s excellent Ansible tutorial at Servers for Hackers. I began thinking in terms of describing the ideal system instead of the commands I’d have to use to make it ideal. The clouds opened up, the angels sang, and my evening was rescued.
Nope. Not yet.
Here’s the sad truth. As a relentless optimizer I refactor till blue in the face, and then optimize some more. In mere moments I began writing my first custom module in Python. My wife called, and I caught myself. What am I doing? Surely someone else has faced this situation before. Then a Google search brought up the ansible module index. Ansible comes with over 450 modules to address nearly every need and environment. My task grew easier as I found and called the right modules in my playbook instead of hacking shell commands. In about an hour the final playbook was ready. In another hour all agents were gone.
From then on, I’ve used Ansible to provision, deploy, orchestrate and secure everything from mission-critical multiprovider infrastructures to cloud-based disposable development environments. It’s easy to grasp, quick to test, and doesn’t need elaborate client setup to run. Ansible plays well with other CM and CI/CD systems too. If you add Ansible Tower you get a web GUI and a REST API, together with role-based access, centralized credentials, playbook loading from git, and a solid audit trail. Ansible Galaxy allows you to find and use Ansible roles written by others in the community, and even contribute some yourself.
For us sysadmins an automation tool like Ansible can be a game-changer. It can be used to run single ad-hoc commands, or to execute playbooks that define infrastructure as code. With dynamic inventory support from cloud providers like Amazon Web Services, Microsoft Azure and Google Cloud Compute, you can provision entire environments within minutes and tear them down just as easily. With Tower, self-service for developers and testers becomes a reality, where they can safely deploy environments from approved templates as needed. But like every application, Ansible has its own approach to scripting and control. Here are a few things I have learned that may help you leverage the best of this amazing tool.
Using Ansible for Admin Tasks in Mixed Windows and Linux Environment
Contributing to Helm Community Charts: Getting Started
Developing and Testing Ansible Roles: Part 0
As passionate technologists, we love to push the envelope. We act as strategists, practitioners and coaches to enable enterprises to adopt modern technology and accelerate innovation.
We help customers win by meeting their business objectives efficiently and effectively.
Join tens of thousands of your peers and sign-up for our best technology content curated by our experts. We never share or sell your email address!
© 2021 Oteemo Inc. All rights reserved