Как настроить конвейер развертывания на GCP с помощью Cloud Build, Container Registry и Cloud Run

Автоматическое создание и развертывание контейнеров в Cloud Run, когда изменения поступают в ваши репозитории Git.

Вступление

В этой статье мы увидим, как настроить конвейер развертывания на Google Cloud Platform на основе Cloud Build, Container Registry и Cloud Run.

Мы рассмотрим процесс настройки конвейера, который:

Следит за изменениями в определенной ветке репозитория GitHub;
После обнаружения изменений в этой конкретной ветке создается образ Docker для приложения;
Помещает образ Docker в Реестр контейнеров;
Разверните образ Docker, который будет обслуживать Cloud Run.

Предупреждение: вам необходимо иметь настроенную платежную учетную запись, чтобы следовать этому руководству. Если у вас нет кредитной карты, которую вы можете использовать, прочтите статью и оставьте любые вопросы, которые могут у вас возникнуть, в разделе комментариев ниже. Я буду рад помочь.

Облачная сборка

Cloud Build - это сервис, который выполняет ваши сборки в инфраструктуре Google Cloud Platform. Cloud Build может импортировать исходный код из Google Cloud Storage, Cloud Source Repositories, GitHub или Bitbucket, выполнять сборку в соответствии с вашими спецификациями и создавать артефакты, такие как контейнеры Docker или архивы Java.

Cloud Build выполняет вашу сборку как серию шагов сборки, где каждый шаг сборки выполняется в контейнере Docker. Шаг сборки может делать все, что можно сделать из контейнера, независимо от среды. Для выполнения своих задач вы можете либо использовать поддерживаемые шаги сборки, предоставляемые Cloud Build, либо написать свои собственные шаги сборки.

Ссылка: https://cloud.google.com/cloud-build/docs

Разрешения IAM

Чтобы наш конвейер Cloud Build работал должным образом, нам необходимо обновить учетную запись службы по умолчанию, используемую службой и идентифицированную по адресу ‹project-number› @ cloudbuild.gserviceaccount.com, добавив несколько новых разрешения. Для этого:

В верхнем левом меню выберите IAM & Admin;
Найдите учетную запись службы, идентифицированную ‹project-number› @ cloudbuild.gserviceaccount.com;
Измените учетную запись службы и добавьте роли Администратор Cloud Run и Пользователь учетной записи службы.

Администратор Cloud Run необходим, поэтому Cloud Build имеет разрешения, необходимые для развертывания службы Cloud Run; Пользователь учетной записи службы необходим, поэтому службу Cloud Run можно настроить для разрешения доступа неаутентифицированным пользователям, как описано здесь.

Реестр контейнеров

Реестр контейнеров - это частный реестр образов контейнеров, который работает в Google Cloud. Реестр контейнеров поддерживает форматы изображений Docker Image Manifest V2 и OCI.

Многие люди используют Dockerhub в качестве центрального реестра для хранения общедоступных образов Docker, но для управления доступом к вашим изображениям вам необходимо использовать частный реестр, такой как Реестр контейнеров.

Вы можете получить доступ к Реестру контейнеров через защищенные конечные точки HTTPS, которые позволяют отправлять, извлекать и управлять образами из любой системы, экземпляра виртуальной машины или вашего собственного оборудования. Кроме того, вы можете использовать инструмент командной строки Docker credential helper, чтобы настроить Docker для аутентификации напрямую с помощью реестра контейнеров.

Ссылка: https://cloud.google.com/container-registry/docs/overview

Cloud Run

Cloud Run - это управляемая вычислительная платформа, которая позволяет запускать контейнеры без сохранения состояния, которые вызываются через веб-запросы или события Pub / Sub. Cloud Run является бессерверным: он абстрагирует все управление инфраструктурой, поэтому вы можете сосредоточиться на самом важном - создании отличных приложений. Он построен на основе Knative, что позволяет вам запускать свои контейнеры либо полностью управляемыми с помощью Cloud Run, в кластере Google Kubernetes Engine, либо в локальных рабочих нагрузках с помощью Cloud Run для Anthos.

Ссылка: https://cloud.google.com/run/docs

Настроить проект GCP

Чтобы следовать этому руководству, вам потребуется доступ к проекту GCP. Для этого:

Войдите в Консоль GCP, введите имя вашего нового проекта и нажмите кнопку СОЗДАТЬ;
После создания проекта убедитесь, что он выбран в верхнем левом углу, рядом с логотипом Google Cloud Platform;
В верхнем левом меню выберите API и службы, затем нажмите кнопку ВКЛЮЧИТЬ APIS И УСЛУГИ;
Включите эти API: Cloud Build API, Google Container Registry API и Cloud Run API.

Отличная работа! Пора запачкать руки!

Образец приложения

Образец приложения, который мы будем использовать в этом руководстве, представляет собой очень простое приложение Flask. Приложение предоставляет две конечные точки:

/ health: общедоступная конечная точка для проверки работоспособности приложения;
/ hello: частная конечная точка, защищенная базовой аутентификацией. Все, что он делает, это возвращает простой JSON. Цель этой конечной точки - продемонстрировать, как мы можем использовать переменные среды в Cloud Run.

ivamluz / cloud-run-sample-flask
Этот проект представляет собой простое приложение Flask, разработанное для демонстрации того, как настроить конвейер развертывания на GCP с помощью… github.com

Пример безопасности приложения

Базовая аутентификация реализована как декоратор, сохраненный в app / secure.py. Все, что он делает, это:

Считайте значение x-api-key из запроса;
Хешируйте прочитанное значение с помощью SHA-512;
Сравните полученное хешированное значение со значением переменной среды HASHED_API_KEY (которая также хранится в форме SHA-512);
Если значения совпадают, запрос будет продолжен. В противном случае возвращается ошибка 401.

Чтобы настроить и протестировать приложение локально, выполните действия, описанные в его README-файле.

Dockerfile

Dockerfile для нашего приложения очень прост. Все, что он делает, это:

Скопируйте исходный код приложения внутрь контейнера;
Установите зависимости приложения с помощью pip;
Запустите приложение с помощью gunicorn и откройте его через заданный порт.

Настройка конвейера сборки облака

Шаги нашего конвейера определены в файле YML с именем cloudbuild.yaml. Как видите, наш конвейер состоит из трех этапов:

Первый шаг отвечает за создание и разметку образа Docker нашего приложения.
Второй шаг отвечает за отправку образа Docker, созданного на первом шаге, в Реестр контейнеров.
Третий шаг отвечает за развертывание образа Docker в Cloud Run путем указания адреса образа, помещенного в реестр контейнеров на втором шаге.

Некоторые вещи, на которые стоит обратить внимание в приведенном выше файле:

На каждом шаге можно использовать разные образы докеров. Например, на первых двух шагах мы использовали образ под названием docker; на третьем этапе мы использовали изображение под названием gcloud. Оба изображения предоставлены Google, но вы также можете загрузить свои собственные изображения в Реестр контейнеров и ссылаться на них на этапах сборки.
Мы используем некоторые переменные, такие как $ {PROJECT_ID} и $ {SHORT_SHA}. Они предоставляются Cloud Build, но, как вы можете видеть в разделе Подстановка значений переменных, также можно указать свои собственные значения. Это случай $ {_ SERVICE_NAME}, пользовательской переменной, которую мы используем для управления созданным нами образом Docker, а также для установки имени развернутой службы Cloud Run.

Настройка триггера сборки облака

Теперь, когда все готово, пора настроить триггер Cloud Build Trigger. Для этого выполните следующие действия:

В верхнем левом меню выберите Cloud Build, выберите Триггеры в левом меню, а затем нажмите кнопку Подключить репозиторий:

Выберите GitHub (приложение Cloud Build GitHub) и нажмите Продолжить:

Разрешите Google Cloud Build доступ к GitHub:

Установите приложение Google Cloud Build GitHub:

Выберите учетную запись GitHub, чтобы установить приложение Google Cloud Build GitHub:

Затем выберите репозитории:

И, наконец, подключите репозиторий GitHub к Cloud Build:

Выберите репозиторий GitHub и нажмите Создать активный триггер.

Обратите внимание, что вы не можете настроить параметры триггера во время его создания, но это возможно сделать после его создания:

Настройте триггер, как показано на изображении ниже:

Здесь мы указываем:

Название и Описание триггера;
Сборка должна запускаться всякий раз, когда данные помещаются в главную ветвь репозитория;
Что конфигурация сборки предоставляется файлом cloudbuild.yaml из нашего репозитория;
Что переменная _SERVICE_NAME из нашего cloudbuild.yaml должна быть заменена значением pipeline-demo. Как описано ранее, эта переменная используется для управления нашим сгенерированным образом Docker, а также для установки имени развернутой службы Cloud Run.

Запуск сборок

Чтобы проверить выполненную конфигурацию, у вас есть два варианта:

Зафиксируйте и отправьте любые изменения в основную ветку вашего репозитория;
Запустите триггер вручную, нажав кнопку Запустить триггер:

Чтобы увидеть свою сборку в действии, выберите Панель управления в левом боковом меню:

Для каждой настроенной сборки на панели инструментов отображаются:

Дата и время последней сборки;
Продолжительность сборки;
Описание триггера;
Ссылка на исходный репозиторий;
Хеш фиксации, для которой была запущена сборка;
Небольшая диаграмма с историей сборки Успех / Неудача;
Средняя продолжительность постройки;
Процент успехов и неудач.

Чтобы просмотреть подробные сведения о нем, щелкните ссылку, отображаемую в разделе Последняя сборка. Вы должны увидеть что-то вроде этого:

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

Просмотр зарегистрированных контейнеров

Если вы хотите видеть / управлять контейнерами, созданными вашей сборкой, вы можете сделать это, обратившись к службе реестра контейнеров из меню в верхнем левом углу:

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

Доступ к развернутому приложению

Теперь, когда приложение создано и развернуто, вы сможете получить к нему доступ через конечную точку, созданную Cloud Run. Чтобы узнать его адрес:

В консоли GCP выберите Cloud Run в верхнем левом меню;
Щелкните по названию развернутой службы;
Скопируйте URL вверху страницы:

Помните, что, как описано ранее, наше приложение предоставляет две конечные точки:

/ health: общедоступная конечная точка для проверки работоспособности приложения;
/ hello: частная конечная точка, защищенная базовой аутентификацией. Все, что он делает, это возвращает простой JSON с надписью «Hello, World». Цель этой конечной точки - продемонстрировать, как мы можем использовать переменные среды в Cloud Run.

Чтобы проверить конечную точку / health, выполните следующую команду curl:

Чтобы проверить конечную точку / hello, выполните следующую команду curl:

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

Чтобы решить эту проблему, мы можем использовать некоторые скрипты, версированные в нашем репозитории. Если вы выполнили действия по запуску и тестированию приложения локально, как описано в приложении Файл README, вы помните сценарий scripts / hash_value.py, который мы можем использовать для хеширования значений в SHA -512 форма.

Ранее в этой статье мы говорили о декораторе require_api_key, который используется для защиты нашей конечной точки / hello с помощью базовой аутентификации. Помните, что под капотом этот декоратор считывает переменную среды HASHED_API_KEY, хеширует полученное значение HTTP-заголовка x-api-key с помощью SHA-512 и сравнивает оба значения, чтобы решить следует ли разрешить выполнение запроса.

Чтобы установить переменную среды HASHED_API_KEY, выполните следующие действия :

Внутри папки скриптов выполните следующую команду:

Вернувшись в консоль GCP, выберите Cloud Run в верхнем левом меню;
Щелкните имя развернутой службы, а затем нажмите кнопку ИЗМЕНИТЬ И УСТАНОВИТЬ НОВУЮ РЕДАКЦИЮ;
В разделе «Дополнительные настройки» выберите вкладку ПЕРЕМЕННЫЕ;
Введите HASHED_API_KEY для имени и хешированное значение, созданное выше для значения:

Нажмите кнопку РАЗВЕРТИТЬ;

Подождите, пока приложение будет развернуто, и повторите его с помощью следующей команды curl:

Обратите внимание, как теперь мы получаем ответ 200, содержащий наш JSON «Hello, world».

Автоматизация настройки переменных среды

В качестве альтернативы, если у вас gcloud настроен локально, вы можете использовать сценарий scripts / set_env_vars.sh для настройки конфигурации переменной среды. Для этого выполните следующую команду из папки сценариев:

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

Уборка

Чтобы отменить изменения, сделанные во время следования этому руководству, убедитесь, что:

Удалите развернутую службу Cloud Run;
Удалите сохраненные изображения из реестра контейнеров;
Удалите настроенные триггеры Cloud Build;
Отключите все подключенные репозитории.

Последние мысли

В этом руководстве мы прошли процесс настройки конвейера развертывания на базе GitHub, Cloud Build, Container Registry и Cloud Run.

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

Создает образ Docker;
Помещает созданный образ Docker в Реестр контейнеров;
Разверните образ Docker в Cloud Run;

Мы также увидели, как использовать переменные среды в Cloud Run. Имейте в виду, что представленный здесь подход Basic Auth предназначен только для иллюстрации. Для более безопасного подхода обратите внимание на услугу Секретный менеджер, также предоставляемую Google.

Несмотря на то, что здесь использовался репозиторий GitHub, процесс настройки репозитория BitBucket очень похож. На данный момент я не знаю, планируется ли GitLab в дорожной карте службы Cloud Build.

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

Наконец, важно подчеркнуть, что в целях иллюстрации многие действия выполнялись вручную. В реальном сценарии это определенно стоило бы максимально автоматизировать процесс, используя такие инструменты, как Terraform или Deployment manager, gcloud, bash и т. Д. Кроме того, также важно убедиться, что у вас правильно реализованы и запущены автоматизированные тесты, чтобы убедиться в надежности вашего трубопровода.

Надеюсь, вы хорошо провели время, читая эту статью, и по ходу узнали кое-что нового.

Удачного кодирования!