Чи підходять інструменти управління конфігурацією для використання в якості інструментів розгортання?

З моєї відповіді на запитання: Як DevOps може допомогти покращити процедури програмного забезпечення? У Тенсібая виникло питання:

Що б вимагало Капістрано на вершці лялечки чи шеф-кухаря?

Моєю відповіддю було розмістити посилання на статтю Ноя Гіббса "Чи потрібні нам і Капістрано, і шеф-кухар?" . Особисто я все ще підписуюся на думку Ноя, що це найбільш доречно:

• використовувати для розгортання спеціалізований інструмент розгортання, такий як Capistrano.
• використовувати для управління конфігурацією спеціалізований інструмент управління конфігурацією, такий як Chef.

Фундаментальний підхід, який використовує кожен тип інструменту для виконання своєї задачі, дуже різний:

• Інструменти управління конфігурацією - це створення та підтримка потрібного стану системи, вони за своєю суттю є безсильними. Прикладами інструментів управління конфігурацією є Chef , Puppet , Ansible , PowerShell DSC , Salt Stack .

• Інструменти розгортання - стосуються доставки версій програмного забезпечення в середовище хостингу, вони надають функціональність для підтримки декількох версій програмного забезпечення на декількох машинах та управління, яка версія є "поточною", вони по суті є обов'язковими за своєю суттю. Прикладами інструментів розгортання є Capistrano , Octopus Deploy , Deployer та Command.io .

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

Запитання: Чи дозріли інструменти управління конфігурацією, такі як Chef, Ansible та Puppet, до того, що вони здатні виконувати як безвідмовні, так і імперативні моделі?

У такому контексті слід негайно застосувати типову пораду: використовувати правильний інструмент для роботи.

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

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

Через це цілком можливо, щоб цілі частини процесу розробки програмного забезпечення були охоплені / перекриті кількома інструментами (наборами), навіть якщо їх основна особливість / можливість відрізняється.

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

Зробити це питання насамперед на основі думки;)

Інструменти управління конфігурацією використовуються для переходу системи у відомий стан. Інструменти розгортання розгортають нові програмні файли та програмні дані в систему. Зрештою, обидва типи інструментів мають певну комбінацію:

• Визначте поточний стан системи.
• Передача файлів у систему.
• Додавання або зміна стійких даних (наприклад, файли конфігурації, дані бази даних, настройки реєстру)
• Запуск або перезапуск програм.

Інструменти управління конфігурацією мають декларативні мови, які вказують стан системи. Інструменти розгортання мають обов'язкові мови, які дозволяють системі робити щось. Людині DevOps потрібно робити і те, і інше.

Використовуючи інструмент розгортання Capistrano, незграбно використовувати його мову, щоб сказати системі, щоб переконатися, що веб-сервер активний. Ви повинні надати команду перезапустити веб-сервер та ще одну перевірити, чи веб-сервер не працює. Перевести веб-сервер у відомий стан неприємно.

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

Деякі люди воліють виконувати обидва типи робіт одним інструментом та обробляти шорсткі краї. Інші люди воліють мати два інструменти, щоб зробити майже те саме, але без шорстких країв. Щоб відповісти на питання, "відповідність" - це питання смаку. Ця відповідь пояснює, чому.

TL; DR : Просто використовуйте Ansbile, це і конфігурація, і інструмент розгортання :)

Існує кілька типів розгортання:

• На основі програми (файли, пакети архівів)

• На основі контейнерів (включає в себе VM, Habitat, LXC, Docker)

• На основі функцій (Мікросервіси / Лямбди / Функції)

Я припускаю, що в цьому випадку ми говоримо лише про оновлення програм на серверах.

Для розгортання потрібно, щоб відбулося дві речі:

1. Правильні файли або пакети потрібно перемістити на сервер.
2. Конфігурацію та стан обслуговування потрібно змінити.

Тепер для (1) ви можете використовувати кілька стратегій:

• Артефакти / сховища
• Пакети сховищ / Менеджери пакунків
• Система контролю версій / оновлення + компіляція (необов'язково)
• Протоколи передачі файлів (scp, rsync, ftp)
• Інструменти розгортання

Для (2) ви можете використовувати:

• Інструменти управління конфігурацією
• Інструменти розгортання

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

З особистого досвіду я використовував усі комбінації, але в даний час ми використовуємо Capistrano для розгортання та синхронізацію Ansible для управління конфігурацією, а також VCS і сховища пакетів для передачі файлів, але з Capistrano є проблеми, і ми плануємо перейти від нього до об'єднати програму Ansible як для розгортання, обслуговування та управління конфігурацією.

Розгортання додатків важко вирішити, оскільки в ньому багато проблем. Системи керування конфігурацією чудово підходять для моделювання завдань, які є конвергентними та працюють із тим, "який бажаний стан системи". У контексті розгортання програми це чудово підходить для таких речей, як розгортання бітів на машині, керування файлами конфігурації та налаштуванням системних служб. Що вкрай погано - це речі, які по суті є процедурними, зокрема міграції баз даних та перезавантаження сервісу. Я, як правило, намагаюся ввести логіку конвергенції в Chef і дозволю зовнішньому процедурному інструменту (як правило, Тканина в моєму випадку) обробляти кілька решти бітів, а також послідовність дійсних конвергентів.

Отже, в основному, ви повинні використовувати обидва для тих частин, які найкраще вміють.

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

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

Для веб-сервісів Amazon це API досить зручно керувати здебільшого, але для тих із нас, хто має керувати власними центрами обробки даних, це не варіант. З цієї причини проект Foreman (і Red Hat, який ребрендує це ) визнав за необхідне об'єднати Katello , Candlepin та менеджер конфігурацій, таких як Ansible, Foreman або Puppet разом при розгортанні сценарію Katello .

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