#docker #docker-compose #microservices #docker-registry
#docker #docker-compose #микросервисы #docker-registry
Вопрос:
Я работаю над приложением на основе архитектуры микросервиса. У меня есть
- N количество микросервисов
- Все находятся в docker
Docker Compose заботится о запуске и сборке. Сейчас проект находится на стадии, когда он должен быть развернут в перечисленных ниже средах,
- Разработка
- QA / Staging
- Предварительная подготовка
- Производство
Мой вопрос в том, как мне управлять образами всех микросервисов
- Должен ли это быть один реестр образов для одного микросервиса и всей среды?
- Должен ли это быть один реестр образов для всех микросервисов для всей среды?
- Должен ли это быть один реестр образов для одного микросервиса на среду?
- Должен ли это быть один реестр образов для всех микросервисов для каждой среды? Я имею в виду облачные сервисы AWS и GCP.
Я действительно не могу найти никаких рекомендаций по этой теме и не могу решить, как мне поступить. Я прошу вашего совета по этому поводу.
Спасибо, Дхирадж Кумар
Комментарии:
1. Прежде всего, вы должны использовать один и тот же ОБРАЗ для всех сред, поэтому, я думаю, вопрос не совсем корректен.
2. Ну, что я имею в виду, что образы, созданные для разработчиков и тестирования, будут иметь разные базовые изображения, например, ИЗ mcr.microsoft.com/dotnet/core/sdk а для производства — ИЗ mcr.microsoft.com/dotnet/core/aspnet надеюсь, это поможет, даже если я использую одно и то же изображение, как мне сохранить его в реестре?
Ответ №1:
Я бы использовал один реестр для всех сред. Будет слишком много возможностей для извлечения изображения, переназначения изображения и переноса изображения в новый реестр — слишком много вещей, которые могут пойти не так, и слишком мало значения.
Возможно, вам захочется создать отдельный реестр для разработки и другой реестр для «автоматизированных сред». С «автоматизированными средами», я имею в виду в CI / CD-конвейере, после того, как разработчик отправил код в Git, должны быть задания автоматической сборки. Причина такого разделения заключается в том, что вы можете захотеть иметь разные требования к аутентификации и отделять то, чему вы доверяете (например, сканируется), а не.
Вам не нужен отдельный реестр для каждого микросервиса, но вы можете захотеть иметь отдельный репозиторий для каждого микросервиса.