Я недавно начал использовать ранчо для проекта. За несколько дней я установил стандартную микросервисную архитектуру с 4 базовыми сервисами (размещенными на Digital Ocean), пытаясь сделать ее максимально готовой к работе.
Услуги:
- API-шлюз
- GraphQL Api
- Сервер OAuth2
- Внешний интерфейс
он также включает балансировщики нагрузки, проверки работоспособности и т. д.
Я поражен тем, насколько он хорош, поэтому я активно использовал все функции, предоставляемые ранчо в моих конфигах, например, соглашения DNS <service>.<stack>, помощники, компоновку ранчо и т. Д.
Вышеупомянутые службы находятся в собственном репозитории и имеют собственные Dockerfile, docker-compose.yml и rancher-compose.yml для производства, так что их можно развертывать независимо.
Теперь, когда я доказал, что владелец ранчо станет моим новым «другом», мне нужна стратегия, позволяющая запускать то же приложение в моей локальной среде и иметь возможность разрабатывать свои службы, как если бы я делал с < сильный> Бродяга.
Мне интересно, как лучше всего перенести приложение, работающее на rancher, в среду разработки.
У меня было несколько идей о том, как с этим справиться, однако ни одна из них, похоже, не позволила мне достичь этого без перенастройки всех сервисов для разработки.
1 - Владелец ранчо на локальной машине
Это мой первый подход: установить rancher-server и rancher-client локально и развернуть весь стек, как в производственной среде. Мне это показалось самой логичной идеей. Однако это не позволило мне изменить код сервисов и отражаться в контейнерах вживую. Возможно, использование общих томов может сработать, но мне это кажется тривиальным, если у вас есть какие-либо идеи, пожалуйста, дайте мне знать. Для меня этого решения больше нет :(
2 - Docker compose
Моя вторая попытка состояла в том, чтобы просто использовать docker compose и общие тома, опуская load balancers и все функции ранчера :( Однако это может сработать, мне нужно будет изменить все конфигурации всех моих служб, на которые они указывают к специфическому DNS-домену владельца ранчо <service>.<stack>, чтобы использовать только <service> через мостовую сеть.Но это означает поддержание двух разных конфигураций для разных сред, что странно и неинтересно делать.
3 - Бродяга
Поскольку второе решение уже запутано (двойная docker-compose и двойная конфигурация для сервисов), почему бы просто не воссоздать всю среду в бродяге (без функций ранчера, возможно, с недоступным), где один nginx выполняет обратный прокси и разрешает запросы между сервисами. Однако это требует также довольно много работы и снова двойных усилий :(
Есть ли какой-нибудь другой подход, который сделает ранчо подходящим для среды разработки безболезненно? Как компании, которые полагаются на ранчо или другие инструменты платформы, решили эту проблему?
