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.