Попытка переместить контейнер, как это, не лучшая практика. Однако может потребоваться некоторая настройка, чтобы привести ваш контейнер в правильное состояние.
Важной деталью является то, что все данные, которые могут измениться и должны быть сохранены, должны храниться вне контейнера . В то время как Docker поддерживает именованные тома для этого, использование собственного пути к файловой системе IME легче поддерживать и перемещать. Вам нужно знать, куда внутри контейнера отправляются данные (как правило, они хорошо документированы), но затем вы можете запускать такие команды, как
docker run -v /data/mysql:/var/lib/mysql/data ... mysql
Теперь вы можете делать все, что захотите, с контейнером , даже с docker rm, но при условии, что /data/mysql на вашем хосте не поврежден, ваши данные в порядке. Это также означает, что вы можете использовать обычный scp для копирования данных на другой хост и docker run в том же контейнере, что является более типичным путем миграции.
Если вы создаете и запускаете пользовательские образы, необходимо проверить пару вещей:
Вы действительно должны использовать какой-то реестр Docker, будь то Docker Hub, что-то, что предлагает ваш облачный провайдер, что-то стороннее или что-то самостоятельно. docker save перемещение изображений - последнее средство, которое редко требуется.
Сами изображения должны быть построены из Dockerfiles и, как и все остальное в вашем приложении, должны быть проверены в системе контроля версий. В идеале у вас есть автоматизированная система сборки (непрерывная интеграция), работающая docker build && docker push для вас. Никогда не используйте docker commit или docker export: они являются рецептом для получения разных версий программного обеспечения на разных системах и не помнят, как вы туда попали.
Ваше приложение должно минимизировать объем данных, которые оно хранит локально. Лучший вариант - хранить все во внешней базе данных, а затем вы можете просто указать на базу данных; если локальное файловое хранилище действительно неизбежно, попробуйте поместить все это в один каталог, который не находится в дереве исходного кода вашего приложения.
Локально вы должны свободно иметь возможность docker stop; docker rm; docker run того же контейнера и не потерять данные. Проверьте это, прежде чем выполнять миграцию между хостами.
Если вы можете структурировать свое приложение так, чтобы все его данные находились во внешней базе данных, рассмотрите возможность запуска базы данных на выделенном хосте с очень хорошими процедурами резервного копирования. Если вы сделали все до этого момента, вы можете получить серьезный скоординированный сбой жесткого диска и потерять все ваши хосты Docker, а на самом деле ничего не потерять (потому что вы можете docker build изображения из источника снова и docker run контейнеры и данные вне хоста).