For most of the past decade, I did my server management primarily with Puppet. Servers being orchestrated by Puppet work on a “pull” model — they periodically contact a central server (colloquially called the puppetmaster), and request info on how they should be configured.
The new employer does things very differently — they primarily use Ansible, which works on a “push” model. When you need to make a configuration change, you actively tell the servers what changes to make and what actions to take.
Is one right and the other wrong? Of course not. But they’re very different, both have ups and downs.
The “pull” model (as Puppet implements it) is pretty much automatic. The Puppet agent phones home on a schedule, and downloads updated configs. You don’t have to think too much about it, just set and forget. That also can be a downside, in that changes will be picked up pretty quickly by your servers. A mistake could propagate pretty quickly. (There are ways to mitigate this, but if you’re new to Puppet these pitfalls and their workarounds may not be obvious.) I’ll admit that I got spoiled by the notion of letting things happen in the background, and just checking in on them later.
Ansible’s “push” model means that changes only go to the specific devices to which you send them. This is done by way of playbooks, files that specify your desired configuration. If you only want to make a change on a subset of servers, it’s a bit easier. But this can lead to configuration drift, because unless you regularly run all your Ansible playbooks against all of your servers, different groups of servers in your environment can have wildly varying versions of things.
Puppet isn’t a good choice for initially building a server, because you have to somehow bootstrap the configuration. (It can’t phone in until it knows where and how to do so.) And Ansible isn’t always the best choice for ongoing validation because of the aforementioned drift, and because YAML is so annoying and picky about spaces. But they’re both valuable tools for ongoing management.
After ten years at WashU, I’ve moved on to Pagely. It’s been a long time since I was so overwhelmed. Honestly, I feel a bit dumb, in the best possible sense of the word.
I’m proud of the work I did at WashU. They hired me to be “the WordPress guy,” and over time I built up a platform that was efficient, resilient, highly available. The main bottleneck was the “I” in that first sentence. Especially in the first year or two, there wasn’t a lot of not-Windows experience around, and most of the design decisions that I made were inherently limited by my own knowledge and skillset at the time.
Pagely is larger than WashU, in terms of the volume of traffic on their WordPress sites. As I write this, their home page lists clients including Disney, Cisco, and WB. They only started a couple years before I started at WashU, but they had the benefits of being a “they” — a group of smart people are going to generate better ideas than any one smart person can alone.
Obviously, some of the complexity is a matter of scale. The WashU environment I built effectively only had one customer (WashU itself), and only hosts a few hundred sites. Pagely has more customers than that, and many of them are bigger than WashU’s biggest sites. And they have to worry about things like “getting paid,” whereas being internal-only saves a lot of paperwork. But in the past week and a half, I think I’ve learned more about how to host WordPress sites at scale than I did in the ten years previous. I’m being exposed to so many new-to-me technologies and ideas. I feel overwhelmed and a bit stupid, and I’m fighting my fair share of impostor syndrome this week. But it will pass, and I’ll learn All. The. Things. and it will be great.
Clear Linux has Big Slackware Energy, in that if you want to use it as a daily driver, you’ll need to know your way around the underlying software. That said, I don’t think that’s how you’re supposed to use it (despite what that one Phoronix post might have you believe). It really feels purpose-built for connecting to cloud-init or Ansible or something like that, for machines you’ll spin up then throw away tomorrow afternoon.
Things I’ve learned while tinkering with Intel’s new Clear Linux distribution. Will probably get updated from time to time, unless I get bored.
Checking for updates: sudo swupd update
Installing a new bundle (their version of a package group): sudo swupd bundle-add bundlename
Bundles you’ll probably want for general tinkering: dev-utils, tmux
Bundles you might want if you want a traditional GUI experience: desktop (GNOME) or maybe os-utils-gui (a basic xfce desktop)
Growing the hard disk (probably needed if you want to install GNOME on a VM): see this (basically, grow it the VM-specific way, install the storage-utils bundle, use parted and resize2fs to actually use the new space)
While Windows Subsystem for Linux (WSL) isn’t perfect, it’s coming along nicely as a replacement for many of the Unix-y things I used to do with Cygwin. And since most of my server work involves Linux as opposed to generic *nix, it’s nice to have handy access to something that more closely resembles my work environment.
Just a few days ago, the Debian project announced “Buster,” the first major upgrade in a couple years. (If you want to be boring, it’s also “Debian 10.0”.) As of this writing, the Microsoft app store doesn’t have Buster ready-to-go. And even if it did, there’s not a super-clean way to migrate any custom work, home directories, etc. from an old Debian installation to a new one. So here, I throw caution to the wind and update my existing Debian WSL installation from “Stretch” (9.x) to Buster.