转载地址:https://blog.csdn.net/zmx729618/article/details/72930474
1.docker 的主要部件:docker(开源的容器虚拟化平台)
docker hub(用于分享、管理Docker容器的Docker SaaS平台)
docker 使用客户端-服务器(C/S)架构模式。Docker客户端会与Docker守护进程进行通信;
docker守护进程会处理复杂繁重的任务(建立,运行,发布docker容器)
docker客户端和守护进程可以运行在同一个系统上,也可以使用docker客户端去连接一个远程的docker守护进程;
docker客户端和守护进程之间通过socket或者RESTful API进行通信;
2.docker 内部构建
docker镜像:Docker images
docker仓库:Docker registeries
docker容器:Docker containers
3.docker镜像:
docker镜像是docker容器运行时的只读模板,每一个镜像都由一系列的层(layers)组成。Docker使用UnionFs来将这些层联合到单独的镜像中。UnionFs允许 独立文件系统中的文件和文件夹(成为分支)被透明覆盖,形成一个单独连贯的文件系统;正是因为有了这些层的存在Docker是如此的轻量;当你改变了一个Docker镜像,不如升级到某个程序到新版本,一个新的层会被创建。因此不用替换整个原先的镜像或者重新建立(在使用虚拟机的时候你可能会这么做),只是一个新的层被添加或升级了。现在你不用重新发布镜像,只需要升级,层使得分发docker镜像变得简单和快速。
4.docker仓库
docker仓库用来保存镜像,可以理解为代码控制中的代码仓库。同样的,docker仓库也有公有和私有的概念。公有的docke仓库名称是Docker Hub。Docker Hub提供了庞大的镜像集合供使用。这些镜像可以是自己创建,或者在别人的基础上创建。Docker仓库是Docker的分发部分;
5.Docker容器
Docker容器和文件夹很类似,一个docker容器包含了所有的某个应用运行所需要的环境。每一个Docker容器都是从Docker镜像创建的。Docker容器可以运行、开始、停止、移动和删除;每一个Docker容器都是独立和安全的应用平台,Docker容器是docker的运行部分;
6.libcontainer
Docker从0.9版本开始使用libcontainer替代lxc,docker和linux的交互图如下:
7.命名空间【Namespaces】
pid namespace
不同用户的进程就是通过pid namespace隔离开的,且不同namespace中可以有相同的PID。具有下列特征:
每个namespace中的pid是有自己的pid=1的进程(类似 /sbin/init进程)
每个namespace中的进程只影响自己的同一个namespace或子namespace中的进程;
因为/proc包含正在运行的进程,因此在container中的pesudo-filesystem的/proc目录只能看到自己namespace中的进程;
因为namespace允许嵌套,父namespace可以影响namespace的进程,所以子namespace的进程可以在父namesapce中看到,但是具有不同的pid;
mnt namespace
类似chroot,将一个进程放到一个特定的目录执行。mnt namespace 允许不同namesapce的进程看到的文件结构不同,这样每个namesapce中的container在/proc/mounts的信息只包含所在namesapce的mount point。
net namespace
网络隔离是通过net namesapce实现的,每个net namesapce有独立的network devices,IP addresses,IP routing tables,/proc/net目录。这样每个container的网络就能隔离开来。docker默认采用veth的方式将container中的虚拟网卡同host上的一个docker bridge连接在一起;
uts namespace
UTS("UNIX Time-sharing System")namespace允许每一个container拥有独立的hostname和domain name,使其在网络上被视作一个独立的节点而非Host上的一个进程;
ipc namespace
container中进程交互还是采用Linux常见的进程间交互方法(interprocess communication - IPC),包括常见的信号量、消息队列和共享内存。然而同VM不同,container的进程间交互实际上还是host上具有相同pid namespace中的进程间交互,因此需要在IPC资源申请时加入namespace信息-每个IPC资源有一个唯一的32bitID;
user namespace
每个container可以有不同的user和group id ,也就是说可以以container内部的用户在container内部执行程序而非Host上的用户。
有了以上6中namespace从进程、网络、IPC、文件系统、UTS和用户角度的隔离,一个container就可以对外展现出一个独立的计算机的能力,并且不同container从OS层面实现了隔离。然而不同namespace之间资源还是相互竞争的,仍然需要类似ulimit来管理每个container所能使用的资源-cgroup;
8.资源配额【cgroups】
cgroups实现了对资源的配额和度量。cgroups的使用非常简单,提供类似文件的接口,在/cgroups目录下新建一个文件夹即可新建一个group,在此文件中新建task文件,并将pid写入该文件,即可实现对该组进程的资源控制。具体的资源配置选项可以在该文件夹中新建子subsystem,{子系统前缀}.{资源项}时典型的配置方法,如memory.usageinbytes就定义了该group在subsystem memory中的一个内存限制选项。另外,cgroups中的subsystem可以随意组合,一个subsystem可以在不同的group中,也可以一个group包含多个subsystem-也就是说一个subsystem。
memory
内存相关的限制;
cpu
在cgroup中,并不能像硬件虚拟化方案一样能够定义cup能力,但是能够定义cpu转轮的优先级,因此具有较高cpu优先级的进程会更可能得到cpu运算。通过将参数写入cup.shares,即可定义该cgroups的CPU优先级-这里是一个相对权重,而非绝对值;
blkio
block IO相关的统计和限制,byte/operation统计和限制(IOPS等),读写速度限制等,但是这里主要统计的都是同步IO;
devices
设备权限限制