Настройка GCP Cloud Run: деплой контейнеров с CI/CD и VPC

Настройка Cloud Run: где ломается развёртывание контейнеров

Контейнер, который локально стартует за секунды, в управляемой среде падает на первом же развёртывании — частый сценарий при переносе. Причины почти всегда одни: конфигурация окружений расходится, внутренние сервисы недоступны из новой сети, часть настроек теряется между выпусками.

Расхождение начинается с мелочей — переменные среды, смонтированные секреты, права сервисной учётной записи. Локально их подставляют вручную, в управляемой среде они берутся из описания сервиса. Если набор отличается хотя бы одним значением, приложение поднимается, но обращается не к той базе или падает на инициализации. Добавьте лимиты памяти и параллелизма — получите нестабильный запуск: одни ревизии отвечают, другие уходят в перезапуск по проверке готовности.

Недоступность внутренних сервисов — отдельная история. Контейнер не видит частную сеть по умолчанию: пока не подключён сетевой коннектор и не описаны маршруты с правилами файрвола, обращения к базе, кэшу и брокеру уходят в таймаут. Ошибки выпуска версии проявляются здесь же: трафик переводят на новую ревизию, а она ещё не готова принимать запросы — сервис отдаёт ошибки несколько минут.

Потеря конфигурации при выпуске — третья ловушка. Правки, сделанные руками в консоли, живут до следующего развёртывания: сервис перезаписывается описанием из репозитория, и переменные, права и настройки окружений откатываются. Разбираем, как это закрывается — от декларативного описания сервисов до проверок перед переключением трафика.

Что даёт управляемый запуск контейнеров

Управляемый запуск контейнеров — это когда платформа сама держит ревизии, распределяет трафик между ними и поднимает экземпляры под нагрузку, а команда описывает только образ, переменные окружения и лимиты. В Cloud Run выпуск сводится к публикации новой ревизии: она поднимается рядом с текущей, проходит проверку готовности и только потом получает трафик. Отсюда два эффекта сразу — простой сервиса при обновлении исчезает, а откат превращается в переключение трафика на предыдущую ревизию вместо повторной сборки и ручных правок.

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

Автоматическое масштабирование здесь считается от запросов, а не от занятости серверов: без трафика число экземпляров падает до нуля, при всплеске растёт в заданных границах. Границы задают заранее — предел экземпляров, конкурентность на один экземпляр, таймауты, объём памяти; иначе сервис упирается в лимиты внешней базы или квоты проекта и начинает отдавать ошибки при пике.

Изоляция трафика решается отдельно от кода приложения. Обращения к внутренним базам и очередям идут через коннектор в частную сеть, а сам сервис закрывается от публичного доступа: вход только через шлюз или внутренний балансировщик с проверкой токена. Внутренние адреса и служебные учётные записи перестают быть доступны извне, а права сводятся к конкретным ролям для конкретных сервисов.

Варианты размещения: сервис, задание, виртуальные машины

Управляемая среда снимает с команды масштабирование, обновление узлов и изоляцию, но взамен задаёт рамки: предельную длительность обработки запроса, отсутствие постоянного локального диска, поведение при простое. Поэтому режим размещения контейнеров выбирают не по привычке, а по профилю нагрузки — от этого зависит и архитектура, и то, какие отказы вообще возможны. В Cloud Run таких режимов три, и они не взаимозаменяемы.

Как выбираем на практике

Считаем профиль: длительность одной операции, есть ли входящий трафик, нужен ли диск между запусками. Если обработка укладывается в лимит управляемой среды — берём сервис, он дешевле в поддержке и сам гасит простой. Если задача длится часами — выносим её в задание, а сервис оставляем принимать запрос и ставить работу в очередь: так таймаут не рвёт вычисления на середине.

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

Этапы настройки: от аудита до передачи в поддержку

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

1. Аудит инфраструктуры. Разбираем текущую схему: как собираются образы, где лежит реестр, какие права у сервисных аккаунтов, что уже работает в проде. На выходе — карта зависимостей и список узких мест.
2. Схема окружений. Проектируем разделение dev, stage и prod: отдельные проекты, свои сервисные аккаунты, конфигурация через переменные окружения и менеджер секретов вместо значений внутри образа. Тестовый ключ больше не уедет в прод.
3. Сборка и выпуск. Собираем контейнер, публикуем в реестр, настраиваем конвейер: проверки на каждую ветку, ручное подтверждение перед продом, выпуск новой ревизии Cloud Run с постепенным переводом трафика.
4. Сетевой контур. Подключаем сервис к приватной сети: коннектор, правила исходящего трафика, доступ к базе только по внутренним адресам — база перестаёт быть видна извне.
5. Сценарии проверки. Прогоняем холодный старт, отказ ревизии, откат на предыдущую, ротацию секретов и недоступность внешней зависимости. Каждый сценарий остаётся воспроизводимым тестом, а не разовой ручной проверкой.
6. Передача в эксплуатацию. Отдаём команде схему окружений, политики доступа, метрики и оповещения, порядок отката. Разбор ведём на живом выпуске — инженеры проходят цикл своими руками.

Конфигурации и инструкции остаются в репозитории команды, поэтому поддержку можно вести и своими силами.

Комплект передачи: конфигурации, схемы, регламенты

Работы закрываются не в момент, когда сервис в Cloud Run отвечает на запросы, а когда ваша команда может выпускать и откатывать его без нас. Поэтому каждый этап заканчивается артефактом, который лежит в вашем репозитории и проверяется вместе с кодом. Ниже — то, что остаётся у заказчика после передачи.

• Комплект документации: описание сервиса, ревизий, переменных окружения и секретов — окружение поднимается из пустого проекта одной командой.
• Схема окружений: какие стенды существуют, чем отличаются по ресурсам и правам, как изменения продвигаются от разработки до продуктивного контура.
• Политики доступа: роли разработчиков, дежурных и подрядчиков, привязка сервисных аккаунтов, выдача прав через группы вместо персональных учёток.
• Регламент отката: порядок возврата на предыдущую ревизию, критерии принятия решения и ответственный за него.
• Конфигурация выпуска: сборка образа, проверки перед выкатом и правила, при которых сломанная сборка не доходит до продуктивного окружения.
• Схема сети: путь трафика от балансировщика до контейнера, границы приватного доступа, какие адреса открыты и зачем.
• Инструкция для команды: пошаговые сценарии — выпуск версии, добавление переменной, разбор упавшего деплоя, чтение логов и метрик.

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

Кейс: убрали простои при обновлении сервиса

Сервис с пиковым трафиком жил на нескольких виртуальных машинах за балансировщиком. Обновления запускали ночью в ручном окне: инженер по очереди останавливал экземпляры, поднимал новые и следил за логами.

До переезда выпуск занимал 40–50 минут, и почти каждая пятая попытка заканчивалась откатом — обычно из-за несовместимой миграции схемы. Если обновление ломало сервис в часы нагрузки, восстановление растягивалось на 20–30 минут ручных действий под давлением.

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

Откат стал переключением трафика на предыдущую ревизию. Проваленные проверки сами возвращают нагрузку на старую версию, поэтому неудачное обновление больше не требует ночного окна и ручных действий.

Результат в цифрах

После переезда выпуск занимает 6–8 минут, доля неудачных обновлений снизилась с 20% до 5%, а восстановление — секунды вместо получаса. Ночные окна убрали: выпускаем в рабочие часы по нескольку раз в неделю, и каждый выкат виден в истории ревизий с точной версией образа.

Что делать, если часть сервисов уже работает в облаке

Переносить всё сразу не нужно и обычно вредно. Рабочая схема такая: часть сервисов остаётся на текущей площадке, часть переезжает в облако, а связь между ними идёт через общую внутреннюю сеть, а не через публичный интернет. Для остальных систем при этом ничего не меняется — меняются только адреса конкретных сервисов.

Сначала строим сетевой мост: приватное соединение между площадками, непересекающиеся диапазоны адресов, маршруты до внутренних сервисов в обе стороны. Поверх — единые правила доступа: одна модель ролей, общие сервисные учётные записи, одинаковые требования к шифрованию и журналированию обращений. Сервис в Cloud Run видит базу и внутренние API так же, как видел их на прежнем размещении, — переписывать код под новый контур не приходится.

Дальше переносим по одному сервису, а не волной. На каждый — свой план миграции: какие зависимости уже доступны из облака, что остаётся на старой площадке, как переключается трафик и как вернуться назад. Порядок задаём по связности: сначала сервисы с малым числом зависимостей, затем те, что тянут за собой базы и очереди.

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

Технические сомнения: доступ, масштабирование, откат

Перед стартом работ заказчики задают одни и те же инженерные вопросы — не про сроки, а про то, как сервис поведёт себя в проде. Ниже короткие ответы, чтобы решения по инфраструктуре принимались до первой выкладки, а не после инцидента.

Как ограничивается внутренний трафик между сервисами?

Сервисы общаются по внутренним адресам, входящий публичный доступ отключается, а вызовы подтверждаются на уровне сервисных учётных записей. Снаружи открыт только тот сервис, который действительно должен быть доступен.

Как откатывается неудачная версия?

Каждая выкладка создаёт неизменяемую ревизию, и откат — это переключение трафика на предыдущую: секунды, без пересборки образа. Прежние ревизии хранятся, поэтому вернуться можно на любую из последних.

Учётные записи окружений разделяются?

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

Что происходит при обновлении работающего сервиса?

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

Обсудим задачу: соберём схему и план внедрения

Чтобы вернуться с оценкой работ и планом внедрения, а не с общими соображениями, нужны вводные по проекту. Ниже — то, что мы разбираем на первом разговоре: по этим данным собирается схема деплоя в Cloud Run, порядок этапов и сроки каждого. Если часть данных ещё не формализована — восстановим картину вместе.

• Состав сервисов: какие приложения уже в контейнерах, что запущено в Cloud Run, что осталось на виртуальных машинах и как сервисы общаются между собой.
• Репозитории и сборка: где лежит код, как устроен конвейер сборки и доставки, какие проверки обязательны перед выпуском и как часто выходят обновления.
• Окружения и доступы: сколько сред нужно (тестовая, предпродакшн, продуктивная), кто владелец облачного проекта и какие права мы получаем на настройку.
• Требования к сети: нужен ли статический внешний адрес, должен ли сервис обращаться к базе в закрытом контуре, есть ли обязательный исходящий маршрут через корпоративную сеть.
• Профиль нагрузки: пиковые запросы, допустимое время отклика, как быстро должен подниматься новый экземпляр — от этого зависят правила автомасштабирования.
• Надёжность и откат: допустимое время недоступности, порядок возврата на предыдущую версию, где хранятся секреты и кто отвечает за их смену.

Этого набора достаточно, чтобы вернуться с оценкой, разбивкой по этапам и сроками. Опишите задачу в удобном виде — перепиской или коротким созвоном: уточним детали и пришлём схему.