Безопасная разработка: Часть 1 — CI/CD: от ручной выкладки к автоматическому деплою

CI/CD — это практика, при которой каждое изменение кода автоматически собирается, проверяется и доставляется на сервер. Вместо ручной последовательности «скопировать файлы, перезапустить сервис и проверить, что ничего не сломалось» эту работу выполняет программа по описанию, которое хранится в репозитории рядом с кодом.

Этой частью открывается цикл о безопасной разработке. Все следующие проверки — поиск секретов, статический анализ кода, проверка зависимостей и контейнерных образов — встраиваются именно в пайплайн, поэтому начинать приходится с него.

CI, CD и ещё раз CD

• Непрерывная интеграция (Continuous Integration). После каждого git push код собирается и проходит тесты. Ошибка обнаруживается через несколько минут после коммита, а не в день выкладки.
• Непрерывная доставка (Continuous Delivery). Каждая успешная сборка готова к выкладке, но команду на выкладку даёт человек.
• Непрерывное развёртывание (Continuous Deployment). Успешная сборка уходит на сервер автоматически, без участия человека.

Небольшим командам обычно подходит вторая модель: всё проверяется автоматически, а выкладка запускается одной кнопкой.

Из чего состоит пайплайн

• Файл описания в репозитории: .gitlab-ci.yml, .github/workflows/*.yml, .gitea/workflows/*.yaml или Jenkinsfile.
• Этапы и задачи. Этапы выполняются по порядку, задачи одного этапа — параллельно, если хватает исполнителей.
• Раннер — программа, которая выполняет задачи. На GitLab.com и GitHub.com есть облачные раннеры; на собственном сервере GitLab или Gitea раннер нужно установить и зарегистрировать самостоятельно.
• Переменные и секреты задаются в настройках проекта, а не в файле пайплайна.

Инструменты

GitLab CI встроен в GitLab — и в облачный GitLab.com, и в устанавливаемый на собственный сервер. Пайплайн описывается в файле .gitlab-ci.yml в корне репозитория. На своём сервере GitLab задачи начнут выполняться только после установки и регистрации GitLab Runner.

GitHub Actions встроен в GitHub. Файлы пайплайнов лежат в каталоге .github/workflows, для типовых шагов есть большая библиотека готовых действий.

Gitea Actions появились в Gitea 1.19, а с версии 1.21 включены по умолчанию. Синтаксис в основном совместим с GitHub Actions, файлы размещаются в .gitea/workflows/, задачи выполняет отдельная программа Gitea Runner. Это лёгкий вариант для компании, которой нужен собственный Git-сервер со встроенной автоматизацией.

Jenkins — отдельный сервер автоматизации: пайплайны описываются в Jenkinsfile, возможности расширяются плагинами. Он очень гибок, но установку, обновления и совместимость плагинов обслуживаете вы. Обычно его выбирают там, где он уже давно работает.

Минимальный рабочий пайплайн

Пример для GitLab CI: тесты на каждое изменение и выкладка только из основной ветки.

stages:
  - test
  - deploy

test:
  stage: test
  image: python:3.13-slim
  script:
    - pip install -r requirements.txt
    - pytest

deploy:
  stage: deploy
  script:
    - ./deploy.sh
  environment: production
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

Задача deploy появляется только в основной ветке и ждёт ручного запуска — это и есть непрерывная доставка. Если убрать when: manual, получится непрерывное развёртывание.

То же для GitHub Actions — файл .github/workflows/ci.yml:

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    container: python:3.13-slim
    steps:
      - uses: actions/checkout@v6
      - run: pip install -r requirements.txt
      - run: pytest

Для Gitea Actions подходит почти такой же файл, только в каталоге .gitea/workflows/.

Где в пайплайне проверки безопасности

Проверка приносит пользу, только если может остановить пайплайн: предупреждения, которые ни на что не влияют, быстро перестают читать. Разумный порядок — включить проверку в режиме отчёта, разобрать найденное, а затем сделать её обязательной.

Секреты и доступы пайплайна

• Пароли и ключи хранятся в защищённых переменных проекта (в GitLab — masked и protected, в GitHub — secrets), а не в YAML-файле.
• Для выкладки заводится отдельный пользователь и ключ с минимальными правами — только на то, что нужно для деплоя.
• Выкладка разрешается только из основной ветки.
• Раннер на собственном сервере не должен выполнять задачи чужих проектов: документация Gitea прямо предупреждает, что нельзя использовать недоверенные раннеры и предоставлять свои раннеры недоверенным инстансам.

GitOps

Для Kubernetes распространён подход GitOps: желаемое состояние кластера описано в Git, а специальный агент в кластере (Argo CD или Flux) сам приводит кластер к этому описанию. Пайплайн в этом случае не выкладывает приложение напрямую, а только обновляет манифесты в репозитории. Для одного-двух серверов без Kubernetes это лишнее усложнение — хватает обычного шага выкладки.

Что учесть в России

• Оплатить зарубежные тарифы GitHub и GitLab.com картой российского банка нельзя: Visa и Mastercard с марта 2022 года не работают за пределами России.
• Независимость от внешних сервисов даёт собственный Git-сервер — GitLab на своём сервере или Gitea с Gitea Actions — и раннеры на своих машинах. Такой вариант требует администрирования, но код, сборки и секреты остаются под вашим контролем.

Типичные ошибки

• Пароли в файле пайплайна. Они попадают в историю Git и видны всем, у кого есть доступ к репозиторию.
• Проверки, которые не останавливают сборку. Их результаты никто не смотрит.
• Долгий пайплайн. Если сборка идёт полчаса, разработчики перестают ждать результатов. Помогают кеширование зависимостей и параллельные задачи.
• Выкладка с любой ветки. Экспериментальный код оказывается на рабочем сервере.
• Один раннер с доступом к продакшену для всех проектов. Ошибка или взлом в одном проекте открывает доступ к остальным.

Настройка пайплайна под конкретный проект — от первых тестов до выкладки на свои серверы — входит в услугу по настройке CI/CD.