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+unsubscr...@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/CAN_%2BVLVscmAq2NpVB6bB9RaUtM0NS-3-Zq14DXo-Ddqj5rf21w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
