затем что у нас есть логическое приложение у которого есть статика?

так может не через fpm? //s3 какое нибудь?

хорошо бы но не всегда возможно

а в чем профит от двух контейнеров в поде вместо одного? скейлить раздельно их нельзя, в случае ООМ одного рестартанется весь под

и т.д.

а гемора с настройкой нжинкс и пхп фпм больше

а в чем профит от двух контейнеров в поде вместо одного? скейлить раздельно их нельзя, в случае ООМ одного рестартанется весь под

так зачем два пода? можно nginx наружу вынести

статика в контейнер как прилетает?

два пода? в моем случае будет 1 под с 1 контейнером

>>в случае ООМ одного рестартанется весь под почему?

статика в образ попадает во время его сборки на CI

статика в образ попадает во время его сборки на CI

ох, звучит прекрасно, хотя возможно я кейса не знаю)

по идеологии 1 контейнер = 1 процесс

Нет такого нигде

Нет такого нигде

процесс не сам по себе один процесс, я имею в виду, что одно приложение 1 nginx, 1 fpm, 1 apache

nginx + fpm это уже не контейнер, это два контейнера

nginx + fpm это уже не контейнер, это два контейнера

вот вроде надо два, а когда нужно подебажить приложение лучше 1)

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

То есть приложение работает только тогда, когда отдает статику?

вот вроде надо два, а когда нужно подебажить приложение лучше 1)

а что там дебажить то

а что там дебажить то

это же пхп

а что там дебажить то

Приложение) что)

Пару раз были специфичные кейсы которые не везде проявляются

Нет такого нигде

на docs.docker.com есть, в Best practices for writing Dockerfiles Each container should have only one concern. Limiting each container to one process is a good rule of thumb, but it is not a hard and fast rule.

>>в случае ООМ одного рестартанется весь под почему?

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

nginx + fpm это уже не контейнер, это два контейнера

или это один контейнер

на docs.docker.com есть, в Best practices for writing Dockerfiles Each container should have only one concern. Limiting each container to one process is a good rule of thumb, but it is not a hard and fast rule.

https://docs.docker.com/config/containers/multi-service_container/ > It is generally recommended that you separate areas of concern by using one service per container. That service may fork into multiple processes (for example, Apache web server starts multiple worker processes). It’s ok to have multiple processes, but to get the most benefit out of Docker, avoid one container being responsible for multiple aspects of your overall application.

как-то так

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

ну да в случае php/nginx можно сказать, что это one concern, если так хочется на архитектурный фейл не тянет в случае 1 контейнера

🤝

процесс не сам по себе один процесс, я имею в виду, что одно приложение 1 nginx, 1 fpm, 1 apache

И даже так не обязательно

на docs.docker.com есть, в Best practices for writing Dockerfiles Each container should have only one concern. Limiting each container to one process is a good rule of thumb, but it is not a hard and fast rule.

И что ? Гуд но не хард

да меня удивило “нет такого нигде”

где-то всё же есть, например, в лучших практиках

ну да в случае php/nginx можно сказать, что это one concern, если так хочется на архитектурный фейл не тянет в случае 1 контейнера

Это зачастую разносится просто мало кто хочет этим морочится

Нет жёсткого правила или то что несколько процессов это плохо

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

хорошо быть богатым и здоровым

конечно же у гугла написанные под контейнеры приложения бегут по одному в контейнере

а мы тут про реальный мир

Нет не по одному

И это реальный мир

Просто надо понимать что к чему и правильно его готовить

Не умеешь не понимаешь делай как говорят

Но гуд руле не означает что всё остальное вери бэд

Мир ни чёрный и не белый это если грубо

Имхо

у меня нет php-fpm сейчас, но если бы был, я бы хотел метрики и логи с двух контейнеров, а не с одного с supervisord или чем там

Ты прав

Какой прок с контейнеров в таком случае, если запихивать все в один?

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

Какой прок с контейнеров в таком случае, если запихивать все в один?

Нет смысла запихивать пхп и нжинкс в один но помимо их в контейнере может быть супервизор лагер аунтификатор сервисмеш коннектор метрика посыльшик хелсчекер и тд

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

Слишком много терминов насыпал. Часть это считай плагины к сервису, часть это обязанность докерфайла, а часть должна быть прибита снаружи

у меня нет php-fpm сейчас, но если бы был, я бы хотел метрики и логи с двух контейнеров, а не с одного с supervisord или чем там

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

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

Чаще всего так и получается дерьмовая архитектура, потому что по итогу выходит что то типа «работает не трогай»

Ты не сделаешь всё сразу хорошо

Что бы понять рекурсию надо понять рекурсию

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

я про те, которые в cadvisor ничего не мешает, но они будут другие

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

Кстати говоря если взять нжинкс да и пхп у них мастер процесс и воркеры как минимум уже не один процесс 😱

потому что не шмогли в треды 😏😏😏

боюсь что изменяет

Есть примета - несколько процессов в контейнере - к зомбиапокалипсису

Кстати говоря если взять нжинкс да и пхп у них мастер процесс и воркеры как минимум уже не один процесс 😱

а если по феншую^W по бестр практисам несколько пулов сделать так вообще 😱

Супервизор их прибивает обычно это его задача

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

И что эти метрики будут значить, сумму температур по больнице?

Мы собираем по всем процессам которым нужно в контейнере и нет проблем

Мы собираем по всем процессам которым нужно в контейнере и нет проблем

И как понять что из условно двух процессов жрет?

Сервисов*

Метрики слать каждые 15-30 сек из контенейра или выгребать прометеем кому как удобней

Нет смысла запихивать пхп и нжинкс в один но помимо их в контейнере может быть супервизор лагер аунтификатор сервисмеш коннектор метрика посыльшик хелсчекер и тд

Зачем их совать в один контейнер если они могут в разных, но в одном поде?

Представь у тебя ещё нет кубернетеса но очень туда охото заехать как есть

ОхотА. Простите за педантичность.

Докеркомпоуз умер, но оставил привычки?

Ранчер 😅

Метрики слать каждые 15-30 сек из контенейра или выгребать прометеем кому как удобней

У тебя в контейнере два сервиса. Шлешь метрики ты со всего контейнера. Как понять какой из сервисов начал жрать больше нормы?

Сервисов оч много просто взмахом одной руки оно не превращается в кубернетес

Докеркомпоуз умер, но оставил привычки?

Можно подумать докеркомпоз заставляет создавать монструозные контейнеры

У тебя в контейнере два сервиса. Шлешь метрики ты со всего контейнера. Как понять какой из сервисов начал жрать больше нормы?

Метрики прилетают в графит у каждого сервиса есть паспорт значений если графит видит что обнормал шлёт Алерт идёшь в графану смотришь графики кто когда почему

У тебя в контейнере два сервиса. Шлешь метрики ты со всего контейнера. Как понять какой из сервисов начал жрать больше нормы?

а что тебе даст знать который из? Это же одно приложение, либо оно работает либо нет. В случае пхп я и так знаю что 99% что жрет пхпфпм, но это знание тоже ничего не даст. Нужная инструментация на уровне языка или приложения чтобы выявить те запросы на которых память течет (тот же ньюрелик ничем тут не поможет)

а что тебе даст знать который из? Это же одно приложение, либо оно работает либо нет. В случае пхп я и так знаю что 99% что жрет пхпфпм, но это знание тоже ничего не даст. Нужная инструментация на уровне языка или приложения чтобы выявить те запросы на которых память течет (тот же ньюрелик ничем тут не поможет)

Это покажет что скейлить/оптимизировать надо, а что и так в порядке

1 nginx + 2 fpm, если у вас неизлечимая проблема с текущей памятью, в итоге OOM не будет приводить к падению сервиса