Англійська для керування налаштуваннями Puppet

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

Ключовий словник

** Manifest ** — файл Puppet, написаний декларативною мовою, який описує бажаний стан ресурсів на вузлі, наприклад, які пакунки слід встановити або які служби слід запустити.

• “Я додав новий пакунок до манифеста, але він не вступить у дію на серверах до наступного запланованого запуску Puppet.” *

** Ресурс ** — основна одиниця, якою керує Puppet, вона представляє один об’ єкт стану системи, наприклад, файл, пакунок, службу або користувача, кожен з яких оголошено за типом і бажаним станом. “Цей манифест оголошує службу nginx як ресурс, який завжди повинен бути запущеним і ввімкненим під час завантаження, тому Puppet перезавантажить його, якщо він коли-небудь зупиниться.”

** Каталог ** — зібраний, специфічний для вузла набір ресурсів і їх бажаних станів, які Puppet створює з манифестів і застосовує під час виконання.

• « Спроба компіляції каталогу зазнала невдачі через помилку синтаксису у спільному модулі, отже цей вузол навіть не намагався застосувати його налаштування. » *

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

** Запуск марионетки (запуск каталогу) ** — періодичний процес, під час якого вузол агента отримує свій зібраний каталог з сервера Puppet і застосовує всі ресурси, які не синхронізовані з потрібним станом.

• “Це відхилення налаштувань буде виправлено автоматично під час наступного запуску Puppet, зазвичай, протягом тридцяти хвилин, якщо хтось не зробить цього вручну.” *

Звичайні фрази

• Чи дійсно ця зміна манифесту вже досягла сервера, або ж вона чекає наступного запуску?»
• «Який ресурс не збирається зливати — це пакунок, служба або файл?»
• Чи взагалі каталог компілявався для цього вузла, чи він зазнав невдачі перед застосуванням чого-небудь?»
• Чи є ця операція ідемпотентною, або повторне виконання може викликати проблему?»
• «Давайте змусимо Puppet запуститися замість того, щоб чекати запланованого інтервалу.»

Приклади висловлювань

Дрейф налаштування зневадження:

• “Цей сервер було змінено вручну поза Puppet, отже, наступне запуск каталогу поверне зміни до того, що було оголошено у манифесті — це очікувано, а не вада.” *

Пояснення затримки розгортання:

• “Зміни у манифесті об’ єднано, але вони не будуть застосовані до наступного запуску Puppet на кожному вузлі, отже, очікуйте, що вони будуть поступово впроваджені протягом наступних тридцяти хвилин.” *

Перегляд нового манифесту: “Переконайтеся, що це оголошення ресурсу є ідемпотентним — якщо воно просто додаватиметься до файла кожного разу, коли програма виконуватиметься, замість того, щоб забезпечувати певний стан, ми отримаємо дублікати записів з часом.”

Професійні поради

• Використовуйте ** manifest ** для файла джерела і ** catalog ** для збірки, результату на вузол — об’ єднання цих двох файлів ускладнює визначення того, чи проблема полягає у коді, чи у тому, як він застосовується до певного сервера.
• Підтверджує, чи зміна дійсно пройшла через ** Puppet run ** перед тим, як припустити, що виправлення зазнало невдачі — більшість звітів « це все ще не працює » насправді є « це ще не збіглося »
• Вказувати, коли запропонована декларація resource не є idempotent під час перегляду — неідемпотентні ресурси є найпоширенішим джерелом серверів, керованих Puppet, які повільно виходять з передбачуваного стану.
• Якщо ви бажаєте негайно запустити програму каталогу, скористайтеся командою « примусити запуск », а не « перезапустити Puppet » — це буде точним способом виконання дії і уникнення плутанини з перезапуском самої служби Puppet.

Практичні вправи

1. Поясніть одним реченням різницю між манифестом і каталогом.
2. Описати, чому ідемпотентність має значення для ресурсу, який додає рядок до файла налаштувань.
3. Напишіть два речення, у яких ви поясните співробітнику команди, чому зміна, яку він вніс вручну на сервері, була скасована автоматично.

Наприклад: спільне використання навігаційних систем

Багато не-англомовних носіїв знаходять точну мову, використовувану в DevOps і управлінні конфігурацією - особливо з такими інструментами, як Puppet - неймовірно складним. Це не просто про розуміння * технічних * термінів; це про оволодіння тим, як ці терміни зазвичай виражаються в професійному, спільному середовищі. Здається простим запит на пояснення може швидко стати заплутаним, якщо погано сформулювати. Наприклад, отримання коментаря в перегляді коду, на кшталт «Це потрібно виправити» є неймовірно нечітким. Вона не каже тобі, що потрібно виправити або чому. Більш конструктивним підходом було б: «Чи не могли б ви, будь ласка, розібратися в проблемі з цим ресурсом? Зокрема, я бачу [описати конкретне спостереження] і я хвилююся про [пояснити потенційні наслідки]. Чи можемо ми обговорити, як забезпечити послідовне застосування цього параметра на всіх серверах?»

Інша поширена область для нерозуміння - це питання звітів. Повідомлення Slack на кшталт « Спроба виконання ляльки зазнала невдачі » також не допоможе. Розробник може відповісти запитанням « Чи можете ви надати повний вивід помилок з запуску каталогу Puppet? Это поможет нам диагностировать коренные причины. Знання puppet apply часу і будь- яких відповідних ідентифікаторів вузлів також буде корисним. » Ключовим у цьому випадку є перенесення фокусу з простого оновлення стану на * інформацію, яку можна використовувати *. Пам’ятайте, що в умовах співпраці, детальна комунікація мінімізує неоднозначність і прискорює вирішення проблем. Це проактивне пошуки ясності, а не пасивне прийняття нечітких повідомлень. Не бійтеся ставити питання - це набагато краще, щоб прояснити припущення, ніж продовжувати на основі неповних або неправильно інтерпретовані дані.

Крім того, формулювання, пов’язані зі змінами і оновленнями, вимагають ретельної уваги. Сказати щось на зразок “Я оновив манифест” недостатньо. Професійнішим підходом буде: «Я змінив ресурс webserver у файлі /etc/puppetlabs/site.yaml, щоб збільшити виділення пам’яті до 4 ГБ. Ця зміна вирішує проблему з різким зменшенням продуктивності, що спостерігалося під час тестування під час максимального навантаження. Я додав коментарі до манифеста, де пояснюю причину цього зміни, і міг мітки для перегляду. » Цей рівень деталізації демонструє відповідальність, надає контекст і дозволяє іншим зрозуміти, * чому * було внесено зміну.

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

# Example Puppet Manifest Snippet (for demonstration only)
node 'webserver01' {
  package { 'nginx':
    ensure => latest,
    install_options => [ '--force', '--no-recheck' ],
  }
}