10 актуальних технологій для DevOps

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт усім! Мене звати Антон Кириленко, я DevOps-інженер з майже 10-річним досвідом роботи в ІТ-продуктах. Вісім з них я працюю в компанії Quarks та розвиваю продукт у сфері Social Discovery. Ми намагаємося використовувати найкращі практики DevOps, спираючись на інструменти, розроблені в межах Cloud Native Computing Foundation.

У цій статті розповім про 10 інструментів, які допомагають нам підтримувати нашу мікросервісну платформу. До кожного з них ми прийшли з часом, порівнюючи ефективність технології з альтернативами.

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

1. Вебсервіси Amazon

Що це таке? Один з найпопулярніших хмарних хостингів з великим вибором інфраструктурних та платформних послуг, як-от набір глобальних обчислень, баз даних з простою конфігурацією та резервацією, storage-сервiсами та балансувальниками.

Для яких завдань? Хмарні технології дозволяють легко масштабувати інфраструктуру та зменшувати витрати на неї. В Amazon можна швидко підняти та масштабувати проєкт, використовуючи вже налаштовані рішення.

Як ми його використовуємо? Насправді AWS — це не ключовий елемент нашої інфраструктури. У нас вона гібридна: частково Amazon, є OpenStack, але здебільшого це self-hosted інфраструктура, розташована в декількох дата-центрах. Чому ми обрали такий варіант? Бо вже маємо експертність у технологіях, можемо контролювати свої ресурси, а ще це краще для нас в плані бюджету. На Amazon ми використовуємо частину сервісів, таких як S3-сховище, а також робимо деякі обчислення, де за короткий проміжок часу можемо отримати бажану конфігурацію інстансу та видалити її після обчислень. Це зручно.

2. Kubernetes

Що це таке? Програмна платформа для автоматичного керування контейнерами, або оркестратор. Пропонує базові механізми для розгортання, масштабування та підтримки контейнерів. Система має відкритий вихідний код, велику підтримку з боку IT-спільноти й екосистему, що швидко зростає.

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

Як ми його використовуємо? До Kubernetes ми випробували кілька рішень: спочатку був Docker Compose, потім був Docker Swarm, після цього вибір був серед Nomad та Kubernetes. У останнього була найбільша підтримка, тому ми й вибрали цю систему оркестрації. Серед інших завдань, які вирішує Kubernetes:

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

Раніше наш продукт був монолітом, написаним на PHP. Управляти всім проєктом в одному репозиторії було складно та громіздко. Один невдалий реліз міг зробити downtime всього продукту. Варіанти повернути зміни назад ставали складнішими та блокували нам розробку нового функціоналу. Постало питання переходу на мікросервісну архітектуру.

Kubernetes оперує контейнерами, тож ми переписали все на Golang і розклали по контейнерах. За допомогою Kuberentes ми маємо змогу підіймати безлімітну кількість оточень для розробників на кожну задачу. Сьогодні у нас понад 150 мікросервісів. Вони не залежать один від одного та відповідають за конкретний напрям — це може бути сервіс листування, фотообробки тощо.

3. Linkerd

Що це таке? Прошарок інфраструктури, який забезпечує зв’язок між сервісами, автоматично шифрує з’єднання, обробляє повторні запити й тайм-аути, виконує балансування навантаження з урахуванням затримок, виявлення сервісів, повторних спроб і дедлайнів.

Для яких завдань? Це додаткова технологія, яка дає змогу знаходити сервіси на кластері, трекати показники відповіді будь-якого запиту, робити retry-логіки (якщо є помилки) та керувати ними, а ще — максимально деталізувати все, що відбувається в міжсервісному спілкуванні на кластері Kubernetes.

Як ми його використовуємо? Коли сервісів стає багато, зрозуміти, який з них працює повільно, дуже складно. Раніше ми для цього використовували інструменти на рівні коду мікросервісу. А у Linkerd це є «з коробки», до того ж він має зручний дашборд з метриками. Можна побачити, скільки запитів, зробили сервіси одне до одного, їхню швидкість тощо.

Інструмент дає змогу будувати дерево взаємодії всіх сервісів, бачити ті, що деградують за продуктивністю. Наприклад, можна зайти на борду та подивитися, що success-rate між сервісом А та B вже 97 %, а не 100.

Так, завдяки Linkerd ми бачимо й інші вузькі місця у своїй системі — що потрібно покращувати, масштабувати, бачимо Latency, квантилі респонсу. Тому це один з крутих інструментів, який допоможе покращити SLO ваших сервісів.

4. Prometheus

Що це таке? Стандарт моніторингу інфраструктури з відкритим кодом, який себе добре зарекомендував. Prometheus інтегрований з багатьма сервісами та має налаштовувані модулі. Він збирає метрики з експортерів та зберігає їх як дані числових рядів з міткою часу. Порівнюючи зі старшими технологіями, інструмент може зберігати набагато більшу кількість метрик та швидко їх опрацьовувати.

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

Сутності, які одержують наявні метрики від сторонньої системи, називаються експортерами. Їх дуже багато. Усі розробники намагаються або включити свій експортер у сервіс, або викотити його окремо. Потім Prometheus ходить по експортерах та збирає метрики.

Також інструмент має дуже багато інтеграцій з системами сповіщень. Є навіть свій алерт-менеджер, який поєднується із зовнішніми сервісами. Зв’язка досить гнучка для управління нотифікаціями команд в різні канали сповіщення. Все працює дуже швидко, легко масштабується.

Як ми його використовуємо? Якось ми зрозуміли, що інстансів Prometheus у нас уже чимало. Вони досить об’ємні, бо збирають великий скоп метрик. Коли виникла потреба зберігати дані для аналізу рік-два, ми обрали хмарне сховище. Тоді знадобився й агрегатор. Зупинилися на Thanos, який створили ті ж розробники, що й Prometheus. Тестували також альтернативу Viktoria Metrics, але врешті-решт зупинилися на інструментах одного виробника. Так ми можемо бути впевнені, що вони є й залишаться сумісними.

Thanos дає змогу збирати й компактити дані з Prometheus Sidecar, заливати їх у хмарний сторедж та зберігати там роками. Втім, не обов’язково забирати всі історичні дані з хмарного сховища. Частину, наприклад, інформацію за останні 24 години, можна забрати з Prometheus Sidecar сховища, їх може бути декілька. Інформацію можна будь-коли дістати, розпакувати або ж агрегувати з безлічі Prometheus за допомогою дедуплікації. Ми намагаємося зберігати сирий формат даних — так можемо побачити інформацію з метрик двомісячної давнини з точністю до секунди. Багато хто про це не знає, й зберігає дані лише n-днів, доки є місце на диску сервера. Але якщо у вас highload, то важливо все відстежувати, знаходити причини змін, що сталися давно та могли вплинути на якісь показники.

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

Також він дає змогу збирати свої типи ресурсів, які називаються Prometheus Rule. Це файл, де можуть бути описані умови щодо тригера сповіщення. Розробник кладе його у свій Helm-чарт в репозиторії та пише кастомізоване сповіщення для свого сервісу. Наприклад, кількість «400-их» помилок за хвилину може бути 1 %, а для інших сервісів — 0,1 % за замовчуванням. Оператор ходить по всім неймспейсам Kubernetes та шукає ресурс, який має тип Prometheus Rule. Він знаходить їх, склеює та робить єдиний файл-конфігу з усіх алертів, а потім його застосовує.

5. Helm

Що це таке? Засіб упаковки застосунку з відкритим вихідним кодом, який допомагає встановлювати програми або чарти (в термінології Helm) Kubernetes і керувати їхнім життєвим циклом.

Для яких завдань? Helm спрощує встановлення, оновлення, менеджмент залежностей та налаштування розгортань у Kubernetes за допомогою простих CLI-команд.

У кожному репозиторії сервісу лежить папка з чартом, де є інформація, як сервіс має виглядати на Kubernetes. Людина описує кілька станів середовищ — як має бути на продакшені, на stage й на своєму локальному комп’ютері. Залежно від цих файлів зі змінними, ми передаємо їх в Helm і розгортаємо той самий реліз на різні оточення — stage, продакшн, девелопмент — але з різними значеннями. Це така гнучка шаблонізація.

Як ми його використовуємо? Helm у нас уже давно. Починали ми ще з yaml-файлів, а їхній облік вів лише Kubernetes. Хто використовував цей підхід знає, тут є підводні камені. Helm дає змогу запакувати цілісний реліз — тобто створити набір цих файлів, підставити кастомну інформацію, змінні, заповнити дані для конкретного середовища. У нас накат і відкат автоматичні, вони пов’язані з Kubernetes і CI/CD. Helm сильно спрощує нам життя.

До речі, Helm має Starter-чарти. Це означає, що він ними управляє, але розробник може зробити свої під певні види та мови сервісів. Якщо написати «Helm New Starter Chart Python», у людини з’явиться шаблон-заготовка, а Helm поверне нашу пакетовану заготовку для Python-сервісу. Як наслідок, замість копіювання коду з помилками з іншого репозиторію варто скористатися репозиторієм вашого Starter-чарту, й одержати цей шаблон. Його потрібно заповнити, підставити кілька значень, залити код — і у вас у репозиторії є готовий до продакшену сервіс.

6. Jenkins

Що це таке? Найпопулярніша в DevOps система для безперервної інтеграції та доставки. Надає безліч плагінів для створення, підтримки, розгортання, автоматизації проєктів, а також для реалізації конвеєрів.

Для яких завдань? Jenkins зазвичай використовується для автоматизації збірки, включаючи компіляцію вихідного коду, тести й пакування програми. Він інтегрується з системами управління джерелами на кшталт Git, і запускає збірки кожного разу, коли зміни надсилаються до сховища. Крім того, Jenkins можна налаштувати для автоматизації розгортання та запуску тестів. Наприкінці інструмент надає докладні звіти про збірку і тестування.

Як ми його використовуємо? Це open-source інструмент, тому його зручно налаштувати під себе. Ми використовуємо власну pipeline-бібліотеку, яку розширюємо та уніфікуємо. Фідбеки щодо статусу збірки приходять просто у Slack, з усіма комітами. Наприклад, сповіщення про початок, закінчення чи проблеми, якщо такі сталися. Коли збірка завершилася, в гілці цієї задачі в Jira з’являється коментар від бота та лінк, за яким треба перейти для тестування свого середовища (якщо таке очікувалося).

Якщо нам потрібна певна перевірка для CI/CD, ми можемо самі все написати, піти на API нашого сервісу, щось перевірити. Наприклад, чи закінчилася перевірка сканування іміджу на вразливості; якщо так — продовжуємо його, якщо ні — чекаємо. З нашого боку все гнучке та кастомізоване. Можемо писати свої pipeline для різних мов програмування, виносячи в репозиторій сервісу лише одну функцію — наприклад, buildGo чи buildPython в Jenkins-файлі. Водночас під час використання запуститься цілий ланцюжок з безмежної кількості лінтерів, збірки іміджу, багаторівневого тестування коду та релізу у відповідне середовище.

7. Vault

Що це таке? Застосунок для централізованого зберігання секретів: паролів, логінів, сертифікатів і токенів.

Для яких завдань? З його допомогою можна покращити безпеку програмного коду, прибравши з нього секретні дані й перемістивши їх у Hashicorp Vault. Так, ми колись зберігали всі паролі та доступи в репозиторіях. І навіть якщо співробітник звільнявся, він зберігав можливість отримати ці чутливі дані. Зберігати так паролі та інші секрети — не дуже хороша практика, й тепер ми вирішуємо це за допомогою Vault. За всім, навіть найменшою викаткою девопс-інфраструктури, ми йдемо до нього.

Як ми його використовуємо? У Vault тепер є вся секретна інформація, навіть SSL-сертифікати. Інструмент дає змогу інтегруватися з багатьма сервісами — з тим же Amazon, Kubernetes, Azure, Google Cloud, базами даних, RabbitMQ. Як це працює? Застосунок розгортається на Kubernetes за допомогою Jenkins. У момент створення контейнера він проходить через інжектор в наш Vault, і той забирає секретну інформацію, яка потрібна для цього сервісу. Це можуть бути логіни та паролі до баз даних або інші файли, які потім беруться зі змінних середовища.

Vault — окреме сховище зі своєю базою даних. Воно стійке, репліковане, не може впасти або зникнути. Зламати його вийде лиш з ключами, які розділені між адміністраторами.

8. Harbor

Що це таке? Безкоштовний реєстр для зберігання Docker-іміджів з відкритим вихідним кодом. Він надає доступ до образів за допомогою політик та вміє сканувати образи на уразливості. Також підходить для зберігання Helm-чартів.

Для яких завдань? Технологія надає централізоване сховище для зберігання та розповсюдження Docker-образів. Це полегшує управління та обмін ними між командами та середовищами. Крім того, тут є сканер, що виявляє вразливості в образах Harbor та інтегрується з конвеєрами CI/CD, що дозволяє автоматизувати створення, тестування та розгортання образів.

Як ми його використовуємо? Harbor інтегрований з хмарним сховищем, де зберігаються наші образи. Воно розбите на команди, й кожна має робот-аккаунт доступу тільки до своєї частини. Також є вебінтерфейс, де людина може подивитися, який образ зібрався після змін в коді. Імідж потрапляє саме в Harbor registry, а потім Kubernetes приходить, забирає його й на цій основі запускає сервіс.

Оскільки Harbor вміє сканувати образи на вразливості, ми знаємо всі слабкі місця всіх наших продуктів та сервісів. Коли поріг перевищує warning чи critical, можемо заборонити Jenkins розгортати образ на кластер. Утім, якщо немає альтернативного вибору, а пакет не дуже важливий, ми можемо це пропустити. Harbor дає вичерпну інформацію про вразливість — назва, опис, пакет, де з’явилася, де можна її усунути, а де поки ні. Наразі ми маємо декілька реалізацій сканерів, які ми можемо використовувати разом з Harbor.

Також ми використовуємо реплікацію — Harbor дозволяє реплікувати наше сховище в інший регіон OpenStack Swift. Якщо з одним регіоном щось станеться, зможемо переключитися на інший.

9. Terraform

Що це таке? Система оркестрації та один з ключових інструментів DevOps, що полегшує управління інфраструктурою. Terraform допомагає автоматизувати все, що можна.

Для яких завдань? Інструмент здатний керувати наявними постачальниками хмарних послуг, а також індивідуальними власними рішеннями. Terraform вміє працювати з різними API: розробник може описати стан, який потрібно отримати, Terraform піде на це API, перевірить, чи там є таке. Якщо ні — він запропонує створити чи видалити ресурси, котрі будуть в різниці станів.

Як ми його використовуємо? У нас він використовується для інфраструктури, частково для управління Kubernetes — накату серверів, підготовчих дій тощо. Сам кластер Kubernetes ми насправді розгортаємо за допомогою Ansible (форк KubeSpray). Ми керуємо через Terraform налаштуваннями неймспейсів Kubernetes та Hashicorp Vault.

У Terraform можна описати безліч ресурсів, зробити модулі, й однією командою застосовувати конфігурацію на сотні серверів та сервісів. Загалом, Terraform за останні п’ять років дуже добре прокачався й заміни для нього майже немає (завчасно прошу пробачення у прихильників Pulumi).

10. GateKeeper

Що це таке? Контролер політик для Kubernetes..

Для яких завдань? За допомогою цього інструмента ви можете створювати свої правила перевірок для ресурсів Kubernetes перед їх застосуванням, використовуючи дуже гнучку мову політик — Rego. Правила можуть бути дуже складними й базуватися на станах інших ресурсів кластера.

Як ми його використовуємо? Ми впровадили GateKeeper декілька років тому, але розвиваємо й досі. Він дає змогу стежити за змінами будь-якого ресурсу кластера та робити дії на основі встановлених політик. Наприклад, у нас GateKeeper не дозволяє зробити реліз Job Kubernetes, якщо розробник не прописав у полі TTL час на видалення незалежно від статусу виповнення. Також не вийде зробити реліз Ingress домена, який не дозволений в білому списку. На Jenkins водночас надходить повідомлення, що розробник щось пропустив чи не врахував. Людина отримує повідомлення в Slack — і йде допрацьовувати.

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

Якщо у вас залишилися запитання щодо тих інструментів, які я перелічив або інших аспектів роботи DevOps — я з радістю відповім на них у коментарях.