Kenneth Lo
2011-Dec-20 16:26 UTC
[Puppet Users] Recommendation for general practice for application deployment?
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. 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. 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.
Felix Frank
2011-Dec-22 09:42 UTC
Re: [Puppet Users] Recommendation for general practice for application deployment?
Hi, On 12/20/2011 05:26 PM, Kenneth Lo wrote:> 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 instanceI''m pretty sure you cannot do that with a single ''tomcat service'' resource. Moreover, you won''t be able to build a mechanism for the semantics of "if the file needs a change, do this thing first", because puppet can only notify resources *after* the fact. Is it strictly necessary to kill tomcat before the war file is touched? If not, just do a single restart after touching the file. Otherwise, I''d build it like this: file { "war-file-in-alternate-location": source => ..., notify => Exec["deployment-script"] } exec { "deployment-script": refreshonly => true, ... } The "deployment script" is a script you roll via puppet, which will kill tomcat, copy the newly rolled war file and then start tomcat anew. Puppet-wise, this is KISSiest way I can think of. HTH, Felix -- 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.
Doug Chapman
2011-Dec-22 14:20 UTC
Re: [Puppet Users] Recommendation for general practice for application deployment?
On Thu, Dec 22, 2011 at 1:42 AM, Felix Frank < felix.frank@alumni.tu-berlin.de> wrote:> Hi, > > On 12/20/2011 05:26 PM, Kenneth Lo wrote: > > 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 > >This strikes me as a problem for package management to solve. Use puppet to ensure the correct package version is present and use the something like rpm %pre and %post stages to control the state of tomcat during the upgrade. -- Doug Chapman -- 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.
Nigel Kersten
2011-Dec-23 19:00 UTC
Re: [Puppet Users] Recommendation for general practice for application deployment?
On Tue, Dec 20, 2011 at 8:26 AM, Kenneth Lo <klo@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. > 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. >-- 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. 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.
Kenneth Lo
2011-Dec-23 19:58 UTC
RE: [Puppet Users] Recommendation for general practice for application deployment?
"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 <klo@paydiant.com<mailto:klo@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+unsubscribe@googlegroups.com<mailto:puppet-users%2Bunsubscribe@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+unsubscribe@googlegroups.com<mailto:puppet-users+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Ken Barber
2011-Dec-23 20:28 UTC
RE: [Puppet Users] Recommendation for general practice for application deployment?
Hot-deploy can be risky. The biggest issue I''ve seen is a low permgen. Hot deploy puts twice the requirement on permgen. On Dec 23, 2011 7:58 PM, "Kenneth Lo" <klo@paydiant.com> wrote:> “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 <klo@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. > 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. > > > > > > -- > 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. > 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. > ------------------------------ > > No virus found in this message. > Checked by AVG - 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+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.
Nigel Kersten
2011-Dec-25 04:18 UTC
Re: [Puppet Users] Recommendation for general practice for application deployment?
Yep. Just checking whether there was a valid reason. I''ve seen people avoid hot deploy even when they''ve got more than enough resources to cope with individual apps hot-deploying. On Fri, Dec 23, 2011 at 12:28 PM, Ken Barber <ken@puppetlabs.com> wrote:> Hot-deploy can be risky. The biggest issue I''ve seen is a low permgen. Hot > deploy puts twice the requirement on permgen. > On Dec 23, 2011 7:58 PM, "Kenneth Lo" <klo@paydiant.com> wrote: > >> “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 <klo@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. >> 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. >> >> >> >> >> >> -- >> 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. >> 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. >> ------------------------------ >> >> No virus found in this message. >> Checked by AVG - 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+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. >-- 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. 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.
Alessandro Franceschi
2011-Dec-26 13:48 UTC
[Puppet Users] Re: Recommendation for general practice for application deployment?
Puppi<http://example42.com/?q=Puppi_A_Puppet_module_for_Deployment_Automation>
(more
info here <http://example42.com/?q=puppi_deployments> download from
here<https://github.com/example42/puppi>)
is a Puppet module made exactly for application deployments.
You can deploy war files with a define like:
puppi::project::war { "myapp":
source =>
"http://repo.example42.com/deploy/prod/myapp.war",
deploy_root => "/store/tomcat/myapp/webapps",
report_email => "sysadmins@example42.com",
}
Want to restart tomcat to avoid hot deploys? Add the argument:
init_script => "tomcat",
Want to run a custom script before (or after) the deployment? Add
predeploy_command => "/path/to/my/script.sh",
Note that the above define makes you able, on from the host where you
defined the resource, to issue the command (via shell, collective, cron job
or at the end of a continuous deployment procedure) :
*puppi deploy myapp*
If you want to perform the deployment directly during the puppet run, you
should add the define:
puppi::run { "myapp": }
And, btw, there are puppy defines to manage, in a similar direct and easy
way, deployments of tar balls, zip archives, files from a given list,
artifacts built by Maven and son on...
Hope it helps
Al
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/AvYdqCWlqSAJ.
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.
骡骡
2012-Feb-07 09:43 UTC
[Puppet Users] Re: Recommendation for general practice for application deployment?
Hi, Alessandro Francesch:
I am just use Puppi, it''s dont work!
my configuration:
server
/etc/puppet/modules/puppi/manifests/init.pp
add
puppi::project::builder { "tengine":
source => "svn://tvmining:tvmining@svn.test.local/product/
tengine",
source_type => "dir",
deploy_root => "/opt/tvm",
user => "tvm",
predeploy_customcommand => '''',
predeploy_user => '''',
postdeploy_customcommand => '''',
postdeploy_user => '''',
run_checks => "true",
backup => "full",
backup_retention => "10",
enable => "true",
}
I''m execute the command ''puppetmasterd --debug
--no-daemonize'' , it''s
not error
client
I''m execute the command ''puppetd --debug
--no-daemonize'', it''s error.
debug: /Stage[main]/Puppi::Logs/Puppi::Log[mail]/File[/etc/puppi/logs/
mail]: Autorequiring File[puppi_logsdir]
debug: /Stage[main]/Puppi::Logs/Puppi::Log[mail]/File[/etc/puppi/logs/
mail]: Autorequiring User[root]
debug: /Stage[main]/Puppi::Infos/Puppi::Info::Module[puppi]/File[/etc/
puppi/info/puppi]: Autorequiring File[puppi_infodir]
debug: /Stage[main]/Puppi::Infos/Puppi::Info::Module[puppi]/File[/etc/
puppi/info/puppi]: Autorequiring User[root]
err: Could not apply complete catalog: Found 1 dependency cycle:
(Class[Puppi] => File[/etc/puppi/projects/tengine/deploy/40-tengine-
Deploy] => Puppi::Deploy[tengine-Deploy] =>
Puppi::Project::Builder[tengine] => Class[Puppi])
Try the ''--graph'' option and opening the resulting
''.dot'' file in
OmniGraffle or GraphViz
Can you help me? Thanks.
On Dec 26 2011, 9:48 pm, Alessandro Franceschi <a...@lab42.it>
wrote:>
Puppi<http://example42.com/?q=Puppi_A_Puppet_module_for_Deployment_Automation>
(more
> info here <http://example42.com/?q=puppi_deployments> download from
here<https://github.com/example42/puppi>)
> is a Puppet module made exactly for application deployments.
> You can deploy war files with a define like:
> puppi::project::war { "myapp":
> source =>
"http://repo.example42.com/deploy/prod/myapp.war",
> deploy_root => "/store/tomcat/myapp/webapps",
> report_email => "sysadm...@example42.com",
>
> }
>
> Want to restart tomcat to avoid hot deploys? Add the argument:
> init_script => "tomcat",
>
> Want to run a custom script before (or after) the deployment? Add
> predeploy_command => "/path/to/my/script.sh",
>
> Note that the above define makes you able, on from the host where you
> defined the resource, to issue the command (via shell, collective, cron job
> or at the end of a continuous deployment procedure) :
> *puppi deploy myapp*
>
> If you want to perform the deployment directly during the puppet run, you
> should add the define:
> puppi::run { "myapp": }
>
> And, btw, there are puppy defines to manage, in a similar direct and easy
> way, deployments of tar balls, zip archives, files from a given list,
> artifacts built by Maven and son on...
>
> Hope it helps
> Al
--
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.