какие?

я в итоге так и не понял каке решение лучшее из того что есть сейчас

я в итоге так и не понял каке решение лучшее из того что есть сейчас

смотря сколько вы шлете

больше 10k в сутки?

в разное время?

понятно оверхед есть у ssmtp - так понял он балком слать не умеет

оно вам критично?

если нет - зачем что-то мудрить

если критично - ну шлите почту через апи

выше же все расписали

https://sendgrid.com вот такую штуку в одном стартапе юзали.

смотря сколько вы шлете

у ssmtp есть универсальное решение чтобы тупо направить всю почту на релей без всяких логинов и паролей в конфиге?

не критично, но пока думаю хорошо ли в каждом контейнере настраивать ssmtp

кто испольузет consul terraform ?

у ssmtp есть универсальное решение чтобы тупо направить всю почту на релей без всяких логинов и паролей в конфиге?

ну а почему нет то, если ваш релей примет без авторизации, то он может и так слать

Есть какая-то разница внутри виртуальной машины докер или на физическом линуксе? Насколько я понимаю никакой

Есть какая-то разница внутри виртуальной машины докер или на физическом линуксе? Насколько я понимаю никакой

не используйте docker как замена VM, это больно и неправильно!!!!

Есть какая-то разница внутри виртуальной машины докер или на физическом линуксе? Насколько я понимаю никакой

Никакой, разве что, если какие либо ограничения наложены на виртуальный инстанс, то они наследуются и для всех контейнеров,соответственно.

не используйте docker как замена VM, это больно и неправильно!!!!

Мне кажется, вопрос был не совсем об этом.

Да, не об этом...

Спасибо, короч

кто испольузет consul terraform ?

кто испольузет consul terraform ?

так консул или терраформ?

вместе

вместе

а в чем вопрос?

в том как это все разворачивают

на хабре писали что начиная с 1.12 меняется подход

на забре была статья четта там свое облако за 5 минут и пример разворачивания через ансибл

а потом недавно вышла статья что с 1.12 что то поменяли и многое уже можно не использовать

на хабре писали что начиная с 1.12 меняется подход

террафрм разворачивать не надо - это тула. в консуле тоже ничего не поменялось за последние 40 летю рафт он и в африке рафт.

я как то так понял

я про разворачивание всего комплекса а н про тераформ )

всего комплекса чего?

у всех свои комплексы

на основе консула и сопутствующих сервисов

принцип то построения один

принцип построения чего?

в зависимости от того что вы строите будет и принцип свой

блин ну есть группа контейнеров и гуппа серверов

и все это разворачивается

что у други ка кто подругому что ли?))

да, бывает по разному

у когото 10 серверов у кого то 1 ё

это не менет основную логику

это не менет основную логику

меняет. ох как меняет.

не меняет

кто-то пачку приватных сетей делает, кто-то шарит общедоступные контейнеры, кто-то вообзе все пихает в один контейнер. у всех все по разнмоу

не меняет

вам виднее.

если подходитьс запасом на многосервеност - не меняется ничего

сети, все в один контейнер это уже второстепенное

если подходитьс запасом на многосервеност - не меняется ничего

ничего не меняется относительно чего? не очень понимаю

основная задача это разворачивание на серверах группы контейнеров

вот старая статья https://habrahabr.ru/post/264269/

основная задача это разворачивание на серверах группы контейнеров

смотрите/читайте в сторону куба и мезоса

вот поноввее https://habrahabr.ru/company/centosadmin/blog/310606/

Обе статьи - говно.

там пишется про старый путь и новый

Если вы закладываетесь хотя бы на 100 серверов - кубернетес.

в новом укзывается что в новой версии произошли изменения

я не против статей получше

я только эти нашел

там в инвентори имена с дэшем, что как бы намекает...

ERROR: S client not available

https://blog.dataloop.io/kubernetes-vs.-mesos-vs.-swarm

Kubernetes лавно смотрел, не остановился, может не понял на тот момент его )

почтаю

Кубер сложнее в установке и поддержке, трубет больше ресурсов, но он умеет работать на тысячах железок. А сварм я бы не рискнул так масштабировать

у меня пока 3 железки

https://www.linux.com/news/5-container-service-tools-you-should-know-about > Google Container Engine, which is built on Kubernetes

https://blog.docker.com/2016/02/containers-as-a-service-caas/

http://techgenix.com/swarm-kubernetes-mesos/

Кубер сложнее в установке и поддержке, трубет больше ресурсов, но он умеет работать на тысячах железок. А сварм я бы не рискнул так масштабировать

под ресурсами что понимается? железо, часы?

И то и то

а целесообразно его при 3-5 машинах использовать?

ИМХО нет, но есть любители

у меня 3 машины должны зеркально работать

а целесообразно его при 3-5 машинах использовать?

а сколько у вас их будет через год?

и впереди балансировщик

больше не будет

контейнерв будет больше

мне пока нужно реализовать автоматичесукую сборку и выкладку

ну и мониторинг с бекапами )

Удачи, чо :)

дык какое решение лучше для такой задачи?

сварм 1.13

дык какое решение лучше для такой задачи?

Которое лучше знаете

начинать лучше со сварма

изучение

остальные - гораздо сложнее

ИМХО, потмоу что нажраться говна можно в любом из них

ну вотя и начал, мнение зала засрало это решение )

Вы задачу сформулировади странно потому что

сделать 3 сервера - это не то же самое что закладываться на масщтабируемость