For pure-cluster pattern, I have to deploy all at once first, then put the config on all the systems. For load balancer + web nodes, the eventual convergence with puppetdb (poor person's service discovery) would work, but clusters are all or nothing deal, eventual convergence would set off alarms.
I am looking into roles/profiles w/ hiera (now roles/profiles w/ hiera + control repo), and trying to read up on this (and usign r10k). It's a bit daunting starting out. I was wondering about these possibilities (if they are possibilities): (1) custom or external facts, command line, or ruby class, (2) ENC to pass in values, which reads current cloud config (gcp or aws) or local vagrant settings for dev, which can pass these values to the class. Bolt has me curious. I have dabbled around with it, running commands or a script to a remote node. Are there other ways I could use this? Could I use it to introduce custom facts, or inject values into puppetdb? hiera? The docs are not all that intuitive (had to step through gem source code to discern how to use ssh transport for my environment). On Monday, April 30, 2018 at 5:19:08 AM UTC-7, Thomas Müller wrote: > > > > Am Samstag, 28. April 2018 03:31:24 UTC+2 schrieb Joaquin Menchaca: >> >> Hello Puppeteers, >> >> Relearning Puppet (converting Ansible, Chef knowledge), not sure best >> approach for this. How can I configure systems based on state of another >> system? Essentially, I would use a tool like Terraform to bring up >> systems. When their IP addresses are available, I would then use that >> information (their IP address) to configure other systems. >> >> I have two simple use cases: >> >> 1. local repository, and if up and available, want to configure all >> clients, e.g. java clients, to use this system (such as /etc/hosts with >> download.oracle.com) >> 2. elastic search cluster where the elasticsearch.yml has ip >> addresses of all nodes within the cluster. >> >> you could report to puppetdb and query it in your manifests (puppet pql) > . but this introduces a circular dependency as you need to run puppet > before having data in puppetdb - so this wouldn't configure your cluster in > the first run. And if you have many severs which need ip adresses of the > other servers then different puppet runs will produce different config > files and maybe restart the service often. I personally would not do it. > > Another way is to use the roles/profiles pattern with hiera integrated > into the environment or module and add the data to hiera. But it requires > that you know your ip addresses (or dns names) before the deployment and > that you're able to release code to a puppet environment as you need it. > > Or you could take a look at bolt/puppet tasks, or if you're on PE then > there is the orchestrator (which i have not used). > > It really depends on how the state of your puppet infrastructure is. :-) > > > - Thomas > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/cdfaf0d1-8c64-4870-beee-7b1363bd716f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
