I agree with these comments. I would also add that the best practice in production (aka ops) would require every change, regardless if implemented via manual human, manual runs of chef-client, or automated runs of chef-client, should be associated with a change record and change board approval. With that said, if you automate chef-client's execution through cron or as a process, prior to every execution, the changes that would be pushed with the next run need to have a CR and need to have been approved by the board.
So, if you can get that succinct process running like a tight ship, then automating the runs would be the way to go.
Sent from my iPhone
On Jan 14, 2014, at 9:32 AM, Brad Knowles <
">
> wrote: On Jan 14, 2014, at 6:02 AM, Sam Darwin <
">
> wrote:- the recipes would need to always be in a perfect and functional state.
let's say that you were experimenting with something. and then every single
server in your environment grabs that recipe and runs it. this could affect
the entire system, every single server.
Don't do this experimentation on your production environment. That should be locked down seven ways from Sunday. Even if a new version of a cookbook were to get pushed out, it wouldn't get used on any production servers until the production environment was updated to allow that newer version.Do this experimentation in your Development environment, and once it's rock solid, then you push to Staging. From there, once it's baked in for a while, you can push to Prod.And you can do all of this on a single Chef server.- even if you had two separate chef servers, one for production and one for
testing... so that the production server was designed to always be correct.
even then, there is some small chance for human error, and it would propagate
automatically and without necessarily being watched at that moment, to every
single server in the environment.
Human error is always a possibility. If you do your job right, with the right unit and integration tests in your code, appropriate acceptance and smoke testing in a suitable "Dev" or "Lab" environment, then the biggest risk is the humans who are pushing the buttons.- you might have recipes that are designed to handle 95% of the tasks, but
there is still a bit of human intervention, or the developers are still logging
into the servers and tweaking things . an automated chef run might cause a
conflict between the recipe and the manually added changes.
Don't let developers log into production servers. In fact, don't let your admin staff log into production servers. Only automated systems should be doing anything on them -- if a human being has to log in, then that machine should be marked as down or broken and pulled out of production.- the recipes are in a state of flux, you might apply them carefully and
methodically to only a few servers at a time.
Recipes as they are being developed should be in a state of frequent flux, but recipes as they are pushed out to the Prod environment should be locked down within an inch of their life.--Brad Knowles <
">
>LinkedIn Profile: <http://tinyurl.com/y8kpxu>
|