ABOUT DOCKA

Docka

Applying configurations like it's the 21st century

Docka initially came to me in a dream. Very normal, very well-adjusted. Before that, I had to (yet again) kill Salt Stack on one of my hosts, because it started gobbling up 4 gigabytes of RAM. Even earlier, I was tasked with writing a Puppet module at work in one of the weirdest DSLs I’ve had the displeasure of using so far. And even earlier again, I had to run a rat’s nest of 20,000 lines of Ansible playbook. It was clearly enough to stay in memory, and it was also annoying enough to haunt my dreams.

The name

Docka is the Swedish word for puppet. Of the available names, it was also the least confusing. Sure, I could’ve opted for snimirtzCA&DS, but that isn’t nearly as memorable. It’s short, pronounceable, and (most importantly) it had domains available.

What sets it apart

Docka comes “with batteries included”1. It’s not the do-everything machine; instead, at its core is a very simple idea: Apply the state from the repository. Since it’s a good idea to know how the servers are looking, it comes with a dashboard2. You don’t want secrets lying around on hosts.

Technologies

Docka itself is a runtime that fetches a repository, renders a host’s desired state, puts that into WebAssembly plugins, and sends you the diff of the system. As such it is more the glue between git, cue, and your host.


  1. now how many times have you read that in README.mds? ↩︎

  2. I am writing this in the present tense, despite 0 LoC of that dashboard existing. ↩︎