容器镜像是容器的基石，也是容器运行的必备条件。容器镜像若没有备份和恢复方案，对企业的在线业务是极大的风险，可能会直接带来业务的可用率和经济损失。本章从容器镜像的本质切入，针对单个镜像、多个镜像、不同的业务场景分别介绍容器镜像的备份方案。

1、容器镜像备份和恢复的意义

容器技术日趋广泛应用，而容器镜像的备份恢复则是保障容器业务的最初始一步，也是容器应用之上的业务稳定安全运行的第一步。容器镜像本质上是文件的集合，对于这些文件的集合的备份和恢复也就是对应用的可靠、高效的保障。针对具体的使用场景，具有不同的意义。

研发流程一致性容器镜像构建完成之后，需要进行一系列的测试、验证、灰度、蓝绿等等流程才能被正式部署上线。容器镜像在代码提交后第一步完成，为了确保后续流程使用的镜像一致，就需要对容器镜像进行存储备份。这样所有流程就可以通过下载镜像，保证使用时同一份镜像，也保证了线上和线下的业务一致性。业务一致性和可用性对于线上业务而言，为了保证业务的可用性，往往是多机房多环境同事部署。容器镜像的备份存储就能保证每个生产环境业务的完全一致，提高业务的稳定性。应用被部署之后，随着业务的发展需要，可能会有业务高峰期需要扩容，这时候容器镜像就显得尤为重要，可以确保扩容后业务的一致性。当然线上业务也可能进行回滚或者升级，这时候只要有镜像的存在，就可以实现滚动的快速的回滚和升级，保障业务的可用性。安全审计在开发流程中有相应的代码安全扫描和审计，对应的容器应用也是一样。毫无疑问，为了保障生产的镜像，往往不会直接复用生产镜像的存储进行安全和审计，会在生产镜像备份一份同步进行安全和审计。

2、Dockerfile的存储

容器镜像一般是通过Dockerfile进行构建而得。首先来看两个个标准的容器镜像构建Dockerfile。一个是nginx镜像的Dockerfile[6]，另一个是常见的java应用。

如下所示，是一个java应用构建容器镜像的Dockerfile。

第一个Nginx的例子中我们可以看到，其Dockerfile非常复杂，而第二个java应用的Dockerfile很简单，基于tomcat将代码war包拷贝至镜像中即可。

容器镜像Dockerfile一般可以分为两种，标准化应用的容器镜像Dockerfile，非标准化应用的容器Dockerfile。标准化应用容器的Dockerfile，变更很少，就像第二个Dockerfile示例一样，只需要将不同的war包放进即可。这类的Dockerfile备份一个即可。这类的容器镜像恢复也有直接的企业流程，故而可以快速的恢复。Dockerfile本质上是一段构建镜像的脚本文件，存储体积很小，需要进行版本管理。Dockerfile的备份和存储，直接使用企业现有的代码版本管理系统直接备份和保存即可。

对于非标准化的镜像Dockerfile则针对不同的需求定制不同的Dockerfile，这类变更频次较低，构建的依赖文件或者环境往往不进行备份，此类如果需要备份和存储，需要将DockerFile中涉及的内容一起备份。

本小节介绍了基于Dockerfile的容器镜像的备份和恢复，标准Dockerfile，企业代码版本管理方式备份，构建环境恢复快速，容器镜像恢复。非标准Dockerfile，Dockerfile和依赖内容一起备份，也可恢复。需要注意的是根据Dockerfile备份从而实现镜像的备份，一般主要用于CI/CD的场景。因为Dockerfile备份的同时，需要对其所依赖的文件以及构建环境都要进行备份，或者能实现快速创建，一旦构建环境或者依赖的war包等无法快速创建或者恢复，是无法现在镜像的恢复。

3、单个容器的备份和恢复

容器镜像是分层存储，从这个角度，镜像是相关文件的集合。镜像是否可以按照文件备份那样进行备份呢？

答案是肯定的。

在一般安装了docker的机器上，可以使用docker save将容器镜像保存至压缩文件。如需要镜像时候再将容器镜像导入至本地。

如果是一个已经运行了容器，在原有的镜像中修改了一些文件，是否可以把相应的容器镜像进行备份？

答案也是肯定的。

通过docker commit 将运行的容器先制作成相应的镜像，再通过上述的docker save 和docker load 将镜像导出和导入。

将镜像导出成文件，再进行备份，可以通过各种的文件备份方案或者存储方案进行备份。这种方式在正式的场景中用的比较少，一是操作比较复杂，效率不高，二是备份存储介质也有要求，三是正式场景中镜像数量较多，也有成熟的容器镜像存储的方案。一般用在对于某些特性的场景镜像调试时候会采用。

本小节演示和介绍了单个容器、单个容器镜像的备份方法，操作简便，效率有待商榷。可以备份使用频次不高的镜像，对于需要快速恢复和部署的场景需要商榷。

4、多容器镜像的备份和恢复

容器镜像来源于DockerFile，那么只要将Dockerfile和容器镜像制作的环境备份和存储，就能恢复容器镜像。这种方案的前提是能通过DockerFile快速的构建容器镜像。镜像的制作目的是进行使用，企业内部使用，或者企业外部使用。是否有一个专门存储镜像的仓库，镜可以支持容器镜像的高效下载，友好管理呢？

有。

容器镜像管理仓库服务器称为Image Register，其中相应的镜像仓库称为Image Repository。一个Image Register可以包含多个Repository。一个Repository会包含同一个软件不同版本的镜像，而标签（Tag）就常用于对应该软件的各个版本。可以通过 <仓库名>:<标签> 的格式来指定具体是这个软件哪个版本的镜像。

如果不设置标签，将以 latest 作为默认标签。如前面的nginx:alpine，其中nginx是软件名，alpine是标签。

Hello-world没有指定Tag，在镜像查看是看到Tag是latest。

容器镜像仓库有公有仓库，也称第三方仓库，和企业内部自行搭建的称为，私有仓库。

公有仓库（第三方仓库）公有的Image Register一般提供容器镜像免费上传和下在服务，也可提供付费镜像管理等服务。私有仓库私有仓库在企业内部使用，不对外发布，在局域网内，访问效率高。

使用公有Image Register，容器镜像的备份一般相应的企业或者组织会进行维护。如需要企业内快速和高效使用，可以本地搭建一个私有Image Register进行本地Mirror。

使用私有Image Register，需要了解其相应的架构，将其重要的数据文件进行备份。比如Harbor将数据使用独立的volume挂载，相应的磁盘在机器上做快照或者选用RAID系列，也可搭建多个Image Register进行同步备份，也可将数据使用共享存储进行挂载。目前的共享存储多种多样，例如SAN,NAS,分布式存储等，可以结合企业已有的共享存储是指快照或者异地备份等策略。

Image Register能进行友好、高效、统一管理容器镜像。无论是采用公有Image Register还是私有Image Register，针对各个相应的软件服务将重要的数据备份，即能实现容器镜像的备份和恢复。

5、容器镜像的备份和恢复场景

前面介绍了容器镜像存备份的场景以及相应的意义。针对不同的容器备份场景采用不同的容器镜像备份方式方法。如下所示是几种场景场景的解决方案。

CI/CD流程中标准构建的容器镜像对于CI/CD流程中标准构建的容器镜像，其Dockerfile文件是标准，比如前面的java应用的Dockerfile，每个不同版本只需要替换其中的war包。此种场景中，只需要将Dockerfile进行版本管理，需要时将Dockerfile依赖的代码和环境是快速搭建和恢复，构建镜像，然后将镜像传送至Image Register，实现容器镜像存储在Image Register的生命周期较短保存，减轻Image Register的中容器镜像的存储压力。应用系统系统类应用，比如Ingress、CoreDNS、Pormetheus等等，部署频次不高，同时镜像的个数也不多，这类应用应多重备份，多个Image Register之间备份，甚至可以参考上一章节的导出至文件进行备份，安全策略允许的前提下可以发布至公网的Image Register。安全审计安全审计通常时间跨度较长，如果一直存储在Image Register上，毫无疑问有存储成本和Image Register镜像使用效率影响。此种场景可以分级进行备份。距离当前时间较长的镜像使用低成本的存储进行备份，距离当前时间短的镜像使用Dockerfile、Image Register进行备份。

总结

本文介绍了容器镜像的本质，容器镜像的从代码，到Dockerfile，到镜像再到存储，再到业务运行的“一生”。对于不同的需求有着不同的备份和存储的要求和意义。随着业务的增长和时间的推移，镜像的数量和存储的空间肯定都会面临挑战，所以一开始就需要明确存储和备份的业务需求，选择好对应的方案，再进行细化。就像使用Image Register也要细化容器镜像的生命周期，Image Register的存储方式，Docker Register的高可用，监控、告警等等。希望本文从本质上介绍后，能给大家以更多的思考。

作者：郑公子

来源：twt社区