Yandex Cloud
Поиск
Связаться с намиПодключиться
  • Документация
  • Блог
  • Все сервисы
  • Статус работы сервисов
    • Популярные
    • Инфраструктура и сеть
    • Платформа данных
    • Контейнеры
    • Инструменты разработчика
    • Бессерверные вычисления
    • Безопасность
    • Мониторинг и управление ресурсами
    • Машинное обучение
    • Бизнес-инструменты
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Облако для интеграторов
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Контент-программа
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Истории успеха
    • Тарифы Yandex Cloud
    • Промоакции и free tier
    • Правила тарификации
  • Документация
  • Блог
Проект Яндекса
© 2025 ООО «Яндекс.Облако»
Yandex Container Registry
  • Начало работы
  • Yandex Container Solution
    • Все руководства
    • Подпись и проверка Docker-образов в Managed Service for Kubernetes
    • Сканирование уязвимостей при непрерывном развертывании приложений Managed Service for Kubernetes с помощью GitLab
    • Непрерывное развертывание контейнеризованных приложений с помощью GitLab
    • Построение пайплайна CI/CD в GitLab с использованием serverless-продуктов
    • Хранение Docker-образов из проектов Yandex Managed Service for GitLab
    • Подключение к Container Registry из VPC
    • Настройка отказоустойчивой архитектуры в Yandex Cloud
    • Запуск внешних агентов для нагрузочного тестирования
    • Запуск контейнерного приложения в Yandex Serverless Containers
    • Развертывание gRPC-сервиса на основе Docker-образа
    • Развертывание сервиса в DataSphere на основе Docker-образа
    • Развертывание сервиса в DataSphere на основе Docker-образа с FastAPI
    • Настройка подключения к Managed Service for PostgreSQL из контейнера Serverless Containers
    • Интеграция с Container Registry
  • Управление доступом
  • Правила тарификации
  • Справочник Terraform
  • Метрики Monitoring
  • Аудитные логи Audit Trails
  • Решение проблем
  • Вопросы и ответы
  • Обучающие курсы

В этой статье:

  • Необходимые платные ресурсы
  • Перед началом работы
  • Скачайте проект
  • Установите дополнительные зависимости
  • Подготовьте инфраструктуру
  • Создайте инстанс GitLab
  • Настройте GitLab
  • Создайте GitLab Runner
  • Загрузите файлы в репозиторий GitLab
  • Создайте переменные окружения GitLab
  • Создайте файл конфигурации сценария CI
  • Проверьте результат
  • Удалите созданные ресурсы
  1. Практические руководства
  2. Построение пайплайна CI/CD в GitLab с использованием serverless-продуктов

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

Статья создана
Yandex Cloud
Обновлена 26 марта 2025 г.
  • Необходимые платные ресурсы
  • Перед началом работы
    • Скачайте проект
    • Установите дополнительные зависимости
    • Подготовьте инфраструктуру
  • Создайте инстанс GitLab
  • Настройте GitLab
  • Создайте GitLab Runner
  • Загрузите файлы в репозиторий GitLab
  • Создайте переменные окружения GitLab
  • Создайте файл конфигурации сценария CI
  • Проверьте результат
  • Удалите созданные ресурсы

Вы можете построить пайплайн непрерывной интеграции и непрерывной поставки (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. Проверьте результат.

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

Необходимые платные ресурсыНеобходимые платные ресурсы

В стоимость поддержки инфраструктуры входит:

  • Плата за диски и постоянно запущенные ВМ (см. тарифы Yandex Compute Cloud).
  • Плата за использование мастера Yandex Managed Service for Kubernetes (см. тарифы Managed Service for Kubernetes).
  • Плата за хранение созданных Docker-образов (см. тарифы Container Registry).
  • Плата за хранение секретов (см. тарифы Yandex Lockbox).
  • Плата за количество вызовов контейнера, вычислительные ресурсы, выделенные для выполнения приложения, и исходящий трафик (см. тарифы Serverless Containers).
  • Плата за запросы к API-шлюзу (см. тарифы API Gateway).
  • Плата за использование публичных IP-адресов (см. тарифы Yandex Virtual Private Cloud).

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

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

Клонируйте репозиторий 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.

Инстанс Managed Service for GitLab
ВМ с образом GitLab

Создайте инстанс Managed Service for GitLab согласно инструкции.

Запустите GitLab на ВМ с публичным IP-адресом.

  1. На странице каталога в консоли управления нажмите кнопку Создать ресурс и выберите Виртуальная машина.

  2. В блоке Образ загрузочного диска в поле Поиск продукта введите Gitlab и выберите публичный образ GitLab.

  3. В блоке Расположение выберите зону доступности, в которой будет находиться ВМ. Если вы не знаете, какая зона доступности вам нужна, оставьте выбранную по умолчанию.

  4. В блоке Вычислительные ресурсы перейдите на вкладку Своя конфигурация и укажите необходимую платформу, количество vCPU и объем RAM:

    • Платформа — Intel Ice Lake.
    • vCPU — 4.
    • Гарантированная доля vCPU — 100%.
    • RAM — 8 ГБ.
  5. В блоке Сетевые настройки:

    • В поле Подсеть выберите сеть и подсеть, к которым нужно подключить ВМ. Если нужной сети или подсети еще нет, создайте их.
    • В поле Публичный IP-адрес оставьте значение Автоматически, чтобы назначить ВМ случайный внешний IP-адрес из пула Yandex Cloud, или выберите статический адрес из списка, если вы зарезервировали его заранее.
  6. В блоке Доступ выберите вариант SSH-ключ и укажите данные для доступа на ВМ:

    • В поле Логин введите имя пользователя. Не используйте имя root или другие имена, зарезервированные ОС. Для выполнения операций, требующих прав суперпользователя, используйте команду sudo.
    • В поле SSH-ключ выберите SSH-ключ, сохраненный в вашем профиле пользователя организации.

      Если в вашем профиле нет сохраненных SSH-ключей или вы хотите добавить новый ключ:

      • Нажмите кнопку Добавить ключ.
      • Задайте имя SSH-ключа.
      • Загрузите или вставьте содержимое открытого SSH-ключа. Пару SSH-ключей для подключения к ВМ по SSH необходимо создать самостоятельно.
      • Нажмите кнопку Добавить.

      SSH-ключ будет добавлен в ваш профиль пользователя организации.

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

  7. В блоке Общая информация задайте имя ВМ: ci-tutorial-gitlab.

  8. Нажмите кнопку Создать ВМ.

Создание ВМ может занять несколько минут. Когда ВМ перейдет в статус RUNNING и запустится GitLab, настройте его.

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

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

Инстанс Managed Service for GitLab
ВМ с образом GitLab
  1. Авторизуйтесь в веб-интерфейсе инстанса Managed Service for GitLab.

  2. Нажмите кнопку Create a project.

  3. Нажмите кнопку Create blank project.

  4. Заполните поля:

    • Project name — gitlab-test.
    • Project URL — выберите пользователя-администратора в поле рядом с FQDN инстанса Managed Service for GitLab.

    Остальные поля оставьте без изменений.

  5. Нажмите кнопку Create project.

  1. На странице сервиса Yandex Compute Cloud выберите созданную ВМ и скопируйте ее публичный IP-адрес.

  2. Подключитесь к ВМ по протоколу SSH.

  3. Получите пароль администратора GitLab с помощью команды ВМ:

    sudo cat /etc/gitlab/initial_root_password
    
  4. Скопируйте пароль из строки Password (исключая пробелы) в буфер обмена или отдельный файл.

  5. Откройте в браузере ссылку http://<публичный_IP-адрес_ВМ>. Откроется веб-интерфейс GitLab.

  6. Войдите в систему с учетной записью администратора:

    • Username or email — root.
    • Password — пароль, скопированный ранее.

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

  7. Смените пароль учетной записи администратора.

  8. Повторно войдите в систему с учетной записью администратора, используя новый пароль.

  9. Выберите Create a project.

  10. Задайте имя проекта: gitlab-test.

  11. Нажмите кнопку Create project.

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

Чтобы запускать задачи сборки в кластере Yandex Managed Service for Kubernetes, создайте GitLab Runner. Для этого установите приложение 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.yandex/.
    • 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. Удалите сервисные аккаунты.

Была ли статья полезна?

Предыдущая
Непрерывное развертывание контейнеризованных приложений с помощью GitLab
Следующая
Хранение Docker-образов из проектов Yandex Managed Service for GitLab
Проект Яндекса
© 2025 ООО «Яндекс.Облако»