Постгрес в докере все равно же использует примонтированный каталог ? останавливаем

докер
обновляем каталог с постгресом
запускаем докер с постгресом новой версии
реплику синхним через rsync (с остановкой и запуском докера)

сам я докер не использую, но процесс представляю себе примерно так

> обновляем каталог с постгресом Просто ради любопытства — как делается вот эта часть, "снаружи" (я к тому, что в норме тут нужны binaries двух версий PostgreSQL)?

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

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

И как вы pg_upgrade-у расскажете про эти докеры?

Понятно, спасибо! Но выглядит как-то сложнее, чем без docker, на первый взгляд. ;)

Ну, всегда есть место извращению с прокидыванием бинарников "на время".

Вопрос же не только в этом, а и том, больше это труда или меньше...

pg_upgrade обоих нужных версий будет внутри контейнера

Alexey Lesovsky
вот к примеру смотрите, у меня для CI/CD тестовый ...

ПонЕл, отстал. Мал-мала тормознул, подумал, что два отдельных докера с двумя версиями, вижу, что неправ.

да, вцелом можно под любые нужды нагородить себе любой огород на вкус и цвет )))

Я думаю тут вопрос масштаба. Приведу пример c Zalando - у них в kubernetes очень большое количество постгресов (десятки сотен) как staging так и разного объема production. Очевидно что задача мажорного обновления возникает регулярно. Так вот от ручного апгрейда они ушли совсем, у них для постгресов собран образ (вроде spilo, но могу и наврать) со всем необходимым инструментарием, в нем работают постгресы. Так вот, при запуске контейнера есть проверка необходимости апгрейда и его запуск если он требуется. Приложения при этом готовы к этому, и просто делают периодческий реконнект. Я думаю в этом случае, подход со сборкой образа сильно экономит время и затраты труда.

Так всё равно там много нетривиального scripting. Который, казалось бы, так же получился бы и без kubernetes, нет?

сложно сказать, я не являюсь сотрудником заландо, и деталей всей кухни не знаю. Наверняка какой-то скриптинг есть, куда без него. Но, я точно знаю, что kubernetes появился для stateless приложений, и только получив и осознав преимущества эксплуатации stateless в k8s, уже потом появились мысли и попытки поместить туда еще и постгрес и прочий stateful

сигнал — к докеру можно быть мягче, Миша ))) https://www.cybertec-postgresql.com/en/running-postgres-in-docker-why-and-how/

не надо. каждому инструменту — своё применение.