Ansible Adventure: Lessons Learned from Practice

On the eve of the start Express course “IaC Ansible” we share with you the translation of the material.


Ansible is a powerful tool IT automation and, like other similar tools, it takes time to master.

I’ve used Ansible to automate the deployment and management of enterprise applications and have learned a number of lessons that I would like to share to help others. After all, this is open source – the principle.

I’ve been doing enterprise software long before Ansible came along, and I remember the days of quarterly deployments when the entire team was on duty to release a release. Deploy was expensive, difficult, inconsistent, and depressing at every stage.

Moving away from this and learning to deploy quickly, regularly and automatically requires both technical and cultural changes. I’ll talk about cultural aspects in another post, but here I would like to highlight some of the Ansible practices I have used.

Standards

Three things are important for automation:

  1. standards

  2. standards and …

  3. oh yes, standards!

It’s pretty easy to write a small playbook to accomplish a specific admin task. But when developing hundreds of playbooks / roles to automatically deploy an entire software stack in different environments, things get pretty tricky. Plus, your playbooks and roles will get more complex if you don’t reuse and standardize roles. You can start learning Ansible with of this tutorial

From day one, standardize playbooks and roles so the team can reuse as much code as possible.

A galaxy far, far away

Ansible GalaxyThe centralized Ansible Role Repository from the community is your friend. You should definitely see if someone else has already solved your problem.

But be careful. The contents of the Galaxy can be used, but should be carefully studied and understood before being placed in your environment. You can quickly and easily ruin your life by using a role that does something unexpected.

Inventory

Ansible can work with machines, using its own inventory engine to search for various systems, or by defining groups by workload or other characteristics. You can also work with dynamic inventory.

For example, we had many XML files containing configuration information for our software. We created Jinja templates and moved the configuration from XML files to Ansible Inventory. XML files have become much easier to generate and deploy to servers. In addition, to work with different environments, we used a specially created Vars Plugin written in Python that loads only the necessary configuration data in the inventory.

Handlers

Handlers are tasks that are triggered on an event. Only by event and only once per playbook. For example, you can set up handlers for an event such as restarting a service or application. Using handlers in a role that manages a specific service can be a great way to create clear and understandable tasks in the handlers / main.yml file that are triggered when the service changes.

When I started working with Ansible, there were no handlers in it yet. So I can tell you what life was like before and after that – don’t let this opportunity go to waste!

Idempotency – understand it, live with it, love it

Idempotency is a way of life for IT automation. You need to understand it and then live by it when writing automation code. So what is it? I will quote Ansible glossary, an operation is “idempotent if the result of a single application of the operation is the same as the result of its repeated application.”

That is, you can run your playbooks multiple times, and the end result will remain the same – the target servers will be in the “desired state”. And if your playbook doesn’t work, then you can fix the problems and start the playbook again. Since the playbook is idempotent, the target servers must be in the “desired state” and no other changes will occur.

What’s in your name?

Please, please always name the problems. This sounds silly and akin to asking for code comment, but it is important to give the tasks clear names so that everyone can understand what it is doing. Follow these simple rules:

  1. Do not write comments in Ansible playbooks like you do in software development, such as “# this is a comment”. Remember, Ansible is not a programming language, it is an automation tool.

  2. Instead, use a meaningful “Name” to describe Play and Task. Describe your intentions, but try to refrain from technical details.

The biggest benefit of the “Name” property is that it is displayed when the playbook starts. This helps with diagnosis. And comments are not displayed.

In my experience, playbooks / roles / tasks are written by different people in the company (at least by the Dev and Ops teams), and everyone should understand what the task is doing.

Variable naming and precedence

Be careful when naming variables in inventories, playbooks, and Ansible roles. Remember that Ansible assigns each variable to a specific Host (Host Variables). Therefore, use common names such as “java_path: / my path” with caution. Chances are, another application on the same host is using Java, but in a different way. Often, a single host can host multiple applications using different versions of Java located in different paths.

Prefix variables using your company name. For example, variables for an AppOne application built by ABC and using Java 1.8 might look like this:

abc_appone_java_path: "/opt/appone/java"

abc_appone_java_version: "1.8"

Don’t copy-paste

Let me be clear. Create reusable roles without copying chunks of code from one playbook to another. This way, the role changes in one place and the dependencies automatically use the latest version. You will not need to look for outdated directives and you will not see unexpected behavior of the playbook a few months later.

Use an IDE

Use some kind of IDE for Ansible. It’s just YAML after all. The IDE should make your job easier. Here are some features that I consider critical to the IDE when creating Ansible roles and playbooks:

  • YAML syntax highlighting and linter support.

  • Python syntax highlighting and linter support – Ansible is written in Python, and trust me, you sometimes have to look at the source code.

  • Integration with version control system.

  • Integration with JIRA – the ability to manage changes in multiple tickets at once.

  • Convenient search and replace – often you will need to change, delete or move a variable in several files at once.

  • Ruby support – if you’re also going to work with Vagrant.

  • Groovy support – if you are going to work with Jenkins jobs.

These tips will help you stay one step ahead and avoid the mistakes I made when using Ansible to deploy and automate enterprise software. You will have your own new and interesting mistakes! For more information on Ansible best practices see best practices section of Ansible documentation and download automation checklistand also follow the Red Hat blogs and Ansible


Learn more about Express course “IaC Ansible”

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *