前言
镜像(Image)作为Docker的“水源”
,取之于它,用之于它。这对于立志成为运维管理的撒手锏——Docker而言,重要性不言而喻。
我们在虚拟机时代(当然现在依然ing…),如何快速完成系统的迁移呢? 通常是Copy 一个VM。这个VM是“又笨又大”
。难怪会被取代,我们总是希望事半功倍,因为本能使然。
一、为什么选择Docker
任何一个出色的新产品诞生,总是能够在正确的时间,正确的场合,通过正确的方式完成它的历史级
“亮相”
。
这里先给一张图:
在上篇文章中,博主对docker的特点做了简单总结:“轻”
和“灵”
。
1. 何谓轻
简单讲,不干涉他人“主权”
,不侵犯他人“资源”
。在需要的时候,只需打个招呼,自然有人送上门来。所以不用背负重量级的操作系统(OS),不必携带庞大的数据(Database),这样就轻了,总算做到了“轻装上阵”
。
2. 何谓灵
既已为轻,其灵自现。“胖子总羡慕瘦子的灵巧,殊不知这个瘦子经历了多少辛酸苦辣”
。曾经看过这样一个命题:如何提高货车的装货量?
有些人可能说:塞满、塞满、塞满,无孔不入;
有些人可能说:分门别类,堆积起来,越高越好;
有些人可能说:全部打包;
当然以上发言均没有错,但是做到高效就困难了。这里,答案是把所有的货物装入一个标准箱里,最后码放一起。
行文至此,博主不禁有所感言:
万物万事的兴衰也许都遵循了一定的运行规律和演变逻辑,所以新老交替不可避免。在IT世界,追求价值,是我们永恒的目标。
通过上图,我们可以直观看到VM负重累累,而Docker则身轻如燕。
二、Docker引擎核心
1. 技术基座
1.1命名空间namespace
在Linux中,命名空间是一种容器隔离基础技术,。它能够把资源封装在不同的命名空间中实现资源隔离,进而达到容器隔离的目的。不同的命名空间有一套独有的系统资源。常见的命名空间包含以下六类:
命名空间 | 用途及使用参数 |
---|---|
UTS | 隔离主机名和域名信息,使容器变为一个独立的节点,参数名:CLONE_NEWUTS |
IPC | 隔离进程间通信,参数名:CLONE_NEWIPC |
Network | 隔离网络资源,参数名:CLONE_NEWNET |
PID | 隔离进程的ID,参数名:CLONE_NEWPID |
Mount | 隔离文件系统挂载点,参数名:CLONE_NEWNS |
User | 隔离用户和组,参数名:CLONE_NEWUSER |
当然,namespace
技术是基于chroot
实现的,关于这个点,各位盆友应该有所了解。
1.2控制组cgroups
cgoups
是Control groups的简称,也是 Linux 内核的一个功能。用于限制、控制和审计进程组所使用的物理资源。Docker基于此实现资源隔离,互不侵犯。
控制范围包括:CPU、内存、磁盘 I/O 、网络带宽、设备访问、资源跟踪审计、层次化控制。
1.3联合文件系统UnionFS
UnionFS
是一种为 Linux 操作系统设计的用于把多个文件系统“合并”
到同一个挂载点的文件系统服务。对外看起来是一个整体,可以说有一定的内聚
的意图。直观一点,看图:
小结
: 对外,docker实现了高内聚,屏蔽了差异,只显示一个整体;对内,每个容器都基于一个基础镜像完成新建和运行,存在版本的差异。
了解了docker的技术基座后,我们看看“项庄们”
如何舞剑吧。
2. 三剑客(镜像-容器-仓库)
下图是Docker引擎三剑客
的核心交互逻辑:
2.1 镜像Image
前面提到了Docker之所以出色,是因为镜像
这个大功臣所赐予。镜像
好比是“静止”
的容器,所以它包含了容器所需的一些必要资源(根文件系统、程序文件、元数据、网络信息、用户组、命令入口等)。
2.2 容器Container
我们都说,容器是镜像的“运行态”
,也就是一个经过写
后的一个“镜像”
实例。比如你需要创建一个最新的nginx镜像,则先准备一个基础镜像,然后完成相应的改造,形成新的镜像。那么该镜像则为当前镜像的latest
版本,也就是一个新Tag
。
所以Container并不是对镜像的直接构造,其实是经过一个“可写层”
,对基础镜像完成改造。这里用到一个思想,所谓“向上open, 向下close”
。
2.3 仓库Repository
docker仓库一般有公有和私有之分。
公有仓库是Docker官方提供一个公共仓库,称为Docker Hub,是免费开放的。受困与网络条件,使用起来比较费劲,一般需要加速器。
私有仓库是用户自己搭建、管理和维护的Docker仓库。当然一般是企业自身或个人使用,不对外开放或者有偿开放。
结语
本文主要对docker的核心原理进行剖析,从底层理解为什么docker能够胜任当前的发展需要。希望各位有所收获,感谢捧场,欢迎一键三连,互相鼓励与学习!
精彩回顾
- 微服务实战系列之玩转Docker(二)
- 微服务实战系列之玩转Docker(一)
- 微服务实战系列之云原生
- 微服务实战系列之Filter
- 微服务实战系列之API加密
- 微服务实战系列之Dubbo(下)
- 微服务实战系列之Dubbo(上)
- 微服务实战系列之ZooKeeper(实践篇)
- 微服务实战系列之ZooKeeper(下)
- 微服务实战系列之ZooKeeper(中)
- 微服务实战系列之ZooKeeper(上)
- 微服务实战系列之MQ
- 微服务实战系列之通信
- 微服务实战系列之J2Cache
- 微服务实战系列之Cache(技巧篇)
- 微服务实战系列之MemCache
- 微服务实战系列之EhCache
- 微服务实战系列之Redis
- 微服务实战系列之Cache
- 微服务实战系列之Nginx(技巧篇)
- 微服务实战系列之Nginx
- 微服务实战系列之Feign
- 微服务实战系列之Sentinel
- 微服务实战系列之Token
- 微服务实战系列之Nacos
- 微服务实战系列之Gateway
- 微服务实战系列之加密RSA
- 微服务实战系列之签名Sign