I’m thinking we might have to go down this route and not schedule chef-client to run automatically, at least until we can re-work the roles into
cookbooks.
I’d prefer to run separate chef servers to minimise the risk of a cookbook being promoted straight to production (it only takes someone to use
–force and it’ll deploy to all environments, overwriting any cookbook restraints), but that makes it harder to run something like nagios which monitors servers from all environments.
Thanks for all the ideas though! Certainly something we need to have a good think over before committing ourselves to a particular route.
It’s a shame there’s no full case studies written up on the getchef.com site, detailing how some larger companies are implementing chef. I know
there’s some videos on youtube (ancestry.com etc), but they can cover everything.
Thanks
Tom
From: DV [mailto:
Sent: 30 July 2014 08:31
To:
Subject: [chef] Re: RE: Running chef in multiple environments
It seems there's two common answers to the "role problem":
* Set up multiple Chef servers
Both are kind of a pain in the ass for various reasons...
Having multiple Chef servers means I can't depend on Chef to seamlessly provide configuration across environments, where needed (such as relying on Chef's search function). I also have to ensure all of my Chef servers have correct versions
of Chef artifacts.
Not using roles... Well, I just don't like the idea. Roles are just such a great way to group things together as well as separate Chef's functionalities into distinct steps. Roles are also very simple to look at - just one file, no versions
to increment, low hassle.
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.
That way you can keep using just one Chef server and keep using roles.
On Fri, Jul 25, 2014 at 6:01 AM, Justin Franks <
" target="_blank">
> wrote:
Tom,
We have spent much time with Opscode coming onsite to help train us. We also have similar environments to you. After talking with Opscode instructors it was decided to
create a chef server for each environment. For us it works well.
It may work well for you too.
*************************
Justin Franks
Lead Operations Engineer
SaaS, Cloud, Data Centers & Infrastructure
Lithium Technologies, Inc
225 Bush St., 15th Floor
San Francisco, CA 94104
tel: +1 415 757 3100 x3219
Hi,
We’re using chef to build our new hosting environment, which comprises of 3 environments (dev, staging and production), and manage our own chef server. So far we’ve been using chef environments to change variables etc between the
3 environments. However, we’ve come across an issue whereby we need to test a new role in our dev environement.
With cookbooks we can restrict the version that is used between environments, but there doesn’t seem to be anything similar with roles (or data bags, which is another issue).
I’m just wondering, what do people do in this situation? Should we be looking to run a separate chef server in each environment instead of using chef environments?
Thanks
Tom
HBVB trading as Bauer Corporate Services (BCS) is a division of the Bauer Media
Group the largest consumer publisher in the UK, and second largest commercial
radio broadcaster. BCS provides financial services and manages and develops IT
systems on which our UK publishing, broadcast, digital and partner businesses depend.
The information in this email is intended only for the addressee(s) named above.
Access to this email by anyone else is unauthorised. If you are not the intended
recipient of this message any disclosure, copying, distribution or any action
taken in reliance on it is prohibited and may be unlawful. HBVB do not warrant that
any attachments are free from viruses or other defects and accept no liability for
any losses resulting from infected email transmissions.
Please note that any views expressed in this email may be those of the originator
and do not necessarily reflect those of this organisation.
HBVB is registered in England; Registered address is
1 Lincoln Court, Lincoln Road, Peterborough, PE1 2RF.
Registration number 8453545
--
Best regards, Dmitriy V.
|