Refguser, товарищ про 169.254 (APIPA), которая работает и без DHCP. Но эти адреса устанешь запоминать, статически заданные значительно удобнее, как по мне.
Александр Маджугин, не знаю, что сложного периодически запускать одной командой плейбук по нужным узлах. альтернатива - всё это делать руками и, разумеется, в какой-то момент оно разъедется.
h7n14, есть два варианта:
1. keepalived на каждом шлюзе (если они это позволяют) - тогда да, скрипту придётся менять конфиги в зависимости от состояния узла.
2. keepalived на каком-то отдельном узле (или узлах), опрашивающем ваши шлюзы - тогда конфиг понадобится один, просто меняющий маршрут через этот узел.
Владимир Алексеев, если бы мне соискатель вместо одного Докерфайла прислал аккуратный Компоуз-проект со всей нужной структурой файлов и каталогов - я бы это оценил значительно выше :)
Анна Г, мы вернулись в начало - "приходит запрос от пользователя - что-то начинает запускаться". Это никогда не будет работать быстро.
> извините но парадигмы не для того чтобы тупо им следовать.
Сейчас я вижу, как вы тупо следуете избранному плану, пытаясь не замечать его недостатков.
> делать разные контейнеры под разные исполняющие среды просто глупо т.к. они будут простаивать большую часть времени.
Ну, а сейчас у вас простаивает вся виртуалка, невелика разница - только когда приходит пользователь, ему ещё приходится подождать, пока оно там с нуля развернётся.
Поскольку у ваших "однотипных контейнеров" внутри каждого СУБД - это огромный оверхед по памяти, а следовательно - этих самых контейнеров значительно меньше, чем могло быть, сделай вы один общий Постгрес. Ну, или виртуалка значительно жирнее, чем могла быть для той же нагрузки - и вы впустую тратите деньги.
Анна Г, что точно неоптимально - так это держать помимо СУБД ещё и другие вещи в том же контейнере :)
Это прямо противоречит всей парадигме контейнеризации, плюс вы не знаете, сколько может потребоваться памяти для СУБД + запущенных рядом скриптов, отсюда и возможные ООМ, которых очень легко избежать.
Анна Г, если Постгрес настроен нормально - пользователь без админских прав никогда ООМ не сделает.
Много мелких СУБД - это конечно, лучше в плане изоляции (хотя если выдавать пользователю права только на свою БД, тоже будет нормально), но гораздо хуже в плане производительности. Одна СУБД с большим количеством CPU и памяти будет работать значительно оптимально.