Ranjib Dey
< >
writes:
this was also discussed in last summit. version everything (roles,Personally I'm not a fan of the push for versioned roles. As one version
environments.. etc) was an item in chef 12 wish list.. may be @btm have
some update?
of a familiar joke goes: 'Some people, when confronted with a problem,
think "I know I'll use versions". Now they have 2.5.1 problems'
Roles provide some nice functionality in certain cases: sharing common
attributes and run_lists across groups of servers or setting attributes
at the right precedence level.
It seems many of the issues encountered when using roles can be better
addressed by means other than versioned roles. For me it helps to view
them simply as data and you don't generally version data. You _do_
carefully manage change to your data or make sure that data is used and
accessible where it is most appropriate and not shared when it isn't.
The Policyfile idea Dan mentioned is similar to some of the stack
freezing ideas we use for working with AWS and cloudformation.
Using (WIP): https://github.com/heavywater/knife-cloudformation/
'knife cloudformation export'
will export a current cfn stack in a state such that an exact copy of
the dependency tree can be recreated again.
On Wed, Jan 15, 2014 at 7:59 AM, Sam Pointer
< >wrote:
At the risk of continually pimping out the same talk to this list, we ran
into a number of these issues at EA and discuss them here:
http://lanyrd.com/2013/ldndevops-january/scbzkw/.
Along with disciplined source control: the concept of releases, etc. we
built some tooling to:
- automatically handle cookbook versioning and version pinning in roles
- monitor for run_list conformity
A great number of problems in this area would be solved with the ability
to version roles, something we raised 2 years ago I raised again with Chris
Brown during a recent speaking engagement with him. Instead we have the
cookbook wrapper pattern which in practice isn't especially great. Others
in our circle have approached this from the point of view of having Jenkins
move cookbooks through environments inspecting the output of chef spec and
minitest runs, lints and whatnot before gating the release to live. In the
round however the problem of continually deploying *code* to production is
a development problem and one that is quite mature in terms of tooling and
practice. Operations people should be looking to their development teams
for guidance. Devops works both ways ;)
Sam Pointer
Lead Consultant
www.opsunit.com
On 14 January 2014 18:57, Lamont Granquist
< >
wrote:
Yeah, the answer is to use environments and to explicitly version pin all
your cookbooks. I'm not sure I'd suggest going down the road of explicitly
version pinning in your cookbook deps, but instead your promotion from
integration to production (or however you have your environments setup)
should be to copy the exact version pins in the integration environment
file and push them into the production one. Ideally you have a full CD
pipeline where you start with "devops"ers working on their laptops doing
local changes to cookbooks and using test-kitchen to validate them against
virtual images. Then those changes are published and made available as a
cookbook version on the chef server, and a jenkins environment that floats
on cookbook versions picks them up and runs test-kitchen against them, and
if they pass they're promoted to a full-sized integration environment where
again there's a test suite that validates that the changes work. If you
swallow the whole koolaid then you will eventually do a push to production
with any CRB approval since you've proved the change works via multiple
testing steps in your different environments.
You don't even really need semantic versioning in this system, you just
need to keep cookbook versions unique and frozen. The set that gets
deployed is the set that was tested together and works, you don't really
want any version constraints in your cookbooks at all, you just test latest
against latest and if its good you ship it.
The same basic workflow also works if you rip out all the CD, but then
you've got manual Q/A process and humans pressing buttons to do the
environment promotion, and a CRB involved at some point before it goes to
prod.
On 1/14/14 8:15 AM, Dylan Northrup wrote:
On Tue, Jan 14, 2014 at 7:02 AM, Sam Darwin
< >wrote:
it seems like the ideal case of using chef, would be to run it as aIf you pin recipes (directly in run_lists or indirectly in environments
cronjob
every day on the servers, to keep the servers in their proper and perfect
configuration.
In practice, we are currently not doing this. there is more than just
one
simple reason for it.
- 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.
or roles), you can upload new versions of recipes without fear of having
them propagate to unintended servers. An operational pattern I've used in
the past is to have dev servers with versions that aren't pinned (so they
get the latest version of whatever cookbooks are out there) and have every
other type of server (integration, reference, production, etc) have
explicitly pinned versions. This allows "testing" and "development" of
cookbooks in the same chef organization/server (insuring you're don't have
any "Dev is different than ref is different than int is different than
prod" issues) without concern that new cookbook versions will affect
production nodes (or any other ones, for that matter).
Two things you'll want (or need) to do if you put this into practice:
1. Verify your pinning all the way down for non-dynamic cookbooks. We
distribute user information (logins, ssh keys, sudoers, etc) via a
generated cookbook. The version of this cookbook will change every time
it's newly generated. Since we want to use the most recent version of this
cookbook every time, we do not do any pinning for this cookbook. But for
cookbooks that are not dynamic, everything gets pinned explicitly or via
dependent pinning. So, the platform cookbook explicitly pins apt, bash,
system ruby, etc; nginx cookbook explicitly pins the lua cookbook and any
module cookbooks it depends on; tomcat cookbook explicitly pins the java
cookbook version; and so on. Make sure it's pinned turtles all the way
down. It's a pain if you have to retrofit, but worth it IMO.
2. Every time you upload a cookbook that will be pinned, it is frozen.
Every time, no exceptions. What you don't want, after going through all
the trouble of making sure you know exactly what version is going to go out
on a specific type of node, only to have that version change.
Still doesn't mean you can't propagate an error to many machines, but
with additional gates in place, it makes it more difficult for this to
happen unintentionally.
Archive powered by MHonArc 2.6.16.