Getting started with Ansible for managing our personal lab – ad-hoc commands

After we installed Ansible and tested that it works well, then we want to make it work for us. There are three methods Ansible can operate. The first one is running so called ad-hoc commands with the ansible command line tool. The second option is to write re-usable code (playbooks, roles and variables) and run them with the ansible-playbook command. Both commands use the push mechanism to interact with the controlled nodes. A third option is a tool called ansible-pull that (as its name suggests) pulls the configuration onto a managed machine from a source code management repo. Let’s take a look at the easiest method, the ad-hoc commands first!

To be able to run ad-hoc commands with Ansible we don’t need too many things and configuration. There are three elements in our very basic example:

• An Ansible control node
• A host inventory of the managed node or nodes (inventory INI file)
• A managed node or nodes

We’ve already installed our Ansible control node. The host inventory is a plain text file that lists our Ansible controlled devices. It can manage even the localhost in an inventory.

By default this file is the /etc/ansible/hosts, but we can (and will) define our own inventory in our Ansible project directory. The inventory file can be in INI format or YAML. Both have their advantages, but currently we will use the INI format. A managed node can be a network device, a virtual machine or a physical server. In our example we will use a virtual machine in VMWare to operate on.

We start with a single Debian server and some ad-hoc commands in our automation journey. Along the way we will create reusable code as our infrastructure will get more devices to manage. The code will incrementally grow so we will separate our playbooks to more fine-tuned Ansible roles. For managing passwords and secret data we will integrate Ansible Vault to our solution.

Setting up the SSH keys

The IP address of our first managed host is 192.168.122.129, and we are going to connect to it via SSH. We don’t use passwords, so let’s set up SSH keys for the communication!

On the Ansible control node we create a private and public SSH key pair for our user. In production we would use a passphrase on the key of course.

ssh-keygen -t rsa

We have to share our public key with the remote machine to be able connect via SSH into it without password.

ssh-copy-id tmolnar@192.168.122.129

After providing our password to the command our the public key will be transferred to the remote server in our user’s home directory, and we are ready to use Ansible without SSH passwords.

Our Ansible control node can reach the managed node now, the SSH key change has happened, so we have to create our inventory file in the next step.

Setting up the inventory file

Let’s create an empty file in our project directory and call it inventory!

touch inventory

We have to add our managed host with some additional information to this file.

[vmware]
debserver ansible_host=192.168.122.129  ansible_connection=ssh  ansible_become_method=su

Let’s break down this host entry!

The first line, [vmware] is the name of the group we create for our hosts. We can operate on our hosts groups using this name.

The debserver is the alias of our managed node. The ansible_host is the IP address of the server that we use for the connection. It can be either an IP address or the FQDN of the managed host. The ansible_connection variable confirms that we use SSH for our remote management. The ansible_become_method is the way that we use on the remote server to become root. As we start with a minimal install of a Debian server it is going to be su initially. Later we will set up sudo.

We can check out inventory with the ansible-inventory command.

ansible-inventory -i inventory --list

The command output must be something similar:

{
    "_meta": {
        "hostvars": {
            "debserver": {
                "ansible_become_method": "su",
                "ansible_connection": "ssh",
                "ansible_host": "192.168.122.129"
            },
            "localhost": {
                "ansible_connection": "local"
            }
        }
    },
    "all": {
        "children": [
            "ungrouped",
            "vmware"
        ]
    },
    "ungrouped": {
        "hosts": [
            "localhost"
        ]
    },
    "vmware": {
        "hosts": [
            "debserver"
        ]
    }
}

Let’s test our connection with Ansible!

ansible vmware -i inventory -m setup --become --ask-become-pass

After typing the root password of the remote server we will see a lot of information and facts about the remote machine. The command not just verifies that Ansible can connect to the managed node, but it becomes root on the Debian server and queries its facts.

If the command ran without issues it means that our Ansible is set up and ready for some real work.

Running our first ad-hoc command

To be able to do operations we have to use Ansible modules. These modules are grouped in collections. One of our most basic collection that we will use is the ansible.builtin collection.

We have a working Ansible infrastructure with an inventory and a server to manage. Let’s install something on it with using Ansible.

ansible vmware -i inventory -m ansible.builtin.apt -a "name=vim state=present" --become --ask-become-pass
BECOME password:
debserver | CHANGED => {
(...)
}

The command above is our first real remote operation on a managed host with Ansible. The ansible command uses the machines in our vmware group as the target hosts. At the moment we only have one Debian server in it. We use our inventory file called inventory. The module we need is the ansible.builtin.apt that accepts different parameters. We gave it two parameters in the command line: the package name (vim), and that we want to install it (present). In the end we have vim installed on the controlled node.

The first ad-hoc command ran successfully. Ansible logged in to the remote server via SSH and changed user to root. It installed the vim package as we’ve requested.

If we had 100 or 1000 servers in our vmware group, then we installed vim on all of them with this one single command.

This was just the beginning of our journey with Ansible.

Ad-hoc commands are great when we have to do something quickly on multiple remote hosts, but its real strength is in eliminating repetition and creating reusable configuration as code. We will create modular code files that can do the heavy lifting instead of us. Keeping the code in source control management is also a wise idea.

Reference: https://docs.ansible.com/ansible/latest/getting_started/index.html

In the next part we will take a look at the next logical level of Ansible: a playbook. Stay tuned and automate!

If you have anything to share then please visit my Tom’s IT Cafe Discord Server!