два домена , которые на него смотрят (нап. dev.test.com и staging.test.com).
dev.test.com должен матчиться с localhost:3000 , a staging.test.com c localhost:3001, это nodejs процессы , у каждого будет свой инстанс cockroachdb . Тут ясно, это разруливать лучше через nginx.
Если взять kubernetes, в нем запустить nginx, и потом два dоcker'а, т.е. для каждого nodejs+БД свой доккер. Это нормальная архитектура будет или ерунда какая-то ?
И еще планируется Gitlab CI + auto deploy, тут я вообще хз как это прилепить к выше описанному.
Маны покурить и всё получится
IMHO Лучше сделать один деплоймент, с одним портом, а Нод.ЖС пусть сам и разруливает
Ничего не понятно. Почему :3000, :3001, ты всё в один под хочешь запихнуть? Лучше растянуть в разные поды и просто ингресом распределять
текущая задача не выглядит сложной, но завтра надо будет 4 енва, потом 2,3,4,5 хостов, потом динамические енвайронменты. Если такое возможно то сразу танцуй с вокруг докера...
на гитлабе прям мануал есть как это делается) сегодня сам ковырялся https://docs.gitlab.com/ee/ci/environments.html
Привет , а почему Ingress не хочешь использовать ?
Да, но есть же ингресс
Нужен ли такой задачи кубернетес - сильно дискуссионный вопрос. Но в кубернетесе это выглядело б примерно так: Ставится ingress controller, эта такая штука которая может принимать запросы извне и по URL знать куда внутри кубернетеса их отправить . Этот контроллер следит за объектами с типом Ingress , это такой ямл/джосн в котором указаны правила какие запросы куда. Общая практика такая,что когда деплоится в куб новое приложение, оно с собой устанавливает этот самый Ingress , в котором говорит, например, все запросы пришедшие на dev.example.com слать мне.
Обсуждают сегодня