A Message from the Ansible

Have you gotten the Ansible working yet?

Not quite yet. Just a little more tweaking. Ah, there we go.

Yes, that’s much better. We’re now back online.

What Came Before

On restarting my blog last fall¹, I changed a lot of software. Too much, in retrospect. One of the changes that I made was to change from Ubuntu to Arch Linux. I had heard many good things about Arch, and I was determined to try it out. I set up Hugo and GitLab, and it worked well enough.

Pacman was fairly alien, but not much more alien than Yum for someone coming from apt. The tooling around Arch User Repository, is fairly atrocious compared to PPAs in the Ubuntu universe. It’s recommended as an advantage to Arch, but I found it nothing but an outdated distraction. The tools I installed most often were AUR helpers, the best of which was aura.

The problem started early this year when GitLab released a new version. That didn’t show up in AUR. For weeks after the release. If I had been on Debian, Ubuntu, or even CentOS, I could have simply updated using the GitLab CE Omnibus installer. Combine that with my general unfamiliarity with Pacman and AUR, and I was ready to change back to a more familiar system, so I backed up my files and wiped my Linode².

What Came During

At work, we’ve been using Ansible to deploy our current project (there will be articles coming about that project soon), and I knew that I didn’t want to spend weeks rebuilding my server, so I decided to use Ansible to build my site. As I worked with Ansible the more I appreciated the niceness of the approach…and I realized that my implementation was wrong.

Not only was I trying to build a single playbook when I needed at least two, but I was misusing roles and constructing everything wrong. I had created a basic setup to provide me with implementations that would let me manually create the next steps, but that left me no better off in many ways than where I had started from. Additionally, the initial bootstrap steps in Linode (or any other environment) needed to be run by hand, equally defeating the purpose of Ansible.

So I spent my (sparse) spare time over the next couple of weeks building out my bootstrap playbook, using Ansible Galaxy as much as possible³. The first pass I made for a bootstrap script was not replayable. It did entirely too much—and could not be safely run as any user other than root.

---
- name: Bootstrap new zieglers.ca servers
  hosts: bootstrap
  remote_user: root
  roles:
    - bootstrap-linode
    - bootstrap
    - role: george.shuklin.reboot-if-needed-for-upgrade
      force_reboot: true

Happily, this short playbook (bootstrap.yml) is replayable, or at least the boostrap role (defined in roles/bootstrap/meta/main.yml) is replayable. It does just enough to initialize and secure the server. After running that, it becomes possible to run site.yml to deploy my blog—and any future features I want (like gogs).

---
- hosts: all
  vars_files:
    - secret_vars/sudo.yml
  roles:
    - common
    - role: george.shuklin.reboot-if-needed-for-upgrade
      ip_to_probe: "{{ ansible_ssh_host }}"
      port_to_probe: "{{ ansible_ssh_port }}"

- hosts: halostatue-blog
  roles:
    - halostatue-blog

I’ve learned a lot over the last few weeks, and I have a lot more to learn—and I will share what I learn.