What we do is a separate chef server per team/org with entirely separate chef repositories. We distribute cookbooks to the whole company and people have to upgrade the common cookbooks every now and then (using librarian internally)
It would be nice to have the "organization" thing available in open source chef so that we don't have a chef server for each team. We try to maintain the number of teams as low as possible because of that.
However within one team the nodes are managed within git (note: it's bare metal we don't have any VM or dynamic node creation) and literally every operation on prod goes through git and then automated release management. This forces people to automate, document and log anything happening on prod. I really think this is the right way. Operations should be rare and release managed as much as possible. Dynamic scaling with VMs could also work but then you have something else automated that manage the nodes for you, not a human.
On 8/14/13 7:09 AM, Jeff Blaine wrote:
Thanks for the helpful replies. We're getting into areas here that were not touched on in the previous thread, so I'm glad I asked after all (after it was discussed 2 days prior).Yeah, what I'm thinking of is scaling to access control out to tens of thousands of computers, thousands of users and hundreds of different teams. A solution that I've seen at that scale was to create a self-service console where managers of different teams were able to hit a webui in order to handle the access control for their direct reports. They were given control over some collection of server roles in the organization and the pain of new hires and terminations was distributed over the entire organization. This was complicated by the needs of centralized operations, networking and security and there were 'horizontal' account management that cut across all the verticals so it wasn't entirely that simple.
Who should be making the configuration-data changes to nodes if not devs and ops (and security in coordination with devs and ops)? What situations exist where the people who don't already have git push and knife upload privileges would need to be given out-of-change-management-control access to site-local node configuration data (which is just as critical to stability (et al) as cookbook code)? Clue me in?
It's not important to know that samsmith changed node['blah'] from X to Y at 7:34PM yesterday because "Explanation A B C"? How is that not absolutely necessary? Or you're (Lamont) saying that this should be gleaned back-channel via the database transaction log coupled with a direct question to the database user who performed the transaction? I'm struggling to resolve this idea you're posing that change control is irrelevant WRT server configuration values.
I'm eager to learn.
Giving out git commit access to the central config management repo that allows you to do the moral equivalent of knife ssh '*:*' 'rm -rf /' everywhere is horrible. You'd have a hundred people who had complete access to all your servers who only needed that for a small slice of their job.
And clearly I don't mean to argue that you don't need history, but that you can use the database for that (and we're working on something very much like that for hosted/private chef which uses the postgres database for change history, not git).
"... given the current interface."Not really what I was saying. The emphasis should have been more on the lack of decent RBAC access controls to individual elements inside of SCM repos. Last time I looked at git it was all-or-nothing access controls over entire repos. You could wrap git with a webui which had RBAC control over individual entities in git and then use that to push to the database, but I'm not seeing the huge advantage there over just embracing that you've just got a database, so throw RBAC tools at the database rather than around git.
"Don't use SCM, even if it really should be used, because the UI provided so far is hairy for non-techies." doesn't hold water to me (as a gut reaction). I realize I am quoting words you didn't say, but that's what it seems you are saying.
You can do that instead with data bags -- have a webui with an RBAC system backed by data bag entries that chef can read, but you can implement it entirely outside of your SCM system. As data bags are updated one of the things it should do is write a data bag stream for every change that is made so that you've still got your auditable history that you can show your SOX auditors. You can try to do that using git entirely as the intermediary, but you need to think about merge conflicts and how your webui will deal with that -- and just having multiple instances of a webui needing to do reads and writes to the same data bags in git is probably going to be a synchronization headache. Clearly, github does stuff like it, but its nowhere near as common of a design pattern as a database (and I wouldn't be too surprised if you peel github apart if they don't have databases to help synchronize their git access).
Archive powered by MHonArc 2.6.16.