Hi,
> Am 29.05.2015 um 19:56 schrieb Daniel DeLeo < "> >:
> 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.