Migrating Docker containers from one host to another is a frequent operation in daily operations and maintenance. Whether it's server upgrades, load balancing, or a complete data center relocation, mastering efficient migration solutions is crucial. Migrating containers involves not only migrating the containers themselves but also ensuring data consistency and service continuity.
Image migration is the most standard method for container migration, suitable for scenarios with high environmental consistency requirements. The core of this method is packaging the container into an image for transfer. When the internal state of a container changes, you can first use the `docker commit` command to save the container's current state as a new image. For example, executing `docker commit <container name> <new image name>` will generate a new image containing the changes to the container's current file system.
Next, use `docker save` to package the image into a file: `docker save -o <package file name>.tar <image name>`. This tar file contains the complete content of the image. After transferring it to the target server, load the image using the `docker load` command: `docker load -i <package file name>.tar`. After completion, use the `docker run` command to start a new container based on the loaded image. This method maintains Docker's standard workflow and is particularly suitable for containerized applications requiring long-term maintenance.
When a container needs to be migrated quickly, especially for temporary debugging or emergency deployment, direct container migration provides a more straightforward solution. This method uses a combination of `docker export` and `docker import` commands to directly package and transfer the container's filesystem.
On the source server, execute:
docker export <container name> > <filename>.tar
This exports the container as a tar file, which is then transferred to the target server. On the target server, use `docker import <filename>.tar <new image name>` to import the file as an image, and then create and start a new container based on this image.
It's important to note that images generated via `export`/`import` do not retain the original container's history and metadata, such as environment variables, working directories, and entry point settings. Therefore, this method is more suitable for temporary migrations; for standardized migrations in production environments, image migration is still recommended.
For stateful containers, data volume migration is a critical step to ensure no data loss. When important data within the container needs to be migrated along with it, the data volume needs to be handled separately.
First, use the `docker inspect` command to view the container's data volume mount point information. Then, create a temporary container, mount the same data volume, and package the data:
`docker run --volumes-from <container name> -v $(pwd):/backup <image name> tar cvf /backup/backup.tar <data path>`
After transferring the backup file to the target server, restore the data before starting the new container: first create a new container and mount the data volume, then use the `docker run` command to mount the data volume and perform data restoration.
During the actual migration process, several key points require special attention. Ensure the Docker version on the target server is compatible with the source server to avoid container malfunctions due to version differences. Migrate network configurations and port mappings, checking the container's network mode (e.g., bridged, host, or custom network) and maintaining the same configuration on the target server, while ensuring consistent port mappings. Containers may depend on specific environment variables; these settings need to be consistent on the target server. You can use `docker inspect` to view the original container's environment variable settings.
Post-migration verification is equally important. After starting the container, check the container logs (`docker logs <container name>`) to confirm that the service has started normally. Verify that all service functions are running correctly, especially those relying on data volumes. Perform connectivity tests on critical ports to ensure service accessibility.
Different migration scenarios are suited to different methods. For long-running production environment containers, image migration is recommended because it maintains Docker best practices and facilitates subsequent maintenance and updates. For temporary containers or emergency migrations, direct container migration may be faster and more efficient. For database containers or stateful services, always combine data volume migration to ensure data integrity.
Regardless of the method chosen, important data should be backed up before migration, and the effectiveness of the migration plan should be verified in a test environment. A well-designed migration process not only ensures a smooth service transition but also allows for rapid rollback in case of problems, minimizing business downtime.