Trying (and failing) to get LXD running on Container Linux
tl;dr - I tried to get LXD working on Container Linux but stopped short. Maybe if anyone picks it up (assuming the lxd team doesn’t tackle it eventually), they can learn from my failed effort. I’ve recently gotten pretty excited about the concept of running higher isolation paradigms (VMs, LXD) in my cluster for larger untrusted workloads. A lot of interest in those concepts has been generated by the idea in the back of my head of building (or at least figuring out how I would build) a system that could spin up mini Kubernetes clusters – like an EKS/AKS/GKE, but easily self-hostable.
Even faster rust builds in Gitlab CI
tl;dr - I applied a few patterns I’ve used on other projects to a Gitlab CI-powered rust project to achieve <2min builds. Basically just caching at different layers – caching via the docker image builder pattern at the docker level, aggressive caching with Gitlab CI at the CI runner level, also one more step of combining some build steps (probably unnecessarily). I recently became a proud rustacean, which is what developers who use the programming language rust call themselves.
Minimal effort build improvements and a GHC 8.2.2 upgrade
tl;dr - On a Haskell project I’m working on I started with >~20 minute cold-cache builds in the worst case in my Gitlab-powered CI environment then found some small ways to improve. Very recently I decided I wasn’t satisfied with ~10 / 15 minute builds and did the laziest, least-effort steps I could find to get to <10 minute cold-cache builds (~5min best case). Check out the [TLDR][tldr] section to see the Dockerfiles and steps I took summarized.
A reliable fix to Docker not keeping it's IPV4 address on Arch
tl;dr - Scroll to the bottom for the fix, if you’re having the problem, thanks to Garett L Ward for submitting the fix to me over email! This is a bit of a repost (since I’ve aleady gone into the fix in an update to the previous post), but I wanted to say it again for anyone who might find this on the internet. If you’re struggling with an issue similar to the one described in one of my previous posts regarding docker0 losing it’s IPV4 address all the time, here’s a quick recap of how I got it fixed, big thanks to Garrett for figuring this out and emailing me:
Switch From ployst/docker-letsencrypt to Jetstack's kube-lego
tl;dr - I switched from ployst/docker-letsencrypt which I considered less complicated than jetstack/kube-lego initially. Turns out jetstack/kube-lego is pretty simple and *just works* which is amazing, props to the team over at jetstack and as always the kubernetes team, for making this more intelligent automation possible. You could honestly just read the jetstack/kube-lego guide, it’s real good. If you wanna see my path through it, keep reading. Up until now I’ve been using ployst/docker-letsencrypt, and it’s been working fine, however I’ve longed for a solution that didn’t require me to manually kubectl exec scripts, and kube-lego is that tool.
Docker on Arch Linux - docker0 just doesn't seem to want it's IPv4 address
tl;dr - My setup of Docker on Arch Linux is having some issues, around docker0 not properly holding on to it’s IPV4 addresses (listed as inet in ip addr output). I originally though it was a problem with Alpine CDNs, but it was actually docker0 throwing up repeatedly. Short term work around I’ve found is to just create the missing link again, w/ sudo ip addr add 172.17.0.1/16 dev docker0.
Static Binaries for Haskell: A Convoluted Approach
tl;dr - After a bunch of trial and error, I end up building a mostly static binary from a docker container. With hindsight it was only “mostly” static because after trying to get sendmail working from haskell code, the getProtocolByName system call was failing, pointing to the fact that there were a bunch of libraries NOT included in the executable I thought was fully static (GHC warned me) that needed to be present in the same form in the deployment container.
Working with PDFs on Arch linux
Working with PDFs on arch linux tldr; If you’re on arch, not all hope is lost when trying to deal with PDFs. pdfunite is out there for combining PDFs, Firefox is surprisingly helpful since is uses pdf.js, pdftk is there if you’re down with downloading the dependencies, convert is available for paring down scanned images, and ultimately, any software you can run on ubuntu can run on arch with a little docker.
Using dockerized Ghost with local SMTP
Getting a dockerized instance of Ghost to use local SMTP When handling mail for a ghost instance, the official recommendation of the Ghost team is to use Mailgun. Since I have email set up on the server on which I’m running Ghost, despite the fact that Mailgun offers a pretty good free tier of services, it seems pretty extraneous/unnecessary to use mailgun just to send email from my own server.
Default docker settings on arch
Default Docker settings on ArchLinux RTFM. Seriously. The Arch Wiki is seriously one of the most informative wikis I’ve ever read, and has excellent guides. If I had read it closer, I would have avoided one problem I’m about to explain below. Change the default filesystem While running on a VPS, I ran into problems deleting containers that were once functional when I was using the default devicemapper driver. The fix for this was simple (and also in the arch manual), and basically consisted of changing the default file system driver to overlayfs.