Чим НЕ слід керувати лялькою?

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

Як приклад, ми зазвичай беремо як належне, що імена хостів уже налаштовані перед тим, як позичати систему керуванню лялькою. Базовий IP-зв’язок, принаймні в мережі, яка використовується для досягнення лялькового майстра, повинна працювати. Використання маріонеткового типу для автоматичного створення файлів зон dns є привабливим, але зворотні вказівники DNS повинні бути вже на місці, перш ніж запускати річ або сертифікати.

Тож чи варто залишати конфігурацію IP від ​​лялькової? Або я повинен її встановити перед тим, як вперше запустити ляльку, але все-таки керувати ip-адресами з лялькою? Що з системами з декількома IP-адресами (наприклад, для WAN, LAN та SAN)?

Що з IPMI ? Ви можете налаштувати більшість, якщо не все, за допомогою ipmitool , врятувавши вас від отримання доступу до консолі (фізичного, послідовного переходу через Інтернет, віддаленого KVM і будь-якого іншого), щоб його можна було автоматизувати з маріонеткою. Але повторна перевірка його стану під час кожного запуску лялькового агента для мене не звучить круто, і базові світильники доступу до системи - це те, що я хотів би мати, перш ніж робити щось інше.

Ще одна ціла історія - про встановлення оновлень. Я не берусь у цьому конкретному питанні, є вже багато запитань щодо СФ та багато різних філософій між різними систематиками. Сам я вирішив не дозволяти ляльковому оновлювати речі (наприклад, лише ensure => installed) і робити оновлення вручну, як ми звикли, залишаючи автоматизацію цього завдання пізніше, коли ми з маріонетками впевненіші (наприклад, додавши MCollective в суміш).

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

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

Конкретні приклади (посилаються на запитання, усі розповіді "Ось чому ви хочете керувати нею"):

Конфігурація мережі IP

Добре, звичайно, ви налаштували адресу / шлюз / NS на апараті перед тим, як впустити його в стійку. Я маю на увазі, якби не ти, як би ти запустив маріонетку, щоб виконати решту конфігурації?

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

Або скажіть, що ваша компанія придбається , і ваша нова материнська компанія вимагає, щоб ви змінилися з вашого 192.168.0.0/24 на 10.11.12.0/24, щоб вони входили в їх систему нумерації.

Або ви раптом отримуєте величезний урядовий контракт - тільки уловлюєте, ви повинні підняти IPv6 ПРАВО ФРАКІНСЬКОГО, або угода підірвана ....

Схоже, мережева конфігурація - це те, чим ми хотіли б керувати ...

Конфігурація IPMI

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

... До того гіпотетичного придбання, про яке я згадував у Конфігурації IP вище, - причина, з якої ви змушені були звільнити ці 192.168-нетто адреси, полягає в тому, що це IPMI-земля згідно з вашими новими корпоративними супервердерами, і вам потрібно продовжити оновлення всіх своїх IPMI-карт. ЗАРАЗ, тому що вони будуть топтати чужий зарезервований простір IP.

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

Оновлення

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

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

Не винаходити колесо.

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

Я говорю з гіркого досвіду. Хоча ldap поки не є таким варіантом.

Ще один приклад - це витіснення файлів хостів, а не просто використання DNS.

• Лялька - це не система оркестрації. Зокрема:
  • Лялька не дуже підходить для оркестрування ВМ, оскільки у ВМ є власний життєвий цикл, якого слід дотримуватися.
  • Лялька не дуже підходить для управління випуском програм / складних оновлень. Для цього можна використати автономні лялькові твори, але, принаймні, це не Маріонетка під контролем, натомість це ваші сценарії обгортки або людський робот, що добре.
• Лялька не є хорошою системою управління користувачем (вона повинна керувати кожним записом користувача, навіть видаленим, щоб бути ефективним. Тому знайдіть інше рішення)
• Лялька не є гарною базою даних конфігурації (дивіться на використання зовнішньої бази даних якогось типу, а також ENC, Hiera чи якийсь подібний клей)

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

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

Я здебільшого погоджуюся з voretaq7, але з парою застережень.

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

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

У моєму випадку у мене є сценарій завантаження, який завантажує мінімальний конфігурацію системи (Ubuntu): Ruby, Rubygems, build-basic, git і т. Д. Мої маніфестні ляльки знаходяться під контролем версій, і я просто клоную сховище. Звідси мій сценарій завантаження робить припущення, яке hostname --shortє дійсним, і намагається зробити це puppet apply /root/infrastructure/puppet/hosts/$( hostname --short ).pp.

Щоб відповісти на ваше запитання:

• Мої сценарії передбачають базове підключення до мережі (DNS, IP) і не керують і не змінюють його;
• Мої сценарії припускають, що особа машини є правильною, і не змінюйте її;
• Мої сценарії припустимо , рубін / Rubygems / Git присутній, але зробити це вдалося згодом.

Подумайте, що вам не потрібно використовувати маріонетку для налаштування мережі. Це колись налаштована річ, як правило. Також ви можете отримати щось лайно, якщо у вас виникнуть помилки (-ла) з IP або MAC або щось подібне, що принесе лялечка.