前言
幸福，就是继续追寻已经拥有的东西。
——圣·奥古斯丁
什么算已经拥有的？比如爱你的人在等你，比如每日热腾腾的三餐，比如身边可爱的同事，又比如此刻的你，看见了这篇博文（😁😁😁）。所以这么看来幸福很简单，也很直接哈。轻松自在，乐于学习，何尝不是一种已经拥有的幸福。
话不多说，言归正传。博主前序的三篇博文，旨在对docker的背景目标、运行原理、桌面体验进行简单概述。我想任何一个“小白”读完后，必然有所收获，甚至可以直接向团队提建议——我们愉快的使用docker吧！
当然，在这里，博主先奉上一句：“玩归玩，闹归闹，不用不知道，用过必骄傲”。可是上古兵法云：“知己知彼，百战不殆”，因此，如需熟练使用docker，还需掌握更多“情报”。
本博将继续挖掘docker的内涵，呈现它的魅力！
Q：如何让Docker更高效
既然提到高效，我们是不是可以想到几个不高效的场景？比如最常见的系统迁移方面。
根据系统实施经验，在系统迁移前，我们最优先考虑的方面主要是数据和应用。换句话说，如何保持数据的连续性和系统的稳定性，是迁移时需解决的核心问题。
当然，数据量大不大取决于业务复杂度，但是无论大小与否，在保持业务连续性的前提下，往往会对应用的迁移施加影响。所以此时怎么办？
有些人说使用docker吧，一劳永逸！这个主意好，但是docker也有“难言之隐”。不过还是前辈们思考周全，真的让我们做到了“一劳永逸”。
1. 面临的挑战
我们在使用docker时，会面临哪些主要挑战呢？
1.1 容器间的数据共享
容器可以run anywhere，那么数据是否可以save anywhere？如无法满足，则带来一个问题，数据在容器间是无法共享的。
1.2 容器与docker主机间的数据共享
容器素以“轻，灵”著称，那么数据是否可以真的被有效剥离？如无法满足，则带来一个问题，容器可能会“越来越胖”，同时数据随容器的消亡而消失。
1.3 容器管理数据的性能代价
我们知道容器的运行是在基础镜像之上，加了个“盖”——可读写层。这个机制靠一个特殊的存储驱动来满足。同时联合文件系统（UnionFS）也依靠存储驱动来实现。如频繁的对容器进行数据操作，那么试想，容器能受得了么？
2. 提供的方案
docker为了真正做到数据与容器的分家，满足数据的共享，提供了3种方案：
| 方案名 | 方案简介 |
|---|---|
| Data Volume | 翻译为数据卷，由docker管理的一种文件目录，主机其他进程无法读写。（推荐） |
| Bind Mount | 绑定挂载，由用户自定义存储目录，主机其他进程可读写。（常用） |
| tmpfs Mount | 临时挂载，只临时存储于主机内存，重启后消失。（不常用） |
2.1 data volume
一种不同于联合文件系统，支持以正常的文件或者目录的形式，与主机进行数据交互，进而实现保存持久化数据以及共享容器间的数据。
一句话总结：docker为了解决以上挑战或劣势，特别发明了一种称为“卷”的文件或目录，这个目录或文件的使命就是完成容器数据的持久化。使用它时，数据被默认存储在主机指定的目录：/var/lib/docker/volumes/卷。
一个卷支持用于一个或多个容器，同时不会自动消失，如需删除必须手工操作。可命名也可通过docker自动取名（全局唯一）。
docker volume 命令 //用于卷管理
| 命令 | 作用 |
|---|---|
| create | 创建一个数据卷。 |
| inspect | 查看一个或多个数据卷基本信息。 |
| ls | 查看已创建的所有数据卷。 |
| prune | 删除全部未使用的卷。 |
| rm | 删除一个或多个指定的数据卷。 |
这是一个卷的信息，可做参考：
2.2 Bind Mount
一种直接与主机磁盘进行交互的数据挂载方式，实现用途大致和
volume类似，也是常用的docker数据持久化技术。
一句话总结：与volume相比，终于实现了目录选择的自由了，容器与主机直接交互。当然，“优势太明显，劣势也直接”。如此选择，会直接影响容器的数据安全。所以选择该方式，通常是一把双刃剑，需评估后操作。
2.3 tmpfs Mount
与
Bind Mount相比，容器的数据只在内存管理，不再持久化，这就是tmpfs。
一句话总结：没有持久化，也就无需考虑数据共享的情景（涉及敏感数据保护、数据安全等），可以选择tmpfs Mount。
结语
docker为了解决数据持久化，满足迁移效率和数据共享的需要，提供了以上3种数据交互方案。每种方案均代表了一类使用场景。根据业务特性和安全要求，选择最佳的持久化方案，应该是我们从中学到的基本经验之一。
系列回顾
535
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
