[chef] Re: Re: Re: Re: RE: Running chef in multiple environments

[Sean OMeara < >]

I'd like to chime in here...

As Lamont said... Chef's lineage definitely derives from CFEngine. The
whole idea is that recipes represent state policy that your machines
are supposed to be in. Running on a control loop ensure that they're
really that way.

Running chef-client on a control loop interval ensures that anything
that perturbs the system (broken code, malicious code, h4x0rs, junior
sysadmins, cowboy developers) will be repaired.

Think about if this way: if your application has a security
vulnerability that allows an attacker to chmod 777 /etc/shadow... do
you want to wait until your next production change window to repair
it? Or do you want to fix it as quickly as possible?

-s


On Wed, Jul 30, 2014 at 6:34 PM, DV 
<
 >
 wrote:
> That's a great point - there'd better be a process to ensure chef-client
> runs frequently enough so that all servers are in line with Chef and don't
> fall too far behind.
>
> As far as my suggestion of not running chef-client daemon on production
> runways - it has at least one weakness: if there's any kind of auto-scaling
> going on, of course chef-client will use whatever role happens to be on Chef
> server when bootstrapping new servers. Similarly for if a server dies and
> needs to be re-built or if there's a host that relies on Chef for latest
> configuration (such as munin, or perhaps a client app that needs to know
> hostname(s) of database servers to connect to).
>
> My company went with pre-prod + prod instances of Chef server from the very
> beginning, and so far it's saved us a lot of trouble since we only allow the
> most experienced Chef users to promote changes to prod Chef.
>
>
> On Wed, Jul 30, 2014 at 9:59 AM, Lamont Granquist 
> <
 >
> wrote:
>>
>> On 7/30/14, 12:30 AM, DV wrote:
>>>
>>>
>>> So, my point is something my colleague brought up recently - why run
>>> chef-client as a daemon on production runway at all? Why not run it on
>>> demand, such as when changes need to go out to production? From my
>>> experience anyway, our production runways never get any updates when they
>>> are actually serving production traffic, so it's safe to turn chef-client
>>> off to prevent any accidental promotion of cookbooks, environments, or 
>>> roles
>>> to production.
>>>
>> Historically, change in IT did not happen very often and Chef inherits a
>> lot of the old CFEngine model where you want to run it periodically and 
>> gain
>> the 'self-healing'/'computer immunity' features so that servers are always
>> being fixed back into compliance.  In places that I've worked in the past,
>> change management was pretty abusive, so if CFEngine wasn't running at 
>> least
>> nightly then it'd never run for months (or sometimes years -- I can think 
>> of
>> a few servers at a company that I worked at for 3 years which were never
>> deployed to).   If you had the model where you only kicked it off when a
>> 'Change' happened then it became terrifying to think about what might occur
>> when you ran it because it hadn't been run in so long.
>>
>> So, that's the background.  That may not make sense any more in a CI/CD
>> agile kind of world.
>>
>
>
>
> --
> Best regards, Dmitriy V.