Интеграция облачных функций Yandex Cloud Functions с GitHub Actions позволяет сократить время развёртывания на 70% и существенно упростить процесс автоматизации.
В прошлой статье мы рассказывали о SourceCraft — инструменте для организации CI/CD‑процессов в Yandex Cloud Functions. Теперь рассмотрим GitHub Actions и классический GitHub Flow. Этот вариант подойдёт командам, которые предпочитают работать с нативными инструментами GitHub и хотят максимально использовать возможности платформы.
GitHub Flow работает по простой схеме: ветка main хранит готовый к продакшну код. Новые функции разрабатываются в отдельных feature‑ветках — ветках для функционала, а исправления — в hotfix‑ветках для срочных правок. После проверки изменения попадают в main, что автоматически запускает развёртывание. Такой процесс экономит время и ускоряет деплой функций в облаке.
В статье расскажем, как подготовить Yandex Cloud Functions и репозиторий GitHub к запуску пайплайна. Рассмотрим настройку workflow GitHub Actions для развёртывания функций на всех этапах от интеграции до продакшна и покажем способы защиты продакшна при автоматическом деплое.
GitHub позволяет автоматически запускать развёртывание через события‑триггеры. Изменения в репозитории (например, push) или создание запроса на слияние (пулл‑реквесты) запускают конвейер автоматизации (CI/CD‑пайплайн).
Подход GitHub Flow использует один репозиторий с основной веткой main. В ней хранится версия, готовая к релизу.
Для работы с функциями создаются три окружения:
События GitHub привязаны к развёртыванию на соответствующие среды:
main развёртывает функцию в тестовом окружении;main запускают развёртывание в продакшне.Автоматизация развёртывания требует подготовки инфраструктуры Yandex Cloud и настройки репозитория:
Дальше настраивается доступ Yandex Cloud для развёртывания. Создаются два сервисных аккаунта: один для продакшна, второй — для непроизводственных окружений. Обоим аккаунтам назначается роль Functions Admin — она даёт права управления версиями функций.
Затем настраивается федерация сервисных аккаунтов через стандарт аутентификации OpenID Connect (OIDC). Это позволяет GitHub Actions обмениваться токенами на временные IAM‑токены Yandex Cloud.
Workload Identity Federation (федерация рабочих нагрузок) работает следующим образом: GitHub выдаёт доверенный OIDC‑токен, а Yandex Cloud обменивает его на IAM‑токен.
Для настройки федерации требуются параметры аутентификации Issuer и Subject. Готовые значения берутся из примера в репозитории. В шаблоне указываются имя GitHub‑репозитория и владелец вместо заполнителей.
Далее сервисные аккаунты привязываются к федерации. Настраиваются правила доступа — они определяют, в каких случаях GitHub‑токен должен быть обменян на IAM‑токен соответствующего сервисного аккаунта.
Для непроизводственных окружений (Integration и Test) в нашем примере используется признак окружения. В конфигурации рабочего процесса указывается environment: "preprod". OIDC‑токен с таким параметром обменивается на IAM‑токен preprod‑аккаунта (для непроизводственных сред).
Для продакшна в данном примере настраивается правило на основе ветки — это один из возможных подходов. В параметрах федерации указывается subject (правило доступа) с шаблоном refs/heads/main. Токен от изменений в main работает от имени продакшн‑аккаунта.
Без указания этих условий (environment или ветки) в workflow привязка не сработает. Облачный токен для развёртывания получен не будет.
Всё, облачные ресурсы готовы: сервисные аккаунты созданы, федерация настроена и связана с аккаунтами. Теперь GitHub Workflows смогут от имени сервисных аккаунтов создавать новые версии функций в Yandex Cloud.
Остаётся настроить сценарии CI/CD.
Следующий шаг — перенос логики CI/CD в репозиторий. В директорию .github/workflows добавляются три файла:
Каждый workflow‑файл описывает шаги развёртывания функции для своего этапа. Файлы содержат параметры‑заполнители, которые заменяются реальными данными из облака: ID каталога, ID сервисного аккаунта, путь до исходников функции.
После коммита файлов в репозиторий новые workflow появляются в списке GitHub Actions. Пайплайн готов к запуску.
Основные параметры workflow определяют логику работы автоматизации.
В секции on каждого YAML‑файла указывается событие, которое запускает рабочий процесс. Например, для продакшн‑развёртывания используется on: push с фильтром branches: [main]. Для интеграционного окружения триггером служит push в feature‑ветки, а для тестового — создание pull request в main.
Workflow CD выполняется при изменениях в ветке main. Параметр paths‑ignore позволяет игнорировать изменения в определённых путях. В исключения обычно добавляются каталоги с workflow‑файлами, тестами, документацией и другими вспомогательными файлами, изменения в которых не требуют развёртывания. Это важная мера предосторожности — изменения в конфигурационных файлах CI/CD почти никогда не должны вызывать автоматического развёртывания кода. Именно поэтому workflow‑файлы добавляются в список игнорируемых путей, особенно для продакшн‑окружения.
Три рабочих процесса GitHub Actions автоматически доставляют код функции через все этапы разработки:
Для внесения изменений в feature‑ветке (непрерывной интеграции) разработчик создаёт новую ветку или работает в существующей. После правок в коде функции разработчик создаёт коммит и отправляет изменения в репозиторий. Это событие запускает рабочий процесс непрерывной интеграции.
При этом в логах GitHub Actions отображается процесс развёртывания на интеграционное окружение Yandex Cloud. Для функции создаётся новая версия. Задача CI завершается успешно — статус отображается зелёным цветом. Версия функции получает статус Active, что означает готовность к работе. Функции в тестовом и продакшн‑окружениях остаются без изменений.
Разработчик открывает запрос на слияние из feature‑ветки в main. Это событие запускает workflow CT, который разворачивает новую версию в тестовом окружении.
Функция успешно обновляется. Задача развёртывания для тестирования завершается с положительным статусом. На этом этапе команда проводит дополнительные тесты. Это позволяет убедиться в работоспособности новой версии перед выпуском в продакшн.
После успешного тестирования на тестовом окружении и одобрения изменений коллегами в рамках pull request код объединяется с веткой main. Это запускает workflow CD для развёртывания в продакшне. Изменения в main создают новую версию функции в продакшн‑окружении Yandex Cloud. Workflow завершается успешно. В логах отображается выпуск обновлённой версии на продакшне.
Автоматизация развёртывания может создать риски для продакшна при неправильной настройке. При ошибках в конфигурации процессы тестирования или интеграции иногда влияют на боевое окружение. Правильная настройка и следование лучшим практикам исключают такие риски. Для дополнительной защиты применяются следующие механизмы:
Тегирование версий функций. При пометке стабильной версии тегом она защищается от удаления. Потребители могут явно ссылаться на помеченную версию для гарантии стабильности. Это защищает от неожиданных изменений только тех клиентов, которые используют тегированную версию. По умолчанию вызывается последняя версия функции — если потребитель не указал конкретный тег, он автоматически получит все обновления при появлении новой версии.
Разделение окружений и доступов. Продакшн изолируется от тестовых сред на уровне прав и ресурсов. Одно из решений — функции разных окружений размещаются в отдельных каталогах Yandex Cloud. Им назначаются разные сервисные аккаунты. Пайплайн для интеграции или теста физически не может изменить ресурсы продакшна.
Это два из возможных подходов к защите продакшна. В практике DevOps существует множество решений, каждая команда выбирает подходящий вариант исходя из своих задач и требований.
