detour through ansible
5 min read
intro
this weekend and much of this week has been completely shot. being sick for much of it, i failed to find the energy and motivation to continue grappling with the projects i’ve been working on. instead, in those moments i found able to focus on writing any code at all, i opted to boot up an idea i’ve had sitting on the backburner: an ansible collection.
some background
over five years ago, i decided to learn JavaScript. at the time i had nothing but an iPad Air and a whole lot of gumption. also at the time, mobile development—or rather, developing on mobile, not for it—was not very manageable. there were a handful of apps for writing, a few terminal apps, some git apps, but nothing fanciful or feature-rich. there were certainly no full blown IDEs; well, not any worth the money or the trouble. i did however, manage to hobble together a system that worked. i found an app in which i could run JS scripts—Play.js, which was later purchased and mutilated by CodeSandbox—and another fully featured terminal app i used to connect to a cloud server on Digitalocean.
as i got more and more savvy with this setup, i started spinning up droplets for different projects. the only real problem i was running into was the time i spent configuring and provisioning new droplets. still relatively knew to the whole developer thing, i didn’t know the first thing about systems automation; i did, however, stumble upon Ansible. after about a week’s worth of trial and error, i had a droplet set up as a control node and certificate authority. when it was time to spin up a new droplet, i fired up the control node and ran my provisioning playbooks through it. i even started working on a personal collection specifically to provision DO droplets, as well as one to work through Vagrant and Docker.
current status: local development
i have since upgraded to a MacBook, and now do most of my development inside virtual machines. for a time, i used one virtual machine in which all of my dev tools were installed. for most of what i was doing, it sufficed, and i never had any concerns over processing, ram, or storage. however, with much of what i’ve been working on lately—hyperion archive, the magi—i’ve come to realize i need more space, and an expanded understanding of how to work with multiple virtual machines and environments. i’ve booted up and torn down a number of VMs lately, all for the purposes of testing new tools and building out new toolchains, and i’ve been running into the same issues i ran into on my iPad with the droplets: provisioning.
as i’m already familiar with Ansible, i dove back into it and started creating a new personal collection for the purpose of simplifying my VM setups.
trouble with python
of course, not being fluent in Ansible collections development, this took me the better part of two days to write out. day one was pretty much spent learning how to set up a proper development environment for python. if i’ve ever written a line of python in my life, i assure you, it was quite by accident. and not because i’m not interested in python, but because i just haven’t taken a dive into it yet.
as such, there was a lot in the setup i found to be confusing. the ansible docs weren’t the least bit helpful. it wasn’t until i figured out what was being asked of me that i knew what to look for. i fumbled quite a bit getting the ansible-dev-tools to install properly, and it was through grappling with this package that i learned all about python’s virtual environments.
i think i booted up no less than three VMs because setting up a new one was easier than having to undo all the shit i had installed and changed in my efforts to figure out what the fuck i was doing. but once i finally understood, it was a simple matter of initializing the collection and writing it.
and, of course, all the trial and error that brought with executing the playbooks. ultimately, i got it all working, running playbooks locally. introducing:
ephemeralrogue.bookworm
there’s really nothing fancy going on here. it’s an Ansible collection aimed at quickly provisioning Debian 12 virtual machines. the whole thing runs pretty quickly and by the time it’s complete, i have a basic set of tools installed:
when i boot up a new vm, i’ll setup passwordless sudo, install Ansible, download this collection, and run the main playbook: provision_debian_vm.yaml:
ansible-playbook -i 127.0.0.1, --extra-vars "user={{ enter username }}" /path/to/playbooks/provision_debian_vm.yaml
this reminds me: shoutout to the one single person who distinctly pointed out the importance of that fucking comma after the localhost ip(thanks to whoever wrote this article on shellhacks). i cannot tell you how much i stumbled over that snafu until someone drew attention to it.
right now, all of the options available for detecting system architecture and software version are hardcoded to arm64 and bookworm, which, of course, suit my purposes just fine at the moment. i do, however, plan to iterate over this and gradually improve and add to the collection as I progress in my exploration of LLMs, containerized applications, and kubernetes. my hope is that this becomes my one-stop shop to quickly instantiate and launch versions of the software i’m hobbling together in my local development toolchain, and will remain useful as newer versions of Debian are released.
i still have to write up the README too, though this isn’t too bad for a half-baked project written while lying in bed sick and drained.