On 18 Jun 2019, at 22:25, Thomas Lackey
<telackey(a)bozemanpass.com> wrote:
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.
I have heard of someone in Australia who did something similar with terraform. I can not
remember their git repo though. It sounds very interesting though!
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs