Подготовка серверов с помощью Chef Solo

В этой статье я хочу рассказать об использовании Chef Solo как для подготовки окружения разработчика (dev-серверов), так и для подготовки боевых серверов. На Хабре уже было несколько статей (Быстрое развертывание среды разработки и Development Environment при помощи Vagrant и Chef), посвященных разворачиванию dev-серверов с помощью Vagrant и Chef Solo. Я же хочу показать, как мы используем Chef Solo в нашей небольшой компании.

Наш web-проект требует довольно сложного окружения, так как используется многосерверная архитектура. Поэтому нам было жизненно важно автоматизировать подготовку такого окружения. Для решения этой задачи мы используем Vagrant и Chef Solo.


Vagrant — это open-source инструмент для создания виртуального окружения (с помощью VirtualBox, VMware, AWS и т.д.). Другими словами, это программа для простого управления виртуальными машинами. Среди прочих плюшек Vagrant поддерживает несколько систем управления конфигурациями (Chef, Puppet, Ansible). Под конфигурацией понимается состояние сервера (в данном случае — виртуальной машины), а именно: набор установленных пакетов, список запущенных сервисов, содержимое конфигурационных файлов, состав пользователей и т.д. То есть Vagrant умеет запускать процесс приведения машины в необходимое состояние сразу после запуска.

Vagrant идеально подошёл для создания окружения разработчика. Разработчику достаточно сделать клон Vagrant-проекта, и выполнить команду «vagrant up». Все остальное делается автоматически: скачивание образа виртуальной машины (если его нет на машине разработчика), запуск виртуальной машины с настроенными сетевыми параметрами и общими каталогами, запуск системы управления конфигурацией. Это обеспечивает единое окружение для всех разработчиков, что очень важно для больших команд или сложных проектов.

Chef — система управления конфигурациями серверов. Chef имеет клиент-серверную архитектуру. На Chef-сервере хранятся сведения о подключенных Chef-клиентах и наборы «рецептов» для их «приготовления» (то есть для приведения их в требуемое состояние). За использование Chef-сервера нужно платить (до 5 клиентов можно подключить бесплатно).

Почему был выбран Chef, а не другая система управлениями конфигурациями (серьезно смотрели только на Puppet):
  • большое community;
  • много готовых рецептов;
  • рецепты написаны на Ruby;
  • предсказуемый порядок выполнения рецептов (в отличие от Puppet);
  • поддерживается в Vagrant.

Chef Solo — это open-source версия Chef-клиента, которая позволяет использовать рецепты без Chef-сервера (рецепты должны быть физически расположенны на этой же машине). Chef Solo бесплатен, но имеет ряд ограничений по сравнению с клиент-серверным Chef'ом. Например, нет возможности использовать в рецептах поиск серверов по условиям.

Почему был выбран Chef Solo, а не клиент-серверный Chef:
  • бесплатно (у нас больше 5 серверов, но еще не тысячи);
  • безопасно (данные о наших серверах не хранятся на чужих серверах);
  • просто (работа с локальными файлами вместо консольных команд Chef-серверу);
  • сохраняется возможность легкого перехода на Chef-сервер (если серверов станет слишком много).

Chef Solo позволил полностью автоматизировать установку и настройку проекта на новом сервере. Разворачивание боевого сервера для нашего приложения обычно занимает около 10-15 минут (в зависимости от сложности рецептов).

Для управления серверами предназначен следующий проект. Из каталога данного проекта запускаются виртуальные машины с помощью Vagrant, а также выполняется подготовка настоящих серверов. В данном проекте уже добавлен один виртуальный сервер (demo), на котором устанавливается свежая версия nginx.

Структура проекта:
  • cookbooks/: каталог чужих рецептов, загруженных извне и неподлежащих редактированию. Подробнее.
  • data_bags/: каталог для хранения дополнительных данных, доступных из рецептов. Подробнее.
  • environments/: каталог окружений. Под окружением понимается определенный набор настроек, применяемых для сервера, разворачиваемого с указанием данного окружения. Именно тут разделяются настройки development/production. Для возможности использования таких окружений необходима версия Chef Solo не ниже 11.6.0 и версия Vagrant не ниже 1.3.0. Подробнее.
  • nodes/: файлы с атрибутами серверов. Для каждого сервера здесь должен присутствовать файл с именем равным его IP-адресу, содержащий значения атрибутов сервера, а также список ролей и рецептов, которые необходимо применить к серверу. Подробнее.
  • roles/: каталог ролей. Под ролью понимается определенный набор настроек, применяемых для сервера, которому назначена данная роль. Серверу может быть назначено несколько ролей. Подробнее.
  • site-cookbooks/: каталог своих рецептов. Содержит рецепты, написанные собственноручно для обеспечения специфических требований (например, деплой рабочих проектов). Этот каталог указывается в файлах «solo.rb» и «Vagrantfile» в качестве дополнительного хранилища рецептов.
  • deploy.sh: скрипт для подготовки боевого сервера (подробности ниже).
  • install.sh: скрипт для установки Chef Solo и его запуска на боевом сервере (подробности ниже).
  • solo.rb: конфигурационный файл Chef Solo.
  • Vagrantfile: файл настроек Vagrant. В нем перечисляются все виртуальные сервера.

Чтобы развернуть новый виртуальный сервер для разработки необходимо:
  1. В «Vagrantfile» связать имя сервера (например, «frontend») с его IP-адресом (например, «10.2.2.100»).
  2. В каталоге «nodes» создать JSON-файл атрибутов нового сервера (например, «10.2.2.100.json»).
  3. Запустить виртуальную машину командой «vagrant up» с указанием имени машины (например, «vagrant up frontend»). При первом запуске будет запущен Chef Solo, который выполнит все рецепты, указанные в соответствующем JSON-файле атрибутов. При этом будет использовано окружение «development» (это указано в «Vagrantfile»).

Чтобы поднять новый боевой сервер необходимо:
  1. В каталоге «nodes» создать JSON-файл атрибутов нового сервера (например, «23.144.12.15.json»).
  2. Запустить скрипт «deploy.sh» с указанием пользователя и IP сервера (например, " ./deploy.sh root@23.144.12.15"). Скрипт «deploy.sh» внутри себя осуществляет SSH-подключение к серверу, поэтому все дополнительные параметры, указанные при запуске этого скрипта, будут использованы в качестве параметров команды «ssh» (это важно при входе по ключу). Под Windows мы запускаем этот скрипт в Git Bash, так как для его выполнения нужны некоторые *nix-команды, которых нет в «cmd.exe».

Скрипт «deploy.sh» выполняет следующие действия:
  1. подключается к серверу через SSH;
  2. архивирует весь каталог проекта и передает архив через SSH на сервер;
  3. распаковывает архив на сервере в каталог "~/chef";
  4. запускает скрипт установки «install.sh».

Скрипт «install.sh» выполняет следующие действия:
  1. проверяет, установлен ли Chef Solo, и при необходимости устанавливает его. На серверах мы используем Ubuntu, поэтому для других систем возможно потребуется поправить команды для установки Chef.
  2. запускает Chef Solo с указанием конфигурационного файла «solo.rb» и JSON-файла настроек сервера. При этом будет использовано окружение «production» (это указано в «solo.rb»).

Кроме первоначальной подготовки сервера часто возникает необходимость обновить его конфигурацию. Например, нужно обновить некоторые пакеты, выложить новую версию приложения или применить последние изменения в рецептах. Для виртуального сервера эту операцию выполняет команда «vagrant provision #имя_машины#». Для боевого сервера нужно повторно запустить "./deploy.sh root@#ip_сервера#".

Скрипты «deploy.sh» и «install.sh» написаны по мотивам статьи Chef Solo tutorial: Managing a single server with Chef.

Вместо «deploy.sh» можно посмотреть на knife-solo, но у него есть несколько недостатков по сравнению с предложенным способом:
  • на машину, с которой осуществляется подготовка сервера, придется ставить Chef;
  • для работы под Windows требуется cygwin+rsync (нетривиальная настройка);
  • установка Chef на сервере осуществляется через Opscode Installer, у которого есть проблемы с установкой некоторых gem-пакетов (эта проблема решается указанием своего скрипта установки).

Вот так, с помощью нехитрых приспособлений, можно относительно просто разворачивать виртуальные сервера для разработки и боевые сервера для рабочих проектов. Надеюсь, моя статья окажется кому-нибудь полезной.
Share post

Similar posts

Comments 15

    0
    Долго выбирал между Chef и Puppet, решил всё таки использовать Puppet, имхо(!) он удобней в конфигурировании и поддержке, плюс хорошая инфраструктура.

    И, что самое главное, не требует написания каких-то .sh скриптов и не имеет проблем с установкой.
      0
      у чефа абсолютно нет проблем с установкой: curl -L opscode.com/chef/install.sh | bash и все, он у вас уже стоит
      А что в puppet есть такого, чего нет у чефа? по инфраструктуре
        0
        Из топика:
        установка Chef на сервере осуществляется через Opscode Installer, у которого есть проблемы с установкой некоторых gem-пакетов (эта проблема решается указанием своего скрипта установки).


        А по поводу второго предложения — я не говорю, что Puppet лучше и у него есть то, чего нет у Chef-а, просто он мне удобней и в итоге сделал выбор в именно сторону Puppet-а. Ну и среди знакомых больше кукловодов, чем шефов:)
        0
        Большой плюс для puppet — существует Pro Puppet книга :) Chef по их документации, вообщем-то как и puppet, сложен для старта, имхо.

        А не имеет проблем с установкой — вы что имеете ввижу? Puppet apply или просто puppet все равно надо как-то устанавливать на изначально лысую машину, и по-моему делать это все равно придется через .sh
          0
          Про Chef тоже недавно вышла хорошая книга:
          Chef Infrastructure Automation Cookbook
            0
            Puppet apply или просто puppet все равно надо как-то устанавливать на изначально лысую машину, и по-моему делать это все равно придется через .sh

            В этом плане хорош ansible — на управляемые им узлы вообще ничего устанавливать не приходится.
            0
            Имхо, оба инструмента замечательны, однако для начинающих и далёких от Ruby советую начинать с Puppet. В любом случае, чтобы вы ни выбрали — ваша жизнь станет ярче и немыслима без подобных инструментов.
              0
              После появления Ansible я у Puppet больше не вижу ровным счетом никаких плюсов.

              Минусы у puppet довольно большие — тормоза, сложность расширения, сложность работы с изменяемыми переменными, сложность установки если хочется больше чем самый базовый вариант установки.
              0
              Open Source Chef — The open source server is a free version of the server. Each instance of the open source server must be configured and managed locally, including data migrations, applying updates, and ensuring that the local infrastructure scales appropriately. The open source server includes support from the community. Support from Opscode is optional.

              В Undev используем для развертывания на сотнях машин.
                0
                Спасибо за наводку, почему-то на сайте opscode сразу не заметили этой версии Chef-сервера.
                Вероятно, с ростом количества машин перейдем на него.
                0
                Отличная вещь, я тоже много думал об именно таком подходе (без chef сервера и чтобы одинаковый сценарий для vargrant/prod).

                Жаль, что у вас install.sh заточен под Debian. Вообще, разве opscode не поставляет .sh скрипт для платформо-независимой установки? Я где-то что-то подобное видел, только не могу вспомнить про puppet или про chef это было.
                  0
                  *заточен под Debian — сорри Ubuntu
                    0
                    разве opscode не поставляет .sh скрипт для платформо-независимой установки?

                    Такой скрипт есть. Выше про него уже написали: curl -L opscode.com/chef/install.sh | bash.

                    Но такой способ установки не всегда подходит, так как могут возникнуть конфликты с некоторыми gem-пакетами, которые используются в рецептах (например, «ruby-shadow» или «pg»).

                    Если же поставить сам Chef в виде gem-пакета (как в install.sh), то этих проблем нет. Адаптация «install.sh» под другую платформу не должна стать проблемой, если эта другая платформа позволяет устанавливать gem-пакеты.
                    0
                    Есть хороший набор статей по Chef Solo leopard.in.ua/2013/01/04/chef-solo-getting-started-part-1/ и Chef Server leopard.in.ua/2013/02/17/chef-server-getting-started-part-1/
                      0
                      Статья немного чепуха и боюсь введет в заблуждение новичков.
                      Chef-solo решение не плохое, но chef сервер можно и не у opscode хостить, тогда он бесплатный.
                      К тому же, используя chef-solo вы без серьезных заморочек не сможете использовать поиск по атрибутам ноды, а это очень серьезный минус, так как теряются серьезные плюсы автоматизации.
                      Еще из минусов chef-solo — невозможность использовать API chef сервера, которое очень серьезное и удобное.
                      А если вам не нужен API сервера шефа, то я рекомендую вам посмотреть в сторону ansible. Простой YAML синтаксис вместо вырвиглазного JSON, отличная документация, великолепная оркестрация (в отличии от chef-solo и chef). И нет никакой необходимости в каком-либо клиенте на серверах.

                      Only users with full accounts can post comments. Log in, please.