intro⌗

Setting up a server is one of the most rewarding things an I.T person could do, you mess around with shell scripts and experiment till you get your configuration just right.

However; there comes a time(it will always come) when you want to deploy to a new location, format the already existing instance or upgrade to an even better instance.

What to do when that time comes? Should you go back to your browser history and look at every guide you took a look at? Maybe, try to get a list of packages that you had installed and re-install them. Or even, copy the /etc/ and /var/ file to mimic the configuration and the data directory.

Too many options and they all do not compare to IaC(Infrastructure as code). The idea is simple: You have a file, you execute a program that takes that file and suddenly you have your server machine setup that way you wanted.

Today, I’ll go over the basics of IaC and a little intro to RedHat’s ansible.

IaC: ansible⌗

Take a look at this file:

- name: Install basic utilities
  hosts: all
  remote_user: zest
  become_method: doas
  tags: pkg_bootstrap
  tasks:
  - name: Update everything
    apk:
      upgrade: true
    become: true

This file represents a group of tasks to “Install basic utilities”. In this group, there are tasks that must be done in the server or otherwise it would stop executing.

Every task has a name, some parameters and finally a module. Each module has its own purpose. In this case, the module we’re using is apk.

apk is a module that manipulates an alpine linux system’s package system. It can install, remove, update or upgrade packages.

You might be wondering; well, how do I find out which module to use for the thing I want to do? The answer is scour the web.

Until yesterday, I had no experience with ansible. But today, my whole server runs on ansible and I am putting together functionality very fast.

Things like becoming root, installing packages, creating configuration files or modifying lines in files are done oh so beautifully in ansible.

After using ansible, you’d probably wonder: “have I been living under a rock?”

ansible: technical details⌗

ansible uses Python3 and yaml for its syntax. yaml is a very readable syntax for describing all types of data from numbers, to float and booleans to lists and objects.

Besides that, ansible does not require you to have ansible installed on the remote host. You have to have ansible on your machine. On the remote machine just install Python3 and you’re good to go.

At first, you could get away with using root password to login but it is far better to use SSH keys for future sessions because they’re less interactive.

Personally, my first login with ansible used the login as root with password but only to harden SSH and disallow future root logins.

cool ansible features⌗

ansible has seriously surprised me in-terms of how many useful features it has. I haven’t encountered such well-written software in a while; it’s quite shocking how good ansible is.

Here are some of the features I found were very useful.

tags⌗

I love this feature. Basically, say you have setup your git server on your remote machine, you shouldn’t have to touch that again if you didn’t modify it, should you?

Well, ansible agrees and you could use tags to describe which groups to run and which not to. Some can only be run once specified and other will always run unless specified not to.

doas, sudo, or $ALTERNATIVE⌗

become is ansible’s program-agnostic way of becoming superuser. You could use doas, sudo or any other program that is supported by ansible.

Furthermore, if the program requires a password, you could use the flag --ask-become-pass or -K. Once this flag is activated, you input a password once and everytime you become a user, ansible will use that password.

host specification⌗

In ansible’s playbooks(ansible-slang for saying config files), you don’t have to specify a host. You only specify a host group through the inventory file.

This means you could run one playbook and simultaneously update every single host depending on its function(db server or web server and so on).

prompts⌗

What if your server needs a specific value from the user? You could get it through the prompt_var section in one of your plays.

A prompt is a way to tell the user: “I need this value from you right now.” - You could make a prompt private or public(do not show password characters but show username characters).

variables & functions⌗

Guess what? You could use variables across tasks in plays. Similarily to how you could use a prompt, you could get that prompt’s value and use it in literally any string.

I found this particularly useful when using lego, my SSL manager, to specify domains.

I had a list variable with my domain list and used a function called join to join all the list elements together.

So, given(YAML syntax):

my_domains:
- "lemondev.xyz"
- "*.lemondev.xyz"

I outputted:

lego --domains lemondev.xyz --domains *.lemondev.xyz

the many amazing modules⌗

cron, file, lineinfile, template. look those up.

conclusion⌗

IaC is good if you want to have reproducible instances & servers. I suggest any Linux novice to try it as the experience it provides is very eye opening.