Not quite the same, we have done completely hands-free deployments to cloud instances using `terraform`. Part of that automation was an additional tool we wrote, `replform`, which handles the automation of replication.
Like `terraform`, it is declarative, ie, you describe the desired end state in a configuration file (we normally stored it in a `git` repo), and it examines the current state, coming up with a "plan" for for the actions that need to be taken to achieve it (eg, create repman, configure replica, add agreements, perform initialization, etc.): https://github.com/bozemanpass/replform While it can be run "globally" to configure all the replication partners in one swoop, when using it with `terraform` we normally have run as the last step of the initial setup, and then frequently as cronjob, in both cases only making changes to the local server. That way each server is responsible for only its end of the bargain as instances are added or removed, which would limit the damage if a bad configuration change were pushed. Again, while this was all using terraformed VMs, there would be a substantial amount of overlap when using containers. _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
