[chef] Re: chef-provisioning / knife-zero


Chronological Thread 
  • From: Roland Moriz < >
  • To:
  • Subject: [chef] Re: chef-provisioning / knife-zero
  • Date: Fri, 29 May 2015 22:21:43 +0200

Hi,

Am 29.05.2015 um 21:55 schrieb Torben Knerr < " class=""> >:

Hi Roland,

if you are managing a fixed set of nodes you might also want to take a look at vagrant [0]. It plays nice with chef_zero (and all the other chef provisioners) and allows you to define your nodes in a "Vagrantfile". You give them a name and then provision them via `vagrant provision <name>` for example.

I’m aware of this but i really like the "all-chef-approach" of chef-provisioning, e.g. converge the chef-provisioning recipe locally on your node. 

I also think that Vagrant’s external provider plugins will probably suffer under the impression of the Terraform project, which kind of replaces Vagrant for that. Terraform is nice but it’s another „external“ tool (and it doesn’t support chef-zero atm). 

regards
Roland




It's just another option, a bit less chef specific though. Depends on what you need and want...

HTH, Torben




On Fri, May 29, 2015 at 8:10 PM, Roland Moriz < " target="_blank" class=""> > wrote:
Hi,

> Am 29.05.2015 um 19:56 schrieb Daniel DeLeo < " class=""> >:
> On Friday, May 29, 2015 at 10:45 AM, Mark Harrison wrote:
>> As I understand it (and one of the creators/maintainers of chef-provisioning please step in and correct me if I'm wrong) chef-provisioning's intended use is for the initial bootstrapping of the machine, and it would 'replace' commands like knife ec2 server create. The initial converge when creating the machine would then use something like the chef-client cookbook to set up chef client against the chef server and you would use daemonized/cronned/manual chef client runs on the server itself against the chef server. After the initial bootstrap is complete, chef-provisioning itself would never run a converge unless the machine needed to be recreated.
>
> Chef Provisioning knows when you’ve updated the run_list or node attributes, and will reconverge a machine if it detects that one of these things has changed. Otherwise, it assumes the node is up to date. I don’t think it can tell if cookbook have been updated outside of Chef Provisioning (e.g., you run Chef Provisioning, update some cookbooks, then re-run Chef Provisioning).


Thanks for all replies, I've found a working solution:


1. Initial bootstrapping with chef-provisioning and the "with_chef_local_server " option which starts a local chef-zero instance:

  `bundle exec chef-client -z provisioning/example.rb`

  Example: https://gist.github.com/rmoriz/f293ca1402591c5469ae


2. single node converging with knife-zero. The key is to configure knife-zero to use the same port number when SSH forwarding the local knife-zero instance to the nodes as chef-provisioning does. See https://github.com/higanworks/knife-zero/issues/31 for the knife.rb config option.

   `knife zero chef_client "name:<node>"`

This combination is IMHO the best "server-less" approach possible with chef because both use chef-zero.

I'll now retiring all my knife-solo/chef-solo setups as soon as possible and migrate to this combination.

best regards
Roland






Archive powered by MHonArc 2.6.16.

§