Налаштування Canary деплою для веб-застосунку

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.
Розробка та обслуговування будь-яких видів сайтів:
Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

Це лише деякі з технічних типів сайтів, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Пропоновані послуги
Показано 1 з 1 послугУсі 2065 послуг
Налаштування Canary деплою для веб-застосунку
Складна
~3-5 робочих днів
Часті питання
Наші компетенції:
Етапи розробки
Останні роботи
  • image_website-b2b-advance_0.png
    Розробка сайту компанії B2B ADVANCE
    1262
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1171
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    874
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1094
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    831
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Розробка веб-сайту для компанії ФІКСПЕР
    851

Налаштування Canary розгортання для веб-додатків

Canary розгортання — постипове переключення трафіку на нову версію: спочатку 1–5% користувачів, потім 10%, 25%, 50% і нарешті 100%. Це дозволяє виявити проблеми на реальному трафіку до повної міграції.

Принцип

v1.0 (95%) ←── 95% запросів
                              ← Load Balancer
v1.1 (5%)  ←──  5% запросів

Якщо метрики (error rate, latency, conversion) в нормі → збільшити відсоток. Якщо погіршення → откатити на 0%.

Nginx split_clients

# /etc/nginx/nginx.conf
split_clients "${remote_addr}${http_user_agent}" $upstream_pool {
    5%   canary;     # 5% → нова версія
    *    stable;     # 95% → стара версія
}

upstream stable {
    server 10.0.0.10:8080;
}

upstream canary {
    server 10.0.0.11:8080;  # нова версія
}

server {
    location / {
        proxy_pass http://$upstream_pool;
    }
}

Щоб змінити відсоток — редагуємо конфіг і перезагружаємо Nginx.

Canary через Cookie (sticky routing)

# Користувач завжди потрапляє в ту саму версію
map $cookie_canary $upstream_canary {
    "1"  canary;
    default stable;
}

# Або примусово включити для тестувальників
map $http_x_canary_override $upstream_override {
    "true" canary;
    default $upstream_canary;
}

Kubernetes + NGINX Ingress

# stable-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-stable
---
# canary-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-canary
---
# canary-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "5"   # 5% трафіку
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            backend:
              service:
                name: myapp-canary-svc
                port: { number: 80 }
# Збільшити до 25%
kubectl annotate ingress myapp-canary \
    nginx.ingress.kubernetes.io/canary-weight=25 --overwrite

# Повна міграція → оновити stable deployment
kubectl set image deployment/myapp-stable myapp=registry/myapp:v1.1.0

# Видалити canary
kubectl delete ingress myapp-canary
kubectl delete deployment myapp-canary

AWS: Weighted Target Groups

import boto3

elbv2 = boto3.client('elbv2')

def set_canary_weight(listener_arn: str, stable_tg: str, canary_tg: str, canary_weight: int):
    """stable_weight + canary_weight повинні дорівнювати 100"""
    stable_weight = 100 - canary_weight

    elbv2.modify_listener(
        ListenerArn=listener_arn,
        DefaultActions=[{
            'Type': 'forward',
            'ForwardConfig': {
                'TargetGroups': [
                    {'TargetGroupArn': stable_tg, 'Weight': stable_weight},
                    {'TargetGroupArn': canary_tg,  'Weight': canary_weight},
                ],
                'TargetGroupStickinessConfig': {
                    'Enabled': True,
                    'DurationSeconds': 3600,  # stickiness 1 година
                }
            }
        }]
    )

Автоматичний Canary з аналізом метрик

# canary-rollout.py
import time
import boto3
import requests

PROMETHEUS_URL = "http://prometheus:9090"

def get_error_rate(version: str, duration: str = "5m") -> float:
    query = f'rate(http_requests_total{{version="{version}",status=~"5.."}}[{duration}]) / rate(http_requests_total{{version="{version}"}}[{duration}])'
    r = requests.get(f"{PROMETHEUS_URL}/api/v1/query", params={"query": query})
    result = r.json()["data"]["result"]
    return float(result[0]["value"][1]) if result else 0.0

def progressive_rollout():
    steps = [5, 10, 25, 50, 75, 100]
    canary_weight = 0

    for target_weight in steps:
        print(f"Setting canary weight to {target_weight}%")
        set_canary_weight(LISTENER_ARN, STABLE_TG, CANARY_TG, target_weight)

        # Ждати і перевіряти метрики
        time.sleep(300)  # 5 хвилин на кожному кроці

        error_rate = get_error_rate("canary")
        print(f"Canary error rate: {error_rate:.2%}")

        if error_rate > 0.01:  # >1% помилок
            print(f"Error rate too high ({error_rate:.2%}), rolling back!")
            set_canary_weight(LISTENER_ARN, STABLE_TG, CANARY_TG, 0)
            return False

    print("Canary rollout complete!")
    return True

Терміни реалізації

  • Nginx canary на VPS: 1–2 дні
  • Kubernetes NGINX Ingress canary: 2–3 дні
  • Автоматичний rollout з метриками: 3–5 днів