Есть докеровский рой. В нем 3 железки. Поднято 3 менеджера для отказоустойчивости. Внутри на данный момент работает nginx->php. И прочие для этого дела сервисы.
Мне нужно, что бы через одну железку приходили подключения на боевой сайт, через другую велась разработка. Порт везде 80. По идее nginx должен быть поднят как для боя, так и на машинке для разработчиков, что бы когда велась разработка тут же иметь доступ к загруженным файлам. Ну и в идеале иметь их изолированными друг от друга. Но сварм, открывает для сервиса порт на всех железках кластера. И получается я не могу запустить 2 nginx в одном кластере. Тут же есть решение использовать ключ mode = host. Но в таком случае не получится сделать красивый рестарт сервиса, что бы клиенты этого не заметили. Реализуется это с помощью order: start-first (докер ругается, что нет доступной ноды, ну это и понятно). То есть стартует новый сервис, а старый тем временем дообслуживает подключившихся клиентов...
Хотел влезть в iptables и там через dnat разрулить все это дело, но как я понял что ip адреса задать тоже не получается, поэтому эта идея отвалилась (.
Поднимать прокси для этого и им разруливать порты? Не создаст ли это дополнительно сильную нагрузку на сеть? Может есть какие то еще решения?
> По идее nginx должен быть поднят как для боя, так и на машинке для разработчиков
Плохая идея. В вашем кластере должен быть один сервис прослушивающий соединения на 80 порту, не важно Nginx это или что угодно. Чтобы решить вашу проблему и маршрутизировать запросы, можно использовать разные порты, что абсолютно дилетантски, или матчить запросы в Nginx:
example.com
dev.example.com // как я понимаю слушает только 192.168...
или
example.com/
example.com/dev // imho не удобно
Ну да, на разных ip они висят, на разных железках... Как в первом варианте так и сделано. Да я понимаю, что раскидывать сервисы по портам, потом делать пробросы на эти порты не очень веселое занятие :). К тому же придется еще и iptables конфиги мучать дополнительно...
На самом деле там не только 80 порт, там и 443 тоже. Но это ладно. я могу настроить все на одном nginx. Но если в дальнейшем появляются еще сайты? Если nginx по не понятным или понятным причинам помер один, у меня всегда будет бэкап его на разработке для каких то важных задач.
Не очень хотелось бы все в один сервис пихать, как то бы по группам это все раскидывать. А то обслуживать такую гору конфигов в одном месте не удобно. Сейчас там грубо 10 поддоменов, у каждого конфиг, у каждого сертификаты и прочее.... Уже под 300 строк конфиг. Это только девелоперский...
связка типа proxy->nginx->php меня пока не вдохновляет тоже. Мне еще по факту надо второй боевой сервер сделать бэкапом первого. Но опять же если поднимать 2 реплики nginx то лишний трафик будет в локалку гоняться...
К тому же в идеале иметь возможность использовать несколько внешних ip адресов на интерфейсе и каждый из можно было бы зарулить в свой nginx. Ведь иметь мощный кластер и ограничиться, может 5 - 10 серверов и ограничится 1 nginx на все как то не очень разумно...
Средний
