On Docker Databases and Nixos

Configuration is a rather big part of what systems administrator(DevOps engineer for the cool kids) does, one must correctly configure a program, most of the time dynamically. And because this is such an important thing, it baffles me, why 90% of all containers primarily use and support environment variables. I get that it's a convenient way to do it, it's simple widely supported, uniform, all around great, but really cumbersome. Say your config file looks like this:

# stripped down Gitea configuration, I kept the parts that nicely illustrate my point
[server]
APP_DATA_PATH    = /data/gitea
ROOT_URL         = https://gitea.redalder.org/
DOMAIN           = gitea.redalder.org

[database]
DB_TYPE  = postgres
HOST     = database-postgres
NAME     = gitea

The config has two sections, server and database, each of these sections has n key-value pairs. This has structure, it has multiple layers and configuration files can get much, much more complex than that. Now, for the sake of argument, let's imagine that we want to "environment-ize" this config. The natural, and frankly only way to do this is to essentially flatten the config file, so we'd get something like this:

SERVER_APP_DATA_PATH="/data/gitea"
SERVER_ROOT_URL="https://gitea.redalder.org/"
SERVER_DOMAIN="gitea.redalder.org"

DATABASE_DB_TYPE="postgres"
DATABASE_HOST="database-postgres"
DATABASE_NAME="gitea"

Now, you might think that this is completely fine, even reasonable, but let me explain to you why that is horrible. First of, there is no imposed structure and structure is always good, nothing is preventing you from mixing the server and database sections and while a "good" admin should not do that, it's best if they don't even have the ability. Next depending on the parser, which parses this "configuration", you might encounter issues when you leave out "", some are better at this than others, but once again, it's an implicit rule, which is bad. I hope you're starting to understand the bigger picture, implicitness is bad, period. It introduces unnecessary mistakes that could have been avoided if just the computer yelled at you. So why not give it the option to do that?

Now, it's finally time to combine databases with configuration. What we get is an all out war between immutable, declarative environments holding stateful and infinitely changing data. You must make sure that your configuration gets applied only at first start, so you must keep state yourself! In a Docker container! Madness! Then comes the joy of updating the configuration. Say you give your user the option to specify the default authentication method (PostgreSQL), the user specifies that they want scram-sha-256, that's nice and all, so you apply it, but only on the first boot. Why? Because now that the value is in the config file, if the user changed it, you'd have to figure out if they changed it and then update the configuration file and that's really hard. The user might have gone into where they store the state for PostgreSQL and manually changed the config file, they might have even completely deleted your configuration and replaced it with their own? What should you do? Most Docker containers just take the easy way out and do as PostgreSQL does and I don't blame them, there is nothing really that you can do.

Similar to some good literature, this rant has gone full circle. We're back at the start, back on the topic of Nix. How can Nix save us? By removing unnecessary state. The mutable configuration file? Gone, it's immutable now. Not knowing whether a setting changed? Poof, gone too, Nix is fully declarative, which means it identifies everything by a sha256 hash in addition to its developer configured name. Nix also serves as a single point of truth, which means even if the user modifies the config files, they will be overwritten before they are used again. This makes mix ups are impossible. Messy and flat "configuration" files? Solved too, the Nix expression language can be as flat or as deep as you need it to be, you can create complex APIs with functions and all that jazz. Basically Nix is awesome!

The take-away from this rant, is that the best course of action is to figure out either how to completely replace Docker and all the other container runtimes with something based on Nix, but since I'm a realist, I propose another possible solution. We must get Nix to nicely work with Docker, so instead of clumsy environment variables, you'd write your configuration in the form of Nix expressions and build a new docker image based on one common base. This ensure that all configuration would be properly hashed and declarative, while allowing for much more complex config files than environment variables or even templates.