Назад | Перейти на главную страницу

Лучшая стратегия держать версии поваренных книг под контролем

Я ищу идеи по поводу управления версиями поваренных книг. Я знаю, что вы закрепляете определенные версии в среде, но не знаю, как это сделать.

Мы используем librarian-chef, который устанавливает книги стороннего сообщества в папку cookbooks. Мы никогда не трогаем эти книги и время от времени обновляем их до более свежих версий.

У нас также есть свои собственные кулинарные книги для конкретных сайтов, из которых мы включаем сообщества (include_recipe).

Теоретически мы могли бы указать конкретные версии книг сообщества, от которых зависят наши пользовательские книги, а затем установить версии наших кулинарных книг в конфигурации среды, но проблема в том, что эти книги сообщества могут полагаться на некоторые другие книги без указанных версий. И эта глубоко вложенная зависимость может продолжаться.

Таким образом, нет гарантии, что при загрузке книги рецептов на сервер шеф-повара продукт не сломается, поскольку зависимые книги рецептов также могут измениться.

Единственное решение, которое я вижу на данный момент, - это указать каждую версию поваренной книги, которую мы используем в конфигурации среды, включая сообщества и пользовательские. Но потом мне нужно просмотреть каждую поваренную книгу и выяснить эти версии.

Мы также время от времени проводим обновления библиотекаря-повара, и я полагаю, что может быть сложно отследить версии, которые изменились, и не забыть обновить версию в среде, когда придет время.

Поделитесь, пожалуйста, своим опытом и лучшими практиками. Я уверен, что это будет супер полезно для других.

Вскоре после того, как я всерьез начал использовать Chef, я столкнулся с теми же проблемами. Я пришел к некоторому рассудку только тогда, когда начал выполнять четыре операции оперативно. Обратите внимание, что некоторые в сообществе Chef могут не считать это «передовым опытом». Тем не менее, именно так я привнес в свой мир здравомыслие, повторяемость и порядок.

  1. Создавайте собственные рецепты. Я вообще перестал пользоваться кулинарными книгами сообщества и просто создал свои рецепты в соответствии со своими требованиями. Таким образом я управляю и контролирую свои собственные зависимости. Многие будут возражать против этого, но, честно говоря, если бы я сначала прочитал некоторые из Opscode и рецептов сообщества, я бы, вероятно, не выбрал Chef в качестве своего решения для начала. Я стараюсь держать свои рецепты простыми и соответствующими своему стилю работы. В моем репозитории ровно ноль кулинарных книг сообщества.
  2. Относитесь к обновлениям дисциплинированно. Если я обновляю рецепт, я удостоверяюсь, что он работает везде, и я испытываю дополнительные трудности, связанные с его развертыванием везде, даже если это нарушит мой рабочий процесс и добавит трений. В конечном итоге это ключ к рассудку шеф-повара. В крайних случаях, если мне нужны варианты для некоторых хостов, например тестовая или производственная среда, я кодирую их в кулинарной книге. Но моя философия заключается в том, что самую последнюю версию каждой кулинарной книги можно безопасно применять везде, где они необходимы.
  3. Используйте Chef Solo для всего. Каждые несколько месяцев мне почему-то приходит в голову, что я должен снова попробовать использовать Chef Server. Версия для сообщества улучшается, но, похоже, вся парадигма никогда не подходит моему миру. И каждый раз, когда я пытаюсь, я бью себя пальцами по лицу. Парадигма Chef Server подходит для мира с долгоживущими серверами, которые требуют частой смены системы. Я вношу изменения в систему так редко, что постоянно проверять обновления на сервере шеф-повара - это просто глупо. И у меня есть гораздо лучшие инструменты, чтобы убедиться, что мои хозяева здоровы. Моя работа связана с миром одноразовых виртуальных машин, где они могут пережить только одно или два изменения конфигурации. Теперь я использую исключительно Chef Solo и отправляю изменения своим хостам, а также отправляю одни и те же кулинарные книги всем хостам, которые в них нуждаются.
  4. Избегайте компиляции программного обеспечения во время запуска Chef. Самый крайний (т.е. глупый) случай для меня был связан с компиляцией ruby-1.9.3 из исходников каждый раз, когда я загружал новый ящик. Но создание собственных пакетов часто может оказаться головной болью. Как только я обнаружил отличный инструмент fpmупаковать мои собственные rpms, debs и gems стало тривиально, что сделало мою жизнь намного более эффективной и легкой.

Надеюсь, это кому-то поможет!

- ОБНОВИТЬ -

Почти три года спустя эти принципы остались для меня полезными. Но я добавлю еще один совет, и это действительно по тем же причинам, по которым я предпочел шеф-соло шеф-повару.

  1. ИСПОЛЬЗУЙТЕ ВОЗМОЖНОЕ ВМЕСТО

Есть 2 проблемы:

  1. управлять версии поваренной книги в разных объектах среды
  2. управлять версия рецепта в узле run_list.

Статья Основы версий кулинарных книг - лучший справочник по версиям кулинарных книг. Согласно пункту 1, вы правы, потому что сложно управлять разными версиями кулинарных книг для обслуживания различных наборов конфигурации, особенно это смешано с зависимостями кулинарных книг, где большая часть кулинарных книг с сайта кулинарных книг не справляется с этой задачей. Так что конфигурация может сломаться. и если вы не управляли версиями, проверяя поведение любого компонента во время выполнения, он просто ломается. Так что загружать кулинарную книгу без указания номера версии в вашем объекте среды - плохая идея. Так что управляйте версиями поваренной книги в объекте среды и внимательно проверяйте, продвигая версию любой новой поваренной книги. Обычно я управляю объектом среды в SCM и не загружаю на сервер Chef через автоматическое задание, пока измененная кулинарная книга не будет хорошо работать с остальными другими существующими компонентами.

Согласно пункту 2, это сложная тема, потому что именно здесь реальная зависимость рецепта работает на каждом узле. Вкратце, для критических узлов лучше контролировать зависимость рецептов, указав версию рецепта в списке выполнения узла / роли. Я почти не делаю этого, потому что это хороший контроль над зернистостью и дороговизна тестирования / продвижения. Однако для критически важной роли / узла это неплохая идея, но она обеспечивает страховку от изменений конфигурации.