I finally got around to setting up a Jenkins job to upload changes to the Chef server when I push them to the git repo. So far it’s great having one source of truth for my Chef data.
However, the one remaining hole is deleting things from the Chef server when they’re deleted from the git repo. Is anyone already doing that in an automated fashion? If so, what is your favorite approach?
It seems there a few options out there for how to do it. Everything from parsing the git log to using a knife plugin to see what’s on the server but not in the local repo working copy.
I kind of wish there were just a “knife sync” command.
I finally got around to setting up a Jenkins job to upload changes to the Chef server when I push them to the git repo. So far it's great having one source of truth for my Chef data.
However, the one remaining hole is deleting things from the Chef server when they're deleted from the git repo. Is anyone already doing that in an automated fashion? If so, what is your favorite approach?
We actually use a fancy bit of ruby script using the spice gem that
does uploads, deletes and runs a bunch of auditing and validation
functions on the chef server. I have heard people have also done
something similar with jclouds but never looked into it.
However a quick and dirty script may work just as well. Something like
I finally got around to setting up a Jenkins job to upload changes to the Chef server when I push them to the git repo. So far it's great having one source of truth for my Chef data.
However, the one remaining hole is deleting things from the Chef server when they're deleted from the git repo. Is anyone already doing that in an automated fashion? If so, what is your favorite approach?
We actually use a fancy bit of ruby script using the spice gem that
does uploads, deletes and runs a bunch of auditing and validation
functions on the chef server. I have heard people have also done
something similar with jclouds but never looked into it.
However a quick and dirty script may work just as well. Something like
Running this made me remember that cookbooks aren't segregated by organization in hosted Chef, so this would delete things that I don't want to delete. Hmm, maybe this needs some more thought. I think deletes would have to be triggered via git log parsing to get around that.
Many times I thought of having only the git repo as the single source of
truth, but since there seems to be no out-of-the-box solution for it kept
just a thought.
For one thing I want the single source of truth in a git repository. If I
can't have that, I'd like to have an audit trail at least...
I finally got around to setting up a Jenkins job to upload changes to
the Chef server when I push them to the git repo. So far it's great
having one source of truth for my Chef data.
However, the one remaining hole is deleting things from the Chef server
when they're deleted from the git repo. Is anyone already doing that in an
automated fashion? If so, what is your favorite approach?
We actually use a fancy bit of ruby script using the spice gem that
does uploads, deletes and runs a bunch of auditing and validation
functions on the chef server. I have heard people have also done
something similar with jclouds but never looked into it.
However a quick and dirty script may work just as well. Something like
Running this made me remember that cookbooks aren't segregated by
organization in hosted Chef, so this would delete things that I don't want
to delete. Hmm, maybe this needs some more thought. I think deletes would
have to be triggered via git log parsing to get around that.
Hi,
I wrote this post-receive hook trying to achieve the same goal:
To deploy a new server, you create a databag json file, commit and
push the file. Same for cookbooks, roles, etc. The hook uploads data
to the chef server and takes care of executing scripts, reporting
everything to an irc channel.
For the audit trail part, the knife execution is done by rundeck, the
url for the output is available on the irc channel.
The workflow is detailed on this blog post (sry, link in spanish,
english version coming up soon) http://www.devops.com.ar/blog/2012/11/20/instalando-servidores-con-un-commit/
regards,
osvaldo
On Tue, Nov 20, 2012 at 4:19 PM, Torben Knerr ukio@gmx.de wrote:
Many times I thought of having only the git repo as the single source of
truth, but since there seems to be no out-of-the-box solution for it kept
just a thought.
For one thing I want the single source of truth in a git repository. If I
can't have that, I'd like to have an audit trail at least...
I finally got around to setting up a Jenkins job to upload changes to
the Chef server when I push them to the git repo. So far it's great having
one source of truth for my Chef data.
However, the one remaining hole is deleting things from the Chef server
when they're deleted from the git repo. Is anyone already doing that in an
automated fashion? If so, what is your favorite approach?
We actually use a fancy bit of ruby script using the spice gem that
does uploads, deletes and runs a bunch of auditing and validation
functions on the chef server. I have heard people have also done
something similar with jclouds but never looked into it.
However a quick and dirty script may work just as well. Something like
Running this made me remember that cookbooks aren't segregated by
organization in hosted Chef, so this would delete things that I don't want
to delete. Hmm, maybe this needs some more thought. I think deletes would
have to be triggered via git log parsing to get around that.
Awesome, thanks for sharing!
Am 20.11.2012 20:32 schrieb "O. T. Suarez" otsuarez@gmail.com:
Hi,
I wrote this post-receive hook trying to achieve the same goal: git hook for chef deployments · GitHub
To deploy a new server, you create a databag json file, commit and
push the file. Same for cookbooks, roles, etc. The hook uploads data
to the chef server and takes care of executing scripts, reporting
everything to an irc channel.
For the audit trail part, the knife execution is done by rundeck, the
url for the output is available on the irc channel.
The workflow is detailed on this blog post (sry, link in spanish,
english version coming up soon)
On Tue, Nov 20, 2012 at 4:19 PM, Torben Knerr ukio@gmx.de wrote:
Many times I thought of having only the git repo as the single source of
truth, but since there seems to be no out-of-the-box solution for it kept
just a thought.
For one thing I want the single source of truth in a git repository. If I
can't have that, I'd like to have an audit trail at least...
I finally got around to setting up a Jenkins job to upload changes to
the Chef server when I push them to the git repo. So far it's great having
one source of truth for my Chef data.
However, the one remaining hole is deleting things from the Chef
server
when they're deleted from the git repo. Is anyone already doing that
in an
automated fashion? If so, what is your favorite approach?
We actually use a fancy bit of ruby script using the spice gem that
does uploads, deletes and runs a bunch of auditing and validation
functions on the chef server. I have heard people have also done
something similar with jclouds but never looked into it.
However a quick and dirty script may work just as well. Something like
Running this made me remember that cookbooks aren't segregated by
organization in hosted Chef, so this would delete things that I don't
want
to delete. Hmm, maybe this needs some more thought. I think deletes
would
have to be triggered via git log parsing to get around that.
We've built a system around Jenkins that attempts to shore up trust in the
Git repo. It uses a volatile Chef server for testing purposes -- one
testing assumption is that only the latest and greatest versions of
everything will be tested, so version constraints are ignored.
I'm now looking at refactoring this system to use Librarian, but the
biggest hurdle I see is determining when and what changed in one of the
dependent Git repositories as a Jenkins build trigger. I'm pretty sure
this is going to end with me writing a Jenkins build trigger plugin and I
have the feeling I am going to find that very unpleasant.
If this does, in fact, come to pass, I'll see about open-sourcing the build
trigger. (Sorry, I don't think I can offer up the entire system at present
... test-kitchen offers a subset of this functionality, though!)
On Tue, Nov 20, 2012 at 11:54 AM, Torben Knerr ukio@gmx.de wrote:
Awesome, thanks for sharing!
Am 20.11.2012 20:32 schrieb "O. T. Suarez" otsuarez@gmail.com:
Hi,
I wrote this post-receive hook trying to achieve the same goal: git hook for chef deployments · GitHub
To deploy a new server, you create a databag json file, commit and
push the file. Same for cookbooks, roles, etc. The hook uploads data
to the chef server and takes care of executing scripts, reporting
everything to an irc channel.
For the audit trail part, the knife execution is done by rundeck, the
url for the output is available on the irc channel.
The workflow is detailed on this blog post (sry, link in spanish,
english version coming up soon)
On Tue, Nov 20, 2012 at 4:19 PM, Torben Knerr ukio@gmx.de wrote:
Many times I thought of having only the git repo as the single source of
truth, but since there seems to be no out-of-the-box solution for it
kept
just a thought.
For one thing I want the single source of truth in a git repository. If
I
can't have that, I'd like to have an audit trail at least...
I finally got around to setting up a Jenkins job to upload changes
to
the Chef server when I push them to the git repo. So far it's great having
one source of truth for my Chef data.
However, the one remaining hole is deleting things from the Chef
server
when they're deleted from the git repo. Is anyone already doing
that in an
automated fashion? If so, what is your favorite approach?
We actually use a fancy bit of ruby script using the spice gem that
does uploads, deletes and runs a bunch of auditing and validation
functions on the chef server. I have heard people have also done
something similar with jclouds but never looked into it.
However a quick and dirty script may work just as well. Something
like
Running this made me remember that cookbooks aren't segregated by
organization in hosted Chef, so this would delete things that I don't
want
to delete. Hmm, maybe this needs some more thought. I think deletes
would
have to be triggered via git log parsing to get around that.
