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

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

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

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

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

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

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

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

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

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

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

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

- ОБНОВИТЬ -

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

5. ИСПОЛЬЗУЙТЕ ANSIBLE INSTEAD

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

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

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

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