Національна інформаційна служба супутникових даних про довкілля (NESDIS) на 35% знизила свої витрати на керування конфігурацією Red Hat Enterprise Linux (RHEL), перейшовши з Puppet Enterprise на Ansible Tower. У цьому відео категорії «як ми це зробили» системний інженер Майкл Рау доводить виконання цієї міграції, ділиться корисними порадами та досвідом, отриманим в результаті переходу з однієї SCM на іншу.
З цього відео ви дізнаєтесь:
- як довести керівництву доцільність переходу з Puppet Enterprise на Ansible Tower;
- які стратегії використовуватиме максимально плавного переходу;
- поради щодо транскодування PE маніфестів у Ansible Playbook;
- рекомендації щодо оптимальної установки Ansible Tower.
Вітаю всіх, мене звуть Майкл Рау, я старший системний інженер компанії ActioNet, яка працює на Національне управління океанічних та атмосферних досліджень (NOAA) служби NESDIS. Сьогодні ми поговоримо про обрізання рядків – мій досвід міграції з Puppet Enterprise на Ansible Tower. Тема цієї презентації полягає в тому, щоб "подивитися на мої шрами", що залишилися після того, як я зробив цей перехід на початку року. Я хочу розповісти, що дізнався під час цього процесу. Так що коли ви візьметеся за подібне, використовуючи мій досвід, то зможете зробити перехід без зайвої праці.
Ви бачите слайди, подібні до цього, на початку кожної презентації на Ansible Fest. На цьому слайді викладено історію автоматизації моєї компанії. Я не новачок у цій справі, тому що користуюсь Puppet/Puppet Enterprise з 2007 року. Я почав працювати з Ansible з 2016 року, і мене, як багато інших користувачів цього продукту, залучила можливість «трюків» за допомогою командного рядка та прості сценарії (playbooks). Наприкінці 2017 року я звернувся до свого керівництва щодо серйозних підстав для переходу на Ansible Tower. Через хвилину я розповім про причини, які спонукали мене на цей крок. Після отримання згоди керівництва знадобилося ще кілька місяців, щоб виконати задумане, і я здійснив перехід у січні-лютому цього року. Отже, ми повністю відмовилися від Puppet на користь Ansible, і це велика справа.
Найбільше в Ansible мене приваблює можливість писати та використовувати ролі (roles) та сценарії (playbooks). Ролі відмінно підходять до створення різних, але взаємозалежних завдань (tasks) і розміщення всіх даних, які стосуються цим завданням, одному місці. Playbook - це синтаксис YAML, файл-сценарій, що описує дії для одного або кількох хостів. Я розповідаю про ці можливості користувачам, насамперед розробникам ПЗ. Ansible Tower дає можливість сказати: "ні, у вас немає доступу до оболонки shell access, але я надаю вам можливість запустити всі процеси Tower і перезавантажити сервіс, коли це потрібно". Я розповім вам про робоче середовище та обладнання, яке ми використовуємо.
Це федеральна LAN, 7 фізичних сайтів, підключених через хмарне MPLS, 140 серверів RHEL, 99% яких віртуальні (vSphere), апаратне забезпечення SuperMicro, мережеве сховище NexentaStore, набір свитків Cisco, Arista та Cumulus та засоби уніфікованого управління загрозами Fortinet UTM .
Федеральна мережа означає, що я маю використовувати всі засоби захисту інформації, передбачені законодавчими актами. Ви повинні мати на увазі, що Puppet Enterprise не підтримує більшу частину обладнання, що використовується у нас. Ми змушені використовувати бюджетне апаратне забезпечення, оскільки державні структури мають проблеми з фінансуванням цієї статті витрат. Тому ми купуємо залізо класу SuperMicro і збираємо наше обладнання з окремих частин, технічне обслуговування яких гарантоване урядовими контрактами. Ми використовуємо Linux і це одна з важливих причин переходу на Ansible.
Наша історія роботи з Puppet є такою.
У 2007 ми мали маленьку мережу з 20-25 вузлів, у якій розгорнули Puppet. В основному ці вузли були просто «коробки» RedHat. У 2010 році ми почали використовувати веб-інтерфейс Puppet Dashboard для 45 вузлів. Оскільки мережа продовжувала розширюватися, у 2014 році ми перейшли на PE 3.3, здійснивши повний перехід з переписуванням маніфесту для 75 вузлів. Це довелося зробити, тому що Puppet любить змінювати правила гри, і в цьому випадку вони повністю змінили мову. Через рік, коли припинилася підтримка 3-ї версії Puppet Enterprise, ми змушені були мігрувати на PE 2015.2. Довелося знову переписати маніфест під нові сервери та придбати ліцензію із запасом на 100 вузлів, хоча на той момент у нас було лише 85 вузлів.
Пройшло лише 2 роки, і нам знову довелося провести велику роботу з переходу на нову версію PE 2016.4. Ми купили ліцензію на 300 вузлів, маючи лише 130. Нам знову довелося вносити серйозні зміни до маніфесту, бо нова версія мови мала синтаксис, відмінний від мови версії 2015 року. У результаті наша SCM перейшла із системи контролю версій SVN на Bitbucket (Git). Такими були наші «відносини» з Puppet.
Отже, мені довелося пояснити керівництву, чому ми повинні переходити на іншу SCM, використовуючи такі аргументи. Перший – найвища вартість сервісу. Я розмовляв з хлопцями RedHat, і вони сказали, що вартість обслуговування мережі з 300 вузлів за допомогою Ansible Tower складає половину вартості Puppet Enterprise. Якщо придбати ще Ansible Engine, ціна буде приблизно однакова, але при цьому ви отримаєте набагато більше функцій, ніж у PE. Оскільки ми є державною компанією, яка фінансується з федерального бюджету, це досить вагомий аргумент.
Другий аргумент – це універсальність. Puppet підтримує лише те обладнання, на якому є агент Puppet. Це означає, що на всі свитчі потрібно встановити агент, причому він має бути останньою версією. І якщо частина ваших свитчів підтримує одну версію, а частина іншу, вам знадобиться встановити на них нову версію агента PE, щоб всі вони могли працювати в одній системі SCM.
Система Ansible Tower працює по-іншому, тому що в неї немає ніяких агентів, зате є модулі, які підтримують свитчі Cisco і всі інші свитчі. Ця SCM підтримує Qubes OS, Linux та 4.NET UTM. Ansible Tower також підтримує контролери мережевих сховищ NexentaStore, що базуються на ядрі Illumos – open-source операційній системі на основі Unix. Це дуже невелика підтримка, але Ansible Tower все одно здійснює її.
Третій аргумент, дуже важливий як для мене, так і для нашої адміністрації, – це простота в освоєнні. Я протягом 10 років освоював модулі та код маніфестів Puppet, але Ansible вивчив протягом тижня, тому що з цією SCM набагато простіше працювати. Якщо ви запускаєте виконувані файли, звичайно, якщо ви не робите цього без необхідності, то з ними працюють розумні та чуйні обробники. Сценарії playbooks, засновані на YAML, характеризується легким вивченням та швидкістю використання. Ті, хто ніколи раніше не чув про YAML, можуть просто прочитати сценарії та легко зрозуміти, як він працює.
Чесно кажучи, Puppet набагато ускладнює вашу працю як розробника, тому що ґрунтується на використанні Puppet Master. Це єдина машина, яка має право спілкуватись з агентами Puppet. Якщо ви внесли якісь зміни до маніфесту та хочете протестувати свій код, ви повинні переписати код для Puppet Master, тобто налаштувати файл Puppet-майстра /etc/hosts для підключення всіх клієнтів та запустити службу Puppet Server. Тільки після цього ви зможете спробувати роботу мережевого обладнання на одному хості. Це досить болісна процедура.
У Ansible все набагато простіше. Все, що потрібно зробити - це розробити код для машини, яка має можливість зв'язатися по протоколу SSH з хостом, що тестується. Із цим набагато простіше працювати.
Наступний великий плюс Ansible Tower – це можливість задіяти вже наявну у вас систему підтримки та зберегти існуючу конфігурацію обладнання. Ця SCM без будь-яких додаткових дій використовує всю наявну інформацію про вашу інфраструктуру та обладнання, віртуальні машини, сервери і т.д. Вона може спілкуватися з вашими RH Satellite серверами, якщо є, і надає вам таку інтеграцію, яку ви ніколи не отримаєте, працюючи з Puppet.
Ще однією важливою річчю є детальний контроль. Ви знаєте, що Puppet є модульною системою, це клієнт-серверна програма, тому ви повинні визначити існуючі аспекти роботи всіх ваших машин в одному довгому маніфесті. При цьому стан кожного окремого елемента системи потрібно тестувати кожні півгодини – це за промовчанням. Ось як працює Puppet.
Tower позбавляє вас від цього. Ви можете без обмежень виконувати різні процеси на різному устаткуванні, можете робити основну роботу, запускати інші важливі процеси, налаштовувати систему безпеки, працювати з базами даних. Ви можете робити все те, що Puppet Enterprise пов'язане з певними труднощами. Так, якщо ви провели налаштування на одному хості, потрібен час, щоб зміни набули чинності на інших хостах. У Ansible всі зміни набувають чинності одночасно.
Зрештою, розглянемо модуль безпеки. У Ansible Tower він реалізований просто приголомшливо, з великою точністю та ретельністю. Ви можете надавати користувачам доступ до конкретних служб або конкретних хостів. Я роблю так зі своїми співробітниками, які звикли працювати на Windows, обмежуючи їм доступ до оболонки Linux. Я забезпечую їм такий доступ до Tower, щоб вони могли виконувати тільки ту роботу та запускати лише ті служби, які належать до їхньої компетенції.
Давайте розглянемо речі, які потрібно зробити заздалегідь, щоб полегшити перехід на Ansible Tower. Насамперед необхідно підготувати ваше обладнання. Якщо якісь елементи вашої інфраструктури ще відсутні у базі даних, їх потрібно додати туди. Існують системи, які не змінюють своїх характеристик і тому відсутні в БД Puppet, але якщо ви не внесете їх туди перед переходом на Tower, то втратите ряд переваг. Це може бути «брудна», попередня БД, але вона повинна містити в собі відомості про все обладнання. Тому вам слід написати динамічний скрипт обладнання, який автоматично вноситиме всі зміни інфраструктури в базу даних, тоді Ansible буде знати, які хости повинні бути в новій системі. Вам не потрібно буде повідомляти цю SCM, які хости ви додали і яких хостів більше не існує, тому що все це вона дізнається автоматично. Чим більше даних буде в БД, тим кориснішим і гнучкішим буде Ansible. Він працює так, ніби просто зчитує з бази даних штрих-код стану обладнання.
Витратьте деякий час на знайомство з роботою командного рядка Ansible. Запустіть якісь спеціальні команди, щоб перевірити роботу скрипта обладнання, напишіть та запустіть якісь прості, але корисні сценарії playbook, використовуйте шаблони Jinja2 там, де це доречно. Спробуйте написати роль і сценарій для комплексного багатоетапного процесу, використовуючи стандартну конфігурацію обладнання, що часто зустрічається. Пограйте із цими речами, протестуйте, як це працює. Таким чином, ви навчитеся працювати з інструментами для створення бібліотек, що використовуються в Tower. Я вже казав, що у мене підготовка до переходу зайняла близько трьох місяців. Думаю, що спираючись на мій досвід, вам вдасться зробити це швидше. Не вважайте цей час втраченим, оскільки пізніше ви відчуєте всі переваги виконаної роботи.
Далі потрібно вирішити, чого ви чекаєте від Ansible Tower, що саме ця система повинна вам зробити.
Чи потрібне вам розгортання системи на порожньому устаткуванні, на порожніх віртуальних машинах? Чи хочете зберегти вихідні умови роботи та налаштування існуючого обладнання? Це дуже важливий аспект для роботи державних компаній, тому ви повинні бути впевнені, що вам вдасться здійснити міграцію та розгорнути Ansible на наявній конфігурації. Визначте рутинні адміністративні процеси, які бажаєте автоматизувати. З'ясуйте, чи потрібно вам розгортати на новій системі специфічні програми та послуги. Складіть список того, що ви хочете зробити, та розставте пріоритети.
Потім починайте написання коду сценаріїв та ролей, які забезпечать виконання запланованих вами завдань. Поєднайте їх у Projects, логічну колекцію відповідних сценаріїв playbooks. Кожен Project буде відноситися до окремого репозиторію Git або іншого репозиторію залежно від того, який менеджер коду ви використовуєте. Ви можете керувати сценаріями playbook і каталогами playbook, помістивши їх вручну в Project Base Path на сервері Tower, або помістивши playbook в будь-яку систему управління вихідним кодом (SCM), що підтримується Tower, включаючи Git, Subversion, Mercurial та Red Hat Insights. Усередині одного Project ви можете розмістити стільки сценаріїв, скільки захочете. Наприклад, я створив один базовий Project, де розмістив сценарій для основних елементів RedHat, сценарій для основи Linux, сценарії для інших базових показників. Таким чином, в одному проекті були найрізноманітніші ролі та сценарії, які керувалися з одного Git-репозиторію.
Запускайте всі ці штуки через командний рядок, це добрий спосіб перевірки їхньої працездатності. Таким чином ви підготуєтеся до встановлення Tower.
Давайте трохи поговоримо про транскодування маніфесту Puppet, тому що я витратив багато часу, поки не зрозумів, що дійсно необхідно зробити.
Як я вже казав, Puppet зберігає всі налаштування та параметри обладнання в одному довгому маніфесті, і в цьому маніфесті зберігається все, що має робити ця SCM. При переході вам не потрібно запихати всі ваші завдання в один список, натомість подумайте про структуру нової системи: ролі, сценарії, теги, групи і про те, що туди має увійти. Деякі з автономних елементів мережі слід об'єднати у групи, для яких можна створити сценарії. Більш складні елементи інфраструктури, які задіяють велику кількість ресурсів, у тому числі включають автономні класи, можна об'єднати в ролях. Перед міграцією вам потрібно з цим визначитись. Якщо ви створюєте об'ємні ролі або сценарії, які не містяться на одному екрані, вам слід використовувати теги, щоб мати можливість захоплювати окремі частини інфраструктури.
18:00
Небагато реклами 🙂
Дякую, що залишаєтеся з нами. Вам подобаються наші статті? Бажаєте бачити більше цікавих матеріалів? Підтримайте нас, оформивши замовлення або порекомендувавши знайомим, , унікальний аналог entry-level серверів, який був винайдений нами для Вас: (Доступні варіанти з RAID1 і RAID10, до 24 ядер і до 40GB DDR4).
Dell R730xd вдвічі дешевше в дата-центрі Equinix Tier IV в Амстердамі? Тільки в нас у Нідерландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – від $99! Читайте про те
Джерело: habr.com