|
Currently, a Chef Server contains nodes, roles, and cookbooks - it's responsible for distributing cookbooks to nodes, allows you to assign roles, and more. This approach works fine when your entire infrastructure is monolithic; as long as every system that uses a given cookbook is ready for that cookbook to be updated, everything is copacetic. The issue arises when this is no longer the case - for example, when you want to have a production, development, or staging environment, where new versions of a cookbook can be used in each. Today, this is only possible by running a distinct chef server instance per environment.
This proposal documents the current thinking around the creation of 'Infrastructures', which solve the above problem.
Infrastructures can be though of as a 'container' for a group of cookbooks, roles, and nodes. Each infrastructure will be given a name, such as 'production', 'development', or 'bootstrapping', along with a long-form description.
What follows is a breakdown of how each component would need to change with the addition of infrastructures, and how they will be exposed through infrastructures.
Components
Cookbooks
We already track cookbook versions. With the addition of infrastructures, we will change the on-disk layout for how the chef server stores cookbooks to be version specific, and to allow multiple versions of the cookbook to be uploaded. For example, when you run:
Rather than storing the new apache2 cookbook directly at /var/chef/cookbooks/apache2, we'll shift to /var/chef/cookbooks/apache2/VERSION. The cookbook loader will be extended to understand the existence of multiple cookbook versions.
Each infrastructure will be able to look at the list of cookbooks available on the server, and set itself to using the latest version of the cookbook, a specific version of the cookbook, or to exclude the cookbook altogether. For example, if we had version 1.0.0, 2.0.0, and 3.0.0 of the apache2 cookbook, we can set the production infrastructure at the '2.0.0' version of the cookbook, while letting the development environment always be at the 'latest' version, and making the apcahe2 cookbook unavailable at all within the 'bootstrapping' infrastructure.
Roles
Roles do not currently have a version number applied. In order to support multiple disparate configurations, we'll need to add this ability, or something similar, to roles. Either they gain the ability to be versioned, or they get entirely containerized within an infrastrucutre - and it's the responsibility of the end user to keep the role up to date.
Nodes
A node is 'assigned' to an infrastructure, and it can be in only one at a time.
|
|