Комментарии 3

Позвольте поинтересоваться — что там за логотип с жар птицей и подписью criu?

ооо, это так называемая Checkpoint/Restore in Userspace (CRIU)!
Когда контейнер останавливается (podman stop), содержимое слоя copy-on-write, выделенного для контейнера, остается в оверлейной файловой системе (если вы не запускаете podman rm), но содержимое в памяти пропадает.
Для большинства «эфемерных» рабочих нагрузок, таких как сервер Apache или Nginx, это хорошо. Но для рабочих нагрузок Java (запуск JVM может занять некоторое время) или баз данных с большими кэшами (на актуализацию которых может потребоваться несколько часов) это неоптимально. Для разрешения этой задачи Podman и CRIU работают вместе, чтобы сохранить содержимое памяти контейнера. Это можно использовать для перезапуска контейнерной рабочей нагрузки, избегая при этом времени запуска или актуализации кэша.

В релизе RHEL 8.2 CRIU, стал частью module stream container-tools:rhel8 и container-tools:2.0. Это дает нам стабильную версию CRIU, которая сопоставляется/совмещается/соответствует версии Podman, обеспечивая совместимость для отдельных жизненных циклов каждого потока модуля

Это тот же самый CRIU, который Виртуоззо пилили?
https://wiki.openvz.org/CRIU/ru
Просто мне казалось, что оно никогда стабильно не работало.


https://www.linux.org.ru/news/opensource/14594341/page1


Год назад пробовал делать живую миграцию LXD-контейнеров. CRIU не справилось даже с default-ным контейнером ubuntu-16.04, в котором из процессов были только systemd и dhclient.

Надеюсь, что с тех пор все стало сильно лучше )

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.