- From: Dan Adams <
- To: <
- Subject: [chef] Re: Re: Chef in "Pure Infrastructure-As-Code" Mode?
- Date: Sun, 24 Jun 2012 16:22:19 +0100
- Mail-reply-to: <
On 24.06.2012 14:48, Dylan Northrup wrote:
I like the 'infrastructure-as-code' idea, but for tracing changes
by chef on a node I would prefer a way to log changes made to the
and by whom. Without the automated procedures detailed later in this
thread, there can be a disconnect between what's in git and what's in
chef. Being able to view logs of cookbook uploads, role changes,
knife ssh runs would be tremendous from an operational perspective in
tracking down what's changed recently (to which the answer is always
"Nothing changed, honest. It just stopped working." ;-)
I want to say I remember mention of increased logging at one of the
ChefConf talks I viewed, but cannot be sure. If this was available,
it would be an invaluable operational tool.
Another approach to provide some of these abilities (in addition to or
instead of some of the other measures mentioned) is to use a custom chef
report handler, which is executed at the end of the chef-client run.
Various handlers are available that will fire off a notification of what
resources have changed on a node to eg graphite, nagios, a log, or
wherever. Since chef is idempotent, in theory most chef-client runs will
be no-ops and so changed resources will be rare and due to manual
changes somewhere in your infrastructure. However, whilst this is true
of simple recipes, it is not necessarily true of more complicated ones
that use search and conditionals etc.
We are using a simple custom report handler to output to the console a
list of resources that have changed on a run. However, we have
additional requirements coming down the pipeline within the organisation
to process this information in a more sophisticated manner, and more
specifically to log it centrally somewhere and tie it to authorised git
commits, in turn tying these to authorised change requests. The wider
Chef is used within enterprises, the more common this kind of
requirement will become I suppose.
Archive powered by MHonArc 2.6.16.