1.容器概念回溯
容器本质是一种特殊的进程
namespace作用是视觉隔离，cgroups作用是限制，给沙箱围了已圈墙
2.容器内看到的文件系统是什么样子？
联想Mount namespace问题
容器里的应用进程,按理应该看到一份完全独立的文件系统,这样就可以在自己容器目录(/tmp)下操作
不受宿主机及其他容器影响
3.拿c的代码去验证一下
伪代码
#define _GNU_SOURCE
#include <sys/mount.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <stdio.h>
#include <sched.h>
#include <signal.h>
#include <unistd.h>
#define STACK_SIZE (1024 * 1024)
static char container_stack[STACK_SIZE];
char* const container_args[] = {
"/bin/bash",
NULL
};
int container_main(void* arg)
{
printf("Container - inside the container!
");
execv(container_args[0], container_args);
printf("Something's wrong!
");
return 1;
}
int main()
{
printf("Parent - start a container!
");
int container_pid = clone(container_main, container_stack+STACK_SIZE, CLONE_NEWNS | SIGCHLD , NULL);
waitpid(container_pid, NULL, 0);
printf("Parent - container stopped!
");
return 0;
}
功能说明:main函数里，clone系统调用创建了新的子进程container_main，声明要为它启用Mount Namespace(即: CLONE_NEWNS标记)
子进程执行的是/bin/bash。这个shell运行在了Mount Namespace隔离环境中
编译代码
$ gcc -o ns ns.c
$ ./ns
Parent - start a container!
Container - inside the container!
进入容器中，执行ls命令
ls /tmp
...
发现展示的内容和宿主机的内容是一样的
发现即使开启了MountNamespace，容器进程总看到的文件系统还是和宿主机一毛一样
4.重新认知一下Mount Namespace
Mount Namespace修改的，是容器进程对文件系统“挂载点”视觉的认知。
只有在“挂载”操作后，视觉才会被改变。在挂载之前，新容器会直接继承宿主机的挂载点
如何修复呢？
在容器执行前，先挂载
int container_main(void* arg)
{
printf("Container - inside the container!
");
// 如果你的机器的根目录的挂载类型是shared，那必须先重新挂载根目录
// mount("", "/", NULL, MS_PRIVATE, "");
mount("none", "/tmp", "tmpfs", 0, "");
execv(container_args[0], container_args);
printf("Something's wrong!
");
return 1;
}
验证
$ gcc -o ns ns.c
$ ./ns
Parent - start a container!
Container - inside the container!
$ ls /tmp
发现变为空目录了，重新挂载生效了，容器内可以用mount -l检查
$ mount -l | grep tmpfs
none on /tmp type tmpfs (rw,relatime)
挂载操作+mount namespace的操作，重新挂载的操作只在容器内的mount namespace中有效。
而在宿主机上执行mount -l 可以发现没有tmpfs的挂载信息
5.更优化的环境，容器中文件系统独立隔离环境，容器镜像
换句话说，就是/分区下是独立的文件系统
chroot帮忙了。change root system 改变进程的根目录到你指定的位置
实际mount namespace就是基于chroot 改良发明的，也是linux 操作系统里的第一个namespace
容器根目录更真实，一版会在根目录下挂载一个完整的文件系统，比如centos的iso，容器启动后，查看ls / 展示的就是centos的所有目录和文件
挂载根目录，用来为容器提供隔离后的执行文件系统，就是容器镜像（rootfs）
一般容器镜像，会包含如下内容
$ ls /
bin dev etc home lib lib64 mnt opt proc root run sbin sys tmp usr var
进入容器后执行的/bin/bash，与宿主机的/bin/bash完全不同
6.docker的核心原理
为待创建的用户进程：
1.启用Linux Namespace配置
2.设置指定的Cgroups参数
3.切换进程的根目录
容器就诞生了。docker项目最后一步切换根目录上，优先使用pivot_root系统调用，如果不支持，才会使用chroot。这2个系统调用功能类似，但有细微区别
7.rootfs的特殊性
rootfs是操作系统包含的文件，配置，目录，不包括系统内核。linux中这2部分是分开的。操作系统只有开机启动才会加载指定版本的内核镜像
同一个宿主机上的n个容器共享宿主机的系统内核
8.镜像带来的强一致性
之前：云端环境与本地服务器环境不同，环境不同，非常痛苦
rootfs打包的不只是应用，而是操作系统层面的打包，应用以及所需要的所有依赖，都被封装一起
应用的依赖，认知不能局限在语言层面，比如golang的godeps.json。实际上操作系统本身才是应用程序最完整的“依赖库”
深入到操作系统层级的环境一致性
9.镜像的分层
用到了什么技术？
Union File System联合文件系统能力，UnionFS
将多个不同位置的目录联合挂载到同一个目录下
$ docker image inspect ubuntu:latest
...
"RootFS": {
"Type": "layers",
"Layers": [
"sha256:f49017d4d5ce9c0f544c...",
"sha256:8f2b771487e9d6354080...",
"sha256:ccd4d61916aaa2159429...",
"sha256:c01d74f99de40e097c73...",
"sha256:268a067217b5fe78e000..."
]
}
rootfs的层次结构
- 只读层
最下面的5层，挂载方式是只读
这些层的内容。增量的方式分别包含了centos操作系统的一部分
$ ls /var/lib/docker/aufs/diff/72b0744e06247c7d0...
etc sbin usr var
$ ls /var/lib/docker/aufs/diff/32e8e20064858c0f2...
run
$ ls /var/lib/docker/aufs/diff/a524a729adadedb900...
bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
- 可读写层
最上面一层，rw方式挂载，没有写入文件前，整个目录空的，一旦容器里做了写操作，产生的内容增量出现在这个层里
如果是删除只读层里的一个文件呢？
通过在读写层创建一个whiteout文件，白名单文件，把你要删除的文件遮挡起来，其实并没有真正删除
比如，你要删除只读层里一个名叫 foo 的文件，那么这个删除操作实际上是在可读写层创建了一个名叫.wh.foo 的文件。这样，当这两个层被联合挂载之后，foo 文件就会被.wh.foo 文件“遮挡”起来，“消失”了。这个功能，就是“ro+wh”的挂载方式，即只读 +whiteout 的含义。我喜欢把 whiteout 形象地翻译为：“白障”。 - Init层
只读层和读写层之间，docker的内部曾，专门存放/etc/hosts,/etc/resolv.conf等信息
用户往往需要启动容器时写入一些特定的值hostname，就需要在读写层对他们进行修改
这个修改支队当前容器有效，不希望docker commit 这些也提交
所以单独抽了一个init层出来，用户docker commit提交的是读写层，不包含这些配置文件内容