One thing we've been sorely lacking is a single way to refer and store configuration in the dokku world.

• Application-related plugins usually store their data in the app's git directory in /home/dokku
• The official datastores store their data (and mount information) in /var/lib/dokku/services/SERVICE/
• Community plugins use stuff like /home/dokku/.o_mysql
• Dokku-wide config is usually stored in /home/dokku

Because of all the random ways in which data can be stored, there isn't exactly a simple way to save the state of an existing dokku installation. You can very easily push the container images to a registry and have backups occur from datastores, but actual config? Fffft.

Our backup plugin has been more or less ignored in the 0.3.x line - totally my fault - and i think we need to start getting serious about this.

At one point, there was a note in a roadmap to store everything in a git directory. I think it's time we head down that road for 0.5.x.

generic spec

• Data should be stored in a directory such as /var/lib/dokku/config.
  • /var/lib/dokku/config/apps - stores application data. Each application should get it's own directory, corresponding to the application name.
  • /var/lib/dokku/config/plugins - stores plugin data. Each plugin should get it's own directory, corresponding to the plugin name.
• We should provide a new dokku-config binary that is aware of the above paths and can interact with them.
  • Apps will interface with it using the --app APP flag, and can perform general crud actions against their own config.
  • Plugins will interface with it using the --plugin PLUGIN flag. Ditto on crud actions
  • The binary is a generic key-value store, and will be capable of triggering hooks on actions. For instance, we might want to log access, or ensure all actions get saved to an external datastore (git!).
• The backup system will be retrofitted to only work with the above system. If you want a backup, you basically get a tar of that directory. Users that want a backup of datastores should interface with those datastores either directly or through their plugin interfaces.
  • The official datastores all have ways of backing up/restoring data, so this is not a problem. We also cover all major datastores.
• All dokku related files should be named with a DOKKU_ prefix. For instance, DOCKER_OPTIONS_* becomes DOKKU_DOCKER_OPTIONS*. Inconsistent config files conventions #2199

open questions

• Do we handle encryption? I don't think it's worth it.
• How do we handle stuff like nginx? Does the nginx include path just change here?
• Should we serialize the data somehow, to json maybe?
• How do we ensure that data doesn't get accidentally overwritten by a shitty plugin/app/user?
• What language should it be written in? Golang is the obvious one to me, though handling plugins in it is annoying.

@Flink @michaelshobbs thoughts?