A serving of servers, please, or how to start deploying with Opscode Chef
Most of the Russian articles on ( Opscode Chef ) that I came across contained excerpts from the cookbook and the story “What a cool thing Chef.” And that’s all. Like, look how I can! But what and how to do with it is not clear. The official website has a detailed wiki. But in it, IMHO, it is easy to get lost. I found the simple guide “how to make elementary work” only in the form of a video, based on which this article was born.
If you have 5 servers, setting them up is extremely rare, then a couple of hands will be enough. You can also put / etc in Git or SVN, be sure to make regular backups and live in peace. For automation of application deployments, what the admin knows best is, even if it is a simple script in bash / python / ruby, or capistrano / fabric / etc.
If there are more than a dozen cars, besides similar or identical, then scripting is already difficult. Capistrano / fabric - provide some convenience, parallel launch on multiple servers, but you still have to write the logic yourself. It’s convenient to deploy with them, especially an application in the same language, but not configure or set up. Here you either need to fence your own “crutches”, or, what’s simpler, take a ready-made one.
From Chef, I unlocked until the last, until I came across the following. Let us have n identical servers, and / etc all have the same repository branch. Changed the nginx config. You need to apply the changes on all other machines. How? For example, take dsh:
Here, in principle, you can add "/etc/init.d/nginx reload" and update everything, everywhere and at once. But for production this is not good. And for local users, interruptions are not very pleasant. Everything else, there is still a supervisor, postgres, mongodb and many other services with which the same story. At a minimum, you will have to do a script to reboot each. In general, “crutches” are obtained.
And the Chef is just for this. Changed the config, it was scattered throughout the farm, the necessary (and only necessary) services were overloaded. Plus, the abstraction from the * nix version, and MS, it seems, is supported. For configs, there are templates that are "collected" depending on the server settings. In general, a lot of tasty. By the way, the current project uses everything at once: a couple of scripts in bash, fabric and Chef.
Closer to practice. Let's write and deploy a simple nginx installation cookbook from scratch, and at the same time we'll figure it out. First you need a test machine with sudo. The instruction is designed for Ubuntu 11.10, but should work with any * nix.
The chef is written in Ruby. And it’s more convenient to install Ruby through Ruby Version Manager (RVM) .
On his machine, from under the normal user:
Next, log in, or open a new terminal (so that the bash profile reboots).
RVM puts both itself and hack into ~ / .rvm if run from outside of root. The system does not get dirty, and it’s easy to remove it, if that.
We put Chef solo. You can install from packages, but rubygems is a more “native” way, independent of the package manager.
There are 3 Chef configurations:
Configure:
The solodemo folder will be created:
This is the so-called "kitchen". In fact, a kind of simplified similarity to Chef Server, only on the local file system.
Create a cookbook to install nginx.
This is also a folder. We look.
Recipe is a script that describes what needs to be done. Both Ruby and Bash, Perl, Python, csh inserts are supported.
There can be several recipes, but “default” is executed unless you specify one specifically (when calling the cookbook).
In recipes / default.rb add
Save.
“Package” here is a resource. You can view the list with a description of the built-in resources on the wiki . They can be supplemented and expanded directly in cookbooks if necessary. The language in which the recipes are written is Ruby DSL . Logic is built from the opposite. We simply say that the package “nginx” must be installed on the server. And Chef makes sure that it is doing what is required. In principle, the same can be described in any other language. But there are many convenient things, as they say, “out of the box”. Of course, there are nuances. For example, with packages, it is important to set the name correctly. So, for apache you need to write a condition, because in RPM-based distributions it is httpd, in Debian it is apache2.
Next, go to the test server and set hostname. This is important because Chef distinguishes nodes by it.
and in / etc / hosts add
We check:
If the answer is "testserver.example.com" - everything is fine. No - edit / etc / hosts.
Now, from the local machine from the solodemo folder:
You will have to wait a bit and, possibly, enter the password for sudo. "Prepare" will install a chef-client that will accept commands.
A file of the form testserver.example.com.json should appear in the nodes folder. We write in it:
That is, you need to run the cookbook "nginx", or rather, the recipe "default" from it.
Later
Yes, there are a lot of dances around one nginx. But there are cookbooks for trivial tasks, with which they are quite flexible and thoughtful. And for non-trivial ones - once a written cookbook allows the installation to be fully automated, it is a kind of documentation. I spent a week to figure out and describe the installation of the first server, but the installation from scratch now takes about 20 minutes. Is this often necessary? Not yet. But configuring now is a pleasure. And if you still write documentation, so why not do it right away on Chef? Yes, and the customer can lift and "touch" everything on his virtual machine with a pair of commands.
I decided not to overload the article with information. This is still more of a guide. But the terms are made by links, so anyone interested is easily found.
Part one. Ideological. What for.
If you have 5 servers, setting them up is extremely rare, then a couple of hands will be enough. You can also put / etc in Git or SVN, be sure to make regular backups and live in peace. For automation of application deployments, what the admin knows best is, even if it is a simple script in bash / python / ruby, or capistrano / fabric / etc.
If there are more than a dozen cars, besides similar or identical, then scripting is already difficult. Capistrano / fabric - provide some convenience, parallel launch on multiple servers, but you still have to write the logic yourself. It’s convenient to deploy with them, especially an application in the same language, but not configure or set up. Here you either need to fence your own “crutches”, or, what’s simpler, take a ready-made one.
From Chef, I unlocked until the last, until I came across the following. Let us have n identical servers, and / etc all have the same repository branch. Changed the nginx config. You need to apply the changes on all other machines. How? For example, take dsh:
dsh -r ssh -c -M -m node1 -m node2 -m nodeN -- 'cd /etc && sudo git pull'Here, in principle, you can add "/etc/init.d/nginx reload" and update everything, everywhere and at once. But for production this is not good. And for local users, interruptions are not very pleasant. Everything else, there is still a supervisor, postgres, mongodb and many other services with which the same story. At a minimum, you will have to do a script to reboot each. In general, “crutches” are obtained.
And the Chef is just for this. Changed the config, it was scattered throughout the farm, the necessary (and only necessary) services were overloaded. Plus, the abstraction from the * nix version, and MS, it seems, is supported. For configs, there are templates that are "collected" depending on the server settings. In general, a lot of tasty. By the way, the current project uses everything at once: a couple of scripts in bash, fabric and Chef.
Closer to practice. Let's write and deploy a simple nginx installation cookbook from scratch, and at the same time we'll figure it out. First you need a test machine with sudo. The instruction is designed for Ubuntu 11.10, but should work with any * nix.
2. Installation and configuration
The chef is written in Ruby. And it’s more convenient to install Ruby through Ruby Version Manager (RVM) .
On his machine, from under the normal user:
bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)Next, log in, or open a new terminal (so that the bash profile reboots).
rvm install 1.9.2
rvm use 1.9.2 --defaultRVM puts both itself and hack into ~ / .rvm if run from outside of root. The system does not get dirty, and it’s easy to remove it, if that.
We put Chef solo. You can install from packages, but rubygems is a more “native” way, independent of the package manager.
gem install knife-soloThere are 3 Chef configurations:
- Solo - gives the ability to run cookbooks.
- Server - a centralized repository of cookies, server data, search on them, web interface.
- Client - starts on a managed machine.
Configure:
cd ~
knife configure -r . --defaults
3. Kitchen, cookbook and knife
knife kitchen solodemoThe solodemo folder will be created:
cd solodemo
tree
.
|-- cookbooks - кукбуки. Подробнее ниже.
|-- data_bags - хранилище данных глобальных данных (например, пользователи, параметры конфигураций, различные общие настройки).
|-- nodes - информация о серверах (нодах).
|-- roles - роли. Фактически это группы кукбуков и параметров к ним. Например, Apache сервер, MySQL сервер.
|-- site-cookbooks
`-- solo.rb
This is the so-called "kitchen". In fact, a kind of simplified similarity to Chef Server, only on the local file system.
Create a cookbook to install nginx.
cd solodemo
knife cookbook create nginx -o cookbooks
This is also a folder. We look.
cd cookbooks
tree
.
|-- attributes
|-- definitions
|-- files
| `-- default
|-- libraries
|-- metadata.rb
|-- providers
|-- README.md
|-- recipes - рецепты "что сделать". default.rb выполняется по умолчанию, если не указать другой. По
одному рецепту в файле.
| `-- default.rb
|-- resources
`-- templates - шаблоны в формате ERB.
`-- default
Recipe is a script that describes what needs to be done. Both Ruby and Bash, Perl, Python, csh inserts are supported.
There can be several recipes, but “default” is executed unless you specify one specifically (when calling the cookbook).
In recipes / default.rb add
package "nginx"Save.
“Package” here is a resource. You can view the list with a description of the built-in resources on the wiki . They can be supplemented and expanded directly in cookbooks if necessary. The language in which the recipes are written is Ruby DSL . Logic is built from the opposite. We simply say that the package “nginx” must be installed on the server. And Chef makes sure that it is doing what is required. In principle, the same can be described in any other language. But there are many convenient things, as they say, “out of the box”. Of course, there are nuances. For example, with packages, it is important to set the name correctly. So, for apache you need to write a condition, because in RPM-based distributions it is httpd, in Debian it is apache2.
Next, go to the test server and set hostname. This is important because Chef distinguishes nodes by it.
hostname testserver.example.com
echo "testserver.example.com" > /etc/hostnameand in / etc / hosts add
10.10.10.10 testserver.example.comWe check:
hostname -fIf the answer is "testserver.example.com" - everything is fine. No - edit / etc / hosts.
Now, from the local machine from the solodemo folder:
knife prepare [email protected]
You will have to wait a bit and, possibly, enter the password for sudo. "Prepare" will install a chef-client that will accept commands.
A file of the form testserver.example.com.json should appear in the nodes folder. We write in it:
{ "run_list": ["recipe[nginx]"] }
That is, you need to run the cookbook "nginx", or rather, the recipe "default" from it.
Later
knife cook [email protected]
conclusions
Yes, there are a lot of dances around one nginx. But there are cookbooks for trivial tasks, with which they are quite flexible and thoughtful. And for non-trivial ones - once a written cookbook allows the installation to be fully automated, it is a kind of documentation. I spent a week to figure out and describe the installation of the first server, but the installation from scratch now takes about 20 minutes. Is this often necessary? Not yet. But configuring now is a pleasure. And if you still write documentation, so why not do it right away on Chef? Yes, and the customer can lift and "touch" everything on his virtual machine with a pair of commands.
I decided not to overload the article with information. This is still more of a guide. But the terms are made by links, so anyone interested is easily found.
References
- Video by Matt Schaeffer , for which immense gratitude to him. :) It is advisable to watch all episodes at once.
- Repository with official cookbooks. You can learn a lot from them, or use completely.
- Site and Chef Wiki.
