Цей пост мав бути опублікованим 24-го лютого, але так і провисів у чернетках аж до сьогодні. Подальшу роботу я не проводив, бо перевіз все на fly.io.
На вихідних я вирішив поекспериментувати зі своїми проєктами та зробити прототип маленької хмарки на кубері.
Раніше я прикидував ціни на менеджед кубери й вибрав Scaleway. Мій рахунок за Heroku зараз складає $53.02. Потрібно було підняти ще один сервіс, а це значить +$16 за базу та інстанс. В таких умовах подумав що можна буде перевезти все що крутиться на хероку в кубер, зекономити грошей та отримати кращу швидкодію. Стандартні хероківські інстанси слабкі, а збільшення потужності коштує дорого. Scaleway за ті самі гроші був би краще.
Kubernetes
Кубер на коні. Google вкинув величезну кількість грошей в маркетинг, тому зараз це стандарт контейнерної оркестрації. Висока складність та поріг входу призвели до появи професії Senior Yaml Developer, які займаються виключно тим що бавлять кубер фултайм.
Є плюс — багато вендорів надають managed рішення, тобто беруть на себе всю роботу по налаштуванню, оновленню та підтримці control plane куберу. Вам залишається під'єднатися до кластера та працювати з ним, на відміну від Nomad, де все потрібно робити самотужки.
Scaleway не бере грошей за кубер. Ви платите тільки за ресурси, які використовує кластер. Щоб дізнатися, скільки пам'яті залишається на апки, я розгорнув кластер, та був приємно вражений: вся кухня+інгрес+cert-manager з'їли приблизно 22% RAM однієї 4GiB ноди, тобто для моїх задач залишалось приблизно 3.5GiB, достатньо щоб повністю мігрувати з Heroku.
План був такий як і для Nomad: Terraform для всіх ресурсів та CI/CD.
З тераформом розібрався досить швидко: кластер та база піднімаються без проблем.
А ось з кубером конкретно пововтузився.
Спільну для всіх частину інфраструктури (ingress та cert-manager) я теж запхав у тераформ, а для апок зробив Helm chart. Кожен сервіс і в Nomad і в K8S розгортається згідно дефінішену. Для Nomad він пишеться на HCL, а для кубера в YAML. HCL досить читаємий; крім того, сама структура Nomad джоб дуже проста. Куберівський ямль — це величезне та складне нагромадження купи об'єктів, які для непідготовленої людини виглядають незрозуміло.
Потрібно розібратися у всій термінології та специфіці куберу, щоб хоч щось почало виходити.
Для того, щоб оновлювати сервіс та деплоїти нові версії, вам потрібно якимось чином шаблонізувати цю гору ямлів. На допомогу приходить Helm. Проблема в тому, що дефолтний шаблон, який вам пропонують, переускладнений та рясніє купою незрозумілих речей.
В Nomad конфігурації в мене був 1 (один!) файлик на 80 рядків з двома джобами: перша для міграцій, інша розгортає вебсервіс. Ну добре, ще один файлик для траєфіку, але він один на всіх.
В кубері для тієї ж задачі я маю 8 (вісім!) файлів, три з яких на 80 рядків, і це тільки вебсервіси.
З декількох туторіалів по кейворду «rails helm» мені вдалося зібрати робочу конфігурацію та все заколосилось.
Невирішеними залишилися ті ж питання: Vault та CI/CD. Секрети я склав в куберівські, а для CI/CD встановив на кластер GitLab агента, який дозволяє сек'юрно без прямого з'єднання з кластером запускати куберівські команди з гітлаб пайплайну. Приведу до ладу Helm чарти, а там вже буде діло техніки
Для цієї конфігурації я теж підготую мануал. upd: мануал я так і не зробив, бо було не до того, а потім переїхав на Fly і вже не було мотивації щось робити. В інтернеті ви знайдете мільйон туторіалів по куберу, але одиниці розжовують покроково що відбувається, натомість ви просто копіпастите ямлі та сподіваєтеся що все запрацює.
Одне тішить — всю цю роботу потрібно зробити один раз, а далі пожинати плоди автоматизації.
Сподобалось? Долучайтеся до мого телеграм каналу: https://t.me/full_of_hatred
