Блок 12 Презентація

Фінал GitOps — ArgoCD та деплой у продакшен

Нотатки презентації та структура виступу для Блоку 12.

Тривалість: ~10 хвилин Мета: Студенти розуміють GitOps як філософію, як ArgoCD її реалізує та чому це змінює все у їхньому уявленні про деплої. Побудуйте азарт — це кульмінація.

Слайд 1: Проблема з “kubectl apply”

Почнемо з жахливої історії.

2 ночі. Деплой у продакшен зафейлився. Команда метушиться. Хтось запитує: “Що насправді зараз працює в кластері?” Ніхто не знає. Три різних інженери запускали kubectl apply в різний час протягом дня. Один з них використав маніфест із гілки, що ніколи не була змерджена. Інший пропатчив щось напряму через kubectl edit. Стан кластера не відповідає нічому в Git.

Це називається configuration drift, і це найпоширеніше джерело кошмарів з деплоями.

Тепер уявіть протилежне. Кожна зміна кластера проходить через Git. Кожна. Без винятків. Якщо цього немає в Git — це не застосовується. Хочете знати, що працює у продакшені? Дивіться гілку main. Крапка. Git — це істина.

Це GitOps.

Цікавий факт: Термін “GitOps” був придуманий Алексісом Річардсоном у Weaveworks у 2017 році. Все почалося з блог-поста. Сьогодні CNCF має цілу робочу групу, присвячену цьому, і навіть найбільш security-conscious фінансові установи — банки, де не можна зробити ssh на сервер без трьох апрувлів — використовують GitOps для продакшен-деплоїв.

Слайд 2: GitOps в одній діаграмі

Ось цикл. Запам’ятайте його, бо коли ви зрозумієте цей цикл, ви зрозумієте GitOps:

Розробник пушить код у Git
         |
         v
ArgoCD стежить за Git-репо (polling або webhook)
         |
         v
ArgoCD порівнює стан Git vs. стан кластера
         |
         v
 Вони відрізняються?
    /          \
  Ні            Так
   |             |
   v             v
 Нічого       Sync: застосувати diff до кластера
 не робити       |
                 v
          Кластер тепер відповідає Git
                 |
                 v
            Знову стежити

Це все. Вся модель. Git — бажаний стан. Kubernetes — фактичний стан. Єдина задача ArgoCD — зробити їх однаковими.

Жодного kubectl apply. Жодних скриптів деплою. Жодних Jenkins-пайплайнів, що ssh-аться на сервер і виконують команди. Ви пушите в Git, і кластер конвергує до відповідності. Якщо хтось вручну щось змінить у кластері, ArgoCD виявить drift і поверне все до того, що каже Git.

Git завжди виграє.

Слайд 3: Чому ArgoCD

Є кілька GitOps-інструментів: ArgoCD, Flux, Jenkins X, Rancher Fleet. Ми використовуємо ArgoCD, бо:

  1. Візуальний дашборд — веб-UI, що показує точно, що синхронізовано, що ні та що зламано. Ви його побачите сьогодні.
  2. Перевірений у боях — graduated CNCF-проєкт. Використовується Intuit (TurboTax), Red Hat, Tesla, IBM та тисячами менших команд.
  3. Декларативна конфігурація — ви описуєте бажане у YAML. ArgoCD робить решту.
  4. Обробляє складність — підтримує Helm charts, Kustomize overlays, сирі маніфести та Jsonnet. Сьогодні ми використовуємо сирі маніфести, але той самий інструмент масштабується до величезних деплоїв.
  5. Self-healing — якщо хтось виконає kubectl delete на ресурсі, що має існувати, ArgoCD поверне його. Кластер самовідновлюється на основі того, що декларує Git.

Ось як ArgoCD-модель виглядає на практиці:

# argocd/application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: ai-coderrank
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/YOUR_USER/ai-coderrank.git
    targetRevision: main
    path: k8s
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Цей файл каже: “Стеж за директорією k8s/ цього GitHub-репо. Коли вона змінюється — синхронізуй у namespace default. Якщо кластер дрифтує — відновлюй автоматично.”

Один YAML-файл. Це вся конфігурація деплою, що вам потрібна.

Слайд 4: Три принципи

GitOps стоїть на трьох принципах. Зробимо їх конкретними:

1. Декларативна конфігурація Ви не пишете скрипти, що кажуть “запусти це, потім те, потім перевір це.” Ви пишете YAML, що каже “я хочу 2 репліки цього контейнера на порті 3000 з цими змінними середовища.” Kubernetes та ArgoCD з’ясовують, як туди дістатися.

Аналогія: Це різниця між покроковими інструкціями (“поверни ліворуч, потім праворуч, потім знову ліворуч”) та адресою, де Google Maps сам знайде маршрут. Декларативний = адреса. Імперативний = інструкції.

2. Git як єдине джерело істини Кожна зміна — це коміт. Кожен коміт має автора, timestamp, повідомлення та diff. Ви отримуєте повний аудит-трейл безкоштовно. Хочете знати, хто змінив кількість реплік з 2 на 5 минулого вівторка? git log. Хочете відкотити? git revert. Ваша історія деплоїв І Є ваша git-історія.

3. Автоматична рекансиляція Система безперервно порівнює бажаний стан (Git) з фактичним станом (кластер) і виправляє будь-який drift. Ви не тригерите деплої. Вони відбуваються тому, що стани розійшлися.

Слайд 5: Що ми зараз робитимемо

Ось план практичної частини. Слідкуйте подумки:

  1. Встановити ArgoCD на k3s-кластер — одна команда kubectl apply (остання, що ви коли-небудь виконаєте вручну для деплоїв)
  2. Отримати пароль адміна та відкрити ArgoCD UI через port-forward
  3. Застосувати ArgoCD Application — направити на ваш репо ai-coderrank
  4. Спостерігати першу синхронізацію — ArgoCD читає маніфести з k8s/ та застосовує їх
  5. Відкрити застосунок — налаштувати NodePort для доступу з інтернету
  6. Запушити темну тему — закомітити, запушити, спостерігати, як ArgoCD виявляє і деплоїть зміну
  7. Відкрити в браузері — ваш застосунок, в інтернеті, з темною темою, задеплоєний через GitOps

А потім, бо це Claude Code 101, і ми не зупиняємося на “воно працює”:

  1. Використати /loop для моніторингу статусу синхронізації ArgoCD в реальному часі
  2. Використати /schedule для налаштування регулярного health check
  3. Використати віддалене керування для моніторингу всього з телефону

Слайд 6: /loop, /schedule та віддалене керування

Три функції, що перетворюють Claude Code з інструменту розробки на інструмент операцій.

/loop — Запустити будь-яку команду або промпт з повторенням через інтервал:

/loop 30s check if ArgoCD sync is complete for ai-coderrank

Claude перевірятиме кожні 30 секунд і звітуватиме. Ідеально для спостереження за розгортанням деплоїв, моніторингу статусу подів або очікування повільної міграції.

/schedule — Створити регулярні хмарні задачі, що виконуються за cron-розкладом:

/schedule create "Daily health check" --cron "0 9 * * *" \
  --prompt "Check the status of all pods in the ai-coderrank namespace, \
  verify the app responds on the health endpoint, and report any issues"

Це запускає агента Claude у хмарі — за розкладом, без вашої присутності за столом. Ранкові health checks, нічні сканування безпеки, щотижневі аудити залежностей. Налаштуй і забудь.

Віддалене керування — Сесії Claude Code доступні віддалено. Використовуйте /remote-control всередині активної сесії або запустіть Claude з --remote-control, потім перевіряйте з браузера телефону чи Claude-додатку. Ви можете моніторити деплой з дивана, апрувнути синхронізацію з таксі або перевірити логи подів з ліжка. (Ми не засуджуватимемо.)

Слайд 7: Загальна картина

Відступимо назад. Подивіться, що ви побудували за ці 12 блоків:

Ви пишете код
     |
     v
Claude Code допомагає реалізувати, ревʼюїти, тестувати
     |
     v
Git commit + push
     |
     v
GitHub Actions запускає CI (Блок 10)
     |
     v
ArgoCD виявляє зміну (Блок 12 — ПРЯМО ЗАРАЗ)
     |
     v
Kubernetes застосовує новий стан
     |
     v
Застосунок живий в інтернеті
     |
     v
/schedule моніторить здоров'я щодня
/loop стежить за деплоями в реальному часі
Віддалене керування дозволяє керувати звідусіль

Це повний, сучасний, production-grade пайплайн розробки та деплою. Не навчальна іграшка. Не симуляція. Справжня річ.

Ви все це побудували. З Claude Code.

Готові перевірити засвоєне?

Пройти квіз →