银河麒麟服务器操作系统运维实践 课件 19.-2 Docker容器安装与部署

Docker虚拟化篇Docker核心组件Docker底层管理Docker原理与安装overlay2

UFS与AUFSDocker镜像应用Docker的特性本章目标◆了解Docker底层架构原理◆掌握Docker虚拟化名字空间的特性，以及不同名字空间的作用◆掌握Docker的安装◆了解Docker镜像的概念，掌握Docker镜像的管理与维护◆了解Docker容器的概念，掌握Docker容器的管理与维护Docker底层原理LinuxNamespaces机制提供一种资源隔离方案。PID、IPC、Network等系统资源不再是全局性的，而是属于某个特定的Namespace。每个namespace下的资源对于其他namespace下的资源都是透明，不可见的。因此在操作系统层面上看，就会出现多个相同pid的进程。Namespace介绍Linux内核实现Namespace的主要目的之一是实现轻量级虚拟化（容器）服务。再此之前，Linux中很多资源是全局管理。命名空间建立系统的不同视图，对于每一个命名空间，从用户看起来，应该像一台单独的Linux计算机一样，有自己的init进程(PID为0)，其他进程的PID依次递增，A和B空间都有PID为0的init进程，子容器的进程映射到父容器的进程上，父容器可以知道每一个子容器的运行状态，而子容器与子容器之间是隔离的。Namespace介绍想要实现一个资源隔离的容器，需要6项隔离，Linux内核提供了这6种Namespace隔离的系统调用，在同一个Namespace下的进程可以感知彼此的变化，但不了解外界的变化，因此，可以让容器中的进程以为自己在一个独立的系统环境中，达到独立和隔离的目的。Linux提供了多个API用来操作Namespace，它们是clone()、setns()和unshare()函数。◆clone()：创建新进程，flags参数可以用来创建新的namespace◆setns()：让进程加入存在的namespace◆unshare()：将调用进程移动到新的namespace中Namespace介绍同时我们还可以通过/proc下面的一些文件来操作Namespace。首先通过systemctlstatusdocker获取到pid查看进程所属的Namespace：从版本号为3.8的内核开始，/proc/[pid]/ns目录下会包含进程所属的namespace信息，使用下面的命令可以查看当前进程所属的namespace信息：ls–l/proc/[PID]/nsNamespace介绍pid名字空间不同用户的进程就是通过pid名字空间隔离开的，且不同名字空间中可以有相同pid。所有的LXC进程在Docker中的父进程为Docker进程，每个LXC进程具有不同的名字空间。同时由于允许嵌套，因此可以很方便的实现嵌套的Docker容器。net名字空间有了pid名字空间,每个名字空间中的pid能够相互隔离，但是网络端口还是共享host的端口。网络隔离是通过net名字空间实现的，每个net名字空间有独立的网络设备,IP地址,路由表,/proc/net目录。这样每个容器的网络就能隔离开来。Docker默认采用veth的方式，将容器中的虚拟网卡同host上的一个Docker网桥docker0连接在一起。ipc名字空间容器中进程交互还是采用了Linux常见的进程间交互方法(interprocesscommunication-IPC),包括信号量、消息队列和共享内存等。然而同VM不同的是，容器的进程间交互实际上还是host上具有相同pid名字空间中的进程间交互，因此需要在IPC资源申请时加入名字空间信息，每个IPC资源有一个唯一的32位id。mnt名字空间类似chroot，将一个进程放到一个特定的目录执行。mnt名字空间允许不同名字空间的进程看到的文件结构不同，这样每个名字空间中的进程所看到的文件目录就被隔离开了。同chroot不同，每个名字空间中的容器在/proc/mounts的信息只包含所在名字空间的mountpoint。uts名字空间UTS(“UNIXTime-sharingSystem”)名字空间允许每个容器拥有独立的hostname和domainname,使其在网络上可以被视作一个独立的节点而非主机上的一个进程。user名字空间每个容器可以有不同的用户和组id,也就是说可以在容器内用容器内部的用户执行程序而非主机上的用户。Docker底层原理-cgroupscgroups是Linux内核提供的一种可以限制单个进程或者多个进程所使用资源的机制，可以对cpu，内存等资源实现精细化的控制，目前越来越火的轻量级容器Docker就使用了cgroups提供的资源限制能力来完成cpu，内存等部分的资源控制。另外，开发者也可以使用cgroups提供的精细化控制能力，限制某一个或者某一组进程的资源使用。cgroups概念及原理cgroups的全称是controlgroups，cgroups为每种可以控制的资源定义了一个子系统。典型的子系统介绍如下：

◆

cpu子系统，主要限制进程的cpu使用率。

◆

cpuacct子系统，可以统计cgroups中的进程的cpu使用报告。

◆

cpuset子系统，可以为cgroups中的进程分配单独的cpu节点或者内存节点。

◆

memory子系统，可以限制进程的memory使用量。

◆

blkio子系统，可以限制进程的块设备io。

◆

devices子系统，可以控制进程能够访问某些设备。

◆

net_cls子系统，可以标记cgroups中进程的网络数据包，然后可以使用tc模块对数据包进行控制。

◆

freezer子系统，可以挂起或者恢复cgroups中的进程。

◆

ns子系统，可以使不同cgroups下面的进程使用不同的namespace。cgroups层级结构（Hierarchy）内核使用cgroup结构体来表示一个controlgroup对某一个或者某几个cgroups子系统的资源限制。cgroup结构体可以组织成一颗树的形式，每一棵cgroup结构体组成的树称之为一个cgroups层级结构。cgroups层级结构可以包含一个或者几个cgroups子系统，当前层级结构可以对其attach的cgroups子系统进行资源的限制。cgroups层级结构（Hierarchy）上面提到了内核使用cgroups子系统对系统的资源进行限制，也提到了cgroups子系统需要attach到cgroups层级结构中来对进程进行资源控制。下面我们来看一下内核是如何把进程与cgroups层级结构联系起来的。在创建了cgroups层级结构中的节点（cgroup结构体）之后，可以把进程加入到某一个节点的控制任务列表中，一个节点的控制列表中的所有进程都会受到当前节点的资源限制。同时某一个进程也可以被加入到不同的cgroups层级结构的节点中，因为不同的cgroups层级结构可以负责不同的系统资源。所以说进程和cgroup结构体是一个多对多的关系。cgroups层级结构（Hierarchy）cgroups文件系统Linux使用了多种数据结构在内核中实现了cgroups的配置，关联了进程和cgroups节点。Linux内核有一个很强大的模块叫VFS(VirtualFileSystem)。VFS能够把具体文件系统的细节隐藏起来，给用户态进程提供一个统一的文件系统API接口。cgroups也是通过VFS把功能暴露给用户态的，cgroups与VFS之间的衔接部分称之为cgroups文件系统。VFS是一个内核抽象层，能够隐藏具体文件系统的实现细节，从而给用户态进程提供一套统一的API接口。VFS使用了一种通用文件系统的设计，具体的文件系统只要实现了VFS的设计接口，就能够注册到VFS中，从而使内核可以读写这种文件系统。UnionFSUnionFS是一种为Linux，FreeBSD和NetBSD操作系统设计的把其他文件系统联合到一个联合挂载点的文件系统服务。它使用branch把不同文件系统的文件和目录“透明地”覆盖，形成一个单一一致的文件系统。这些branches或者是read-only或者是read-write的，所以当对这个虚拟后的联合文件系统进行写操作的时候，系统是真正写到了一个新的文件中。看起来这个虚拟后的联合文件系统是可以对任何文件进行操作的，但是其实它并没有改变原来的文件，这是因为unionfs用到了一个重要的资管管理技术叫写时复制。Docker原理与安装04Docker工作流程Docker采用了C/S架构，包括客户端和服务端。Dockerdaemon作为服务端接受来自客户的请求，并处理这些请求（创建、运行、分发容器）。客户端和服务端既可以运行在一个机器上，也可通过socket或者RESTfulAPI来进行通信。Docker工作流程dockerdaemon一般在宿主主机后台运行，等待接收来自客户端的消息。Docker客户端则为用户提供一系列可执行命令，用户用这些命令实现跟Dockerdaemon交互。容器-镜像-仓库-daemon-client之间的关系Docker安装卸载旧版本[root@kylinos~]#yumremovedocker安装docker[root@kylinos~]#yuminstalldocker启动docker[root@kylinos~]#systemctlstartdocker开机自启[root@kylinos~]#systemctlenabledocker验证启动[root@kylinos~]#systemctlstatusdockerDocker镜像加速国内从DockerHub拉取镜像有时会遇到困难，此时可以配置镜像加速器。Docker官方和国内很多云服务商都提供了国内加速器服务，例如：科大镜像：/网易：/七牛云加速器：mkdir/etc/dockervim/etc/docker/daemon.json(如果文件不存在则创建){"registry-mirrors":["/"]}##配置完后还要对服务进行重启systemctlrestartdockerDockerEngineDocker生态已经远比它诞生之初要庞大许多，目前这款实现容器化的工具是由Docker官方进行维护的，Docker官方将其命名为DockerEngine，同时定义其为工业级的容器引擎。在DockerEngine中，实现了Docker技术中最核心的部分，也就是容器引擎这一部分。虽然DockerEngine是一款软件，但其实算是由多个独立软件所组成的软件包。在这些程序中，最核心的就是dockerdaemon和dockerCLI。DockerDaemonDockerdaemon：所有通常认为的Docker所能提供的容器管理、应用编排、镜像分发等功能，都集中在了dockerdaemon中，而之前所提到的镜像模块、容器模块、数据卷模块和网络模块也都实现在其中。在操作系统里，dockerdaemon通常以服务的形式运行以便静默的提供这些功能，所以也通常称之为Docker服务。DockerclientDockerclient：Dockerclient是一个泛称，用来向Dockerdaemon发起请求，执行相应的容器管理操作。它既可以是命令行工具docker，也可以是任何遵循了DockerAPI的客户端。在dockerdaemon管理容器等相关资源的同时，它也向外暴露了一套RESTfulAPI，能够通过这套接口对dockerdaemon进行操作。dockerdaemon和dockerCLI所组成的，是一个标准C/S结构的应用程序。衔接这两者的，正是dockerdaemon所提供的这套RESTfulAPI。Client与Daemon分离作为Docker容器管理的守护进程，DockerDaemon从最初集成在docker命令中（1.11版本前），到后来的独立成单独二进制程序（1.11版本开始），其功能正在逐渐拆分细化，被分配到各个单独的模块中去。从Docker服务的启动脚本，也能看见守护进程的逐渐剥离。课程小结课后练习◆简述Docker虚拟化的特性◆描述Docker基本架构原理◆简述Docker名字空间的作用，包括pid、net、ipc、mnt、uts和user◆

部署Docker虚拟化环境UFS与AUFS05UnionFileSystemUnionFileSystem，简称UnionFS，是一种为Linux、FreeBSD和NetBSD操作系统设计的文件系统，它能够多个其他文件系统联合到一个地方来挂载。换句话说，就是多个目录合并mount到同一个目录中。它和核心原理有两个：

分支管理：它使用branch把不同文件系统的文件和目录"透明地"覆盖，形成一个单一一致的文件系统。这些branch或者是read-only的，或者是read-write的，所以当对这个虚拟后的联合文件系统进行写操作的时候，系统是真正写到了一个新的文件中。

写时复制：copy-on-write，简写为CoW，也叫隐式共享，是一种提高资源使用效率的资源管理技术。UnionFileSystem写时复制的思想：如果一个资源是重复的，在没有对资源做出修改前，并不需要立即复制出一个新的资源实例，这个资源被不同的所有者共享使用。当任何一个所有者要对该资源做出修改时，复制出一个新的资源实例给该所有者进行修改，修改后的资源成为其所有者的私有资源。通过这种资源共享的方式，可以显著地减少复制相同资源带来的消耗，但是这样做也会在进行资源的修改时增加一部分开销。AUFS的概念AUFS又叫AnotherUnionFS，后来叫AlternativeUnionFS，再后来更改为AdvanceUnionFS。开发人员叫JunjiroOkajima在2006年开发的。AUFS完全重写了早期的UnionFS1.x，其主要目的是为了可靠性和性能，并且引入了一些新的功能，比如可写分支的负载均衡。AUFS在使用上全兼容UnionFS，而且比之前的UnionFS在稳定性和性能上都要好很多，后来的UnionFS2.x开始抄AUFS中的功能。AUFS演示在麒麟操作系统中，我们可以通过mount命令手动来创建AUFS，以此来感受AUFS的特性。1. 创建实验目录aufsroot@kylinos:~#mkdir/aufs2. 在aufs目录下创建mnt目标作为文件系统的挂载点root@kylinos:~#mkdir/aufs/mnt3. 在aufs目录下创建container-layer文件夹，用来模拟容器的读写层，并初始化内容root@kylinos:~#mkdir/aufs/container-layerroot@kylinos:~#echo"containerlayer">/aufs/container-layer/container-layer.txtAUFS演示4.在aufs目录下创建三个文件image-layer01、image-layer02、image-layer03，用来模拟容器的镜像层，并初始化内容root@kylinos:~#mkdir/aufs/{image-layer01,image-layer02,image-layer03}root@kylinos:~#echo"imagelayer01">/aufs/image-layer01/image-layer01.txtroot@kylinos:~#echo"imagelayer02">/aufs/image-layer02/image-layer02.txtroot@kylinos:~#echo"imagelayer03">/aufs/image-layer03/image-layer03.txtAUFS演示创建AUFS文件系统通过mount把container-layer、image-layer01、image-layer02、image-layer03以AUFS的方式挂载到刚才创建的mnt目录下root@kylinos:~#mount-taufs-odirs=/aufs/container-layer:/aufs/image-layer01:/aufs/image-layer02:/aufs/image-layer03none/aufs/mntroot@kylinos:~#tree/aufs/mnt/aufs/mnt├──container-layer.txt├──image-layer01.txt├──image-layer02.txt└──image-layer03.txtAUFS演示在mount命令中我们没有指定要挂载的4个文件夹的权限信息，其默认行为是：dirs指定的左边起第一个目录是read-write权限，后续目录都是read-only权限。验证写时复制接下来我们向mnt/image-layer03.txt文件写入数据：root@kylinos:~#echo"image-layer03.txt">>/aufs/mnt/image-layer03.txt查看/aufs/mnt/image-layer03.txt的内容，发现已经变化了：那再去看看底层文件/aufs/image-layer03/image-layer03.txt，发现他的内容并没有改变AUFS演示那么，改变的内容被存储到了什么地方呢？去看看container-layer目录当尝试向mnt/image-layer03.txt中写入文件时，系统首先在mnt目录下查找名为image-layer03.txt的文件，将其拷贝到read-write层的container-layer目录中，接着对container-layer目录中的image-layer03.txt的文件进行写操作。这个过程也就是AUFS的实际工作原理。Overlay202Overlay2docker支持多种graphDriver，包括vfs、devicemapper、overlay、overlay2、aufs等等，其中最常用的就是aufs了，但随着linux内核3.18把overlay纳入其中，overlay的地位变得更重，国产麒麟操作系统docker环境默认使用Overlay2存储驱动Overlay2查看docker默认的存储目录/var/lib/docker，我们只需要关心/var/lib/docker/image和/var/lib/docker/overlay2两个目录首先我们创建一个容器，后面章节也会重点讲到容器。root@kylinos:~#dockerrun-dnginxOverlay2先到/var/lib/docker/image目录下查看，只能看到overlay2这个目录，docker会在/var/lib/docker/image目录下按每个存储驱动的名字创建一个目录，如这里的overlay2。接下来，使用tree命令浏览一下overlay2目录：Overlay2关键地方是imagedb和layerdb目录就是专门用来存储元数据的地方，那为什么区分image和layer呢？因为在docker中，image是由多个layer组合而成的，换句话就是layer是一个共享的层，可能有多个image会指向某个layer。那如何才能确认image包含了哪些layer呢？我们可以在imagedb这个目录中去找。比如之前启动的nginx容器，我们可以先找到这个容器对应的镜像Overlay2我们打印/var/lib/docker/image/overlay2/imagedb/content/sha256这个目录：所显示的内容正是记录我们nginx镜像元数据的文件，接下来cat一下这个文件，得到一个长长的json，我们只查看关键信息，也就是rootfscat/var/lib/docker/image/overlay2/imagedb/content/sha256/904b8cb13b932e23230836850610fa45dce9eb0650d5618c2b1487c2a4f577b8|json_pp|grep-A10rootfsOverlay2可以看到rootfs的diff_ids是一个包含了6个元素的数组，其实这6个元素正是组成nginx镜像的6个layerID，从上往下看，就是底层到顶层。现在得到了组成这个image的所有layerID，那么我们就可以带着这些layerID去寻找对应的layer了。接下来，我们返回到上一层的layerdb中，先打印