Потом остается избавиться от yii, и правильная архитектура готова :)

а на что менять yii?

У меня бывшие коллеги сейчас весь проект на юии переводить решили

Потом остается избавиться от yii, и правильная архитектура готова :)

Ладно это шутка 😜

Ладно это шутка 😜

фух. У вас ии какой версии?

Ассетами управлять вполуручную вполне реально

фух. У вас ии какой версии?

От первой до второй. Но они не в докере.

Можно еще разработчиков заменить и тогда точно правильная архитектура готова и приде конец страданиям :) Так в любом проекте... меняешь весь стек, от сервера и технологий до людей и вроде все должно стать лучше :)

Ну прастити, кто тут у нас хочет сделать максимально сложно и грамотно ? 😆

Ассетами управлять вполуручную вполне реально

напиши потом решение которое придумали с ассетами. Так как у меня проекта на 2-й версии и я уже тоже задумался из-за docker-way про ассеты... которые в этот вэй никак не вписываются

Ну прастити, кто тут у нас хочет сделать максимально сложно и грамотно ? 😆

мне пока нравится, то что мне вправляют мозг и я начинаю думать иначе. Это невероятное ощущение :) Ты уже не как все те холопы которые пихают в один контейнер и супервизор и уже на него nginx, php-fpm, db, memcached и все это в продакшен.

Еще раз спасибо всем кто принимает участие :)

Совсем мозг вправится когда дойдет, что пихать все в один контейнер вовсе не плохой вариант

ахаха :) выше обсуждали. Это вариант для поиграться и для небольшого продакшена.

Ой да ладно большие продакшены для миллионов пользователей были еще задолго до докера, и не умерли как то

ахаха :) выше обсуждали. Это вариант для поиграться и для небольшого продакшена.

а что такое большой? :)

небольшой - это там где не нужно масштабирование.

от цифр ваших это не зависит :) если миллион ваша арзитектура выдерживает на одной тачке в одном контейнере... отлично :)

а там где нужно кластеризация и масштабирование на несколько хостов да обслужвать это все и держать на плаву... "все в одном" не пойдет. Хотя... тут уже будет поздно.

Это я все в теории пока знаю :)

а там где нужно кластеризация и масштабирование на несколько хостов да обслужвать это все и держать на плаву... "все в одном" не пойдет. Хотя... тут уже будет поздно.

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

представляю :) но мы же в группе по докеру

даже на докере можно придумать много вариантов больишх продакшенов, но как вияснилось... одни потом превращаются в боль, а другие нет. В этом и разница :)

я к тому, что "больше одного процесса в контейнере плохо" - это отнюдь не абсолютная аксиома.

это я понимаю :)

дальше надо взвешивать

мне товарищи говорили что супервизор в контейнере на котором fpm + nginx + ... это круто тем, что если что-то одно падает то весь контейнер не падает и супервизор потом все поднимет сам.

То есть даже в этом варианте в некоторых ституациях есть свои плюсы :)

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

я к тому, что "больше одного процесса в контейнере плохо" - это отнюдь не абсолютная аксиома.

Это кажется одна из основных идей именно докера?

Это кажется одна из основных идей именно докера?

who cares? если удобнее жить в парадигме "5 процессов на контейнер" - нужно плюнуть на это потому что Docker Inc. завещала так не делать?

кстати интересно посмотреть, где именно это записано как заповедь :)

если удобно - живи :)

но не зря же епридумали и написали Best Practices https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/

да и хвала небесам что они есть :)

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

In almost all cases, you should only run a single process in a single container. Decoupling applications into multiple containers makes it much easier to scale horizontally and reuse containers.

вообще не выглядит как, строго запрещено

it depends

best practices это правила готорые подходят для 90% типичных проектов, а 10% не подходят

если у меня один процесс прилаги не имеет смысла в отрыве от другого процесса

best practices это правила готорые подходят для 90% типичных проектов, а 10% не подходят

вот, тоже верно :)

Скалировать горизонтально можно как контейнер с 1 процессом так и контейнер с 2 процессами, ровно ничего не случится.

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

ну, смотря что за процессы :) опять же... все индивидуально

Например php-fpm и кеш запросов redis

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

нее fpm и кэш.. не поверю что нужно в один

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

я, как человек учащийся, сперва сделаю по best practices. А кгда я пойму почему они написанны именно так, то уже можно и свои BP писать :)

вот мой кейс. Пришел запрос в API. API поставила задачу в кролика на обработку, количий эксчейндж рассувал задачу во все очереди которые подвязаны. И вот все воркеры которые слушают эти очереди они делают по факту одну и туже бизенсс-задачу. Я по быстрому засунул все в один контейнер, до сих пор не разнес. Работают хорошо.

кодовая база была одна, конфиг супервизорда уже был.

кстати интересно посмотреть, где именно это записано как заповедь :)

Нигде. Это просто бестпрактис

Есть два питоновских контейнера. Хочется из одного питоновского кода вызвать какие-то методы у приложения в другом. Контейнеры могут быть на разных машинах. Какой способ сделать это православен, джентльмены?

rpc ?

rpc ?

ну т.е какой-нибудь https://leonid.shevtsov.me/post/messagepack-rpc/, да? А вот тогда вопрос как им друг другу дискавери сделать самым простым образом. В сворме есть?

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

ты-то сам что используешь? :)

у нас своя поделка в стиле json-rpc

Я бы не использовал rpc, предпочитаю очередь

+1

+1 ну не 90'е же за окном

и на минуточку, Докер же тут не причем. Ты просто строишь распределенную систему

ну вопрос был про SD

Я бы не использовал rpc, предпочитаю очередь

Это разные механизмы и не всегда заменимые

Добре.

Возвращаясь к вечному - nginx+fpm. Если с докером на одной машине все относительно ясно - можно папку монтировать с машины (ИМХО, ни есть гуд), можно отдельный data container сделать.... и прочее.

То в swarm mode не все так радужно.

Есть какие-то костыли для распределенного хранения данных, но все как-то...

Нормальный драйвер для ceph так и не запилили, а то, что было, вроде забросили.

они же инфинит купили. у них будет своя распределенная фс с катрочнымим шулерами и дамами

Вижу на данный момент оптимальным вариантом - упаковка nginx+fpm+код в один контейнер.

они же инфинит купили. у них будет своя распределенная фс с катрочнымим шулерами и дамами

Будет. А нужно, как обычно, вчера. :)

Будет. А нужно, как обычно, вчера. :)

это был сарказм. ничего у них не будет

Вижу на данный момент оптимальным вариантом - упаковка nginx+fpm+код в один контейнер.

а потом у вас будет два контейнера в проде с разным кодом. ну мало ли.

а потом у вас будет два контейнера в проде с разным кодом. ну мало ли.

Сейчас на проде код подсасывается на все бэкенды через рсинк

но в данный момент пока не о проде

актуально - автоматизированные тесты

ох. рсинк как доставка кода.

ох. рсинк как доставка кода.

о да