Ansible

No matter your role, or what your automation goals are, Ansible can help you demonstrate value, connect teams, and deliver efficiencies for your organization. Built on open source, Red Hat® Ansible® Automation Platform is a hardened, tested subscription product that offers full life cycle support for organizations. Explore how Ansible can help you automate today—and scale for the future.

I will explain what Ansible is and show different real life scenarios where it can be used to make ID processes efficient.

We’re going to look at Ansible components like Playbooks and why it’s a good idea to use Ansible with Docker. 

And at the end we will compare Ansible with its alternative tools like Puppet and Chef.

So what is Ansible?

It’s a tool that helps you automate different It tasks.

So now the question is what are examples of such It tasks and why is it important or better to do them automatically rather than manually? 

So let’s go through these example tasks one by one:

When you have a complex It infrastructure with tens of servers, some It tasks can be time consuming and tedious to do manually.

For example, imagine a scenario where you have ten servers where your distributed application is running. 

Now, let’s say you release new application version and you need to deploy that on all those servers.

Or another scenario where you want to update Docker version on all those ten servers.

Sometimes such upgrades might involve multiple steps like restarting some processes, reconfiguring the environment, et cetera. 

Or yet another example of repetitive tasks that system administrators perform and often take hours to do manually, such as updates, backups, weekly system reboots creating users, assigning groups and permissions to these users, et cetera. 

In all these scenarios, manual approach will be that you SSH into the first server, do the necessary configuration there, then SSH into the next server, do the same there and so on for all ten servers. And every time this configuration or upgrade or deployment needs to happen again, you need to start from scratch and go through that whole process again. And especially if it involved multiple steps, you’ll have to remember exactly what you did the last time. 

One approach that I’ve personally seen in my projects was that people would just write notes and document in Confluence pages all the things they configured or changed on the servers to deploy an application or steps of how they installed a certain software so that they can remember it when they need to do it again on the same server or on other environments. 

So now Ansible comes in to make all these different scenarios much more efficient and less time consuming in four different ways:

So one you can execute all these tasks like updates and deployments, et cetera on all the servers from your own machine remotely instead of going into each server one by 1

Second: You can do it by writing all the steps of configuring, installing, deploying, et cetera in a single YAML file instead of doing it with manual steps or combination of shell scripts and manual steps.

Three: you can reuse the same file to execute the same task sequence multiple times if needed on the same server when you’re doing re upgrade, for example, or on different environments, like when you’re trying to create the identical environment on dev, staging and prod environments. 

Number four, also a big plus, since humans are prone to make mistakes or forget stuff, especially when it comes to executing complex sequence of It tasks, automating it with tools like Ansible makes it more reliable and less likely that errors will happen when configuring servers or deploying applications. 

And right now the state of Ansible is that whatever It or system administration tasks you can imagine, starting from OS level updates to cloud provisioning, you can do all of them with Ansible because it really has expanded so much that it supports all operating systems, a lot of different cloud providers works with virtual cloud servers as well as bare metal infrastructure.

And only thing you have to do in order to execute these Ansible files on the target servers from your own control machine is simple SSH access to the target servers. 

And that’s one of the unique advantages of Ansible compared to its alternative tools, that is agent-less.

So what does it mean?

Normally, when you want to use some tool on a machine, you need to go to the machine and install an agent for that tool to use Ansible, however, you don’t have to install any thing on the target servers. You just install it on one machine, which is your control machine, could be even your laptop. And that machine can now manage a whole fleet of target machines remotely. 

So this means, ONE: you don’t have any deployment effort on the beginning

And second you don’t have any upgrade effort either when moving to a new Ansible version

So far we covered What is Ansible? And When Ansible it’s used?

Now let’s see How Ansible Works on a Multiple Server Environment to carry all of these tasks:

Ansible works with Modules, and Modules are actually small programs that do the work. They get sent from the control machine to the target servers, so they get pushed out there, they do their job on the target server like installing an application, stop a process, apply firewall rules, and so on, and when they are done, they get removed.

And it’s important to know here that Modules are very granular, one Module does one small specific task, so, you have a Module to Create or Copy a file, a Module to install Nginx Server, or Modules to Start Ngnix Server, or to start a Docker Container with some arguments, or create a Cloud intance, so all this are specific tasks that represent a Module

And Ansible has hundreds of Modules that each executes specific tasks.

As I mention before, with Ansible you can execute any IT task because of all these Modules.

So it has Modules for many different Cloud tools like AWS or Google Cloud, it has Modules to work with Docker or many different Databases, Network and Security tools. So if you want to execute an IT task there’s probably a Module to do so.

Ansible has an official list of Modules and tasks that you can check right here   

Another important distinction of Ansible and big reason of why it became so popular is that Ansible uses simple  YAML language with means it doesn’t require learning any special language because it is super intuitive, so, let’s see some examples of Modules uses in YAML:

So this is an example of a Jenkins Module (jenkins_job)

# Create a Jenkins job using basic authentication

 

– jenkins_job:

  config: “{{ lookup(‘file’, ‘templates/test.xml’) }}”

  name: test

  password: admin

  url: http://localhost:8080

  user: admin

 

# Delete a Jenkins job using the token

 

– jenkins_job:

  name: test

  token: asdfsfdsafdsasfdsa

  state: absent

  url: http://localhost:8080

  user: admin

 

This example is just creating a job or deleting a job using different arguments

Or the following Docker module:

– name: Create a data container

  docker_container:

    name: mydata

    image: busybox

    volumes:

    – /data

– name: Start a container with a command

  docker_container:

    name: sleepy

    image: ubuntu:14.04

    command: [“sleep”, “infinity”]

 

– name: Add container to networks

  docker_container:

    name: sleepy

    networks:

    – name: TestingNet

      ipv4_address: 172.1.1.18

      links:

      – sleeper

    – name: TestingNet2

      ipv4_address: 172.1.10.20

      links:

      – mydata

 

This 3 examples of Docker Modules show how Modules can be used to Create, Start or Apply configuration to containers.

And also examples in Postgres that show how it can be use to make a lot of DB tasks like Create a table, set privileges, etc.

– name: Rename table too to bar

  postgresql_table:

    table: foo

    rename: bar

 

– name: Set owner to someuser

  postgresql_table:

    name: foo

    owner: someuser

 

– name: Truncate table foo

  postgresql_table:

    name: foo

    truncate: yes

 

Like I said, Modules are very granular and very specific, so obviously when deploying modules to create various applications and stoping and starting several processes, you will need multiple Modules in a certain sequence, group together to represent one whole configuration or all the steps to deploy the application.

And that’s where Ansible Playbooks come in:

 

– hosts: all

  become: true

  vars:

    http_port: 80

    max_clients: 200

 

  tasks:

  – name: Ensure apache is at the latest version

    yum:

      name: httpd

      state: latest

 

  – name: Start and enable the httpd service

    service:

      name: httpd

      state: started

      enabled: true

 

  – name: Copy the apache configuration file

    template:

      src: httpd.conf.j2

      dest: /etc/httpd/conf/httpd.conf

 

  – name: Ensure the httpd service is running

    service:

      name: httpd

      state: restarted

 

Here we can see how different modules are grouped in TASKS

Where 1 Task equals an action to be performed, each task makes sure that each module gets executed with certain arguments and also describes the task using the “ name: “

So here we have an example where we tell Ansible to  Ensure apache is at the latest version first, then we tell Ansible to Start and enable the httpd service

And once that it’s done we also ask to perform a copy of configurations giving the source and the destination and then we ask Ansible to Ensure the httpd service is running giving it the name of the service and making sure is running by giving the service the state of restarted (just in case the service was down, or running)

 

You could tell by the example before how different Modules can be used in this case the yum: module, that installs apache and the service: module that starts that httpd service or the template: module that copies the configuration file.

And that will be ONE configuration file grouped together.

Also, at the beginning of the file we can read this:

– hosts: all

  become: true

  vars:

    http_port: 80

    max_clients: 200

 

This is telling Ansible WHERE to run this configuration file. YAML is pretty self explanatory, you can tell by just reading the code that it’s getting executed on all our hosts on port 80 and with a limit of 200 clients.

You can add different variations to this such as Users and Hosts environments as follow

– hosts: databases

  remote_user: root

  become: true

  vars:

    http_port: 80

    max_clients: 200

 

Such as Python and other programing languages in YAML and Ansible you can use variables when certain parameters are repeated through the code

– hosts: databases

  remote_user: root

  vars:

    tablename: foo

    tableowner: someuser

 

  tasks:

   – name: Rename table {{ tablename }} to bar

     postgresql_table:

       table: {{ tablename }}

       rename: bar

 

   – name: Set owner to someuser

     postgresql_table:

       name: {{ tablename }}

       owner: someuser

 

   – name: Truncate table {{ tablename }}

     postgresql_table:

       name: {{ tablename }}

       truncate: yes

 

So, on this file where we set parameters for hosts, users, and tasks, we call this a Play. And on a single file can be a lot of different Plays and this it’s what is called a Playbook, where one or more Play are executed in order.

So a Playbook basically describes HOW and in WHICH order and at what TIME and WHERE (on which machines) and WHAT (the Modules) should be executed. We could say, it orchestrates the Module execution.

That covers the basics of Ansible and why it can be so useful when dealing with multiple servers.