Make backup-bot configuration separate from each app configuration #2
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
As mentioned in compose-stacks/wordpress#7 (comment):
In practice, this would mean we'd set it up something like https://git.autonomic.zone/autonomic-cooperative/renovate-bot where we have a separate repo with all the app connection details we want to do backups for are listed and then it runs on some fixed schedule. The main advantage of this then would be that it would live outside of the app configuration and can be easily re-worked and changed without altering the app configuration.
Think this is maybe not possible but I am not sure. It will require quite a deep dive into docker networking, it seems. Looks like the place to start digging is over in https://docs.docker.com/network/network-tutorial-overlay/. Basically, the bot, running independently in its own swarm service would need to peak out of that service scope and into other services (the ones it wants to backup). It would also need additional secret loading on a per-service basis. I am not sure how this would look in practice but it seems worth investigating because otherwise, we'll need to copy/pasta 20 lines into every application compose.yml.
Starting point is compose-stacks/wordpress#7 (comment) which shows a working backup-bot configuration and all the bells and whistles required to get it running.
Ooooor we just do this!
And then let the deploy take care of picking that up.
Much easier!
OK, re-opening because we discussed and it seems needed. I think we need a docker bridge network in the end following https://docs.docker.com/network/bridge/#differences-between-user-defined-bridges-and-the-default-bridge because "On a user-defined bridge network, containers can resolve each other by name or alias.". So, we'd need to make a user-defined bridge network that all apps sit on and then we could access mysql databases from isolated, one-time-run back-up containers run outside of the context of a stack/compose.yml. At least this is what I undestand now...