Re: [Puppet Users] Re: Coordinated application deployments
Why don't you use nodes groups or environments to prevent the second set of servers to be updated? Once validated on the first node group, you can easily deploy on the second set. -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Coordinated application deployments
Why don't you use nodes groups or environments to prevent the second set of servers to be updated? Once validated on the first node group, you can easily deploy on the second set. -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Coordinated application deployments
Sorry wrong thread *getting more coffee* -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Coordinated application deployments
On Tuesday, February 12, 2013 8:37:56 PM UTC-6, blalor wrote: I'd like to use Puppet for the last-mile deployment of our applications, starting from a bare VM and ending up with a server that is running a specific version of an application. We're using a Puppet master already, which I kind of feel is something of a problem: if I were just running puppet apply in standalone mode, I could be confident that a successful run resulted in the server being configured correctly. When using a puppet master, changes could be applied anytime between now and the next agent check-in. Well, no. If you run the puppet agent then your machine will be configured as directed by the master each time it checks in, and not any time in between. Moreover, it will check in immediately when you first start it. In fact, this really has little to do with running the agent as a daemon. Daemon mode just puts the responsibility on the agent to check in periodically, but each individual run is the same no matter how the agent is run. I don't like nondeterminism. :-) It's completely deterministic. With sufficient information you can predict precisely when each node will sync with the master, and therefore when any updated configuration the master may have for it will be applied. Moreover, if agent runs are automated on a schedule, then Puppet can ensure that your nodes' configurations get repaired if ever they are broken. I don't want to reinvent the wheel. How are other people solving this problem? In general, how do you roll out changes to managed systems in a controlled, deterministic fashion? Are there simpler solutions than MCollective? If by deterministic you mean immediate or synchronized for all clients, then your best bet is to push out the needed manifests and data to the nodes and trigger a puppet apply via whatever cluster control tool you favor. MCollective would be one option for such a tool. This is all more work to set up and monitor than a solution revolving around a puppetmaster. I urge you to consider whether and to what extent you really need to control when updated configuration is applied. Generally speaking, there are a lot of circumstances in which it is quite sufficient to have a predictable window in which you can rely on updates being applied, at least in terms of functionality and level of service. John -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Coordinated application deployments
There may be, but when we want to upgrade an application and minimize downtime, a well-defined window of a checkin period is not sufficient. For example, given 10 machines, we need to upgrade 5, validate them, then upgrade the remaining 5. The 5 being upgraded will get pulled out of the load balancer during the puppet run. If the upgrade is deemed a failure, the old version must be reinstated on those 5 machines. This is all possible with puppet, and it feels like the master/agent relationship is an impediment. -- Brian Lalor bla...@bravo5.org On Feb 13, 2013, at 4:09 PM, jcbollinger john.bollin...@stjude.org wrote: I urge you to consider whether and to what extent you really need to control when updated configuration is applied. Generally speaking, there are a lot of circumstances in which it is quite sufficient to have a predictable window in which you can rely on updates being applied, at least in terms of functionality and level of service. -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
