DevOps Engineer Tools: Librarian
This article is intended for those who use or plan to start using the configuration management system Opscode Chef .
The main task of implementing any configuration management system, be it Chef , Puppet or something else, is to repeat and update the environment of all environments used in software development (dev, CI, QA, stage, production). It follows that the configuration description itself must be uniquely stored and updated. Unfortunately, the versioning capabilities that Chef has are quite limited. Therefore, in conjunction with Chef, Librarian has recently been actively used. But before we talk about him, let's talk a bit about the cookbooks.
Kukbuki (in more detail about what it is, you can read here ) can be divided into 3 types:
In your project, all the cookbooks can be in the cookbooks folder under the version control system. And if for own kukbuk is the only reasonable way, then for kukbuk of the first two types, this solution seems rather strange. For the simple reason that you need to check for updates, manage dependencies and update such kukbuki in "manual" mode. In addition, if you take a cookbook and simply add it to the cookbooks folder, remembering where you got it from will be extremely difficult. Cookbooks with GitHub can be stored as git submodules, but this does not solve most of the problems listed here.
Moreover, if any of the cookbooks you use have dependencies (they are written in the cookbook metadata.rb file), then you will have to manually add dependencies to the project.
')
All these problems can be avoided by using Librarian . This is a tool that helps manage the dependencies and versions of your cookbooks.
There is a similar project that does almost the same thing, Berkshelf . It appeared later Librarian, pulls with it a bunch of dependencies, has 2 times less installations ( judging by rubygems ), but it is slightly better documented. The choice of one of them is exclusively a matter of taste. You can switch to another tool at any time, because the dependency description files are identical. We use Librarian, but what is written further is almost completely relevant for Berkshelf.
Imagine a very simple project that uses quite a few cookbooks. Let's start using librarian with the help of the
Add one line to our file and execute
This command will put all the necessary cookies in the cookbooks folder and create the
We store local for the project kukbuki in inhouse-cookbooks folder. These are those cookbooks that are specific to this particular project. In
Also in
This combination of features makes it easy and convenient to always collect the same cookbooks in the cookbooks folder.
It should be clearly understood that the current "slice" of all Kukbooks is stored in the Cheffile.lock file, and the Cheffile file is only a "hint" about how to collect Cheffile.lock, and it alone is not enough for versioning the Kukbooks. If you do not have Cheffile.lock, then depending on what time you executed the
Moreover, if you explicitly indicate the versions of the books you need, updating the books will become much more difficult.
But what if you need to update some kind of Kukbook? For example, we learned that the lvm version of the book came out, with some changes we needed. Then we do the following:
This command will update the kvbuk lvm to the latest available. Moreover, it will update all dependencies of the kvbuk lvm, if necessary. We recommend doing
You can also understand this this way: Cheffile is the description of the necessary requirements for the version of the cookbooks at the current moment, and Cheffile.lock is a slice that satisfies these requirements for the current moment.
And one more thing that should not be forgotten when working with librarian. Each time before
Perhaps this approach may seem somewhat complicated, but worth it. After all, it always guarantees the current cut of kukbuk, automatic dependency management, as well as the flexibility of using local kukbuk, kukbuk from the Opscode site and kukbuk from various git-repositories, including the github.
The main task of implementing any configuration management system, be it Chef , Puppet or something else, is to repeat and update the environment of all environments used in software development (dev, CI, QA, stage, production). It follows that the configuration description itself must be uniquely stored and updated. Unfortunately, the versioning capabilities that Chef has are quite limited. Therefore, in conjunction with Chef, Librarian has recently been actively used. But before we talk about him, let's talk a bit about the cookbooks.
Kukbuki (in more detail about what it is, you can read here ) can be divided into 3 types:
- kukbuki from community.opscode.com ;
- Kukbuki from GitHub and other places;
- own project kukbuk.
In your project, all the cookbooks can be in the cookbooks folder under the version control system. And if for own kukbuk is the only reasonable way, then for kukbuk of the first two types, this solution seems rather strange. For the simple reason that you need to check for updates, manage dependencies and update such kukbuki in "manual" mode. In addition, if you take a cookbook and simply add it to the cookbooks folder, remembering where you got it from will be extremely difficult. Cookbooks with GitHub can be stored as git submodules, but this does not solve most of the problems listed here.
Moreover, if any of the cookbooks you use have dependencies (they are written in the cookbook metadata.rb file), then you will have to manually add dependencies to the project.
')
All these problems can be avoided by using Librarian . This is a tool that helps manage the dependencies and versions of your cookbooks.
There is a similar project that does almost the same thing, Berkshelf . It appeared later Librarian, pulls with it a bunch of dependencies, has 2 times less installations ( judging by rubygems ), but it is slightly better documented. The choice of one of them is exclusively a matter of taste. You can switch to another tool at any time, because the dependency description files are identical. We use Librarian, but what is written further is almost completely relevant for Berkshelf.
Imagine a very simple project that uses quite a few cookbooks. Let's start using librarian with the help of the
init command, which creates the initial Cheffile file - it will contain the description of the cookbooks you use. $ librarian-chef init create Cheffile $ cat Cheffile site 'http://community.opscode.com/api/v1' Add one line to our file and execute
librarian-chef install $ cat Cheffile site 'http://community.opscode.com/api/v1' cookbook 'lvm' $ librarian-chef install Installing lvm (0.8.6) This command will put all the necessary cookies in the cookbooks folder and create the
Cheffile.lock file. $ ls cookbooks lvm $ cat Cheffile.lock SITE remote: http://community.opscode.com/api/v1 specs: lvm (0.8.6) DEPENDENCIES lvm (>= 0) We store local for the project kukbuki in inhouse-cookbooks folder. These are those cookbooks that are specific to this particular project. In
Cheffile we add the following: cookbook 'project42', :path => 'inhouse-cookbooks/project42' Also in
Cheffile you can refer to specific revisions of the kukbuk in the gita. cookbook "postgresql", :git => "git@github.com:express42-cookbooks/postgresql.git", :ref => "0.1.4" cookbook "newrelic", :git => "git@github.com:heavywater/chef-newrelic.git", :ref => "b2309495b367da4bfe6f1761876b5d58e2455d6a" This combination of features makes it easy and convenient to always collect the same cookbooks in the cookbooks folder.
It should be clearly understood that the current "slice" of all Kukbooks is stored in the Cheffile.lock file, and the Cheffile file is only a "hint" about how to collect Cheffile.lock, and it alone is not enough for versioning the Kukbooks. If you do not have Cheffile.lock, then depending on what time you executed the
librarian-chef install command, Cheffile.lock will be different for you. Even if you explicitly record all the versions of the kukbooks used in the Cheffile (which is not strongly recommended to do), then the kukbooks that will be assembled by dependencies may differ.Moreover, if you explicitly indicate the versions of the books you need, updating the books will become much more difficult.
But what if you need to update some kind of Kukbook? For example, we learned that the lvm version of the book came out, with some changes we needed. Then we do the following:
$ librarian-chef update lvm This command will update the kvbuk lvm to the latest available. Moreover, it will update all dependencies of the kvbuk lvm, if necessary. We recommend doing
git diff Cheffile.lock after this to make sure that exactly what you wanted has changed. By the way, if you register in Cheffile a version for a cookbook on which lvm depends, then lvm may not be updated, and you will have to wonder for a long time why this happens.You can also understand this this way: Cheffile is the description of the necessary requirements for the version of the cookbooks at the current moment, and Cheffile.lock is a slice that satisfies these requirements for the current moment.
And one more thing that should not be forgotten when working with librarian. Each time before
librarian-chef install recipe to a chef-server, you need to do git pull and librarian-chef install . Because if someone has uploaded a more recent recipe, nothing will automatically change in your local cookbooks folder.Perhaps this approach may seem somewhat complicated, but worth it. After all, it always guarantees the current cut of kukbuk, automatic dependency management, as well as the flexibility of using local kukbuk, kukbuk from the Opscode site and kukbuk from various git-repositories, including the github.
Source: https://habr.com/ru/post/182264/
All Articles