I recently posted about my experience with k3s and how I’m now using it to run my blog. I also mentioned my blog’s new domain and how I’m keeping the old name working. That involved changing the Ingress resource for my blog, so I’ll show how I updated it to accept the old domains and automatically redirect to my preferred domain without needing to make WordPress itself do any redirecting.
It has been a while since I last posted, but between college, work, and kids, I’ve been pretty busy. That said, I recently attended KubeCon 2019 and saw a lot of interesting presentations. As a fan of Rancher, I gravitated toward a lot of their talks. One that really caught my attention was Darren Shepherd’s talk on k3s. I really liked what I saw; it made setting up Kubernetes really easy, lightened the dependency load for small clusters, but still is very much the right amount of “batteries included” like most things made by Rancher.
I decided to move my home server (which runs, among other things, this blog) to k3s. Here, I’ll walk through how I did it — at least specifically for running a WordPress blog — just to demonstrate how easy it is. Fair warning though, there is a lot of YAML ahead!
There are lots of good reasons for and articles recommending running Docker containers read-only, but what I have a difficult time finding are descriptions of how to do this for many popular images. Some software needs to write to a few important and predictable locations. It surprises me how often image providers neglect to offer instructions or details required to run their image this way.
Even setting aside read-only containers, counting on writing to the writable layer just feels wrong. Per the documentation, for the writable layer, both read and write speeds are lower because of the copy-on-write/overlay process through the storage driver. In my experience,
docker diff output means I haven’t taken the time to configure my volume declarations, either through tmpfs mounts, volumes, or bind mounts.
In yet another exciting move for my blog, I’ve switched SSL providers from my previous provider to Let’s Encrypt. I’ve done so using a set of Docker containers, which also helped me move this WordPress blog to Docker as well. Now my blog is faster, encrypted for free, and easier to backup and maintain. I’ll probably post a brief article soon about how I set this up in more detail (including some
docker-compose.yml snippets) soon.
Throughout my career, I’ve seen a couple recurring patterns related to the tools I write: I write a lot of small CLI tools and I like to share them with my coworkers (and whenever possible, the rest of the world).
This has led to several iterations of solving the problem How do I make this tool easy to run? since I don’t want to burden people with understanding the intricacies of all my tools’ dependencies. These tend to be Ruby, some number of gems, and possibly some other common unix utilities. The solutions I’ve come up with have included a lengthy README with detailed instructions, Bundler with Rake tasks to do all the heavy lifting for non-Ruby things, fpm, and even “curl bash piping” (yes, I’m horrible).
Recently I decided to use Docker to solve this problem, since I’m using it so much anyway. Using Docker has some huge benefits for sharing applications of all types: the dependencies list gets whittled down to just Docker, things work on more platforms, testing gets simpler, and it is the new hotness which makes people say “whoa” and that’s fun. That said, the downsides can be frustrating: working with files on your machine gets messy, more typing with the extra Docker-related preamble, things are less straightforward and clear, simple mistakes can lead to lots of images and containers to clean up, and the executable gets significantly larger (since the Docker image is a whole, albeit lightweight, OS userland to run the app). After weighing these pros and cons, I’ve found that telling a coworker to
docker pull registry.url/my/app and run it with
--help is so much more convenient than the alternatives.
At work, I’ve been working on a lot of automation lately and I ran into a seemingly simple problem that ended up being a bit more complicated than I had first imagined. I have been collaborating on a project that we’re using for auditing Active Directory users and groups and tracking changes to those groups via some simple automation. While that project is interesting in its own right, my boss and I agreed that tackling another helpful automation problem would help our entire IT team: determining if user accounts are locked. I’ve been pushing #ChatOps hard at work through Lita, so adding a plugin for our bot to work with Active Directory seemed only logical.
Context out of the way, making Ruby work with LDAP is a solved problem, many times over. Thankfully, Active Directory exposes most everything you’d want via LDAP, so with a few helper methods, building a few objects tailored to this task was easy work. We quickly discovered that each Active Directory user has a handy attribute called
lockoutTime, and even some helpful hints via the interwebs that we just need to check if that value is
0 (meaning the user isn’t locked out) or any other value (indicating, naturally, that they are locked out). Well, this would be a pretty crappy blog post if that was the end, but it wasn’t.
Continue reading Check for locked out Active Directory user via Ruby
Thanks to the good people at SSls.com, my blog is now more secure than ever! And for only about $15… for a three-year cert! I’m not sure how they’re doing it, but I encourage anyone looking for an SSL certificate to check them out. Note that I am in no way affiliated with (and sadly not being paid to advertise for) SSLs.com. Along with this move to SSL, I have relocated this blog to an LXC container running on Ubuntu since the FreeBSD jail I was using couldn’t quite keep up with the demand (to be fair, I’m pretty sure that machine is plenty busy even without my tiny blog).