Сейчас я работаю над сценарием использования CoreOS. Вероятно, это не вариант использования первого класса. Но я бы хотел получить указатель, если он действителен. Поскольку я действительно только начинаю разбираться в CoreOS, я надеюсь, что мой «вариант использования» не совсем верен.
Представьте себе многопользовательское приложение, в котором каждый клиент должен получить собственную среду выполнения. Давайте возьмем веб-приложение, работающее на Node.js и PostgreSQL для хранения данных, как указано. Каждая среда клиента будет работать на CoreOS в своих контейнерах. Сохранение данных пока не учитывается. Для меня в настоящее время это больше касается общей осуществимости.
Так почему же CoreOS?
В настоящее время я стараюсь придерживаться идеи разделения сред на каждого арендатора. Чтобы оптимизировать плотность экземпляров БД и веб-серверов на каждом аппаратном хосте, я подумал, что CoreOS может быть правильным выбором вместо «классической» виртуализации.
Другая причина заключается в том, что многим арендаторам может потребоваться не более одного небольшого экземпляра БД и одного небольшого веб-сервера. Но могут быть и другие арендаторы, которым требуется постоянно масштабируемое развертывание. Другим может потребоваться временное масштабирование во время всплеска. CoreOS здесь тоже неплохо подходит.
С другой стороны, должна быть масштабируемая инфраструктура обмена сообщениями (RabbitMQ), которая будет обрабатывать большое количество сообщений. Эта инфраструктура будет использоваться всеми арендаторами и должна в лучшем случае динамически масштабироваться. Возможно, появится и «масштабируемая» инфраструктура Elasticsearch. Если смотреть через мою текущую «CoreOS для всего», это тоже кажется хорошим подходом.
В случае, если весь этот сценарий в целом верен, в настоящее время я не могу понять, как можно было бы направить трафик для общедоступного веб-сайта в различные контейнеры-арендаторы.
Представьте, что приложение работает на app.greatthing.tld. Пользователь может войти в систему, и ему должно быть представлено приложение, обслуживаемое его клиентом. Это что-то, что нужно решить Socketplane и / или Flannel? Или как могло бы выглядеть решение, чтобы арендатор обслуживал нужные контейнеры? Я думаю, это вопрос общего характера. Но, по крайней мере, в контексте контейнерной среды CoreOS я вообще не понимаю, как с этим справиться.
Похоже, ваша главная проблема - маршрутизация. Вам нужно будет настроить какой-то уровень маршрутизации, который является точкой входа в кластер, считывает заголовок хоста и перенаправляет трафик в соответствующий контейнер (ы). Обычный способ сделать это - запустить confd + nginx в контейнере.
Вторая часть состоит в том, чтобы ваши бэкэнд-контейнеры «объявляли» о себе, то есть записывали некоторые данные в etcd, когда они активны и прошли проверку работоспособности. Это позволяет вам перемещаться по серверным модулям при развертывании новых версий, масштабировании и т. Д.
Итак, как вы это развернете? Во-первых, проверьте кластерные архитектуры док. Я бы взял подмножество ваших машин и поместил их за облачным LB (или сделал циклический DNS), который указывает на ваши контейнеры маршрутизации, работающие на 80/443. Затем они перенаправляют трафик из инфракластера в соответствующий бэкэнд.
Нет необходимости использовать фланель или другие сетевые проекты, если вы просто сохраняете комбинацию IP / порта серверной части для подключения.