Ask Your Question

r10k, roles and profiles

asked 2016-01-14 15:02:16 -0600

luksi1 gravatar image

I'm having some difficulties wrapping my head around how to use r10k along with Craig Dunn's Roles & Profiles pattern. I like the idea of abstracting my application layer from my modules. Unfortunately, my company has a very heterogeneous environment, so different roles and profiles will abound. I'm all about version control, but checking out a module with several hundred profiles from a hundred different people with commits coming hourly is really not practical. I have a hard time believing I'm the only one stuck with this problem. Is the community using submodules to get around this? Or maybe wrappers? Their appears to be an application type for PE, something called Application Orchestrator, but this does not appear to be in 4.3. Thoughts?

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2016-02-01 21:45:41 -0600

updated 2016-02-01 21:48:32 -0600

I was kind of hoping others would answer this one. Here's my take.

You are definitely not alone in dealing with these sorts of issues, although the issue of the highly heterogeneous environment with many (I read between the lines as probably "siloed"?) teams begins at the organisation structural level. For real success with DevOps/Infrastructure-as-code, change needs to start at the top with a clean organisational structure. No amount of technology is going to solve the problem of 5 teams trying to solve the same problems and reinventing the wheel.

So you shouldn't need 100 developers to manage several hundred profiles, and that's why in an ideal case, the roles and profiles pattern does not run into this particular scaling up issue.

Given your actual situation, use of Git submodules sounds like a perfectly reasonable choice to me. But keep in the front of your mind that if you're allowing Git submodules so that no one team ever has to have responsibility for the code base as a whole, well you can't hope to end up with a clean, coherent, cohesive code base.

edit flag offensive delete link more

answered 2016-02-10 13:33:45 -0600

luksi1 gravatar image

Thanks a lot for answering.

"the issue of the highly heterogeneous environment with many (I read between the lines as probably "siloed"?) teams begins at the organisation structural level."

This is very true. Unfortunately, infrastructure teams don't have the ability to change that structure. I would, in fact, guess that a lot of the consulting work in the infrastructure-as-code sector exists, because ABC company started building their code base from two "lazy" technicians that wanted to automate their work. Now, everyone hops on board and their code sucks, because it didn't scale, and it needs to get cleaned up. Infrastructure-as-code (I'm guessing for most organizations) doesn't start at the organization level, so you deal with what you have.

That said, a lot of organizations don't dictate the applications that will exist on their infrastructure, i.e. the public sector. If a town, state, government, school system, or health care system choose application Foo, Bar, and Beef to use as their new applications and Foo has a Lamp stack, Bar is a .Net application and Beef is a Client/Database system with an Informix backend, nobody cares that you have more knowledge about Linux or Windows or Oracle or MSSQL. You have to deliver those systems. And for large organizations that requires a very diverse set of applications that need to be configured and handled by a lot of people. Here lies the rub. A lot of people doing small changes consistently.

I think sub-modules might actually be the answer. I also read from this blog entry, in the comments, by Gary Larizza,, that he's seen people simply invert the module name and the sub-class "profile" and then check that in and allow that team to handle the configuration.

You're right that you don't want a lot of repetitive shit lying around, creating a murky, confusing code-base. On the flip side, these are the wrappers (the roles and profiles). Those writing a profile don't get the option to screw up all of the architect's hard work; they only get to slice and dice what's given to them, i.e. the modules that are created and imported for the organization.

I'll try and do a write-up about our successes and failures when it's done and re-post my findings here for future reference.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2016-01-14 15:02:16 -0600

Seen: 510 times

Last updated: Feb 10 '16