Express 42
Компания
32,26
рейтинг
5 июня 2013 в 18:23

Разное → Инструменты DevOps-инженера: Librarian

Данная статья предназначена для тех, кто использует или планирует начать использовать систему управления конфигурацией Opscode Chef.

Основная задача внедрения любой системы управления конфигурацией, будь то Chef, Puppet или что-то еще, — повторяемо воспроизводить и обновлять окружение всех сред, использующихся при разработке ПО (dev, CI, QA, stage, production). Отсюда следует, что само описание конфигурации необходимо однозначно хранить и обновлять. К сожалению, возможности по версионированию, которые есть в Chef, достаточно ограничены. Поэтому в связке с Chef в последнее время стали активно использовать Librarian. Но перед тем, как рассказать о нем, поговорим немного о кукбуках.

Кукбуки (более подробно о том, что это такое, можно прочитать здесь) можно разделить на 3 вида:
  1. кукбуки с сайта community.opscode.com;
  2. кукбуки с GitHub и других мест;
  3. собственные кукбуки проекта.

В вашем проекте все кукбуки могут лежать в папке cookbooks под управлением системы контроля версий. И если для собственных кукбуков это единственный разумный способ, то для кукбуков первых двух видов это решение кажется достаточно странным. По той простой причине, что проверять обновление, управлять зависимостями и обновлять такие кукбуки вам придется в „ручном“ режиме. Помимо всего прочего, если вы возьмете кукбук и просто добавите его в папку cookbooks, вспомнить потом, откуда вы его взяли, будет крайне непросто. Кукбуки с GitHub можно хранить как git submodules, но это не решает большинства проблем, которые здесь перечислены.

Более того, если какой-то из используемых вами кукбуков имеет зависимости (они прописаны в файле metadata.rb кукбука), то добавлять зависимости в проект вам придется вручную.

Все эти проблемы можно избежать, если использовать Librarian. Это инструмент, который помогает управлять зависимостями и версиями ваших кукбуков.

Есть еще похожий проект, который делает почти то же самое, — Berkshelf. Он появился позже Librarian, тянет с собою кучу зависимостей, имеет в 2 раза меньше инсталляций (судя по rubygems), но зато чуть лучше документирован. Выбор одного из них — исключительно дело вкуса. В любой момент можно перейти на другой инструмент, потому что файлы описания зависимостей у них идентичны. Мы используем Librarian, но то, что написано дальше, практически полностью актуально и для Berkshelf.

Представим себе очень простой проект, в котором используется совсем немного кукбуков. Начнем использовать librarian с помощью команды init, которая создает начальный файл Cheffile — в нем будет храниться описание используемых вами кукбуков.

$ librarian-chef init
  create  Cheffile
$ cat Cheffile
site 'http://community.opscode.com/api/v1'


Добавим в наш файл одну строчку и выполним librarian-chef install

$ cat Cheffile
site 'http://community.opscode.com/api/v1'

cookbook 'lvm'

$ librarian-chef install
Installing lvm (0.8.6)


Данная команда поставит все необходимые кукбуки в папку cookbooks и создаст файл Cheffile.lock.

$ ls cookbooks
lvm

$ cat Cheffile.lock
SITE
  remote: http://community.opscode.com/api/v1
  specs:
    lvm (0.8.6)

DEPENDENCIES
  lvm (>= 0)


Мы храним локальные для проекта кукбуки в папке inhouse-cookbooks. Это те кукбуки, которые специфичны именно для этого проекта. В Cheffile мы добавляем следующее:

cookbook 'project42',
        :path => 'inhouse-cookbooks/project42'


Также в Cheffile можно ссылаться на конкретные ревизии кукбуков в гите.

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"



Такая комбинация возможностей позволяет легко и удобно всегда собирать одни и те же кукбуки в папке cookbooks.

Надо четко понимать, что актуальный «срез» всех кукбуков хранится в файле Cheffile.lock, а файл Cheffile является только «подсказкой» о том, как Cheffile.lock собирать, и его одного для версионирования кукбуков недостаточно. Если у вас нет Cheffile.lock, то в зависимости от того, в какое время вы выполнили команду librarian-chef install, Cheffile.lock у вас получится разным. Даже если вы зафиксируете явно все версии используемых кукбуков в Cheffile (чего делать категорически не советуется), то кукбуки, которые соберутся по зависимостям, могут отличаться.

Более того, если вы явно укажете версии необходимых вам кукбуков, обновление кукбуков станет гораздо более сложным.

Но что делать, если необходимо обновить какой-то кукбук? Например, мы узнали, что вышла версия кукбука lvm, с какими-то нужными нам изменениями. Тогда мы делаем следующее:

$ librarian-chef update lvm


Данная команда обновит кукбук lvm на последний доступный. Более того, она обновит все зависимости кукбука lvm, если это будет необходимо. Мы рекомендуем после этого делать git diff Cheffile.lock, чтобы убедиться, что поменялось ровно то, что вы хотели. Кстати, если вы пропишете в Cheffile версию для какого-то кукбука, от которого зависит lvm, то lvm может и не обновиться, и вам долго придется гадать, почему это происходит.

Можно это понимать еще и так: Cheffile — это описание необходимых требований к версиям кукбуков на текущий момент, а Cheffile.lock — это срез, удовлетворяющий этим требованиям на текущий момент.

И еще один момент, который не стоит забывать, при работе с librarian. Каждый раз перед тем, как залить какой-то рецепт на chef-server, необходимо делать git pull и librarian-chef install. Потому что если кто-то залил более свежий рецепт, в вашей локальной папке cookbooks автоматически ничего не поменяется.

Возможно, такой подход может показаться несколько сложным, но он того стоит. Ведь он гарантирует всегда актуальный срез кукбуков, автоматическое управление зависимостями, а также гибкость использования локальных кукбуков, кукбуков с сайта Opscode и кукбуков из различных git-репозитариев, в том числе с гитхаба.
Автор: @evtuhovich
Express 42
рейтинг 32,26
Компания прекратила активность на сайте

Комментарии (21)

  • +3
    Нормально, налицо копирование хороших практик с Bundler.

    Пожалуй, перейду с подмодулей на Librarian.
    • 0
      Привет, Акжан!

      В Librarian, как и в Berkshelf, выдран кусок Bundler, который зависимости вычисляет. Так что это не просто «копирование практик». А так да, идеологически то же самое, что и сабмодули, но удобнее.
  • 0
    Как про Berkshelf прочитал:) Пожалуй попробую, т.к. у Berkshelf не прозрачно с удалением кукбуков как то.
    • +1
      По-мне, так шило на мыло. В чем-то получше berkshelf, в чем-то — либрариан. Мы в компании раз 5 метались туда-обратно, остановились на либрариане пока.
  • 0
    Интересный тул. Можно попробовать, хотя пока мы не сталкивались с необходимостью апдейтить гитхабовские кукбуки, которые закинули себе. Но могу представить себе кейс, когда это было бы полезно.

    А вот не подскажите ли инструмент для управления значениями аттрибутов, более удобного, чем то, как это сейчас организовано из коробки в шефе. А то мы свой наколенный велосипед написали, чтобы все конфиги хранились в одном ямле.
    • +1
      Мы храним все аттрибуты в ролях, роли в roles/rolename.rb, а потом заливаем их knife role from file roles/rolename.rb.

      Из всего, что я знаю — это самый лучший способ.
      • 0
        роли, да — это стандартный инструмент и он немного не о том. Есть, скажем, N различных окружений, которые поднимаются шефом(develop, CI, QA, production,etc.), для каждого окружения мы создавали конфиг файл, в котором перечисляли роли и рецепты, которые должны отработать на конкретном инстанце, а также переопределяли аттрибуты. Затем нужно было только сказать шефу выполнить тот или иной конфиг. Но это не удобно — потому что с увеличением количества различных конфигураций виртуалок, увеличивалось количество конфигов с переопреденными аттрибутами. Мы придумали свою систему с наследованием и т.п. усовершенствованиями — все аттрибуты храним в yaml файле и вычитываем нужную конфигурацию по запросу. Вот хотелось узнать у людей, которые используют шеф — может уже появился стандартный инструмент управления конфигурациями?
        • 0
          Стандартный инструмент управления конфигурациями к инструменту управления конфигурациями системы управления конфигурациями (читай пакетами)? ;))

          • 0
            Есть придирки к мелочам, но в целом шутка удалась :-)
            • 0
              В каждой шутке, есть доля шутки. Но реалии таковы, что уже не до шуток. :)
        • 0
          я использовал databag'и, по сути тоже самое делал, в json хранил атрибуты и грузил их по ролям…
        • 0
          Нет, ничего такого я не встречал.

          Мы храним настройки окружений в git в environmets/env.rb. Единственное, что мы не храним и не версионируем — это связки нода-роль. Все остальное лежит в системе контроля версий. Обязательно поделюсь где-нибудь, когда придумаю, как можно сделать это удобно.
          • 0
            Я правильно понимаю? Если стоит задача развернуть несколько mysql серверов с разными конфигурациями, то под каждый сервер вы определяете новую роль и форкаете репу и модифицируете параметры?
            • 0
              Если нам надо несколько серверов mysql с разными параметрами, то мы делаем несколько вызовов lwrp для mysql.

              А в каких рецептах будут эти вызовы lwrp и как эти рецепты будут привязаны к ролям — зависит от конкретной задачи.

              Если немного подробнее, то мы подцепляем все рецепты через librarian, а в локальных рецептах храним только описание текущего проекта, в котором декларативно вызываются только стандартные ресурсы шефа и lwrp из подключенных рецептов.
  • 0
    По следам только прошедшей конференции от опскод — беркшелф набирает популярность, про библиотекаря никто не упоминал, так что я бы советовал использовать его, если хотите задел на будущее. Да и гитхаб аккаунт их выглядит посерьезнее: github.com/riotgames

    А технологически и то, и то — бандлер, конечно.
    • 0
      Да, вокруг беркшелфа больше хайпа, об этом нет смысла спорить даже. Мы пробовали оба инструмента использовать, но по второстепенным причинам нам librarian понравился гораздо больше. Кстати, он недавно обновился до версии 0.1.0 и на гитхабе появился к нему нормальный хелп github.com/applicationsonline/librarian-chef
  • +1
    Я наверное немного не по адресу, но может кто-нибудь сможет помочь с Puppet?
    stackoverflow.com/questions/16891580/github-boxen-puppet-how-to-use-global-exec-path-in-my-manifest
    • 0
      Я не совсем специалист в puppet, но есть рассылка groups.google.com/forum/?fromgroups#!forum/devopsru там специалистов много, можно там спросить.
      • 0
        благодарю!
  • +2
    Добрый день! Спасибо за статью, сам использую berkshelf для шефа, но альтернатив для паппета кроме librarian вроде нет.

    У меня есть вопрос, но не совсем по теме: с локом версий кукбуков понятно, а вот можно ли так же в стиле бандлера фиксировать версии пакетов (устанавливаемых package ресурсом)?

    Пример: ubuntu 12.04.2 ставит mysql-server 5.5, но нужно чтобы явно ставился 5.1. Я пока знаю только способ указывать явно версию атрибутом version для package. Т.е., например, если есть список пакетов, я храню их в хеше имя — версия и потом прохожусь по нему с each.

    Спасибо.
    • 0
      Когда нужно иметь две версии(mysql/pgsql, nginx итд) мы прибавляем к имени пакета его версию. Например, пакеты с postgresql 9.1 и 9.2 соответственно называются postgresql-9.1 и postgresql-9.2. Способ подходит, если таких пакетов мало.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное