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.
Nico Kadel-GarciaEmail: n " target="_blank">Sent from iPhoneYo,On Wed, Jun 24, 2015 at 10:37 AM Chris Magnuson < " target="_blank"> > wrote: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.