Какова лучшая практика для развертывания моего приложения на моем VPS с использованием Docker?

Question

У меня есть приложение (Python Flask), которое я хочу развернуть с помощью GitLab CI и Docker на моем VPS.

На моем сервере я хочу иметь рабочую версию и промежуточную версию моего приложения.Для обоих из них требуется подключение к MongoDB.

Мой план состоит в том, чтобы автоматически собрать приложение на GitLab и отправить его в Docker Registry GitLab.Если я хочу развернуть приложение в стадии подготовки или производства, я делаю docker pull, docker rm и docker run.

. Планируется сохранить конфигурацию (например, secret_key) в .production.env (и .staging.env) и передать его приложению, используя docker run --env-file ./env.list

У меня уже установлена ​​MongoDB на моем сервере, и обе среды приложений должны использовать один и тот же экземпляр MongoDB, но другое имя базы данных (настроено в .env).

Это лучшая практика для развертывания моего приложения?У вас есть какие-нибудь рекомендации?Спасибо!

Answer 1

Вот моя конфигурация, которая работала достаточно хорошо в разных организациях и размерах проектов:

Для постройки:

1. Приложения находятся в git-репозитории (GitLab в вашем случае). Каждое приложение имеет собственный Dockerfile.
2. Я использую Jenkins для сборки, вы, конечно, можете использовать любой другой инструмент для компакт-дисков. Дженкинс извлекает хранилище приложения, создает образ докера и публикует его в частном хранилище Docker ( Nexus, в моем случае).

Для развертывания:

1. У меня есть один центральный, независимый от приложения репозиторий с файлом docker-compose (или, возможно, несколькими файлами, которые расширяют один центральный файл для разных сред). Этот файл содержит все определения сервисов и ссылки на изображения докеров в моем репозитории Nexus.
2. Если я использую секреты, я сохраняю их в экземпляре HashiCorp Vault. Дженкинс тянет их и записывает в файл .env. Файл docker-compose может ссылаться на отдельные переменные среды.
3. Дженкинс извлекает репозиторий docker-compose и, в моем случае через scp, загружает файл (-ы) docker-compose и файл .env на мои серверы.
4. Затем запускается docker-compose up (для небольших приложений) или повторное развертывание стека докеров в рой (для более крупных приложений).
5. Дженкинс удаляет все с целевых серверов.

Если вам это нравится, вы можете выполнить шаг 3. через Docker Machine. Я чувствую, однако, что его преимущества не требуют использования в моих случаях.

Answer 2

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

Службы, находящиеся в сети, могут иметь несколько реплик, и всякий раз, когда вы обновляете службу (IE развертывает новый образ), рой будет заботиться о том, чтобы одна из них всегда была в сети.

docker service update <service name> --image <new image name>

Некоторые VPS-серверы на самом деле используют Kubernetes в качестве службы (например, Digital Ocean). Если это так, то это более предпочтительно. Gitlab на самом деле имеет функцию autodevops и может удаленно управлять вашим кластером Kubernetes, но вы также можете вручную развернуть его с помощью kubectl.