cloud-run-basics

Официальный skill Google Cloud Run Basics — это проверяемая карта выбора ресурса и подготовки deployment для трех сценариев Cloud Run. Материал описывает Cloud Run как полностью управляемую платформу, где не требуется самостоятельно поддерживать базовую инфраструктуру. Он разделяет ресурсы по характеру нагрузки: services отвечают на HTTP-запросы через стабильную конечную точку, jobs выполняют задачи до завершения, а worker pools обслуживают постоянно работающие фоновые процессы с pull-моделью. Такое разделение полезно на этапе проектирования: HTTP API и веб-приложение относятся к service, пакетную или расписанную обработку — к job, а непрерывный consumer для Kafka, Pub/Sub pull или RabbitMQ — к worker pool. Это не декоративная классификация: у трех ресурсов разные команды управления и разные требования к процессу. Для service skill отдельно фиксирует обязательный контракт запуска. Развернутый код должен слушать адрес 0.0.0.0, а порт брать из переменной окружения PORT; если переменная не задана, в материале указан порт 8080 по умолчанию. Привязка только к 127.0.0.1 приводит к сбою запуска, поэтому этот пункт нужно проверить до поиска проблем в маршрутизации или healthcheck. Service можно развернуть из готового container image либо из исходников. Для source deployment материал показывает путь через gcloud run deploy с флагом source: Cloud Run использует buildpacks и Cloud Build, а в варианте с Dockerfile собирает контейнер на основе проекта. Для worker pool описан аналогичный source-путь через gcloud run worker-pools deploy. При deployment из image нужно передать ссылку на образ; для Artifact Registry допускаются тег или точный digest, а для Docker Hub Google рекомендует учитывать кэширование образов через Artifact Registry remote repository. Перед первым запуском skill предлагает проверить доступность Cloud Run Admin API и Cloud Build API. Для deployment в проекте перечислены роли Cloud Run Admin, Cloud Run Source Developer, Service Account User для service identity и Logs Viewer. Для сборки исходников Cloud Build также требуется роль Cloud Run Builder у Cloud Build service account. Эти проверки помогают отличить ошибку конфигурации проекта от ошибки приложения. Если действует организационная политика, запрещающая неаутентифицированные вызовы, запрос к private service нужно тестировать по отдельному сценарию Google для private services, а не считать отказ публичного HTTP-запроса поломкой контейнера. Для jobs материал дает отдельную последовательность создания и запуска. Job можно создать командой gcloud run jobs create или задеплоить через gcloud run jobs deploy, затем выполнить отдельно командой gcloud run jobs execute. Флаг execute-now запускает выполнение сразу после создания. Число tasks может быть от 1 до 10 000; каждой задаче Cloud Run передает индексы CLOUD_RUN_TASK_INDEX и CLOUD_RUN_TASK_COUNT. Для отказоустойчивости можно задать max-retries от 0 до 10: после превышения лимита неудача задачи помечает весь job как failed. Для длительности предусмотрен task-timeout: значение по умолчанию — 10 минут, верхний предел — 168 часов, а для GPU-задач в источнике указан предел 1 час. Parallelism ограничивает число задач, работающих одновременно. Эти параметры позволяют явно связать размер пакетной работы, стоимость параллельного выполнения и ожидаемое время завершения, но сами по себе не гарантируют корректность повторного запуска: идемпотентность обработки остается обязанностью приложения. Worker pool предназначен для постоянной фоновой нагрузки и разворачивается из image либо исходников. После успешного deployment Cloud Run показывает сведения о revision. Для source deployment используются buildpacks и Cloud Build, поэтому проекту все равно нужны корректные роли и доступ к сборочному процессу. При сбое deployment официальный материал предлагает сначала определить класс проблемы: IAM или permissions, crash on boot или healthcheck, native dependency для Node или Python. Для быстрой диагностики runtime-ошибки он указывает чтение свежих записей Cloud Logging через фильтр resource.labels.service_name и ограничение количества строк. Если native dependency ломается при варианте без сборки, рекомендуемый в skill путь — вернуться к source deployment через buildpacks, чтобы расширение собиралось под Linux. Этот skill полезен как стартовый чек-лист для инженера, который выбирает между service, job и worker pool, готовит минимальные IAM-права и проверяет команду gcloud до deployment. Он не заменяет документацию конкретного приложения, настройки сети, секретов или бизнес-логики и не доказывает, что выбранный ресурс подходит для любой нагрузки. Для точного синтаксиса CLI, клиентских библиотек, MCP-интеграции, IAM и поведения autoscaling исходный репозиторий направляет к отдельным reference-файлам и официальной документации Google Cloud. Поэтому практический сценарий работы такой: сначала определить тип ресурса и модель завершения, затем включить API и проверить роли, после этого проверить контракт PORT и адрес прослушивания, выполнить deployment, получить revision или execution status и только затем разбирать логи приложения.