Long, long overdue post going over my Ansible config for my DO server that's running this website/blog/thing. Does it count as a blog if you're writing raw HTML yourself? At any rate, I decided to use Ansible to configure my DigitalOcean droplet after Terraform built it for me. Why? Mostly due to comfort. I taught myself Ansible out of necessity in a previous role where I was able to automate quite a bit with it. It's just what I'm comfortable with. I'm sure the same sorts of things could be done with Chef, Puppet, Saltstack, a shell script, python, and so on.

Ansible essentially connects to a system via SSH and converts the playbooks and roles in my repo to python scripts to configure docker (which runs the container for this site), a GitHub Actions Runner (which provides ci/cd tooling connectivity to GitHub), and certbot, which gives me free SSL certs via LetsEncrypt and keeps things auto-renewed.

So, some core concepts for Ansible that will come in handy if you check out my repo.

• A playbook is a yaml file consisting of tasks and/or roles to be executed against the host(s) specified. Official docs
• A role is a set of tasks that are logically grouped together and called as a single unit. Official docs
• A task describes the action you want to take.

In my case, host_configure.yml says "Apply the roles docker, ghrunner, and certbot to webserver using the variables found in inventory/group_vars/vault.yml." So let's break down what those mean a bit.

The roles in the repo linked above are very minimalistic, and are laid out following Ansible's guidance for creating roles. Let's start with the docker role, since it's mentioned first in the playbook.

The docker role describes only two tasks:

1. Make sure the docker.io package is installed using apt.
2. Make sure the docker service is started and that it's set to start on system boot.

Easy, right?

The ghrunner role is next. It's a bit more complex than the docker role above, but it's not too hard to grok:

• Create the directory /tmp/actions-runner - used as a landing spot for the next task
• Download the actions-runner-linux-x64-2.276.1.tar.gz file from the URL listed, and unarchives it to the path specified
• Check to see if there's already a runner configured on the server, and register a variable called 'config'
• Here's where things get interesting - this next task (configure-runner) does a couple of neat things. It uses {{runnertoken}} which is passed in from the variables in the playbook (inventory/group_vars/vault.yml) only when the runner config checked above doesn't exist, and it doesn't log any output for security reasons.
• Check to see if there's already a runner service in existence and register it as a variable called 'service'.
• Install the runner service only if the service didn't exist in the previous step.
• Make sure the runner service is started and that it's set to start on system boot.

The variable used in the previous step contains the GitLab runner token used to connect back to my GitHub repo, and it's been encrypted using Ansible vault - so it can be safely stored in GitHub and yet still available for Ansible to use. There's tons of good documentation around on how to use Ansible vault.

The last role Ansible uses is certbot. Sharp eyed readers will notice this role is a bit different than the others, it includes a template directory, which will get to in a sec. Here's what the role's doing:

• Make sure snapd is installed and updated.
• Remove any pre-existing certbot stuff.
• Install the certbot snap
• Create a symlink for certbot to work at /usr/bin/certbot
• Allow certbot root access.
• Install a certbot plugin for DigitalOcean dns validation.
• Check to see if a cert already exists, register a variable 'cert'
• Generate a config file from the template directory (mentioned above) for certbot to use.
• Run a certbot command to generate a cert if it doesn't exist.

So that's what Ansible is doing. What about where it's running those tasks. If you recall in the playbook linked above, the hosts line in the yaml file is just 'webserver', which definitely is not enough info for Ansbile to use. That's where an inventory comes into play. Mine is quite simple and contains only a single file with a single host (and the user to connect as).

So now we have the infrastructure in code with Terraform, the configuration in code with Ansible, and next I'll show you how to glue all this stuff together to make a working site.

Posted 2021-04-08

📬 Posts | 🏠 Home | 👋 About