At the moment, in Wiki Cafe, we use Coop Cloud tooling to run all of our applications. Coop Cloud’s recipes and CLI tool called abra are tools that help you self-host web applications easily without having to grok Docker Swarm. The recipes give you all the files you need to deploy applications with sane out-of-the-box configs. You can then use abra to deploy what the recipes describe. Easy.

The cool thing about abra —and why it might be better to start off with abra—is that it forces you to use best practices for deployments while making it easier to do so. With abra, we are managing secrets, configs, environment variables, volumes, images, in ways that seasoned Docker users would, all without having to first read every page in the docker documentation site or the entire compose specification.

While abra has been extremely helpful in getting us up and running and has influenced the way in which we think about infrastructure, I think it is time for us to stop using the training wheels. Abra, in its current form, does not fit our use case any longer. We need to use our own custom recipes, build our own images, possibly support multi-node deployments, and possibly many other things that abra was not built for.

Understanding the why of abra

When I was trying to understand why abra exists or how it works under the hood, I asked 3wc (from Autonomic) if they knew what were the “hacks” or features that abra implements. Here is what they responded with:

  • separation of recipe definition from per-app config, via the above “env file” hack - which is otherwise almost impossible with swarm, and which allows easy version control of both
  • versioning docker-swarm secrets and configs - both are immutable, and swarm gives you approximately zero support for obvious real-world requirements to update both. co-op cloud introduces the concept of a secret/config “version”, which basically ends up just being a suffix on the secret name but ends up allowing inspecting and rolling back to previous versions too
  • auto-generation of secrets, e.g. for internal database passwords, and ones based on length requirements, e.g. salt / nonce / SECRET_KEY values which many apps require
  • safety checks, e.g. with normal docker swarm it’s scarily easy to deploy one app to another stack name, docker stack deploy -c nextcloud.yml federatedwiki - whoops, your federated wiki app is gone, you’ve got 2 copies of your nextcloud app, unlucky
  • standardised format for defining backup/restore operations for each service (e.g. see backupbot labels in the fedwiki / nextcloud services)
  • simpler, more consistent UI for people who aren’t grizzled docker veterans - the docker cli has grown organically over time, and in practice it seems hard to remember if you need docker stack / docker service / docker volume etc as the prefix for commands

Supporting Coop Cloud

While we are not going to continue using abra, we highly recommend it for self-hosting beginners. We plan to continue contributing to the recipes and plan to continue giving feedback to the Coop Cloud community.

Personally, I’d love to have more time to put into abra. I think Coop Cloud is trying to do for Docker what Helm does for Kubernetes; Something very worthwhile. At the moment, given my personal capacity, I don’t think I can contribute to the development of abra as I am already spread a little too thin.