← All posts

2026-05-08

A Love Letter to Ansible

Charles Mingus' ballad 'A Love Letter to Duke Ellington' is one of the most beautiful pieces of music to have ever entered my ears. Not the vocal version on 'Changes Two' mind you, but the instrumental version on 'Changes One' from 1971. The theme is magical, in the key of Db with non-typical chord changes. George Adams blows his soul out of the sax on the theme, the solos start. The tune runs for about 12 minutes, and I am always amazed at how the solos are consistently flowing, mindful, lyrical, and playful. Even Mingus plays a gentle-ish solo on the double bass. What i am trying to say is, you can feel the musicians' love for Duke Ellington, a love letter crafted by musical geniuses, on an autumn day in 1971.

Now, this blog post is called 'A Love Letter to Ansible'. I mean, that is obviously an exaggeration, and my love for Ansible is not as strong as Mingus' love for Ellington. But as an IT developer, I do really like Ansible.

So what is Ansible? And why should you use it, even if you do not work with large scale infrastructure deployment on a daily basis?

If you read this, I assume you are a technical person and you are familiar with git and programming. I also assume that you exclusively use Linux for development. If you do use Windows for development, you should strongly be considering switching to WSL. Right? RIGHT? (Insert meme)

If you only program in C#, if all of your infrastructure is Windows, if you don't know your way around databases and SQL (looking at you Entity Framework)... I don't know, get a new job? Just kidding.

Joking aside, you have considered using NixOS. Wow, it builds the entire system from the ground up every time you use 'rebuild nix' or whatever the command is called, and it just installs and configures everything in some flake or yaml file or whatever you guys do. It is idempotent and declarative or whatever. Now you put this into your git --bare repos on a remote vps and you can always restore your niche OS machine with an OS that no one actually uses.

Then you have this weird Arch Linux type who is like I know everything about the Linux kernel, I use Arch btw, I only live in hard mode, I have no partner and so on. That's fine. But when you inevitably need to re-install Arch because you fucked some obscure setting up, then you would wish you were on Nix. Or would you?

Now, for a very specific reason, I use Ubuntu Server 24.04 as my dev machine. Which is fine. I would rather use Fedora or Arch, but the trees do not grow into heaven as they say. And for that same very specific reason, I often need to recreate Ubuntu servers on premise with the exact same software, configurations, and dotfiles. This is where Ansible comes into play. When I create a new Ubuntu server, I do something like 'sudo apt update && sudo apt updgrade'. Then I do something like 'sudo apt install git ansible'. Finally, I git clone from a remote repos, cd into that repository, run something like 'ansible-playbook setup.yml -K', and boom! Neovim is installed, the config file is placed in ~/.config/nvim/init.lua, zsh is downloaded and .zshrc is up and running, fzf is installed, rust is installed, golang is installed, sway is installed, the sway config is configured, gcc, makefile, whatever. You have it all there. Beautiful. Version controlled. The most important things in your life, served in a couple yaml files.

But god damn it, I do not want to know anything about Ansible! Okay, but consider this; now you are always able to reproduce your dev machines. Furthermore, you also know the basics of Ansible, which is so good for infrastructure automation, it works in the cloud, on-premise, on wherever. It uses ssh for provisioning! It could not be simpler. Write Ansible on your resumé and get dev machine as code!

First of, do the git init. Then something like 'vi setup.yml'. Because we all know and love vi (or use your favourite text editor).

Then do something like so: 


---
- name: Ubuntu Server Setup
  hosts: localhost
  connection: local

  tasks:
    - import_tasks: tasks/apt_packages.yml
    - import_tasks: tasks/snap.yml
    - import_tasks: tasks/dotfiles.yml
    - import_tasks: tasks/go.yml
    - import_tasks: tasks/rust.yml
    - import_tasks: tasks/starship.yml
    - import_tasks: tasks/uv.yml
    - import_tasks: tasks/fzf.yml

This is the main entry point. Then you do something like 'mdkir tasks' and then 'vi tasks/apt_packages.yml'. Here you just slap on the apt software you want, as such: 


---
- name: Upgrade all packages before installing
  ansible.builtin.apt:
    upgrade: dist
    update_cache: true
  become: true

- name: Install apt packages
  ansible.builtin.apt:
    name:
      - libopenjp2-7-dev
      - ffmpeg
      - libreoffice
      - clang
      - ncurses-base
      - fzf
      - sqlite3
      - libgs-dev
      - libssl-dev
      - libopenjp2-7-dev
      - unixodbc
      - unixodbc-dev
      - ripgrep
      - jq
      - libopenjp2-7
      - sway
      - findutils
      - fd-find
      - gawk
      - curl
      - tar
      - wofi
      - alacritty
      - wl-clipboard
      - stow
      - git
      - make
      - tmux
      - podman
      - hugo
      - zsh
      - zsh-autosuggestions
      - zsh-syntax-highlighting
      - gcc-mingw-w64-x86-64
      - g++-mingw-w64-x86-64
      - maven
      - openjdk-21-jdk
      - dotnet-sdk-10.0
    state: present
  become: true

But why do you install dotnet??? yeah whatever.

Then run 'ansible-playbook setup.yml -K' and there you have it.

But Bartal, how do you manage your dotfiles? Glad you asked. I use symlink manager gnu stow.

'vi tasks/dotfiles' 


- name: Clone dotfile repos
  git:
    repo: "INSERT YOUR REMOTE REPOS"
    dest: "{{ ansible_user_dir }}/dotfiles"
    accept_hostkey: true
  become: false
  
- name: Set zsh as default shell for current user
  user:
    name: "{{ ansible_user_id }}"
    shell: /usr/bin/zsh
  become: true

- name: Ensure stow is installed
  package:
    name: stow
    state: present
  become: true

- name: Stow dotfile packages
  shell:
    cmd: stow --restow */
    chdir: "{{ ansible_user_dir }}/dotfiles"
  become: false
  changed_when: true

Perhaps use user_dir and user_id instead of prefixing it with ansible_. It will get deprecated at some point, but I am too lazy to alter it.

Gnu stow is so awesome, go check it out. Or write me if you want some guidance. Or perhaps I'll write a blog post about at some point.

Anyways, the sky is the limit here. My advice. Choose a Linux distro, stick with it for as long as you can. Write an Ansible playbook for your setup. Be happy. I mean, the dev machine and its software + dotfiles is your instrument. Charles Mingus primarily used his own double bass at gigs. You make sure that your instrument is available, so that you can go out and do some amazing stuff in the world. And perhaps, some day, someone will write YOU a love letter.

← All posts