Re: [vagrant-up] Best workflow

[Simon McCartney]

1 - although with puppet, same principles apply.

I start with a base box that matches our production environemnt (CentOS 5.6 or 6.3) and then layer on top using puppet

Why?  Because that's how we'll build out production, so my dev environment matches production, and I get to iron out anu wrinkeles with the build out proces

On 16 September 2012 00:40, Karel Ledru-Mathé <ka...@ledrumathe.com> wrote:

Hi,

I recently started to play with vagrant and I managed to get it working with chef.

It took me quite a while to get the good cookbooks to work together, in the right order but finally I have a provisioning that works. Though, I'm really wondering if I'm doing it right. As it took me 100 the time I would have needed to build it by hand, I'm thinking of changing the way I use vagrant from:

1. Keep updated cookbooks, vagrantfiles... for all the different stack you may need (ruby/postgres, lamp, node...) and when you start a new project, you start from the base precise64 box (for instance) and provision it entirely based on your run list

TO

1. Keep the provisioning part to the very minimum, vagrant up, manually install the stack I want and package it for whatever future project using that stack. So I basically create personal boxes for my needs.

What are you doing, 1or 2? I'm really surprised that there is no boxes with existing common stacks so that I truly just need to do a vagrant up without even maintenaing a personal box, cookbooks or whatever else. Am I missing something?

Thank for you help.

--

Simon McCartney

E: si...@mccartney.ie

M: +44 7710 836 915

[caspyin]

Hey Karel. I struggled with this as well and it took a really long time (hundreds of provisions) to get things working the way I wanted. I've decided to go with #1. I have a Vagrantfile that creates the generic rails stack I need for development and then I customize it for specific apps. This way I can keep the provisioning stuff with the code for the app and I have a dev vm that I can spin up quickly to do what ever I need. Also I agree with Simon's point about building the box up to match production. That is important. But it is important to understand if that is what one needs for their current situation or not. For dev purposed I don't think you do.

Option #2 certainly has some benefits, namely that it is super easy and you don't have to deal with cookbook customizations. The only real problem I see with #2 is the case where someone else has to re-provision the box. Maybe you're no longer with the project or they deleted the box. That person doesn't know what packages you installed and configuration steps you took. Of course you could offset that by documenting it somewhere. But if you're going to do that then I would just use the shell provisioning that Vagrant supports.

I've also been surprised that there aren't common stacks available (though I learned alot more because there wasn't ;)). Maybe it is because the chef cookbooks change so it would have been hard to include those and keep everything working. But I use librarian-chef and I think it would eliminate that problem. Let me know if you want to create some together. I think that would be a big help to a lot of new people. Oh there is the rails sponsored one that I just discovered the other day https://github.com/rails/rails-dev-box. Again though I would like to see more of those for other stacks.

[Karel]

Thanks all for your input, I indeed sticked to #1. 

I built a little vagrant-starter I user for my new projects here : https://github.com/karellm/vagrant-starter

It includes the stacks I use the most : rails, nodejs and php (for wordpress sites). Though it is highly opinionated and isn't really intended to be open-sourced. 

On Monday, 15 October 2012 11:53:45 UTC-4, Dave Pijuan-Nomura wrote:

Hi Karel,

We use veewee to build our baseboxes from scratch. It allows us to automate basebox creation, and puts the basebox config under version control. That way, we know exactly how our basebox is built, and we can tweak it and rebuild it as needed. Once it's built, we store the basebox on s3 for easy access.

Here's a good article on getting started with veewee.

Dave

[Nick Silkey]

A 'vagrant up --no-provision' should bring your box(es) up without firing the provisioner(s).

On Oct 19, 2012, at 9:02 PM, Renoir Boulanger <ren...@gmail.com> wrote:

> All a good read, this thread.
>
> I tried both with puppet and chef.
>
> A thing that struck me is that every time I start the machine (vagrant up), it rebuilds completely the provions.
>
> Although interresting, it makes me realize that not only we need to make the proper recipes/modules combinations, we have to figure out proper checks to skip installation.
>
> Do anybody in here has a similar line of thought or figured a good way to prevent constant rebuild at every "vagrant up"?
>
> Thanks
>
> Renoir B.

[Mathias Lafeldt]

Renoir,

I'm not familiar with Puppet, but Chef recipes, or more precisely the
resources used by them, should check that things aren't installed
twice. That's done implicitly for files (using checksums to see if
something has changed) and can be done explicitly for other resources.
For example, you can say that the "bash" resource should only run
script X to compile tool Y when the tool is not already installed.

So, to answer your question: if the provisioner does the same
(time-consuming) thing over and over again, it's a problem with the
recipe.

-Mathias

[Karel]

When you do a vagrant up, it runs the provisioning but your provisioning system should see that there is nothing new to do.

So basically, it does run the provisioning but it shouldn't take more than couple seconds because the actual provisioning has already be done.

[Stefan Goethals]

The way puppet and chef are meant to be used is to write the recepies as such that
re-running them on a 'ok' system makes no changes to that system at all.

So for instance if a package is already installed, they will notice that and not try re-installing.
If a config file has the desired content it will not be re-written.


Zipkid.