Hi all -
I’m starting to drink more kool-aid but don’t want to reinvent the wheel.
We have a several war projects we want to deploy to a windows server running
tomcat.
So the order of operation is:
1 - Install Tomcat if it’s not there
2 - it it was there shut it down
3 - archive previous wars
4 - put in new war
5 - tweak any configuration I need to (some may be INSIDE the war)
6 - start up tomcat
So far, I haven’t seen a tomcat for windows cookbook. Is it bad to include
the binary of tomcat I want to install as part of the cookbook? What about
our wars, do they need to be in a cookbook which has recipes specific to our
needs?
This feels kinda clunky (most likely because of my understanding of things,
not chefs fault).
One final passing thought - there seem to be several ways to split up the
dev/qa/stage/prod type configurations. I can have an environments databag
for dev/qa and an encrypted databag for stage/production. But also, I could
segregate via environments. Either way, for sure, we’ll have sensitive
passwords that need to be obfuscated.
What do people typically do?
Ok, now that I've worked through all of these, one question remains.
If I'm using chef to deploy a war, do I need to update the cookbook every
time the war changes?
How do people typically control this kind of thing?
On Fri, Sep 30, 2011 at 10:25 AM, Maven User maven.2.user@gmail.com wrote:
Hi all -
I'm starting to drink more kool-aid but don't want to reinvent the wheel.
We have a several war projects we want to deploy to a windows server
running tomcat.
So the order of operation is:
1 - Install Tomcat if it's not there
2 - it it was there shut it down
3 - archive previous wars
4 - put in new war
5 - tweak any configuration I need to (some may be INSIDE the war)
6 - start up tomcat
So far, I haven't seen a tomcat for windows cookbook. Is it bad to include
the binary of tomcat I want to install as part of the cookbook? What about
our wars, do they need to be in a cookbook which has recipes specific to our
needs?
This feels kinda clunky (most likely because of my understanding of things,
not chefs fault).
One final passing thought - there seem to be several ways to split up the
dev/qa/stage/prod type configurations. I can have an environments databag
for dev/qa and an encrypted databag for stage/production. But also, I could
segregate via environments. Either way, for sure, we'll have sensitive
passwords that need to be obfuscated.
What do people typically do?
On Mon, Oct 3, 2011 at 12:18 PM, Maven User maven.2.user@gmail.com wrote:
Ok, now that I've worked through all of these, one question remains.
If I'm using chef to deploy a war, do I need to update the cookbook every
time the war changes?
How do people typically control this kind of thing?
Several options but the way the application cookbook works, you would
typically change the version number in a databag that would cause
chef-client to run through the deploy steps because the asset has
changed.
ohai!
On Oct 3, 2011, at 12:18 PM, Maven User wrote:
Ok, now that I've worked through all of these, one question remains.
If I'm using chef to deploy a war, do I need to update the cookbook every
time the war changes?
How do people typically control this kind of thing?
Either use a node attribute or read the value from a data bag.
Yeah, I'm pretty sold on the databag attribute.
Running via chef-solo for testing out the cookbook means I don't have
access, correct?
Also, the existing jpackage/tomcat/java cookbooks are *nix specific or are
there neat/unique ways I could have leveraged them?
They seemed to be very *nix path/tooling centric...
On Mon, Oct 3, 2011 at 5:25 PM, Joshua Timberman joshua@opscode.com wrote:
ohai!
On Oct 3, 2011, at 12:18 PM, Maven User wrote:
Ok, now that I've worked through all of these, one question remains.
If I'm using chef to deploy a war, do I need to update the cookbook every
time the war changes?
How do people typically control this kind of thing?
Either use a node attribute or read the value from a data bag.
On 04.10.2011, at 15:29, Maven User wrote:
Yeah, I'm pretty sold on the databag attribute.
Running via chef-solo for testing out the cookbook means I don't have access, correct?
have a look at: https://github.com/iteh/vagrant-demos/tree/master/vagrant-java-application-reworked to get an idea
its *nix specific but most parts should work, at least the ideas
https://github.com/iteh/vagrant-demos/blob/master/vagrant-java-application-reworked/cookbooks/tomcat/providers/context.rb
e.g. deployment is protected by:
unless @context.deployed && @context.checksum == @new_resource.checksum
Also, the existing jpackage/tomcat/java cookbooks are *nix specific or are there neat/unique ways I could have leveraged them?
They seemed to be very *nix path/tooling centric...
On Mon, Oct 3, 2011 at 5:25 PM, Joshua Timberman joshua@opscode.com wrote:
ohai!
On Oct 3, 2011, at 12:18 PM, Maven User wrote:
Ok, now that I've worked through all of these, one question remains.
If I'm using chef to deploy a war, do I need to update the cookbook every
time the war changes?
How do people typically control this kind of thing?
Either use a node attribute or read the value from a data bag.
--
DI Edmund Haselwanter, edmund@haselwanter.com, http://edmund.haselwanter.com/
http://www.iteh.at | Facebook | http://at.linkedin.com/in/haselwanteredmund