[chef] Re: Re: Re: Chef feature howtodo


Chronological Thread 
  • From: Ranjib Dey < >
  • To: " " < >
  • Subject: [chef] Re: Re: Re: Chef feature howtodo
  • Date: Tue, 30 Jun 2015 17:16:04 -0700

the puppet workflow you have mentioned involves a workstation as well, from the place where you edit the master node list or update the external node classifier backends (may be a mysql db). 
master node list is treated as data as opposed to code, and not checked in , can be obtained by knife node list. earlier you would need the access to source repo of puppet code, here you'll need a access to the chef server. you still have a dependency .. and its the source code repo of puppet server (and even and external node classifier backend, if you use that feature).
as other have mentioned, masterless provisioning is possible, where you assemble the cookbooks via berks and then run chef in solo mode (which is very similar to masterless puppet installations) ... now chef-provisioning is fairly stable, you can use that to even bridge that gap, and it will also save the node objects locally.. which in turn you can check in. i can see its usage in offline analysis or reporting. validator less bootstrapping is also something you can use in conjunction

keep  asking things that are not clear :-), if its too complicated or too many buzzwords etc..  We can create a puppet to chef migration wiki/blog ... something

On Tue, Jun 30, 2015 at 4:33 PM, Nico Kadel-Garcia < " target="_blank"> > wrote:
Or use chefdk and chef-solo with FQDN specific node files, and do not run a chef server at all. I've come to much prefer this for small environments: chefdk gets you BerkShelf, and you don't have to put unencrypted keys or plain text passwords on the distinct chef server itself.
Yo,

I¹m in a Chef class today and it¹s pretty fun.

My only previous experience with config mgmt is with Puppet and I¹m trying
to figure out how to do one thing in Chef that I could do there.

In Puppet I could define a single flat-text file with parameters about all
the client/node devices (IP, hostname, which packages to install,
parameters for them etc) then if the Puppet service on the server was
started, and one of the client nodes (specified in that config file)
contacted the server at some later time then the client node would get set
up per the config.

The beauty of this was just that you didn¹t need a workstation to do knife
bootstrap and things like that. If the client had the required client
software already installed and it contacted the server then it would get
configs/packages installed that the server had for it.

What approach could I use with Chef to do something similar?

Give your machines a Chef Client configuration (client.rb) and a validation key from the chef server (or hosted chef) which allows them to self-register. You can use the host-name as your node name in the client configuration or similar. You may obviously then supply a particular run list, allowing a machine to say what it needs to be, as opposed to having that knowledge hard-coded in your puppet master text file.

"When the package is installed, and the software is started, it will contact the server and get the 'configs/packages installed that the server had for it'"

cheers,

--aj




Archive powered by MHonArc 2.6.16.

§