One of the natural consequences of using lightweight Docker hosts and running everything in containers is that I tend not to interact with the actual VM’s system as much. I SSH straight to a container for IRC, I do my kernel builds in containers, etc. With this, it’s made sense to strip out components out of the VM that were used solely for user interaction.

Some of those components were easy to identify and pull out:

• Stopped cloning my dotfiles and scripts repos to the VM image
• Removed packages like vim-minimal and zsh

But the big change I wanted to make was simplifying the init process itself.

Building on my previous work, I’ve been working to solve some pain points for deploying and managing VMs. There were a couple big ones that I specifically targetted:

1. Speed. It turns out that building a kernel and an Arch environment from scratch on each VM takes a long time.
2. In-place upgrades. All upgrades were full redeployments. Coupled with the speed problem, this got pretty annoying
3. Secure data. When all the data on the VM is generated on-site and sourced from public GitHub repos, passing secure data (think SSL keys or API keys) becomes problematic.

Thankfully, after some thought, I realized that these problems are all facets of what was, in hindsight, a poor design choice: generating the components on the VM itself. In round two, I set out to find a better route.

Linux containers have recently been in the spotlight, in no small part due to Docker’s work in providing a user-friendly interface to LXC. Lightweight containers allow us to reimagine how we handle deployments, separation of services, and infrastructure management. A system that can be spun up in seconds, configured on the fly, and spun down just as fast presents the next step in a trend begun by the virtual private server.

In a world where all the action happens inside containers, it seemed wasteful for the “host” system to be a full-service Linux system of its own. I went on a mission to strip down an Arch system as far as I could, to the point where I had a read-only system with only essential services from which to run Docker.

It’s pretty clear these days that {thing}-as-a-service is a powerful concept. That said, it involves a certain level of trust in whoever is providing the service. Part of that is the trust that they’ll keep providing you the service, but on the tin-foil-hat side, you trust that they won’t use the information you give them to your detriment. This is especially true for storage/hosting service providers, where you’re quite literally handing your data to a 3rd party.

I love Dropbox, but I’m not sure I’m ready to trust them with my secret plans for world domination. As such, I’ve decided that I’d like to add a layer of encryption on top of my Dropbox storage, as well as other similar providers. I looked around, and decided to work with Dropbox, Copy (Update: the Copy service has shut down), and Google Drive. As a disclaimer, the Dropbox link includes my referral code so I get extra space if you use it.