Многоплатформенные проекты (Web, мобильные, микросервисы) требуют гибкой и надёжной системы CI/CD. В статье сравниваются два популярных решения – GitHub Actions и GitLab CI – и показывается, как интегрировать их с docker-compose для единообразного окружения.
Почему Docker‑Compose?
Docker‑Compose позволяет описать весь стек (БД, кеш, брокеры, сервисы) в одном файле и запускать его как локально, так и в CI‑пайплайне. Это упрощает:
- Тестирование интеграций.
- Переиспользование конфигураций между разработкой и продакшном.
- Изоляцию окружения.
GitHub Actions: базовая конфигурация
Пример workflow, который собирает Docker‑образ, запускает docker-compose up, выполняет тесты и публикует образ в Docker Hub.
name: CI/CD for Multi‑Platform Project
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build-test-deploy:
runs-on: ubuntu-latest
services:
docker:
image: docker:20.10-dind
privileged: true
steps:
- name: Checkout repository
uses: actions/checkout@v3
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2
- name: Log in to Docker Hub
uses: docker/login-action@v2
with:
username: ${{ secrets.DOCKER_HUB_USER }}
password: ${{ secrets.DOCKER_HUB_TOKEN }}
- name: Build and push Docker image
uses: docker/build-push-action@v3
with:
context: .
push: true
tags: ${{ secrets.DOCKER_HUB_USER }}/my‑app:${{ github.sha }}
- name: Set up Docker Compose
run: |
sudo apt-get update && sudo apt-get install -y docker-compose
- name: Run integration stack
run: |
docker-compose -f docker-compose.yml up -d
docker-compose -f docker-compose.yml exec -T app python -m pytest tests/
- name: Deploy to production (optional)
if: github.ref == 'refs/heads/main'
run: |
echo "Deploy step – could trigger Helm, K8s, or SSH scripts"
GitLab CI: базовая конфигурация
Аналогичный пайплайн в GitLab CI, использующий встроенный Docker‑executor и docker-compose.
stages:
- build
- test
- deploy
variables:
DOCKER_DRIVER: overlay2
build_image:
stage: build
image: docker:20.10
services:
- docker:20.10-dind
script:
- docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
test_integration:
stage: test
image: docker/compose:1.29.2
services:
- docker:20.10-dind
script:
- docker-compose -f docker-compose.yml up -d
- docker-compose -f docker-compose.yml exec -T app python -m pytest tests/
- docker-compose -f docker-compose.yml down
deploy_production:
stage: deploy
image: alpine:latest
only:
- main
script:
- echo "Deploy to production – trigger Kubernetes, Helm or custom scripts"
Сравнительная таблица
| Критерий | GitHub Actions | GitLab CI |
|---|---|---|
| Интеграция с репозиторием | Нативна для GitHub, простая настройка через UI | Тесно связан с GitLab, единый UI для репо и CI |
| Стоимость | Бесплатные минуты ограничены, платные runner‑ы | Бесплатные минуты в публичных проектах, платные для приватных |
| Поддержка Docker‑in‑Docker | Требует отдельный сервис‑контейнер | Встроенный Docker‑executor, проще конфигурировать |
| Кастомные runners / agents | Self‑hosted runners, но требуется отдельный сервер | Shared и специфические runners, легко масштабировать |
| Хранилище артефактов | Artifacts в рамках workflow, ограничено размером | Artifacts в job‑ах, более гибко с кешированием |
Лучшие практики
- Разделяйте сборку и тесты. Сначала собирайте образ, затем используйте один и тот же образ в тестовой фазе.
- Кешируйте зависимости. В GitHub Actions –
actions/cache, в GitLab CI –cache:секция. - Не храните секреты в репозитории. Используйте
Secrets(GitHub) илиCI/CD variables(GitLab). - Отключайте сервисы после тестов.
docker-compose downгарантирует чистое окружение. - Параллелизм. Запускайте отдельные сервисы в разных джобах, если они независимы.
Когда выбирать GitHub Actions, а когда GitLab CI
GitHub Actions идеален, если ваш код уже хранится в GitHub, вы цените простоту UI и хотите быстро настроить небольшие пайплайны без отдельного сервера CI.
GitLab CI предпочтительнее для крупных корпоративных решений, где требуется глубокая интеграция с управлением проектом, более гибкое кеширование и возможность использовать собственные GitLab‑раннеры в закрытой сети.
Заключение
Оба инструмента способны обеспечить надёжный CI/CD для многоплатформенных проектов с Docker‑Compose. Выбор зависит от экосистемы вашего проекта, бюджета и требований к гибкости.
Услуги RybinskLab
RybinskLab предлагает профессиональную настройку CI/CD, миграцию между GitHub Actions и GitLab CI, разработку Docker‑Compose инфраструктур и поддержку DevOps процессов под ключ. Обращайтесь для ускорения доставки вашего продукта.