Модуль 4.1: Основи CI/CD
Складність:
[MEDIUM]- Концепції доставкиЧас на виконання: 25-30 хвилин
Передумови: Частина 3 (Хмарна нативна архітектура)
Що ви зможете робити
Розділ «Що ви зможете робити»Після завершення цього модуля ви зможете:
- Пояснити різницю між Continuous Integration, Continuous Delivery та Continuous Deployment
- Визначити етапи типового CI/CD пайплайну та що кожен етап перевіряє
- Порівняти інструменти CI/CD (Jenkins, GitHub Actions, GitLab CI, Tekton) за архітектурою та варіантами використання
- Оцінити GitOps як модель розгортання та чим він відрізняється від традиційного push-based CI/CD
Чому цей модуль важливий
Розділ «Чому цей модуль важливий»Сучасна доставка програмного забезпечення вимагає автоматизації. Безперервна інтеграція та Безперервна доставка/розгортання (CI/CD) є фундаментальними практиками для надійної доставки коду від розробки до продакшену. KCNA перевіряє ваше розуміння цих концепцій.
Що таке CI/CD?
Розділ «Що таке CI/CD?»┌─────────────────────────────────────────────────────────────┐│ ОГЛЯД CI/CD │├─────────────────────────────────────────────────────────────┤│ ││ БЕЗПЕРЕРВНА ІНТЕГРАЦІЯ (CI) ││ ───────────────────────────────────────────────────────── ││ Часте злиття змін коду у спільний репозиторій ││ Автоматична збірка та тестування кожної зміни ││ ││ Код → Збірка → Тестування → Злиття ││ ││ БЕЗПЕРЕРВНА ДОСТАВКА (CD) ││ ───────────────────────────────────────────────────────── ││ Автоматична підготовка коду до випуску в продакшен ││ Розгортання — ручне (натискання кнопки) ││ ││ CI → Пакування → Стейджинг → [Ручне розгортання] ││ ││ БЕЗПЕРЕРВНЕ РОЗГОРТАННЯ (CD) ││ ───────────────────────────────────────────────────────── ││ Автоматичне розгортання кожної зміни в продакшен ││ Без ручного втручання ││ ││ CI → Пакування → Стейджинг → [Авто розгортання] ││ ││ Різниця: ││ • Безперервна доставка: МОЖЕ розгортати в будь-який час ││ • Безперервне розгортання: РОЗГОРТАЄ автоматично ││ │└─────────────────────────────────────────────────────────────┘Пайплайн CI/CD
Розділ «Пайплайн CI/CD»┌─────────────────────────────────────────────────────────────┐│ ПАЙПЛАЙН CI/CD │├─────────────────────────────────────────────────────────────┤│ ││ Код ││ │ ││ ▼ ││ ┌─────────────────────────────────────────────────────┐ ││ │ 1. ДЖЕРЕЛО │ ││ │ Розробник комітить код у Git │ ││ │ Запускає пайплайн │ ││ └─────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌─────────────────────────────────────────────────────┐ ││ │ 2. ЗБІРКА │ ││ │ Компіляція коду, розвʼязання залежностей │ ││ │ Створення образу контейнера │ ││ └─────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌─────────────────────────────────────────────────────┐ ││ │ 3. ТЕСТУВАННЯ │ ││ │ Модульні тести, інтеграційні тести │ ││ │ Сканування безпеки, лінтинг │ ││ └─────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌─────────────────────────────────────────────────────┐ ││ │ 4. ПАКУВАННЯ │ ││ │ Завантаження образу контейнера в реєстр │ ││ │ Створення Helm chart/маніфестів │ ││ └─────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌─────────────────────────────────────────────────────┐ ││ │ 5. РОЗГОРТАННЯ │ ││ │ Розгортання на стейджинг/продакшен │ ││ │ Запуск smoke тестів │ ││ └─────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ Продакшен ││ │└─────────────────────────────────────────────────────────────┘Переваги CI/CD
Розділ «Переваги CI/CD»┌─────────────────────────────────────────────────────────────┐│ ПЕРЕВАГИ CI/CD │├─────────────────────────────────────────────────────────────┤│ ││ БЕЗ CI/CD: ││ ───────────────────────────────────────────────────────── ││ • Ручні збірки ("працює на моїй машині") ││ • Рідкісні релізи (великий вибух) ││ • Ручне тестування (схильне до помилок) ││ • Довгі цикли зворотного звʼязку ││ • Ризиковані розгортання ││ ││ З CI/CD: ││ ───────────────────────────────────────────────────────── ││ • Автоматичні збірки (відтворювані) ││ • Часті релізи (невеликі зміни) ││ • Автоматичне тестування (послідовне) ││ • Швидкий зворотний звʼязок (хвилини, не дні) ││ • Безпечні розгортання (готовність до відкату) ││ ││ Ключові метрики: ││ ───────────────────────────────────────────────────────── ││ • Частота розгортань (як часто) ││ • Час виконання (від коміту до продакшену) ││ • Частота невдач змін (% що спричиняють проблеми) ││ • Середній час відновлення (виправлення продакшен ││ проблем) ││ │└─────────────────────────────────────────────────────────────┘Інструменти CI/CD
Розділ «Інструменти CI/CD»Загальні платформи CI/CD
Розділ «Загальні платформи CI/CD»| Інструмент | Опис |
|---|---|
| Jenkins | Самостійний хостинг, високо налаштовуваний |
| GitHub Actions | Вбудований у GitHub |
| GitLab CI | Вбудований у GitLab |
| CircleCI | Хмарний нативний CI/CD |
| Travis CI | Простий CI/CD |
Kubernetes-нативний CI/CD
Розділ «Kubernetes-нативний CI/CD»┌─────────────────────────────────────────────────────────────┐│ KUBERNETES-НАТИВНИЙ CI/CD │├─────────────────────────────────────────────────────────────┤│ ││ TEKTON (CNCF) ││ ───────────────────────────────────────────────────────── ││ • CI/CD як ресурси Kubernetes ││ • Tasks, Pipelines, PipelineRuns ││ • Хмарний нативний, serverless ││ ││ ARGO CD (CNCF Graduated) ││ ───────────────────────────────────────────────────────── ││ • GitOps безперервна доставка ││ • Декларативний, Git як джерело істини ││ • Синхронізація стану кластера з Git ││ ││ FLUX (CNCF Graduated) ││ ───────────────────────────────────────────────────────── ││ • GitOps безперервна доставка ││ • Подібний до Argo CD ││ • Тісна інтеграція з Helm ││ ││ ARGO WORKFLOWS (CNCF) ││ ───────────────────────────────────────────────────────── ││ • Рушій робочих процесів для Kubernetes ││ • Робочі процеси на основі DAG ││ • CI/CD та пайплайни даних ││ │└─────────────────────────────────────────────────────────────┘GitOps vs Традиційний CI/CD
Розділ «GitOps vs Традиційний CI/CD»┌─────────────────────────────────────────────────────────────┐│ GITOPS vs ТРАДИЦІЙНИЙ CI/CD │├─────────────────────────────────────────────────────────────┤│ ││ ТРАДИЦІЙНИЙ (На основі push): ││ ───────────────────────────────────────────────────────── ││ ││ Git → CI сервер → Push до кластера ││ ││ ┌──────┐ ┌─────────┐ ┌─────────────┐ ││ │ Git │ → │ CI │ → │ Кластер │ ││ │ │ │ Сервер │ │ │ ││ └──────┘ └─────────┘ └─────────────┘ ││ ││ • CI потребує облікові дані кластера ││ • Зовнішня система надсилає зміни ││ ││ GITOPS (На основі pull): ││ ───────────────────────────────────────────────────────── ││ ││ Git ← Pull з кластера ││ ││ ┌──────┐ ┌─────────────┐ ││ │ Git │ ←────────── │ Кластер │ ││ │ │ агент │ (Argo CD) │ ││ └──────┘ витягує └─────────────┘ ││ ││ • Кластер витягує з Git ││ • Не потрібен зовнішній доступ ││ • Git = джерело істини ││ │└─────────────────────────────────────────────────────────────┘Стратегії розгортання
Розділ «Стратегії розгортання»┌─────────────────────────────────────────────────────────────┐│ СТРАТЕГІЇ РОЗГОРТАННЯ │├─────────────────────────────────────────────────────────────┤│ ││ ROLLING UPDATE (Типова для Kubernetes) ││ ───────────────────────────────────────────────────────── ││ Поступова заміна старих Podʼів новими ││ ││ [v1][v1][v1] → [v1][v1][v2] → [v1][v2][v2] → [v2][v2][v2]││ ││ + Без простою ││ + Просто ││ - Повільний відкат ││ ││ BLUE-GREEN ││ ───────────────────────────────────────────────────────── ││ Запуск обох версій, миттєве перемикання трафіку ││ ││ [Blue v1] ← трафік [Blue v1] ││ [Green v2] → [Green v2] ← трафік ││ ││ + Миттєвий відкат ││ + Повне тестування перед перемиканням ││ - Подвійні ресурси ││ ││ CANARY ││ ───────────────────────────────────────────────────────── ││ Направлення малого % трафіку на нову версію ││ ││ [v1][v1][v1] ← 90% трафіку ││ [v2] ← 10% трафіку (canary) ││ ││ + Тестування з реальним трафіком ││ + Поступове розгортання ││ + Швидкий відкат (просто видаліть canary) ││ - Складніше налаштування ││ │└─────────────────────────────────────────────────────────────┘Порівняння стратегій
Розділ «Порівняння стратегій»| Стратегія | Простій | Відкат | Вартість ресурсів | Складність |
|---|---|---|---|---|
| Rolling | Немає | Повільний | Звичайна | Низька |
| Blue-Green | Немає | Миттєвий | 2x під час розгортання | Середня |
| Canary | Немає | Швидкий | Незначне збільшення | Висока |
| Recreate | Так | Повільний | Звичайна | Найнижча |
Реєстри контейнерів
Розділ «Реєстри контейнерів»┌─────────────────────────────────────────────────────────────┐│ РЕЄСТРИ КОНТЕЙНЕРІВ │├─────────────────────────────────────────────────────────────┤│ ││ Де зберігаються образи контейнерів ││ ││ CI збирає образ → Push до реєстру → K8s витягує образ ││ ││ Публічні реєстри: ││ ───────────────────────────────────────────────────────── ││ • Docker Hub (docker.io) ││ • GitHub Container Registry (ghcr.io) ││ • Google Container Registry (gcr.io) ││ • Quay.io ││ ││ Приватні реєстри: ││ ───────────────────────────────────────────────────────── ││ • Harbor (CNCF Graduated) ││ • AWS ECR ││ • Azure ACR ││ • Google Artifact Registry ││ ││ Можливості Harbor: ││ • Сканування вразливостей ││ • Підписання образів ││ • Доступ на основі ролей ││ • Реплікація ││ │└─────────────────────────────────────────────────────────────┘Чи знали ви?
Розділ «Чи знали ви?»-
Безперервне розгортання вимагає впевненості — Вам потрібне комплексне автоматичне тестування та моніторинг для автоматичного розгортання кожного коміту.
-
GitOps придумав Weaveworks — Термін та практика були популяризовані Weaveworks, творцями Flux.
-
Canary походить з вугільних шахт — Шахтарі використовували канарок для виявлення токсичних газів. У розгортаннях canary реліз виявляє проблеми з реальним трафіком.
-
Метрики DORA — DevOps Research and Assessment (DORA) визначила частоту розгортань, час виконання, частоту невдач змін та MTTR як ключові показники ефективності.
Поширені помилки
Розділ «Поширені помилки»| Помилка | Чому це шкодить | Правильне розуміння |
|---|---|---|
| Без автоматичних тестів | Зламані розгортання | Тести необхідні для CI |
| Ручні розгортання | Непослідовно, схильне до помилок | Автоматизуйте все |
| Релізи великим вибухом | Високий ризик | Невеликі, часті зміни |
| Без плану відкату | Застрягли з поганою версією | Завжди майте готовий відкат |
Тест
Розділ «Тест»-
Яка різниця між безперервною доставкою та безперервним розгортанням?
Відповідь
Безперервна доставка означає, що код завжди готовий до розгортання (ручний тригер). Безперервне розгортання автоматично розгортає кожну зміну, що пройшла тести. Доставка = МОЖЕ розгортати; Розгортання = РОЗГОРТАЄ. -
Що таке GitOps?
Відповідь
Підхід CD, де Git є джерелом істини для інфраструктури та стану застосунків. Агент у кластері витягує бажаний стан з Git та узгоджує його. Зміни вносяться через Git коміти, не через прямі kubectl команди. -
Що таке canary розгортання?
Відповідь
Стратегія розгортання, де малий відсоток трафіку направляється на нову версію, поки більшість трафіку йде на стару. Якщо canary працює добре, трафік поступово переміщується. Якщо ні — canary видаляється. -
Назвіть два Kubernetes-нативні інструменти CI/CD.
Відповідь
Tekton (CI/CD пайплайни як ресурси Kubernetes), Argo CD (GitOps безперервна доставка), Flux (GitOps), Argo Workflows (рушій робочих процесів). Всі є проєктами CNCF. -
Що таке метрики DORA?
Відповідь
Частота розгортань (як часто ви розгортаєте), Час виконання (час від коміту до продакшену), Частота невдач змін (% розгортань, що спричиняють проблеми), Середній час відновлення (час для виправлення продакшен проблем). Вони вимірюють ефективність DevOps.
Підсумок
Розділ «Підсумок»Концепції CI/CD:
- CI: Часта інтеграція та тестування коду
- CD (Доставка): Завжди готовий до розгортання
- CD (Розгортання): Автоматичне розгортання всього
Етапи пайплайну: Джерело → Збірка → Тестування → Пакування → Розгортання
Стратегії розгортання:
- Rolling: Поступова заміна (типова)
- Blue-Green: Перемикання трафіку між версіями
- Canary: Тестування з малим відсотком трафіку
GitOps:
- Git = джерело істини
- На основі pull (кластер витягує з Git)
- Інструменти: Argo CD, Flux
Наступний модуль
Розділ «Наступний модуль»Модуль 4.2: Пакування застосунків - Helm, Kustomize та інші інструменти для пакування застосунків Kubernetes.