Найкраща стратегія, щоб тримати під контролем версії кухарів кухарів

Я шукаю ідеї щодо управління версіями шеф-кухарів. Я знаю, що ви закріплюєте конкретні версії в оточенні, але я не впевнений, як це зробити.

Ми використовуємо бібліотекаря-шеф-кухаря, який встановлює книги сторонніх громад у папку кулінарних книг. Ми ніколи не торкаємось цих книг, а час від часу лише оновлюємо новіші версії.

У нас також є власні спеціальні кулінарні книги, від яких ми включаємо їх у спільноту ( include_recipe).

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

Тому немає гарантії, що коли ви завантажуєте кулінарну книгу на сервер шеф-кухаря, вона не порушиться, оскільки залежні кулінарні книги також можуть змінитися.

Єдине рішення, яке я бачу на даний момент, - це вказати кожну версію кулінарної книги, яку ми використовуємо в конфігурації середовища, включаючи спільноту та користувацькі. Але тоді я повинен пройти кожну кулінарну книгу і розібратися в тих версіях.

Ми також час від часу робимо оновлення бібліотекаря-шеф-кухаря, і я думаю, що може бути важко відслідковувати версії, які змінилися, і не забувати оновлювати версію в середовищі, коли настане час.

Будь ласка, поділіться своїм досвідом та найкращими практиками. Я впевнений, що це буде дуже корисно для інших людей.

Невдовзі після того, як я серйозно почав використовувати шеф-кухаря, я підходив до цих же проблем. До певного почуття розуму я прийшов лише тоді, коли почав робити чотири речі оперативно. Зауважте, що деякі з них можуть не вважатися "найкращими методами" у спільноті шеф-кухарів. Тим не менш, саме так я привнесла в свій світ розум, повторюваність і порядок.

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

Сподіваюся, це комусь допоможе!

- ОНОВЛЕННЯ -

Майже через три роки ці принципи мені залишилися корисними. Але я додам ще одну пораду, і це дійсно з тих же причин, що я віддав перевагу шеф-кухару-соло перед шеф-кухарем.

5. ВИКОРИСТОВУЙТЕ НЕМАТИЧНУ ВСТАНОВУ

Є дві проблеми:

1. керувати версіями кулінарної книги в різних об'єктах навколишнього середовища
2. керувати версією рецептів у вузлі run_list.

Стаття Основи версій кулінарної книгиє найкращим посиланням для версій кулінарної книги. Відповідно до №1, ви маєте рацію, тому що керувати різною версією кулінарних книг, щоб обслуговувати різні набори конфігурації, це нелегка робота, особливо це поєднується із залежностями кухарської книги, де більшість кулінарних книг із сайту кулінарної книги не справляються із цією роботою. Тому конфігурація може порушитися. і якщо ви не керували версіями, перевіряючи поведінку будь-якого компонента, він просто порушується. Тож погана ідея завантажувати кулінарну книгу, не вказуючи номер версії у вашому об’єкті оточення. Тому керуйте версіями кулінарної книги в об'єкті навколишнього середовища та ретельно перевіряйте, рекламуючи версію будь-якої нової кулінарної книги. Зазвичай я керую об’єктом середовища в SCM і не завантажую його на сервер шеф-кухаря через автоматизовану роботу, поки змінена кулінарна книга не може добре працювати з рештою інших існуючих компонентів.

Відповідно до №2, це хитра тема, адже саме тут реальна залежність від рецепту працює на кожному вузлі. Коротше кажучи, для критичних вузлів вам краще контролювати залежність рецептів, вказавши версію рецепта у списку запуску вузлів / ролей. Я навряд чи це роблю, тому що це тонкий контроль зернистості та коштує більше витрат на тестування / просування. Однак для критичної ролі / вузла це не погана ідея, але забезпечують страхування від зміни конфігурації.