Sounds like a good idea. I don't know anything about Makefiles, so I'll have to research that and how it integrates with Packer. If you can point me to any good resources, feel free to share :)
On Thursday, March 20, 2014 6:58:35 AM UTC-4, Lee Hambley wrote: > > One great thing about knife-solo is that it integrates with Berkshelf to >> resolve cookbook dependencies when you "knife solo cook". Very nice >> feature. I won't be doing that anymore, but I'll see if I can figure out >> how to have my Packer provisioning hook into that somehow to save headache. >> It might be as easy as using a script provisioner to fire berks installand >> prepare the cookbooks. I'll find out. > > > I have a Makefile for my Packer build (make, make clean, etc) which I use > to kick off things like Berkshelf and friends when I'm using them. > > Lee Hambley > -- > http://lee.hambley.name/ > +49 (0) 170 298 5667 > > > On 20 March 2014 11:54, Roy Miller <r...@theotherroad.com <javascript:>>wrote: > >> Yep, makes sense to me. >> >> The work I've done to figure out the approach I was using definitely >> isn't wasted. I learned a ton about Cap, knife-solo, and rake specfically, >> and provisioning and deployment in general. Now I'll shift to figuring out >> how to reuse my recipes via Packer instead. >> >> One great thing about knife-solo is that it integrates with Berkshelf to >> resolve cookbook dependencies when you "knife solo cook". Very nice >> feature. I won't be doing that anymore, but I'll see if I can figure out >> how to have my Packer provisioning hook into that somehow to save headache. >> It might be as easy as using a script provisioner to fire "berks install" >> and prepare the cookbooks. I'll find out. >> >> Thanks again for the advice. And from now on I'll post all Cap-related >> questions here instead of potentially putting non-issues on a particular >> tool's issues list at GitHub (e.g., capistrano/rbenv). >> >> >> >> On Thursday, March 20, 2014 6:44:16 AM UTC-4, Lee Hambley wrote: >> >>> It's always a fine balance, definitely there's something our industry >>> has to fine it's way with. Years ago the unit of deployment was "bare metal >>> boxes", recently it's become "diffs from a source control mechanism"… but >>> the less we deploy, the more we assume about what came before, and I so I >>> expect our devops movement towards more atomic deployments of assets. >>> Probably that will be binary-identical virtual machines. (but then of >>> course, we have to improve the way we handle configuration and consensus) >>> >>> We're not there yet, but for now, Packer provisioning my own >>> *nearly*immobile components, and relying on a combination of nfs and etcd >>> are >>> giving me the flexibility that I need. >>> >>> - Cheers >>> >>> Lee Hambley >>> -- >>> http://lee.hambley.name/ >>> +49 (0) 170 298 5667 >>> >>> >>> On 20 March 2014 11:23, Roy Miller <r...@theotherroad.com> wrote: >>> >>>> I get your point, Lee. I don't see what I'm doing as making >>>> Capistrano responsible for provisioning (knife-solo does that), it's just >>>> kicking the process off as a prerequisite to doing the actual deploy. But >>>> I >>>> understand how one could see "Capistrano drives it" as making Cap do too >>>> much. >>>> >>>> It certainly does take a lot of time building up from a bare box. I've >>>> already used Packer, so I'm familiar with it and I already know how to >>>> provision a box like what I want, Ruby and all. So I'll probably switch >>>> over to using the Packer AWS builder and chef-solo provisioner. That >>>> should >>>> accomplish the same goal. As you mention, the debugging time should drop, >>>> too. >>>> >>>> Going that route also will let me avoid installing rbenv and using the >>>> Cap/rbenv integration. It works fine, no complaints, but it'll be >>>> unnecessary for what I'm trying to accomplish. If I need to switch Rubies >>>> (the primary purpose of rbenv), I'll re-provision the box. They're >>>> supposed >>>> to be Phoenix servers anyway. >>>> >>>> Thanks for the advice. >>>> >>>> >>>> >>>> On Thursday, March 20, 2014 3:31:34 AM UTC-4, Lee Hambley wrote: >>>>> >>>>> I spent the last two days trying to figure out how to make a my >>>>>> deploy to a Vagrant box run faster. It takes roughly 30 minutes. Not >>>>>> unexpected considering that I'm trying to create a box almost from bare >>>>>> metal (i.e., it has the OS and pretty much nothing else), but it's too >>>>>> slow >>>>>> for what I need. >>>>>> >>>>> >>>>> The short answer: Don't. >>>>> >>>>> The longer, and more helpful one: If you start from a naked Ubuntu (or >>>>> similar) base box, you're going to waste a lot of time, all the time >>>>> setting the box up. The Vagrant author also produces a tool called Packer >>>>> ( >>>>> http://packer.io/), packer (example manifest and etc here: >>>>> https://github.com/capistrano/packer) allows you to easily build a >>>>> base box for Vagrant (amongst other things) >>>>> >>>>> The linked Packer template won't install Ruby (check `./scripts/`), >>>>> but you have a script for that already >>>>> >>>>> >>>>>> Part of the process is using knife-solo to provision the box. I wrote >>>>>> a rake task for it, called with a "before" hook in Cap. It works just >>>>>> great, and Cap manages the entire deploy process, which is nice. The >>>>>> slowdown comes when I install Ruby. I'm installing directly from source. >>>>>> It >>>>>> works, but man, it's dog slow, even on a beefier AWS box. That one >>>>>> recipe >>>>>> takes 15-20 minutes to run for a fresh box. >>>>>> >>>>> >>>>> You can also use knife solo to provision the box with Packer. >>>>> >>>>> >>>>>> So I experimented with getting rbenv working. It seems to take much >>>>>> less time to install Ruby. I have no idea why, but the time drops to >>>>>> about >>>>>> 5 minutes. Much better. Getting it to work with Cap was a little >>>>>> challenging, believe it or not, but I got it working -- until I hit a >>>>>> snag. >>>>>> >>>>> >>>>> The time drops, because those tools will install a binary packaged >>>>> managed by their communities, if one is found. They also almost certainly >>>>> install less extensions to Ruby than the script I gave you (OpenSSL.) >>>>> Also, >>>>> you trade 10 minutes of installation time, once with 10 minutes of >>>>> debugging every time you try and deploy/automate anything. >>>>> >>>>> >>>>>> Part of my provisioning process is to set up the deploy user in an >>>>>> automated fashion. Cap doesn't complain when I don't use the >>>>>> capistrano-rbenv gem. As soon as I plug that in, however, the initial >>>>>> rbenv:validate check fails because ... the deploy user isn't there yet, >>>>>> of >>>>>> course, and rbenv says it can't authenticate. >>>>>> >>>>> >>>>> Right, that's why we discourage the use of Capistrano for >>>>> *provisioning*, Cap excels at short, rapid fire processes. Provisioning >>>>> is >>>>> anything but. >>>>> >>>>> >>>>>> So I'm stuck. If I don't use rbenv with Cap, the Ruby install takes >>>>>> forever. If I use it, I can't deploy until the deploy user is there, and >>>>>> it's not there until after I provision the box. Catch-22. >>>>>> >>>>> >>>>> tl;dr: Use Packer. >>>>> >>>>> Hope that helps Roy. >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Capistrano" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to capistrano+...@googlegroups.com. >>>> To view this discussion on the web, visit https://groups.google.com/d/ >>>> msgid/capistrano/2475811c-dd4e-4bd0-93d7-784206111163% >>>> 40googlegroups.com<https://groups.google.com/d/msgid/capistrano/2475811c-dd4e-4bd0-93d7-784206111163%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Capistrano" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to capistrano+...@googlegroups.com <javascript:>. >> To view this discussion on the web, visit >> https://groups.google.com/d/msgid/capistrano/2b0d26b7-8214-4735-a8c1-d08164098190%40googlegroups.com<https://groups.google.com/d/msgid/capistrano/2b0d26b7-8214-4735-a8c1-d08164098190%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Capistrano" group. To unsubscribe from this group and stop receiving emails from it, send an email to capistrano+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/capistrano/90b1d950-b89b-473c-b81c-63066a3f8da6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
