Способ переключения между дампами базы данных в докер-контейнерах

Question

Ситуация: я работаю над большим стартап-веб-проектом, который часто идет в производство, поэтому вся разработка идет довольно быстро. У нас есть несколько сред - dev (local), QA, stage и production с разными данными в базах данных (мы используем postgres). Моя ежедневная рутина заключается в том, что, работая над какой-то новой функцией, некоторые специалисты по обеспечению качества могут найти критическую ошибку в одной из этих сред, поэтому мне нужно ее исправить или, по крайней мере, посмотреть, что не так.

Проблема: чтобы переключиться с локального контекста на рабочий /qa/stage, я обычно выгружаю базу данных из этих сред локально, а затем выполняю отладку. Проблема в том, что, во-первых, дампы очень тяжелые, и иногда их загрузка и применение занимает до 30 минут, во-вторых, когда я записываю их в локальную базу данных, я теряю свой локальный контекст разработки.

Желание: возможность быстро переключать контексты локально

Пример: допустим, у нас есть докер-контейнер для веб-сервера, который связан с контейнером postgres, как в этом примере docker-compose.yml файл

version: '3'

services:
  pg:
    image: "mdillon/postgis"
    hostname: pghost
    ports:
          - "5433:5432"
    volumes:
          - "~/pgdata:/var/lib/postgresql/data"
    ...
  webserver:
    image: "some_app_image"
    links:
          - pg:postgres
   ...

И давайте представим, что этот веб-сервер действительно тяжелый, так что иметь несколько работающих контейнеров с этим было бы большой проблемой с точки зрения использования памяти и читабельности.

Вопрос: существует ли какой-нибудь элегантный (или нет) способ быстрого переключения между различными наборами данных базы данных? может иметь разные папки pgdata или как-то связать несколько контейнеров postgres (хотя я не уверен, что это возможно)

Answer 1

Это никогда не будет быстрым, так как дело в том, что для резервного копирования, загрузки и восстановления больших баз данных требуется время. Все, что вы действительно можете контролировать, чтобы оптимизировать, - это как часто вы должны делать любую из этих трех вещей. Ваши варианты здесь сводятся к использованию службы, такой как RDS или Google Cloud SQL, которая позволит вам создавать резервные копии и восстанавливать базы данных в облаке по требованию и полностью исключать загрузку; или автоматизировать создание резервной копии, загрузку (с помощью системы оркестровки вы можете "загрузить" на хост-сервер и развернуть новый контейнер базы данных, чтобы восстановить резервную копию с помощью небольшого сценария, который будет намного быстрее, чем отправка резервной копии по сети) и восстанавливать процессы и запускать их по таймеру для настройки безопасных баз данных песочницы, которые вы можете использовать для тестирования. Последнее с задержкой в ​​реальном времени означает, что если в новых данных обнаружен дефект, вам все равно придется подождать, чтобы обновить свою песочницу, но, возможно, она того стоит.