|
I can’t think of a way to enforce that except for a “thou shalt always add the X role to thy VM’s” and a cluebat to enforce it. Perhaps someone else can think of something.
We have a ‘base’ role that gets applied to absolutely every node we have, VM’s or not, that contain things like chef client config, ntp, timezone, base syslog, collectd, etc, and while we’ve never had to enforce it (small team etc) if I had to start enforcing
it I’d probably setup a script that polled the node configs and add the base role back into the run_list if it wasn’t there already. And then haul out the aforementioned cluebat and chase down the offender. :)
cheers
mike
--
Michael Hart
Arctic Wolf Networks
M: 226-388-4773
On Sep 25, 2014, at 11:53, Phil Oliva <
">
> wrote: Daniel,
We're trying to enforce some governance on all the nodes that bootstrapped to our chef server. Coming from a large organization and trying to onboard many groups to our ha chef server infrastructure on our Opennebula based private cloud.
We provided a single bash context script (coined "one init.sh script to rule them all") as a point of entry that groups can put in their vm template context along and with some standardized chef related template variables (chef_server_url, validator_key, bootstrap_json,
chef_environment, etc..). Our bash script installs the recommended chef client package version (our team determines which version will get used) then runs chef-apply blocks to setup vm networking (nice because resources work on RH + Ubuntu ) and then setups
up the /etc/chef/chef-client.rb properly and runs chef-client based on variables provided. This approach has worked well thus far.
We also wrote a hook for our hypervisors to cleanup node/client data when vms get deleted/recreated. Our chef server has a special admin account for that hypervisors can use to run pychef and manage it.
That was all the logic we wanted to add to init.sh script. Anything that needs to be done to node after chef-client is assumed to be in a cookbook. Don't want to modify the init.sh very often (ideally never).
So I wanted to create a base cookbook that has a recipe that forces nodes checking every 15 minutes into server with chef-client runs using a cron or chef-client daemon. This recipe would need to survive a DR scenarios if our chef server ended up needing to
be recreated and data loss was present. Example if node/client data not on server and vm still has client.pem (delete client.pem if getting "Failed to authenticate to .* with key /etc/chef/client.pem" message).
My question came about because I had an idea that I wanted our staging HA chef server to force people to run this recipe/cookbook even if they didn't specify it in their own run_list. This way people would learn if their cookbooks were truly idempotent (which
is our end goal) in testing lab before it ended up in production. If people choose to proceed to production with non-idempotent cookbooks well then operators would need to know they would need to destroy vm and recreate any time they want cookbook rerun.
Phil
----Original Message-----
From: Daniel DeLeo [
">mailto:
] On Behalf Of Daniel DeLeo
Sent: Wednesday, September 24, 2014 4:47 PM
To:
">
Subject: [chef] Re: Enforce certain recipe in run_list
On Wednesday, September 24, 2014 at 10:03 AM, Phil Oliva wrote:
Hi all,
Is there a way to enforce all nodes that bootstrap with chef-client to certain chef-server run extra recipe(s) on top of their specified run list? Basically want to create a base cookbook for my organization and ensure all managed bootstrap nodes have run certain
recipes from this cookbook.
Phil Oliva
To start this one over from the beginning, what do you mean by "ensure all managed bootstrap nodes have run certain recipes from this cookbook?” Are you worried that users in your organization will unintentionally create nodes without these recipes? Or that
users will intentionally create nodes without these recipes? Do you need to manage the set of “required” base recipes over time? What kinds of users create new nodes, and how do they specify their customizations?
--
Daniel DeLeo
|