Использование переменных, секретов и артефактов

Курс: DevOps с нуля: Путь к автоматизации и CI/CD16+

Мы уже изучили структуру файла .gitlab-ci.yml и научились запускать задачи на GitLab Runner. Однако в реальных проектах пайплайны редко бывают статичными. Нам нужно передавать настройки между этапами, скрывать пароли от посторонних глаз и сохранять результаты сборки. Для этого в GitLab CI/CD существуют механизмы переменных, секретов и артефактов.

Гибкость через GitLab CI/CD Variables

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

Переменная в CI/CD позволяет менять параметры деплоя, не создавая лишних коммитов. В GitLab их можно задать на трех уровнях:

В файле .gitlab-ci.yml: для констант проекта, которые не жалко показать коллегам.
В интерфейсе GitLab (Settings → CI/CD): для данных, которые нельзя хранить в репозитории (токены, логины).
Предопределенные переменные: GitLab создает их сам. Например, CI_COMMIT_REF_NAME содержит имя ветки, а CI_JOB_ID — уникальный номер задачи.

Сравните два подхода. Во втором случае для смены версии достаточно поправить одну строку в начале файла или в настройках интерфейса.

# Плохо: версия «зашита» в код
build_job:
  script:
    - echo "Сборка версии 1.0.5"

# Хорошо: используем переменную
variables:
  APP_VERSION: "1.0.5"

smart_build_job:
  script:
    - echo "Сборка версии $APP_VERSION"

Безопасность и секреты

Для паролей от баз данных или API-ключей обычные переменные опасны. Используйте секрет (secret) — это переменная, созданная в интерфейсе GitLab с особыми настройками:

Masked (Маскирование): GitLab вырежет значение из логов и заменит его на [MASKED]. Если вы случайно выполните echo $PASSWORD, секрет не утечет в консоль.
Protected (Защита): переменная попадет только в пайплайны защищенных веток (например, main). Это защитит ключи, если кто-то создаст стороннюю ветку и попытается украсть данные через print.

Маскирование — не панацея. Оно работает только для строк определенного формата и длины. Старайтесь вообще не выводить отладочную информацию в логах продакшн-задач 🔏

Передача данных через Artifacts

Каждая задача запускается в изолированной среде. Если вы скомпилировали файл на этапе build, на этапе test его не будет — контейнер просто удалится. Чтобы передать результат дальше, используйте CI/CD-артефакт.

Artifacts — это файлы и папки, которые GitLab сохраняет после завершения задачи и пробрасывает в следующие этапы. Как показано на Схеме 1, артефакты работают как мост между изолированными стадиями.

Пример настройки:

stages:
  - build
  - test

compile_code:
  stage: build
  script:
    - mkdir build
    - echo "Binary data" > build/app.exe
  artifacts:
    paths:
      - build/
    expire_in: 1 week # Экономим место на сервере

run_tests:
  stage: test
  script:
    - ./build/app.exe --version

Оптимизация с помощью Cache

Не путайте артефакты с кэшем. Cache нужен для ускорения сборки. В нем хранят тяжелые зависимости (папки node_modules или кэш pip), которые почти не меняются.

Характеристика	artifacts	cache
Зачем нужен	Передать результат (бинарник, отчет)	Ускорить сборку (библиотеки)
Связь	Между этапами (Stages)	Между разными запусками пайплайна
Доступ	Можно скачать из интерфейса	Недоступен для скачивания вручную
Надежность	Гарантированно передается	Может быть удален системой 🧹

Что проверить, если что-то идет не так

Если переменная «исчезла»:

Регистр: $MY_VAR и $my_var — разные вещи для Linux.
Scope: проверьте, не привязана ли переменная к конкретному окружению (Environment).
Protected Status: если вы работаете в ветке feature, а переменная помечена как Protected, она не появится в пайплайне.

Мы заложили фундамент безопасности и научились управлять данными. В следующей теме перейдем к практике: интегрируем Docker в пайплайны, чтобы собирать и публиковать полноценные образы приложений.