容器的特性决定了容器本身是非持久化的，容器被删除，其上的数据也一并删除。而其上承载的应用分为有状态和无状态。容器更倾向于无状态化应用，可水平扩展的，但并不意味所有的应用都是无状态的，特别是银行的应用，一些服务的状态需要保存比如日志等相关信息，因此需要持久化存储。以下内容解答了关于容器存储持久化的若干疑问，包括解决方案解析及比较。
Docker容器关闭后，容器产生的数据还在磁盘上吗？
Docker里的数据不做持久化的话数据是不保留的。所有的数据都是临时的，关了或者重启都会让数据丢失。
如何持久化保存容器的数据，这是自Docker诞生之日起就一直存在的问题。在Docker的初始设计中，数据与容器共生共灭，人们很难把容器从一台机器迁移到另一台机器。时至今日，存储的发展和变革给了容器持久化存储以多种多样的解决之道。
容器架构使用到三种类型的存储：
第一是镜像存储。这可以利用现有的共享存储进行交付，要求类似于服务器虚拟化环境中虚拟机镜像分发保护的平台架构。容器镜像的一项好处在于其存储容量相较于完整的虚拟机镜像小了许多，因为它们不会复制操作系统代码。此外，容器镜像的运行在设计之初便是固定的，因此可以更高效地存储、共享。但也因此，容器镜像无法存储动态应用程序的数据。
第二类需要存储的数据是容器的管理。当然，可以借助现有存储完成这项工作。不论使用Docker、Kubernetes、Tectonic、Rancher还是其它类型的容器管理，都需要存储配置数据、日志记录等管理数据。
第三类存储，容器应用的存储，是最具挑战的。只有支持真正的微服务式编程时，容器代码可以直接写入镜像目录和文件。但是容器使用一种分层文件系统，将所有新写入的数据存储在临时虚拟层，最底层的容器镜像却未被修改。一旦容器消失——相比虚拟机，容器的设计寿命更短——所有的临时存储都会随之消散。
Docker等容器管理产品提供可插拔的卷管理。例如Flocker是开源Docker可插拔卷中的最受欢迎的替代品，可以通过集群智能管理、迁移数据卷及其容器。大多数传统存储供应商和云存储服务提供商为其存储阵列生成各类容器系统卷插件，就是很好的顺应了时代的发展。
什么是容器持久化存储？会带来哪些优势，以及会带来哪些潜在的风险点？
容器持久化数据卷：在容器中运行的应用，应用真正需要保存的数据，可以写入持久化的Volume数据卷。在这个方案中，持久层产生价值，不是通过弹性，而是通过灵活可编程，例如通过设计的API来扩展存储。这个方案结合了持久层和或纯云原生设计模式。
Docker发布了容器卷插件规范，允许第三方厂商的数据卷在Docker引擎中提供数据服务。这种机制意味着外置存储可以超过容器的生命周期而独立存在。而且各种存储设备只要满足接口API标准，就可接入Docker容器的运行平台中。现有的各种存储可以通过简单的驱动程序封装，从而实现和Docker容器的对接。可以说，驱动程序实现了和容器引擎的北向接口，底层则调用后端存储的功能完成数据存取等任务。目前已经实现的Docker Volume Plugin中，后端存储包括常见的NFS，GlusterFS和块设备等。
趋势上，随着有状态容器的使用率变高，持久化就会会变成一项必须的内容。
这个技术本身谈不上优势，只能说是一种需要。
至于风险，从设计原理上应该是几乎没有风险的，但程序的事情没人敢保证100%，因此增加的一个和硬件沟通的间接渠道相当于打开了一扇门，是不是有什么潜在的Bug就不好说了
如何解决Docker的持久化存储问题？如何连接数据与Docker容器？
容器持久化数据卷：在容器中运行的应用，应用真正需要保存的数据，可以写入持久化的Volume数据卷。在这个方案中，持久层产生价值，不是通过弹性，而是通过灵活可编程，例如通过设计的API来扩展存储。这个方案结合了持久层和或纯云原生设计模式。
Docker发布了容器卷插件规范，允许第三方厂商的数据卷在Docker引擎中提供数据服务。这种机制意味着外置存储可以超过容器的生命周期而独立存在。而且各种存储设备只要满足接口API标准，就可接入Docker容器的运行平台中。现有的各种存储可以通过简单的驱动程序封装，从而实现和Docker容器的对接。可以说，驱动程序实现了和容器引擎的北向接口，底层则调用后端存储的功能完成数据存取等任务。目前已经实现的Docker Volume Plugin中，后端存储包括常见的NFS，GlusterFS和块设备等。
Docker Volume Plugin的原理和机制？
Docker Plugin其实是一种API.
包括Plugin的发现，描述，套接字，握手协议等。
具体的细节在Docker的官网上有描述，可以参考(不过是英文的)
支持的厂家有IBM，EMC，Netapp，Veritas等
因为应用数据对安全，可用性，共享，性能等方面的要求和Root Image的要求完全不一样，所以Docker并不推荐采用Root Image的存储方式来存储应用数据，而是采用了Volume这样一个独立的数据访问接口。应用通过Volume去访问相关的数据，Volume的实现和CoW的分层文件系统完全独立，通过Volume plugin机制可轻易驱动外部存储。
(1) Docker Daemon对Volume的管理
Docker Daemon结构中有个成员Volumes，类型是VolumeStore类型，包含一组管理Volume的函数：Create、Remove、List、Get、Refs ...。通过两个变量，管理Container和Volume的关系。 names : map结构，Key是Volume的name，value是实现Volume接口的结构对象。存储该Daemon内所有的Volume。 ReFS: map结构，key是volume的name，value是string数组保存引用该Volume的Container ID。 Docker Daemon通过Volumes变量，就可以管理所有的Volume。
(2) Docker Volume的管理
Docker提供两个接口Volume和Driver，所有提供给Docker使用的Volume必须实现Volume接口。后端驱动需要实现Driver接口。Driver是对提供出去的Volume进行管理。目前Docker实现了两种Volume &Drive。
(2.1)基于本地文件系统的Volume
可以在执行Docker create或Docker run时，通过-v参数将主机的目录作为容器的数据卷。这部分功能便是基于本地文件系统的volume管理。上图中蓝色部分LocalVolume和Root。这两个结构就是对主机目录和文件进行管理
(2.2)适配Plugin的volume
Docker为了支持第三方存储方案，在1.8版本引入Volume Plugin机制，Volume Adapter和Volume Driver Adapter分别实现了接口Volume和Driver接口，用于表示由Plugin提供的Volume和Plugin driver。
(3) Docker Plugin实现原理
Volume Driver Adapter : 实现Driver接口，用于抽象各种Plugin的驱动，该类型可以适配所有符合规范的Volume Plugin，对Plugin进行管理。 Volume Adapter : 实现Volume接口，用于抽象所有Plugin提供的Volume，该类型可以适配所有符合规范的Volume Plugin提供的类型，对Volume进行管理。 通过抽象，对于Plugin和其提供的Volume，Docker Daemon结构和Container结构使用上述两个适配类型，对Plugin和Volume进行管理和使用。
发现步骤： Docker Daemon首先会在/run/docker/plugins搜索对应的套接字文件，套接字文件名必须和Volume Driver名一致，如上述命令，便是搜索convoy.sock。 如果上一步搜索不到，则到/etc/docker/plugins和/usr/lib/docker/plugins两个目录搜索spec或json文件。文件中指定套接字文件的URL。如：unix:///var/run/convoy/convoy.sock 。 根据前面两步发现的Unix域套接字URL，构建Plugin对象，并将新建对象加入到全局变量storage的Plugins字段中。
不同场景下持久化存储的解决方案如何选择？
容器持久化的解决方案在于需要不需要保存数据。
其次，保存在哪？
保存在本地(故障率高)，那就是本地硬盘
保存在外部：
1.分布式系统(并行处理)，那么就需要分布式系统支持Volume Plugin
2.共享存储(高可用)，那么外部存储需要支持Volume Plugin的Driver(厂家提供)
那么这个问题就变成你用哪家人家的存储/存储软件，然后这家的是不是支持Volume Plugin。
开发测试云：
- 容器的轻量级特性，降低了开发测试环境的虚拟化成本，提高了资源利用率
- 容器的快速部署和启停能力，提高了开发测试环境的部署效率和产品迭代效率
- 容器的应用隔离能力，降低了同一操作系统中不同应用间的测试干扰
- 容器的操作系统无关性，降低了开发测试环境的迁移复杂度和迁移成本
- 容器的多副本镜像管理能力，降低了应用程序测试版本的管理复杂度
- 容量按需扩展
- 开发、测试环境数据共享
- 数据分层及自动备份归档
- 不同应用数据隔离
- 跨物理机的容器及数据迁移
- 数据分层及自动备份归档
DevOps开发运维一体化：
除了“开发测试云”中实现的容器化收益之外，
- 开发、测试与生产环境共享镜像仓库，加速研发交付流程，让代码承载业务的脉动，快速推向市场
- 容器的volume特性，可实现同一应用的不用容器在不同物理机上的负载均衡部署
- 有效结合Jenkins、Zabbix等开源框架实现自动化的CI/CD持续集成与持续交付以及自动化的监控与运维能力
- 容量按需扩展
- 开发、测试、生产环境数据共享
- 数据分层及自动备份归档
- 不同应用间数据隔离
- 跨物理机的数据共享及容器迁移
- 关键数据分层及自动备份归档
- 关键数据高可用及灾备能力
BigData大数据服务：
- 容器的轻量级特性，降低了开发测试环境的虚拟化成本，提高了资源利用率
- 容器的批量快速部署能力，加速了大数据集群的部署过程，还可以按需快速调整容器数量以适应大数据平台资源需求的变化
- 容器的应用隔离，降低了同一操作系统中不用应用间的测试干扰
- 容器的操作系统无关性，降低了生产环境至大数据环境的迁移复杂度和迁移成本
- 容器的volume特性，可实现同一大数据应用的不用容器在不同物理机上的负载均衡
- 容量按需扩展
- 生产、大数据环境数据共享
- 数据分层及自动备份归档
- 支持大规模容器启动，提供高性能访问能力
- 不同大数据应用间数据隔离
- 跨物理机的数据共享及容器迁移
- 元数据、关键数据分层及自动备份归档
Container Cloud容器云平台：
结合Docker Swam，Kubernets等开源容器云平台，商业容器云平台实现：
- 镜像的自动化发布
- 容器的自动化编排、高可用及应用的负载均衡
- 镜像、容器、存储的资源管理、监控及运维
- 容量按需扩展
- 云平台应用商店，镜像自动发布
- 数据分层及自动备份归档
- 支持大规模容器启动，提供高性能访问能力
- 有状态容器的数据存储及隔离
- 跨物理机的数据共享及容器高可用
- 关键数据分层及自动备份归档
- 存储资源的集成监控管理
目前能够提供容器持久化存储的开源/商品化的解决方案有哪些？其优势对比？
这个就很多了，IBM，HPE，EMC|DELL，Veritas等大厂商都有支持Docker Volume的Plugin。
开源的话就比较复杂了，一般你用内置盘的话Docker自己就有一个。
但你用外部存储或者商品话系统的话，你需要一个Driver，这个就是各家厂商提供了。
像IBM提供的Plugin本身也是开源的，IBM提供代码并托管到Github上。支持GPFS以及IBM的块存储。
开源领域主要是ceph，由redhat/intel/suse/zte等一波开源社区坚定的支持者来维护。能否提供一个集块，对象，文件合一的统一存储。它的优势在于性价比，劣势在于产品化严重不足，需要专家级团队的支持。
文件系统存储、块存储和对象存储，三种存储系统实现容器持久存储对比？
这个和标准的文件系统，块，对象在使用上的差别是类似的。
块比较快，扩展弱，价格贵
文件系统性能中等，扩展强，价格中等，分布式环境可用
对象性能弱，扩展极强，价格低，一般都是分布式环境的，或者云的。
所以从实现上是没多大区别的，只要Driver支持。
目前看来，块存储的应用最为广泛，主要是块存储的技术储备最多，并且广泛使用。
对象存储次之，现在object存储基于S3 / swift/ OSS接口，随着公有云的普及，被广泛使用。
文件存储，目前还是NAS传统存储的天下，性能和可靠性最为稳定。cephFS目前还是不足以满足生产环境的使用。
对象数据放在物理机、VM、docker上持久化存储的差异在哪？
放物理机等同于直接放磁盘(内部或者外部)
放VM，有两种，看你是用穿透的放法还是统一管理的，第一种类似与放磁盘，但失去很多VM的功能，第二种实际上是嵌入到了一个文件中。
docker的持久化存储，数据是通过volume plugin落在磁盘上的，是API提供了一个通道，让数据可以写磁盘
