0

How can attributes be organized in Chef to support multiple, isolated, clusters of nearly identical servers in an environment?

My organization, and I assume many alike, has several staging instances. Different staging instances need to use different database connections and hostnames and little things like that, but otherwise they're identical. In a world where one staging instance = 1 server, you can easily put staging specific attributes in a Chef environment called staging, and you can define instance specific attributes on the node itself.

But what happens when every instance of staging is more than one server? Say we have several different services on different nodes that talk to each other and form an instance of an application.

I can't create an environment for each of these instances, as a node can only be in 1 environment and I don't want to duplicate all the shared attributes between them. Likewise, I don't want to duplicate all the instance/cluster specific attributes on each node.

Should I create a role for each of these instances that just has the instance/cluster specific config? Should I create a cookbook for each of these instances?

I've been looking through blog posts and things but haven't found anything addressing this.

1 Answer 1

0

There is no right or wrong here. Using different roles (you can assign multiple) might be one of the easier choices.

If you want to test new cookbook versions in the staging environment, before rolling them out to production, the environment cookbook pattern would provide you means for doing so.

But as chef is just code and you can do nearly anything in code, you could, e.g., also define the environment (not on chef terms) using the host name, which then chef reads out and uses the set of attributes specified for this environment (and in chef you can specify these sets in the environment, a role, a cookbook...).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .