On Tue, Jun 11, 2013 at 6:18 PM, Jamie Winsor <
" target="_blank">
> wrote:
Hey Elvin,With the exception of my 8 person team at Riot, nobody else really knows Ruby. It's been quite a challenge for us over the last two years to create a workflow and supporting tools to enable non-Ruby and non-engineering types to leverage Chef properly.The number one way that we were able to empower our software engineers and operations folks was to focus on reducing complexity.The second most important thing that we've done is to create a clean room for people to live in by prescribing and documenting a workflow for people to follow.There's just no reason to need to explain anything past a cookbook to an engineer or an operator. This cookbook is for a specific component in your infrastructure and it contains a README. This README contains instructions for which recipes to place on a machine to turn it into the thing that you want it to become (this is where a Role COULD have come in). And the operator/engineer uploads this cookbook into their Chef server and locks their environment to use just the version of the cookbook that you gave them. Bonus points because you remembered to explicitly state your dependencies and gave them some nice version constraints in your cookbooks' metadata.We have some still non-open sourced (soon to be) tooling here that assists this process even more, but this is a pretty good summary of the generic workflow we built off of. With the addition of the `berks apply` command (new in 2.0) you also could be "promoting" the state of entire environments throughout some sort of release pipeline.This works for us, but I think it would work for you too.--Jamie Winsor@resetexistencehttps://github.com/resetOn Tuesday, June 11, 2013 at 3:05 PM, Elvin Abordo wrote:
/sigh proofreading will be the end of me. I was going to mention something about the food fight show, but the quote escaped me.On Tue, Jun 11, 2013 at 6:02 PM, Elvin Abordo < " target="_blank"> > wrote:<zips up flame suit>roles are designed to make the whole system flexible and easy to use.It really depends on your business requirements and current situation. You could be in a situation where you're in a team that is slow to adopt new cultural and workflow changes.Telling a team in that situation "Ok you need to learn just a bit of ruby in order to append the resolv.conf settings. By the way since you're modifying code you need to go through a brand new process before rolling out to production. Oh and remember how you would test in Dev? yea that's not going to work anymore because Dev is now Production" Versus. "Here's a role that's applied to all of our servers, these settings shouldn't ever really change because that's how roles were designed, but since we'd like to add another dns server follow the same format that is in this role"if you're in a team like Riot Games who off the bat know ruby or development processes then hell ya cookbook all the things!While beating the dead horse ..they're there for certain use cases and allowing flexibility. Not everybody is a "devops" ninja. someone on the food fight show said that.To really beat the horse dead. Only the person/team implementing chef needs to use the right ingredients at the right time. You can't take someone else's ideas and or concepts and apply it to your environment expecting Nirvana.With all that said. One needs to take care in using roles. Like cooking there needs to be a balance of everything in my opinion. Roles really need to be used as they were designed [0]"A role is a way to define certain patterns and processes that exist across nodes in a Chef organization as belonging to a single job function."It's safe to say that if a new guy comes into my environment who is new to chef and the culture of devops they can see how my environment looks without having to dig into the chef recipes one by one.--On Tue, Jun 11, 2013 at 5:27 PM, Joshua Miller < " target="_blank"> > wrote:We've moving towards "cookbooks in place of roles". Not being able to version lock roles is a real problem. Note that if you're currently relying on the role-level precedence you may need to rethink.On Tue, Jun 11, 2013 at 12:35 PM, Ranjib Dey < " target="_blank"> > wrote:i use a combination of both, if i can achieve my customizations just by means of attributes and aggregating recipes, i always prefer to use roles. Its cleaner, by design roles does not allow any logic except attributes and a run list. If i need anything more than this, i use cookbooks/recipes.On Tue, Jun 11, 2013 at 12:31 PM, Larry Wright < " target="_blank"> > wrote:A few months ago there was some discussion about using cookbooks as containers in place of roles. This started with a blog post that advocated always using cookbooks in place of roles, as I recall (though I can't seem to find it at the moment). Some discussions at work have got me to thinking this might be a useful thing in some cases, so I'm wondering how many of you are actually doing this and what you have found the pros/cons of this approach to be.Thanks in advance--
Larry Wright
Elvin Abordo
Mobile: (845) 475-8744--
Elvin Abordo
Mobile: (845) 475-8744
Archive powered by MHonArc 2.6.16.