If you are using Vagrant, and you decide to go the role/wrapper cookbook way (rather than using roles), then this might be helpful too:
https://github.com/tknerr/vagrant-toplevel-cookbooks
This pattern works well for me as long as versionable (and dependency-manageable) roles are not there yet.
HTH, Torben
We're likely to tell you to use roles. If you wind up going the role cookbook route and wind up in with problems with computed attributes, we'll tell you to put that attribute in a role. We recognize that roles have a weakness right now which is that they are not versioned. In the future they're going to be compiled into the policyfile object that gets shipped up to the server and defines how a given node in a given environment behaves.
We'll almost certainly continue to support role-less deployments, but we won't encourage that because the computed attribute problem is always going to be waiting for people who ditch roles entirely. People who do ditch roles and wind up with the computed attribute problem can continue to try to work around that problem by pushing loading attributes into recipe code, but that goes against best practice. We fixed attribute loading in Chef 11 so that people could set attributes deterministically in attribute files with the intent that people would set attributes in roles and attribute files and stop setting them in recipe code (where compile/converge mode issues usually troll them hard). We can't stop people from going that route, but when people wind up leaving behind them a mess of attribute mangling code directly in their recipes we also can't rescue whoever winds up maintaining that.
There are ways to use setting attributes in recipes that are sane (e.g. to set an attribute saying you did a thing or found a thing and then letting `knife node show` or `knife node search` look for it later), but if you are setting attributes in recipe code and then consuming those attributes later, it is almost always better to push those attributes into attributes files or roles.
Still you can put roles on a huge diet. You can have roles that include nothing more than a role cookbook. All the attribute setting can be moved to the role cookbook and the run_list for the role can be put into include_recipe statements in the default recipe of the role_cookbook. When you do this, you should be aware that you need one cookbook per every role, you can't have a single role cookbook with all your roles in it, because all of your attribute files will be parsed irregardless of if that role is in the run-list. This leads to a lot of cookbooks, and if you are doing one-git-repo-per-cookbook (per The Berkshelf Way) then you will have a *lot* of repos -- start budgeting for 50-100 or more for a small-medium-business size deployment.
So, roles will not be going away, they should be getting fixed and will be more useful in the future.
On Mon Sep 15 17:15:05 2014, AJ Christensen wrote:
Yo,
Forgive my reply-all!
Roles are fine, use whatever you like. I use them all the time! They're awesome.
If you don't use roles you'll end up half ass inventing them with
application/library/wrapper shenanigan cookbooks, or other external
stuff -- You could put run lists in a custom API, Consul, or etcd, for
example.
I semi-expect Chef to offer some more guidance officially soon with
regard to version-able policy representing the cookbooks, attributes,
version locks and execution order.
Chef-RFC RFC019 [0] is worth looking at regarding workflows and the
ChefDK, "the berkshelf way".
I would also urge you to read Dan's proposal regarding Arbitrary
cookbook identifiers which is used for his (experimental? prototype?)
Policyfile implementation. It's the way I hope we all choose to
proceed, personally. [1]
regards,
--aj (fujin)
[0] https://github.com/opscode/chef-rfc/blob/6a239ff5dc223290d4488d76fadaeeb6d14f5ab1/rfc019-chef-workflows.md
[1] https://github.com/opscode/chef-rfc/pull/20
On Tue, Sep 16, 2014 at 8:20 AM, Greg Barker < " target="_blank"> > wrote:
After googling around and reading various blog posts about roles, I'm still
not sure if I should be using them. Since I'm new to chef, I wanted to
describe my line of thinking and hear if maybe I'm going about things the
wrong way.
There are certain things I think might be the same on all my servers, so I
created a base_role.rb. It's fairly simple: specifies
set_fqdn=*.mycompany.com, some openssh & postfix attributes, and a run_list
of hostname, openssh, fail2ban, and postfix.
So now I want to spin up a jenkins server. I see there is a popular
community cookbook with some LWRPs that I'll probably use, so I run `berks
cookbook mycompany-jenkins` to create my jenkins cookbook and add "depends
'jenkins'" to the metadata.rb file. But I also need the stuff from my
base_role on the jenkins server, so I create a new role,
mycompany_jenkins.rb. Inside that role I specify some attributes for the
java version, and the run_list is role[base_role], java, maven, jenkins, and
mycompany-jenkins. Or maybe the attributes I specified in the role should
actually be in the mycompany-jenkins cookbook default attributes?
Now I go back to the mycompany-jenkins metadata.rb file and start adding
more depends lines for hostname, openssh, fail2ban, postfix, java, and
maven. Even though the mycompany-jenkins cookbook doesn't have anything in
it yet, it depends on all these things because of the role. But the role
doesn't even live inside the cookbook, why should the cookbook have to
declare all those dependencies. Now I'm thinking that maybe my base_role
should be a recipe instead? Then berks could figure out all those
dependencies for me. Or should the run_list I put in the rule actually be a
couple of include_recipe lines in my default.rb? That would make all the
depends lines in the metadata make more sense.
The 2nd google result for "chef roles" is this article that states versioned
roles are likely coming with Chef 12. I was thinking maybe that is something
that will help me here. So I googled "chef 12 versioned roles" and it led me
to CHEF-4837. It didn't really add much clarity though, I am still confused
where the discussion ends and it doesn't seem to pick up on github.
At any rate, hopefully this describes some of my confusion with the use of
roles. Please help steer me in the right direction.
Thanks in advance!
Archive powered by MHonArc 2.6.16.