В этом вопрос?

Ты не можешь разобраться со своей жизнью?

Тебя понесло уже не в ту степь )

Ок - кратко. У меня есть мнение, что докер должен использоваться только для дистрибьюции исходного кода приложений и связных с ним компонентнов (не активных сервисов). Все персистентные хранилища не должны быть упакованы в докер.

такой вот вопрос был

Про атомарные еденицы... Атомарной еденицей в веб приложениях я считаю - исходный код приложения с определенной версией, интерпретатор, вебсервер. Это минмум. Если в этой атомарной еденице есть сбой - вся атомарная еденица идет а расход. Т.е. под снос.

Из балансеровщика она исключается.

звучит логично

Взамен же в 2016 году нам предлагают заменить это на хуллион докер контейнеров.

Не, тебя никто не обязыавет

(речь сейчас о продакшене)

Есть же всякие smell-baron's, baseimage, e.t.c.

Не, тебя никто не обязыавет

Нет, я просто разобраться хочу.

Честно.

> Если в этой атомарной еденице есть сбой - вся атомарная еденица идет а расход. Почему вся, а не только тот компонент который сбоит?

> Если в этой атомарной еденице есть сбой - вся атомарная еденица идет а расход. Почему вся, а не только тот компонент который сбоит?

Вот ты докер в продакшене используешь? Как ты будешь удалять связные контейнеры?

Или как ты будешь выяснять что именно у тебя сбой дало?

Из за сбоя в одном из докер контейнеров могут быть сайд-эффекты в других

> Или как ты будешь выяснять что именно у тебя сбой дало? так же как и во всех остальных случаях - по логам.

И снова - при использовании атомарной еденицы - она выключается полностью. Тогда вся остальная система удовлетворяет дизайну.

это зависит от архитектуры тогда. если слабосвязные компоненты - можно разделять. если сильносвязные - можно упаковать в один

> Или как ты будешь выяснять что именно у тебя сбой дало? так же как и во всех остальных случаях - по логам.

Молодец. Наслаждайся дальше неконсистентным продекшеном.

> Из за сбоя в одном из докер контейнеров могут быть сайд-эффекты в других Если речь о сайд-эффектах физической консистентности, то как раз не могут.

Контейнеры изолированы

> Из за сбоя в одном из докер контейнеров могут быть сайд-эффекты в других Если речь о сайд-эффектах физической консистентности, то как раз не могут.

И ты так до сих пор и не ответил, используется ли у тебя докер в продакшене.

нет

только в хоумпагшене

это зависит от архитектуры тогда. если слабосвязные компоненты - можно разделять. если сильносвязные - можно упаковать в один

я бы сказал - слабосвязанные разделять и деплоить отдельно, сильносвязанные деплоить только вместе

не вижу смысла

НО НА ПРАКТИКЕ никто не группирует! Покажите мне хоть одного кто так делает

ну кубернейтс

вот там поды

поды - это группа контейнеров

на 1 айпишнике

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

так проще

ну и хорошо, если они будут разделены

вот если у нас контейнер с субд не меняется - зачем каждый раз снова деплоить? именно вот сам postgres

И продакшен превращается вот в это.

тут важно понимать, что в каком порядке надо перезапускать

Ооо... начинается.

ну и отлично. можно ловить мух :)

Добро пожаловать в мир SOA :)

Добро пожаловать в мир SOA :)

?

Добро пожаловать в мир SOA :)

Желаю тебе попасть в компанию, где тебе придется этим управлять в самого начала твоей работы.

надо документировать всё

Для этого есть куча тулз, всякие консулы и т.д.

и иметь планы на каждую ситуацию

Тогда бы ты либо перестал так набрасывать, либо изменил своей мнение.

Ну я так подозреваю что в граммарли так и есть

все типовые ошибки документировать и их решение

это всё есть в ITIL

Ну реально не туда ушли.

Желаю тебе попасть в компанию, где тебе придется этим управлять в самого начала твоей работы.

а в чем проблема собственно?

Кончили за ITIL

Заебись )

ITIL - это вообще хорошо

Ктож спорит

в чем у тебя проблема с SOA?

Ответа на свой вопрос, кроме как от Евгения я больше ни от кого не услышал между прочим.

Ну тут просто людей не так много

всего 637 :)

Ответа на свой вопрос, кроме как от Евгения я больше ни от кого не услышал между прочим.

а вопрос в чем? для вновьзашедших

А что за вопрос?

Ок - кратко. У меня есть мнение, что докер должен использоваться только для дистрибьюции исходного кода приложений и связных с ним компонентнов (не активных сервисов). Все персистентные хранилища не должны быть упакованы в докер.

второй раз повторяю

Михаил, спасибо ))

ERROR: S client not available

У тебя вопрос неконсистентный) Хранилища упаковывать - нет, сервисы - да.

ну мне самому ответ интересен )

тю. Ну такое, могут быть и упакованы

есть еще темы с волюм драйверами которые позволяют двигать/синхронить данные между хостами

если часто обновляемые и много зависимых компонентов, то почему бы не упаковать?

так это не вопрос, а мнение

я пока не пробовал, но хочется

докер - это когда тебе удобно шипить что-то там

ну то есть вопрос доставки, если у тебя с хранилищами остро встает вопрос доставки приложения и зависимостей, то докер это неплохое решение

и то вопрос еще, у меня вот уберджары - и я не могу придумать, нафига мне их в докер пихать

и то вопрос еще, у меня вот уберджары - и я не могу придумать, нафига мне их в докер пихать

ну у нас тоже есть. Вопрос унификации сборки\доставки приложения

Просто все советы по докеру, ИМХО на уровне "Hello world", что в Интернете, что в этом чате. Реальный case-study, взвешанный я по-моему еще не видел.

докер молод

у вас _тоже_, а у нас _только они_ :)

Типа "напишите Докерфайл и докер/рокер компоуз"

А дальше ибитесь как хотите.

ну а что? Везде есть нюансы

Просто все советы по докеру, ИМХО на уровне "Hello world", что в Интернете, что в этом чате. Реальный case-study, взвешанный я по-моему еще не видел.

реальным опытом компании на конференциях делятся

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

вон скоро опять митап от баду про докер

Вам в DC хорошо там)

Просто все советы по докеру, ИМХО на уровне "Hello world", что в Интернете, что в этом чате. Реальный case-study, взвешанный я по-моему еще не видел.

просто у большинства людей проекты мелкие и им что Docker, что просто всё на 1 сервер положить - всё будет работать

+1 за разделение сервисов и данных, и данные без докера

Где бы лучше почитать про то, что такое pacemaker/corosync? И зачем оно надо.

собственно о чём и речь - есть , условно, сотня-две компаний, которым и правда нужно серьёзно, а большинству хватило бы и 1 жирного сервера вообще под все задачи компании

Просто все советы по докеру, ИМХО на уровне "Hello world", что в Интернете, что в этом чате. Реальный case-study, взвешанный я по-моему еще не видел.

А ты пробовал искать?

просто у большинства людей проекты мелкие и им что Docker, что просто всё на 1 сервер положить - всё будет работать

Пока с докерхаба имедж не удалят :)

Вам в DC хорошо там)

хорошо

Где бы лучше почитать про то, что такое pacemaker/corosync? И зачем оно надо.

лучше сразу закопать

лучше сразу закопать

спасибо, я предложу CTO

спасибо, я предложу CTO

это будет лучшим решением 2016 года, айм сириоуз

Я сам не крутил, поэтому не могу говорить уверенно, но если есть нормальный volume driver который позволит нормально снихронизировать данные между хостами, то тема с БД в докере начинает быть полезной.