Чому люди використовують Puppet / Chef з Amazon Cloud Formation замість того, щоб просто використовувати CloudInit?

Ми плануємо використовувати екземпляри AMI EC2, які не є "попередньо запеченими". Тобто, коли вони обертаються, вони просто встановлюють AWS linux. Наш процес завантаження завантажить різні встановлення, які нам потрібні, наприклад, python, tomcat. У нас буде мінімум 3 примірники та максимум 8.

З огляду на ці вимоги, чи буде корисним використання Puppet / Chef, а не використання Amazon Cloud Formation (CloudInit)?

Найкраще, що я бачу, це те, що якщо ми використовували Puppet, тоді у нас було б декларативне програмування, яке легше перевірити, щоб побачити, що відбувається, порівняно зі сценарієм. Також CloudInit має обмеження розміру скрипта в 16 тис., На які ми можемо натрапити чи не зіткнутися.

Хтось перейшов із CloudInit до Лялькового чи Шеф-кухаря з конкретної причини, яку він може надати тут у відповідь на моє запитання?

Чи є перевага над CloudInit? Так, абсолютно багато з них!

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

CloudInit не є управлінням конфігурацією. Якщо ви вирішите почати використовувати програмне забезпечення для управління конфігурацією, використовуйте хмарний init лише для одного завдання: завантажити Puppet / Chef / інший агент.

Лялька не просто допомагає вам автоматизувати встановлення пакетів, налаштувати ключі ssh або налаштувати купу Tomcat. Це забезпечує стан речей. Коли розробник виконує усунення несправностей програми Java о 3 ранку та змінює конфігурацію Tomcat, Puppet змінить її назад. Ви можете швидко змінити версію Python для всіх або груп вузлів, і якщо хтось встановить іншу версію, Puppet змінить її назад.

Коли ваш стек програм змінюється, і ви починаєте використовувати, скажімо, RabbitMQ, або Jetty, або нову СУБД, ви можете легко протестувати та застосувати зміни на десятках або тисячах серверів.

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

Вся суть управління конфігурацією полягає в тому, щоб обертати машини передбачувано та послідовно. CloudFormation і cloudinit чудово підходять, коли ви обмежуєтесь лише AWS (хоча налагодження шаблонів CloudFormation - це жалюгідний досвід ), а як щодо програм, які використовують як ресурси ЦОД, так і AWS, або локальні середовища тестування, або машини для розробки?

Якщо ви існуєте виключно в AWS, я гадаю, ви могли б уникнути cloudinit і нічого іншого, але я не впевнений, що це реально для програм будь-якого масштабу (наприклад, Netflix попередньо випікає свої AMI за допомогою написаних ними технологій OSS) і випущений у світ; розгляньте це відео для деталей). Високодоступні програми є трансрегіональними, часто базуються на VPC, зазвичай створюють резервні копії до центрів обробки даних через VPN, і це навіть не стосується демонстраційних, інтерактивних, тестових або середовищ розробки. Як хтось, хто доручений машинам забезпечення, останнє, що я хочу зробити, - це повторити роботу або застрягти в налагодженні декількох методів забезпечення.

Звідси шеф-кухар чи маріонетка. Вони працюють так само добре для AWS, як і для мого центру обробки даних, і так само добре, як і для моєї машини-розробника під управлінням Vagrant, як і для демонстраційних середовищ, які мені час від часу потрібні на льоту. Я б набагато запустив Chef або Puppet із cloudinit, ніж підтримував і cloudinit, і Chef або Puppet.

Для серверів, що викидають, скажімо, працює за групою автомасштабування, я б сказав, що cloudinit, мабуть, достатньо. сценарії оболонки Linux або скрипти PowerShell Windows повинні зробити це.

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

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

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

Твій вибір.