Що таке Helm і як він спрощує розгортання?
Автор: Редакція Domeny.ForSale Опубліковано
Коротко: Helm — це менеджер пакетів для Kubernetes, тобто інструмент, який спрощує встановлення, налаштування й оновлення застосунків у кластері. Замість того щоб окремо керувати багатьма файлами з описом застосунку, ви використовуєте пакет, який називається чартом, і передаєте йому власні налаштування. Helm також допомагає відстежувати послідовні розгортання, але не замінює Kubernetes і не гарантує безпечного оновлення.
Яку проблему розв’язує Helm?
Kubernetes — це система для запуску застосунків у контейнерах і керування ними. Кластер, тобто середовище з машин під керуванням Kubernetes, потребує опису того, що саме він має запустити. Такий опис найчастіше зберігають у маніфестах — файлах YAML, які визначають ресурси. Наприклад, Deployment керує екземплярами застосунку, а Service забезпечує підключення до них.
Один застосунок може потребувати кількох або понад десяти таких ресурсів. Якщо ви запускаєте його окремо в тестовому й виробничому середовищах, частина налаштувань буде спільною, а частина відрізнятиметься: кількість екземплярів, доменна адреса, версія образу контейнера чи обмеження пам’яті. Копіювання маніфестів вручну ускладнює підтримання їхньої узгодженості.
Helm дає змогу об’єднати шаблони цих ресурсів в один пакет. На основі шаблонів і конфігурації він генерує маніфести, а потім передає їх до Kubernetes. Ідея подібна до менеджера пакетів в операційній системі, проте Helm керує ресурсами кластера, а не програмами, встановленими на ноутбуці.
Chart, release і values — три основні поняття
Chart — це пакет Helm, який містить шаблони ресурсів Kubernetes, типові налаштування та відомості про пакет. Він може описувати окремий застосунок або набір пов’язаних компонентів. Чарт також може мати залежності, тобто використовувати інші чарти.
Release — це конкретна інсталяція чарту в кластері, яка має власну назву. Один і той самий чарт можна встановити кілька разів, наприклад як mahazyn-test і mahazyn-prod, з різними налаштуваннями. Отже, release означає не просто версію застосунку, а ідентифікує розгортання, яким керує Helm.
Values — це значення конфігурації, які підставляються в шаблони. Чарт зазвичай містить типовий файл values.yaml, а користувач може передати додатковий файл із власними налаштуваннями. Назви доступних параметрів залежать від конкретного чарту; Helm не встановлює універсального поля для налаштування будь-якого застосунку.
Приклад структури простого чарту:
mii-zastosunok/
├── Chart.yaml
├── values.yaml
└── templates/
├── deployment.yaml
└── service.yaml
Файл Chart.yaml описує пакет, values.yaml містить типову конфігурацію, а каталог templates зберігає шаблони. Версія чарту й версія застосунку — різні речі: зміна способу розгортання не обов’язково означає зміну самої програми.
Як відбувається розгортання за допомогою Helm?
Припустімо, команда підтримує застосунок магазину. У тестовому середовищі потрібен один його екземпляр, а у виробничому — три. Команда може використати один чарт і два файли конфігурації замість створення двох незалежних копій маніфестів.
Якщо чарт підтримує параметр replicaCount, файл values-test.yaml може містити:
replicaCount: 1
У наведеному нижче прикладі передбачається, що у вас встановлено Helm, є доступ до кластера та локальний чарт у каталозі mii-zastosunok. Спочатку можна згенерувати маніфести без встановлення застосунку:
helm template mahazyn-test ./mii-zastosunok -f values-test.yaml
Це дає змогу перевірити результат обробки шаблонів, але ще не підтверджує, що кластер прийме всі ресурси або що застосунок працюватиме. Встановити чи оновити release можна командою:
helm upgrade --install mahazyn-test ./mii-zastosunok \
-f values-test.yaml --namespace test --create-namespace
Namespace — це логічно відокремлений простір для ресурсів у кластері. Параметр --install дозволяє виконати встановлення, якщо release ще не існує; інакше команда оновлює його. Перед запуском перевірте поточний контекст Kubernetes, щоб випадково не розгорнути застосунок у виробничому середовищі.
Оновлення та обмеження відкату змін
Helm зберігає історію послідовних ревізій release, тобто змін його розгортання. Команда helm history mahazyn-test -n test показує цю історію, а helm rollback дає змогу повернутися до попередньої ревізії.
Відкат не є резервною копією застосунку чи його даних. Повернення до попередньої конфігурації ресурсів не скасує автоматично міграцію бази даних, зміни в зовнішньому сервісі чи наслідки роботи програми. Для оновлення застосунків, які зберігають дані, потрібен окремий план резервного копіювання та забезпечення сумісності версій.
Helm також не усуває потреби розуміти Kubernetes. Неправильні обмеження ресурсів, брак потрібних прав доступу чи некоректний образ контейнера можуть завадити запуску застосунку незалежно від того, чи маніфести створено вручну, чи згенеровано з чарту.
Коли обрати Helm і як оцінити готовий чарт?
Helm корисний, коли ви повторюєте розгортання, підтримуєте кілька середовищ або встановлюєте застосунок, що складається з багатьох ресурсів. Якщо ж у вас лише кілька простих маніфестів, які рідко змінюються, він може додати зайвий шар шаблонів. Альтернативою іноді є Kustomize: цей інструмент адаптує наявні маніфести, а не використовує шаблони Helm.
Перед використанням готового чарту перевірте його походження, документацію, потрібні версії Kubernetes, права доступу та спосіб роботи з даними, які мають зберігатися постійно. Перегляньте згенеровані маніфести, особливо ресурси, що надають права доступу, і сервіси, які роблять застосунок доступним поза кластером. Паролі, записані у файл values, не стають безпечними лише тому, що ви використовуєте Helm — не зберігайте їх у звичайному репозиторії коду.
Для початку оберіть тестове середовище й один чарт. У документації до його конкретної версії перевірте доступні параметри, а потім протестуйте встановлення, оновлення й те, що відбувається з даними під час відкату змін.
Дивіться також: Що таке Brave?
Читайте також
