Vagrantfile chef.run_list Vs. "knife solo cook"

Chef Infra (archive)
1

Hi,

I’m fairly new to Chef but at work I’ve noticed my approach is different to
some of my co-workers.

We all work remotely and use github and vagrant w/ chef for local
development.

From our workstation it’s mostly capistrano deployment to production
servers.

There are two apps that we’ve just updated the vagrant builds.

For one of these apps my coworker put his run lists in the Vagrantfile -
which works fine.

So when you “vagrant up” the recipes run and everything gets pretty much
done.
Then there’s just a rake db seeding task to finish the build off.

The other app is the one I’ve done, but the run list is in a node.json file.

“vagrant up” just boots up the VM … then I use “knife solo cook” to run
the recipies.

Ex: knife solo cook vagrant@192.168.33.10

I’m thinking the “knife solo cook” method is better as it more versatile.
These same recipes are not bound to vagrant and can easily be run on a
remote server.

What do you think? Am I missing something?

2

The run-list being in json or in vagrant doesn't make a difference in terms
of what is run.

I would say 'better' depends on how you are running chef on your servers.
Solo or Client?

Nic

On Thu, Jul 11, 2013 at 10:14 AM, Rudi ooly.me@gmail.com wrote:

Hi,

I'm fairly new to Chef but at work I've noticed my approach is different
to some of my co-workers.

We all work remotely and use github and vagrant w/ chef for local
development.

From our workstation it's mostly capistrano deployment to production
servers.

There are two apps that we've just updated the vagrant builds.

For one of these apps my coworker put his run lists in the Vagrantfile -
which works fine.

So when you "vagrant up" the recipes run and everything gets pretty much
done.
Then there's just a rake db seeding task to finish the build off.

The other app is the one I've done, but the run list is in a node.jsonfile.

"vagrant up" just boots up the VM .. then I use "knife solo cook" to run
the recipies.

Ex: knife solo cook vagrant@192.168.33.10

I'm thinking the "knife solo cook" method is better as it more versatile.
These same recipes are not bound to vagrant and can easily be run on a
remote server.

What do you think? Am I missing something?

3

I'm also fairly new to the team and I don't think there's much Chef in
production at all - solo or client.

It's mostly just in use in the development environment.

Production boxes are mostly managed servers that we just contact the host
about to configure (pretty old skool and years of legacy in there).

On Thu, Jul 11, 2013 at 11:18 PM, Nic Grayson nic.grayson@banno.com wrote:

The run-list being in json or in vagrant doesn't make a difference in
terms of what is run.

I would say 'better' depends on how you are running chef on your servers.
Solo or Client?

Nic

On Thu, Jul 11, 2013 at 10:14 AM, Rudi ooly.me@gmail.com wrote:

Hi,

I'm fairly new to Chef but at work I've noticed my approach is different
to some of my co-workers.

We all work remotely and use github and vagrant w/ chef for local
development.

From our workstation it's mostly capistrano deployment to production
servers.

There are two apps that we've just updated the vagrant builds.

For one of these apps my coworker put his run lists in the Vagrantfile -
which works fine.

So when you "vagrant up" the recipes run and everything gets pretty much
done.
Then there's just a rake db seeding task to finish the build off.

The other app is the one I've done, but the run list is in a node.jsonfile.

"vagrant up" just boots up the VM .. then I use "knife solo cook" to run
the recipies.

Ex: knife solo cook vagrant@192.168.33.10

I'm thinking the "knife solo cook" method is better as it more versatile.
These same recipes are not bound to vagrant and can easily be run on a
remote server.

What do you think? Am I missing something?

4

On Thu, Jul 11, 2013 at 4:14 PM, Rudi ooly.me@gmail.com wrote:

For one of these apps my coworker put his run lists in the Vagrantfile -
which works fine.

So when you "vagrant up" the recipes run and everything gets pretty much
done.
Then there's just a rake db seeding task to finish the build off.

The other app is the one I've done, but the run list is in a node.jsonfile.

"vagrant up" just boots up the VM .. then I use "knife solo cook" to run
the recipies.

Ex: knife solo cook vagrant@192.168.33.10

I'm thinking the "knife solo cook" method is better as it more versatile.
These same recipes are not bound to vagrant and can easily be run on a
remote server.

What do you think? Am I missing something?

The recipes are not bound to Vagrant in either case, so the biggest
difference is user experience.

Is the point of the Vagrant configuration to run your application, or to
run Chef? If the application is the important part, is Chef simply an
implementation detail, or do you expect everyone using Vagrant to be
comfortable using Chef too?

When Chef is just an implementation detail, I prefer making Vagrant
responsible - adding "knife solo" means more dependencies, and more for
your users to understand before they are productive.
On the other hand, if the point is to let people get comfortable with Chef,
it might make sense to avoid some of Vagrant's magic. If you're using (or
planning on using) "knife solo" on your production machines, using it for
your local VMs is a good way to build experience in a safer environment.

Of course, you can provide a Vagrantfile that makes it easy to provision
your VM, and still use the same cookbook(s) via "knife solo".

Zac

5

I would recommend to stay with vagrant + chef solo for either local vms,
cloud instances or managed servers. The benefit is that you have the same
configuration mechanism (Vagrantfile), same CLI (vagrant up) and can use
the same vagrant plugin ecosystem (e.g. vagrant-omnibus for installing
chef) for all these environments - it's just harmonized.

For managed servers vagrant does not seem to be a good fit at first (thus
you probably use knife.solo at the moment -- and I have used it too in the
past), but you can use the vagrant-managed-servers provider for this:

On Thu, Jul 11, 2013 at 5:23 PM, Rudi ooly.me@gmail.com wrote:

I'm also fairly new to the team and I don't think there's much Chef in
production at all - solo or client.

It's mostly just in use in the development environment.

Production boxes are mostly managed servers that we just contact the host
about to configure (pretty old skool and years of legacy in there).

On Thu, Jul 11, 2013 at 11:18 PM, Nic Grayson nic.grayson@banno.comwrote:

The run-list being in json or in vagrant doesn't make a difference in
terms of what is run.

I would say 'better' depends on how you are running chef on your servers.
Solo or Client?

Nic

On Thu, Jul 11, 2013 at 10:14 AM, Rudi ooly.me@gmail.com wrote:

Hi,

I'm fairly new to Chef but at work I've noticed my approach is different
to some of my co-workers.

We all work remotely and use github and vagrant w/ chef for local
development.

From our workstation it's mostly capistrano deployment to production
servers.

There are two apps that we've just updated the vagrant builds.

For one of these apps my coworker put his run lists in the Vagrantfile

  • which works fine.

So when you "vagrant up" the recipes run and everything gets pretty much
done.
Then there's just a rake db seeding task to finish the build off.

The other app is the one I've done, but the run list is in a node.jsonfile.

"vagrant up" just boots up the VM .. then I use "knife solo cook" to
run the recipies.

Ex: knife solo cook vagrant@192.168.33.10

I'm thinking the "knife solo cook" method is better as it more versatile.
These same recipes are not bound to vagrant and can easily be run on a
remote server.

What do you think? Am I missing something?