微服务实战系列之玩转Docker（四）

news2024/9/23 22:35:59

前言

幸福，就是继续追寻已经拥有的东西。
——圣·奥古斯丁

在这里插入图片描述

什么算已经拥有的？比如爱你的人在等你，比如每日热腾腾的三餐，比如身边可爱的同事，又比如此刻的你，看见了这篇博文（😁😁😁）。所以这么看来幸福很简单，也很直接哈。轻松自在，乐于学习，何尝不是一种已经拥有的幸福。

话不多说，言归正传。博主前序的三篇博文，旨在对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	删除一个或多个指定的数据卷。

这是一个卷的信息，可做参考：
在这里插入图片描述