Hello Alessandro,
Thanks again for your prompt reply,
I tried using Puppi but no success, if you don't mind, can you please
answer below basic questions.
1) I have installed puppi as puppet module using 'puppet module install
example42-puppi' and that has created the Puppet module as expected but I
was unable to execute 'puppi' command manually from command line. Is there
any additional software I need to install to use puppi command line?
2) Where do I need to create the class to deploy the 'war' file? do I need
to create new '.pp' file in '/puppet/modules/puppi/manifests/projects' or
do I need to add this class definition to default 'war.pp' file located in
'/puppet/modules/puppi/manifests/'? because I tried doing both but no luck.
Any help on above points will be much appreciated as I am not getting much
help from google.
Thanks & Regards,
Krishna Murthy
On Friday, 22 February 2013 19:25:29 UTC, Alessandro Franceschi wrote:
>
> Hi Krishna,
> to deploy 2 different wars you can place 2 different puppi defines on the
> same node:
>
> puppi::project::war { 'myapp':
> source =>
> "http://repo.example42.com/deploy/${environment}/myapp.war";,
> deploy_root => '/store/tomcat/webapps',
> }
>
>
>
> puppi::project::war { 'other':
> source =>
> "http://repo.example42.com/deploy/${environment}/other.war
> <http://repo.example42.com/deploy/$%7Benvironment%7D/myapp.war>",
> deploy_root => '/store/tomcat/webapps',
> }
>
> This will provide 2 puppi deploy commands:
> puppi deploy myapp
> and
> puppi deploy other
> that would deploy the 2 wars on the same webapps dir.
>
> Note that if you don't have autodeployment activated on your application
> server you need to restart its service to deploy an app and this would
> affect the other app.
> In this case you might prefer to have 2 distinct application servers
> instances one for each app.
>
> If, instead, your 2 apps are somehow related and should be deployed at the
> same time, there it currently no supportm, out the box, of a unique puppi
> deploy procedure that takes 2 wars at the same time from 2 different
> sources , deploys them and eventually restarts the application server.
>
> Actually that's not a big effort to do (it would require the addition of
> some parameters in puppi/manifests/projects/war.pp and sono resources) but
> it requires some knowledge on how the puppi module is done. IF you need
> such a feature please open a feature request on Github.
>
> As a side note, you can create a custom procedure (similar to the example
> ones present in puppi/manifests/projects/ which actually cover most of the
> common cases) that does whatever you need.
>
> Ciao
> al
> On Friday, February 22, 2013 11:52:21 AM UTC+1, Krishna Murthy T wrote:
>>
>> 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',
>>> 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.
