Построение CI/CD-пайплайна с помощью serverless-продуктов Yandex Cloud и GitLab CI

CI/CD-пайплайн — это поток автоматической интеграции и доставки (или развёртывания) приложений. Он позволяет минимизировать человеческий фактор, ускорить сборку кода и повысить качество работы. Создание serverless-архитектуры также позволяет быстрее достигать результата и концентрироваться на бизнес-логике проекта, а не на том, где и как хранятся данные и как сделать продукт отказоустойчивым и масштабируемым. Эта статья поможет вам создать собственное serverless-приложение и выстроить для него CI/CD-пайплайн с применением сервисов Yandex Cloud.

Место serverless в инфраструктуре проектаМесто serverless в инфраструктуре проекта

Обычно инфраструктура проекта состоит из нескольких важных частей:

• Здание, коммуникации, электрика, интернет-каналы, охрана и т. д. Чаще всего этот пункт реализован в ЦОД, и редко кто-то занимается им самостоятельно: все обращаются за ресурсами к провайдерам инфраструктуры.

• Виртуализация и изолирование ресурсов. Это затратные для основного бизнеса и тяжёлые в сопровождении блоки. Но проблема решается делегированием их IaaS-провайдеру.

• Управление патчами, конфигурациями, доступом.

• Установка и настройка middleware (например, серверов приложений и СУБД) и контейнеризация.

• Кластеризация серверов: настройка, управление и сопровождение. С работой над этими частями помогают справиться управляемые сервисы. Всё настраивается в рамках веб-консоли, не нужно погружаться глубоко в настройку ОС. В Yandex Cloud можно настроить параметры, выбранные нашими разработчиками. Это поможет повысить надёжность и производительность системы.

• Планирование ресурсов, автоскейлинг, катастрофоустойчивость. Обо всём этом нужно подумать до того, как разработчики начнут разворачивать приложение, а проект — приносить прибыль. Эту задачу решают serverless-сервисы.

• Поставка кода, управление им и доступом к данным.

• Доставка контента, кеширование.

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

Особенности архитектуры при serverless-подходеОсобенности архитектуры при serverless-подходе

Для реализации serverless-подхода необходимо перейти к событийно-ориентированной (event‑driven) архитектуре приложения. Она предполагает, что есть некоторое событие (event) — существенное изменение состояния. И есть триггер — реакция на определённое событие, которая запускает код.

Чтобы перейти к такой архитектуре, нужно реализовать в приложении несколько условий:

1. Атомарность. Объём задач каждого компонента приложения должен быть минимальным. Это нужно для того, чтобы можно было распределить нагрузку, распараллелить её.
2. Асинхронность. Она предполагает, что какой-то процесс инициирует другой и сам прекращает свою работу. Такие цепочки передачи сообщений позволяют формировать оптимальную по затратам ресурсов среду, так как не нужно держать какой-то сервис в фоне, ожидая другие процессы.
3. Decoupling (ослабление связанности). Он предполагает слабую связанность компонентов приложений.
4. Stateless. Компоненты вашего сервиса не должны сохранять своё состояние, если это возможно.

Отдельная рекомендация — работать с push-моделью, то есть отказаться от периодических опросов инфраструктуры приложения в пользу получения сообщений от клиентов управляющим сервисом.

Пример serverless-приложенияПример serverless-приложения

Для построения CI/CD-пайплайна мы предлагаем пример приложения e-commerce-магазина с товарами и корзиной. Приложение создано исключительно для демонстрации создания CI/CD‑пайплайна и не является готовым продуктом. При обращении к приложению можно заметить небольшую задержку. Её можно существенно снизить за счёт использования подготовленных экземпляров.

Мы развернём приложение в serverless-контейнерах, автоматически распределённых по трём ЦОД. Это обеспечит катастрофоустойчивость решения. Данные тоже будем хранить в serverless-режиме, используя Yandex Managed Service for YDB и объектное хранилище Yandex Object Storage. Также мы используем сервисы IAM и Lockbox, чтобы обеспечить безопасность решения.

Собранный образ приложения поместим в Yandex Container Registry.

В качестве точки входа для обращения к ресурсам мы будем использовать Yandex API Gateway. Для публикации приложения используем Yandex Cloud DNS.

Код можно хранить либо в Yandex Managed Service for GitLab, либо в GitLab, развёрнутом на виртуальной машине.

Автоматизацию доставки кода построим с помощью GitLab CI. Кроме того, в инструкции мы используем GitLab Runner — приложение с открытым исходным кодом, которое выполняет задания конвейерной обработки GitLab CI/CD по инструкциям из специального файла. С его помощью можно запускать автоматизированные сборки в рамках кластера Managed Service for Kubernetes^®. Но GitLab Runner также можно развернуть самостоятельно на виртуальной машине.

Инструкцию о построении CI/CD-пайплайна можно найти в документации.

С помощью serverless-продуктов Yandex Cloud можно за несколько простых шагов построить пайплайн непрерывной интеграции и непрерывной поставки. Он поможет уменьшить время на сборку и доставку кода в тестовое и продуктовое окружения, минимизировать ошибки, сделать работу над продуктом более эффективной и позволит сконцентрироваться на разработке бизнес‑логики.