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
|