Обзор

При использовании CI/CD-системы пользователь должен учитывать её особенности и интегрироваться с существующими примитивами и компонентами.

werf предлагает готовую интеграцию для GitLab CI/CD и GitHub Actions. Используя служебные переменные окружения CI-заданий, интеграция выполняет следующие действия:

  • Создание временной Docker-конфигурации на основе текущей пользовательской и авторизация в container registry CI.
  • Простановка значений по умолчанию для команд werf:
    • Использование container registry CI (WERF_REPO).
    • Определение текущего окружения (WERF_ENV).
    • Аннотирование выкатываемых ресурсов чарта, связывание с CI-системой (WERF_ADD_ANNOTATION_*). Во все выкатываемые ресурсы добавляются аннотации, которые позволяют пользователю перейти в связанный пайплайн, задание и коммит при необходимости.
    • Настройка логирования werf (WERF_LOG_*).
    • Включение автоматической очистки процессов werf для отменённых CI-заданий (WERF_ENABLE_PROCESS_EXTERMINATOR=1). Процедура требуется только в тех CI-системах, которые не умеют посылать сигнал о завершении порожденным процессам (например, в GitLab CI/CD).

GitLab CI/CD

Вся интеграция сводится к вызову команды ci-env и последующим выполнением инструкций, которые команда выводит в stdout.

. $(werf ci-env gitlab --as-file)

Далее в рамках shell-сессии все команды werf будут использовать проставленные значения по умолчанию и работать с container registry CI.

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

Deploy to Production:
  stage: deploy
  script:
    - . $(werf ci-env gitlab --as-file)
    - werf converge
  environment:
    name: production

Полный .gitlab-ci.yml для готовых рабочих процессов, а также особенности использования werf c Shell, Docker и Kubernetes executors можно найти в соответствующих статьях руководства:

GitHub Actions

По аналогии с GitLab CI/CD интеграция сводится к вызову команды ci-env и последующим выполнением инструкций, которые команда выводит в stdout.

. $(werf ci-env github --as-file)

Далее в рамках шага все команды werf будут использовать проставленные значения по умолчанию и работать с container registry CI.

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

converge:
  name: Converge
  runs-on: ubuntu-latest
  steps:

    - name: Checkout code
      uses: actions/checkout@v3
      with:
        fetch-depth: 0

    - name: Install werf
      uses: werf/actions/install@v2

    - name: Run script
      run: |
        . $(werf ci-env github --as-file)
        werf converge
      env:
        WERF_KUBECONFIG_BASE64: ${{ secrets.KUBE_CONFIG_BASE64_DATA }}
        WERF_ENV: production
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Полный набор конфигураций (.github/workflows/*.yml) для готовых рабочих процессов можно найти в соответствующей статье руководства.