Налаштування Kubernetes-оркестрації бекенду мобільного додатку

Зазначимо: коли ми беремося за налаштування Kubernetes для мобільного бекенду, перша проблема — різкі стрибки навантаження. Наприклад, додаток з 50 000 активних користувачів зазнає 10–15-кратних коливань трафіку: ранковий пік, обід, вечір. На одному сервері це означає або перевитрату ресурсів вночі, або деградацію в пік. Одного разу до нас звернувся клієнт з 100 000 DAU: його Node.js API падав при пікових 10k RPS, а ECS не справлявся з автомасштабуванням. Kubernetes вирішує це через горизонтальне автомасштабування, rolling update без даунтайму та ізоляцію сервісів. Досвід — 5 років в DevOps для мобільних проєктів, понад 20 успішних впроваджень, сертифіковані інженери (CKA, CKAD). Гарантуємо SLA 99.9% та підтримку після запуску. Завдяки оркестрації економія на хмарних ресурсах може сягати 50 000–200 000 гривень на місяць. Замовте консультацію — ми підберемо оптимальну конфігурацію.

Як виглядає базова архітектура Kubernetes-оркестрації для мобільного бекенду?

Типовий набір компонентів:

Deployment і HPA — налаштування kubernetes оркестрації

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mobile-api
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mobile-api
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0  # Zero-downtime
  template:
    metadata:
      labels:
        app: mobile-api
    spec:
      containers:
        - name: api
          image: ghcr.io/myorg/mobile-api:1.2.3
          ports:
            - containerPort: 3000
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: url
            - name: REDIS_URL
              valueFrom:
                secretKeyRef:
                  name: redis-credentials
                  key: url
          resources:
            requests:
              memory: "256Mi"
              cpu: "100m"
            limits:
              memory: "512Mi"
              cpu: "500m"
          livenessProbe:
            httpGet:
              path: /health/live
              port: 3000
            initialDelaySeconds: 10
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 5
          lifecycle:
            preStop:
              exec:
                command: ["/bin/sh", "-c", "sleep 5"]

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: mobile-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: mobile-api
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

preStop sleep на 5 секунд потрібен, щоб Ingress встиг прибрати Pod з rotation до того, як він почне завершувати з'єднання. Як рекомендує preStop hook, цей крок гарантує zero-downtime при rolling update.

Що робити, якщо HPA не масштабується?

Часта проблема — метрики не доходять до HPA. Перевірте, чи запущений metrics-server, та правильність target averageUtilization. Для custom метрик (наприклад, по RPS) використовуйте Prometheus Adapter з конфігурацією для збору метрик з кожного пода. Ми закладаємо 2 дні на налагодження HPA при першому впровадженні.

Secrets та конфіденційні дані

APNs .p8 ключі, FCM server key, JWT secrets — в Kubernetes Secrets:

kubectl create secret generic apns-credentials \
  --from-file=AuthKey_XXXXXX.p8 \
  --from-literal=key_id=XXXXXXXXXX \
  --from-literal=team_id=YYYYYYYYYY

Для production використовуйте External Secrets Operator з AWS Secrets Manager або HashiCorp Vault — це дозволяє ротувати секрети без ручного перестворення Kubernetes Secret.

WebSocket і sticky sessions

WebSocket — stateful з'єднання. При rolling update старий Pod повинен дочекатися завершення всіх активних з'єднань. Конфігурація nginx-ingress:

nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
nginx.ingress.kubernetes.io/upstream-hash-by: "$remote_addr"

Краще зробити WebSocket сервіс stateless через Redis Pub/Sub: клієнт підключається до будь-якого пода, повідомлення маршрутизуються через Redis channel. Тоді rolling update проходить прозоро.

Monitoring та observability

Prometheus + Grafana — стандарт для Kubernetes. Для мобільного бекенду ключові метрики:

• http_request_duration_seconds з перцентилями p50/p95/p99
• websocket_connections_active (норма: до 10 000 на под)
• push_notification_delivery_rate (цільовий рівень: 99.9%)
• database_pool_size та database_query_duration

Алерти на p99 latency > 500ms, error rate > 0.5%, pod restart count > 3 за 5 хвилин. Налаштування алертів входить у вартість — зв'яжіться для деталей.

Чому GitOps — стандарт для управління інфраструктурою?

ArgoCD або Flux відстежують зміни в Git-репозиторії з маніфестами та застосовують їх у кластері. CI лише збирає образ та оновлює тег у маніфесті через kustomize edit set image або Helm values:

# .github/workflows/deploy.yml
- name: Update image tag
  run: |
    cd k8s/overlays/production
    kustomize edit set image ghcr.io/myorg/mobile-api=ghcr.io/myorg/mobile-api:${{ github.sha }}
    git commit -am "deploy: ${{ github.sha }}"
    git push

ArgoCD бачить коміт і синхронізує кластер. GitOps гарантує, що кластер завжди відповідає стану в репозиторії. Це підвищує прозорість, спрощує аудит та знижує ризик людської помилки при деплої. Наші інженери мають сертифікати CKA та CKAD, тому впровадження GitOps проходить без збоїв.

Процес роботи та що входить

Етапи:

1. Аудит поточної інфраструктури
2. Проєктування namespace/RBAC структури
3. Написання маніфестів (Deployment, Service, Ingress, HPA)
4. Налаштування Secrets management
5. Налаштування моніторингу (Prometheus, Grafana, алерти)
6. Інтеграція з CI/CD (GitOps, ArgoCD/Flux)
7. Навантажувальне тестування автомасштабування з 200% пікового навантаження
8. Документація та навчання команди (2 сесії)
9. Підтримка після запуску (1 місяць)

Зазначимо: що входить у результат:

• Helm-чарти або Kustomize-оверлеї для всіх компонентів
• Документація з архітектури та runbook
• Доступи до моніторингу та алертів
• Доступ до Git-репозиторію з історією
• Навчання команди (2 сесії по 2 години)
• Гарантія коректної роботи HPA та rolling update

Термін: 5 днів для типового бекенду на GKE/EKS/AKS. Вартість розраховується індивідуально після аналізу архітектури та вимог по SLA.

Замовте консультацію, і ми підготуємо індивідуальний план.

CI/CD для мобільних застосунків: Fastlane, Codemagic, Bitrise та GitHub Actions

Ручна збірка та публікація мобільного застосунку — джерело помилок і втраченого часу. Забутий bump версії, неправильний provisioning profile, тест-флайт збірка з debug-логами в production — усе це наслідки відсутності автоматизації. Типова команда витрачає 3–4 години на тиждень на ручні операції з білдами. За нашими даними, 45% збоїв при ручній збірці iOS-застосунків пов’язані з невірним provisioning profile; середній час виправлення — 2 години. Автоматизація через Fastlane та match усуває цю проблему повністю.

Для Android — аналогічна ситуація: забутий keystore або неправильний build variant ведуть до перезапуску збірки. Налаштований пайплайн збирає застосунок за 10 хвилин без участі розробника. Середня економія часу — 8 годин на тиждень. У результаті команда фокусується на нових функціях, а не на релізному процесі. Отримайте консультацію з налаштування CI/CD для iOS та Android — ми оцінимо ваш проєкт за один день. Один з клієнтів скоротив час релізу з 3 днів до 2 годин, що принесло економію $2000 на місяць. Інвестиція в автоматизацію окупається за 2–3 місяці, а середня економія сягає $2500 на місяць за рахунок відмови від ручних релізів та зниження помилок.

Ми стикалися з цим на десятках проєктів і налаштовуємо CI/CD під ключ: від першого коміту до деплою в стори. Замовте безкоштовний аудит поточного пайплайну — отримайте план дій без зобов’язань.

Проблеми, які вирішуємо

• Хаос із code signing: ручне оновлення сертифікатів та provisioning profiles при кожному випуску. match перетворює це на одноразове налаштування.
• Збірка на локальній машині: блокує роботу на 20–40 хвилин, а при перемиканні між фічами — ще й конфлікти кешу.
• Ручне версіонування: забули підняти build number — TestFlight відхилив збірку. Повторна збірка з правильним номером займає ще годину.
• Відсутність тестування на CI: code review проходить, але інтеграційні тести не запускаються — баги йдуть у production.

Як Fastlane вирішує проблему code signing

Fastlane — де-факто стандарт для автоматизації збірок. Fastfile описує lanes — послідовності actions. Типова iOS-конфігурація:

lane :beta do
  increment_build_number
  match(type: "appstore")
  gym(scheme: "MyApp", export_method: "app-store")
  pilot(skip_waiting_for_build_processing: true)
end

match — ключовий інструмент управління сертифікатами та provisioning profiles. Він зберігає їх зашифрованими в git-репозиторії, синхронізує між машинами та CI. Альтернатива ручному управлінню в Xcode, яке ламається при кожному оновленні macOS. Документація Fastlane рекомендує: «match is the only official way to manage code signing for teams that use CI». Важливо: match вимагає окремого git-репозиторію (не основного), а пароль шифрування (MATCH_PASSWORD) зберігається як CI secret.

Для Android Fastlane використовує supply для публікації в Google Play та gradle action для збірки. Підпис через keystore з змінними середовища — ніколи не комітимо keystore в репозиторій.

Головний біль Fastlane: Ruby середовище. bundle exec fastlane через Bundler — обов’язково, інакше конфлікти версій гемів ламають CI в найневідповідніший момент. Ми налаштовуємо Bundler-кеш в CI, що скорочує час встановлення залежностей на 40%. Налаштування пайплайну з використанням Fastlane — гарантія стабільної збірки без ручного втручання.

GitHub Actions для мобілки

GitHub Actions підходить, якщо репозиторій уже на GitHub. Для iOS потрібен macOS runner — runs-on: macos-14 (Apple Silicon). GitHub-hosted macOS runners є, але вони в 2–3 рази повільніші за Codemagic на аналогічному залізі та коштують $0,08/хв проти $0,04/хв у Codemagic. Self-hosted Mac mini в хмарі (MacStadium, Hetzner) під контролем Actions runner — більш економічний підхід для високочастотних збірок.

Типовий workflow для iOS:

jobs:
  build:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          bundler-cache: true
      - run: bundle exec fastlane beta
        env:
          MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
          APP_STORE_CONNECT_API_KEY_KEY: ${{ secrets.ASC_API_KEY }}

App Store Connect API Key замість Apple ID + пароля — обов’язково. Apple ID з 2FA не працює надійно на CI. API Key створюється в App Store Connect → Users and Access → Keys. Ми включаємо в роботу створення та ротацію цих ключів.

Для налаштування GitHub Actions під iOS виконайте кроки:

1. Створіть YAML-файл в .github/workflows/
2. Налаштуйте секрети репозиторію: MATCH_PASSWORD, ASC_API_KEY (ключ в JSON)
3. Вкажіть runs-on: macos-14
4. Використовуйте ruby/setup-ruby@v1 з bundler-cache: true
5. Запустіть bundle exec fastlane beta

Як вибрати між Codemagic та Bitrise?

Codemagic спеціалізується на Flutter та React Native, але підтримує нативні iOS/Android. Killer feature — codemagic.yaml конфігурація та macOS M2 машини без додаткового налаштування. Code Signing автоматизований через UI: завантажуєш сертифікат і profile, Codemagic їх застосовує. Зручно для команд без DevOps. Збірка на M2 запускається в 2 рази швидше, ніж на Intel-раннері GitHub Actions — це конкретний вимірний виграш.

Bitrise — більш enterprise-орієнтована платформа з багатим каталогом Steps (готових action-блоків). Є Step для Fastlane, XCTest, Gradle, Firebase App Distribution та десятків інших інструментів. Workflow Editor з візуальним інтерфейсом знижує поріг входу. Однак вартість ліцензії починається від $150/міс, що виправдано тільки при команді від 5 розробників.

Основні етапи налаштування CI/CD

Distribution: TestFlight, Firebase App Distribution, Diawi

Для внутрішнього тестування iOS — TestFlight через pilot (Fastlane) або App Store Connect API. Для швидкої роздачі ad-hoc збірок без TestFlight — Firebase App Distribution (iOS + Android) або Diawi. Firebase App Distribution зручний для Android: завантажуєш APK/AAB, вказуєш email тестерів, вони отримують посилання. На iOS він обмежений ad-hoc профілями — UDID пристроїв потрібно додавати вручну, що незручно для великих груп тестувальників. Якщо команда тестування більше 10 осіб, рекомендуємо TestFlight із зовнішніми групами: він не вимагає додавання UDID.

Як налаштувати версіонування без помилок?

Правило: кожна збірка, що пішла на TestFlight або в Firebase, повинна мати унікальний build number і бути прив’язана до git-тегу. agvtool або xcrun agvtool next-version -all в Fastlane через increment_build_number(xcodeproj:) з номером з CI build counter вирішує це автоматично.

Чек-лист типових помилок при налаштуванні версіонування:

• Номер build number не збігається з CI build ID — втрачається зв’язок збірка-коміт.
• Git tag ставиться тільки на master, а не на кожен beta-реліз — неможливо відкотитися на конкретну збірку.
• Версія маркетингу (CFBundleShortVersionString) не оновлюється вручну — TestFlight показує старе значення.

Що входить в роботу

Ми налаштовуємо CI/CD під ключ з гарантією працездатності. У результаті ви отримуєте:

• Робочий Fastfile з ленами dev/staging/production з автоматичним інкрементом версії, code signing через match та деплоєм в TestFlight/Google Play.
• Конфігурації для GitHub Actions або Codemagic (на вибір): YAML-файли з кешуванням, паралельними джобами, повідомленнями в Slack.
• App Store Connect API Key та налаштування push-повідомлень (APNs/FCM).
• Документацію з запуску збірок та оновлення сертифікатів.
• Навчання команди: 2 години онлайн-воркшопу по роботі з пайплайном.
• Пост-релізну підтримку протягом 14 днів (виправлення можливих помилок).

Чому варто довірити налаштування нам?

Ми — команда мобільних розробників з 5+ роками досвіду в CI/CD. За цей час реалізували 50+ проєктів для iOS, Android та кроссплатформи. Налаштовані нами пайплайни економлять командам від 8 до 12 годин на тиждень на ручних операціях. Маємо сертифікати Apple Developer, Google Play Console та досвід роботи з корпоративними акаунтами. Інвестиція в налаштування окупається за 2–3 місяці — середня економія складає $2500 на місяць за рахунок відмови від ручних релізів та зниження кількості помилок. Ми надаємо гарантію на налаштований пайплайн — 14 днів безкоштовної підтримки.

Терміни та вартість

Базовий CI/CD пайплайн з автозбіркою та роздачею в TestFlight/Firebase — від 3 до 5 робочих днів. Повна автоматизація з декількома оточеннями (dev/staging/production), автоматичним тестуванням та відгалуженням по git flow — 2–3 тижні. Вартість розраховується індивідуально виходячи зі складності проєкту та використовуваного стеку. Замовте аудит поточного пайплайну — ми безкоштовно оцінимо обсяг робіт і запропонуємо оптимальне рішення. Отримайте консультацію — зв’яжіться з нами.

Wikipedia-стаття «CI/CD» та офіційна документація Fastlane.