VADOSWARE

tl;dr - I’ve been doing a lot of work with SQLite lately, using it in one of my projects to try and test it’s limits before I moved to something like Postgres. I wanted to scale the API up and after ensuring that SQLite was thread safe and parallel access safe, I tried but was limited by shared file system mode limitations of my platform (kubernetes). This post details some prior art (rqlite, dqlite) and what I want to make for distributing SQLite, which is expressly not what SQLite is for but seems like it would be fun.

tl;dr - After a bad kernel upgrade (pacman -sYu) on my Arch-powered server I decided to go back to Container Linux, after being equal parts annoyed by Arch and encouraged by the Press release put out by red hat. This time, I spent much more time with the Ignition config files in conjunction with kubeadm and ended up with a bootable master node. Feel free to check out the tldr at the end.

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.

WARNING - This is a opinion-based fluff piece, read at your own risk. There’s no technical writeup or deep technical insight to be gained in this article, if ever there was in any of my posts to begin with. tl;dr - the cure for impostor syndrome is growing the amount of slow, hard-fought knowledge you have in a given area. Don’t over-sell how much you know, don’t under-sell it. If you’ve actually read the documentation and/or code for a project, used a piece of code/methodology before in a relevant context, worked through problems with it, you have a certain amount of valuable expertise, even if you are not an expert – being an “expert” is only a matter of how much expertise you possess, and the cutoffs are endlessly subjective.

tl/dr; an update (sudo pacman -Syu) to a server I manage running Arch messed up the boot process of my server, due to interaction between RAID and GRUB, and I stumbled my way through debugging it. WARNING If you find yourself with this problem, make sure to read all the way to the end, because I take some steps that I think made things worse half way through (in particular running grub-install and in-effect wiping out boot)

tl;dr - I spent a bunch of time stumbling through getting kim/opentracing integrated into my small Servant powered web app. In the end I actually switched to servant-tracing due to some issues integrating, and was able to get it working – there’s a TON of wandering in this post (basically half the time you’re reading an approximation of my stream of consciousness, some might consider the experiments with kim/opentracing a waste of time, but I do not), so please check out the tldr section for the working code that uses servant-tracing (somewhat specialized to my app structure).

tl;dr - I switched from Jetstack’s kube-lego to cert-manager (it’s natural successor), and am pretty happy with the operator pattern they’ve decided to adopt, switch over was easy, but I tripped myself up for a bit because I don’t like using Helm. Complete resource definitions (that worked for me, YMMV) are in the TLDR section @ the bottom. I’m taking a break from my regularly scheduled programming (I’m in the middle of a series on trying out monitoring/observability tools/frameworks in Kubernetes) to write about my switch from jetstack/kube-lego to jetstack/cert-manager.

I’m taking a break from my regularly scheduled programming (I’m in the middle of a Series on trying out monitoring/observability tools/frameworks) to discuss a tool that I recently came across that is super useful and was a delight to use: MailCatcher. UPDATE (10/04/2018) I found a nice and light mailcatcher docker container jeanberu/mailcatcher, so you don't have to dirty your own local ruby gems! MailCatcher's Logo I recently completely rewrote a component I’m using for email templating and sending in a web application I’m currently working on to use ginger over HStringTemplate.

tl;dr - I started trying to set up EFK (Elastic, FluentD, Kibana), and hit frustrating integration issues/bugs with Elastic+Kibana 6.x, tripped myself up a LOT, almost gave up and went with Graylog, but then rallied to finish setting everything up by basically fixing my own bad configuration. Skip to the TLDR section for the hand-written working k8s configuration. This is Part 2 in a series of blog posts where I seek to increase observability on my single-node Kubernetes cluster.

It’s been a while since I learned of the wonders (and cleared up my misconceptions) of dedicated hosting and set up a “Baremetal” CoreOS single-node k8s cluster. For a while now I’ve maintained a single large (by my standards) machine that has been running Kubernetes, and purring right along – outside of the occasional restart or operator error, it hasn’t gone down and has kept my applications running. While most of the applications don’t get much traffic (as most are projects that haven’t launched), it does keep up some more important things like my mail servers for some domains I hold.