Hello Alessandro,

Thank you very much for your quick reply, now it is bit more clear to me 
and I will start implementing Puppi today.

One more quick question :-)  I need to deploy two 'war' files to the same 
server, which means same 'deploy_root' but two 'war' files and I don't 
think I can use two 'source' two times.

Any suggestions will be much appreciated.

Thanks & Regards,
Krishna Murthy

On Friday, 22 February 2013 05:20:13 UTC, Alessandro Franceschi wrote:
>
> Hi Krishna,
> the execution of a "puppi deploy myapp"  is not done generally via Puppet 
> (Puppet creates the environment that allows you to make a deploy with a 
> puppi deploy command, you can also trigger a "puppi deploy myapp" execution 
> via Puppet but that's not common if not for first time setup ) and can be 
> done in various ways:
> - Directly from an host, typing as root: puppi deploy myapp
> - Doing the same via a cron job (puppi can check if the artifacts to 
> deploy have changes)
> - Via Jenkins or similar, typically doing a ssh connection with an 
> unprivileged user tha can so "sudo puppi deploy myapp"
> - Via Mcollective, using the puppi plugin.
> - Via whatever type of more or less centralized orchestration/scheduling 
> tool that can execute a remote command
>
> To decide which war (or whatever artifact) deploy on which node, just 
> consider that you have normal Puppet defines with some parameters that 
> allow you to define what to deploy (or better, what to configure for puppi 
> deploys) on what hosts.
>
> For example, for a role, or group of servers you can have :
>
> puppi::project::war { 'myapp':
>   source           => 
> "http://repo.example42.com/deploy/${environment}/myapp.war";,
>   deploy_root      => '/store/tomcat/myapp/webapps',
> }
>
> (note the environment variable that allows you to pick from different 
> sources wars for different environments)
> and at the same time have to deploy different things on different servers 
> (this time picking the artifacts from a Maven repository) with defines like 
> :
>
> puppi::project::maven { 'supersite':
>   source           => 
> 'http://nexus.example42.com/nexus/content/repositories/releases/it/example42/supersite/',
>   deploy_root      => '/usr/local/tomcat/supersite/webapps',
>   init_script      => 'tomcat',
>   report_email     => 'sysa...@example42.com <javascript:>',
>   enable           => 'true',
> }
>
>
> Hope to have cleared a bit...
> Alessandro
>
>
> On Friday, February 22, 2013 12:59:41 AM UTC+1, Krishna Murthy T wrote:
>>
>> Hello Alessandro,
>>
>> I found Puppi very interesting and want to use it along side our Puppet 
>> environment.
>>
>> Can you please give me an idea about how to deploy same and different 
>> 'war' files to different environments using Puppi?
>>
>> I have several node definitions in my Puppet manifest each serving 
>> different purpose, I want to use Puppi to deploy to all those hosts but not 
>> at the same time.
>>
>> Any help will be appreciated.
>>
>> Thanks in advance,
>> Krishna Murthy
>>
>> On Thursday, 17 January 2013 22:02:25 UTC, Alessandro Franceschi wrote:
>>>
>>> Oh, I was forgetting, Puppi is also a required  dependency of all 
>>> Example42 modules, since it provides some functions used by these modules.
>>> Note anyway that you can decide to use these modules without using puppi 
>>> in any way (that is to not install the command and its working environment 
>>> on your nodes)... you just need it in your modulepath to pluginsync its lib 
>>> dir.
>>> al
>>>
>>> On Thursday, January 17, 2013 10:58:20 PM UTC+1, Alessandro Franceschi 
>>> wrote:
>>>>
>>>> Hi,
>>>> Puppi is a shell tool, installed and configured bythe omonimous Puppet 
>>>> module, that has basically 2 functions:
>>>> 1- Manage application deployments
>>>> 2- Provide an handy bash command with data driven by Puppet
>>>>
>>>> For the first task there are a bunch of puppet defines that allow you 
>>>> to define a deployment procedure (and some ready to use deployments 
>>>> samples 
>>>> good for many different uses (defined in manifests/projects/*.pp )).
>>>> These defines, that you configure on puppet, provide to you the 
>>>> possibility of executing, on your nodes, commands like "puppi deploy 
>>>> myapp" 
>>>> or "puppi rollback myapp" to manage deployments.
>>>>
>>>> For the second task you need modules that actually can drive data to 
>>>> Puppet (Example42 ones do), but it's not too difficult to feed custom 
>>>> configurations to populate the output of actions like puppi check (does an 
>>>> immediate health check of your system and its applications), puppi info 
>>>> [app] (show information about your system and applications), puppi log 
>>>> [app] (tails all the configured logs).
>>>>
>>>> Since the command is always one (puppi) and the actions are always the 
>>>> same (deploy, rollback, check, info, log etc) you can easily uniform some 
>>>> operations on your infrastructure (whatever are the operations you have to 
>>>> do for a deploy, you have to run "puppi deploy something"). Puppi, of 
>>>> course can be run directly from the shell , but also via a jenkins ssh 
>>>> command (allowing only a "sudo puppi") or via mcollective (via the 
>>>> mc-puppi 
>>>> plugin) , or as a command that interacts with other orchestration / remote 
>>>> execution tools.
>>>>
>>>> I found it extremely useful on a variegated environment, managed by a 
>>>> team of various people, where there are many different kind of servers 
>>>> with 
>>>> diffferent deployment needs (wars, tarballs, maven artifacts, git sources 
>>>> and so on) and where it has been possibly to streamline and make it easy 
>>>> to 
>>>> make a deployment (if you just write 'puppi' you see also the available 
>>>> projects / apps you can deploy on the local nodes).
>>>>
>>>> Also, when configured with sane checks, it's very handy to write "puppi 
>>>> check" on a node and see if everything is going fine on it: at system / 
>>>> services / application levels (if you add, for example, url based checks 
>>>> (all checks are based on Nagios plugins).
>>>>
>>>> Hope to have given you  a clearer view on puppi, I'm actually aware 
>>>> that the documentation is not good and somehow scattered on different 
>>>> places (what have you seen? the README on the git repo?)
>>>>
>>>> I'm at disposal to answer to any question about it and eventually to 
>>>> suggest you the possible Puppet code you can write to manage an 
>>>> application 
>>>> deployment you may need.
>>>>
>>>> Regards
>>>> Alessandro Franceschi
>>>> (yes, I wrote it)
>>>>
>>>> On Thursday, January 17, 2013 12:01:21 PM UTC+1, Rajeev Iyer wrote:
>>>>>
>>>>> How useful is Puppi? Can someone throw light on this? The 
>>>>> documentation on the web is not so good. 
>>>>>
>>>>> Thanks, 
>>>>> Rajeev 
>>>>>
>>>>

-- 
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+unsubscr...@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.


Reply via email to