Я хочу иметь возможность разрабатывать микросервисы локально, но и «подталкивать» их к производству с минимальными конфигурационными изменениями. Я использовал все микросервисы в одном docker-compose локально; но я начинаю понимать, что это не может быть практическим.Docker-compose на микросервис в местных и производственных помещениях?
Новая идея состоит в том, чтобы иметь один докер-состав за услугу. Это не означает, что он будет работать только с одним контейнером; он может иметь больше внутри (например, какой-то хранилище данных и т. д.).
С этой новой точки зрения, давайте взглянем на известный docker voting app example, которые состоят из 5 компонентов:
- (P) Python WebApp, который позволяет голосовать между двумя вариантами
- (R) очереди Redis, которая собирает новые голоса
- (J) Java работник, который потребляет голоса и сохраняет их в ...
- (S) Postgres база данных поддерживается объемом Докер
- (N) Node.js WebApp, который показывает результаты голосования в режиме реального времени
Допустим, вы хотите, чтобы подтолкнуть этот пример в производство (поэтому иметь только один docker-compose не вариант :). Не забывайте, что над ним могут быть добавлены дополнительные компоненты, связанные с инфраструктурой (например, кибана, прометей ...). И мы хотим иметь возможность масштабировать то, что нам нужно; и мы используем, например, роя.
Возникает вопрос:
- Как организовать этот пример: в одном
docker-composesили много? - Какие микросервисы у нас есть? Другими словами, какие компоненты вы бы объединили в один
docker-compose? Пример: J и S? - Если услуги не состоят в одиночной компоновке докеров, добавим ли они их в одну и ту же сеть наложения, чтобы использовать функцию swarm dns?
- и так далее ...
(мне не нужна подробности о том, как установить вещи, этот вопрос об организации верхнего уровня)