Ansible for DevOps: Simple IT Automation

Many developers and system administrators manage servers by logging into them via SSH, making changes, and logging off. Some of these changes would be documented, some would not. If an admin needed to make the same change to many servers (for example, changing one value in a config file), the admin would manually log into each server and repeatedly make this change. If there were only one or two changes in the course of a server’s lifetime, and if the server were extremely simple (running only one process, with one configuration, and a very simple firewall), and if every change were thoroughly documented, this process wouldn’t be a problem.

Get hands-on experience on Ansible at DevOps Online Training

But for almost every company in existence, servers are more complex — most run tens, sometimes hundreds of different applications. Most servers have complicated firewalls and dozens of tweaked configuration files. And even with change documentation, the manual process usually results in some servers or some steps being forgotten. If the admins at these companies wanted to set up a new server exactly like one that is currently running, they would need to spend a good deal of time going through all of the installed packages, documenting configurations, versions, and settings; and they would spend a lot of unnecessary time manually reinstalling, updating, and tweaking everything to get the new server to run close to how the old server did. Some admins may use shell scripts to try to reach some level of sanity, but I’ve yet to see a complex shell script that handles all edge cases correctly while synchronizing multiple servers’ configuration and deploying new code.

Configuration management

Lucky for you, there are tools to help you avoid having these snowflake servers — servers that are uniquely configured and impossible to recreate from scratch because they were hand-configured without documentation. Tools like CFEngine²⁵, Puppet²⁶ and Chef²⁷ became very popular in the mid-to-late 2000s

But there’s a reason why many developers and sysadmins stick to shell scripting and command-line configuration: it’s simple and easy-to-use, and they’ve had years of experience using bash and command-line tools. Why throw all that out the window and learn a new configuration language and methodology? Enter Ansible. Ansible was built (and continues to be improved) by developers and sysadmins who know the command line — and want to make a tool that helps them manage their servers exactly the same as they have in the past, but in a repeatable and centrally managed way. Ansible also has other tricks up its sleeve, making it a true Swiss Army knife for people involved in DevOps (not just the operations side).

Get more knowledge on ansible at DevOps Online Training India

One of Ansible’s greatest strengths is its ability to run regular shell commands verbatim, so you can take existing scripts and commands and work on converting them into idempotent playbooks as time allows. For someone (like me) who was comfortable with the command line, but never became proficient in more complicated tools like Puppet or Chef (which both required at least a slight understanding of Ruby and/or a custom language just to get started), Ansible was a breath of fresh air. Ansible works by pushing changes out to all your servers (by default), and requires no extra software to be installed on your servers (thus no extra memory footprint, and no extra daemon to manage), unlike most other configuration management tools.

Ansible Terms:

• Controller Machine: The machine where Ansible is installed, responsible for running the provisioning on the servers you are managing.
• Inventory: An initialization file that contains information about the servers you are managing.
• Playbook: The entry point for Ansible provisioning, where the automation is defined through tasks using YAML format.
• Task: A block that defines a single procedure to be executed, e.g. Install a package.
• Module: A module typically abstracts a system task, like dealing with packages or creating and changing files. Ansible has a multitude of built-in modules, but you can also create custom ones.
• Role: A pre-defined way for organizing playbooks and other files in order to facilitate sharing and reusing portions of provisioning.
• Play: A provisioning executed from start to finish is called a play. In simple words, the execution of a playbook is called a play.
• Facts: Global variables containing information about the system, like network interfaces or operating system.
• Handlers: Used to trigger service status changes, like restarting or stopping a service.

Ansible is a helpful tool that allows you to create groups of machines, describe how these machines should be configured or what actions should be taken on them. Ansible issues all commands from a central location to perform these tasks.

No other client software is installed on the node machines. It uses SSH to connect to the nodes. Ansible only needs to be installed on the control machine (the machine from which you will be running commands) which can even be your laptop. It is a simple solution to a complicated problem.

I am not boasting off when I say that Ansible has filled up all the holes in Configuration Management and IT Orchestration world.