The 2nd of February is the day Punxsutawney Philis is going to predict winter or early spring in the eyes of many believers. Today, Bill Murray too might find himself in a time loop with the same day going over and over(!). And it’s also when we rendezvous for the next chapter of our Ansible Safari. Very fancy!

So where were we? Yes. We were going ad-hoc! So, let’s talk about the important built-in module called ansible.builtin.copy. Of course, with the proper arguments as the name suggests, this module is going to help us copy files from the control machine to one or many of the target machines.

Copy Modules in Ansible

Let’s first create a temporary text file for getting hands-on. We’ll call it index.html using vim {filename.ext} and populate it with some text. In this case, it’ll be an index.html file with the text “Ansible test file”.

After getting into our target machine, the command for achieving this would look something like this:

ansible rmwebservers -m ansible.builtin.copy -a "src=index.html dest=/var/www/html/index.html" -i inventory --become

which should hopefully lead to this:

Let’s talk about what happened here.

1. First, we must take into account that since we’re copying files here we have to have a source and a destination. The important thing to remember is the way we give values to these arguments, in this case, “src” and “dest”. src contains index.html precisely because we’re executing the command from the same directory that contains the index.html file. On the other hand, dest contains an absolute path to be resolved in the target machine(s), in this case, the machines in the rmwebservers group.

2. Secondly, there’s a lot of beautiful amazing information in the output that we just got. The thing that is going to help us in the future is the “owner” field. Remember this!

Obviously, if I rerun the command I should get something like this:

signifying the idempotent (maintenance of state) nature of configuration tools, in our case, Ansible. An exercise on this would be to make any changes in the text file and rerun the command.

Well, all this has been a sneak attack (a little project). We’ve copied (overridden) the file into the httpd (Tomcat) server’s default webpage location and if you log into any one of EC2 instances, you’ll find this:

Ansible Playbooks

What????? REALLY??? Not a dream. I can stretch a joke only so far. We’ll create a new one in this chapter or the next. Anyway, this is going to be just an overview so calm down.

What are Playbooks?

These are books we play with. Actually, no. Close though. These are books that contain plays. Plays on the other hand contain tasks which we, you and me, want to perform on the remote machines. If the reader has a little bit high level of Docker-compose this is going to be super duper easy. For the rest, we’ll manage with super easy.

So, let’s learn by example.

---

- hosts: rmwebservers
  tasks:
    - name: Install Apache App Server
      yum:
        name: httpd
        state: latest
    - name: Deploy config
      copy: 
        src: file/httpd.conf
        dest: /etc/httpd.conf

- hosts: rmdbservers
  tasks:
    - name: Install PostgreSQL
      yum: 
        name: postgresql
        state: latest

Note: Revise Python lists and dictionaries, it’ll come in handy.

As mentioned, a playbook is a list of plays. You must be aware that a list in YAML is denoted by the (-) symbol.

Let’s dive deeper into this sample playbook:

1. The ( — -) symbol denotes that whatever comes next has to be treated as YAML or a part of YAML.

2. We have a list of two plays (python dictionaries) with corresponding key-value pairs. An easy way to segregate the plays is through hostnames or just by looking at the indentation levels.

For elaboration, we could look at this in this way:

## List and Dictionary representation of the above Playbook

playbook = [
    {
        'hosts': 'rmwebservers',
        'tasks': [
            {
                'name': 'Install Apache App Server',
                'yum': {
                    'name': 'httpd',
                    'state': 'latest'
                }
            },
            {
                'name': 'Deploy config',
                'copy': {
                    'src': 'file/httpd.conf',
                    'dest': '/etc/httpd.conf'
                }
            }
        ]
    },
    {
        'hosts': 'rmdbservers',
        'tasks': [
            {
                'name': 'Install PostgreSQL',
                'yum': {
                    'name': 'postgresql',
                    'state': 'latest'
                }
            }
        ]
    }
]

Here, playbook is a list containing two dictionaries. Each dictionary corresponds to a block in the original YAML data. Each dictionary has a'hosts'key and a'tasks'key. The'tasks'key contains a list of dictionaries representing the tasks specified under each host. Each task dictionary contains keys such as'name'and'yum'where the former describes the name of the task and the latter is containing another dictionary having two key-value pairs, name (of the package) and state (the target state, latest). State as ‘Latest’ means in addition to installation, it will go ahead and update if it is not of the latest available version.

The descriptions of them are as follows:

• hosts: Pretty self-explanatory. Hosts or the remote machines this particular play is going to act on. Defines a particular play.

• tasks: Can contain many fields but in the most basic form, we have to have a name for the task, the module it’s going to make use of and the action it’s going to take with the target states mentioned as arguments.

If you go ahead and execute this right now by googling things, it won’t work. The why behind that is a secret sauce for the next chapter.

What next?

Now that the joke is over (sadly), we’ll dive much deeper into playbooks. Like a deep ocean dive if you will. It’ll be so much playbook this and playbook that. Almost like

You thought I wouldn’t use this legend of a meme TODAY? Think again!

Stay tuned.

Connect with me on Linkedin.

Originally published athttps://medium.comon February 2, 2024.

Do you notice how unplanned trips or getaways in today's monotonous life always turn out to be the best? If you do, you'll love what we'll get into today.

Google defines ad hoc as

made or happening only for a particular purpose or need, not planned before it happens

and rightfully so. We do encounter such situations almost daily and our guy Ansible isn't someone who likes to stay out of action. Hence, we have tons of ad hoc commands to practice, learn, and love hopefully.

It's super important that you refer to the documentation, especially for this lesson, and here's the link for that.

As always, there are some important things to remember before we begin:

1. Ansible uses states to perform actions/tasks. We give Ansible a task along with a target state we wish to achieve on the target machine.

2. Ansible has a lot of extremely helpful built-in modules.

Commands

Installation using Package management

The first command we execute will use the built-in module called ansible.builtin.yum with the proper arguments. You can read more on Yum here. The command would look like:

ansible remotemachine01 -m ansible.builtin.yum -a "name=httpd state=present" -i inventory

The interesting part is that when we execute this, it'll throw an error which would look something like:

We spoke about the "changed" field, right? Here's when it shines. What's happening here is

We have asked ansible to execute a yum install command (internally through python scripts ofcourse) for installing httpd web server on the target machine with the host name remotemachine01, along with (read carefully), the target state of the machine with regards to the change we desire. Here,

change = installation of httpd and

state = present

which means in a plain sense, that we want such a state where httpd is present.

Alright. But what about the error Mr. Layman? Well, there's the amazing "msg" field for saving ourselves from endless troubleshooting. Let's read it. It says "This command has to be run under the root user."

Note: I'm assuming that you're aware of users, sudo, and privilege escalation basics in Linux. If you aren't, I do have some resources for you in the end.

The "ec2-user" user that we are using does have the sudo privilege (is a sudoer) but needs an instruction to exercise that power. This means that we're going to have to modify our ad hoc command a little bit. Like:

ansible remotemachine01 -m ansible.builtin.yum -a "name=httpd state=present" -i inventory --become

where --become serves the purpose of asking the user we're using to log in to the target machine to execute commands using sudo. Let's execute this and hope that it looks like:

Happily so, our "changed" field says true which means that the present state of the target machine (here, remotemachine01) is indeed, changed. The "results" field describes the changes made (here, httpd installation).

Let's try something more interesting. We'll change the host from a single host to a group in our commands and explore more.

ansible rmwebservers -m ansible.builtin.yum -a "name=httpd state=present" -i inventory --become

When we execute this, we'll see:

Now, the already updated (the machine with the changed state) status has the changed field as false while the other one is updated with the desired state. Here, remotemachine02 was not in the same state and hence, it applied the changes. And now let's run this command once again.

If we re-run the command we'll see something like this:

What we see above, is configuration management using target/desired states and is greatly used in the DevOps world.

Note: A fun exercise for you all would be changing the state as absent in the above commands and analyzing the output.

Starting and Enabling installed Services

For starting and enabling (so that it starts at boot time. Read about systemd and symlinks for more on this) a service, we can use another built-in command called ansible.builtin.service. The command would look like:

ansible rmwebservers -m ansible.builtin.service -a "name=httpd state=started enabled=yes" -i inventory --become

and it should give us

where we've successfully changed the target state of the machines, enabled the httpd service, and started it as well.

So, that's a lot for you all to think about and a little exercise for you would most definitely be another module called ansible.builtin.copy. We'll discuss it in the next one before jumping onto playbooks (yes, it's gonna be funny for as long as I WANT!).

What next?

The above-mentioned module, its corresponding ad hoc commands, a little project, and the basics of Ansible playbooks are what we'll get into next. And to address the playbook situation, I think I'm borderline funny. OR MAYBE--

Connect with me onMy LinkedIn.

We reached the world of "ad-hoc" commands by the end of the last chapter. We also executed our first command. If you need to revise, here you go.

Here's a little refresher.

ansible remotemachine01 -m ping -i inventory

where ansible is our best friend, remotemachine01 is the name for our target one (refer inventory), the -m flag is followed by the module we want to work with, here it's ping, and -i goes with the inventory file.

So, as promised we'll dive deeper into two things in this chapter. They are:

1. The inventory file.

2. The output of our first ad-hoc command.

Groups in Ansible Inventory

The official documentation refers to ansible inventory as:

a list or group of lists to automate tasks on managed nodes or “hosts” in your infrastructure

Through the Ansible inventory file, Ansible knows where to look for (ansible_host, ansible_user, etc) and what to look with (ansible_ssh_private_key_file) because as mentioned before, Ansible uses established connections specific to specific operating systems, in this case, SSH, to form connections.

Let's understand its structure. As mentioned above, it's a list of groups. But what's important to note is:

• Each group has children which can be or cannot be defined.

• In most cases, this is used in conjunction with a hierarchical structure.

Let's see our inventory file, shall we?

all:
  hosts:
    remotemachine01:
      ansible_host: 172.31.18.192         //will be different for you obviously
      ansible_user: ec2-user                     //amazon does this for RHEL OS
      ansible_ssh_private_key_file: clientkey.pem     //our private key for SSH

I'm assuming that you know how to structure YAML configuration files. Equal spaces, indentation, and no tabs. That's how you avoid mistakes in such files.

Let's modify this.

all:
  hosts:
    remotemachine01:
      ansible_host: 172.31.26.104
      ansible_user: ec2-user
      ansible_ssh_private_key_file: clientkey.pem
    remotemachine02:
      ansible_host: 172.31.18.151
      ansible_user: ec2-user
      ansible_ssh_private_key_file: clientkey.pem
    remotedb01:
      ansible_host: 172.31.29.220
      ansible_user: ec2-user
      ansible_ssh_private_key_file: clientkey.pem

  children:
    rmwebservers:
      hosts:
        remotemachine01:
        remotemachine02:
    rmdbservers:
      hosts:
        remotedb01:

Now to understand this one needs to know that:

1. In Ansible, the "all" at the top of your inventory file is a special keyword that represents the top-level group, taking into account all hosts defined in the inventory. It essentially groups together all the hosts listed below it. This allows you to address all hosts in your inventory collectively or apply configurations to all hosts.

2. In this inventory file, the "all" group contains three hosts: remotemachine01, remotemachine02, and remotedb01. It also defines two child groups (rmwebservers and rmdbservers. This structure allows you to organize your hosts into different groups and apply configurations selectively.

We're now ready to execute commands. We can now, perform host-based, as well as, group-based ad-hoc commands. Execute the following commands:

ansible remotedb01 -m ping -i inventory
ansible rmwebservers -m ping -i inventory

What did you see? Is it respectively like this? (ignore the host names, mine are different)

YAY! We now have a basic understanding of groups in Ansible inventory files.

Regarding the output, there are three sections here:

1. The facts gathered by Ansible about the target machine it connected to. There's an amazing module Ansible executes first before any other module, whether ad-hoc or through a playbook. We'll get to it soon. Here, it's just the interpreter used for this particular script's execution on the target machine.

2. Changes made by Ansible on the target made. In this case, it's false because we're just pinging the target machine but we'll see it becoming true very soon.

3. Ping and pong. Modules usually have corresponding responses which we'll see soon but this is just for fun.

These and many more fields in Ansible outputs will be your friends for life. They'll help you with details, debugging, and generating test cases.

What next?

You already know it! I guess not. We'll finish the hierarchical structure of this inventory file and apart from that, the next chapter will wholly be dedicated to a lot of ad-hoc commands. Buckle up!

Connect with me on LinkedIn.

Again, let's begin with another praise for Ansible. I love Ansible's documentation for how easy it is to navigate it. I already am doing it so at this point, you the reader don't have to. I got you.

Ansible Installation

A little assumption from my side is that you have a machine at your disposal that you could use. We could do with:

1. A virtual machine on your system (using Vagrant maybe) or

2. An EC2 instance preferably (t2.micro would work. Make sure you edit the security group for SSH inbound traffic from your IP)

Just make sure you have compute resources as well. Now, navigate to https://docs.ansible.com/ansible/latest/installation_guide/installation_distros.html and select the favorite OS and distro of your choice. Statistics and my personal bias say that Linux and Ubuntu respectively are the best for this.

You must execute the following commands in the CLI of your choice (mine is Git Bash) to install Ansible on the machine

$ sudo apt update
$ sudo apt install software-properties-common
$ sudo add-apt-repository --yes --update ppa:ansible/ansible
$ sudo apt install ansible

and finally, we will validate our installation with a ansible --version command.

Great. We're now done with the installation of Ansible. This machine which now holds your Ansible power will henceforth be referred to as the "Control Machine".

Ansible Architecture

The architecture consists of a Control Machine, where we write the code and specify what we want to do and how we want to do it, a set of Target Machines we want to automate or "change", a configuration file, and an inventory file.

There are in essence, three important things one needs to know here.

1. Ansible loves Python.

   Both Python 2 and Python 3 interpreters are used by Ansible to execute remote and local automation. We have different modules in Ansible that we are going to use and different modules, use different Python interpreters and different Python versions. Some modules make this distinction very clear and we'll get into those soon.

2. The Target Machine is where the magic happens.

   All the code that we are going to run or write will be translated into Python scripts. And those Python scripts will run on the client (target) machine, and not on the control machine. Although the magic (in this case YAML scripts) is written on the control machine, it happens (executes) on the target machine. Hence, we achieve automation.

3. Understanding Ansible inventory makes or breaks things.

   I know we haven't talked about this and that's exactly what we'll do.

Ansible Inventory

Ansible in order to perform automation needs to know where it has to do so. The inventory file defines that along with a few very important things. According to the official Ansible documentation

The simplest inventory is a single file with a list of hosts and groups. The default location for this file is /etc/ansible/hosts. You can specify a different inventory file at the command line using the -i <path> option or in configuration using inventory.

Another thing I'd like to emphasize is how essential the usage of environmental variables is in the world of Ansible (or in automation in general). I'd encourage you to explore them while going through the documentation (which you must).

For our exercise, the environment variables we'll use are

• ansible_host

• ansible_user

• ansible_ssh_private_key_file

Before writing our inventory file, we have to set up a few things. These are:

1. We should have an understanding of YAML (Yet Another Markup Language) and of Vim/Vi editor.

2. We should set up at least four EC2 instances (or Vagrant VMs). Three CentOS (RHEL) and one Ubuntu (Debian).

3. We must modify a few defaults before attempting to use an Ansible module.

Now, while I leave the first two points up to you, I'd like to get my hands dirty on the third.

Firstly, we have to create a file called clientkey.pem (a private key for OpenSSH from AWS) through Vim and paste the RSA content which can be found in the key you downloaded when you created a keypair while creating EC2 instances into it. This will validate the SSH connection that our control machine will make with our target machines.

Secondly, we'll get into modifying default configurations. We have to generate our own Ansible configuration file while overriding the default ansible.cfg file at /etc/ansible/ansible.cfg using

ansible-config init --disabled all > .ansible.cfg

This will generate an extensive ansible configuration. Open it through the Vim editor, search the keywords "host_key_checking" using / operator, uncomment, and disable it. This will disable the host key checking prompt and make the connection non-interactive, exactly as we want.

Thirdly, we want to modify permissions to avoid an "UNPROTECTED PRIVATE KEY FILE" using

chmod 400 clientkey.pem

A typical inventory file for our exercise in order to broaden our understanding further would look something like this. Make sure you name it inventory. The interpretation of this will extensively be covered in the next chapter.

all:
  hosts:
    remotemachine01:
      ansible_host: 172.31.18.192
      ansible_user: ec2-user
      ansible_ssh_private_key_file: clientkey.pem

And for the showdown, we execute our first "ad-hoc" command. I'll leave it up to you to go through the output and we'll pick it from there in the next chapter.

The command uses a test module in Ansible named ping (as the name suggests it pings the target machine and returns a JSON output).

ansible remotemachine01 -m ping -i inventory

What next?

Next, we'll deep dive into Ansible configuration, followed by an introduction to groups of hosts and our very own playbook.

Connect with me on My LinkedIn.

We begin this with the reason I've taken this tool up. It's because I see it EVERYWHERE. My ever-alive need to stay up to the standard while learning DevOps has brought me to Ansible.

Let's start.

What is Ansible?

Whenever we speak about DevOps, we think of automation, and rightly so. There have been innumerable attempts to make things as automated as possible. The simplest of those would be Ansible.

Ansible as a tool can be categorized in automation, server management, provisioning, and configuration management and it would pass with flying colors as all of the above. The reason is the ability to adapt through regular integrations with ever-evolving technologies.

What makes Ansible different?

1. When overseeing the administration of a network comprising many (say 100) servers via configuration management tools such as Puppet, Chef, or Salt Stack the conventional approach involves installing agents on each of these machines. However, with Ansible, this step is no longer required. Ansible uses established connections specific to specific operating systems; for Linux environments, it employs SSH, while for Windows systems, it uses winRM. This makes it simpler and easy to use.

2. Another plus point would be its "no residual software" policy which in simple terms is that when we write Ansible code, specifically playbooks, the process involves generating Python scripts. These scripts are then executed on a custom target, making desired changes. There is no residual or left-out software residue on either the target system or the control machine (the machine on which Ansible is running), making Ansible clean and efficient in execution.

3. And since it's based essentially on Python libraries, we can simply get started with a pip install command, along with other ways of course. This along with YAML being the standard in writing Ansible playbooks (a list of tasks) makes it a very "friendly" tool.

What next?

Next, there's action. We'll get into installation, Ansible architecture, inventory and configuration files, and Ansible ad-hoc commands followed by writing our very own Ansible playbook.

Since this is my first post, I'd be grateful if you could share this. It ain't much but it's honest work. Thanks for reading and stay tuned.

Connect with me on My LinkedIn.