"What are the problems this requirement is intended to solve?"
What I was told from my eng team is that tomcat's hot-deployment for our app will eventually break, so we want to always make sure tomcat is stop before the deployment, and starting up fresh. We will probably go with Doug's suggestion earlier and re-package our app and process via rpm directly. --KL From: puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com] On Behalf Of Nigel Kersten Sent: Friday, December 23, 2011 2:00 PM To: puppet-users@googlegroups.com Subject: Re: [Puppet Users] Recommendation for general practice for application deployment? On Tue, Dec 20, 2011 at 8:26 AM, Kenneth Lo <k...@paydiant.com<mailto:k...@paydiant.com>> wrote: Hi: I have a pretty general high-level question regarding application deployment using puppet infrastructure. Being new with puppet here we have a pretty simple module setup where we are utilizing a basic package-file-service combo for an tomcat application server, and with some additional war files for our apps. One of the engineering requirement regarding app deployment is to make sure tomcat shutdown cleanly before we move in with the new app war files. What are the problems this requirement is intended to solve? The way we handle new app release is via file resource that point to different puppet source based on the release tag. So the question is, given the service resource is also within the same module with the file, how do I make sure we can do the following sequentially?: 1. Shutdown the tomcat instance (service resource in tomcat module) 2. Update the application war file (file resource in tomcat module) 3. Start the tomcat instance We've been using mcollective to manually shutdown the service before applying puppet run, but I'm not sure if the sequence is correct. Thanks in advance. --KL This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. -- 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<mailto:puppet-users@googlegroups.com>. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com<mailto:puppet-users%2bunsubscr...@googlegroups.com>. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Nigel Kersten Product Manager, Puppet Labs -- 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<mailto:puppet-users@googlegroups.com>. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com<mailto:puppet-users+unsubscr...@googlegroups.com>. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. ________________________________ No virus found in this message. Checked by AVG - www.avg.com<http://www.avg.com> Version: 2012.0.1901 / Virus Database: 2109/4698 - Release Date: 12/23/11 This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
