Планируется 3 боевых сервера + 3 реплики этих боевых в другом датацентре. Все сервера пока изолированны друг от друга. На каждом будут запущены nginx+php+mysql с отдельными проектами. Все конечно же в докере ибо для меня оно так уже гораздо проще. Сейчас прототип этой схемы есть он работает через docker-compose но надо переезжать и мысль подумать как сделать лучше.
Один кластер nomad + consul у меня есть и думал натянуть эту схему и сюда, что бы по-простому заливать нужные мне контейнеры на боевые и резервные сервера и проще контролировать весь это процесс (к тому же потом может один проектов вырастет и будет уже не только на одном сервере) . Но вот мудрить кластер из 3 мастер серверов nomad серверов совсем нет желания. Хотелось бы в начале сделать 1 мастер и он отправляет на всех задачи. Но тут есть пара моментов. Что если мой мастер помер (мастер на виртуалке будет и я довольно быстро все верну из бэкапов)? Продолжат ли работать уже запущенные контейнеры на клиентах? И вообще стоит ли шкура выделки? :).
Можно было бы и поднять конечно полноценный кластер но нужно ли оно если и так все будет хорошо работать? И минус до Мастера с каждого сервера у меня будет туннель шифрованный и все взаимодействие будет идти по этому туннелю, а вот если несколько мастеров тогда тут туннелей не напасешься придется через внешку гнать трафик не совсем секьюрно :)
Ну и по логике не совсем понятно как это все разделить...
Или ну его нафиг оставить докеркомпос да не парится? :)
Максим Федоров, Обычно запускаю только на небольших проектах но для контроля версий очень удобно. Тут 2 момента, не давать докеру что бы он кильнул сервер раньше чем он остановится когда мы хотим его остановить. Но это тоже к большим проектам относится где база может стопится по несколько минут и вынести дату за пределы докера. а так думаю как раз таки оверфлоу почти не будет.
Просто очень удобно, разработчики там говорят мне нужно такое то окружение, фигась им сделал все что надо даже не подходя к конкретному серверу, чисто пульта управления :). Ну и развитие дальнейшее. Уже раз поднял как то докер сварм и уперся что он сетку свою виртуальную не может больше 100 мегабит раскочегарить, тормоза начинаются. Ну и все поехали на номэд все переводить еще 2 недели работы...
Станислав Бодро́в, Ну вот тот нативный механизм после 100 мегабит загрузки начинает тайминги приличные давать :). Мы перевели кластер все чудно было, потопу мемкэш я запустил и поехали тормоза, сначала долго понять не могли что за фигня то, но потом вьехали )
Максим Федоров, база в докере не так страшна. Обычно для данных монтируется в контейнер отдельный диск и работает оно себе спокойно. Проверено неоднократно во многих продах. И не так страшон докер с базой (оговорюсь, всё сделано по уму и проверено -- но это касается любых решений с базами), как запросы наскоро набросанные в ORM или не протестированные миграции.
Есть куда более забавные проявления, правда в них контейнеризация лишь постольку поскольку. Когда в кубах пытаются изобразить мультимастерные кластера баз данных на базе Мускула или Пострге. Очень феерическое зрелище.
Станислав Бодро́в, я на предыдущей работе наткнулся на 2 мастера и vrrp между ними. Потом почитал почему так лучше не делать и оставил мастер слейв. В конце концов переключить совсем не проблема, а вот когда данные как попало начнут писаться это уже хуже )
kiranananda, пробовали сравнивать разные режимы работы сетевой подсистемы контейнеров (bride, host, vxlan)? Ни докер, ни системы оркестрации не тянут за собой никаких сетевых приложений во время установки. Используют имеющиеся механизмы ОС: namespace, iptables, control groups, ...
Другой вопрос. Сетевая подсистема ОС с настройками по умолчанию или протюнингована и проверена?
Станислав Бодро́в, я попал только докерсвармом после этого все перевел в nomad и host. Настроил consul-template который конфигурит nginx само приложение разработчиков, указывает там адреса и порты мэмкшей и еще там нужных сервисов. В итоге получилось вообще без ингресов все напрямую. Тут конечно скорость хорошая :).
Ну настройки которые расширяют пропускную способоность конечно тюнили. Там нагрузка хорошая 3 сервера по 40 ядер, ну это по всему проекту. Без тюнинга просто даже количество tcp не потянет. А по поводу виртуальной сети поискал, что то в инете но толком ничего не нашел, инглин не идеальный все таки... (
В кубах не нравится одно то что там сплошные конфигуратор что бы поднять какое то решение. А досконально въехать в его работу это я пол году ухайдохаю. А вот если решение это по каким то причинам будет работать не так как надо, то тут придется на горячую руку как то все понять. Номад он попроще попонятнее. Может я что не так понимаю?
Станислав Бодро́в что если я буду использовать 1 мастер и он отвалится? Продолжит ли работать под? Хочется без ингресс напрямую под выпустить по 443 порту. Зачем лишняя прослойка в моем случае...
kiranananda, Отвечаю сам себе, да все будет работать если мастер помрет, только сам кластер и миграции соотвественно не будет работать, а все что запущено все будет продолжать работать в штатном режиме...
Так что наверное это будет хорошим решением использовать куб,
что если я буду использовать 1 мастер и он отвалится?
У мастера основная задача проверять чтобы текущее состояние соответствовало желаемому (декларативный подход) и выполнять изменения по этому поводу в кластере. Поэтому если он отвалится, то просто не будут выполняться эти проверки . С другой стороны, а чего ему вдруг падать? Если на мастере, кроме основных процессов ничего левого не стоит, падать ему особенно не от чего.
Хочется без ингресс напрямую под выпустить по 443 порту.
Не вопрос. Поднимаешь сервис в режиме node-ip и готово.
А досконально въехать в его работу это я пол году ухайдохаю.
И заметно поднимешь свою стоимость как специалиста на рынке труда.
А вот если решение это по каким то причинам будет работать не так как надо, то тут придется на горячую руку как то все понять.
Есть куча мануалов (лучше смотреть свежие) и minikube, где все довольно просто делается.
Судя по всему у тебя простая трёхзвенка без всяких навороченных решений типа менеджера очередей, кэша для запросов к базе, кластера самой базы (один мастер и куча читающих реплик) ну и вообще ни микросервисы. Поэтому особенных морок не предвидится.
Станислав Бодро́в, Ну да в этом проекте пока все просто, в дальнейшем они хотят переписать код сделанный на битриксе на нормальное решение, вот там может придется расширять на несколько виртуалок(решили не связываться с железом), что бы пропускную способность увеличить.
За миникуб спасибо гляну обязательно.
Да падение мастера это на случай падения виртуалки на хостере. А это если и будет то не надолго поэтому смысла в мультимастере не вижу...
Ну и конечно для меня проект должен быть интересным. Тупо делать реплику одного сервера в другой датацентр ну скукота :)...
И еще вопросик есть. Насколько безопасно делать все взаимосвязи куба через внешние IP адреса или лучше заморочиться и туннели поднять?
Станислав Бодро́в, Спасибо понял. Все таки покажу пальцем когда рег ру например взял и вернул виртуалку из бэкапа которой уже больше суток. Мне народ пишет что такое типа ты там закомитил что то у нас все изменения пропали нет говорю. Причем либо щас меня глючит либо даже аптайм не показывал перезагрузки...
Щас на вмваре будем хостить... Но все же заказчик говорит, а что на управляющий сервер давай его в резервном датацентре там дешевле. Ну вопросов нет, давай :). Потом не обижайся ))...
Станислав Бодро́в, так и я до последнего сопротивлялся ). Говорю сами накосячили ищите. Но это ладно работа разработчика пропала, так пропала еще и работа того кто сайт наполнял. ну тут думаю точно что то не ладно ). У меня таких хитрых скриптов нету :)
