[chef] Re: Bridging the gap between node and artifact

[Mike Thibodeau < >]

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