Я разрабатываю обычный веб-сайт на базе django с базой данных Postgres. Я разрабатываю локально и имею 3 сервера VPS для тестирования, тестирования и производства. На каждом VPS работает собственный стек Linux / Apache / Python / Postgres с собственными базами данных.
Я начал обнаруживать, что при непрерывном развертывании с использованием git постановка практически стала избыточной (переход от постановки к производству требует замены IP-адресов, что требует перезагрузки VPS).
Единственный раз, когда я могу предвидеть полезность промежуточной миграции, - это когда должна произойти сложная миграция базы данных, и даже тогда, поскольку базы данных Postgres в промежуточной и производственной среде не зеркалируются, могут возникнуть проблемы с потерей данных, которые были введены между миграциями.
Мой вопрос (ы): должен ли я зеркалировать Postgres между постановкой и производством? (если да, то как?) И правильно ли я делаю? Я действительно не могу найти много документации о лучших практиках развертывания веб-приложений.
Вы можете избежать потери данных во время миграции, сделав действующий сайт доступным только для чтения на время обновления.
Я бы сказал, что вам следует зеркалировать Postgres между промежуточной и производственной стадиями, если вы думаете, что вам придется выполнять сложную миграцию БД более одного раза. Выполнение миграции вручную может быть настолько подвержено ошибкам, что вы почти наверняка окупите время, потраченное на настройку миграции.
Я не специалист по Postgres, но вот обзор вариантов репликации.
Предположительно у вас есть система резервного копирования для вашей базы данных postgresql? В таком случае вы можете использовать эти резервные копии для заполнения данных в вашей промежуточной среде / dev. У меня есть клиенты, которые используют репликацию (в основном в пространстве MySQL).
Для резервного копирования / подготовки: Производство - репликация -> Подготовка --mysqldump -> резервное копирование
Для разработки: Backup --mysqlimport -> development
Когда им нужно протестировать развертывание, они просто прерывают репликацию. Эта система используется нечасто (2-4 раза в год). Недостатком этого является то, что в какой-то момент вам придется сбросить репликацию, что может потребовать некоторого времени простоя в производственной системе.
Вероятно, есть более чистые реализации, но они обнаружили, что это хорошо работает. Приятно то, что они просто продвигают код в промежуточную систему, прерывают репликацию, и у них в основном есть текущий, живой ящик для регрессии и тестирования приложений.