We've got some thoughts on how this might be accomplished, which I
just posted to the wiki at:
http://wiki.opscode.com/display/chef/Roles+and+Infrastructures
The gist is adding three new concepts:
1) Tags
Support for tags already exists, but we don't use it. This is
essentially allowing you to easily tag/untag a given node, from the
ui, an attribute file, or a recipe. Tags might be something like
'dl380', 'ec2', etc.
2) Roles
Right now, a node is configured based on the list of recipes it should
apply. That will remain the same, but we're going to add another
layer on top, which is a 'role'. In addition to the recipes that
would be applied, it will also contain a list of the cookbooks needed
to fulfill that role, and potentially any attributes that would need
to be set.
A node wind up in a given role in one of two ways: manual placement or
tag matching. Each role would have a set of tags that, if present on
a node, cause the node to automatically receive a given role.
Nodes can have multiple roles.
3) Infrastructures
Infrastructures are where you can define what roles are available for
a given environment. Think 'production', 'testing', etc. It would
also allow you to define a 'policy', which would be evaluated against
a given node and place it dynamically into roles.
The ways this would change chef:
A) We would be able to compute the exact set of recipes for a given
node, making sure we only ship the minimal set.
B) It would allow for automatic assignment of recipes based on policies.
C) It would eliminate the need for lots of small cookbooks that do
nothing but contain a default recipe full of 'include_recipe' - for
example, no more 'web_server' cookbooks.
What do ya'll think?
Adam
--
On Fri, Apr 17, 2009 at 10:28 AM, snacktime <snacktime@gmail.com> wrote:
> I actually have a similar need and was looking at how difficult it would be
> to add domains to chef. So a domain could contain it's own cookbooks,
> nodes, etc..
>
> Chris
>
> On Fri, Apr 17, 2009 at 5:39 AM, AJ Christensen <aj@junglist.gen.nz> wrote:
>>
>> This is a major problem, and something we've discussed although no
>> concrete decisions going forward have been made.
>>
>> I'm interested in potential solutions for this, but walking recipes
>> (server) included on a node for include_recipe and only caching those ones
>> seems like a pretty good solution.
>>
>> On 17/04/2009, at 11:48 PM, Miguel Cabeça wrote:
>>
>>> Hi,
>>>
>>>
>>>> Chef client will cache all cookbooks available from the Chef server each
>>>> time.
>>>
>>> Does anyone else see a problem with this?This means any node managed by a
>>> chef server will have access to recipes, files and templates meant for any
>>> other node. If one node is compromised, the atacker will have access to
>>> sensitive data for that node and for any other node just by looking at the
>>> Chef client cache.
>>>
>>> I know that the chef server is dumb and all the smarts are on the chef
>>> client by design, but perhaps a smart move would be to give some recipe
>>> processing brains to Chef server. At least to let it make decisions about
>>> what coockbooks to provide to each client based on "include_recipe"
>>> directives.
>>>
>>> For now, I'll have to leave my multi-user machines outside of chef
>>> management because of that.
>>>
>>> I know that this may not be a big problem for the typical use of Chef
>>> that I'm aware of (Web app server farms), for for my usage scenario
>>> (Computer center of a major University in Portugal, with servers, multi-user
>>> clusters and personal workstations) it is.
>>>
>>> What are your thoughts on that?
>>>
>>> Best Regards
>>>
>>> Miguel Cabeça
>>>
>>
>
>
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-4759 E: adam@opscode.com
Archive powered by MHonArc 2.6.16.