> > 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> 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+unsubscr...@googlegroups.com. > 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/CAN_%2BVLWVzvK_C_KX%2BFePqMfAXbo0qzAUAtgEfu4hJQA0JJf1-g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
