Cookbook Metadata
The following DSL functions can be used in a cookbook's metadata.rb file. Each function accepts a name and an optional version constraint. If the version constraint is not provided, the default constraint of ">= 0.0.0" will be used.
Example version constraints in a cookbook/metadata.rb file:
Specifying a version constraint for these functions is optional. If no version constraint is provided, the default version constraint of ">= 0.0.0" will be used.
Environment Cookbook Versions
An environment can specify a list of allowed cookbook versions using version constraints. When defining a constraint, you must specify the cookbook name and the version constraint. Any cookbook not explicitly constrained in the environment file is assumed to have no version constrain and can be used at any version by every node in that environment.
Cookbook Versions in Run List Items
You can peg the cookbook version to use for recipe items in a node's run list. The syntax uses '@' to specify a version. Only the equality constraint is supported for specifying constraints in run lists.
Example run list JSON
Freezing Cookbooks
You can also freeze your cookbooks, to prevent anyone from uploading the frozen cookbook at the same version number. Once a cookbook is frozen, you can only upload a cookbook with the same name and version by using the --force option:
By combining frozen cookbook versions with environments you can make sure that production is safe from accidental updates when testing out changes in your development infrastructure.
There are two main strategies for implementing version control:
- If you place supreme importance on always keeping every last bit of data in version control, you’ll want to use the maximum version control strategy and drive your use of environments by editing files only.
- If you’re already managing your cookbooks for separate environments using git branches, and you already have your versioning policy information stored in your cookbooks’ metadata, you might opt for a lighter weight branch tracking strategy.
Below are examples of both of these strategies.
Branch Tracking Strategy
In the branch tracking strategy, you have a branch in your source control repo for each environment, and your cookbook versioning policy tracks whatever is in the tip of each branch. This strategy is simple and lightweight. For development environments that track the latest cookbooks, you just need to bump the version before you upload the cookbook for testing. For environments that need special protection, i.e., production, you always upload cookbooks using the -E ENVRIONMENT and --freeze flags.
In development:
1. Bump the version number as appropriate.
2. Make the changes needed to the cookbook.
3. Upload and test. Upload for dev is the same as always:
Repeat steps 2 and 3 as necessary.
When you’re ready to move your changes into production:
1. Upload for prod with automatic version constraints:
Adding the -E ENVIRONMENT option will cause knife to automatically set the version constraint on that environment to match the version you’re uploading.
Maximum Version Control Strategy
If you prefer to version control absolutely everything, then you need to use a file-editing based approach to environments. In your development environment, you work the same as the branch tracking strategy.
In development:
1. Bump the version number as appropriate.
2. Make the changes needed to the cookbook.
3. Upload and test. Upload for dev is the same as always:
Repeat 2 and 3 as necessary.
When you’re ready to move your cookbooks into production, you’ll do the following:
1. Upload and freeze your cookbooks:
2. Modify your environment to prefer the new version you uploaded:
3. Upload the updated environment:
4. Deploy!
|
