Hi. Has Puppet been used as deployment tool for application installations and upgrades? From searching the web, I found the ControlTier site, which actually places Puppet in the software configuration level, while leaving the app deployment for itself, Capistrano and some other tools: http://blog.controltier.com/2009/04/new-whitepaper-achieving-fully.html Is this the recommended and general practice, or I can get away by using only Puppet (which I, frankly, prefer). Thanks. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
You can easily get away with only using puppet IF you don''t have cross-system dependencies. If you have cross-system dependencies, it can still be done, but it gets hairy. Example: Web server A should not be turned on until database B is active. Trevor On Mon, Jan 11, 2010 at 8:24 AM, SyRenity <stas.oskin@gmail.com> wrote:> Hi. > > Has Puppet been used as deployment tool for application installations > and upgrades? > > > From searching the web, I found the ControlTier site, which actually > places Puppet in the software configuration level, while leaving the > app deployment for itself, Capistrano and some other tools: > > http://blog.controltier.com/2009/04/new-whitepaper-achieving-fully.html > > > Is this the recommended and general practice, or I can get away by > using only Puppet (which I, frankly, prefer). > > Thanks. > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > > > >-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 1/11/10 5:24 AM, SyRenity wrote:> Hi. > > Has Puppet been used as deployment tool for application installations > and upgrades? >I highly suggest you leave Puppet to what it does best - managing resources (files, packages, users, mounts, etc.). -scott -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hi.> If you have cross-system dependencies, it can still be done, but it gets hairy. > > Example: > > Web server A should not be turned on until database B is active.Unfortunately I do have such dependencies. What tool would require the least dependencies on managed machines, and would be the easiest to learn? Thanks again. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hi.> I highly suggest you leave Puppet to what it does best - managing resources (files, packages, users, > mounts, etc.).But application can be also considered as a resource - it has files, packages and settings. Or there is some clear difference between system components and the custom applications? Regards. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Then, Puppet + ControlTier is a pretty safe bet. If you want to do it all Puppet then you''ll need to figure out how to do cross-system semaphores or something like that. Alternatively, you can just re-write your app initialization scripts to check for the resources themselves. This was what I generally did back in the early 90''s with great success. This way all of your systems are self controlled instead of relying on an external brain. Then you could do everything with Puppet again. Trevor On Mon, Jan 11, 2010 at 10:44 AM, SyRenity <stas.oskin@gmail.com> wrote:> Hi. > >> If you have cross-system dependencies, it can still be done, but it gets hairy. >> >> Example: >> >> Web server A should not be turned on until database B is active. > > Unfortunately I do have such dependencies. > > What tool would require the least dependencies on managed machines, > and would be the easiest to learn? > > Thanks again. > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > > > >-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 1/11/10 7:46 AM, SyRenity wrote:> But application can be also considered as a resource - it has files, > packages and settings. >No, an application may be composed of resources. Puppet is perfectly capable of managing them, yes. But the deliberate *deployment* of live software in a dynamic fashion is different. - How do you manage killing database connections before restarting an application after you''ve pushed the new code? - How do you manage failing over load balancer VIPs and taking servers in and out of service? - What if deploying one application requires restarting or updating configs on another application? etc. These things are key aspects of proper software deployment. Puppet isn''t the best tool for handling them. And that''s OK, it''s good to split functionality between different software.> Or there is some clear difference between system components and the > custom applications? >Yep, exactly. -scott -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 1/11/10 7:44 AM, SyRenity wrote:> Unfortunately I do have such dependencies. > > What tool would require the least dependencies on managed machines, > and would be the easiest to learn? >Check out Capistrano or Vlad (I prefer Vlad). http://www.capify.org/index.php/Capistrano http://rubyhitsquad.com/Vlad_the_Deployer.html -scott -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hi.> > Check out Capistrano or Vlad (I prefer Vlad). > > http://www.capify.org/index.php/Capistrano > > http://rubyhitsquad.com/Vlad_the_Deployer.htmlThanks. These 2 seems to be mostly Ruby/ROR oriented - any of them working with Java/C++ apps, or my best bet still the ControlTier? Regards. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
SyRenity wrote:> Thanks. These 2 seems to be mostly Ruby/ROR oriented - any of them > working with Java/C++ apps, or my best bet still the ControlTier? > > Regards. >Control Tier uses capistrano. -scott -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
2010/1/11 SyRenity <stas.oskin@gmail.com>:> Hi. > >> >> Check out Capistrano or Vlad (I prefer Vlad). >> >> http://www.capify.org/index.php/Capistrano >> >> http://rubyhitsquad.com/Vlad_the_Deployer.html > > > Thanks. These 2 seems to be mostly Ruby/ROR oriented - any of them > working with Java/C++ apps, or my best bet still the ControlTier?I haven''t used Vlad but Capistrano can be used for Java app deployment. Out of the box Capistrano is configured for deploying Rails apps but you can configure it for other kinds of app. http://code.google.com/p/bungeni-dspace/wiki/InstallingDspaceUsingCapistrano http://github.com/leehambley/railsless-deploy/> > Regards. > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > > > >-- Julian Simpson Software Build and Deployment http://www.build-doctor.com http://twitter.com/builddoctor -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
I find that there are two problems when trying to use puppet for application deployment. 1. Latency 2. Intersystem dependencies Latency : I cannot count on puppet to do what I want it to do in a low latency fashion. Puppetrun can address the issue, but I cannot specify an order of operations etc.. plus I have to verify that the application has completed its roll out which mean taking a look at a report. Intersystem dependencies: I think this was addressed in a later thread, but I haven''t found an easy way of specifying "check db on server[1] is at this version before running rpms on servers [5-100]", or better still "update db on server 1 before executing package installations on servers [5-100] ". I find that tools like capistrano, func, and pssh address these two issues better; i know that something has run, and can immediately address any issues as the bubble up. They aren''t persistent like puppet, which makes them difficult to use when verifying configurations a week later. Also, they have implicit dependencies unlike puppet(it executes from step a->z because a comes before b, etc...), which makes writing a deployment script easier. //geoff On Mon, Jan 11, 2010 at 7:46 AM, SyRenity <stas.oskin@gmail.com> wrote:> Hi. > >> I highly suggest you leave Puppet to what it does best - managing resources (files, packages, users, >> mounts, etc.). > > > But application can be also considered as a resource - it has files, > packages and settings. > > Or there is some clear difference between system components and the > custom applications? > > Regards. > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > > > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
I''m finding this discussion interesting and... depressing, as I''m trying to model an enviroment where our #1 task is to deploy Java web apps on tomcat servers. Is there any already existant documentation/resource discussing this? The 2 objections listed are interesting, even if my enviroment usually does not have the second, the first mean that I will have a difficult time deploying on one leg and then on the other leg using Puppet, right? As in, I''m not going to know if it is being deployed on both at the same time, causing an outage, unless I do some kind of hack (change the resource in one node, then in the other...) I''m correct? Are those arguments explained in detail somewhere? ------------------------------ Jesús Couto F. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Probably a brainfart, but:
This scenario is typical and would suggest the requirement of database
resource. And this would be just enough.
Hypothetical example:
On the db machine you will have a resource like:
database
{ "mydb":
ensure => 34,
versionscript => "puppet:///modules/myapp/db_getversion.sql",
installscript => "puppet://...",
updatescript => "puppet:///...."
server => "db-serv.example.com",
username => "....",
.....
}
Now the ensure would be the required installed version of the db, or
simply true. Version script should return the current version of the db
when run. Install script creates the db, optional update updates the db
from a version to another.
The cool thing about this is that it can be added on the web app node
too as a check/dependency solver.
This or similar cases should be solvable with a similar solution.
What are your ideas about this?
Silviu
Jesús Couto wrote:> I''m finding this discussion interesting and... depressing, as
I''m
> trying to model an enviroment where our #1 task is to deploy Java web
> apps on tomcat servers.
>
> Is there any already existant documentation/resource discussing this?
> The 2 objections listed are interesting, even if my enviroment usually
> does not have the second, the first mean that I will have a difficult
> time deploying on one leg and then on the other leg using Puppet,
> right? As in, I''m not going to know if it is being deployed on
both at
> the same time, causing an outage, unless I do some kind of hack
> (change the resource in one node, then in the other...)
>
> I''m correct? Are those arguments explained in detail somewhere?
>
> ------------------------------
>
> Jesús Couto F.
>
> ------------------------------------------------------------------------
>
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
I studied CT a bit, and it seems to solve such tasks perfectly. I need much more on-hand experience of course. Regards. On Jan 12, 2:57 pm, Jesús Couto <jesus.co...@gmail.com> wrote:> I''m finding this discussion interesting and... depressing, as I''m trying to > model an enviroment where our #1 task is to deploy Java web apps on tomcat > servers. > > Is there any already existant documentation/resource discussing this? The 2 > objections listed are interesting, even if my enviroment usually does not > have the second, the first mean that I will have a difficult time deploying > on one leg and then on the other leg using Puppet, right? As in, I''m not > going to know if it is being deployed on both at the same time, causing an > outage, unless I do some kind of hack (change the resource in one node, then > in the other...) > > I''m correct? Are those arguments explained in detail somewhere? > > ------------------------------ > > Jesús Couto F.-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 1/12/10 10:23 PM, Silviu Paragina wrote:> Probably a brainfart, but: > This scenario is typical and would suggest the requirement of database > resource. And this would be just enough. >Interesting idea, but it can''t handle complex schema changes. Usually these are not "set it and forget it" operations. Another issue: handling sensitive data that needs to be deployed to servers. Passphrases, encrypted file stores, etc. Most software deployment tasks should be handled by something else. Read this: http://dev2ops.org/blog/2009/11/2/6-months-in-fully-automated-provisioning-revisited.html There is a reason "Command and Control" is seperate from "Compliance and Remediation" -scott -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Just as a point of clarification, ControlTier does not use Capistrano though there is a bit of conceptual similarity around the notion of "command dispatching". On Jan 11, 10:27 am, Scott Smith <sc...@ohlol.net> wrote:> SyRenity wrote: > > Thanks. These 2 seems to be mostly Ruby/ROR oriented - any of them > > working with Java/C++ apps, or my best bet still the ControlTier? > > > Regards. > > Control Tier uses capistrano. > > -scott-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 1/14/10 11:36 AM, Alex-SF wrote:> Just as a point of clarification, ControlTier does not use Capistrano > though there is a bit of conceptual similarity around the notion of > "command dispatching". >You''re right, as much as I read somehow I misunderstood that. Speaking of, how many people on the list have experience with it? -scott -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Resurrecting this a bit... I have to check those tools (ControlTier, Capistrano), but a more higher level question: does this mean those tools sit on top of Puppet or other System Configuration Tool, doing changes to Puppet manifiests, or simply that one assumes a System Configuration Tool to keep the "system" (defined as ... dunno, everything but the applications? Packages, services, disks, etc) managed and then uses a separate language/model to deal with the particularities of web applications? ------------------------------ Jesús Couto F. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> Resurrecting this a bit... I have to check those tools (ControlTier, > Capistrano), but a more higher level question: does this mean those tools > sit on top of Puppet or other System Configuration Tool, doing changes to > Puppet manifiests, or simply that one assumes a System Configuration Tool to > keep the "system" (defined as ... dunno, everything but the applications? > Packages, services, disks, etc) managed and then uses a separate > language/model to deal with the particularities of web applications?I tried making the app responsible for declaring its immediate dependencies. Obviously you''re going to need to have middleware etc. on the systems before you start app deployment. But if the app knows some of the gory detail, I think that''s good. http://www.build-doctor.com/2009/12/09/dependency-hell/ -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.