Trying out Ansible

26/02/2025 #homelab

It’s been a week since I last tried doing anything with my new homelab rack and it’s still in a mess. Since my previous approch wasn’t working, I’ve decided to try a completely different set of tools, and I figured why not pick up a new skill while I’m at it. I’ve heard a lot about Ansible, and it seems like now is a good time to try it out.

What is Ansible?

Ansible is an automation tool that lets you use YAML files to describe what you want your servers to look like, and then it takes care of making sure that they are in that state. The main advantage of Ansible is that it’s agentless, which means that you don’t need to install anything on the servers that you want to manage. You just need to have SSH access to them. In my case, I’m using my Pi3B+ (which I’ll refer to from now on as ControlPi) as the control node, and the rest of the rack as the managed nodes.

Setting up Ansible

Installing Ansible on ControlPi was pretty straightforward. I opted to use pipx since it was the first installation method on the official documentation. I just had to run the following commands:

sudo apt update
sudo apt install pipx
pipx ensurepath

After that, I installed Ansible with pipx:

pipx install --include-deps ansible

This took a few minutes since the Pi3B+ isn’t the fastest machine, but it eventually finished without any issues. I ran pipx ensurepath again the update the system PATH, source ~/.bashrc to reload the PATH, and then ran ansible --version to check that the installation was successful.

Following the quickstart guide

I followed the quickstart guide on the Ansible documentation to get a feel for how things work. I created a new folder in the home directory called ansible, and then another folder called quickstart inside that. I then created a new file called inventory.ini with the following contents:

[myhosts]
192.168.1.206
192.168.1.207

This file lists the IP addresses of the managed nodes. At this point, it’s just the the two VMs that run docker containers, but I’ll be adding the rest of the rack to this file as I go along.

I then ran the following command to verify the inventory:

ansible-inventory -i inventory.ini --list

It printed out what looked like a json file, so I guess it worked. So continuing with the guide, I tried pinging the managed nodes:

ansible myhosts -m ping -i inventory.ini

But this time it threw an error at me, and got stuck there for a while until I used Ctrl+C to stop it.

192.168.1.207 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: Warning: Permanently added '192.168.1.207' (ED25519) to the list of known hosts.\r\n[email protected]: Permission denied (publickey,password).",
    "unreachable": true
}

I could manually ping the VMs, so I know it’s not a network issue. From what I can tell, it looks like ansible uses the same username as the one running the command to connect to the managed nodes. Since I was running the command as admin, it was trying to connect to the managed nodes as admin. But I don’t have a user on my VMs named admin, so it can’t SSH in.

A quick google search later, and I found that I could specify the username to use with the ansible_user variable. Varaibles looked easier to manage in YAML, so I changed the inventory file to inventory.yaml and updated it to look like this:

docker-vms:
  hosts:
      docker_internal:
        ansible_host: 192.168.1.206
        ansible_user: richard
      docker_external:
        ansible_host: 192.168.1.207
        ansible_user: richard

I then ran the following command to verify the inventory:

ansible-inventory -i inventory.yaml --list

It gave me a similar json as before, but it also gave a warning about invalid characters in a group name.

[WARNING]: Invalid characters were found in group names but not replaced, use -vvvv to see details

I ran the command again with the -vvvv flag to see what the issue was, and it turns out that the group name docker-vms was invalid. I changed it to docker_vms and ran the command again. This time it worked without any issues.

I then tried pinging the managed nodes again:

ansible docker_vms -m ping -i inventory.yaml

But nope, still getting an error.

{ % highlight bash %} docker_external | UNREACHABLE! => { “changed”: false, “msg”: “Failed to connect to the host via ssh: [email protected]: Permission denied (publickey,password).”, “unreachable”: true } { % endhighlight %}

It occurred to me at this point that it’s not pinging the VMs, but rather trying to SSH into them. I hadn’t set up my SSH keys, so I couldn’t connect to them.

Setting up SSH keys

I generated a new SSH key on ControlPi with the following command, then copied it to the managed nodes:

ssh-keygen -t ed25519 -C "admin@pidns"

ssh-copy-id -i ~/.ssh/id_ed25519 [email protected]
ssh-copy-id -i ~/.ssh/id_ed25519 [email protected]

It prompted me for my password on the two managed nodes, and after that I tried the “ping” command again.

ansible docker_vms -m ping -i inventory.yaml

This time, everything worked out fine, but I still got a warning about the python interpreter on the managed nodes.

[WARNING]: Platform linux on host docker_internal is using the discovered Python interpreter at /usr/bin/python3.12, but future installation of another Python interpreter could change the meaning of that path. See https://docs.ansible.com/ansible-core/2.18/reference_appendices/interpreter_discovery.html for more information.
docker_internal | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3.12"
    },
    "changed": false,
    "ping": "pong"
}

I’ll have to look into this later, but for now, I’m just happy that I got the ping command to work and I can continue with the quickstart guide.

Quickstart playbook

I created a new file called playbook.yaml with the following contents, then ran the playbook:

- name: My first play
  hosts: docker_vms
  tasks:
   - name: Ping my hosts
     ansible.builtin.ping:

   - name: Print message
     ansible.builtin.debug:
       msg: Hello world

ansible-playbook -i inventory.yaml playbook.yaml

Ansible returned the following output, which seems fine to me other than the python interpreter warnings.

PLAY [My first play] **********************************************************************************************************

TASK [Gathering Facts] ********************************************************************************************************
[WARNING]: Platform linux on host docker_internal is using the discovered Python interpreter at /usr/bin/python3.12, but
future installation of another Python interpreter could change the meaning of that path. See https://docs.ansible.com/ansible-
core/2.18/reference_appendices/interpreter_discovery.html for more information.
ok: [docker_internal]
[WARNING]: Platform linux on host docker_external is using the discovered Python interpreter at /usr/bin/python3.12, but
future installation of another Python interpreter could change the meaning of that path. See https://docs.ansible.com/ansible-
core/2.18/reference_appendices/interpreter_discovery.html for more information.
ok: [docker_external]

TASK [Ping my hosts] **********************************************************************************************************
ok: [docker_external]
ok: [docker_internal]

TASK [Print message] **********************************************************************************************************
ok: [docker_internal] => {
    "msg": "Hello world"
}
ok: [docker_external] => {
    "msg": "Hello world"
}

PLAY RECAP ********************************************************************************************************************
docker_external            : ok=3    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
docker_internal            : ok=3    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Fixing the python warning

Based on the interpreter discovery documentation, it looks like I can set the python interpreter to use in the inventory file, or I can just silence the warning. I’ll go with the latter for now since I might mess with python interpreters later on and I’d rather not have to update the inventory file every time. To silence the warning, I added the ansible_python_interpreter: auto_silent variable to the inventory file:

docker_vms:
  hosts:
      docker_internal:
        ansible_host: 192.168.1.206
        ansible_user: richard
        ansible_python_interpreter: auto_silent
      docker_external:
        ansible_host: 192.168.1.207
        ansible_user: richard
        ansible_python_interpreter: auto_silent

I then ran the playbook again, and this time I didn’t get any warnings about the python interpreter.

Conclusion

I’ll leave things here for now. I’ve managed to get Ansible installed, set up an inventory file, and run a basic playbook. Moving forward, I’ll likely be setting up some new VMs or LXCs, and I’ll create a new playbook in parallel to automate the process.