делайте через composer. Если переход будет идти не разом во всех проектах, это вас немного спасет. Вы сможете переводить на новую версию common проекты постепенно.
sarbash75: Со свободными контейнерами все понятно, они в такой схеме будут работать как задумано. А вот привязанные начинают работать как обычные lxc контейнеры и на мой взгляд их наличие не упрощает систему, а лишь усложняют.
Я уже приводил пример с разбором стека технологий автора вопроса. У меня (на вскидку) получилось что только 25% можно упаковать правильно в контейнеры, а все что пишет на диск или используют память между сессиями уже нужно "прибивать гвоздями". Тогда такие контейнеры уже не защищены от смерти физической машины.
На мой взгляд привязывание контейнера к конкретному физическому хосту убивает всю суть перераспределения контейнеров по другим физ хостам при ошибках на одном из них.
mysql proxy как раз и создан для быстрого встраивания в работающую систему, вы просто указываете новый адрес mysql (уже mysql proxy) и все запросы будут бегать через proxy
почему в миграциях Yii есть safeUp/safeDown - потому что некоторые базы данных поддерживают транзакции с DDL читаем тут сравнение https://wiki.postgresql.org/wiki/Transactional_DDL... Mysql в этот список не входит.
"Давайте на чистоту: никто так не делает." - да, именно так и делают в больших проектах.
миграции нужны для управления СТРУКТУРОЙ базы данных, а не самими данными. Вставлять данные миграциями - очень плохая идея. "Шурупы можно забивать молотком, но правильнее закручивать шуруповертом". Я для таких вещей создаю консольную команду. У нас в команде один "молодец" миграциями файлы на диске перемещает )))
кеширование - это один из приемов оптимизации, а преждевременная оптимизация ЗЛО. С системой сообщений вообще не все однозначно, надо понимать как она используется, т.е. нужна статистика. Возможные ситуации
Если диалогов (пользователь -пользователь) много, а сообщений внутри диалога мало, можно все в базе хранить, индексы и денормализация помогут справиться.
Если диалогов мало, но сообщений в них много - можно диалоги в файлах хранить. Кеширование тут совсем не нужно. У какой-то соц сети кстати так и хранится. Операции с файлами атомарные, новые сообщения в конец просто добавляются.
Может быть что диалогов много и сообщений в них много - тогда эффективнее кешировать последние N сообщений, а история будет в базе - в этом случае надо правильно интерфейс сделать, чтобы новые сообщения добавлялись наверх, а если пользователь начинает скроллить вниз - сообщения подкачиваются прямиком из базы.
я бы вообще на этапе разработки не стал прикручить кеширование, потом когда встанет вопрос оптимизации - тогда и прикрутите. Может денормализация и шардирование БД с правильными индексами даст больший эффект чем кеширование.
храните не объект, а саму переписку, уже сгенерированный html или например массив сообщений или json. В зависимости от того как вы потом будете генерировать переписку