Налаштування CI/CD пайплайну через Harness
Ми стикалися з ситуацією: пайплайн успішно деплоїть нову версію, а через п'ять хвилин — падіння error rate в Prometheus, користувачі скаржаться, адмін у паніці. Звичайний CI/CD не вміє відкочуватися сам — тільки скрипти та ручні тригери. Наш досвід впровадження Harness показує, що платформа вирішує цю проблему: після деплою вона аналізує метрики та автоматично запускає rollback при деградації. Це не просто CI/CD — це intelligent deployment з безперервною верифікацією. MTTR (Mean Time To Recovery) скорочується з 2 годин до 10 хвилин, а витрати на відкати знижуються на 80%.
Як працює Continuous Verification в Harness?
Після кожного деплою Harness запускає етап Verify, який протягом заданого часу (наприклад, 15 хвилин) порівнює нові метрики з baseline попередньої версії. Для цього використовуються ML-моделі, що враховують час доби, день тижня та історичні патерни. Якщо error rate виріс або latency деградувала вище порогу — запускаються rollbackSteps без участі людини. Це дозволяє знизити MTTR з годин до хвилин. У порівнянні з Jenkins, де ролбек доводиться писати скриптом і налаштовувати моніторинг окремо, Harness прискорює реакцію в 3-5 разів.
Приклад налаштування етапу Verify з Prometheus:
---
- stage:
name: Verify Staging
identifier: verify_staging
type: Deployment
spec:
execution:
steps:
- step:
type: Verify
name: CV Check
identifier: cv_check
spec:
type: Rolling
monitoredServiceRef: myapp-staging-monitored
healthSources:
- identifier: prometheus-staging
spec:
sensitivity: MEDIUM
duration: 15m
deploymentTag: <+artifacts.primary.tag>
Чому Delegate важливий для безпеки?
Harness не звертається безпосередньо до вашого Kubernetes-кластеру з хмари. Натомість встановлюється Delegate — агент в кластері, який приймає завдання від Harness Platform і виконує їх локально. Це вирішує проблему з private clusters без публічного доступу. Delegate працює в ізольованій мережі, не вимагаючи відкриття inbound-портів. Масштабується горизонтально і оновлюється автоматично. Кожен екземпляр Delegate потребує 2 vCPU та 4 GB RAM, підтримує до 10 паралельних завдань; для продакшену рекомендується мінімум 2 репліки.
Встановлення через Helm:
helm install harness-delegate harness/harness-delegate \
--namespace harness-delegate-ng \
--create-namespace \
--set delegateName=my-delegate \
--set accountId=$HARNESS_ACCOUNT_ID \
--set delegateToken=$DELEGATE_TOKEN \
--set managerEndpoint=https://app.harness.ioСтруктура Harness: Pipelines, Stages, Steps
Harness Pipeline складається з Stages. Тип Stage визначає контекст: CI, CD, Feature Flags, Approval, Custom.
Конфігурація через YAML (Harness YAML):
---
pipeline:
name: myapp-ci-cd
identifier: myapp_ci_cd
projectIdentifier: myproject
orgIdentifier: myorg
stages:
- stage:
name: Build and Test
identifier: build_and_test
type: CI
spec:
cloneCodebase: true
platform:
os: Linux
arch: Amd64
runtime:
type: Cloud
spec: {}
execution:
steps:
- step:
type: Run
name: Install and Test
identifier: install_and_test
spec:
connectorRef: docker-hub-connector
image: node:20-alpine
command: |
npm ci
npm run lint
npm run test -- --coverage
- step:
type: BuildAndPushDockerRegistry
name: Build and Push Image
identifier: build_push
spec:
connectorRef: docker-registry-connector
repo: registry.example.com/myapp
tags:
- <+pipeline.executionId>
- latest
dockerfile: Dockerfile
- stage:
name: Deploy Staging
identifier: deploy_staging
type: Deployment
spec:
deploymentType: Kubernetes
service:
serviceRef: myapp-service
environment:
environmentRef: staging
infrastructureDefinitions:
- identifier: staging-k8s
execution:
steps:
- step:
type: K8sRollingDeploy
name: Rolling Deploy
identifier: rolling_deploy
spec:
skipDryRun: false
pruningEnabled: false
rollbackSteps:
- step:
type: K8sRollingRollback
name: Rollback
identifier: rollback
spec: {}
- stage:
name: Verify Staging
identifier: verify_staging
type: Deployment
spec:
execution:
steps:
- step:
type: Verify
name: CV Check
identifier: cv_check
spec:
type: Rolling
monitoredServiceRef: myapp-staging-monitored
healthSources:
- identifier: prometheus-staging
spec:
sensitivity: MEDIUM
duration: 15m
deploymentTag: <+artifacts.primary.tag>
Які метрики аналізує Harness для верифікації?
Harness інтегрується з Prometheus, DataDog, New Relic, Splunk та іншими системами моніторингу. За замовчуванням використовуються метрики error rate, latency, трафік, saturation — так звані золоті сигнали (Golden Signals). ML-модель порівнює їх з історичним baseline та виявляє аномалії. Наприклад, якщо error rate виріс на 5% при звичайній варіації в 2% — це тригерить rollback. Чутливість налаштовується через параметр sensitivity (LOW, MEDIUM, HIGH).
Порівняння метрик для верифікації
| Метрика | Джерело | Типовий поріг |
|---|---|---|
| Error rate | Prometheus, DataDog | +5% від baseline |
| Latency (p95) | Prometheus, DataDog | +20% від baseline |
| Traffic drop | Grafana, CloudWatch | -10% за 15 хв |
Connectors та Secrets
Harness використовує Connectors для підключення до зовнішніх систем: Docker Registry, Kubernetes, Git, Helm Chart repos. Секрети зберігаються в Harness Secrets Manager або делегуються у зовнішній Vault:
---
connector:
name: vault-connector
identifier: vault_connector
type: Vault
spec:
vaultUrl: https://vault.example.com
authType: AppRole
appRoleId: harness-app-role
secretId: harness-vault-secret
secretEngine: secret
secretEngineVersion: 2
Після цього будь-який секрет з Vault доступний в пайплайні через <+secrets.getValue("vault://myapp/prod/db_password")>.
Що входить до нашої роботи
Ми надаємо повний цикл впровадження Harness. Наш досвід — понад 40 успішних проектів у великих кластерах (від 10 до 500 нод). Ми налаштовуємо GitOps-пайплайни, автоматичний відкат і моніторинг деплою. В послугу входить:
- Аудит поточної інфраструктури та пайплайнів
- Проектування архітектури CI/CD з урахуванням безпеки та масштабування
- Розгортання Delegate та налаштування Connectors (Docker Registry, K8s, Git, Vault)
- Побудова Pipeline з CI, CD та Verify stages
- Інтеграція з моніторингом (Prometheus, DataDog, New Relic) для Continuous Verification
- Документація по пайплайнах та керівництво для розробників
- Навчання команди роботі з Harness
- Підтримка протягом першого місяця після запуску
Процес роботи
- Аналітика — аудит інфраструктури, збір вимог, визначення метрик успіху.
- Проектування — архітектура пайплайнів, схема безпечних доступів, вибір стратегії деплою (rolling, blue-green, canary).
- Реалізація — розгортання Delegate, налаштування Connectors, створення Pipeline з CI, CD, Verify.
- Тестування — перевірка ролбеку, верифікація аномалій, навантажувальне тестування.
- Деплой — введення в експлуатацію, навчання, передача документації.
Орієнтовні терміни
| Масштаб | Термін |
|---|---|
| Базова установка + один сервіс | 2-3 дні |
| Декілька сервісів + CV + Vault | 4-6 днів |
| Enterprise setup з кількома cluster | 6-10 днів |
Вартість розраховується індивідуально після аудиту інфраструктури. Зв'яжіться з нами для оцінки вашого проекту — отримайте консультацію інженера. Ми гарантуємо стабільність пайплайнів і скорочення часу rollback до мінімуму.
Типові помилки при налаштуванні Harness
- Неправильна конфігурація healthSources — метрики не приходять, верифікація не спрацьовує.
- Занадто низька чутливість (sensitivity) — аномалії пропускаються.
- Відсутність rollbackSteps в CD-стадії — при помилці деплой не відкочується.
- Delegate без достатніх прав — не може виконувати операції в кластері.
- Ігнорування baseline — якщо baseline побудований на нерепрезентативних даних, ML помилково спрацьовує.
Замовте впровадження Harness у нашої команди. Отримайте консультацію інженера та розрахунок термінів для вашого проекту.
