个人做医疗类网站违法,网站 侧边栏,北京短视频代运营,在线小游戏网页版前言 幸福#xff0c;就是继续追寻已经拥有的东西。 ——圣奥古斯丁 什么算已经拥有的#xff1f;比如爱你的人在等你#xff0c;比如每日热腾腾的三餐#xff0c;比如身边可爱的同事#xff0c;又比如此刻的你#xff0c;看见了这篇博文#xff08;#x1f601;#…前言 幸福就是继续追寻已经拥有的东西。 ——圣·奥古斯丁 什么算已经拥有的比如爱你的人在等你比如每日热腾腾的三餐比如身边可爱的同事又比如此刻的你看见了这篇博文。所以这么看来幸福很简单也很直接哈。轻松自在乐于学习何尝不是一种已经拥有的幸福。
话不多说言归正传。博主前序的三篇博文旨在对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种数据交互方案。每种方案均代表了一类使用场景。根据业务特性和安全要求选择最佳的持久化方案应该是我们从中学到的基本经验之一。 系列回顾 微服务实战系列之玩转Docker三微服务实战系列之玩转Docker二微服务实战系列之玩转Docker一微服务实战系列之云原生
