Справа наближалася до Нового року. Діти всієї країни вже надіслали листи Діду Морозу або загадали собі подарунки, а головний їхній виконавець — один із великих рітейлерів — готувався до апофеозу продажу. У грудні навантаження на його ЦОД зростає у кілька разів. Тому компанія вирішила модернізувати дата-центр та ввести в дію кілька десятків нових серверів замість обладнання, термін служби якого завершувався. На цьому приказка на тлі сніжинок, що кружляють, закінчується, і починається трилер.
Обладнання прийшло на майданчик за кілька місяців до піку продажу. Служба експлуатації, зрозуміло, знає, як і що налаштовувати на серверах, щоб ввести в production-окружение. Але нам потрібно було автоматизувати це та виключити людський фактор. До того ж, сервери замінювали перед міграцією набору систем SAP, критично важливих для компанії.
Введення в дію нових серверів було жорстко прив'язане до дедлайн. І зрушити його означало поставити під загрозу і відвантаження мільярда подарунків та міграцію систем. Змінити дату не могла б навіть команда у складі Діда Мороза, Санта Клауса — переносити систему SAP для керування складом можна лише раз на рік. З 31 грудня на 1 січня величезні склади рітейлера сумарно як 20 футбольних полів зупиняють свою роботу на 15 годин. І це єдиний проміжок часу для переїзду системи. Права на помилку із введенням серверів у нас не було.
Поясню відразу: моя розповідь відображає такий інструментарій та процес управління конфігураціями, які застосовує наша команда.
Комплекс управління конфігураціями складається з кількох рівнів. Ключовий компонент – CMS-система. При промисловій експлуатації відсутність одного з рівнів неминуче призвела б до неприємних чудес.
Управління встановленням ОС
Перший рівень - це система управління установкою операційних систем на фізичні та віртуальні сервери. Вона створює базові зміни ОС, позбавляючи людського чинника.
За допомогою цієї системи ми отримували типові та придатні для подальшої автоматизації екземпляри серверів з ОС. При "розливанні" вони отримували мінімальний набір локальних користувачів та публічних ключів SSH, а також узгоджену конфігурацію ОС. Ми могли гарантовано керувати серверами через CMS і були впевнені, що внизу, на рівні ОС, немає сюрпризів.
Завдання "максимум" для системи керування установкою - автоматично налаштовувати сервери від рівня BIOS/Firmware до ОС. Багато чого тут залежить від обладнання та завдань налаштування. Для різноманітного обладнання можна розглянути . Якщо все «залізо» від одного вендора, то найчастіше зручніше використовувати готові засоби керування (наприклад, HP ILO Amplifier, DELL OpenManage тощо).
Для встановлення ОС на фізичних серверах ми застосовували всім добре знайомий Cobbler, у якому визначено набір узгоджених із службою експлуатації профілів інсталяції. При додаванні нового сервера в інфраструктуру інженер прив'язував MAC-адресу сервера до потрібного профілю Cobbler. При першому завантаженні мережею сервер отримував тимчасову адресу і свіжу ОС. Потім його переводили до цільової VLAN/IP-адресації і продовжували роботу вже там. Так, зміна VLAN забирає час і вимагає узгодження, зате це дає додатковий захист від випадкової інсталяції сервера в production-оточенні.
Віртуальні сервери ми створювали на основі шаблонів, підготовлених за допомогою HashiCorp Packer. Причина була та сама: щоб запобігти можливим людським помилкам при установці ОС. Але, на відміну від фізичних серверів, Packer дозволяє не використовувати PXE, мережне завантаження та зміну VLAN. Це полегшило та спростило створення віртуальних серверів.
Мал. 1. Управління встановленням операційних систем.
Управління секретами
Будь-яка система управління конфігураціями містить у собі дані, які мають бути приховані від пересічних користувачів, але необхідні підготовки систем. Це паролі локальних користувачів та сервісних облікових записів, ключі сертифікатів, всілякі API Tokens та ін. Зазвичай їх називають секретами.
Якщо від початку не визначити, де і як зберігати ці секрети, то, залежно від строгості вимог ІБ, можливі такі способи зберігання:
- прямо у коді управління конфігурації або у файлах у репозиторії;
- у спеціалізованих інструментах керування конфігураціями (наприклад, Ansible Vault);
- у системах СI/CD (Jenkins/TeamCity/GitLab/і т. п.) або в системах керування конфігураціями (Ansible Tower/Ansible AWX);
- також секрети можуть передавати на "ручному управлінні". Наприклад, викладають обумовлене місце, та був їх використовують системи управління конфігураціями;
- різні комбінації вищеописаного.
Кожен метод має свої недоліки. Головний із них — відсутність політик доступу до секретів: не можна чи важко визначити, хто може використати ті чи інші секрети. Ще один мінус – відсутність аудиту доступу та повноцінного життєвого циклу. Як швидко замінити, наприклад, публічний ключ, який прописаний у коді та ряді суміжних систем?
Ми використовували централізоване сховище секретів HashiCorp Vault. Це дозволило нам:
- зберігати секрети безпечно. Вони зашифровані, і навіть якщо хтось отримає доступ до бази даних сховища Vault (наприклад, відновивши її з резервної копії), то не зможе прочитати секрети, що зберігаються там;
- організувати політики доступу до секретів. Користувачам та додаткам доступні лише «виділені» ним секрети;
- проводити аудит доступу до секретів. Будь-які дії із секретами записуються до журналу аудиту Vault;
- організувати повноцінний «життєвий цикл» роботи із секретами. Їх можна створювати, відкликати, ставити термін дії тощо.
- легко інтегруватися з іншими системами, яким потрібний доступ до секретів;
- а також використовувати наскрізне шифрування, одноразові паролі для ОС і БД, сертифікати уповноважених центрів і т.д.
Тепер перейдемо до центральної системи автентифікації та авторизації. Можна було обійтися і без неї, але адмініструвати користувачів у багатьох супутніх системах занадто нетривіально. Ми налаштували автентифікацію та авторизацію через службу LDAP. Інакше в тому ж Vault довелося б безперервно випускати та вести облік автентифікаційним токенам для користувачів. А видалення та додавання користувачів перетворилося б на квест «а чи скрізь я створив/видалив цю УЗ?»
Додаємо ще один рівень нашої системи: управління секретами та центральну аутентифікацію/авторизацію:
Мал. 2. Управління секретами.
Управління конфігураціями
Дісталися серцевини — до системи CMS. У нашому випадку це зв'язка Ansible та Red Hat Ansible AWX.
Замість Ansible може бути Chef, Puppet, SaltStack. Ми вибрали Ansible за кількома критеріями.
- По-перше, це універсальність. Набір готових модулів для керування . А якщо його не вистачає, можна пошукати на GitHub та Galaxy.
- По-друге, не потрібно ставити та підтримувати агенти на керованому устаткуванні, доводити, що вони не заважають навантаженню, та підтверджувати відсутність «закладок».
- По-третє, у Ansible низький поріг входження. Грамотний інженер напише робочий playbook буквально першого дня роботи з продуктом.
Але одного Ansible у промисловому оточенні нам було недостатньо. Інакше виникло б багато проблем з обмеженням доступу та аудитом дій адміністраторів. Як розмежувати доступ? Адже потрібно було, щоб кожен підрозділ керував (читай запускав Ansible playbook) «своїм» набором серверів. Як дозволити запуск конкретних Ansible Playbook тільки певним співробітникам? Або як простежити, хто запускав playbook, не заводячи безліч локальних УЗ на серверах та устаткуванні під керуванням Ansible?
Левову частку таких питань вирішує Red Hat , або його open-source upstream проект . Тому ми і віддали перевагу його замовнику.
І ще один штрих до портрета нашої системи CMS. Ansible playbook має зберігатися у системах управління репозиторієм коду. У нас це .
Отже, самими конфігураціями управляє зв'язка з Ansible/Ansible AWX/GitLab (див. рис. 3). Очевидно, AWX/GitLab інтегровані з єдиною системою аутентифікації, а Ansible playbook - з HashiCorp Vault. Конфігурації потрапляють у production-оточення тільки через Ansible AWX, в якому задані всі «правила гри»: хто і що може конфігурувати, звідки брати код керування конфігураціями для CMS і т.д.
Мал. 3. Управління конфігураціями.
Управління тестуванням
Наша конфігурація представлена як код. Тому ми змушені грати за тими самими правилами, що й розробники програмного забезпечення. Нам необхідно було організувати процеси розробки, безперервного тестування, доставки та застосування конфігураційного коду production-сервери.
Якщо це зробити відразу, то написані ролі зміни чи перестали б підтримувати і змінювати, або припинили запускати в production. Ліки від цього болю відомі, і вони виправдали себе в цьому проекті:
- кожна роль покрита модульними тестами;
- тести проганяються автоматично за будь-якої зміни в коді, що управляє конфігураціями;
- зміни у коді управління конфігураціями потрапляють у production-оточення лише після успішного проходження всіх тестів та code review.
Розробка коду та управління конфігураціями стали спокійнішими та передбачуваними. Для організації безперервного тестування ми використовували інструментарій GitLab CI/CD, а як фреймворк для організації тестів взяли .
При будь-якій зміні в коді керування конфігураціями GitLab CI/CD викликає Molecule:
- та перевіряє синтаксис коду,
- піднімає Docker-контейнер,
- застосовує змінений код у створений контейнер,
- перевіряє роль ідемпотентність і проганяє тести цього коду (гранулярність тут лише на рівні ansible role, див. рис. 4).
Конфігурації у production-оточення ми доставляли за допомогою Ansible AWX. Відповідальні за експлуатацію інженери застосовували зміни у конфігурації через заздалегідь визначені шаблони. AWX самостійно при кожному застосуванні "запитував" останню версію коду з майстер-гілки GitLab. Так ми виключали вживання неперевіреного чи застарілого коду у production-оточенні. Природно, код у майстер-гілку потрапляв лише після тестування, перегляду та погодження.
Мал. 4. Автоматичне тестування ролей у GitLab CI/CD.
Є ще проблема, пов'язана з експлуатацією production-систем. У реальному житті дуже важко змінювати конфігурацію лише через код CMS. Виникають позаштатні ситуації, коли інженер повинен змінювати конфігурацію «тут і зараз», не чекаючи виправлення коду, тестування, узгодження тощо.
Внаслідок ручних змін з'являються розбіжності у конфігурації на однотипному устаткуванні (наприклад, на вузлах HA-кластера різна конфігурація налаштувань sysctl). Або реальна конфігурація на устаткуванні відрізняється від тієї, яка задана в коді CMS.
Тому на додаток до безперервного тестування ми перевіряємо production-оточення на розбіжність конфігурацій. Вибрали найпростіший варіант: запуск коду конфігурації СMS у режимі "dry run", тобто без застосування змін, але з повідомленням про всі розбіжності між запланованою та реальною конфігурацією. Ми реалізували це за допомогою періодичних запусків усіх Ansible playbook з опцією «check» на production-серверах. За запуск та актуальність playbook, як завжди, відповідає Ansible AWX (див. рис. 5):
Мал. 5. Перевірки на розбіжність конфігурацій у Ansible AWX.
Після перевірок AWX надсилає звіт про розбіжності адміністраторам. Вони вивчають проблемну конфігурацію, а потім виправляють її через скориговані playbook. Так ми підтримуємо конфігурацію в production-оточенні та CMS завжди знаходиться в актуальному та синхронізованому стані. Це позбавляє неприємних «чудес», коли код CMS застосовується на «бойових» серверах.
Тепер у нас з'явився важливий рівень тестування, який складається з Ansible AWX/GitLab/Molecule (Мал. 6).
Мал. 6. Управління тестуванням.
Важко? Не сперечаюсь. Але такий комплекс управління конфігураціями став вичерпною відповіддю на безліч питань, пов'язаних із автоматизацією налаштування серверів. Тепер у рітейлера у типових серверів завжди суворо певна конфігурація. СMS, на відміну від інженера, не забуде додати необхідні налаштування, створити користувачів та виконати десятки чи сотні необхідних налаштувань.
У налаштуваннях серверів та оточень сьогодні відсутні «таємні знання». Всі необхідні особливості відображені у playbook. Більше ніякої творчості та туманних інструкцій: «став як звичайний Oracle, але там потрібно пару налаштувань sysctl прописати, і користувачів з потрібним UID додати. Запитай у хлопців із експлуатації, вони знають».
Можливість виявляти розбіжність конфігурацій і заздалегідь їх виправляти надає спокою. Без системи керування конфігураціями це зазвичай виглядає інакше. Проблеми накопичуються доти, доки одного разу не «вистрілюють» у production. Потім проводиться розбір польотів, перевіряють та виправляють конфігурації. І цикл повторюється знову
І, звичайно, ми прискорили запуск серверів в експлуатацію з декількох днів до годин.
Ну а самої новорічної ночі, коли діти радісно розвертали подарунки і дорослі загадували бажання під бій курантів, наші інженери мігрували SAP-систему на нові сервери. Навіть Дід Мороз скаже, що найкращі дива – добре підготовлені.
PS Наша команда часто стикається з тим, що замовники хочуть якнайпростіше вирішити завдання управління конфігураціями. В ідеалі, щоб як за помахом чарівної палички — одним інструментом. Але в житті все складніше (так, знову не завезли срібні кулі): доводиться створювати процес за допомогою зручних для команди замовника інструментів.
Автор: Сергій Артемов, архітектор відділу «Інфосистеми Джет»
Джерело: habr.com