Chef feature howtodo

Chef Infra (archive)
1

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?

Thanks!

Chris

2

Yo,

On Wed, Jun 24, 2015 at 10:37 AM Chris Magnuson chrismagnuson@interush.net
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

3

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-Garcia
Email: nkadel@gmail.commailto:kadel@gmail.com
Sent from iPhone

On Jun 23, 2015, at 19:22, “AJ Christensen” <aj@junglistheavy.industriesmailto:aj@junglistheavy.industries> wrote:

Yo,

On Wed, Jun 24, 2015 at 10:37 AM Chris Magnuson <chrismagnuson@interush.netmailto:chrismagnuson@interush.net> 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

4

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 <
nkadel@skyhookwireless.com> 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.

Nico Kadel-Garcia
Email: nkadel@gmail.com
Sent from iPhone

On Jun 23, 2015, at 19:22, "AJ Christensen" aj@junglistheavy.industries
wrote:

Yo,

On Wed, Jun 24, 2015 at 10:37 AM Chris Magnuson <
chrismagnuson@interush.net> 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