Home » Настройка конвейера непрерывного деплоя с GitLab на Ubuntu

Настройка конвейера непрерывного деплоя с GitLab на Ubuntu

Настройка CI/CD конвейера — это один из тех навыков, которые отделяют настоящих сисадминов от тех, кто до сих пор деплоит через FileZilla. Если вы устали от ручного копирования файлов, забытых миграций и багов, которые попадают в продакшн, то эта статья для вас. Мы разберём настройку полноценного конвейера непрерывного деплоя с GitLab на Ubuntu — от установки до автоматизации деплоя в несколько сред.

Почему именно GitLab? Потому что это open-source решение с встроенным CI/CD, которое можно развернуть на своём железе. Никаких лимитов на приватные репозитории, полный контроль над процессом и возможность кастомизации под любые нужды. Плюс интеграция с Docker, Kubernetes и кучей других инструментов из коробки.

Как это работает: архитектура GitLab CI/CD

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

GitLab Server — центральный сервер, который хранит код и управляет пайплайнами
GitLab Runner — агент, который выполняет задачи CI/CD
.gitlab-ci.yml — файл конфигурации пайплайна в корне проекта

Когда вы пушите код в репозиторий, GitLab автоматически запускает пайплайн согласно настройкам в .gitlab-ci.yml. Runner подхватывает задачи и выполняет их: сборка, тестирование, деплой. Всё это происходит в изолированных контейнерах или виртуальных машинах.

Подготовка сервера Ubuntu

Для начала нам понадобится сервер с Ubuntu 20.04 LTS или новее. Если у вас ещё нет подходящего сервера, можете заказать VPS или выделенный сервер под свои нужды.

Обновляем систему и устанавливаем необходимые пакеты:

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl openssh-server ca-certificates tzdata perl
sudo apt install -y postfix # выбираем "Internet Site" при установке

Добавляем официальный репозиторий GitLab:

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

Устанавливаем GitLab Community Edition:

sudo EXTERNAL_URL="http://your-domain.com" apt install gitlab-ce

Замените your-domain.com на ваш домен или IP-адрес. После установки GitLab автоматически настроит конфигурацию.

Настройка GitLab Runner

Теперь устанавливаем GitLab Runner — это можно сделать как на том же сервере, так и на отдельной машине:

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
sudo apt install gitlab-runner

Регистрируем Runner в GitLab:

sudo gitlab-runner register

Вам понадобится:

URL GitLab (например, http://your-domain.com/)
Registration token (найдёте в Admin Area → Runners)
Описание Runner’а
Теги (опционально)
Executor — выберите “docker” для максимальной гибкости
Default Docker image — можете указать “alpine:latest”

Создание .gitlab-ci.yml файла

Основа любого CI/CD пайплайна — это файл .gitlab-ci.yml. Вот пример базовой конфигурации для веб-проекта:

stages:
  - build
  - test
  - deploy

variables:
  DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

build:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $DOCKER_IMAGE .
    - docker push $DOCKER_IMAGE
  only:
    - main
    - develop

test:
  stage: test
  image: node:16
  script:
    - npm install
    - npm run test
  artifacts:
    reports:
      coverage: coverage/
  only:
    - main
    - develop

deploy_staging:
  stage: deploy
  image: alpine:latest
  before_script:
    - apk add --no-cache openssh-client
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
  script:
    - ssh -o StrictHostKeyChecking=no $DEPLOY_USER@$STAGING_SERVER "docker pull $DOCKER_IMAGE"
    - ssh -o StrictHostKeyChecking=no $DEPLOY_USER@$STAGING_SERVER "docker-compose up -d"
  environment:
    name: staging
    url: https://staging.your-domain.com
  only:
    - develop

deploy_production:
  stage: deploy
  image: alpine:latest
  before_script:
    - apk add --no-cache openssh-client
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
  script:
    - ssh -o StrictHostKeyChecking=no $DEPLOY_USER@$PROD_SERVER "docker pull $DOCKER_IMAGE"
    - ssh -o StrictHostKeyChecking=no $DEPLOY_USER@$PROD_SERVER "docker-compose up -d"
  environment:
    name: production
    url: https://your-domain.com
  when: manual
  only:
    - main

Настройка переменных окружения

Для работы пайплайна нужно настроить переменные в GitLab. Идём в Settings → CI/CD → Variables и добавляем:

SSH_PRIVATE_KEY — приватный ключ для подключения к серверу
DEPLOY_USER — пользователь для деплоя
STAGING_SERVER — IP или домен staging сервера
PROD_SERVER — IP или домен production сервера

Приватный ключ можно сгенерировать так:

ssh-keygen -t rsa -b 4096 -C "gitlab-ci@your-domain.com"
cat ~/.ssh/id_rsa # приватный ключ — в переменную
cat ~/.ssh/id_rsa.pub # публичный ключ — на сервер деплоя

Практические кейсы и решения

Давайте разберём несколько реальных сценариев использования:

Сценарий	Решение	Плюсы	Минусы
Деплой Laravel приложения	Composer install, миграции, кэширование	Быстрый деплой, автоматические миграции	Нужно настроить очистку кэша
Деплой React SPA	npm build, nginx static files	Лёгкий деплой, CDN friendly	Нужно настроить роутинг
Микросервисы на Docker	Docker build, kubernetes deploy	Масштабируемость, изоляция	Сложность настройки

Продвинутые настройки

Для более сложных проектов можно использовать дополнительные возможности:

Parallel jobs

Для ускорения сборки можно распараллелить задачи:

test:
  stage: test
  parallel: 4
  script:
    - npm run test:split -- --index $CI_NODE_INDEX --total $CI_NODE_TOTAL

Cache и artifacts

Настройка кэширования для ускорения сборки:

cache:
  paths:
    - node_modules/
    - .npm/
  key: 
    files:
      - package-lock.json

Review apps

Автоматические тестовые окружения для каждого merge request:

review:
  stage: deploy
  script:
    - echo "Deploying review app for $CI_COMMIT_REF_NAME"
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://$CI_COMMIT_REF_NAME.review.your-domain.com
    on_stop: stop_review
  only:
    - merge_requests

Мониторинг и отладка

Для мониторинга состояния CI/CD используйте встроенные инструменты GitLab:

Pipeline graphs — визуализация этапов
Job logs — детальные логи выполнения
Metrics — статистика производительности
Notifications — уведомления в Slack/email

Для отладки проблем с Runner’ом:

sudo gitlab-runner list
sudo gitlab-runner verify
sudo gitlab-runner status
sudo journalctl -u gitlab-runner

Сравнение с альтернативами

Рассмотрим основные альтернативы GitLab CI/CD:

Решение	Плюсы	Минусы	Лучше для
GitHub Actions	Интеграция с GitHub, marketplace	Только cloud, лимиты	Open-source проектов
Jenkins	Много плагинов, гибкость	Сложная настройка, старый UI	Enterprise окружений
GitLab CI/CD	Всё в одном, self-hosted	Ресурсоёмкий	Полного контроля
Drone CI	Docker-native, лёгкий	Меньше функций	Микросервисов

Безопасность CI/CD

Несколько важных аспектов безопасности:

Secrets management — используйте переменные GitLab, никогда не коммитьте секреты
Runner изоляция — используйте Docker executor для изоляции
Права доступа — настройте минимальные права для deploy пользователя
Аудит — включите логирование всех действий

# Создание deploy пользователя с минимальными правами
sudo useradd -m -s /bin/bash deploy
sudo usermod -aG docker deploy
sudo -u deploy ssh-keygen -t rsa -b 4096

Автоматизация и скрипты

Для автоматизации рутинных задач можно создать вспомогательные скрипты:

#!/bin/bash
# deploy.sh - скрипт для деплоя
set -e

echo "Starting deployment..."

# Backup current version
docker-compose exec app php artisan backup:run --only-db

# Pull new image
docker-compose pull

# Update containers
docker-compose up -d

# Run migrations
docker-compose exec app php artisan migrate --force

# Clear cache
docker-compose exec app php artisan cache:clear
docker-compose exec app php artisan config:cache

echo "Deployment completed successfully!"

Интеграция с внешними сервисами

GitLab CI/CD отлично интегрируется с различными внешними сервисами:

Slack — уведомления о статусе деплоя
Sentry — мониторинг ошибок
Datadog — метрики производительности
Jira — автоматическое закрытие задач

Пример интеграции со Slack:

notify_slack:
  stage: deploy
  script:
    - 'curl -X POST -H "Content-type: application/json" 
      --data "{\"text\":\"Deployment to production completed successfully!\"}" 
      $SLACK_WEBHOOK_URL'
  when: on_success
  only:
    - main

Производительность и оптимизация

Для оптимизации скорости работы CI/CD:

Используйте кэширование — особенно для зависимостей
Параллелизация — разбивайте тесты на несколько job’ов
Оптимизируйте Docker образы — используйте multi-stage builds
Настройте local Registry — для быстрого доступа к образам

Пример оптимизированного Dockerfile:

# Multi-stage build for faster CI/CD
FROM node:16-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:16-alpine AS runtime
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
EXPOSE 3000
CMD ["npm", "start"]

Заключение и рекомендации

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

Основные рекомендации:

Начните с простого пайплайна и постепенно усложняйте
Используйте Docker для изоляции и воспроизводимости
Настройте мониторинг и алерты с первого дня
Не забывайте про безопасность — особенно управление секретами
Регулярно обновляйте GitLab и Runner’ы

GitLab CI/CD отлично подходит для команд любого размера — от solo разработчиков до enterprise компаний. Главное преимущество — полный контроль над процессом и возможность кастомизации под любые нужды. Если вы работаете с чувствительными данными или просто хотите держать всё под контролем, self-hosted GitLab — отличный выбор.

Для получения дополнительной информации рекомендую изучить официальную документацию GitLab CI/CD и документацию по GitLab Runner.

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

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