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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to