Построение пайплайна CI/CD с использованием serverless-продуктов

Вы можете построить пайплайн непрерывной интеграции и непрерывной поставки (CI/CD) с использованием serverless-продуктов.

В качестве примера проекта будет использовано веб-приложение, реализованное на Django, которое имитирует корзину товаров интернет-магазина. В базе данных хранятся описания товаров, а состояние корзины товаров сервис хранит в сессии пользователя. Django-приложение разворачивается в контейнере Serverless Containers, при этом секреты безопасно доставляются в приложение с помощью сервиса Yandex Lockbox. Yandex API Gateway принимает запросы от пользователей и перенаправляет их в контейнер приложения.

Для проекта используются два окружения:

• prod — продакшн, доступный пользователям.
• testing — тестовое, используется для проверки приложения перед релизом в prod.

Для каждого из окружений создается отдельный каталог в Yandex Cloud, а так же отдельный набор статических ресурсов — БД, сервисные аккаунты и т. д. Таким образом все окружения изолированы друг от друга на уровне настроек Yandex Identity and Access Management.

Дополнительно используется общий каталог infra с реестром Yandex Container Registry — в него публикуются все собранные Docker-образы приложения. Публикация образов осуществляется от отдельного сервисного аккаунта builder. Сервисные аккаунты окружений prod и testing имеют ограниченные права в каталоге infra и могут только скачивать Docker-образы.

Чтобы построить пайплайн CI/CD с использованием serverless-продуктов:

1. Создайте инстанс GitLab.
2. Настройте GitLab.
3. Создайте GitLab Runner.
4. Загрузите файлы в репозиторий GitLab.
5. Создайте переменные окружения GitLab.
6. Создайте файл конфигурации сценария CI.
7. Проверьте результат.

Если созданные ресурсы вам больше не нужны, удалите их.

Перед началом работыПеред началом работы

Скачайте проектСкачайте проект

Клонируйте репозиторий yc-serverless-gitlab-ci-cd с помощью Git:

git clone https://github.com/yandex-cloud-examples/yc-serverless-gitlab-ci-cd.git

Установите дополнительные зависимостиУстановите дополнительные зависимости

Установите в локальном окружении:

• Интерфейс командной строки Yandex Cloud.

• Утилиту потоковой обработки JSON-файлов jq.

• Утилиту потоковой обработки YAML-файлов yq.

• Python версии 3.8 или выше.

• Библиотеки Python, перечисленные в файле проекта application/requirements.txt:

  python -m pip install -r ./application/requirements.txt
  

Подготовьте инфраструктуруПодготовьте инфраструктуру

1. Перейдите в директорию с проектом и запустите скрипт bootstrap.sh, указав идентификатор вашего облака:

   YC_CLOUD_ID=<идентификатор_облака> ./bootstrap.sh
   

   Этот скрипт развернет базовую инфраструктуру и создаст YAML-файлы в директории config с описанием созданных ресурсов. Вы можете отредактировать скрипт, чтобы создать дополнительные каталоги с нужными ресурсами. Например, добавить еще одно тестовое окружение.

   Важно

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

2. Создайте сервисные аккаунты:

   • Сервисный аккаунт для ресурсов с ролью editor на каталог, в котором создается кластер Yandex Managed Service for Kubernetes. От его имени будут создаваться ресурсы, необходимые кластеру Managed Service for Kubernetes.
   • Сервисный аккаунт для узлов с ролью container-registry.images.puller на каталог с реестром Docker-образов. От его имени узлы будут скачивать из реестра необходимые Docker-образы.

   Вы можете использовать один и тот же сервисный аккаунт для обеих операций.

3. Создайте кластер Managed Service for Kubernetes и группу узлов. При создании кластера укажите ранее созданные сервисные аккаунты для ресурсов и узлов.

4. Настройте группы безопасности для работы кластера Managed Service for Kubernetes.

5. Настройте группу безопасности для работы инстанса Yandex Managed Service for GitLab.

Создайте инстанс GitLabСоздайте инстанс GitLab

Создайте инстанс Managed Service for GitLab или виртуальную машину с образом GitLab в той же облачной сети, где расположен кластер Managed Service for Kubernetes.

Настройте GitLabНастройте GitLab

Чтобы настроить GitLab и подготовить процесс непрерывной интеграции (Continuous Integration, CI), создайте новый проект и введите параметры для авторизации в CI:

Создайте GitLab RunnerСоздайте GitLab Runner

Чтобы запускать задачи сборки в кластере Yandex Managed Service for Kubernetes, создайте GitLab Runner.

После установки вы можете запускать автоматизированные сборки внутри своего кластера Managed Service for Kubernetes.

Подробнее про установку и настройку GitLab Runner читайте в документации GitLab.

Загрузите файлы в репозиторий GitLabЗагрузите файлы в репозиторий GitLab

1. Добавьте SSH-ключ для безопасного доступа к GitLab.

2. Склонируйте репозиторий gitlab-test с помощью SSH.

3. Скопируйте все файлы из репозитория yc-serverless-gitlab-ci-cd в gitlab-test.

4. Перейдите в директорию gitlab-test.

5. Проиндексируйте новые файлы:

   git add .
   

6. Сделайте коммит:

   git commit -m "Add project files"
   

7. Отправьте изменения в репозиторий gitlab-test:

   git push
   

Создайте переменные окружения GitLabСоздайте переменные окружения GitLab

1. На панели слева в GitLab перейдите в раздел Settings и во всплывающем списке выберите пункт CI/CD.

2. Нажмите кнопку Expand напротив пункта Variables.

3. Добавьте переменные окружения с выключенной опцией защиты. Все необходимые переменные и их значения были выведены в конце выполнения скрипта bootstrap.sh:

   • cloud_id — идентификатор вашего облака.
   • CI_REGISTRY — идентификатор реестра Container Registry в каталоге infra с префиксом cr.yandexcloud.kz/.
   • CI_REGISTRY_KEY — ключ сервисного аккаунта builder.
   • cart_prod — имя продакшн каталога в Yandex Cloud.
   • DOCAPI_ENDPOINT_prod — Document API эндпоинт БД Yandex Managed Service for YDB в каталоге prod.
   • PROD_SA_ID — идентификатор сервисного аккаунта deployer в каталоге prod.
   • SA_PROD_DEPLOYER_PRIVATE_KEY — ключ сервисного аккаунта deployer в каталоге prod.
   • prod_container_id — идентификатор контейнера Serverless Containers в каталоге prod.
   • cart_testing — имя тестового каталога в Yandex Cloud.
   • DOCAPI_ENDPOINT_testing — Document API эндпоинт БД Managed Service for YDB в каталоге testing.
   • TESTING_SA_ID — идентификатор сервисного аккаунта deployer в каталоге testing.
   • SA_TESTING_DEPLOYER_PRIVATE_KEY — ключ сервисного аккаунта deployer в каталоге testing.

   Для добавления переменной:

   1. Нажмите кнопку Add variable.
   2. В появившемся окне в поле Key укажите имя переменной, в поле Value — значение переменной.
   3. Выключите опцию Protect variable.
   4. Нажмите кнопку Add variable.

Создайте файл конфигурации сценария CIСоздайте файл конфигурации сценария CI

1. Откройте проект gitlab-test.

2. В строке навигации по репозиторию нажмите кнопку и в выпадающем меню выберите пункт New file.

3. Назовите файл .gitlab-ci.yml и добавьте в него этапы сборки:

   .gitlab-ci.yml

   stages:
     - build
     - deploy-test-env
     - test
     - delete-test-env
     - release
   
   # Сборка образа контейнера.
   build-job:
     stage: build
   # Использование kaniko для создания контейнера внутри контейнера для большей безопасности.
     image:
       name: gcr.io/kaniko-project/executor:debug
       entrypoint: [""]
     script:
       - mkdir -p /kaniko/.docker
   # Отправка образа контейнера в реестр. Образ отмечен хэшем коммита.
       - echo "{\"auths\":{\"$CI_REGISTRY\":{\"auth\":\"$(echo -n "json_key:${CI_REGISTRY_KEY}" | base64 | tr -d '\n' )\"}}}" > /kaniko/.docker/config.json
       - >-
         /kaniko/executor
         --context "${CI_PROJECT_DIR}/application"
         --dockerfile "${CI_PROJECT_DIR}/application/Dockerfile"
         --destination "${CI_REGISTRY}/${CI_PROJECT_PATH}:${CI_COMMIT_SHORT_SHA}"
   
   # Развертывание тестовой среды с использованием встроенного образа контейнера.
   deploy-test-env-job:
     stage: deploy-test-env
     image: alpine:3.15
     script:
   # Установка инструментов.
       - apk add -q --no-cache bash curl jq gettext
       - apk add yq --repository=http://dl-cdn.alpinelinux.org/alpine/edge/community
       - curl --fail -silent --location --remote-name https://storage.yandexcloud.net/yandexcloud-yc/install.sh
       - bash install.sh -i /usr/local/yandex-cloud -n
       - ln -s /usr/local/yandex-cloud/bin/yc /usr/local/bin/yc
    # Аутентификация с помощью ключа сервисного аккаунта.
       - echo "$SA_TESTING_DEPLOYER_PRIVATE_KEY" > key.json
       - yc config profile create sa-profile
       - yc config set service-account-key key.json
   # Установка переменных для развертывания API Gateway и создание контейнера.
       - export sa_id=$TESTING_SA_ID
       - export container_id=$(yc serverless container create --name testing --cloud-id ${cloud_id} --folder-name ${cart_testing} | yq .id)
   # Развертывание ревизии.
       - yc serverless container revision deploy --container-name testing --image "${CI_REGISTRY}/${CI_PROJECT_PATH}:${CI_COMMIT_SHORT_SHA}" --cores 1 --memory 512mb --concurrency 1 --execution-timeout 10s --cloud-id ${cloud_id} --folder-name ${cart_testing} --service-account-id ${TESTING_SA_ID} --environment DOCAPI_ENDPOINT=${DOCAPI_ENDPOINT_testing},DB_TABLE_PREFIX='' --secret environment-variable=AWS_ACCESS_KEY_ID,name=cart-app,key=AWS_ACCESS_KEY_ID --secret environment-variable=AWS_SECRET_ACCESS_KEY,name=cart-app,key=AWS_SECRET_ACCESS_KEY --secret environment-variable=SECRET_KEY,name=cart-app,key=SECRET_KEY
   # Настройка шаблона и развертывание API Gateway.
       - (cat ${CI_PROJECT_DIR}/apigw.yaml.j2 | envsubst) > apigw.yaml
       - cat apigw.yaml
       - yc serverless api-gateway create --name testing --spec=apigw.yaml --description "created from gitlab CI" --cloud-id ${cloud_id} --folder-name ${cart_testing}
       - mkdir output
       - export gwdomain=$(yc serverless api-gateway get testing --cloud-id ${cloud_id} --folder-name ${cart_testing} | yq .domain)
       - echo "https://"$gwdomain>output/gwurl
     artifacts:
       paths: [output/]
   
   e2e-test-job:
     stage: test
     image: alpine:3.15
     script:
       - apk add -q --no-cache bash curl
       - apk add yq --repository=http://dl-cdn.alpinelinux.org/alpine/edge/community
       - cat output/gwurl
       - export gwurlvar=$(cat output/gwurl)
       - curl $gwurlvar
   
   load-test-job:
     stage: test
     image: alpine:3.15
     script:
       - echo "Here goes load testing commands"
       - echo "Might even invoke bash with prepared bash script"
       - echo "Hello!"
   
   delete-test-env-job:
     stage: delete-test-env
     image: alpine:3.15
     script:
       - apk add -q --no-cache bash curl jq gettext yq
       - curl --fail --silent --location --remote-name https://storage.yandexcloud.net/yandexcloud-yc/install.sh
       - bash install.sh -i /usr/local/yandex-cloud -n
       - ln -s /usr/local/yandex-cloud/bin/yc /usr/local/bin/yc
       - echo "$SA_TESTING_DEPLOYER_PRIVATE_KEY" > key.json
       - yc config profile create sa-profile
       - yc config set service-account-key key.json
       - yc serverless api-gateway delete testing --cloud-id ${cloud_id} --folder-name ${cart_testing}
       - yc serverless container delete testing --cloud-id ${cloud_id} --folder-name ${cart_testing}
   
   release-job:
     stage: release
     image: alpine:3.15
     script:
       - apk add -q --no-cache bash curl jq gettext
       - curl --fail --silent --location -remote-name https://storage.yandexcloud.net/yandexcloud-yc/install.sh
       - bash install.sh -i /usr/local/yandex-cloud -n
       - ln -s /usr/local/yandex-cloud/bin/yc /usr/local/bin/yc
       - echo "$SA_PROD_DEPLOYER_PRIVATE_KEY" > key.json
       - yc config profile create sa-profile
       - yc config set service-account-key key.json
       - yc serverless container revision deploy --container-name prod --image "${CI_REGISTRY}/${CI_PROJECT_PATH}:${CI_COMMIT_SHORT_SHA}" --cores 1 --memory 512mb --concurrency 1 --execution-timeout 10s --cloud-id ${cloud_id} --folder-name ${cart_prod} --service-account-id ${PROD_SA_ID} --environment DOCAPI_ENDPOINT=${DOCAPI_ENDPOINT_prod},DB_TABLE_PREFIX='' --secret environment-variable=AWS_ACCESS_KEY_ID,name=cart-app,key=AWS_ACCESS_KEY_ID --secret environment-variable=AWS_SECRET_ACCESS_KEY,name=cart-app,key=AWS_SECRET_ACCESS_KEY --secret environment-variable=SECRET_KEY,name=cart-app,key=SECRET_KEY
       - container_id=${prod_container_id}
   # Создание продакшн среды.
     environment:
       name: production/$CI_COMMIT_SHORT_SHA
   

4. Напишите комментарий к коммиту в поле Commit message: CI scripts.

5. Нажмите кнопку Commit changes.

В файле .gitlab-ci.yml описаны следующие этапы сценария CI:

• build — сборка Docker-образа с использованием Dockerfile и загрузка образа в Container Registry.
• deploy-test-env — тестовое развертывание приложения. Дополнительно описан, но не использован механизм artifacts для передачи данных из одного этапа в другой. При необходимости настройте его.
• test — тестирование приложения. В качестве тестов приведены имитации e2e и нагрузочного тестирования. Опишите и настройте собственные тесты.
• delete-test-env — удаление тестового приложения.
• release — продакшн развертывание приложения. Дополнительно на этом этапе используются среды развертывания. Они создаются и сохраняются при каждом успешном выполнении пайплайна. Воспользуйтесь ими, чтобы восстановить и развернуть прошлую версию приложения.

После сохранения файла конфигурации .gitlab-ci.yml запустится сценарий сборки.

Проверьте результатПроверьте результат

Чтобы проверить результаты выполнения сценария сборки, на панели слева в проекте gitlab-test выберите пункт Build, в выпадающем меню выберите пункт Pipelines. Все пять этапов должны успешно завершиться.

Приложение будет доступно по адресу служебного домена API-шлюза API Gateway в каталоге prod. Адрес можно посмотреть в консоли управления или в значении поля domain в логе выполнения скрипта bootstrap.sh.

Удалите созданные ресурсыУдалите созданные ресурсы

Некоторые ресурсы платные. Чтобы за них не списывалась плата, удалите ресурсы, которые вы больше не будете использовать:

1. Удалите каталоги prod, testing и infra вместе с ресурсами в них.
2. Удалите инстанс Managed Service for GitLab или созданную ВМ с образом GitLab.
3. Удалите кластер Managed Service for Kubernetes.
4. Если вы зарезервировали для кластера публичный статический IP-адрес, удалите его.
5. Удалите сервисные аккаунты.