В настоящее время я изучаю лучшие практики для сохранения данных и обеспечения их эффективной доступности в многоконтейнерном докере.
Большинство докерских приложений используют базы данных для сохранения данных, но это делает ваше приложение зависимым от версии ядра СУБД, поэтому, если требуется новая функция, необходимо выполнить миграцию.
Миграции требуют много времени для планирования, медленного развития, подвержены ошибкам и могут (в худшем случае) полностью нарушить состояние.
Чтобы обойти эту проблему, я часто спрашивал себя, почему бы просто не создать том и читать / записывать все данные с / на том UUID/SESSION-ID.JSON способом?
Таким образом, каждый контейнер остается без состояния / эфемерным и может считывать состояние с тома в любое время, что делает его легко масштабируемым, и поскольку может быть только один UUID / SESSION-ID, проблема одновременной записи решается неявно.
В чем проблема с такой архитектурой приложения?