Hey Luke,
Thanks for bringing this up, this is a common problem that I personally
have seen time and time again needing to be solved in the chef community. I
can at least shed some light on how my teams have accomplished this. My
team performs deploys at any time, sometimes we can have up to 20-30
deploys a day to any environment (dev, staging, qa, production). We first
started out using the environment files as the first indication of the
build. Essentially we would all update an attribute override for
application-version in the environment. We have about 50 different portions
that go into our whole application so we can build a single portion an
deploy that portion as needed. The problem with this was, our developers
needed to push as well and eventually we ended up having to put information
overrides into the environment file as well that included things like
production application passwords or keys that would fill in
certain configuration files per environment. These attributes we did not
want everyone to be able to see or have access to.
Our second approach was to use jenkins to edit the json file. We attempted
a series of regex/perl replacements for strings, this sucked and i will
leave it at that
Eventually, we got to where we recently landed within the last couple of
weeks. I ended up writing tools for our team, I am contemplating open
sourcing it if I can see enough people who would like to use it. But
essentially I wrote a web based (django app) that allows users to edit
portions of the environment files based on their permissions level. This
does sanity checking to ensure that its modified properly, when the edit is
done, it pushes to git to track and backup the modification, and it also
makes an API call to the local chef server to actually process the change.
The tool also allows the developers and admins to launch deploys per
server/environment based on their permissions levels as well.
I hope that helps but essentially yes, you should be tracking everything in
git. How you want to edit the json files seems to be the #1 disconnect so
far of managing chef. I have written this tool and I know some others who
have done similar. If interested I could hack together an open source
version of my tool you can fit into your environment.
Jonathan
On Fri, May 31, 2013 at 7:28 AM, Luke luke.a.egging@accenture.com wrote:
All,
I’m reaching out to you from a project that is harnessing Chef to automate
deployment of Application artifacts that change regularly, such as EARs,
WARs,
DB Schemas etc. This is definitely something that Chef can do however I
feel
that the approach my team has come to is a poor one. I'm looking for a
'best
practice' solution to solving this particular problem with Chef. Let me
explain
where my team stands right now...
Someone wants to deploy a new version of HelloWorld EAR into our Dev
environment. Presently he does this by kicking off a job in Jenkins which
simply exposes the target host and the application artifact to deploy.
Under the covers Jenkins SSH's onto the remote server and invokes the
'chef-client' command on that host, passing some JSON that specifies where
the
recipe should get the EAR file from --- basically the version of the EAR
since
the path is consistent.
So this works. Chef goes ahead and deploys the new artifact. Awesome.
However
it seems really hacky. I don't like that this approach means that
Environment
config on the Chef Server will always of date with our Environment JSON in
source control.
I feel that the correct approach is to use Jenkins to update the JSON for
the
environment you want to deploy to in source control, then updates
Chef-Server
using knife. Finally Jenkins calls 'chef-client' on the box and it will
work as
above.
The real value that I see from this second approach is that if you commit
each
change to your environment's JSON to source control, you have
traceability. The
other benefit is that you could build a totally new Chef Server (e.g. in a
second cloud) and because your source control is up to date with your
environment, you should get an identical environment built up by Chef.
Finally,
everything is aligned: if you need to check what version of your app is
deployed to your dev environment you could check in source control, on Chef
server or on Jenkins and it will all be aligned.
What are your thoughts on these two approaches? I would like to see what
the
Chef community has done to solve this problem before so I can align my
project
with best practice in this particular area. Need your support
Many Thanks,
Luke