2、docker入门基本概念
docker架构
本章要点：docker核心的基本三个概念，资源隔离(了解一下就行)，docker镜像，docker仓库
Docker实现技术
- Docker 的早期版本中，LXC 作为底层架构的一个模块，用来创建容器，现在用的则是自己开发的
libcontainer，并且积极推动开放容器规范runc，试图打造更通用的底层虚拟化库； - 但无论是 LXC 还是 libcontainer ，都离不开 cgroup(控制组)、 namespace(名称空间)、union FS (联合文件系统)和linux的虚拟化支持； 查看本章资源隔离
基础架构
标准的C/S架构，C/S可以在同一台机器，也可以在不同机器上通过docker或RESTful API来进行通信
CS端说明
- 服务端： 接受来自客户的请求，并处理这些请求(创建、运行、分发容器)
- 客户端： C端为客户提供了一系列可执行命令，用户用这些命令与Docker Daemon交互
- 与S端不同的是，C端发送命令后，等待服务端返回，一旦收到返回后，客户端立刻执行结束并退出；
- 用户端执行新的命令，需要再次调用客户端命令；
- 如果在不同的机器上则可以通过
docker -H tcp://地址:端口 命令来调用
docker基本概念
镜像(Image)， 容器(Container)，仓库(Repository)，三者围绕使用
-
容器是镜像的一个运行实例；
-
仓库可以存储镜像；
-
编译好的容器可以反过来在打包成镜像；
- 完整链路： 比如我们从docker仓库中pull到本地就是镜像，本地在run这个镜像就成了容器，如果你改了容器并且想保存，那就在把这个容器再打包镜像，再如果你想从北京换到上海服务器，那就把这个打包好的镜像再上传到仓库，最后循环执行这个过程。
- 完整链路： 比如我们从docker仓库中pull到本地就是镜像，本地在run这个镜像就成了容器，如果你改了容器并且想保存，那就在把这个容器再打包镜像，再如果你想从北京换到上海服务器，那就把这个打包好的镜像再上传到仓库，最后循环执行这个过程。
docker 镜像
Docker 镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。
镜像分层机制
镜像充分利用union fs技术，将其设计为分层存储的架构。镜像只是一个虚拟的概念,其实际并非由一个文件组成,而是由一组文件系统组成，或者说是由多层系统联合组成，最底层的为bootfs,其之为rootfs
-
bootfs: 用于系统引导的文件系统，包括bootloader和kernel，容器启动完成后会被卸载以节约内存资源‘
-
rootfs: 位于bootfs之上，表现为docker容器的根文件系统
- 传统模式中,系统启动之时,内核挂载rootfs时会首先将其挂载为“只读”模式，完整性自检完成后将其重新挂载为读写模式
- docker中，rootfs由内核挂载为"只读"模式, 而后通过"联合挂载"技术额外挂载一个"可写"层;
镜像层
- 镜像每层定义机制说明
这里总结：
- bootfs做为镜像的引导层，启动之后就会被卸载以节省空间；
- rootfs在bootfs之上运行基础的操作系统如centos,ubuntus，(说白了镜像其实也是一个最小化的操作系统只是阉割了很多东西)；
- 在往上就是分层，每保存一次就多一层，[比如要跑tomcat, 那就先，操作系统，jdk包，tomcat本服务，java程序(这里反正也随你搭配，最后只要能跑起来就完事，核心它就是一层一层的像乐高积木一样)]；
- 最后启动脚本要运行在镜像的最后一层；(最后要有个进程一直hold在前台，不然程序结束容器结束)
docker仓库
两种：公有， 私有
Docker 仓库用来保存镜像，可以理解为代码控制中的代码仓库。
Docker Hub( https://hub.docker.com ) 提供了庞大的镜像集合供使用。
公有 Docker Registry
启动容器时，docker daemon会试图从本地获取相关驱动，当本地镜像不存在时，会自动从registry中下载该镜像并保存至本地， 常见的有官方：docker hub 、国内镜像服务器一般被为加速器，常见的有阿里云,阿里云docker使用教程、daocloude加速器
私有 Docker Registry
用户自建仓库、Docker 官方提供了 Docker Registry， 不过开源的 Docker Registry 镜像只提供了 Docker Registry API 的服务端实现，没图形化不太方便， 除了官方的 Docker Registry 外，还有第三方软件实现了 Docker Registry API，甚至提供了用户界面以及一些高级功能。比如， VMWare Harbor 和 Sonatype Nexus，这里推荐可以使用 docker harbor带图形化也有接口，个人感觉还行，如果有更好的请推荐一下
资源隔离
命名空间
| namespace | 系统调用参数 | 隔离内容 | 内核版本 |
|---|---|---|---|
| UTS(主机名) | CLONE_NEWUTS | 主机名和域名 | 2.6.19 |
| IPC(进程间通信) | CLONE_NEWIPC | 信号量、消息队列和共享内存 | 2.6.19 |
| PID | CLONE_NEWPID | 进程编号 | 2.6.24 |
| Network | CLONE_NEWNET | 网络设备、网络栈、端口等 | 2.6.19 |
| mount(根文件) | CLONE_NEWNS | 挂载点（文件系统） | 2.4.19 |
| User | CLONE_NEWUSER | 用户和用户组 | 3.8 |
pid 命名空间
不同用户的进程就是通过 pid 命名空间隔离开的，且不同命名空间中可以有相同 pid。在同一个Namespace中只能看到当前命名空间的进程。所有的 LXC 进程在 Docker 中的父进程为Docker进程，每个 LXC 进程具有不同的命名空间。同时由于允许嵌套，因此可以很方便的实现嵌套的 Docker 容器。
网络命名空间
有了 pid 命名空间, 每个命名空间中的 pid 能够相互隔离，但是网络端口还是共享 host 的端口。网络隔离是通过 net 命名空间实现的， 每个 net 命名空间有独立的 网络设备, IP 地址, 路由表, /proc/net 目录。这样每个容器的网络就能隔离开来。Docker 默认采用 veth 的方式，将容器中的虚拟网卡同 host 上的一 个Docker 网桥 docker0 连接在一起。通过： brctl show可以查看docker虚拟网口
ipc 命名空间
容器中进程交互还是采用了 Linux 常见的进程间交互方法(interprocess communication – IPC), 包括信号量、消息队列和共享内存等。然而同 VM 不同的是，容器的进程间交互实际上还是 host 上具有相同 pid 命名空间中的进程间交互，因此需要在 IPC 资源申请时加入命名空间信息，每个 IPC 资源有一个唯一的 32 位 id。
mnt 命名空间
类似 chroot，将一个进程放到一个特定的目录执行。mnt 命名空间允许不同命名空间的进程看到的文件结构不同，这样每个命名空间 中的进程所看到的文件目录就被隔离开了。同 chroot 不同，每个命名空间中的容器在 /proc/mounts 的信息只包含所在命名空间的 mount point。
uts 命名空间
UTS(“UNIX Time-sharing System”) 命名空间允许每个容器拥有独立的 hostname 和 domain name, 使其在网络上可以被视作一个独立的节点而非 主机上的一个进程。
cgroups
其名称源自控制组群（control groups）的简写，是Linux内核的一个功能，用来限制、控制与分离一个进程组的资源（如CPU、内存、磁盘输入输出等）。
- **资源限制：**组可以被设置不超过设定的内存限制；这也包括虚拟内存。
- **优先级：**一些组可能会得到大量的CPU或磁盘IO吞吐量。
- **结算：**用来衡量系统确实把多少资源用到适合的目的上。
- **控制：**冻结组或检查点和重启动。
- 隔离： 为组隔离命名空间，这样一个组不会看到另一个组的进程、网络连接和文件系统；
联合文件系统
aufs联合文件系统图例说明， autofs， Docker存储驱动—Overlay/Overlay2
当我们在下载docker镜像的时候，会发现每一层都有一个id，这是层的概念，是AUFS （联合文件系统） 中的重要概念；
**UnionFS（联合文件系统）：**Union文件系统（UnionFS）是一种分层、轻量级并且高性能的文件系统，它支持对文件系统的修改作为一次提交来一层层的叠加，同时可以将不同目录挂载到同一个虚拟文件系统下(unite several directories into a single virtual filesystem)。Union 文件系统是 Docker 镜像的基础。镜像可以通过分层来进行继承，基于基础镜像（没有父镜像），可以制作各种具体的应用镜像
目前使用的是 OverlayFS文件系统，类型于AUFS，但性能更好一些， 通过配置文件定义
]# cat /etc/docker/daemon.json{ "storage-driver": "overlay2", }
Overlayfs是一种堆叠文件系统，它依赖并建立在其它的文件系统之上（例如ext4fs和xfs等等），并不直接参与磁盘空间结构的划分，仅仅将原来底层文件系统中不同的目录进行“合并”，然后向用户呈现。因此对于用户来说，它所见到的overlay文件系统根目录下的内容就来自挂载时所指定的不同目录的“合集”。