一个老版本docker的迁移——安装迁移第一次尝试

最新推荐文章于 2025-02-19 11:37:55 发布

zs911zs

最新推荐文章于 2025-02-19 11:37:55 发布

阅读量1k

点赞数 16

文章标签： docker 容器运维

本文链接：https://blog.youkuaiyun.com/zs911zs/article/details/137973428

版权

本文详细描述了在CentOS7系统上安装特定版本Docker（如1.13.1）的步骤，包括查找安装包、处理依赖、版本升级、源码安装，以及如何迁移容器和数据卷。作者分享了迁移过程中遇到的问题及解决方案，如依赖管理、版本不一致和配置一致性等。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

参考文章

centos7安装Docker详步骤（无坑版教cntos7安装Docker详细步骤（无坑版教程）-腾讯云开发者社区-腾讯云 (tencent.com)

Linux安装Docker完整教程-腾讯云开发者社区-腾讯云 (tencent.com)

介绍Docker容器迁移到其他服务器的5种方法_centos docker 容器迁移另一个服务器-优快云博客

Docker镜像与容器备份迁移（export、import与commit、save、load）-腾讯云开发者社区-腾讯云 (tencent.com)

工作需要将一个老版本的docker进行迁移，将过程记录下。

1. 首先想到的是如果有当时的安装包，会省事的多。先在机器上用find命令找安装文件

find / -name "*.rpm"
find / -name "docker"

没有找到。那只能一步步走

2.查找linux和docker版本

cat /etc/redhat-release
#CentOS Linux release 7.8.2003 (Core)
uname -a
#Linux XX 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
docker version

这是找这个版本的安装包。不好找，最后向AI提问“哪里能找到docker-1.13.1-204.git0be3e21.el7.x86_64这个版本的docker”，它帮我找到了。链接如下，也有其它老版本的docker

Kimi.ai - 帮你看更大的世界

docker-1.13.1-204.git0be3e21.el7.x86_64.rpm CentOS 7 Download (pkgs.org)

之后下载，上传到服务器。rpm -ivh xx.rpm安装。提示少依赖，再找再上传，再提示...当这个过程重复10几次后，我终于放弃（是不是有更方便的方法呢，请网友知道的指点下）。先不纠结如此细致的版本号了，找一个方便点的最近似的版本。

3. 安装docker

#更新yum 
#升级所有包同时也升级软件和系统内核；本次方案采用
yum -y update： 
#只升级所有包，不升级软件和系统内核
yum -y upgrade：

#卸载旧版本的docker,因为是新机器，此步跳过
yum remove docker  docker-common docker-selinux docker-engine
#安装需要的软件包， yum-util 提供yum-config-manager功能，另两个是devicemapper驱动依赖
yum install -y yum-utils device-mapper-persistent-data lvm2

以上都没问题，下步在设置 yum 源时出现问题，看教程上写了两个，我以为是哪个可用就用哪个。因此两个都设置了，但马上出现了bad id for repo的错误。刚开始想忽略，但这错误一直存在，最后只能取消，重新设置一个，别的文章也只设置一个就行。

yum-config-manager --add-repo http://download.docker.com/linux/centos/docker-ce.repo（中央仓库）

yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo（阿里仓库）

#查看可用列表
yum list docker-ce --showduplicates | sort -r

此处没有13版本，且Docker从17.03版本之后分为两个版本：社区版（Community Edition，缩写为 CE）和企业版（Enterprise Edition，缩写为 EE）。企业版包含了一些收费服务，个人开发者一般用不到。只好安装一个最和13接近的版本。最后的迁移效果能不能用还要验证。

#选择版本，17.03.0是版本号，默认的话直接docker-ce就可以
yum -y install docker-ce-17.03.0.ce

别人都很顺利，我这提示少依赖。只能再下载docker-ce-selinux = 17.03.0.ce-1.el7.centos用rpm安装，总算没别的事故了。

#服务启动成功
systemctl start docker

最可能的问题是版本不一致，留后观察，17版本只能先试验看。

4. 迁移

迁移总结最好的是这两文章：介绍Docker容器迁移到其他服务器的5种方法_centos docker 容器迁移另一个服务器-优快云博客https://blog.youkuaiyun.com/u014389734/article/details/115265963

Docker镜像与容器备份迁移（export、import与commit、save、load）-腾讯云开发者社区-腾讯云 (tencent.com)https://cloud.tencent.com/developer/article/2027894

可以有5种方式：

导入导出容器文件

docker export -o container.tar container_name
docker import container.tar
#压缩的版本
docker export container-name | gzip > container-name.gz 
zcat container-name.gz | docker import - container-name

特点：只导容器的文件，不保存状态、端口、变量。通常用于备份容器的文件系统，或者将容器的文件系统迁移到另一个 Docker 主机上。

容器镜像迁移
```
docker commit container-id image-name
```
特点：由容器反向生成镜像，数据卷不会被迁移，但它会保留在容器内创建的应用程序的数据。通常用于没有镜像或明显容器有改动的情况。

保存和加载镜像

docker save image-name > image-name.tar 
docker load < image.tar

特点：直接迁移image。

迁移数据卷


#一个方法是通过在“docker run”命令中传递“-volumes from”参数来备份和恢复数据卷。
docker run --rm --volumes-from datavolume-name -v $(pwd):/backup image-name tar cvf backup.tar /path-to-datavolume 

#这里，datavolume名称是/path/to/volume。此命令提供数据卷的备份。要指定工作目录，还可以指定-w/backup。在/backup文件夹中生成的备份可以通过scp或ftp工具复制到新服务器。然后提取复制的备份并将其还原到新容器中的数据卷中。

docker run --rm --volumes-from datavolume-name -v $(pwd):/backup image-name bash -c "cd /path-to-datavolume && tar xvf /backup/backup.tar --strip 1" 


说的更明白的方式：

#创建数据卷容器：在源环境中创建一个仅用于数据卷的容器。
docker create -v /data --name data_container busybox
#将数据卷挂载到源容器：在源容器中使用 --volumes-from选项将数据卷容器挂载到源容器。
docker run -d --volumes-from data_container --name source_container image_name
#迁移数据卷：将数据卷容器的数据目录复制到目标环境。
#创建目标容器：在目标环境中创建一个仅用于数据卷的容器。
docker create -v /data --name data_container busybox
#将数据卷挂载到目标容器：在目标容器中使用 --volumes-from选项将数据卷容器挂载到目标容器。
docker run -d --volumes-from data_container --name target_container image_name

或者手动迁移也行。

迁移整个Docker容器

就是copy整个docker目录(“/var/lib/docker”)复制到新服务器。几个关键点如下：

保留文件夹的权限和所有权。
迁移前停止Docker服务。
验证两台服务器中的Docker版本是否兼容。
迁移前后验证容器列表和功能。
环境变量和其他配置文件的路径。

以上这些方法都可以使用。

5. 导出

1.image

docker images

查看都有镜像，那直接image导出。其它都很顺利，但有个镜像报错：

Error response from daemon: open /var/lib/docker/overlay2/df93bf17da2fcc542bca2846e999f61ce49bce81e644121044c9c53e1edb7367/merged/XXX/lib/log4j-api-2.11.2.jar: no such file or directory

明显这是修改log4j漏洞时动过，第一反应是：手动把文件和目录建好，导出后再删除。结果失败。

2.commit

之前怀疑镜像损坏，那把现在正在运行的容器生成image再导出会不会就成功了？结果还是失败。这说明不单单是镜像的问题了，但因为是生产环境，又不能乱动。

3. export

那把所有的容器文件导出来。哪个行用哪个。

注：有说明export、commit时需要停止容器，但生产环境没办法停，我查了下也可以直接导出，后续影响待观察。

6. 导入

1. image

通过容器观察，有问题的那个容器没有端口，命令只有ping，也不能进入。暂且搁置

导入

2. import

#这里指定images : ex_lib
docker import - ex_lib < lib\:3.15.tar

7.数据卷

其实这一步是之后启动容器时检查才发现的，之前忘记处理数据卷了。在迁移的时候就应该考虑到。最开始有想到，但陷入问题中就把它忘记了，最好的方式其实还是列个清单，最清晰。

数据卷的迁移好多都说建立临时容器，再备份挂载，新机器上再用临时容器恢复。觉得都不够简洁，直接手动迁移就行。docker的数据卷都在/var/lib/docker/volumes/下，在下面直接找到打包带走。如果不放心可以用命令查询所有的数据卷：

#查询所有的数据卷
docker volume ls

在新机器上新建卷，后恢复到固定位置，最后创建容器时挂载：

#创建数据卷
docker volume create volume_name
#注意-C大写，表示解压到指定位置
tar -xvf backup.tar -C /var/lib/docker/volumes/volume_name

#最后再用run -v 参数挂载
docker run -d --name target_container -v volume_name:/path/to/data your_image

8.容器设置

我认为这才是最可能有问题的地方，容器这么多，设置要是更改过或分散在容器中的不同位置，恐怕真是一点办法都没有。

首先docker ps中ports，command列，能看到一参配置，那先从这个入手。因为我不知道哪些容器配置是从image中带出来的，哪些是要自己配置的，所以只能是先试一下。新老容器比对后再调整。

第一版：

docker run -itd --name consul -p 8300:8301 -p 8301:8302/udp -p 8500:8500 --expose 8600 --expose 8600/udp <image>:<tag> /bin/bash
#其余容器不再重复

10个容器完成后发现只有2个能正常启动，其余的只能ps -a查看跑不起来。因为有端口绑定，怀疑是端口没开放。检查端口发现没问题，那肯定是容器配置不对。

用命令查看配置，并把两个容器比对，发现确实有不少配置缺失，那下一步就是怎么还原这些配置项：

#查看配置
docker inspect container_id(container_name)

这个时候找个ai，简单很多。把两个配置丢给他，再给他启动命令，让他分析该补充哪些参数。

结果我找到了env、工作目录、安全选项、特权模式、设备映射（访问linux内存）、bind挂载（直接将宿主机上的一个目录挂载到容器内部）、卷、还找到了那个一直没用的容器，是给其它容器依赖的,又学了一招。

然后一通比对修改，我很想把命令贴出来记录下，但可能涉及安全问题。最长的一个命令有1000多个字符，我都惊了...

第二版后，果然容器正常启动了。但是报了个错：

由于对docker命令不太熟练，每次对日志都会从头显示一遍，我总以为是没启动好，总是比对重新创建容器，其实只要关注日志的最后一部分或者按时间排除一下就好，不能老是docker logs contain_id这么操作。

#某时间后的最后10行
$ docker logs -f -t --since="2024-04-22" --tail=10 CONTAINER_ID
#查看最近5分钟的日志:
$ docker logs --since 5m CONTAINER_ID
#查看某时间之后的日志，-t表示显示时间戳：
$ docker logs -t --since="2018-02-08T13:23:37" CONTAINER_ID
#查看某时间段日志：
$ docker logs -t --since="2024-04-22T13:23:37" --until "2024-04-22T12:23:37"

这些容器怎么才能确定正常呢？没有数据，日志也看不出什么来。首先，我知道生产环境的重启命令，那么容器有可能有依赖，我就以启动顺序为准一个个恢复。当容器都启动后，串联上下关联的程序，更改配置，把这些新容器加入环境中，哪个有问题调整哪个。

一顿操作之后，果然是有问题：第一个登录就调不通。但我不知道具体出问题的服务在哪，也不能这么每个容器都这么瞎找，这样没目标。思考下：通过浏览器调试或日志，肯定能显示出是哪个服务没有通；而且这么多服务肯定是有一个服务注册的地方，先看注册好不好用。检查docker配置，发现一个CONSUL_HOST环境配置。再一查这就是spring服务注册的服务，找到对应的容器IP端口：直接访问查看

发现有些服务失败，有些没有注册进来。刚好和我调试跟踪到的服务是相同的，相互印证，针对有问题的容器再排查，修改、新创建。

最后都顺利启动。

9.总结

1.环境如有条件的话还是留一份安装包，回头一两年后迁移时，会省不少的力气。现在一般也是云，直接做成模版，也很方便。

2.docker就是为了部署迁移方便做出来的，这次基本上也算没遇到什么大坑，唯一的一个就是镜像、commit时报少文件，这个明显是对容器做过改动，但当时没有修改镜像，而且感觉那个容器也是有配置问题，虽然可以运行，但生成镜像出错，肯定不对。以后改动容器后用commit命令验证下。

3.同样的容器run命令，有时就是不行，有时就能正常创建启动，不知原因是什么，我只能认为是参数太多，没有识别好。

4. 迁移了这么多数据卷，到最后就只有一个有挂载使用。而且后来找到了当时创建容器的命令，发现没有卷的挂载操作！结合那个什么都不干的给别人用的挂载容器，可以肯定这是后来改进后的方式。想想确实如此，把那个数据卷打到容器中，以容器的方式操作部署迁移，比卷的操作更方便。

5.这次还算幸运，没有遇见把容器参数四处放飞的情况，全部配置在了容器inspect的env中，像时区、url、密码这些都写在了里面。这个可以当作一种目标规范定下来，以后的查看，更改都会方便很多。像下边这ENV的例子

TZ=
PROFILE=
CONSUL_HOST=
CONSUL_PORT=
HOST_NAME=
REDIS_HOST=
REDIS_PORT=
REDIS_PASSWORD=
MONGODB_URI=
LICENSE_URL=