Home Lab Chronicles

Step 4: Ansible

Previous Articles

• Step 1: Making Choices
• Step 2: GlusterFS
• Step 3: Cockpit

I have four nodes set up at this time and it’s going to eventually be 20 nodes. I need a solution where I can deploy configuration changes to the whole cluster without logging into each machine. Enter Ansible from Red Hat.

First, let’s install it on kube1:

sudo apt update
sudo apt install ansible -y

This is just using the default Ubuntu repository. If feature velocity on Ansible increases, we may switch over to the ansible ppa. However, there isn’t actually an Ubuntu 20.04 repository there yet.

See if it installed correctly with ansible --version. You should see something like:

Now we want to create the hosts file that ansible will work on:

sudo cp /etc/ansible/hosts /etc/ansible/hosts.example
sudo nano /etc/ansible/hosts

Mine looks like this at first:

I prefer yaml format. An interesting thing is that I want to be able to hit kube1 with ansible, the host we’re working from. Earlier, we didn’t create a key to ssh from kube1 to kube1, so we need to do that now. It’s just a few lines:

ssh-keygen -t ecdsa -b 521 -f .ssh/kube1 -N ""
ssh-copy-id -i .ssh/kube1 galen@kube1
nano ~/.ssh/config

That leaves you in an editor where you need to add a kube1 section. Just make it look like all the others you added earlier. Once all that’s done, I test ansible with ansible rockpi -m ping. And I get:

It’s working! We’re not done, though. Ansible needs to be able to execute privileged actions on each host. There are a number of ways to do it. You can use --ask-become-pass to prompt for the sudo password. That’s not terrible. One option would be to set up an ansible user on each host and then set it so it could escalate privileges without passwords. That is essentially doubling down on the keys we created earlier. Once again, not terrible. Using Ansible Vault is more extensible, though. We may need to store credentials securely for more than just the sudo password. A good example is if we need an API key to modify DNS entries to automate TLS certificate operations from Let’s Encrypt.

I mentioned Ansible Vault with telling what it is. It’s essentially an Ansible feature that encrypts and decrypts data at rest. One way to use it is to create an encrypted yaml file of variables. We’ll do that here with:

mkdir ansible
cd ansible
ansible-vault create passwd.yml

This puts us into vi editing the file after you give the file a password. If you don’t know how to use vi, then do a search for it. Make the screenlook like:

---
sudo_pw: whateveryourpwis

Once that’s done, exit and write the file. Ansible will encrypt it. Next we need to to change the hosts file again. This is what mine looks like after I edit it:

Basically, I’m telling ansible to use sudo when it connects to the rockpi hosts and then use the rockpi_sudo variable as the password.

Our ansible shell commands get a little longer. We have to tell it what file to get the rockpi_sudo variable from and tell it to prompt for the vault password. Here’s a sample that will list all the block devices on every rockpi host:

ansible rockpi -a "lsblk" --extra-vars '@passwd.yml' --ask-vault-pass

And here is the result:

That was a lot easier than logging into every machine and checking each one. So we have a small taste of how Ansible makes administration at scale much easier. Ansible is a big, dynamic ecosystem. There are lots of plugins and pre-written playbooks available. We will not get into that here.

The next chapter in this will actually be to install Kubernetes using Ansible. That will be fun and then we’ll actually be getting to the point of installing user-facing apps.