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. I don''t like nondeterminism. :-) 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? Thanks, Brian -- 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+unsubscribe@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.
You could just disable the puppet daemon on the node after setting it up and manually running puppet with --noop so you know what has changed before you apply it. On 13 February 2013 12:37, Brian Lalor <blalor@bravo5.org> 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. I don''t like nondeterminism. :-) > > 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? > > Thanks, > Brian > > -- > 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+unsubscribe@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. > > >-- 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+unsubscribe@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.
On Feb 12, 2013, at 10:16 PM, Peter Brown <rendhalver@gmail.com> wrote:> You could just disable the puppet daemon on the node after setting it up and manually running puppet with --noop so you know what has changed before you apply it.Ok, so that would keep it from checking in periodically but would still sync state with the master? That could work… -- 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+unsubscribe@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.
On 13 February 2013 13:24, Brian Lalor <blalor@bravo5.org> wrote:> On Feb 12, 2013, at 10:16 PM, Peter Brown <rendhalver@gmail.com> wrote: > > You could just disable the puppet daemon on the node after setting it up > and manually running puppet with --noop so you know what has changed before > you apply it. > > > Ok, so that would keep it from checking in periodically but would still > sync state with the master? That could work… >Correct. It would only sync when you ran puppet manually. --> 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+unsubscribe@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. > > >-- 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+unsubscribe@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.
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+unsubscribe@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.
Brian Lalor
2013-Feb-13 22:11 UTC
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 blalor@bravo5.org On Feb 13, 2013, at 4:09 PM, jcbollinger <John.Bollinger@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+unsubscribe@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.
jcbollinger
2013-Feb-15 16:19 UTC
Re: [Puppet Users] Re: Coordinated application deployments
On Wednesday, February 13, 2013 4:11:40 PM UTC-6, blalor wrote:> > 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. > >Perhaps it is. I already gave you a suggestion for how to operate without the master. Do be aware, however, that when the agent is running in daemon mode, you can trigger it to check in with the master immediately by sending it a SIGUSR1. You can roll your own mechanism for doing that, or I think MCollective knows how to do it. Whether running the agent daemon or not, you should also be able run the agent manually as long as a run is not already in progress. The gotcha there is that if you trigger several agents at the same time, then the master needs to have the capacity to handle all their requests. If you are running the master in apache/passenger, then five simultaneous requests should not be a problem. Furthermore, if you are running under a master then you can track success / failure of the agent runs in one place by configuring the agents to send reports to the master; otherwise you have to roll your own mechanism for collecting that data. I''m not trying to tell you that you need to use a master, but I do think you would be wise to make your decision based on a true characterization of how the master and agent work, and of what they can (and can''t) do for you. Some of your comments make me think you are working under some misapprehensions there, and perhaps without all the relevant information. 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+unsubscribe@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.
Benoit BARTHELEMY
2013-Feb-18 19:45 UTC
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+unsubscribe@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.
Benoit BARTHELEMY
2013-Feb-18 19:45 UTC
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+unsubscribe@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.
Benoit BARTHELEMY
2013-Feb-18 19:48 UTC
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+unsubscribe@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.