There’s a couple of ways to skin this cat.
First, if you want to use code straight from git or svn, you could use the git or subversion resources, and check it out directly from within the recipe. Make your desired branch/tag/commit an attribute and you’re good to go.
http://docs.opscode.com/chef/resources.html#git http://docs.opscode.com/chef/resources.html#subversion
If you’re using a tarball, pull it down via the remote_file resource, and make the filename an attribute. Then you can change the attribute to change the file downloaded.
http://docs.opscode.com/chef/resources.html#remote-file
There are a couple of cookbooks that add resources designed to help with the tarball download-unpack-symlink dance:
https://github.com/burtlo/ark https://github.com/reset/libarchive-cookbook
That said, if you’re deploying via tarballs, I strongly suggest you switch over to native packaging if at all possible. FPM can make creating a versioned deb or rpm almost easier than wrapping up a tarball:
https://github.com/jordansissel/fpm
Hope that helps!
On July 14, 2014 at 8:49:37 PM, Danny Hadley (
">
) wrote:
hmm, I must not have phrased my question correctly. What I’m trying
to solve is how to get a specific version of that “package” onto a
node being provisioned with chef.
Suppose my package only has one file, an index.html file. And in
master the file looks like:
<!doctype html>
<html>
<title>zz</title>
…
</html>
but then I cut a feature branch, and make a commit (12a4) that
changes the title:
<!doctype html>
<html>
<title>zz | home</title>
…
</html>
How can I get that code (the “package”) deployed onto a new machine
without merging into master and promoting a new build
artifact/release version?
I’m not asking about tracking the artifact after it’s been
deployed to the machine, but how to get a specific build version of
the artifact itself onto the machine. This is something that I’ve
come across when using a “phoenix” approach with nodes where they
are only ever provisioned with chef once. There are no re-runs;
servers are provisioned, tested/used, and discarded, being replaced
by the next generation (blue/green).
On July 14, 2014 at 8:09:47 PM, Mike
Thibodeau (
">
) wrote:
Unpacking a tar or other file archive means content,
files, that is not maintained inside chef or inside the node
itself.
I have been thinking of using an intermediate directory on the
destination machine to cache or explode archives and use fpm to
turn that into a short lived package for the node to then truly
install. This way you can have a record of each file and you can
keep using your chosen source object. Creating metadata for that
transient package that includes the source path, name, sum, size,
and anything else about it would be good to have for future
comparison and reporting.
Using the nodes native packager enables uninstall, upgrade, and all
the other sweetness a package management utility brings.
Similar to downloading source and compiling locally except in this
case it's only the last steps of making the package and
installing.
> On Jul 14, 2014, at 2:48 PM, Danny Hadley
<
> wrote:
>
> Hey guys,
>
> I have been using chef for around a year now and I'm having a
bit of trouble
> bridging one last piece of the automation puzzle with a chef
workflow; getting
> a specific commit (i.e a feature branch I want to deploy to
staging) deployed
> onto a node using chef.
>
> For time purposes, lets say my deployment procedure is to
simply download and
> unpack a tarball into the doc root of a web server, and lets
also say that the
> installation of that webserver on the node is taken care of in
a different
> recipe. So, my "zz" cookbook has two recipes:
>
> zz::server
> zz::application
>
> where the application recipe looks like
>
> tarball "/http/public" do
> source "http://my-artifact-server/zz.tar.gz"
> end
>
> what is the best way of handling that situation I mentioned
where I want a
> feature branch (a specific commit), rather that the
master/prod release that is
> most likely the file downloaded by
"http://my-artifact-server/zz.tar.gz"? Lets
> say my CI pipeline has the ability to build upon push, and the
commit hash is
> 12a4, so I do have an artifact for the 12a4 build. I was
thinking that one
> solution would be to have the chef "tarball" resource download
it's file from a
> url like:
>
> "http://my-artifact-server/zz?nn=#{node.node_name}"
>
> where the "nn" param is the node name. This way, the
responsibility relies on
> the artifact server to serve up the correct artifact and chef
needs only have
> one version of the recipe. I'm not sure that tool exists
though, and it seems
> like a tool that would need to be in cahootz with chef since
the node would
> have configuration properties stored in multiple places.
>
> Anyways, does this make sense to anyone, has anyone else faced
these growing
> pains, and if so, how did you go about solving them?
>
> Thanks!
> -Danny
|