Правильный способ развертывания docker сервисов через Gitlab CI / CD на собственный сервер - PullRequest
Новая
       103

Правильный способ развертывания docker сервисов через Gitlab CI / CD на собственный сервер

0 голосов
/ 17 января 2020

Мое приложение создается с использованием 3 Docker сервисов:

  • backend (React)
  • frontend (Node.js)
  • nginx (маршрутизация traffi c)

До сих пор я вручную входил в систему на собственном сервере Digital Ocean, клонировал репозиторий и запускал службы с помощью docker-compose build && docker-compose up.

Я хочу автоматизировать процесс с этого момента.

Учитывая Gitlab CI / CD Pipelines и бегуны, , что было бы лучшим подходом для автоматического развертывания код для сервера Digital Ocean ?

[О чем я думал, может показаться очень «новичком»]

Идея 1: Как только коммит был передан мастеру -> Gitlab runner создаст службы и затем скопирует их на сервер DO через scp. Проблема: как вы запускаете сервисы? Вы подключаетесь к серверу DO через ssh от бегуна, а затем запускаете там стартовый скрипт?

Идея 2: Зарегистрировать работника на сервере DO, чтобы при извлечении данных из Gitlab он имел код на самом сервере DO. Просто нужно их построить и запустить. Но этот подход не масштабируемый и кажется хакерским.

Я ищу некоторые руководящие принципы мышления или пошаговый подход.

1 Ответ

0 голосов
/ 17 января 2020

Одним из преимуществ использования Docker в сценарии производственного развертывания является то, что вы не отдельно scp код своего приложения; все, что вам нужно, встроено в образ.

Если вы используете систему автоматизации, такую ​​как Ansible, которая может напрямую запускать контейнеры на удаленных хостах , то это просто. Ваша система CI создает Docker изображений, маркирует их с помощью уникальной метки версии и отправляет их в хранилище (Docker Hub, который предоставляется вашим облачным провайдером, который вы запускаете самостоятельно). Затем она запускает систему автоматизации, чтобы сообщить ей о запуске контейнеров с созданным вами образом. (В случае Ansible он работает с s sh, так что это более или менее эквивалентно другим опциям на основе s sh; для таких инструментов, как Chef или Salt Stack, требуется целевой агент в целевой системе. )

Если у вас нет подобной системы автоматизации, но в целевой системе установлены s sh и Docker Compose, то вы можете скопировать только docker-compose.yml файл на целевой хост, а затем запустите его. 

TAG=...
docker push myname/myimage:$TAG
scp docker-compose.yml root@remote:
ssh root@remote env TAG=$TAG docker-compose up -d

Еще один вариант - использовать выделенный менеджер кластеров, такой как Kubernetes, и поговорить с его API; тогда кластер сам извлечет обновленные контейнеры, и вам не нужно ничего делать sh. В обсуждаемой шкале это, вероятно, намного более тяжелый вес, чем вам нужно.

...