Recommendation for general practice for application deployment?

[Kenneth Lo]

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.

[Felix Frank]

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

I'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

[Doug Chapman]

On Thu, Dec 22, 2011 at 1:42 AM, Felix Frank <felix...@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

[Nigel Kersten]

On Tue, Dec 20, 2011 at 8:26 AM, Kenneth Lo <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...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

--
Nigel Kersten
Product Manager, Puppet Labs

[Kenneth Lo]

“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

---

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

[Ken Barber]

Hot-deploy can be risky. The biggest issue I've seen is a low permgen. Hot deploy puts twice the requirement on permgen.

[Nigel Kersten]

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.

[Alessandro Franceschi]

Puppi (more info here download from here)  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     => "sysa...@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

[骡骡]

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:tvmi...@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*