About installing packages using Chef
When managing configuration using Chef, especially at the very beginning of use, there is a need to install the necessary sets of packages on a freshly introduced system. For example, if the habit dictates that the system should be htop and mc. Add complexity, we need packages to be from a specific repository. How can you solve this problem with Chef?
On the Communuty Site there are many examples of kukbuk with one single recipe that makes solely the installation of one package. Even without customization. Often they put not one package, but several, but this only worsens the situation because the kukbook becomes less universal.
')
In such recipes, the addition of a repository usually occurs “on the back” and usually only for one distribution kit or platform.
For all its simplicity and obviousness, this solution lacks universality and has practically no chance of reuse, especially outside the infrastructure for which it was spawned. First of all, run_list will have to swell, secondly, if you want to install another package, you need to create another kukbook and increase the same run_list even more, 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 non-lazy. Let's try to improve the situation.
In the past, the approach clearly wants to make a list of packages for installation in some common place and in the recipe itself in the cycle go through this list. Community Cookbooks already have a turnkey solution - platform_packages . Cookbook allows you to install on the system by means of the standard package management system a list specified in the attributes or in the data tag. Why there are still new recipes from one action, which have almost no benefit, remains a mystery to me.
Now the solution looks nicer, lists of necessary packages can be specified in the basic role. In additional roles, this list can be clarified and Chef itself will merge these lists. Moreover, in the environment settings it will be possible to redefine what is needed, for example, if for a test environment you need to install assemblies with debugging information enabled. What we have left to improve the obvious from the first option? Configuring repository
How can we make our “on bash” repository setting more universal? All in the same community recipes there is a ready resource for manipulating APT repositories . By the way, it is used by Opscode itself, but right in the recipe, just before installing the packages. There is an excellent Kumbook for managing Yum, there is for Solaris, but if you take care of setting up your repository directly in the recipe and for all platforms, you’ll get poorly readable pile-up of if-s, and we want beauty and grace. At the same time, I want to be able to use different repositories in test and production environments, which means that you need to use either attributes or data tags. We have already started to play role-playing games, so we will continue with the attributes.
A preliminary search for a suitable ready-made solution was not crowned with success, so we will do our bicycle on square wheels.
An example of a role in the simplest form:
Each recipe on a cookbook will configure one repository for the maximum number of platforms. For simplicity, while there is only apt, maybe in the future, good people will add yum and other options.
Option one. All in a bunch
On the Communuty Site there are many examples of kukbuk with one single recipe that makes solely the installation of one package. Even without customization. Often they put not one package, but several, but this only worsens the situation because the kukbook becomes less universal.
')
In such recipes, the addition of a repository usually occurs “on the back” and usually only for one distribution kit or platform.
For all its simplicity and obviousness, this solution lacks universality and has practically no chance of reuse, especially outside the infrastructure for which it was spawned. First of all, run_list will have to swell, secondly, if you want to install another package, you need to create another kukbook and increase the same run_list even more, 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 non-lazy. Let's try to improve the situation.
Option two. Role-playing games.
In the past, the approach clearly wants to make a list of packages for installation in some common place and in the recipe itself in the cycle go through this list. Community Cookbooks already have a turnkey solution - platform_packages . Cookbook allows you to install on the system by means of the standard package management system a list specified in the attributes or in the data tag. Why there are still new recipes from one action, which have almost no benefit, remains a mystery to me.
Now the solution looks nicer, lists of necessary packages can be specified in the basic role. In additional roles, this list can be clarified and Chef itself will merge these lists. Moreover, in the environment settings it will be possible to redefine what is needed, for example, if for a test environment you need to install assemblies with debugging information enabled. What we have left to improve the obvious from the first option? Configuring repository
Option three. We take out of the recipes repository.
How can we make our “on bash” repository setting more universal? All in the same community recipes there is a ready resource for manipulating APT repositories . By the way, it is used by Opscode itself, but right in the recipe, just before installing the packages. There is an excellent Kumbook for managing Yum, there is for Solaris, but if you take care of setting up your repository directly in the recipe and for all platforms, you’ll get poorly readable pile-up of if-s, and we want beauty and grace. At the same time, I want to be able to use different repositories in test and production environments, which means that you need to use either attributes or data tags. We have already started to play role-playing games, so we will continue with the attributes.
A preliminary search for a suitable ready-made solution was not crowned with success, so we will do our bicycle on square wheels.
An example of a role in the 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 on a cookbook will configure one repository for the maximum number of platforms. For simplicity, while there is only apt, maybe in the future, good people will add yum and other options.
Source: https://habr.com/ru/post/152233/
All Articles