google-agents-cli-deploy

Официальный skill Google ADK описывает повторяемый путь от подготовленного проекта AI-агента к dev- и production-развёртыванию в Google Cloud. Для команд используется agents-cli; исходник отдельно требует установить его через uv tool install google-agents-cli и связывает этот skill с Agent Runtime, Cloud Run и GKE. Документ не смешивает деплой с написанием кода агента, оценкой качества или созданием проекта: для этих задач он отсылает к отдельным skills из той же линейки. Главное решение перед запуском — выбрать целевую платформу. Agent Runtime — управляемая среда для ADK-агентов с автоматическим масштабированием, нативным сервисом сессий и сетевыми возможностями VPC-SC и PSC-I. В этом варианте проект разворачивается как контейнер, Agent Engine собирает образ из обязательного Dockerfile, а единое FastAPI-приложение использует passthrough-маршрут /api. Cloud Run подходит, когда нужны самостоятельная настройка числа инстансов, concurrency, CPU, VPC egress, IAP и правил ingress. GKE даёт полный контроль Kubernetes-среды, включая Autopilot, manifests, Workload Identity и HPA. Матрица в источнике показывает компромисс: управляемый runtime требует меньше операций, Cloud Run оставляет больше инфраструктурной свободы, а GKE требует более глубоких Kubernetes-навыков. Для dev-deployment workflow сначала определяет target и при необходимости выполняет scaffold enhance, затем skill требует сообщить человеку, что оценки и тесты достигли порогов, и дождаться явного разрешения перед agents-cli deploy. Для сложной конфигурации Cloud Run предусмотрен dry-run, который печатает полный gcloud-вызов и позволяет добавить аргументы вручную. Если проект определяется автоматически, в неинтерактивном запуске нужен --no-confirm-project. Agent Runtime не управляется через отдельную команду gcloud: для старта используется agents-cli deploy, а для проверки — agents-cli deploy --status. Долгий запуск можно отправить с --no-wait; документ указывает, что такая операция может занимать 5–10 минут. Отдельный раздел посвящён sizing. В типовых настройках указаны 1 CPU, 4 GiB памяти, concurrency 8, один минимальный и десять максимальных инстансов. Контейнер обслуживает запросы одним асинхронным процессом uvicorn, поэтому пропускную способность обычно увеличивают горизонтальным масштабированием, concurrency и max-instances, а не добавлением worker-процессов. Память считается первым ограничением: одновременно ожидающие запросы удерживают рабочий набор, историю, RAG-фрагменты и буфер ответа. Поэтому повышение concurrency без увеличения memory может привести к OOM. Значение 8 считается консервативным для memory-heavy или multimodal агента; диапазон 16–32 и выше источник допускает только после load-тестов. Для GKE те же sizing-флаги не применяются: размер задаётся Terraform-manifest и HorizontalPodAutoscaler. Production CI/CD вынесен в отдельные reference-файлы, где описаны prerequisites, Workload Identity Federation, стадии pipeline и approval. В scaffolded-проекте app_sa является runtime-идентичностью отдельного окружения, а cicd_runner_sa — идентичностью GitHub Actions или Cloud Build в CI/CD-проекте; последней нужны права и в staging, и в production. Документ связывает типовые 403 с конкретными причинами: deployment role для Cloud Run, iam.serviceAccountUser для app_sa, secretmanager.secretAccessor, roles/cloudsql.client и доступом Cloud Run service agent к Artifact Registry. Для CI/CD также указан доступ secretmanager.admin сервисного аккаунта Cloud Build к GitHub-токену в Secret Manager. Перед deployment должны быть включены cloudbuild.googleapis.com, secretmanager.googleapis.com и run.googleapis.com. Секреты для API-учётных данных skill предлагает хранить в Secret Manager, а не передавать обычными переменными окружения. После запуска предусмотрены curl-проверки, load-тесты и чтение статуса. Для восстановления документ содержит rollback и recovery-процедуры; отдельные разделы описывают Cloud Run, Agent Runtime, GKE, Terraform, observability и Agent Gateway. Ограничение карточки принципиальное: skill перечисляет команды, роли и порядок действий, но не выдаёт IAM-доступ, не подтверждает настройки конкретного проекта, не заменяет load-тест и не является security-аудитом. Перед реальным изменением нужно сверить проект, регион, Dockerfile, роли, секреты и approval-политику конкретной среды.