前言
幸福,就是继续追寻已经拥有的东西。
------圣·奥古斯丁
什么算已经拥有的?比如爱你的人在等你,比如每日热腾腾的三餐,比如身边可爱的同事,又比如此刻的你,看见了这篇博文(😁😁😁)。所以这么看来幸福很简单,也很直接哈。轻松自在,乐于学习,何尝不是一种已经拥有的幸福。
话不多说,言归正传。博主前序的三篇博文,旨在对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自动取名(全局唯一)。
powershell
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种数据交互方案。每种方案均代表了一类使用场景。根据业务特性和安全要求,选择最佳的持久化方案,应该是我们从中学到的基本经验之一。