Containerized Dotfiles #6
Description
Pros
Modern workflow:
- Cross Platform - either fully cross platform in the container, or greatly eased development of native cross platform configurations
- Setup fragility - though my goal has always been to fully automate the setup of a new machine, any they work well for reinstalling the same machine, they've never fully survived a switch of hardware or OS without some changes.
- limited host pollution. Docker itself is a heavy dependency, but it's the only one. Conventional dotfiles tend to leak their dependencies into all nooks and crannies of their host system, being virtually uninstallable
- Isolation from "install script drift": as a system is in use for longer and longer after having run the installation script, the installation script tends to be broken without noticing, even when you with unfailing discipline copy all installation commands you perform into the script after verifying they work on your existing system, it is basically never tested against a clean OS install again until you really need it. It's a backup without guarantees, basically setting up a backup harddrive without testing the restore process until the original crashes
- Dotfiles can run in CI
- Reproducible environment
- No risk of declaring OS bancruptcy - reinstalling the entire machine because you've screwed up paths and installed versions over each other beyond repair. Conventional dotfiles make hardware expendable, Dockerized dotfiles make hardware reliable.
Cons
- Build time (cache-busting apt on every build makes it a lot slower) citation needed
- Project dependencies (one of the pros of using a containerised development environment is not polluting the machine with dependencies. So where do those dependencies go? If all of your projects are also dockerized then it's not an issue, but when they aren't you basically have the following options:
- polluting your dotfile Dockerfile with the project dependencies
- take responsibility for dockerizing the project, this might be a good idea anyway, usually doesn't clutter the project much and doesn't interfere with other people's local installations, but if most of your projects aren't already dockerized and have complex setups, you're in for quite a time investment.
- make a custom dotfile image for that project, "FROM dotfiles" it and perform the local setup separated from your base dotfiles
- keep them locally on the machine, start the servers outside of docker entirely and enjoy at least running your setup and stuff in isolation. This might be a good 80/20 solution, you get most of the benefits of your setup, with very little effort if you've already got the stuff on your computer, and you usually don't interact much with servers running other than watching the logs and restarting them - you might be able to live with them being outside your containerised Tmux or i3 or whatever
- Performance?
- Fiddly Docker stuff: some things that are easily done native are tricky to get working in a docker container. Depending on the native terminal that you're interacting with the container through, you might have issues with Ctrl+Z...
Basically all cons are related to running the dotfiles fully inside a Docker container, which has its own set of hurdles. If you are going for simply improving reliability and reproducibility of you native setup, there are basically no downsides - the steps to set up are the same, the use case is different, but you are simply opting to keep your current set of drawbacks and only improving the setup you have. I highly recommend doing this.
Setup
- Use host SSH credentials
- Mount development folder
- Dogfood the dotfiles
- Run webservers from within container
- GNU Stow
- Install Docker in the container