Настройка serverless контейнеров: Fargate, Cloud Run, ACI

Мы настраиваем serverless контейнеры на трёх ведущих платформах: AWS Fargate, GCP Cloud Run и Azure Container Instances. Вы привозите Docker-образ — мы поднимаем инфраструктуру, которая масштабируется по нагрузке, не простаивает и не требует ручного управления нодами. Команды часто сталкиваются с проблемами холодного старта (1–5 секунд для Cloud Run, если не держать прогретые инстансы), сетевыми задержками при доступе к приватным ресурсам и перерасходом ресурсов из-за неправильной конфигурации контейнеров. Наш опыт — более 50 проектов по миграции на эти сервисы. Мы видели, как неоптимальный выбор платформы увеличивает счёт за облако на 30–50%, и знаем, как этого избежать. Serverless computing — это не просто тренд, а экономия до 70% затрат на инфраструктуру.

Три главных игрока работают по-разному, и выбор между ними часто определяется не техническими характеристиками, а тем, где уже живёт ваша инфраструктура. Разберём их сильные стороны и узкие места.

Как выбрать платформу для вашего сценария?

AWS Fargate: интеграция в экосистему

Fargate работает через ECS или EKS. Без ECS/EKS кластера Fargate не запустить — это важно понимать. Сам по себе Fargate не умеет принимать HTTP-трафик, нужен ALB.

Главное преимущество Fargate — нативная интеграция с AWS-сервисами: IAM Task Roles дают безопасный доступ к S3/DynamoDB/Secrets Manager без credentials в переменных, VPC-native networking, CloudWatch Logs без дополнительной настройки, Service Connect для service mesh между сервисами.

Для stateful задач — EFS mount в Fargate задачу. Persistent storage без управления EBS.

Ограничения: нет поддержки привилегированных контейнеров, нет host networking mode, минимальная поддержка GPU (только в ECS, не EKS). Если нужен --privileged — только EC2 launch type.

GCP Cloud Run: самый простой запуск

Cloud Run — самый низкий порог входа среди трёх. gcloud run deploy myservice --image gcr.io/my-project/myimage --region us-central1 — и сервис запущен с публичным HTTPS URL.

Особенность Cloud Run — масштабирование до нуля. При отсутствии трафика инстансов нет, стоимость = 0. Для dev-окружений, внутренних инструментов, нерегулярных сервисов — идеально. Для production с требованием latency < 200ms — учитываем cold start: первый запрос к холодному инстансу занимает 1–5 секунд в зависимости от размера образа и runtime.

Для снижения cold start — --min-instances 1 держит один прогретый инстанс всегда. Стоимость при idle для одного инстанса Cloud Run — небольшая, но ненулевая.

Cloud Run поддерживает --concurrency — количество одновременных запросов на один инстанс (до 1000). Это радикально отличает его от Lambda (один запрос — один инстанс): один Cloud Run инстанс может обслуживать сотни одновременных запросов.

# cloud-run-service.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: myapp
  annotations:
    run.googleapis.com/ingress: all
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "1"
        autoscaling.knative.dev/maxScale: "100"
        run.googleapis.com/cpu-throttling: "false" # CPU не throttle вне запросов
    spec:
      containerConcurrency: 80
      containers:
        - image: gcr.io/my-project/myapp:latest
          resources:
            limits:
              cpu: "1"
              memory: "512Mi"
          env:
            - name: DB_URL
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: url

cpu-throttling: false — CPU доступен всегда, а не только во время обработки запроса. Нужно для фоновых задач (очистка кэша, отправка метрик) внутри инстанса.

Azure Container Instances: быстрый запуск, без оркестрации

ACI — самый примитивный из трёх. Это просто запуск контейнера без встроенной оркестрации и автоскейлинга. Нет встроенного HTTPS, нет Load Balancer из коробки, нет автоматического масштабирования.

ACI пригодится для сценариев, где оркестрация не нужна: разовые batch задачи (запустить, дождаться завершения, убить), сайдкары в CI/CD пайплайнах, dev-окружения по требованию, тестирование образов.

Для production HTTP-сервисов ACI без дополнительной надстройки (Application Gateway, AGIC) не подходит.

Почему serverless контейнеры выгоднее виртуальных машин?

Виртуальные машины требуют управления ОС, мониторинга патчей, резервирования. Serverless контейнеры экономят до 40% затрат на администрирование. Вы платите только за потреблённые ресурсы — без оплаты простоев. В итоге общая стоимость владения снижается на 40–70% по сравнению с VM-инфраструктурой. Чтобы оценить экономию для вашего проекта, закажите аудит — мы подготовим детальный расчёт.

Сетевая интеграция

Все три платформы поддерживают private networking:

• Fargate: задача запускается в VPC, получает ENI с приватным IP. Security Groups управляют входящим/исходящим трафиком.
• Cloud Run: VPC Connector или Direct VPC Egress для доступа к приватным ресурсам (Cloud SQL, Memorystore). Входящий трафик через Load Balancer или напрямую через IAM.
• ACI: виртуальная сеть через Azure VNet интеграцию.

Управление секретами

Общий принцип для всех: не хранить секреты в переменных окружения в конфигурации деплоя.

• Fargate: Secrets Manager или SSM Parameter Store через ECS Task Definition secrets field.
• Cloud Run: Secret Manager через volume mount или environment variable reference.
• ACI: Key Vault через managed identity.

Как мы это делаем: пошагово

1. Аудит и выбор платформы. Анализируем нагрузку, требования к latency, бюджет, текущее облачное окружение.
2. Проектирование сети. Настраиваем VPC, private endpoints, security groups, VPC Connector.
3. Настройка CI/CD. Интегрируем GitLab CI или GitHub Actions с Terraform-деплоем.
4. Развёртывание и тестирование. Проверяем масштабирование (HPA, concurrency), холодный старт, сетевую связность.
5. Мониторинг и документация. Устанавливаем Prometheus/Grafana, создаём runbook и обучаем команду.

Что входит в нашу работу

• Аудит текущей инфраструктуры и выбор платформы
• Настройка CI/CD пайплайна (GitLab CI, GitHub Actions, Cloud Build)
• Конфигурация сети: VPC, private endpoints, security groups
• Развёртывание с автоскейлингом (HPA, конфигурация concurrency)
• Интеграция с мониторингом (Prometheus/Grafana, CloudWatch)
• Документация runbook и обучение команды
• Поддержка после запуска (SLA — по запросу)

Сравнение платформ

Cloud Run масштабируется до нуля, что даёт экономию до 70% по сравнению с Fargate при непостоянной нагрузке. Для стабильного трафика Fargate с ALB надёжнее и предсказуемее.

Сроки и сложность настройки

Оценим ваш проект и подберём оптимальное решение. Свяжитесь с нами — получите консультацию и расчёт стоимости за 1 день. Закажите аудит инфраструктуры — мы подберём подходящую платформу.