hey, if you dont use cross aws/datacenter and only aws i would recommend to use use ops-works.. its chef based but for aws only its quite nice
> On Sunday, May 25, 2014 11:21:20 AM UTC-7, Jakov Sosic wrote: > > Can you somehow get list of active nodes from balancer? You could use > that list in a daily cron to do a 'puppet cert clean' and remove all > other certificates? > > I can get a list of active nodes in the constellation, the instances > in the constellation have a constant embedded in the instance name > that tells which constellation they belong to. That's how my Nagios > instance works after all -- it queries AWS for the list of active > nodes and reconfigures Nagios to look at the active nodes. Otherwise > Nagios would be completely out of date after the first scaling event. > I'm somewhat reluctant to embed AWS credentials into the puppetmaster > though. The other thing that someone mentioned in another forum was to > look for nodes reporting in the reports directory, and if a node > hasn't reported for over an hour (mine are checking in every twenty > minutes at a minimum so should have checked in by then) to do a > 'puppet cert clean' on that node and then a 'puppet > certificate_revocation_list destroy' just in case it comes back to > life and checks in again. The other thing mentioned has been to change > the hostname of the instances as part of their cloud_init stage to add > the instance ID as well as the IP address as the hostname. That would > actually work fairly well, I suspect, since the chance of both > instance ID *and* the IP address being reused for the same instance > are pretty much non-existent, and also gives me more information on my > Splunk server about what Splunk event applies to what instance,but > will require a lot of time to debug on my part because the only way to > debug it is to run Cloudformation time... after... time... after... > time... creating and destroying constellations until I get it right. > > I don't want to go to master-less configuration because I tweak > constellations before rolling them into production, and it's easier to > do that via a configuration master. For example, new constellations > start out pointed at a testing database, and one of the things that > happens when they're moved into production is that they get re-pointed > at the production database. I might try migrating to a different > configuration tool such as Chef in the future, but I have limited time > to devote to this project. So right now the priority is just forcing > Puppet to work the way it needs to work in the cloud, rather than the > way the Puppet authors believe it should work, which is completely > incompatible with cloud ops. > > -- > 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 puppet-users+unsubscr...@googlegroups.com > <mailto:puppet-users+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/80ef1916-4434-4405-a357-62345d111618%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-users/80ef1916-4434-4405-a357-62345d111618%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout. -- 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/5384C4BA.9070704%40gmail.com. For more options, visit https://groups.google.com/d/optout.
