September 25, 2012 at 20:38About installing packages using Chef
When managing configuration with Chef, especially at the very beginning of use, it becomes necessary to install the necessary package sets on a freshly introduced system. For example, if the habit dictates that the system should have htop and mc. Add complexity, we need packages to be from a specific repository. How can you solve this problem with Chef?
There are many sample cookbooks on the Communuty Site with one single recipe that only installs one package. Even without customization. Often they put not one package, but several, but this only worsens the situation because the cookbook becomes less universal.
In such recipes, adding a repository usually happens “on a bash” and usually only for one distribution or platform.
For all its simplicity and obviousness, such a solution is devoid of universality and has practically no chance of reuse, especially outside the infrastructure for which it was generated. First, run_list will have to swell, secondly, if you want to install another package, you need to create another cookbook and increase the run_list even more strongly, and thirdly, it’s not obvious what to do if you want to install some packages from your repository. Bad, this is an option for the lazy. Let's try to improve the situation.
In the previous approach, I clearly want to make the list of packages for installation in some general place and in the recipe in the loop go along this list. Community Cookbooks already has a ready-made solution - platform_packages . Cookbook allows you to install on the system using the standard package management system the list specified in the attributes or in the databag. Why there are still new recipes from a single action, which have almost no benefit, remains a mystery to me.
Now the solution already looks nicer, lists of necessary packages can be set in the base role. In additional roles, this list can be clarified and Chef will merge these lists himself. Moreover, in the environment settings it will be possible to redefine the necessary, for example, if for the test environment you need to install assemblies with debugging information enabled. What is left of us to improve the obvious from the first option? Repository setup.
How can we make our repository configuration “on the bash” more universal? All in the same community recipes there is a ready-made resource for manipulating APT repositories . By the way, Opscode itself uses it, but right in the recipe, immediately before installing the packages. There is a wonderful cookbook for managing Yum, there is one for Solaris, but if you take care of setting up your repository directly in the recipe and for all platforms, you will get a poorly readable pile of ifs, and we want beauty and grace. At the same time, I want to be able to use different repositories in the test and production environments, which means that you need to use either attributes or databags. We have already begun to play role-playing games, so we will continue with the attributes.
A preliminary search for a suitable turnkey solution was not successful, so we will make our bike on square wheels.
An example of a role in its simplest form:
Each recipe in the cookbook will configure one repository for the maximum number of platforms. For simplicity, there is only apt so far, maybe in the future, good people will add yum and other options.
Option one. All in a bunch
There are many sample cookbooks on the Communuty Site with one single recipe that only installs one package. Even without customization. Often they put not one package, but several, but this only worsens the situation because the cookbook becomes less universal.
In such recipes, adding a repository usually happens “on a bash” and usually only for one distribution or platform.
For all its simplicity and obviousness, such a solution is devoid of universality and has practically no chance of reuse, especially outside the infrastructure for which it was generated. First, run_list will have to swell, secondly, if you want to install another package, you need to create another cookbook and increase the run_list even more strongly, and thirdly, it’s not obvious what to do if you want to install some packages from your repository. Bad, this is an option for the lazy. Let's try to improve the situation.
Option Two. Role-playing games.
In the previous approach, I clearly want to make the list of packages for installation in some general place and in the recipe in the loop go along this list. Community Cookbooks already has a ready-made solution - platform_packages . Cookbook allows you to install on the system using the standard package management system the list specified in the attributes or in the databag. Why there are still new recipes from a single action, which have almost no benefit, remains a mystery to me.
Now the solution already looks nicer, lists of necessary packages can be set in the base role. In additional roles, this list can be clarified and Chef will merge these lists himself. Moreover, in the environment settings it will be possible to redefine the necessary, for example, if for the test environment you need to install assemblies with debugging information enabled. What is left of us to improve the obvious from the first option? Repository setup.
Option Three. We take out repositories from recipes.
How can we make our repository configuration “on the bash” more universal? All in the same community recipes there is a ready-made resource for manipulating APT repositories . By the way, Opscode itself uses it, but right in the recipe, immediately before installing the packages. There is a wonderful cookbook for managing Yum, there is one for Solaris, but if you take care of setting up your repository directly in the recipe and for all platforms, you will get a poorly readable pile of ifs, and we want beauty and grace. At the same time, I want to be able to use different repositories in the test and production environments, which means that you need to use either attributes or databags. We have already begun to play role-playing games, so we will continue with the attributes.
A preliminary search for a suitable turnkey solution was not successful, so we will make our bike on square wheels.
An example of a role in its simplest form:
run_list(
"recipe[repos::percona]",
"recipe[repos::opscode-chef-10]",
"recipe[platform_packages]")
override_attributes(
"platform_packages" => {
"pkgs" =>
[ { "name" => "chef",
"action" => "upgrade"},
{ "name" => "percona-server-client"}
]})
Each recipe in the cookbook will configure one repository for the maximum number of platforms. For simplicity, there is only apt so far, maybe in the future, good people will add yum and other options.