Что такое CI/CD на сервере Linux? Конвейер CI/CD на Linux? Учебное пособие для начинающих.

CI/CD на сервере Linux Это практика автоматизации сборки, тестирования и развертывания кода с использованием Linux-сервера в качестве среды выполнения и доставки. Она подключает ваш репозиторий к конвейеру, который непрерывно интегрирует изменения, запускает тесты и развертывает артефакты на тестовой или производственной среде с помощью повторяемых скриптов, надежной защиты и минимального времени простоя.

Непрерывная интеграция и непрерывная доставка (CI / CD) Внедрение CI/CD на сервере Linux — один из самых надежных способов быстрой доставки программного обеспечения без сбоев в производственной среде. В этом руководстве вы узнаете, как работает CI/CD, какие инструменты выбрать, как настроить его на Ubuntu или аналогичных дистрибутивах, а также как безопасно и многократно развертывать программное обеспечение без простоев.

Независимо от того, развертываете ли вы веб-приложение, API или микросервис, это простое и понятное руководство для начинающих поможет вам разобраться во всех тонкостях. 15 + годы Мы разделим практический опыт в области хостинга и DevOps на понятные этапы. Основное внимание будет уделено практическим примерам с использованием GitLab CI и Docker, а также рекомендациям по Jenkins и GitHub Actions, чтобы вы могли выбрать оптимальный конвейер для своего стека и команды.

Что такое CI/CD на сервере Linux?

CI/CD — это конвейер DevOps, который автоматизирует разработку программного обеспечения. Доставка от коммита до продакшена. На сервере Linux это означает, что ваши сборки, тесты и развертывания выполняются на хосте Linux (виртуальной машине, VPS или физическом сервере) с использованием таких инструментов, как GitLab CI, GitHub Actions или Jenkins. Результатом являются более быстрые релизы, согласованные среды и меньшее количество человеческих ошибок.

Как работает CI/CD: от фиксации изменений до развертывания

Непрерывная интеграция (CI)

CI запускается при каждом коммите или запросе на слияние/выполнение команды. Конвейер устанавливает зависимости, проверяет код на наличие ошибок, запускает модульные/интеграционные тесты и создает артефакты или образы Docker. Цель — выявлять дефекты на ранних стадиях и обеспечивать постоянную готовность основной ветки к развертыванию.

Непрерывная доставка или развертывание (CD)

Система непрерывной доставки (CD) продвигает протестированные сборки в тестовую или производственную среду с контролируемым процессом утверждения. «Доставка» обычно останавливается на этапе ручного утверждения. «Развертывание» полностью автоматизирует выпуск в производственную среду. В Linux для обеспечения стабильных и воспроизводимых развертываний CD часто использует SSH, Docker, systemd и Nginx.

Типичные этапы конвейера CI/CD

• Источник: Код загружен в Git (GitHub, GitLab, Bitbucket).
• Телосложение: Компиляция или упаковка; создание образов Docker; создание артефактов.
• Контрольная работа: Выполните модульное, интеграционное и сканирование безопасности (SAST/DAST).
• Релиз: Помечайте изображения и загружайте их в реестр; подписывайте артефакты.
• Развертывание: Обновите службы на сервере Linux; выполните миграции.
• Убедитесь, что: Проверка на дымность, медицинские осмотры и оповещения системы мониторинга.

Выбор стека CI/CD для Linux

GitHub Actions против GitLab CI против Jenkins

• Действия GitHub: Встроенная функция GitHub, удобные действия в маркетплейсе, отлично подходит для проектов с открытым исходным кодом и небольших команд. Поддерживаются саморазмещаемые Linux-серверы.
• GitLab CI: IИнтегрированные задачи, утверждение запросов на слияние, реестр контейнеров и среды. GitLab Runner на Linux прост и масштабируем.
• Дженкинс: Обладает широкими возможностями настройки и обширной экосистемой плагинов, идеально подходит для сложных корпоративных конвейеров. Требует более тщательной проработки и поддержки.

В качестве альтернативы можно рассмотреть CircleCI, Drone CI и Argo CD (для GitOps/Kubernetes). Если вы размещаете собственные раннеры на сервере Linux, убедитесь, что они изолированы с помощью Docker, защищены брандмауэром и регулярно обновляются.

Предварительные условия: Подготовьте свой Linux-сервер.

Базовая настройка

• ОС: Ubuntu 22.04+ или Debian 12+ (стабильная версия, широко поддерживаемая).
• Пользователей: Создайте пользователя без прав root для развертывания, использующего команду sudo, для выполнения контролируемых задач.
• Сеть: Настройте статический IP-адрес, DNS-записи A/AAAA и откройте только необходимые порты (80/443/22).
• ТЛС: Используйте сертификаты Let's Encrypt (Certbot) для HTTPS.
• Хранение: По возможности используйте отдельные тома для журналов, Docker и резервных копий.

# Create deploy user and harden SSH
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo mkdir -p /home/deploy/.ssh && sudo chmod 700 /home/deploy/.ssh
# Add your public key to /home/deploy/.ssh/authorized_keys
sudo apt update && sudo apt install -y ufw fail2ban

# Basic firewall
sudo ufw allow OpenSSH
sudo ufw allow http
sudo ufw allow https
sudo ufw enable

Установите Docker, Nginx и необходимые утилиты.

sudo apt install -y docker.io docker-compose-plugin nginx certbot python3-certbot-nginx jq
sudo usermod -aG docker deploy
sudo systemctl enable --now docker nginx
sudo certbot --nginx -d example.com -d www.example.com

Docker стандартизирует среды, Nginx выступает в качестве обратного прокси, а systemd — в качестве средства контроля среды. manageЖизненные циклы сервисов. Это трио является проверенной основой для надежное развертывание на Linux.

Пошаговое руководство: Простой конвейер CI/CD в Linux (GitLab CI + Docker)

В этом примере создается образ Docker, загружается в реестр и развертывается на сервере Linux через SSH. Аналогичный алгоритм можно адаптировать для GitHub Actions или Jenkins.

Пример Dockerfile

# Dockerfile
FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:stable-alpine
COPY --from=build /app/dist /usr/share/nginx/html
EXPOSE 80
HEALTHCHECK CMD wget -qO- http://localhost/ > /dev/null || exit 1

.gitlab-ci.yml

stages:
  - test
  - build
  - deploy

variables:
  IMAGE_NAME: registry.gitlab.com/namespace/project
  DOCKER_DRIVER: overlay2

test:
  image: node:20-alpine
  stage: test
  script:
    - npm ci
    - npm test -- --ci

build:
  image: docker:24.0.6
  stage: build
  services:
    - docker:24.0.6-dind
  script:
    - docker build -t "$IMAGE_NAME:$CI_COMMIT_SHA" .
    - docker push "$IMAGE_NAME:$CI_COMMIT_SHA"
    - docker tag "$IMAGE_NAME:$CI_COMMIT_SHA" "$IMAGE_NAME:latest"
    - docker push "$IMAGE_NAME:latest"
  only:
    - main

deploy_production:
  image: alpine:3.19
  stage: deploy
  before_script:
    - apk add --no-cache openssh-client
  script:
    - |
      ssh -o StrictHostKeyChecking=no deploy@your-server-ip '
        set -e
        docker pull '$IMAGE_NAME':latest
        docker compose -f /opt/app/docker-compose.yml up -d --no-deps --build app
        docker image prune -f
      '
  only:
    - tags
    - main

файл docker-compose.yml на сервере

version: "3.9"
services:
  app:
    image: registry.gitlab.com/namespace/project:latest
    restart: always
    networks: [web]
    healthcheck:
      test: ["CMD-SHELL", "wget -qO- http://localhost || exit 1"]
    labels:
      - traefik.enable=false
networks:
  web: {}

Обратный прокси-сервер Nginx (пример)

server {
    listen 80;
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_read_timeout 60s;
    }

    access_log /var/log/nginx/app_access.log;
    error_log /var/log/nginx/app_error.log;
}

Привяжите свой контейнер к 127.0.0.1:8080 (или к сети Docker) и позвольте Nginx обрабатывать SSL и HTTP/2 на периферии сети. Такое разделение упрощает обновление сертификатов и повышает производительность.

Развертывание и откат без простоев

Обновления сине-зеленого или поэтапного типа.

• Сине-зелёный: Запустите два идентичных стека (синий и зеленый). Переключите трафик на Nginx, когда зеленый будет работать корректно; синий оставьте для отката.
• Прокатка: Постепенно заменяйте контейнеры проверками работоспособности. Хорошо работает с репликами Docker Compose или оркестровкой (Swarm/K8s).
• Канарейки: Перенаправьте небольшой процент трафика на новую версию, а затем, если показатели будут хорошими, постепенно увеличивайте нагрузку.

Безопасная миграция баз данных

• Используйте обратно совместимые миграции (шаблон расширения-сокращения).
• Перед переключением трафика выполняйте миграции в качестве отдельной задачи CI/CD.
• Создайте резервную копию базы данных и потренируйтесь в восстановлении. Автоматизируйте создание моментальных снимков.

Рекомендации по обеспечению безопасности CI/CD в Linux

• Управление секретами: Храните токены, SSH-ключи и учетные данные реестра в секретах/переменных CI/CD. Никогда не отправляйте секреты в Git.
• Наименьшие привилегии: Ограничьте права пользователя, используемого для развертывания, и при необходимости используйте команду sudoers с указанием точных команд. Ограничьте исходящий сетевой трафик от запускающих процессов.
• Изолированные бегуны: Используйте выделенные виртуальные машины Linux или контейнеры для самостоятельного запуска тестов. Не запускайте ненадежные запросы на слияние на производственных хостах.
• Регулярно обновляйте: Автоматизируйте обновления безопасности для пакетов ОС и контейнеров. Регулярно пересобирайте базовые образы.
• Безопасность изображений: Сканируйте изображения (Trivy, Grype), подписывайте их (Cosign) и закрепляйте дайджесты для детерминированного развертывания.
• Гигиена SSH: Используйте ключи Ed25519, отключите аутентификацию по паролю и рассмотрите возможность использования ProxyJump или VPN для обеспечения доступа через бастион.

Мониторинг, регистрация данных и контроль затрат

• Мониторинг: Используйте Prometheus + Grafana или легковесный node_exporter для получения метрик ЦП, ОЗУ, диска и приложений.
• Логирование: Централизуйте систему с помощью стека ELK/Elastic или Loki + Promtail. Храните журналы на отдельном хранилище и регулярно проводите ротацию.
• Проверка здоровья: Интеграция контрольных точек проверки работоспособности в Nginx и дымовые тесты CI. Оповещения о кодах, отличных от 200, и скачках задержки.
• Оптимизация затрат: Настройте размер вашего Linux VPS, включите автоматическое удаление старых образов и архивируйте артефакты по истечении заданного периода времени.

Распространенные ошибки, которых следует избегать

• Сборка осуществляется на производственном сервере, а не путем распространения предварительно собранных артефактов или образов.
• Смешивание кода приложения и конфигурации сервера в произвольных скриптах (используйте концепцию «инфраструктура как код» или, по крайней мере, версионированные конфигурации).
• Пропуск тестов и проверок работоспособности приводит к сбоям в основных ветках и неудачным развертываниям.
• Встраивайте секреты в скрипты напрямую; используйте переменные CI или хранилище.
• Игнорируйте планы отката; всегда держите под рукой предыдущий образ и конфигурацию Nginx.

Реальные схемы расстановки оборудования

• Малые команды: GitHub Actions или GitLab CI с одним VPS-сервером на Linux, Docker-контейнером, прокси-сервером Nginx и ежедневным резервным копированием.
• Растущие стартапы: Самостоятельно размещенный пул GitLab Runner на Linux, реестр + хранилище артефактов, среды тестирования и производства, сине-зеленый алгоритм.
• Предприятия: Jenkins с агентами Linux, политиками как кодом, подписанными артефактами, несколькими средами, канареечными релизами, единым входом (SSO) и журналами аудита.

Когда следует выбрать управляемый хостинг или помощь?

Если вы предпочитаете сосредоточиться на своем приложении, рассмотрите вариант надежного VPS на базе Linux или manageОблачное решение от провайдера, который понимает рабочие процессы CI/CD. YouStableМы предоставляем быстрые экземпляры VPS на базе Linux, IPv4/IPv6, бесплатный SSL и круглосуточную поддержку — идеально подходит для размещения Docker-приложений за Nginx и беспроблемной интеграции конвейеров GitHub/GitLab.

Часто задаваемые вопросы