Запуск контейнеров на Google Cloud Run

Быстрые ссылки

• Какой сервис выбрать?
• Начало работы с Cloud Run

Какой сервис выбрать?

У вас, по сути, две основные опции для запуска контейнеров в GCP. Cloud Run — простой и удобный вариант, который подойдёт для большинства приложений. Службы в Cloud Run запускаются как «сервисы» — каждому экземпляру выделяется настраиваемый объём памяти и один или несколько CPU. Можно назначать собственные домены и пробрасывать порты.

Cloud Run хорошо подходит, если вы хотите быстро развернуть приложение без управления виртуальными машинами (Compute Engine) или полноценного Kubernetes-кластера. Это удобный заменитель AWS ECS для задач типа веб‑приложений, API и фоновых процессов, которые запускаются в контейнере.

Если вам нужен детальный контроль оркестрации, специальные политики автоскейлинга, сложные сетевые политики или мультиконтейнерные распоряжения с зависимостями, лучше смотреть в сторону Google Kubernetes Engine (GKE) — управляемого Kubernetes.

Google предлагает реестр образов — Google Container Registry (GCR) и Artifact Registry — для хранения образов, которые затем можно развернуть в Cloud Run или в GKE.

Важно: если приложение держит длительные соединения, выполняет тяжёлые вычисления без возможности горизонтального масштабирования или зависит от низкоуровневых сетевых настроек, Cloud Run может быть не лучшим выбором.

Когда выбирать Cloud Run — быстрые рекомендации

• Выгодно для REST/HTTP сервисов и небольших фоновых задач.
• Вы хотите минимизировать DevOps‑операции и не управлять кластерами.
• Нужна автоматическая масштабируемость на входящую нагрузку.

Когда Cloud Run не подойдёт:

• Нужна сложная межконтейнерная коммуникация или StatefulSet.
• Требуются специфичные сетевые плагины или кастомные драйверы.
• Нужно контролировать отдельные узлы и их привязку к оборудованию.

Альтернативы и сравнение

• Cloud Run — серверлес, упрощённый деплой контейнера, автоскейл по запросам.
• Google Kubernetes Engine — полноценный Kubernetes, для сложной оркестрации и кастомных политик.
• Compute Engine + Docker — для полного контроля над виртуальными машинами.

Факт‑бокс: типичные параметры

• Память на экземпляр: настраивается от сотен мегабайт до нескольких гигабайт.
• CPU: обычно 1‑2 vCPU на экземпляр, в некоторых конфигурациях больше.
• Масштабирование: по числу одновременных запросов или экземпляров; можно ограничить максимум.

Начало работы с Cloud Run — пошаговая инструкция

1. Откройте Google Cloud Console и выберите раздел Cloud Run. Нажмите “Create Service” (Создать службу).

2. Выберите регион исполнения и задайте имя службы.

3. Настройте доступ: можно сделать сервис публичным или ограничить доступ через Cloud IAM. Для внутренних сервисов включите проверку доступа и назначьте роли сервисным аккаунтам или пользователям.

Примечание: при включённом IAM доступе убедитесь, что у аккаунтов есть роль run.invoker для вызова сервиса.

4. Укажите URL образа контейнера — он может храниться в Docker Hub, Google Container Registry или Artifact Registry.

5. В “Advanced Settings” можно задать порт контейнера, команду входа (entrypoint) и аргументы.

6. В разделе “Capacity” укажите предел одновременных запросов на экземпляр, таймаут запроса, число CPU и объём памяти на экземпляр. Оставьте эти параметры минимальными для экономии, увеличьте при необходимости.

7. Настройте автоскейлинг: Cloud Run масштабирует автоматически, но вы можете установить максимальное число экземпляров, если хотите ограничить расходы.

8. Нажмите “Create”. После развертывания в консоли появится URL сервиса, по которому приложение будет доступно. Можно связать собственный домен через CNAME или через настройку домена в Cloud Run.

Если перейти по URL, вы увидите, что сервис работает.

Мини‑методология перед деплоем (чек‑лист)

• Соберите контейнер локально и проверьте его с помощью docker run.
• Убедитесь, что приложение слушает порт, заданный в конфигурации (обычно 8080).
• Протестируйте обработку SIGTERM и корректное завершение работы (graceful shutdown).
• Настройте переменные окружения и секреты через Secret Manager или переменные Cloud Run.
• Настройте мониторинг и логирование (Stackdriver/Cloud Logging).

Роли и чек‑листы

Для разработчика:

• Убедиться, что контейнер статичен, конфигурация извлекается из переменных окружения.
• Обработать завершение процесса и таймауты.

Для DevOps:

• Настроить репозиторий образов и CI/CD (push образа и автоматический деплой).
• Мониторить метрики: ошибки 5xx, задержки, использование CPU/памяти.

Для ответственного за безопасность:

• Ограничить доступ через IAM, использовать TLS для доменов.
• Проверить уязвимости образов и актуализировать зависимости.

Критерии приёмки

• Сервис стартует и отвечает по HTTP 200 для тестового запроса.
• Логи показывают корректное завершение при SIGTERM.
• Пределы памяти/CPU не превышаются при нормальной нагрузке.
• Автоматическое масштабирование работает и увеличивает/уменьшает число экземпляров в ответ на нагрузку.

Когда Cloud Run не подойдёт — примеры

• Приложение требует постоянной привязки к локальной файловой системе экземпляра.
• Необходимы специализированные сетевые плагины, которые доступны только в Kubernetes.
• Нужно управлять состоянием кластера или использовать StatefulSet с длительным хранением данных.

Короткий словарь

• Образ (image) — готовый контейнерный артефакт для запуска.
• Экземпляр (instance) — отдельный процесс/контейнер, выполняющий ваш образ.
• Автоскейлинг — автоматическое увеличение/уменьшение числа экземпляров.

Итог

Cloud Run — быстрый и удобный способ запускать контейнеры без управления кластером. Он хорошо подходит для статeless HTTP‑сервисов и API, при этом даёт гибкие настройки памяти, CPU и авто‑масштабирования. Если нужны сложные сценарии оркестрации, стоит рассмотреть GKE. Следуйте чек‑листу перед деплоем, настраивайте IAM для безопасности и мониторьте приложение в проде.

Важно: тестируйте поведение при завершении процессов и настройте лимиты по памяти/CPU, чтобы избежать неожиданных рестартов.

Ключевые действия: подготовить образ, указать репозиторий, задать параметры instance/capacity, протестировать и настроить мониторинг.