夜法之书 • Posts by "docker" category

使用 Shell 脚本实现一个简单 Docker

2022-03-18T06:33:17.000Z

《使用 Shell 脚本实现 Docker》旨在通过一系列的实验使用户对docker的底层技术，如Namespace、CGroups、rootfs、联合加载等有一个感性的认识。在此过程中，我们还将通过Shell脚本一步一步地实现一个简易的docker，以期使读者在使用docker的过程中知其然知其所以然。

我们的实验环境为Ubuntu 18.04 64bit，简易docker工程的名字为 docker.sh，该工程仓库地址如下：

https://github.com/pandengyang/docker.sh.git
https://github.com/appotry/docker.sh

《使用 Shell 脚本实现 Docker》目录如下：

1. Namespace
1.1. Namespace简介
1.2. uts namespace
1.2.1. uts namespace简介
1.2.2. docker.sh
1.3. mount namespace
1.3.1. /etc/mtab、/proc/self/mounts
1.3.2. /proc/self/mountinfo
1.3.3. bind mount
1.3.4. mount namespace简介
1.3.5. docker.sh
1.4. pid namespace
1.4.1. unshare的--fork选项
1.4.2. pid namespace简介
1.4.3. pid嵌套
1.4.4. docker.sh
2. CGroups
2.1. CGroups简介
2.2. 限制内存
2.2.1. 用CGroups限制内存
2.2.2. docker.sh
3. 切换根文件系统
3.1. 根文件系统
3.2. pivot_root
3.3. docker.sh
4. 联合加载
4.1. 联合加载简介
4.2. AUFS
4.3. docker.sh
5. 卷
5.1. 卷简介
5.2. docker.sh
6. 后记

Namespace

Namespace简介

传统上，在Linux中，许多资源是全局管理的。例如，系统中的所有进程按照惯例是通过PID标识的，这意味着内核必须管理一个全局的PID列表。而且，所有调用者通过uname系统调用返回的系统相关信息都是相同的。用户id的管理方式类似，即各个用户是通过一个全局唯一的UID标识。

Namespace是Linux用来隔离上述全局资源的一种方式。把一个或多个进程加入到同一个namespace中后，这些进程只会看到该namespace中的资源。namespace是后来加入到Linux中的，为了兼容之前的全局资源管理方式，Linux为每一种资源准备了一个全局的namespace。Linux中的每一个进程都默认加入了这些全局namespace。

Linux中的每个进程都有一个/proc/[pid]/ns/目录，里面包含了该进程所属的namespace信息。我们查看一下当前Shell的/proc/[pid]/ns目录，命令及结果如下：

phl@kernelnewbies:~$ sudo ls -l /proc/$$/ns
total 0
lrwxrwxrwx 1 phl phl 0 Jan 22 08:43 cgroup -> cgroup:[4026531835]
lrwxrwxrwx 1 phl phl 0 Jan 22 08:43 ipc -> ipc:[4026531839]
lrwxrwxrwx 1 phl phl 0 Jan 22 08:43 mnt -> mnt:[4026531840]
lrwxrwxrwx 1 phl phl 0 Jan 22 08:43 net -> net:[4026531993]
lrwxrwxrwx 1 phl phl 0 Jan 22 08:43 pid -> pid:[4026531836]
lrwxrwxrwx 1 phl phl 0 Jan 22 08:43 pid_for_children -> pid:[4026531836]
lrwxrwxrwx 1 phl phl 0 Jan 22 08:43 user -> user:[4026531837]
lrwxrwxrwx 1 phl phl 0 Jan 22 08:43 uts -> uts:[4026531838]

该目录下有很多符号链接，每个符号链接代表一个该进程所属的namespace。用readlink读取这些符号链接可以查看进程所属的namespace id。我们读一下当前Shell所属的uts namespace id，命令及结果如下：

phl@kernelnewbies:~$ sudo readlink /proc/$$/ns/uts
uts:[4026531838]

后文中我们将介绍uts namespace、mount namespace、pid namespace的用法。

uts namespace

uts namespace简介

uts namespace用于隔离系统的主机名等信息，我们将通过实验学习其用法。在实验过程中，我们采用如下的步骤：

查看全局uts namespace信息
新建一个uts namespace，查看其信息并作出修改
查看全局uts namespace，查看其是否被新建的uts namespace影响到

对于其他namespace，我们也采取类似的步骤进行实验学习。

首先，我们查看一下全局的hostname及uts namespace id。命令及结果如下：

phl@kernelnewbies:~$ hostname
kernelnewbies

phl@kernelnewbies:~$ sudo readlink /proc/$$/ns/uts
uts:[4026531838]

然后，我们创建一个新的uts namespace，并查看其namespce id。

在继续之前，需要介绍一个namespace工具unshare。利用unshare我们可以新建一个的namespace，并在新namespace中执行一条命令。unshare执行时需要root权限。unshare的使用方法如下：

unshare [options] [program [arguments]]

执行unshare时，我们可以指定要新建的namespace的类型以及要执行的命令。unshare提供了一系列选项，当指定某个选项时可新建指定的namespace。namespace类型选项如下：

–uts创建新的uts namespace
–mount创建新的mount namespace
–pid创建新的pid namespace
–user创建新的user namespace

介绍完unshare之后，我们继续之前的实验。我们用unshare创建一个新的uts namespace，并在新的uts namespace中执行/bin/bash命令，命令及结果如下：

phl@kernelnewbies:~$ sudo unshare --uts /bin/bash
root@kernelnewbies:~#

我们用unshare创建了一个新的uts namespace。在新的uts namespace中查看其hostname和namespace id，命令及结果如下：

root@kernelnewbies:~$ hostname
kernelnewbies

root@kernelnewbies:~# readlink /proc/$$/ns/uts
uts:[4026532177]

从结果我们可以看到，新uts namespace的id与全局uts namespace的id不一致。这说明/bin/bash已运行在一个新的uts namespace中了。

我们将新uts namespace的hostname改为dreamland，并强制更新Shell提示符。命令及结果如下：

root@kernelnewbies:~# hostname dreamland
root@kernelnewbies:~# hostname
dreamland

root@kernelnewbies:~# exec /bin/bash
root@dreamland:~#

从结果我们可以看到，新uts namespace的hostname的确是被修改了，exec /bin/bash用于强制更新Shell的提示符。

我们重新打开一个Shell窗口，该Shell位于全局uts namespace中。在新的Shell窗口中查看全局uts namespace id及hostname，命令及结果如下：

phl@kernelnewbies:~$ hostname
kernelnewbies

phl@kernelnewbies:~$ sudo readlink /proc/$$/ns/uts
uts:[4026531838]

从结果我们可以看到，我们在新uts namespace中所作的修改并未影响到全局的uts namespace。

父进程创建子进程时只有提供创建新namespace的标志，才可创建新的namespace，并使子进程处于新的namespace中。默认情况下，子进程与父进程处于相同的namespace中。我们在新的uts namespace中创建一个子进程，然后查看该子进程的uts namespace id，命令及结果如下：

phl@kernelnewbies:~$ sudo unshare --uts /bin/bash
root@kernelnewbies:~# readlink /proc/$$/ns/uts
uts:[4026532305]

root@kernelnewbies:~# bash
root@kernelnewbies:~# readlink /proc/$$/ns/uts
uts:[4026532305]

从结果我们可以看到，子进程所属uts namespace的id与其父进程相同。其他namespae与uts namespace类似，子进程与父进程同属一个namespace。

`docker.sh`

有了以上关于uts namespace的介绍，我们就可以将uts namespace加入到docker.sh中了。docker.sh工程分为两个脚本：docker.sh和container.sh。

docker.sh用于收集用户输入、调用unshare创建namespace并执行container.sh脚本，docker.sh脚本如下：

#!/bin/bash

usage () {
        echo -e "\033[31mIMPORTANT: Run As Root\033[0m"
        echo ""
        echo "Usage:    docker.sh [OPTIONS]"
        echo ""
        echo "A docker written by shell"
        echo ""
        echo "Options:"
        echo "          -c string       docker command"
        echo "                          (\"run\")"
        echo "          -m              memory"
        echo "                          (\"100M, 200M, 300M...\")"
        echo "          -C string       container name"
        echo "          -I string       image name"
        echo "          -V string       volume"
        echo "          -P string       program to run in container"

        return 0
}

if test "$(whoami)" != root
then
        usage
        exit -1
fi

while getopts c:m:C:I:V:P: option
do
        case "$option"
        in
                c) cmd=$OPTARG;;
                m) memory=$OPTARG;;
                C) container=$OPTARG;;
                I) image=$OPTARG;;
                V) volume=$OPTARG;;
                P) program=$OPTARG;;
                \?) usage
                    exit -2;;
        esac
done

export cmd=$cmd
export memory=$memory
export container=$container
export image=$image
export volume=$volume
export program=$program

unshare --uts ./container.sh

脚本最开始为usage函数，该函数为docker.sh的使用说明。当用户以非预期的方式使用docker.sh时，该函数会被调用。该函数输出如下信息：

IMPORTANT: Run As Root

Usage:  docker.sh [OPTIONS]

A docker written by shell

Options:
                -c string       docker command
                                ("run")
                -m              memory
                                ("100M, 200M, 300M...")
                -C string       container name
                -I string       image name
                -V string       volume
                -P string       program to run in container

从usage函数的输出我们可以看到，执行docker.sh时需要root权限且需要正确地传递参数。

docker.sh首先对当前用户进行检测，如果用户不为root，则打印使用说明并退出脚本；如果用户为root，则继续执行。检测用户的脚本如下：

if test "$(whoami)" != root
then
        usage
        exit -1
fi

然后，docker.sh使用getopts从命令行提取参数，然后赋值给合适的变量。从命令行提取参数的脚本如下：

while getopts c:m:C:I:V:P: option
do
        case "$option"
        in
                c) cmd=$OPTARG;;
                m) memory=$OPTARG;;
                C) container=$OPTARG;;
                I) image=$OPTARG;;
                V) volume=$OPTARG;;
                P) program=$OPTARG;;
                \?) usage
                    exit -2;;
        esac
done

如果用户的输入不正确，则打印使用说明并退出脚本；如果用户输入正确，则解析命令行参数并赋值给合适的变量。

为了简化，用户在运行docker.sh时需提供完整的参数列表，示例如下：

sudo ./docker.sh -c run -m 100M -C dreamland -I ubuntu1604 -V data1 -P /bin/bash

当然，如果当前用户就是root，就不需要sudo了。下表列出了各个参数的含义及示例：

docker.sh将命令行参数赋值给变量后，需要将这些变量导出，以传递给container.sh。导出变量的脚本如下：

export cmd=$cmd
export memory=$memory
export container=$container
export image=$image
export volume=$volume
export program=$program

这里说明一下为什么要将docker.sh工程拆分为docker.sh和container.sh两个脚本。因为调用unshare创建新的namespace时，会执行一个命令，该命令在新的namespace中运行。该命令一旦结束，unshare也就结束了，unshare创建的新namespace也就不存在了。

docker.sh不会并发地执行unshare命令与unshare之后的脚本，因此，只有unshare结束了，后续脚本才可继续运行。但是当unshare结束了，准备执行后续脚本时，新的namespae已经不存在了。因此一些加入cgroups、切换根文件系统等工作必须在unshare执行的命令中进行，所以我们采用在unshare中执行container.sh脚本的方式完成后续的工作。

最后，docker.sh调用unshare创建新的uts namespace，并执行container.sh脚本。调用unshare的脚本如下：

unshare --uts ./container.sh

container.sh将容器的hostname修改为通过-C传递的容器的名字，然后执行通过-P传递的程序。container.sh脚本如下：

#!/bin/bash

hostname $container
exec $program

现在，我们运行docker.sh，并查看其hostname。命令及结果如下：

phl@kernelnewbies:~/docker.sh$ sudo ./docker.sh -c run -m 100M -C dreamland -I ubuntu1604 -V data1 -P /bin/bash
root@dreamland:~/docker.sh# hostname
dreamland

从结果我们可以看到，容器的hostname已经改变为我们传递的容器名字dreamland了。

mount namespace

/etc/mtab、/proc/self/mounts

早期的Linux使用/etc/mtab文件来记录当前的挂载点信息。每次mount/umount文件系统时会更新/etc/mtab文件中的信息。

后来，linux引入了mount namespace，每个进程都有一份自己的挂载点信息。当然，处于同一个mount namespace里面的进程，其挂载点信息是相同的。进程的挂载点信息通过/proc/[pid]/mounts文件导出给用户。

为了兼容以前的/etc/mtab，/etc/mtab变成了指向/proc/self/mounts的符号链接。通过readlink查看/etc/mtab指向的文件，命令及结果如下：

phl@kernelnewbies:~$ readlink /etc/mtab
../proc/self/mounts

通过读取/proc/self/mounts文件，可以查看当前的挂载点信息，命令及结果如下：

phl@kernelnewbies:~$ cat /proc/self/mounts
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
/dev/sda1 / ext4 rw,relatime,errors=remount-ro 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
...

由于该文件中内容太多，我们省略了一部分，只保留了一些比较重要的挂载点信息。每行的信息分为六个字段，各字段的含义及示例如下：

由于该文件有点过时，被后文介绍的/proc/self/mountinfo替换掉，所以不做过多介绍。

/proc/self/mountinfo

/proc/self/mountinfo包含了进程mount namespace中的挂载点信息。它提供了旧的/proc/[pid]/mounts文件中缺少的各种信息（传播状态，挂载点id，父挂载点id等），并解决了/proc/[pid]/mounts文件的一些其他缺陷。我们查看进程挂载点信息时应优先使用该文件。

该文件中每一行代表一个挂载点信息，每个挂载点信息分为11个字段。挂载点信息的示例如下：

各字段的含义及示例如下：

我们主要关注可选字段中的传播状态选项。首先，我们看一下关于mount namespace的问题。问题如下：

当创建mount namespace时，新mount namespace会拷贝一份老mount namespace里面的挂载点信息。例如，全局mount namespace中有一个/a挂载点，新建的mount namespace中也会有一个/a挂载点。那么我们在新mount namespace中的/a下创建或删除一个挂载点，全局mount namespace中的/a会同步创建或删除该挂载点吗？或者在全局mount namespace中的/a下创建或删除一个挂载点，新mount namespace中的/a会同步创建或删除该挂载点吗？

mountinfo文件中可选字段的传播状态就是控制在一个挂载点下进行创建/删除挂载点操作时是否会传播到其他挂载点的选项。传播状态有四种可取值，常见的有如下两种：

shared 表示创建/删除挂载点的操作会传播到其他挂载点
private 表示创建/删除挂载点的操作不会传播到其他挂载点

由于在容器技术中要保证主机与容器的挂载点信息互不影响，因此要求容器中的挂载点的传播状态为private。

1.3.3.bind mount

bind mount可以将一个目录（源目录）挂载到另一个目录（目的目录），在目的目录里面的读写操作将直接作用于源目录。

下面我们通过实验了解一下bind mount的功能，首先，我们准备一下实验所需要的的目录及文件。命令及结果如下：

phl@kernelnewbies:~$ mkdir bind
phl@kernelnewbies:~$ cd bind/
phl@kernelnewbies:~/bind$ mkdir a
phl@kernelnewbies:~/bind$ mkdir b
phl@kernelnewbies:~/bind$ echo hello, a > a/a.txt
phl@kernelnewbies:~/bind$ echo hello, b > b/b.txt

然后，我们将a目录bind mount到b目录并查看b目录下的内容。命令及结果如下：

phl@kernelnewbies:~/bind$ sudo mount --bind a b
phl@kernelnewbies:~/bind$ tree b
b
└── a.txt
0 directories, 1 file

从结果我们可以看到，b目录下原先的内容被隐藏，取而代之的是a目录下的内容。

然后，我们修改b目录下的内容，修改完毕后，从b目录上卸载掉a目录。命令及结果如下：

phl@kernelnewbies:~/bind$ echo hello, a from b > b/a.txt
phl@kernelnewbies:~/bind$ sudo umount b

我们读取一下a目录中a.txt，看看其内容是否被改变。命令及结果如下：

phl@kernelnewbies:~/bind$ cat a/a.txt
hello, a from b

从结果我们可以看到，a目录中的内容确实被当a被bind mount到b时对b目录的操作所修改了。

bind mount在容器技术中有很重要的用途，后文会有涉及。

mount namespace简介

mount namespace用来隔离文件系统的挂载点信息, 使得不同的mount namespace拥有自己独立的挂载点信息。不同的namespace之间不会相互影响，其在unshare中的选项为–mount。

当用unshare创建新的mount namespace时，新创建的namespace将拷贝一份老namespace里的挂载点信息，但从这之后，他们就没有关系了。这是unshare将新 namespace 里面的所有挂载点的传播状态设置为private实现的。通过mount和umount增加和删除各自mount namespace里面的挂载点都不会相互影响。

下面我们将演示mount namespace的用法。首先，我们准备需要的目录和文件，命令及结果如下：

phl@kernelnewbies:~$ mkdir -p hds/hd1 hds/hd2 && cd hds

phl@kernelnewbies:~/hds$ dd if=/dev/zero bs=1M count=1 of=hd1.img && mkfs.ext2 hd1.img
phl@kernelnewbies:~/hds$ dd if=/dev/zero bs=1M count=1 of=hd2.img && mkfs.ext2 hd2.img

phl@kernelnewbies:~$ tree .
.
├── hd1
├── hd1.img
├── hd2
└── hd2.img
2 directories, 2 files

然后，我们在全局的mount namespace中挂载hd1.img到hd1目录，然后查看该mount namespace中的挂载点信息与mount namespace id。命令及结果如下：

phl@kernelnewbies:~/hds$ sudo mount hd1.img hd1
phl@kernelnewbies:~/hds$ cat /proc/self/mountinfo | grep hd
556 27 7:18 / /home/phl/hds/hd1 rw,relatime shared:372 - ext2 /dev/loop18 rw

phl@kernelnewbies:~/hds$ sudo readlink /proc/$$/ns/mnt
mnt:[4026531840]

然后，执行unshare命令创建一个新的mount namespace并查看该mount namespace id和挂载点信息。命令及结果如下：

phl@kernelnewbies:~/hds$ sudo unshare --uts --mount /bin/bash
root@kernelnewbies:~/hds# cat /proc/self/mountinfo | grep hd
739 570 7:18 / /home/phl/hds/hd1 rw,relatime - ext2 /dev/loop18 rw

root@kernelnewbies:~/hds# readlink /proc/$$/ns/mnt
mnt:[4026532180]

从结果我们可以看到，新mount namespace中的挂载点信息与全局mountnamespace中的挂载点信息基本一致，一些挂载选项（如传播状态）变化了。新的mount namespace id与全局mount namespace id是不一样的。

然后，我们在新的mount namespace中挂载hd2.img到hd2目录，并查看挂载点信息。命令及结果如下：

root@kernelnewbies:~/hds# mount hd2.img hd2
root@kernelnewbies:~/hds# cat /proc/self/mountinfo | grep hd
739 570 7:18 / /home/phl/hds/hd1 rw,relatime - ext2 /dev/loop18 rw
740 570 7:19 / /home/phl/hds/hd2 rw,relatime - ext2 /dev/loop19 rw

从结果我们可以看到，新mount namespace中有hd1和hd2这两个挂载点。现在启动一个新的Shell窗口，查看全局mount namespace中的挂载点信息。命令及结果如下：

phl@kernelnewbies:~/hds$ cat /proc/self/mountinfo | grep hd
556 27 7:18 / /home/phl/hds/hd1 rw,relatime shared:372 - ext2 /dev/loop18 rw

从结果我们可以看到，全局mount namespace中的挂载点信息只有hd1，而没有hd2。这说明在新mount namespace中进行挂载/卸载操作不会影响其他mount namespace中的挂载点信息。

mount namespace只隔离挂载点信息，并不隔离挂载点下面的文件信息。对于多个mount namespace都能看到的挂载点，如果在一个namespace中修改了挂载点下面的文件，其他namespace也能感知到。下面，我们在新建的mount namespace中创建一个文件，命令如下：

root@kernelnewbies:~/hds# echo hello from new mount namespace > hd1/hello.txt

在新启动的Shell中，查看hd1目录并读取hd1/hello.txt文件。命令及结果如下：

phl@kernelnewbies:~/hds$ tree hd1
hd1
├── hello.txt
└── lost+found [error opening dir]
1 directory, 1 file

phl@kernelnewbies:~/hds$ cat hd1/hello.txt
hello from new mount namespace

从结果我们可以看到，在全局mount namespace中，我们可以读取到在新建的mount namespace中创建的文件。

`docker.sh`

有了以上关于mount namespace的知识，我们就可以将mount namespace加入到docker.sh中了。mount namespace将放在docker.sh中，带下划线的行是我们为实现mount namespace而修改的代码。修改后的docker.sh脚本如下：

...
unshare --uts --mount ./container.sh

从上述代码我们可以看到，我们仅仅是在调用unshare时加入–mount选项，就可为docker.sh引入了mount namespace功能。

pid namespace

unshare的–fork选项

unshare有一个选项–fork，当执行unshare时，如果没有这个选项，unshare会直接exec新命令，也就是说unshare变成了新命令。如果带有–fork选项，unshare会fork一个子进程，该子进程exec新命令，unshare是该子进程的父进程。我们分别不带–fork和带–fork来执行unshare，然后查看进程之间的关系。

首先，我们不带–fork选项执行unshare，并查看当前Shell的进程id。命令及结果如下：

phl@kernelnewbies:~$ sudo unshare --uts /bin/bash
root@kernelnewbies:~/hds# echo $$
11699

此时unshare会创建一个新的uts namespace，然后exec /bin/bash。我们启动一个新Shell，然后使用pstree查看进程间关系，命令及结果如下：

phl@kernelnewbies:~/hds$ pstree -p | grep 11699
sudo(11698)---bash(11699)

从结果我们可以看到，sudo fork出一个子进程，该子进程执行unshare。unshare创建了新uts namespace后，exec了/bin/bash，也就是说unshare变成了/bin/bash。

然后，我们带–fork选项执行unshare，并查看当前Shell的进程id。命令及结果如下：

phl@kernelnewbies:~/hds$ sudo unshare --uts --fork /bin/bash
root@kernelnewbies:~/hds# echo $$
11866

此时unshare会创建一个新的uts namespace，然后fork出一个子进程，该子进程exec /bin/bash。我们启动一个新Shell，然后使用pstree查看进程间关系，命令及结果如下：

phl@kernelnewbies:~/hds$ pstree -p | grep 11866
sudo(11864)---unshare(11865)---bash(11866)

从结果我们可以看到，sudo fork出一个子进程，该子进程执行命令unshare。unshare创建了新uts namespace后，fork出一个子进程，该子进程exec /bin/bash，也就是说unshare变成了新的/bin/bash进程的父进程。

pid namespace简介

pid namespace用来隔离进程pid空间，使得不同pid namespace里的进程 pid可以重复且相互之间不影响。进程所属的pid namespace在创建的时候就确定了，无法更改，因此需要–fork选项来创建一个新进程，然后将该新进程加入新建的pid namespace中。pid namespace在unshare中的选项为–pid。

unshare在创建pid namespace时需同时提供–pid与–fork选项。unshare本身会加入全局的pid namespace，其fork出的子进程会加入新建的pid namespace。

首先，我们查看全局pid namespace id，命令及结果如下：

phl@kernelnewbies:~$ sudo readlink /proc/$$/ns/pid
pid:[4026531836]

然后，执行unshare命令创建一个新的pid namespace并查看该pid namespace id。命令及结果如下：

phl@kernelnewbies:~$ sudo unshare --mount --pid --fork /bin/bash
root@kernelnewbies:~# readlink /proc/$$/ns/pid
pid:[4026531836]

从结果我们可以看到，新创建的进程也处于全局pid namespace中，而不是新的pid namespace。

出现这种情形是因为当前的/proc文件系统是老的。我们查看一下$$的值，命令及结果如下：

root@kernelnewbies:~# echo $$
1

从结果我们可以看到，$$的值为1，但是/proc文件系统却是老的，因此我们查看的实际是init进程所属的pid namespace，当然是全局pid namespace了。

重新挂载/proc文件系统，这也是unshare执行时带–mount选项的原因，只有这样，重新挂载/proc文件系统时，不会搞乱整个系统。再次查看新进程所属的pid namespace，命令及结果如下：

root@kernelnewbies:~# mount -t proc proc /proc
root@kernelnewbies:~# readlink /proc/$$/ns/pid
pid:[4026532182]

从结果我们可以看到，新进程的pid namespace与全局pid namespace的id不同。

接下来，我们再来查看一下新pid namespace中的进程信息。命令及结果如下：

root@kernelnewbies:~# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 19:03 pts/1    00:00:00 /bin/bash
root        10     1  0 19:03 pts/1    00:00:00 ps -e

从结果我们可以看到，当前pid namespace中只有2个进程，看不到全局pid namespace里面的其他进程。我们通过unshare执行的进程pid为1，也就是说该进程成了新pid namespace中的init进程。

pid嵌套

pid namespace可以嵌套，也就是说有父子关系，在当前pid namespace里面创建的所有新的pid namespace都是当前pid namespace的子pid namespace。

首先，我们创建3个嵌套的pid namespace，并查看每个pid namespace id。–mount-proc选项用于自动挂载/proc文件系统，省去了手动挂载/proc文件系统的操作。命令及结果如下：

phl@kernelnewbies:~$ sudo readlink /proc/$$/ns/pid
pid:[4026531836]

phl@kernelnewbies:~$ sudo unshare --uts --mount --pid --mount-proc --fork /bin/bash
root@kernelnewbies:~# readlink /proc/$$/ns/pid
pid:[4026532182]

root@kernelnewbies:~# unshare --uts --mount --pid --mount-proc --fork /bin/bash
root@kernelnewbies:~# readlink /proc/$$/ns/pid
pid:[4026532185]

root@kernelnewbies:~# unshare --uts --mount --pid --mount-proc --fork /bin/bash
root@kernelnewbies:~# readlink /proc/$$/ns/pid
pid:[4026532188]

然后，我们启动一个新Shell，然后使用pstree查看进程间关系。命令及结果如下：

phl@kernelnewbies:~$ pstree -lp | grep unshare
sudo(12547)---unshare(12548)---bash(12549)---unshare(12579)---bash(12580)---unshare(12593)---bash(12594)

使用cat /proc/[pid]/status | grep NSpid可查看某进程在当前pid namespace及子孙pid namespace中的pid。我们在全局pid namespace中查看上述各进程在各pid namespace中的pid，命令及结果如下：

phl@kernelnewbies:~$ cat /proc/12594/status | grep NSpid
NSpid: 12594 21 11 1

phl@kernelnewbies:~$ cat /proc/12593/status | grep NSpid
NSpid: 12593 20 10

phl@kernelnewbies:~$ cat /proc/12580/status | grep NSpid
NSpid: 12580 11 1

phl@kernelnewbies:~$ cat /proc/12579/status | grep NSpid
NSpid: 12579 10

phl@kernelnewbies:~$ cat /proc/12549/status | grep NSpid
NSpid: 12549 1

下面我们将以上进程在各pid namespace中的pid，整理成表格。表格信息如下：

我们以最后一行为例进行介绍，最后一行有4个pid，这4个pid其实是同一个进程。这个进程在4个pid namespace中都可以被看到，且其在4个pid namespace中的pid各不相同。

`docker.sh`

有了以上关于pid namespace的知识，我们就可以将pid namespae加入到docker.sh中了。pid namespace将放在docker.sh中，带下划线的行是我们为实现pid namespace而修改的代码。修改后的docker.sh脚本如下：

...
unshare --uts --mount --pid --fork ./container.sh

从上述代码我们可以看到，我们仅仅是在调用unshare时加入–pid和–fork选项，就可为docker.sh引入了pid namespace功能。

然后，我们需要重新挂载/proc文件系统。重新挂载/proc文件系统的功能将放在container.sh中，带下划线的行是我们为重新挂载/proc文件系统而新添的代码。修改后的container.sh脚本如下如下所示：

hostname $container
mount -t proc proc /proc
exec $program

现在，我们运行docker.sh，并查看当前的进程信息。命令及结果如下：

phl@kernelnewbies:~/docker.sh$ sudo ./docker.sh -c run -m 100M -C dreamland -I ubuntu1604 -V data1 -P /bin/bash
root@dreamland:~/docker.sh# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 17:31 pts/1    00:00:00 /bin/bash
root        16     1  0 17:31 pts/1    00:00:00 ps -ef

从结果我们可看出，当前进程只有两个，不再有主机上的其他进程。

CGroups

CGroups简介

CGroups是一种将进程分组，并以组为单位对进程实施资源限制的技术。每个组都包含以下几类信息：

进程列表
资源A限制
资源B限制
资源C限制
…

我们将以常见的CPU资源及内存资源为例进行介绍。以下的信息将使进程号为1001、1002、2008、3306的四个进程总共只能使用一个CPU核心；总共最多使用25%的CPU资源；总共最多使用100M内存，这样的一个分组被称为cgroup。

上面的介绍只是说明了要将何种资源限制施加于哪些进程，并未说明资源限制是如何施加到进程上。具体施加资源限制的过程需要subsystem来帮忙。subsystem读取cgroup中的资源限制和进程列表，然后将这些资源限制施加到这些进程上。常见的subsystem包括如下几种：

cpu
memory
pids
devices
blkio
net_cls

每个subsystem只读取与其相关的资源限制，然后施加到进程上。例如：memory子系统只读取内存限制，而cpu子系统只读取cpu限制。

cgroup被组织成树，如下图所示：

采用树状结构可以方便地实现资源限制继承，一个cgroup中的资源限制将作用于该cgroup及其子孙cgroup中的进程。例如：图中13001、10339、2999受到A、B、C、D四个cgroup中的资源限制。这样的一个树状结构被称为hierarchy。

hierarchy中包含了系统中所有的进程，它们分布于各个cgroup中。在hierarchy中，一个进程必须属于且只属于一个cgroup，这样才能保证对进程施加的资源限制不会遗漏也不会冲突。

要想让一个subsystem读取hierarchy中各cgroup的资源限制，并施加于其中的进程需要将subsystem和hierarchy关联起来。subsystem与hierarchy的关系如下：

系统中可以有多个hierarchy
一个hierarchy可以关联0个或多个subsystem，当关联0个subsystem时，该hierarchy只是对进程进行分类
一个subsystem最多关联到一个hierarchy，因为每个hierarchy都包含系统中所有的进程，若一个subsystem关联到了多个hierarchy，对同一进程将有多种资源限制，这是不对的

系统使用CGroups通常有两种形式：一种是创建一个hierarchy，将所有的subsystem关联到其上，在这个hierarchy上配置各种资源限制；另一种是为每一个subsystem创建一个hierarchy，并将该subsystem关联到其上，每个hierarchy只对一种资源进行限制。后一种比较清晰，得到了更普遍的采用。

CGroups不像大多数的技术那样提供API或命令之类的用户接口，而是提供给用户一个虚拟文件系统，该虚拟文件系统类型为cgroup。一个挂载后的cgroup文件系统就是一个hierarchy，文件系统中的一个目录就是一个cgroup，目录中的文件代表了进程列表或者资源限制信息。文件系统是树状结构，其各个目录之间的父子关系就代表了cgroup之间的继承关系。挂载cgroup虚拟文件系统后，通过在该文件系统上创建目录、写进程列表文件、写资源限制文件就可以操作CGroups。

下面，我们通过实验学习一下CGroups的用法。首先，我们挂载一个cgroup虚拟文件系统，该文件系统不与任何subsystem关联，仅仅是将进程进行分类。命令及结果如下：

phl@kernelnewbies:~$ mkdir -p cg/test
# -o none,name=test 表示该cgroup文件系统不与任何子系统关联
# 该文件系统用name=test来标识
phl@kernelnewbies:~$ sudo mount -t cgroup -o none,name=test test cg/test
phl@kernelnewbies:~$ tree cg/test
cg/test
├── cgroup.clone_children
├── cgroup.procs
├── cgroup.sane_behavior
├── notify_on_release
├── release_agent
└── tasks
0 directories, 6 files

挂载cgroup文件系统后，该cgroup文件系统的根目录下会生成许多文件，该根目录被称为root cgroup。cgroup.procs里面存放的是当前cgroup中的所有进程id，由于该hierarchy中只有一个cgroup，所以这个文件包含了系统中所有的进程id。其他的文件与cgroups基本功能关系不大，暂时可以忽略。

在cgroup文件系统中，创建一个目录就会创建一个cgroup。下面我们将会演示如何创建下面这样的hierarchy：

命令及结果如下：

phl@kernelnewbies:~$ sudo mkdir -p cg/test/test1/test11
phl@kernelnewbies:~$ sudo mkdir -p cg/test/test2/test22
phl@kernelnewbies:~$ tree cg/test
cg/test
├── cgroup.clone_children
├── cgroup.procs
├── cgroup.sane_behavior
├── notify_on_release
├── release_agent
├── tasks
├── test1
│   ├── cgroup.clone_children
│   ├── cgroup.procs
│   ├── notify_on_release
│   ├── tasks
│   └── test11
│       ├── cgroup.clone_children
│       ├── cgroup.procs
│       ├── notify_on_release
│       └── tasks
└── test2
    ├── cgroup.clone_children
    ├── cgroup.procs
    ├── notify_on_release
    ├── tasks
    └── test22
        ├── cgroup.clone_children
        ├── cgroup.procs
        ├── notify_on_release
        └── tasks

4 directories, 22 files

从结果我们可以看到，我们创建了相应的目录后，这些目录下自动出现了包含cgroup信息的目录及文件。

删除cgroup时只需删除该cgroup所在的目录即可。下面我们将删除test11 cgroup，命令及结果如下：

phl@kernelnewbies:~$ sudo rmdir cg/test/test1/test11
phl@kernelnewbies:~$ tree cg/test
cg/test
├── cgroup.clone_children
├── cgroup.procs
├── cgroup.sane_behavior
├── notify_on_release
├── release_agent
├── tasks
├── test1
│   ├── cgroup.clone_children
│   ├── cgroup.procs
│   ├── notify_on_release
│   └── tasks
└── test2
    ├── cgroup.clone_children
    ├── cgroup.procs
    ├── notify_on_release
    ├── tasks
    └── test22
        ├── cgroup.clone_children
        ├── cgroup.procs
        ├── notify_on_release
        └── tasks

3 directories, 18 files

每个cgroup下面都有一个cgroup.procs文件，该文件里面包含当前cgroup里面的所有进程id。只要将某个进程的id写入该文件，即可将该进程加入到该cgroup中。下面，我们将当前的bash加入到test22 cgroup中，命令及结果如下：

phl@kernelnewbies:~$ echo $$
3894
phl@kernelnewbies:~$ sudo sh -c "echo 3894 > cg/test/test2/test22/cgroup.procs"

/proc/[pid]/cgroup包含了某个进程所在的cgroup信息。下面，我们查看一下当前bash进程所在的cgroup信息，命令及结果如下：

phl@kernelnewbies:~$ cat /proc/3894/cgroup
13:name=test:/test2/test22
12:freezer:/
11:perf_event:/
10:blkio:/user.slice
9:devices:/user.slice
8:hugetlb:/
7:cpu,cpuacct:/user.slice
6:net_cls,net_prio:/
5:memory:/user.slice
4:rdma:/
3:pids:/user.slice/user-1001.slice/session-4.scope
2:cpuset:/
1:name=systemd:/user.slice/user-1001.slice/session-4.scope
0::/user.slice/user-1001.slice/session-4.scope

从结果我们可以看到，当前bash进程加入了多个cgroup，其中带下划线的行为我们刚刚加入的cgroup。

要想将hierarchy与子系统关联起来，需要在-o选项中指定子系统名称。下面演示了如何将memory子系统与新挂载的cgroup文件系统关联起来。代码如下：

phl@kernelnewbies:~$ sudo mkdir cg/memory
phl@kernelnewbies:~$ sudo mount -t cgroup -o memory memcg cg/memory

由于很多发行版的操作系统已经为我们配置好了这些cgroup文件系统，我们应当直接使用这些已经挂在好的文件系统，不需要自己去挂载。

另外，当创建子进程时，子进程会自动加入父进程所在的cgroup。

限制内存

用CGroups限制内存

下面我们将介绍演示CGroups如何限制进程使用的内存资源，我们以内存为例进行讲解。

Ubuntu18.04已经为我们挂载了一个关联memory子系统的cgroup虚拟文件系统。我们用mount命令查看一下该系统挂载到了何处，命令及结果如下：

phl@kernelnewbies:~$ mount | grep cgroup
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)

该系统挂载到了/sys/fs/cgroup/memory目录下。我们在该hierarchy中创建一个test cgroup并查看该cgroup的目录结构，命令及结果如下：

phl@kernelnewbies:~$ sudo mkdir /sys/fs/cgroup/memory/test
phl@kernelnewbies:~$ tree /sys/fs/cgroup/memory/test
/sys/fs/cgroup/memory/test
├── cgroup.clone_children
├── cgroup.event_control
├── cgroup.procs
├── memory.failcnt
├── memory.force_empty
├── memory.kmem.failcnt
├── memory.kmem.limit_in_bytes
├── memory.kmem.max_usage_in_bytes
├── memory.kmem.slabinfo
├── memory.kmem.tcp.failcnt
├── memory.kmem.tcp.limit_in_bytes
├── memory.kmem.tcp.max_usage_in_bytes
├── memory.kmem.tcp.usage_in_bytes
├── memory.kmem.usage_in_bytes
├── memory.limit_in_bytes
├── memory.max_usage_in_bytes
├── memory.move_charge_at_immigrate
├── memory.numa_stat
├── memory.oom_control
├── memory.pressure_level
├── memory.soft_limit_in_bytes
├── memory.stat
├── memory.swappiness
├── memory.usage_in_bytes
├── memory.use_hierarchy
├── notify_on_release
└── tasks
0 directories, 27 files

从结果我们可以看到，新建的test cgroup中有许多文件，这些文件中存放着资源限制信息。其中memory.limit_in_bytes里面存放的是该cgroup中的进程能够使用的内存额度。

下面，我们将当前bash加入到test cgroup中并查看当前bash所属的cgroup信息。命令及结果如下：

phl@kernelnewbies:~$ echo $$
2984
phl@kernelnewbies:~$ sudo sh -c "echo 2984 > /sys/fs/cgroup/memory/test/cgroup.procs"
phl@kernelnewbies:~$ cat /proc/2984/cgroup
12:devices:/user.slice
11:hugetlb:/
10:memory:/test
9:rdma:/
8:perf_event:/
7:blkio:/user.slice
6:cpu,cpuacct:/user.slice
5:pids:/user.slice/user-1001.slice/session-4.scope
4:freezer:/
3:cpuset:/
2:net_cls,net_prio:/
1:name=systemd:/user.slice/user-1001.slice/session-4.scope
0::/user.slice/user-1001.slice/session-4.scope

从结果我们可以看到，当前bash所属的memory cgroup变为了/test，该目录为一个相对于root cgroup的相对路径。

然后，将100M写入test cgroup中的memory.limit_in_bytes文件中，命令如下：

phl@kernelnewbies:~$ sudo sh -c "echo 100M > /sys/fs/cgroup/memory/test/memory.limit_in_bytes"

我们在当前bash中启动一个占用300M进程的stress进程，该stress进程是bash的子进程，其与bash进程都在test cgroup中。命令如下：

phl@kernelnewbies:~$ stress --vm 1 --vm-bytes 300M --vm-keep

启动一个新的Shell窗口，执行top命令查看stress进程占用的内存。命令及结果如下：

PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
14216 root      20   0  315440 101224    264 D 27.7  2.5   0:02.66 stress

从结果我们可以看到，stress进程占用了2.5%的内存。我的电脑的内存为4G，4G * 2.5% = 100M，stress进程确实受到了cgroup中设置的内存额度的限制。

`docker.sh`

下有了以上关于CGroups的知识，我们就可以将限制内存的功能加入到docker.sh中了。限制内存的功能将放在container.sh中，带下划线的行是我们为实现限制内存而新添的代码。修改后的container.sh脚本如下：

hostname $container
mkdir -p /sys/fs/cgroup/memory/$container
echo $$ > /sys/fs/cgroup/memory/$container/cgroup.procs
echo $memory > /sys/fs/cgroup/memory/$container/memory.limit_in_bytes
mount -t proc proc /proc
exec $program

首先，我们根据容器的名字创建cgroup，命令如下：

mkdir -p /sys/fs/cgroup/memory/$container

然后，我们将当前bash加入到我们创建的cgroup中，命令如下：

echo $$ > /sys/fs/cgroup/memory/$container/cgroup.procs

最后，我们将内存限制写入新cgroup的memory.limit_in_bytes文件中，命令如下：

echo $memory > /sys/fs/cgroup/memory/$container/memory.limit_in_bytes

现在，我们运行docker.sh，并启动一个占用300M进程的stress进程。命令及结果如下：

phl@kernelnewbies:~/docker.sh$ sudo ./docker.sh -c run -m 100M -C dreamland -I ubuntu1604 -V data1 -P /bin/bash
root@dreamland:~/docker.sh# stress --vm 1 --vm-bytes 300M --vm-keep
stress: info: [12] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd

启动一个新的Shell窗口，执行top命令查看stress进程占用的内存。命令及结果如下：

PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
14216 root      20   0  315440 101224    264 D 27.7  2.5   0:02.66 stress

从结果我们可以看到，容器内的stress进程只使用了100M的内存。

切换根文件系统

根文件系统

在容器技术中，根文件系统可为容器进程提供一个与主机不一致的文件系统环境。举个例子，主机为Ubuntu 18.04，创建的容器采用Ubuntu 16.04的根文件系统，那么容器运行时所用的软件及其依赖库、配置文件等都是Ubuntu 16.04的。尽管该容器使用的内核是仍旧是Ubuntu 18.04的，但应用软件的表现却与Ubuntu 16.04一致，从虚拟化的角度来说该容器就是一个Ubuntu 16.04系统。

debootstrap是Ubuntu下的一个工具，用来构建根文件系统。生成的目录符合Linux文件系统标准，即包含了/boot、/etc、/bin、/usr等目录。debootstrap的安装命令如下：

sudo apt install debootstrap

下面我们通过debootstrap构建Ubuntu 16.04的根文件系统。为了清晰，我们在images目录下生成根文件系统。命令及结果如下：

phl@kernelnewbies:~/docker.sh$ mkdir images
phl@kernelnewbies:~/docker.sh$ cd images
phl@kernelnewbies:~/docker.sh/images$ sudo debootstrap --arch amd64 xenial ./ubuntu1604

制作根文件系统需要从服务器下载很多文件，很耗时，请耐心等待。当文件系统制作好后，可以使用tree命令查看生成的根文件系统。命令及结果如下：

phl@kernelnewbies:~/docker.sh/images$ tree -L 1 ubuntu1604/
ubuntu1604/
├── bin
├── boot
├── dev
├── etc
├── home
├── lib
├── lib64
├── media
├── mnt
├── old_root
├── opt
├── proc
├── root
├── run
├── sbin
├── srv
├── sys
├── tmp
├── usr
└── var
20 directories, 0 files

这个根文件系统与Linux系统目录很相近，我们后续的实验将使用该根文件系统。

pivot_root

pivot_root命令用于切换根文件系统，其使用方式如下：

pivot_root new_root put_old

pivot_root将当前进程的根文件系统移至put_old目录并使new_root目录成为新的根文件系统。

下面我们将通过实验学习pivot_root的使用方法。为了简单，我们在一个新的mount namespace下进行实验。首先，我们创建一个新的mount namespace，命令及结果如下：

phl@kernelnewbies:~/docker.sh/images$ sudo unshare --mount /bin/bash
root@kernelnewbies:~/docker.sh/images#

在我们的实验中，我们的根文件系统将挂载在ubuntu1604目录，而老的根文件系统将被移动到ubuntu1604/old_root目录下。我们先创建old_root目录，命令如下：

root@kernelnewbies:~/docker.sh/images# mkdir -p ubuntu1604/old_root/

由于pivot_root命令要求老的根目录和新的根目录不能在同一个挂载点下，因此我们通过bind mount将ubuntu1604目录变成一个挂载点。命令及结果如下：

root@kernelnewbies:~/docker.sh/images# mount --bind ubuntu1604 ubuntu1604
root@kernelnewbies:~/docker.sh/images# cat /proc/self/mountinfo | grep ubuntu1604
624 382 8:1 /home/phl/docker.sh/images/ubuntu1604 /home/phl/docker.sh/images/ubuntu1604 rw,relatime - ext4 /dev/sda1 rw,errors=remount-ro

准备好切换根文件系统所需要的条件后，我们调用pivot_root切换根文件系统。命令及结果如下：

root@kernelnewbies:~/docker.sh/images# cd ubuntu1604/
root@kernelnewbies:~/docker.sh/images/ubuntu1604# pivot_root . old_root/

此时，已完成根文件系统的切换，/proc文件系统也被挪到了
/home/phl/docker.sh/images/ubuntu1604/old_root/proc，也就是说当前没有/proc文件系统，因此，我们无法查看挂载点信息，自然也无法执行一些依赖于/proc文件系统的操作。我们需要重新挂载/proc文件系统。命令如下：

root@kernelnewbies:~/docker.sh/images/ubuntu1604# mount -t proc proc /proc

重新挂载/proc文件系统后，我们就可以查看当前的挂载点信息了。通过读取/proc/self/mountinfo文件来查看系统的挂载点信息。命令及结果如下：

root@kernelnewbies:~/docker.sh/images/ubuntu1604# cat /proc/self/mountinfo
382 624 8:1 / /old_root rw,relatime - ext4 /dev/sda1 rw,errors=remount-ro
...
624 381 8:1 /home/phl/docker.sh/images/ubuntu1604 / rw,relatime - ext4 /dev/sda1 rw,errors=remount-ro
625 624 0:5 / /proc rw,relatime - proc proc rw

此时的挂载点很多，为了方便查看，此处只保留了一些主要的挂载点信息。这些挂载点信息包括/、/proc、/old_root。/old_root为老的根文件系统，我们需要将其卸载。命令及结果如下：

root@kernelnewbies:~/docker.sh/images/ubuntu1604# umount -l /old_root/

卸载掉老的根文件系统后，我们再查看系统的挂载点信息。命令及结果如下：

root@kernelnewbies:~/docker.sh/images/ubuntu1604# cat /proc/self/mountinfo
624 381 8:1 /home/phl/docker.sh/images/ubuntu1604 / rw,relatime - ext4 /dev/sda1 rw,errors=remount-ro
625 624 0:5 / /proc rw,relatime - proc proc rw

此时，挂载点信息中只有/、/proc，不再有主机的挂载点信息。

`docker.sh`

有了以上关于切换根文件系统的知识，我们就可以将切换根文件系统的功能加入到docker.sh中了。切换根文件系统的功能将放在container.sh中，带下划线的行是我们为实现切换根文件系统而新添的代码。修改后的container.sh脚本如下：

#!/bin/bash

hostname $container

mkdir -p /sys/fs/cgroup/memory/$container
echo $$ > /sys/fs/cgroup/memory/$container/cgroup.procs
echo $memory > /sys/fs/cgroup/memory/$container/memory.limit_in_bytes

mkdir -p images/$image/old_root
mount --bind images/$image images/$image

cd images/$image
pivot_root . ./old_root

mount -t proc proc /proc
umount -l /old_root

exec $program

首先，我们在新的根文件系统目录中创建挂载老的根文件系统的目录。命令如下：

mkdir -p images/$image/old_root

然后，我们将新根文件系统目录bind mount成一个挂载点。命令如下：

mount --bind images/$image images/$image

然后，我们切换根文件系统。命令如下：

cd images/$image
pivot_root . ./old_root

最后，我们重新挂载/proc文件系统，然后卸载掉老的根文件系统。命令如下：

mount -t proc proc /proc
umount -l /old_root

现在，我们运行docker.sh，并查看当前的发行版信息。命令及结果如下：

phl@kernelnewbies:~/docker.sh$ sudo ./docker.sh -c run -m 100M -C dreamland -I ubuntu1604 -V data1 -P /bin/bash
root@dreamland:/# cat /etc/issue
Ubuntu 16.04 LTS \n \l

从结果我们可以看出，读出的发行版信息是Ubuntu 16.04 LTS \n \l，而非主机的Ubuntu 18.04.3 LTS \n \l。这说明当前使用的根文件系统确实是ubuntu16.04目录下的根文件系统，而非主机的根文件系统。

我们再查看一下当前的挂载点信息，看看是否只有/与/proc。命令及结果如下：

root@dreamland:/# cat /proc/self/mountinfo
625 381 8:1 /home/phl/docker.sh/images/ubuntu1604 / rw,relatime - ext4 /dev/sda1 rw,errors=remount-ro
626 625 0:52 / /proc rw,relatime - proc proc rw

从结果我们可看出，当前挂载点信息中只有/、/proc，不再有主机的挂载点信息。

通过根文件系统，我们实现了在容器中虚拟出与主机不一样的操作系统的功能。

联合加载

联合加载简介

联合加载指的是一次同时加载多个文件系统，但是在外面看起来只能看到一个文件系统。联合加载会将各层文件系统叠加到一起，这样最终的文件系统会包含所有底层的文件和目录。

联合加载的多个文件系统中有一个是可读写文件系统，称为读写层，其他文件系统是只读的，称为只读层。当联合加载的文件系统发生变化时，这些变化都应用到这个读写层。比如，如果想修改一个文件，这个文件首先会从只读层复制到读写层。原只读层中的文件依然存在，但是被读写层中的该文件副本所隐藏。我们以后读写该文件时，都是读写的该文件在读写层中的副本。这种机制被称为写时复制。

我们之前实现的docker.sh，有一个很大的缺陷。那就是，如果使用相同的根文件系统同时启动多个容器的实例，那么，这些容器实例使用的根文件系统位于同一个目录。我们在不同的容器实例对根文件系统所作的修改，这些容器彼此之间都可以看到，甚至一个容器可以覆覆盖另一个容器所作的修改。同时，容器实例退出时，对根文件系统所作的修改也直接作用于其所使用的根文件系统。当我们使用该根文件系统再次启动容器实例时，新启动的容器实例也可以看到以前的这些修改。例如，我们用ubuntu1604根文件系统启动两个容器实例，命令如下：

phl@kernelnewbies:~/docker.sh$ sudo ./docker.sh -c run -m 100M -C dreamland -I ubuntu1604 -V data1 -P /bin/bash
phl@kernelnewbies:~/docker.sh$ sudo ./docker.sh -c run -m 100M -C dreamland2 -I ubuntu1604 -V data1 -P /bin/bash

这两个容器实例对根文件系统做的修改彼此都可以看到。容器实例退出时，这些修改也被保存了下来，当用ubuntu1604根文件系统启动新的容器实例时，新实例也可看到以前实例所做的修改。

如果容器使用的根文件系统是一个联合加载的文件系统，原先的根文件系统作为一个只读层，再添加一个读写层，那么，在容器内所作的修改都将只作用于读写层。为了区分，我们以后称ubuntu1604目录下的根文件系统为镜像。而我们可以为每一个容器实例指定一个唯一的读写层目录，这样的话，多个容器实例就可以使用同一个镜像，容器内所作的修改不会影响彼此，也不会影响到以后启动的容器实例。例如：

phl@kernelnewbies:~/docker.sh$ sudo ./docker.sh -c run -m 100M -C dreamland -I ubuntu1604 -V data1 -P /bin/bash
phl@kernelnewbies:~/docker.sh$ sudo ./docker.sh -c run -m 100M -C dreamland2 -I ubuntu1604 -V data1 -P /bin/bash

我们使用ubuntu1604镜像启动了两个容器示例，并在容器实例里进行读写操作。这两个容器实例的读写层目录是不一样的，在容器实例中所作的修改只作用于各自的读写层，彼此之间不会影响，当然更不会影响到后续启动的容器实例。

AUFS

AUFS是一个实现了联合加载功能的文件系统。我们将采用AUFS实现docker.sh中的联合加载功能。

下面，我们将通过实验演示一下AUFS文件系统的用法。首先，我们准备需要用到的目录及文件。命令及结果如下：

phl@kernelnewbies:~$ mkdir aufs
phl@kernelnewbies:~$ cd aufs/
phl@kernelnewbies:~/aufs$ mkdir rw r1 r2 union
phl@kernelnewbies:~/aufs$ echo hello r1 > r1/hellor1.txt
phl@kernelnewbies:~/aufs$ echo hello r2 > r2/hellor2.txt
phl@kernelnewbies:~/aufs$ echo hello rw > rw/hellorw.txt

下表列出了各个目录的作用。列表如下：

rw为aufs文件系统的读写层目录
r1为aufs文件系统的只读层目录
r2为aufs文件系统的只读层目录
union为挂载点，联合加载的aufs文件系统挂载于此目录

下面我们将rw、r1、r2联合加载到union目录。命令如下：

phl@kernelnewbies:~/aufs$ sudo mount -t aufs -o dirs=rw:r1:r2 none union

-t aufs表示要挂载的文件系统类型为AUFS
-o dirs=rw:r1:r2表示要将哪些目录加载到afus文件系统中，多个目录之间以:分隔。目录列表中的第一个目录表示读写层目录
union表示aufs文件系统要挂载的目录

挂载好AUFS文件系统后，我们进入该文件系统，查看其内容。命令及结果如下：

phl@kernelnewbies:~/aufs$ cd union/
phl@kernelnewbies:~/aufs/union$ ls
hellor1.txt hellor2.txt hellorw.txt

从输出结果来看，rw、r1、r2目录下的内容全部出现在了AUFS文件系统中，该文件系统由rw、r1、r2目录叠加而成。

然后，我们修改这些文件，看看原始的rw、r1、r2目录下的文件是否更改。命令及结果如下：

phl@kernelnewbies:~/aufs/union$ echo hello to r1 from union > hellor1.txt
phl@kernelnewbies:~/aufs/union$ echo hello to r2 from union > hellor2.txt
phl@kernelnewbies:~/aufs/union$ echo hello to rw from union > hellorw.txt

我们返回到aufs目录，直接查看aufs目录下的内容。命令及结果如下：

phl@kernelnewbies:~/aufs$ tree .
.
├── r1
│   └── hellor1.txt
├── r2
│   └── hellor2.txt
├── rw
│   ├── hellor1.txt
│   ├── hellor2.txt
│   └── hellorw.txt
└── union
    ├── hellor1.txt
    ├── hellor2.txt
    └── hellorw.txt

4 directories, 8 files

从输出结果我们可以看到，我们修改的hellor1.txt和hellor2.txt文件分别被拷贝了一份放在读写层目录rw中。我们查看一下这些文件的内容，命令及结果如下：

phl@kernelnewbies:~/aufs$ cat r1/hellor1.txt
hello r1
phl@kernelnewbies:~/aufs$ cat r2/hellor2.txt
hello r2
phl@kernelnewbies:~/aufs$ cat rw/hellor1.txt
hello to r1 from union
phl@kernelnewbies:~/aufs$ cat rw/hellor2.txt
hello to r2 from union
phl@kernelnewbies:~/aufs$ cat rw/hellorw.txt
hello to rw from union

从输出结果我们看到，用户修改只读层r1、r2中的文件时，这些文件被复制到了读写层，我们修改的是读写层的副本，原只读层中的文件没有变化。用户修改读写层rw中的文件时，修改直接作用于这些文件本身。

`docker.sh`

在继续之前，我们需要将上一章在ubuntu1604根文件系统中创建的old_root目录删除掉，以保证该根文件系统跟刚制作好时一样。命令及结果如下：

phl@kernelnewbies:~/docker.sh$ sudo rm -rf images/ubuntu1604/old_root

有了以上关于联合加载的介绍，我们就可以将联合加载功能加入到docker.sh中了。联合加载功能将放在container.sh脚本中，带下划线的行是我们为实现联合加载功能而新添的代码。修改后的container.sh如下：

#!/bin/bash

hostname $container

mkdir -p /sys/fs/cgroup/memory/$container
echo $$ > /sys/fs/cgroup/memory/$container/cgroup.procs
echo $memory > /sys/fs/cgroup/memory/$container/memory.limit_in_bytes

mkdir -p $container/rwlayer
mount -t aufs -o dirs=$container/rwlayer:./images/$image none $container

mkdir -p $container/old_root
cd $container
pivot_root . ./old_root

mount -t proc proc /proc
umount -l /old_root

exec $program

首先，我们根据容器的名字创建联合加载需要的读写层目录及文件系统挂载目录。命令如下：

mkdir -p $container/rwlayer

假如我们传递的容器的名字为dreamland，将创建以下目录：

phl@kernelnewbies:~/docker.sh$ tree dreamland/
dreamland/
└── rwlayer

其中dreamland/rwlayer目录为创建的AUFS文件系统的读写层，dreamland目录为AUFS文件系统的挂载点。

然后我们将镜像目录、读写层目录联合加载到挂载点目录。命令如下：

mount -t aufs -o dirs=$container/rwlayer:./images/$image none $container

假如容器名字为dreamland，使用的镜像为ubuntu1604根文件系统，dreamland/rwlayer、images/ubuntu1604将被联合加载的dreamland目录。其中，dreamland/rwlayer为AUFS文件系统的读写层，images/ubuntu1604为AUFS文件系统的只读层。

之前我们将老的根文件系统挪到了rootfs/old_root，rootfs代表一个具体的镜像目录。创建old_root目录时直接修改了该镜像。下面我们将老的根文件系统的挂载点目录放在AUFS文件系统中，并将老的根文件系统挪到此处。命令如下：

mkdir -p $container/old_root
cd $container
pivot_root . ./old_root

此时，$container目录本身就是一个挂载点，挂载了AUFS文件系统。因此下面的代码就被移除了：

mount --bind images/$image images/$image

现在，我们运行docker.sh，并在/root下创建一个文件。命令及结果如下：

phl@kernelnewbies:~/docker.sh$ sudo ./docker.sh -c run -m 100M -C dreamland -I ubuntu1604 -V data1 -P /bin/bash
root@dreamland:/# cd /root
root@dreamland:/root# ls
root@dreamland:/root# cat /etc/issue > hello.txt
root@dreamland:/root# cat hello.txt
Ubuntu 16.04 LTS \n \l

启动一个新的Shell窗口，查看一下该容器使用的AUFS文件系统。命令及结果如下：

phl@kernelnewbies:~/docker.sh$ sudo tree dreamland/
dreamland/
└── rwlayer
    ├── old_root
    └── root
        └── hello.txt

2 directories, 1 file

从结果我们可以看到，我们新建的文件及创建的老根文件系统的挂载点目录都出现在了读写层。我们再查看一下新创建的文件。命令及结果如下：

phl@kernelnewbies:~/docker.sh$ sudo cat dreamland/rwlayer/root/hello.txt
Ubuntu 16.04 LTS \n \l

文件内容是Ubuntu 16.04的发行版信息。

通过联合加载，我们实现了在容器中的读写不会影响使用的镜像。这样使用ubuntu1604镜像创建多个容器时，彼此之间就不会相互影响了。

卷

卷简介

卷是容器内的一个目录，这个目录可以绕过联合文件系统，提供数据共享（容器所使用的的联合文件系统不应该被主机或其他容器访问）与数据持久化的功能。

举个例子，假如容器有个目录为/data的卷，我们向这个卷写入的内容不会出现在联合文件系统的读写层，而是直接出现在这个目录里。主机与其他容器也可以访问该目录，从而达到数据共享与数据持久化的目的。

卷位于联合文件系统中，通常来说写入该目录的内容会被写入容器的读写层中，那么怎样才能是写入卷的目录直接出现在该目录中，而不是容器读写层呢？其实方法很简单，只要我们将该目录变成一个挂载点就行，变成挂载点后，这个目录中的内容就不属于联合文件系统了，写入该目录的内容自然会保存在挂载到该挂载点的设备中。

`docker.sh`

有了以上关于卷的介绍，我们就可以将卷功能加入到docker.sh中了。卷功能将放在container.sh脚本中，带下划线的行是我们为实现卷功能而新添的代码。修改后的container.sh脚本如下：

#!/bin/bash

hostname $container

mkdir -p /sys/fs/cgroup/memory/$container
echo $$ > /sys/fs/cgroup/memory/$container/cgroup.procs
echo $memory > /sys/fs/cgroup/memory/$container/memory.limit_in_bytes

mkdir -p $container/rwlayer
mount -t aufs -o dirs=$container/rwlayer:./images/$image none $container

mkdir -p $volume
mkdir -p $container/$volume
mount --bind $volume $container/$volume

mkdir -p $container/old_root
cd $container
pivot_root . ./old_root

mount -t proc proc /proc
umount -l /old_root

exec $program

首先，我们根据卷的名字创建主机卷目录，我们在容器内部对卷的修改，都将作用于此目录。命令如下：

mkdir -p $volume

然后，我们在容器内部创建同名卷目录，该目录本身会出现在容器的读写层中，因为该目录是在AUFS文件系统中创建的。因为 $c o n t a i n e r 目录为容器的根目录，所以容器内部卷目录的路径为 /$ volume。命令如下：

mkdir -p $container/$volume

将主机上的卷目录bind mount到容器内部的卷目录上，这样容器内部对卷目录的修改，都将作用于主机卷目录。命令如下：

mount --bind $volume $container/$volume

现在，我们运行docker.sh，并在卷目录（/data1）中创建一个文件。命令及结果如下：

phl@kernelnewbies:~/docker.sh$ sudo ./docker.sh -c run -m 100M -C dreamland -I ubuntu1604 -V data1 -P /bin/bash
root@dreamland:/# cd /data1
root@dreamland:/data1# echo "hello to data1 volume from ubuntu16.04" >> hello.txt

启动一个新的Shell窗口，查看一下该容器使用的AUFS文件系统中的内容。命令及结果如下：

phl@kernelnewbies:~/docker.sh$ sudo tree dreamland/
dreamland/
└── rwlayer
    ├── data1
    ├── old_root
    └── root
        └── hello.txt

4 directories, 1 file

从结果我们可以看到，我们使用的卷目录被创建在了容器的读写层，但是我们在卷目录中新建的文件却没有出现在读写层中。

我们再来查看一下主机卷目录的内容。命令及结果如下：

phl@kernelnewbies:~/docker.sh$ sudo tree data1/
data1/
└── hello.txt

0 directories, 1 file

从结果我们可以看到，在容器内部对卷目录的修改直接作用在了主机上的卷目录。我们再来查看一下主机卷目录下hello.txt中的内容。命令及结果如下：

phl@kernelnewbies:~/docker.sh$ sudo cat data1/hello.txt
hello to data1 volume from ubuntu16.04

从结果我们可以看到，该文件的内容与我们在容器内部写入hello.txt的内容一致。

通过卷目录，我们实现了容器之间数据共享与数据持久化的功能。

后记

至此，我们通过一系列的实验对docker的底层技术有了一个感性的认识。我们在使用docker时，也能够对其是如何运作的有了一个大致的了解。当然，这对于掌握docker技术来说还远远不够，有很多知识我们没有涉及，例如user namespace、容器安全、其他的CGroups、虚拟网络等。

编辑整理 ScratchLab

系列教程

全部文章RSS订阅

Docker系列

Docker 分类 RSS 订阅

Hexo系列

HexoRSS分类订阅

[十万字图文教程]基于Hexo的matery主题搭建博客并深度优化完全一站式教程

markdown 各种其它语法插件，latex公式支持，mermaid图表，plant uml图表，URL卡片，bilibili卡片，github卡片，豆瓣卡片，插入音乐和视频，插入脑图，插入PDF，嵌入iframe

Earthly 一个更加强大的镜像构建工具

2021-10-31T23:25:00.000Z

一、Earthly 介绍

开局一张图，功能全靠吹。

Earthly 是一个更加高级的 Docker 镜像构建工具，Earthly 通过自己定义的 Earthfile 来代替传统的 Dockerfile 完成镜像构建；Earthfile 就如同 Earthly 官方所描述:

**Makefile + Dockerfile = Earthfile**

在使用 Earthly 进行构建镜像时目前强依赖于 buildkit，Earthly 通过 buildkit 支持了一些 Dockerfile 的扩展语法，同时将 Dockerfile 与 Makefile 整合，使得多平台构建和代码化 Dockerfile 变得更加简单；使用 Earthly 可以更加方便的完成 Dockerfile 的代码复用以及更加友好的 CI 自动集成。

二、快速开始

2.1、安装依赖

Earthly 目前依赖于 Docker 和 Git，所以安装 Earthly 前请确保机器已经安装了 Docker 和 Git。

2.2、安装 Earthly

Earthly 采用 Go 编写，所以主要就一个二进制文件，Linux 下安装可以直接参考官方的安装脚本:

sudo /bin/sh -c 'wget https://github.com/earthly/earthly/releases/latest/download/earthly-linux-amd64 -O /usr/local/bin/earthly && chmod +x /usr/local/bin/earthly && /usr/local/bin/earthly bootstrap --with-autocomplete'Copy

安装完成后 Earthly 将会启动一个 buildkitd 容器: earthly-buildkitd。

2.3、语法高亮

目前 Earthly 官方支持 VS Code、VIM 以及 Sublime Text 三种编辑器的语法高亮，具体如何安装请参考官方文档。

2.4、基本使用

本示例源于官方 Basic 教程，以下示例以编译 Go 项目为样例:

首先创建一个任意名称的目录，目录中存在项目源码文件以及一个 Earthfile 文件；

main.go

package main

import "fmt"

func main() {
    fmt.Println("hello world")
}Copy

Earthfile

FROM golang:1.17-alpine
WORKDIR /go-example

build:
    COPY main.go .
    RUN go build -o build/go-example main.go
    SAVE ARTIFACT build/go-example /go-example AS LOCAL build/go-example

docker:
    COPY +build/go-example .
    ENTRYPOINT ["/go-example/go-example"]
    SAVE IMAGE go-example:latestCopy

有了 Earthfile 以后我们就可以使用 Earthly 将其打包为镜像；

# 目录结构
~/t/earthlytest ❯❯❯ tree
.
├── Earthfile
└── main.go

0 directories, 2 files

# 通过 earthly 进行构建
~/t/earthlytest ❯❯❯ earthly +dockerCopy

构建完成后我们就可以直接从 docker 的 images 列表中查看刚刚构建的镜像，并运行:

三、进阶使用

3.1、多阶段构建

Earthfile 中包含类似 Makefile 一样的 target，不同的 target 之间还可以通过特定语法进行引用，每个 target 都可以被单独执行，执行过程中 earthly 会自动解析这些依赖关系。

这种多阶段构建时语法很弹性，我们可以在每个阶段运行独立的命令以及使用不同的基础镜像；从快速开始中可以看到，我们始终使用了一个基础镜像(golang:1.17-alpine)，对于 Go 这种编译后自带运行时不依赖其语言 SDK 的应用，我们事实上可以将 “发布物” 仅放在简单的运行时系统镜像内，从而减少最终镜像体积:

由于使用了多个 target，所以我们可以单独的运行 build 这个 target 来验证我们的编译流程，这种多 target 的设计方便我们构建应用时对编译、打包步骤的细化拆分，同时也方便我们进行单独的验证。 例如我们单独执行 build 这个 target 来验证我们的编译流程是否正确:

在其他阶段验证完成后，我们可以直接运行最终的 target，earthly 会自动识别到这种依赖关系从而自动运行其依赖的 target:

3.2、扩展指令

3.2.1、SAVE

SAVE 指令是 Earthly 自己的一个扩展指令，实际上分为 SAVE ARTIFACT 和 SAVE IMAGE；其中 SAVE ARTIFACT 指令格式如下:

SAVE ARTIFACT [--keep-ts] [--keep-own] [--if-exists] [--force] <src> [<artifact-dest-path>] [AS LOCAL <local-path>]Copy

SAVE ARTIFACT 指令用于将文件或目录从 build 运行时环境保存到 target 的 artifact 环境；当保存到 artifact 环境后，可以通过 COPY 等命令在其他位置进行引用，类似于 Dockerfile 的 COPY --from... 语法；不同的是 SAVE ARTIFACT 支持 AS LOCAL <local-path> 附加参数，一但指定此参数后，earthly 会同时将文件或目录在宿主机复制一份，一般用于调试等目的。SAVE ARTIFACT 命令在上面的样例中已经展示了，在运行完 earthly +build 命令后实际上会在本地看到被 SAVE 出来的 ARTIFACT:

而另一个 SAVE IMAGE 指令则主要用于将当前的 build 环境 SAVE 为一个 IMAGE，如果指定了 --push 选项，同时在执行 earthly +target 命令时也加入 --push 选项，该镜像将会自动被推送到目标 Registry 上。SAVE IMAGE 指令格式如下:

SAVE IMAGE [--cache-from=<cache-image>] [--push] <image-name>...Copy

3.2.2、GIT CLONE

GIT CLONE 指令用于将指定 git 仓库 clone 到 build 环境中；与 RUN git clone... 命令不同的是，GIT CLONE 通过宿主机的 git 命令运行，它不依赖于容器内的 git 命令，同时还可以直接为 earthly 配置 git 认证，从而避免将这些安全信息泄漏到 build 环境中；关于如何配置 earthly 的 git 认证请参考官方文档；下面是 GIT CLONE 指令的样例

3.2.3、COPY

COPY 指令与标准的 Dockerfile COPY 指令类似，除了支持 Dockerfile 标准的 COPY 功能以外，earthly 中的 COPY 指令可以引用其他 target 环节产生的 artifact，在引用时会自动声明依赖关系；即当在 B target 中存在 COPY +A/xxxxx /path/to/copy 类似的指令时，如果只单纯的执行 earthly +B，那么 earthly 根据依赖分析会得出在 COPY 之前需要执行 target A。COPY 指令的语法格式如下:

# 与 Dockerfile 相同的使用方式，从上下文复制
COPY [options...] <src>... <dest>

# 扩展支持的从 target 复制方式
COPY [options...] <src-artifact>... <dest>Copy

3.2.4、RUN

RUN 指令在标准使用上与 Dockerfile 里保持一致，除此之外增加了更多的扩展选项，其指令格式如下:

# shell 方式运行(/bin/sh -c)
RUN [--push] [--entrypoint] [--privileged] [--secret <env-var>=<secret-ref>] [--ssh] [--mount <mount-spec>] [--] <command>

# exec 方式运行
RUN [[<flags>...], "<executable>", "<arg1>", "<arg2>", ...]Copy

其中 --privileged 选项允许运行的命令使用 privileged capabilities，但是需要 earthly 在运行 target 时增加 --allow-privileged 选项；--interactive / --interactive-keep 选项用于交互式执行一些命令，在完成交互后 build 继续进行，在交互过程中进行的操作都会被持久化到镜像中:

限于篇幅原因，其他的具体指令请查阅官方文档 Earthfile reference。

3.3、UDCS

UDCs 全称 “User-defined commands”，即用户定义指令；通过 UDCs 我们可以将 Earthfile 中特定的命令剥离出来，从而实现更加通用和统一的代码复用；下面是一个定义 UDCs 指令的样例:

# 定义一个 Command
# ⚠️ 注意: 语法必须满足以下规则
# 1、名称全大写
# 2、名称下划线分割
# 3、首个命令必须为 COMMAND(后面没有冒号)
MY_COPY:
    COMMAND
    ARG src
    ARG dest=./
    ARG recursive=false
    RUN cp $(if $recursive =  "true"; then printf -- -r; fi) "$src" "$dest"

# target 中引用
build:
    FROM alpine:3.13
    WORKDIR /udc-example
    RUN echo "hello" >./foo
    # 通过 DO 关键字引用 UDCs
    DO +MY_COPY --src=./foo --dest=./bar
    RUN cat ./bar # prints "hello"Copy

UDCs 不光可以定义在一个 Earthfile 中，UDCs 可以跨文件、跨目录引用:

有了 UDCs 以后，我们可以通过这种方式将对基础镜像的版本统一控制、对特殊镜像的通用处理等操作全部抽象出来，然后每个 Earthfile 根据需要进行引用；关于 UDCs 的使用样例可以参考我的 autobuild 项目，其中的 udcs 目录定义了大量的通用 UDCs，这些 UDCs 被其他目标镜的 Earthfile 批量引用。

3.4、多平台构建

在以前使用 Dockerfile 的时候，我们需要自己配置然后开启 buildkit 来实现多平台构建；在配置过程中可能会很繁琐，现在使用 earthly 可以默认帮我们实现多平台的交叉编译，我们需要做的仅仅是在 Earthfile 中声明需要支持哪些平台而已:

以上 Earthfile 在执行 earthly --push +all 构建时，将会自动构建四个平台的镜像，并保持单个 tag，同时由于使用了 --push 选项还会自动推送到 Docker Hub 上:

四、总结

Earthly 弥补了 Dockerfile 的很多不足，解决了很多痛点问题；但同样可能需要一些学习成本，但是如果已经熟悉了 Dockerfile 其实学习成本不高；所以目前还是比较推荐将 Dockerfile 切换为 Earthfile 进行统一和版本化管理的。本文由于篇幅所限(懒)很多地方没有讲，比如共享缓存等，所以关于 Earthly 更多的详细使用等最好还是仔细阅读一下官方文档。

整理转载：the-best-image-build-tool-earthly

系列教程

全部文章RSS订阅

Docker系列

Docker 分类 RSS 订阅

如何使用Traefik V2 在Ubuntu20.04 上面来做 Dockers Containers 的反向代理

2021-10-14T11:25:00.000Z

How To Use Traefik v2 as a Reverse Proxy for Docker Containers on Ubuntu 20.04

Traefik 适合配合Dockers swarm 做服务， Dockers portainer 做管理，ELK集群做监控日志。

traefik 与 nginx 一样，是一款优秀的反向代理工具，或者叫 Edge Router。至于使用它的原因则基于以下几点

无须重启即可更新配置
自动的服务发现与负载均衡
与 docker 完美集成，基于 container label 的配置
漂亮的 dashboard 界面
metrics 的支持，支持对 prometheus 和 k8s 集成

Introduction

Docker can be an efficient way to run web applications in production, but you may want to run multiple applications on the same Docker host. In this situation, you’ll need to set up a reverse proxy. This is because you only want to expose ports 80 and 443 to the rest of the world.

Traefik is a Docker-aware reverse proxy that includes a monitoring dashboard. Traefik v1 has been widely used for a while, and you can follow this earlier tutorial to install Traefik v1). But in this tutorial, you’ll install and configure Traefik v2, which includes quite a few differences.

The biggest difference between Traefik v1 and v2 is that frontends and backends were removed and their combined functionality spread out across routers, middlewares, and services. Previously a backend did the job of making modifications to requests and getting that request to whatever was supposed to handle it. Traefik v2 provides more separation of concerns by introducing middlewares that can modify requests before sending them to a service. Middlewares make it easier to specify a single modification step that might be used by a lot of different routes so that they can be reused (such as HTTP Basic Auth, which you’ll see later). A router can also use many different middlewares.

In this tutorial you’ll configure Traefik v2 to route requests to two different web application containers: a Wordpress container and an Adminer container, each talking to a MySQL database. You’ll configure Traefik to serve everything over HTTPS using Let’s Encrypt.

Prerequisites

To complete this tutorial, you will need the following:

One Ubuntu 20.04 server with a sudo non-root user and a firewall. You can set this up by following our Ubuntu 20.04 initial server setup guide.
Docker installed on your server, which you can accomplish by following Steps 1 and 2 of How to Install and Use Docker on Ubuntu 20.04.
Docker Compose installed using the instructions from Step 1 of How to Install Docker Compose on Ubuntu 20.04.
A domain and three A records, db-admin.your_domain, blog.your_domain and monitor.your_domain. Each should point to the IP address of your server. You can learn how to point domains to DigitalOcean Droplets by reading through DigitalOcean’s Domains and DNS documentation. Throughout this tutorial, substitute your domain for your_domain in the configuration files and examples.

Step 1 — Configuring and Running Traefik

The Traefik project has an official Docker image, so you will use that to run Traefik in a Docker container.

But before you get your Traefik container up and running, you need to create a configuration file and set up an encrypted password so you can access the monitoring dashboard.

You’ll use the htpasswd utility to create this encrypted password. First, install the utility, which is included in the apache2-utils package:

sudo apt-get install apache2-utils

Then generate the password with htpasswd. Substitute secure_password with the password you’d like to use for the Traefik admin user:

htpasswd -nb admin secure_password

The output from the program will look like this:

Outputadmin:$apr1$ruca84Hq$mbjdMZBAG.KWn7vfN/SNK/

You’ll use this output in the Traefik configuration file to set up HTTP Basic Authentication for the Traefik health check and monitoring dashboard. Copy the entire output line so you can paste it later.

To configure the Traefik server, you’ll create two new configuration files called traefik.toml and traefik_dynamic.toml using the TOML format. TOML is a configuration language similar to INI files, but standardized. These files let us configure the Traefik server and various integrations, or providers, that you want to use. In this tutorial, you will use three of Traefik’s available providers: api, docker, and acme. The last of these, acme, supports TLS certificates using Let’s Encrypt.

Create and open traefik.toml using nano or your preferred text editor:

nano traefik.toml

First, you want to specify the ports that Traefik should listen on using the entryPoints section of your config file. You want two because you want to listen on port 80 and 443. Let’s call these web (port 80) and websecure (port 443).

Add the following configurations:

traefik.toml

[entryPoints]
  [entryPoints.web]
    address = ":80"
    [entryPoints.web.http.redirections.entryPoint]
      to = "websecure"
      scheme = "https"

  [entryPoints.websecure]
    address = ":443"

Note that you are also automatically redirecting traffic to be handled over TLS.

Next, configure the Traefik api, which gives you access to both the API and your dashboard interface. The heading of [api] is all that you need because the dashboard is then enabled by default, but you’ll be explicit for the time being.

Add the following code:

traefik.toml

...
[api]
  dashboard = true

To finish securing your web requests you want to use Let’s Encrypt to generate valid TLS certificates. Traefik v2 supports Let’s Encrypt out of the box and you can configure it by creating a certificates resolver of the type acme.

Let’s configure your certificates resolver now using the name lets-encrypt:

traefik.toml

...
[certificatesResolvers.lets-encrypt.acme]
  email = "your_email@your_domain"
  storage = "acme.json"
  [certificatesResolvers.lets-encrypt.acme.tlsChallenge]

This section is called acme because ACME is the name of the protocol used to communicate with Let’s Encrypt to manage certificates. The Let’s Encrypt service requires registration with a valid email address, so to have Traefik generate certificates for your hosts, set the email key to your email address. You then specify that you will store the information that you will receive from Let’s Encrypt in a JSON file called acme.json.

The acme.tlsChallenge section allows us to specify how Let’s Encrypt can verify that the certificate. You’re configuring it to serve a file as part of the challenge over port 443.

Finally, you need to configure Traefik to work with Docker.

Add the following configurations:

traefik.toml

...
[providers.docker]
  watch = true
  network = "web"

The docker provider enables Traefik to act as a proxy in front of Docker containers. You’ve configured the provider to watch for new containers on the web network, which you’ll create soon.

Our final configuration uses the file provider. With Traefik v2, static and dynamic configurations can’t be mixed and matched. To get around this, you will use traefik.toml to define your static configurations and then keep your dynamic configurations in another file, which you will call traefik_dynamic.toml. Here you are using the file provider to tell Traefik that it should read in dynamic configurations from a different file.

Add the following file provider:

traefik.toml

[providers.file]
  filename = "traefik_dynamic.toml"

Your completed traefik.toml will look like this:

traefik.toml

[entryPoints]
  [entryPoints.web]
    address = ":80"
    [entryPoints.web.http.redirections.entryPoint]
      to = "websecure"
      scheme = "https"

  [entryPoints.websecure]
    address = ":443"

[api]
  dashboard = true

[certificatesResolvers.lets-encrypt.acme]
  email = "your_email@your_domain"
  storage = "acme.json"
  [certificatesResolvers.lets-encrypt.acme.tlsChallenge]

[providers.docker]
  watch = true
  network = "web"

[providers.file]
  filename = "traefik_dynamic.toml"

Save and close the file.

Now let’s create traefik_dynamic.toml.

The dynamic configuration values that you need to keep in their own file are the middlewares and the routers. To put your dashboard behind a password you need to customize the API’s router and configure a middleware to handle HTTP basic authentication. Let’s start by setting up the middleware.

The middleware is configured on a per-protocol basis and since you’re working with HTTP you’ll specify it as a section chained off of http.middlewares. Next comes the name of your middleware so that you can reference it later, followed by the type of middleware that it is, which will be basicAuth in this case. Let’s call your middleware simpleAuth.

Create and open a new file called traefik_dynamic.toml:

nano traefik_dynamic.toml

Add the following code. This is where you’ll paste the output from the htpasswd command:

traefik_dynamic.toml

[http.middlewares.simpleAuth.basicAuth]
  users = [
    "admin:$apr1$ruca84Hq$mbjdMZBAG.KWn7vfN/SNK/"
  ]

To configure the router for the api you’ll once again be chaining off of the protocol name, but instead of using http.middlewares, you’ll use http.routers followed by the name of the router. In this case, the api provides its own named router that you can configure by using the [http.routers.api] section. You’ll configure the domain that you plan on using with your dashboard also by setting the rule key using a host match, the entrypoint to use websecure, and the middlewares to include simpleAuth.

Add the following configurations:

traefik_dynamic.toml

...
[http.routers.api]
  rule = "Host(`monitor.your_domain`)"
  entrypoints = ["websecure"]
  middlewares = ["simpleAuth"]
  service = "api@internal"
  [http.routers.api.tls]
    certResolver = "lets-encrypt"

The web entry point handles port 80, while the websecure entry point uses port 443 for TLS/SSL. You automatically redirect all of the traffic on port 80 to the websecure entry point to force secure connections for all requests.

Notice the last three lines here configure a service, enable tls, and configure certResolver to "lets-encrypt". Services are the final step to determining where a request is finally handled. The api@internal service is a built-in service that sits behind the API that you expose. Just like routers and middlewares, services can be configured in this file, but you won’t need to do that to achieve your desired result.

Your completed traefik_dynamic.toml file will look like this:

traefik_dynamic.toml

[http.middlewares.simpleAuth.basicAuth]
  users = [
    "admin:$apr1$ruca84Hq$mbjdMZBAG.KWn7vfN/SNK/"
  ]

[http.routers.api]
  rule = "Host(`monitor.your_domain`)"
  entrypoints = ["websecure"]
  middlewares = ["simpleAuth"]
  service = "api@internal"
  [http.routers.api.tls]
    certResolver = "lets-encrypt"

Save the file and exit the editor.

With these configurations in place, you will now start Traefik.

Step 2 – Running the Traefik Container

In this step you will create a Docker network for the proxy to share with containers. You will then access the Traefik dashboard. The Docker network is necessary so that you can use it with applications that are run using Docker Compose.

Create a new Docker network called web:

docker network create web

When the Traefik container starts, you will add it to this network. Then you can add additional containers to this network later for Traefik to proxy to.

Next, create an empty file that will hold your Let’s Encrypt information. You’ll share this into the container so Traefik can use it:

touch acme.json

Traefik will only be able to use this file if the root user inside of the container has unique read and write access to it. To do this, lock down the permissions on acme.json so that only the owner of the file has read and write permission.

chmod 600 acme.json

Once the file gets passed to Docker, the owner will automatically change to the root user inside the container.

Finally, create the Traefik container with this command:

docker run -d \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v $PWD/traefik.toml:/traefik.toml \
  -v $PWD/traefik_dynamic.toml:/traefik_dynamic.toml \
  -v $PWD/acme.json:/acme.json \
  -p 80:80 \
  -p 443:443 \
  --network web \
  --name traefik \
  traefik:v2.2

This command is a little long. Let’s break it down.

You use the -d flag to run the container in the background as a daemon. You then share your docker.sock file into the container so that the Traefik process can listen for changes to containers. You also share the traefik.toml and traefik_dynamic.toml configuration files into the container, as well as acme.json.

Next, you map ports :80 and :443 of your Docker host to the same ports in the Traefik container so Traefik receives all HTTP and HTTPS traffic to the server.

You set the network of the container to web, and you name the container traefik.

Finally, you use the traefik:v2.2 image for this container so that you can guarantee that you’re not running a completely different version than this tutorial is written for.

A Docker image’s ENTRYPOINT is a command that always runs when a container is created from the image. In this case, the command is the traefik binary within the container. You can pass additional arguments to that command when you launch the container, but you’ve configured all of your settings in the traefik.toml file.

With the container started, you now have a dashboard you can access to see the health of your containers. You can also use this dashboard to visualize the routers, services, and middlewares that Traefik has registered. You can try to access the monitoring dashboard by pointing your browser to https://monitor.your_domain/dashboard/ (the trailing / is required).

You will be prompted for your username and password, which are admin and the password you configured in Step 1.

Once logged in, you’ll see the Traefik interface:

You will notice that there are already some routers and services registered, but those are the ones that come with Traefik and the router configuration that you wrote for the API.

You now have your Traefik proxy running, and you’ve configured it to work with Docker and monitor other containers. In the next step you will start some containers for Traefik to proxy.

Step 3 — Registering Containers with Traefik

With the Traefik container running, you’re ready to run applications behind it. Let’s launch the following containers behind Traefik:

A blog using the official WordPress image.
A database management server using the official Adminer image.

You’ll manage both of these applications with Docker Compose using a docker-compose.yml file.

Create and open the docker-compose.yml file in your editor:

nano docker-compose.yml

Add the following lines to the file to specify the version and the networks you’ll use:

docker-compose.yml

version: "3"

networks:
  web:
    external: true
  internal:
    external: false

You use Docker Compose version 3 because it’s the newest major version of the Compose file format.

For Traefik to recognize your applications, they must be part of the same network, and since you created the network manually, you pull it in by specifying the network name of web and setting external to true. Then you define another network so that you can connect your exposed containers to a database container that you won’t expose through Traefik. You’ll call this network internal.

Next, you’ll define each of your services, one at a time. Let’s start with the blog container, which you’ll base on the official WordPress image. Add this configuration to the bottom of the file:

docker-compose.yml

...

services:
  blog:
    image: wordpress:4.9.8-apache
    environment:
      WORDPRESS_DB_PASSWORD:
    labels:
      - traefik.http.routers.blog.rule=Host(`blog.your_domain`)
      - traefik.http.routers.blog.tls=true
      - traefik.http.routers.blog.tls.certresolver=lets-encrypt
      - traefik.port=80
    networks:
      - internal
      - web
    depends_on:
      - mysql

The environment key lets you specify environment variables that will be set inside of the container. By not setting a value for WORDPRESS_DB_PASSWORD, you’re telling Docker Compose to get the value from your shell and pass it through when you create the container. You will define this environment variable in your shell before starting the containers. This way you don’t hard-code passwords into the configuration file.

The labels section is where you specify configuration values for Traefik. Docker labels don’t do anything by themselves, but Traefik reads these so it knows how to treat containers. Here’s what each of these labels does:

traefik.http.routers.adminer.rule=Host(`````blog.your_domain`````) creates a new router for your container and then specifies the routing rule used to determine if a request matches this container.
traefik.routers.custom_name.tls=true specifies that this router should use TLS.
traefik.routers.custom_name.tls.certResolver=lets-encrypt specifies that the certificates resolver that you created earlier called lets-encrypt should be used to get a certificate for this route.
traefik.port specifies the exposed port that Traefik should use to route traffic to this container.

With this configuration, all traffic sent to your Docker host on port 80 or 443 with the domain of blog.your_domain will be routed to the blog container.

You assign this container to two different networks so that Traefik can find it via the web network and it can communicate with the database container through the internal network.

Lastly, the depends_on key tells Docker Compose that this container needs to start after its dependencies are running. Since WordPress needs a database to run, you must run your mysql container before starting your blog container.

Next, configure the MySQL service:

docker-compose.yml

services:
...
  mysql:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD:
    networks:
      - internal
    labels:
      - traefik.enable=false

You’re using the official MySQL 5.7 image for this container. You’ll notice that you’re once again using an environment item without a value. The MYSQL_ROOT_PASSWORD and WORDPRESS_DB_PASSWORD variables will need to be set to the same value to make sure that your WordPress container can communicate with the MySQL. You don’t want to expose the mysql container to Traefik or the outside world, so you’re only assigning this container to the internal network. Since Traefik has access to the Docker socket, the process will still expose a router for the mysql container by default, so you’ll add the label traefik.enable=false to specify that Traefik should not expose this container.

Finally, define the Adminer container:

docker-compose.yml

services:
...
  adminer:
    image: adminer:4.6.3-standalone
    labels:
      - traefik.http.routers.adminer.rule=Host(`db-admin.your_domain`)
      - traefik.http.routers.adminer.tls=true
      - traefik.http.routers.adminer.tls.certresolver=lets-encrypt
      - traefik.port=8080
    networks:
      - internal
      - web
    depends_on:
      - mysql

This container is based on the official Adminer image. The network and depends_on configuration for this container exactly match what you’re using for the blog container.

The line traefik.http.routers.adminer.rule=Host(`````db-admin.your_domain`````) tells Traefik to examine the host requested. If it matches the pattern of db-admin.your_domain, Traefik will route the traffic to the adminer container over port 8080.

Your completed docker-compose.yml file will look like this:

docker-compose.yml

version: "3"

networks:
  web:
    external: true
  internal:
    external: false

services:
  blog:
    image: wordpress:4.9.8-apache
    environment:
      WORDPRESS_DB_PASSWORD:
    labels:
      - traefik.http.routers.blog.rule=Host(`blog.your_domain`)
      - traefik.http.routers.blog.tls=true
      - traefik.http.routers.blog.tls.certresolver=lets-encrypt
      - traefik.port=80
    networks:
      - internal
      - web
    depends_on:
      - mysql

  mysql:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD:
    networks:
      - internal
    labels:
      - traefik.enable=false

  adminer:
    image: adminer:4.6.3-standalone
    labels:
    labels:
      - traefik.http.routers.adminer.rule=Host(`db-admin.your_domain`)
      - traefik.http.routers.adminer.tls=true
      - traefik.http.routers.adminer.tls.certresolver=lets-encrypt
      - traefik.port=8080
    networks:
      - internal
      - web
    depends_on:
      - mysql

Save the file and exit the text editor.

Next, set values in your shell for the WORDPRESS_DB_PASSWORD and MYSQL_ROOT_PASSWORD variables:

export WORDPRESS_DB_PASSWORD=secure_database_password
export MYSQL_ROOT_PASSWORD=secure_database_password

Substitute secure_database_password with your desired database password. Remember to use the same password for both WORDPRESS_DB_PASSWORD and MYSQL_ROOT_PASSWORD.

With these variables set, run the containers using docker-compose:

docker-compose up -d

Now watch the Traefik admin dashboard while it populates.

If you explore the Routers section you will find routers for adminer and blog configured with TLS:

Navigate to blog.your_domain, substituting your_domain with your domain. You’ll be redirected to a TLS connection and you can now complete the WordPress setup:

Now access Adminer by visiting db-admin.your_domain in your browser, again substituting your_domain with your domain. The mysql container isn’t exposed to the outside world, but the adminer container has access to it through the internal Docker network that they share using the mysql container name as a hostname.

On the Adminer login screen, enter root for Username, enter mysql for Server, and enter the value you set for MYSQL_ROOT_PASSWORD for the Password. Leave Database empty. Now press Login.

Once logged in, you’ll see the Adminer user interface.

Both sites are now working, and you can use the dashboard at monitor.your_domain to keep an eye on your applications.

Conclusion

In this tutorial, you configured Traefik v2 to proxy requests to other applications in Docker containers.

Traefik’s declarative configuration at the application container level makes it easy to configure more services, and there’s no need to restart the traefik container when you add new applications to proxy traffic to since Traefik notices the changes immediately through the Docker socket file it’s monitoring.

To learn more about what you can do with Traefik v2, head over to the official Traefik documentation.

服务集群

k8s 太重了,虽然也有 k3s 之类的轻量级 k8s 解决方案，不过我还是选择了原生的 docker swarm。VPS 安装好 Docker 之后，不需要额外安装软件，就可以马上建立集群。

# 集群初始化，节点成为 manager 节点
docker swarm init --advertise-addr=x.x.x.x

# 集群丢失 Leader 时，强制重建集群
docker swarm init --advertise-addr=x.x.x.x --force-new-cluster

# 获取作为 worker 节点加入集群的命令
docker swarm join-token worker

# 获取作为 manager 节点加入集群的命令
docker swarm join-token manager

# 加入集群
docker swarm join --token xxx x.x.x.x:xxx --advertise-addr=x.x.x.x

参考：

系列教程

全部文章RSS订阅

Docker系列

Docker 分类 RSS 订阅

如何通过IPV6访问Qnap NAS中Docker的服务

2021-10-12T05:42:55.000Z

目前找到了两个解决方案

socat 端口转发

docker-ipv6nat

很早就和QNAP官方反馈请求支持IPV6，但一直没反应

socat 端口转发

环境

系统：QTS 4.3.6
网络：IPV4 & IPV6
Docker: 由Container Station提供

问题

通过ipv6地址可以打开NAS的管理页面，但是无法访问Docker对应端口的服务。

排查

QTS中Docker使用的虚拟交换机网络没有启动IPV6，且无法在虚拟交换机设置中手动启动。这样一来，Docker只监听了tcp4的端口，对于主机上tcp6的端口的访问无法映射到docker容器上。

解决方案

在主机上开一个tcp6的端口，将其转发到主机上与docker关联的tcp4端口。即：
docker(tcp4)–>host(tcp4)–>host(tcp6)

在qts上安装包管理器：Entware. https://github.com/Entware/Entware/wiki/Install-on-QNAP-NAS
执行opkg update,更新
安装端口转发工具，这里使用socat：opkg install socat

设置转发host(tcp6)–>host(tcp4)

socat TCP6-LISTEN:6880,reuseaddr,fork TCP4:127.0.0.1:7880 &

大功告成

docker-ipv6nat

IPv4 & IPv6 可以平等使用（端口可以在主机系统上共享）

容器并不完全在线，因为 Docker 容器并不总是以安全着称

步骤1：

为 ip6tables NAT 安装内核模块。不幸的是，QNAP 没有自带这些模块，所以你必须自己构建它们。谢天谢地，有人已经这样做并在 github 上发布了它。qnap-ip6tables_nat-module。在 Release 下，您已经可以在此处下载当前构建的模块。我将它们放在 Docker 容器的应用程序目录中：

/share/CACHEDEV1_DATA/Container/container-station-data/application/ipv6nat/kernel_mods/

然后，您必须确保在启动时加载这些模块。为此，必须在您的 autorun.sh 中输入以下行。

# ipv6-tables
# some required modules are already built into QTS, so you can load them with 'modprobe'
/sbin/modprobe ip6_tables
/sbin/modprobe nf_nat
/sbin/modprobe xt_MASQUERADE

# then load the new module
insmod /share/CACHEDEV1_DATA/Container/container-station-data/application/ipv6nat/kernel_mods/ip6table_nat.ko

您可以在 QNAP Wiki 中了解如何在您的 QNAP 模型上编辑此文件：Running_Your_Own_Application_at_Startup

添加模块后，您需要重新启动 NAS。

第2步：

为了设置 docker-ipv6nat 容器，我准备了一个 docker-compose 文件。您可以通过 Create 简单地将其插入 ContainerStation：

version: '3'

services:
  ipv6nat:
    container_name: ipv6nat
    restart: always
    image: robbertkl/ipv6nat
    privileged: true
    network_mode: host
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /lib/modules:/lib/modules:ro

容器应该在终端上没有任何输出的情况下启动。不起眼……现在呢？创建也应该可以通过 IPv& 访问的容器时是否需要一些手动工作。至少我还没有通过 QNAP 界面找到更简单的方法。

如果需要，您必须为每个容器创建至少一个支持 IPv6 的网络。

为此，请通过 SSH 登录 QNAP 并创建一个新的 Docker 网络：

docker network create --ipv6 --subnet fd00:dead:beef::/48 ipv6net-1

当然，您也可以使用任何其他 ULA 范围 (fc00::/7)。

现在只需使用 ipv6net-1 作为容器的外部网络。这是一个小例子：

version: "3"
  services:
    alp1:
      image: yeasy/simple-web:latest
      ports:
      - 80:80
      networks:
      - ipv6net-1

networks:
  ipv6net-1:
    external: true

现在您的容器端口来自 IPv4：

nmap <ipv4 ip> -p 80

PORT   STATE  SERVICE
80/tcp open http

也可以通过 IPv6 访问：

nmap <ipv6 ip> -6 -p 80

PORT   STATE  SERVICE
80/tcp open http

享受通过 IPv4 和 IPv6 托管您的服务的乐趣！

实操

遇到问题： robbertkl/ipv6nat 启动日志报错

开启防火墙使用到了geoip会遇到如下错误

iptables   exit status 1: Can't find library for match `geoip'

可能的解决方案

编译支持 geoip

Install geoip for iptables in Debian 10

Xtables-Addons On Centos 6 & Iptables GeoIP Filtering

不使用 geoip

把防火墙中的规则设计到geoip 的都修改为任何地区，防火墙规则设计的好，针对一个地区开发某些端口和针对所有地区开发端口基本一样的风险。

使用第二种方案，实际测试使用发现丢包率还不低！

# 在开启了ipv6的docker中运行如下命令
# ping6  2409:804c:2000:2::1
PING 2409:804c:2000:2::1 (2409:804c:2000:2::1): 56 data bytes
ping: getnameinfo: Temporary failure in name resolution
64 bytes from unknown: icmp_seq=1 ttl=57 time=4.073 ms

...

^Cping: getnameinfo: Temporary failure in name resolution
64 bytes from unknown: icmp_seq=24 ttl=57 time=3.654 ms
--- 2409:804c:2000:2::1 ping statistics ---
25 packets transmitted, 22 packets received, 12% packet loss
round-trip min/avg/max/stddev = 3.606/4.100/5.562/0.608 ms

Temporary failure in name resolution 似乎是DNS配置问题

测试IPV6

Windows

以下Windows版本的ping命令支持ping IPv6地址：

Windows XP with SP1 及以上
Windows Vista 及以上
Windows Server 2003 及以上

ping ipv6主机名

ping -6 ipv6.google.com
ping -6 ipv6.test-ipv6.com  
ping -6 ipv6.baidu.com

**/!\注意：**当ping ipv6主机名时，必须加上参数-6；直接ping IPv6地址时可以省略。

ping ipv6地址

ping IPv6Address[%ZoneID]

例如：

ping 2001:4860:0:2001::68

如果要ping link-local地址，则需要指定网络接口索引，如：

ping fe80::260:97ff:fe02:6ea5%4

其中**%4**表示“用索引为4的网络接口”ping目标计算机。

Linux

在Linux发行版中，使用ping6命令ping IPv6主机或者地址。

ping ipv6主机名

ping6 ipv6.google.com

ping ipv6地址

ping6 IPv6Address[%InterfaceName]

如果要ping link-local地址，则需要指定网络接口名称，如：

ping fe80::260:97ff:fe02:6ea5%eth0

其中**%eth0**表示“用网络接口eth0 ping目标计算机”。

ping dns

ping6  2409:804c:2000:2::1

ssh

ssh root@fe80::c09a:4363:5763:32%enpxxx(网卡名称)

chrome IPV6

Chrome 地址栏输入

about:net-internals/#dns

访问 https://www.test-ipv6.com/

nginx支持ipv6

nginx 1.14 开始就默认支持ipv6了，不再需要添加编译参数 --with-ipv6，可以直接配置监听 ipv6

检查nginx是否监听了ipv6

netstat -tuln

同时监听IPV4和IPV6

server  {
....
listen  [::]:80;
listen  [::]:443;
...
}

只监听IPV6

server  {
....
listen  [::]:80  default  ipv6only=on;
listen  [::]:443  default  ipv6only=on;
...
}

监听指定IPV6地址

{
....
listen  [3608:f0f0:3002:31::1]:80;
listen  [3608:f0f0:3002:31::1]:443;
...
}

重启nginx

nginx -s reload

安全设置

暴露Nas到公网是会有很大安全隐患的，请注意你已经做好了安全防范！

开启动态安全码

开启防火墙，最好最高安全级别，自己控制端口开启

开启IP访问保护失败登录尝试阻止时间调整

暴露出去的服务全部采用高强密码，最好所有服务全部采用高强度密码

尽量使用Docker，而不是套件版软件服务

重要数据定期离线备份

IPv6: 为什么Link-local地址后面要有百分号(%)？

由于所有的link-local地址都有相同的前缀FE80::/64，并且每个网络接口都必须分配一个link-local地址，因而导致当发送数据包到一个link-local地址时，如果路由器使用普通的路由方法就无法决定选用哪个网络接口。因此，引入了一种被叫做zone index的标识符，它提供额外的路由信息，这个标识符通常指网络接口，并且通过一个百分号(%)被附加在IPv6地址后面。但是准确的表示方法还取决于操作系统：

Windows: 使用网络接口索引表示

如：

fe80::3%1
fe80::260:97ff:fe02:6ea5%4

要查看网络接口索引，请执行该命令：

netsh interface ipv6 show address

Linux: 使用网络接口名称表示

如：

fe80::3%eth0
fe80::260:97ff:fe02:6ea5%tun0

Linux只需要ifconnfig命令就可列出所有网络接口名称。

参考

系列教程

全部文章RSS订阅

Docker系列

Docker 分类 RSS 订阅

附赠

alpine linux 使用国内镜像源进行加速

Alpine 的源文件为：

/etc/apk/repositories

这里面的默认配置例如：

http://dl-cdn.alpinelinux.org/alpine/v3.11/main
http://dl-cdn.alpinelinux.org/alpine/v3.11/community

可以使用以下命令来进行源的切换（阿里云源）：

sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories

中国科技大学的源：

sed -i 's/dl-cdn.alpinelinux.org/mirrors.ustc.edu.cn/g' /etc/apk/repositories

清华源：

sed -i 's/dl-cdn.alpinelinux.org/mirrors.tuna.tsinghua.edu.cn/g' /etc/apk/repositories

目前 Docker 官方已开始推荐使用 Alpine 替代之前的 Ubuntu 做为基础镜像环境。

Alpine 使用 apk 来进行包管理。

可以在 Docker file 中添加以下语句，来加速 apk 的包管理。

...
RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.tuna.tsinghua.edu.cn/g' /etc/apk/repositories
RUN apk add --no-cache gcc musl-dev linux-headers
...

注： sed 可依照脚本的指令来处理、编辑文本文件。 Sed 主要用来自动编辑一个或多个文件、简化对文件的反复操作、编写转换程序等。

为知笔记私有化Docker部署

2021-09-09T01:25:00.000Z

已经不建议使用！

格式私有，不支持导出数据到其它类型笔记软件。数据进入后，基本只能用为知笔记编辑了，导出图片和PDF? what?

收费吃相难看，VIP到期后，功能限制严重！

不推荐任何不支持导入导出数据的笔记软件。推荐使用开放格式的 Joplin 软件

登陆NAS，打开套件中心，搜索docker，并安装。

搜索wiznote，找到wiznote/wizserver，双击下载

在NAS中创建共享目录，用于存放笔记数据

启动File Station
在docker目录下创建文件夹：

wiz
在wiz文件夹下创建文件夹：data
双击创建容器，启用资源限制，设置为内存限制4096MB，官方介绍说需要4G内存
高级设置，启动自动重新启动
卷设置，使用刚才我们创建的data目录进行配置，装载路径/wiz/storage，docker/wiz/config装载路径/wiz/app/wizserver/config
网络设置不动，端口设置添加映射：8888映射80端口（8888可以随便设置，跟访问地址有关）

设置环境变量
```
SEARCH=true TZ=Asia/Shanghai
```
直接应用，启动docker，然后就静静的等待吧，可以看看镜像的日志，看到这些基本上就差不多启动好了（最新的镜像在NAS上首次启动非常慢，本人等了一个多小时才完全启动完毕，在本地安装速度非常快）
通过 http://NAS的IP:8888，进行访问，就可以看到已经启动完成

默认管理员账号：admin@wiz.cn，密码：123456

管理后台登陆地址：http://IP地址:端口/wapp/pages/admin

NAS开启SSH

首先在NAS上启动SSH

登陆NAS，打开控制面板-终端机和SNMP，在启动SSH功能前打上勾

打开命令行，输入

ssh NAS管理员账号@NAS的IP地址 ssh端口号默认是22

看到提示符，输入账号的密码，输入时不可见，输入完成按回车，看到命令行提示符变了，登陆成功。

进入容器

在命令行中输入

sudo docker ps

可能提示输入密码，就输入NAS管理员的密码即可，显示列表，查看到如下列表，找到其中运行了为知笔记的一行

复制为知笔记的CONTAINER ID，然后再输入如下命令并回车：

sudo docker exec -it 粘贴刚复制好的ID号 /bin/bash

至此进入到容器中

修改配置文件

输入如下命令打开配置文件进行编辑：

vi /wiz/app/wizserver/config/default.json

vi命令的具体使用方法请自行百度，保存好后退出，重启容器生效。

进入docker，修改文件/wiz/wizserver/app/config/default.json

"as": {
     "admin": ["admin@wiz.cn"],
     "share": {
       "admin": ["admin@wiz.cn"],
       "enableHttps": false,
       "enableSubDomain": false,
       "appShareUrl": "127.0.0.1:5001"
     },

其中127.0.0.1:5001修改为自己的服务器访问地址，可以给docker做个端口映射（因为群晖NAS占用了5001端口），譬如映射8889端口到容器的5001端口，则设置为xxx.xxx.xxx.xxx:8889，分享后的链接即为该链接。

在NAS上可以用反向代理来解决二级域名的问题。

分享功能需要用户绑定手机，并完成认证，在docker中登陆数据库，并修改数据

mysql -u root -p

输入密码，密码在docker中/wiz/wizserver/app/config/default.json中查看

"mysql": {
  "as": {
   "host": "127.0.0.1",
   "user": "root",
   "password": "******************",
   "database": "wizasent",
   "connectionLimit": 50,
   "connectTimeout": 60000,
   "aquireTimeout": 60000,
   "waitForConnections": true
  },

其中password就是密码，进入mysql控制台后，执行以下命令：

use wizasent;
update wiz_user set MOBILE='你的手机号', MOBILE_VERIFY='1' where ID='1';

web端登陆为知笔记，并修改默认账号后，修改后的账号无法登陆管理后台，需要做以下配置，修改文件/wiz/wizserver/app/config/default.json，找到以下代码：

"as": {
  "admin": ["admin@wiz.cn"],
  "share": {
    "admin": ["admin@wiz.cn"],
    "enableHttps": false,
    "enableSubDomain": false,
    "appShareUrl": "127.0.0.1:5001"
  },

其中admin@wiz.cn修改为修改后的账号。

登陆NAS，打开控制面板-应用程序门户-反向代理

点击新增，然后输入如下：

实际测试来源协议选择https时只有网页端可以登陆，客户端无法登陆，暂时还是选择http为好，也可以网页端通过https登陆，客户端通过http登陆，配置两个不同的端口（记得要在路由上配置端口映射）。

修改default.json

{
  "debug": true,
  "enableHttps": true,
  "storage": {
     "__comments": "oss|local|s3|cos",
     "use": "local",
     "oss": {
       "bucket": "data_root",
       "region": "test",
       "accessKeyId": "test",
       "accessKeySecret": "test",
       "internal": false
     },

其中enableHttps配置成true

重启服务

cd /wiz/app/wizserver
pm2 restart all

删除/wiz/storage/index/.search文件和/wiz/storage/index/nodes目录

重启容器

链接数据库，执行下列SQL

update wizksent.wiz_kb_stat set index_new_status=4

进入容器，执行

cd /wiz/app/wizserver
pm2 start app.js --name="index2"  -f -- -c 1 -i 1 -t 2 -s index
pm2 start app.js --name="index2"  -f --  -s copy

查看日志

pm2 logs index2

下载官方插件，并安装到Chrome中

http://www.wiz.cn/downloads-webclipperchrome.html

在浏览器中输入chrome://extensions/打开插件列表，开启开发者模式

看ID号，在浏览器中输入chrome://inspect/#extensions在打开的列表中找到WizClipper，点击inspect，开启调试窗口。

选择Sources标签，并打开文件Scripts\wiz\WizConstant.js

在代码中查看note.wiz.cn和api.wiz.cn的网址全部替换成自己私有云的地址，实测，登陆没问题，保存失败。

管理功能

增加重建索引功能，以备不时之需
增加备份与恢复功能
增加markdown语法扩展：

flow（流程图）、sequence（时序图）、mermaid（流程图、时序图、甘特图）、LaTeX（公式）
增加手动配置分享链接
支持社交绑定的配置
支持对象存储或webdav存储

Web&Mac客户端

增加自定义模板
增加偏好设置，自定义快捷键（主要是编辑和预览切换的快捷键非常不适应）
增加同步预览模式，可以参考下Typora，Bear都不错
增加https访问方式
支持导出jpg、png、docx格式

浏览器插件

增加支持私有云登陆

【部署环境】
群晖DS1517+（DSM6.2.2）
容器分配内存4G，CPU*2核

【出现的问题】

网页版上提示，自动保存失败，网络错误，请尽快保存（最后发现是时区不通道导致的，第8点解决了此问题）
所有社交平台账号无法绑定
mywiz邮箱不可修改
绑定手机无法收到验证码，即无法绑定手机（通过修改数据库搞定）
存储设置功能多余（因为已经本地化部署了），改成数据备份/恢复就好了
支付信息是支付到为知去的，这个功能容易产生误解（如果多人使用的话）
docker容器的时区与宿主机时区不同，添加环境变量解决，TZ=Asia/Shanghai

数据导出

方法很困难。

ExportToMd

最新版Wiznote测试这个插件已经不可用了。

WizNotePlus

第三方客户端导出，已在 v2.11 中初步实现，见如下issue链接。

https://github.com/altairwei/WizNotePlus/issues/182

Memocast客户端

随后搜索到Memocast，是重写为知笔记的客户端。

使用OpenAPI

为知笔记提供了OpenAPI来查看和编辑笔记，Memocast也是类似方式，服务说明及登录和笔记接口介绍了如何登录获取Token，如何查询文件夹文档，下载html，下载资源(图片)等接口。

对于为知笔记来说，所有的笔记保存为html，所以下载后需要做转换。

通过Postman的接口测试发现完全可行，那么就可以编程导出了。具体的代码。html转md的库使用html-to-markdown，案例代码在这。

如何使用？按照下面提示输入账户和密码，然后设置导出的文件夹即可。

go install github.com/GalaIO/wiz_export@latest
wiz_export --output './' --userId 'xx' --password 'xx' --folders '/日记/,/工作/'

借助Pandoc转换到HTML再转换到Markdown

For .html files within a directory

for f in *.html ; do pandoc ${f} -f html -t markdown -s -o ${f}.md ; done

For recursive directory conversion with subfolders

find . -name "*.ht*" | while read i; do pandoc -f html -t markdown "$i" -o "${i%.*}.md"; done

wiz2joplin

这个需要Mac环境，看提交记录时间，可行性很高。

参考：

系列教程

全部文章RSS订阅

Docker系列

Docker 分类 RSS 订阅

笔记系列

Note分类RSS订阅

Gitbook使用系列

Gitbook分类RSS订阅

Gitlab 使用系列

Gitlab RSS 分类订阅

Hexo系列

HexoRSS分类订阅

[十万字图文教程]基于Hexo的matery主题搭建博客并深度优化完全一站式教程

markdown 各种其它语法插件，latex公式支持，mermaid图表，plant uml图表，URL卡片，bilibili卡片，github卡片，豆瓣卡片，插入音乐和视频，插入脑图，插入PDF，嵌入iframe

docker使用简明教程

2021-08-01T12:25:00.000Z

关于docker安装，查看，镜像管理，以及一个实用Dockerfile， LAMP，PHP，LTMJ。

关于本blog，图床一般使用github，已经配置了CDN，如果图片还是未显示请自行代理解决

Docker安装

在Ubuntu系统下安装：

apt-get install docker

在Fedora/CentOS系统下安装：

yum install docker
dnf install docker # Fedora 25+

在SUSE系统下安装：

zypper install docker

Docker容器

首先启动Docker

# 启动Docker
systemctl start docker
# 设置开机自启动，可选
systemctl enable docker

启动Docker测试容器

docker run "hello-world"

在启动容器时，如果使用的镜像在本地不存在，会尝试从网络上获取。
在一般情况下，启动Web服务的容器，使用以下命令：

# -d：daemon，使容器在后台运行
# -p：port，指定容器的端口，这里是将容器的80端口映射到主机的8001端口
docker run -d -p 8001:80 "image_name"

查看容器运行情况

docker ps

Docker会为容器分配一个Container ID和一个Container Name，Name可以在运行时通过-name自行指定，这两个可以用来标识容器。
需要停止容器时，使用以下命令：

docker stop "container_name"
# 或使用ID查找
docker stop "container_id"
# 重启
docker restart "container_id"

Docker镜像

Dokerfile编译镜像

Docker容器是运行的Docker镜像实例，一般情况下，我们需要制作自己的Docker镜像。
Docker镜像的制作依赖于Dockerfile，我们稍后在讨论Dockerfile的编写，这里假定我们有一个编写好的Dockerfile。
下面的命令将在当前路径查找Dockerfile并构建一个名为“image_name”的镜像。

docker build -t "image_name" ./

查看本地所有镜像

在构建过程中需要在网络上下载来源镜像，可能需要一段时间。
如果Dockerfile中的命令都正确结束（Exit code 0），那么Docker镜像的构建也将顺利完成，我们可以通过下面的命令查看我们的所有镜像：

docker images

导出备份已有镜像文件

我们还可以导出我们制作好的Docker镜像，下面的命令将image_name镜像导出为image_name.tar

docker save "image_name" > image_name.tar

导入已有镜像备份

在另一台机器上，我们不需要网络就可以导入并使用该镜像：

docker load < image_name.tar

Dockerfile

Dockerfile本质上是一组命令集合，用于自动化构建镜像，下面以几个实例来说明Dockerfile的编写方法：

实例一：LAMP（Linux+Apache+MySQL+PHP）环境配置

# 来源镜像，一般可以使用标准的系统或者带有各种环境的系统
# 显然这里使用的是标准的Ubuntu 14.04系统
FROM ubuntu:14.04
# 镜像作者
MAINTAINER wrlu
# 刷新日期
ENV REFRESHED_AT 2018-08-05
# 设定字符集
ENV LANG C.UTF-8
# RUN命令用于执行系统命令
# 因为需要自动化安装，所以最好通过-y命令跳过确认
# 更新APT软件源
RUN apt-get update -y
# 安装MySQL
RUN apt-get -y install mysql-server
# 安装Apache
RUN apt-get -y install apache2
# 安装PHP5
RUN apt-get -y install php5 libapache2-mod-php5
RUN apt-get install -yqq php5-mysql php5-curl php5-gd php5-intl php-pear php5-imagick php5-imap php5-mcrypt php5-memcache php5-ming php5-ps php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl
# 删除Apache2列出目录配置
RUN sed -i 's/Options Indexes FollowSymLinks/Options None/' /etc/apache2/apache2.conf
# COPY命令可以复制文件，但是似乎不能递归复制文件
COPY IncludeAirline/* /var/www/html/
COPY IncludeAirline/airlines/* /var/www/html/airlines/
# 删除默认的主页
RUN rm /var/www/html/index.html
# 复制启动脚本
COPY start.sh /root/start.sh
RUN chmod +x /root/start.sh
# 设置启动目录以及启动脚本
ENTRYPOINT cd /root; ./start.sh
# 设置需要暴露的端口
EXPOSE 80,3306

本例中还有一个启动脚本start.sh，用于导入数据库，编写如下：

#!/bin/bash
# 启动后延时
sleep 1
# 启动Apache服务器
/etc/init.d/apache2 start
# 启动MySQL数据库
find /var/lib/mysql -type f -exec touch {} ; && service mysql start
# 定义SQL文件路径
sqlfile=/var/www/html/includeAirline.sql
if [ -f $flagfile ]; then
	# 修改MySQL的密码
    mysqladmin -u root password "root"
    # 登录MySQL并导入SQL文件执行
    mysql -uroot -proot < $sqlfile
    # 删除SQL文件
    rm -f $sqlfile
fi
# 此处注意，如果命令执行完后脚本退出
# 则Docker容器也会因为没有前台应用运行而中止
# 所以这里使用一个前台命令来保活Docker容器
tail -f /var/log/apache2/error.log

实例二：PHP环境配置：

# 来源镜像，自带Apache+PHP环境
FROM php:7.0-apache
MAINTAINER tl
ENV REFRESHED_AT 2018‐08‐03
ENV LANG C.UTF‐8
# ADD命令在COPY命令的基础上，具有自动解包tar的功能
ADD web_tired.tar /var/www/html/
EXPOSE 80

实例三：LTMJ（Linux+Tomcat+MySQL+JSP）环境配置

FROM ubuntu:16.04
MAINTAINER wrlu
ENV REFRESHED_AT 2018-08-05
ENV LANG C.UTF-8
RUN apt-get update -y
RUN apt-get -y install mysql-server
# 安装wget，因为Docker提供的镜像是最小镜像，所以用到的其他工具需要自行安装
RUN apt-get -y install wget
# 安装Java 8
RUN apt-get -y install openjdk-8-jre
# 下载Tomcat 8服务器
RUN wget http://mirrors.hust.edu.cn/apache/tomcat/tomcat-8/v8.5.32/bin/apache-tomcat-8.5.32.tar.gz
# 解压tar.gz
RUN tar -xzf apache-tomcat-8.5.32.tar.gz -C /root
RUN mv /root/apache-tomcat-8.5.32 /root/tomcat
# 删除默认页面
RUN rm -rf /root/tomcat/webapps/*
# 拷贝war文件
COPY CAAC-SQL-Injection.war /root/tomcat/webapps/
COPY wafwtf.sql /root/
COPY start.sh /root/start.sh
RUN chmod +x /root/start.sh
ENTRYPOINT cd /root; ./start.sh
# Tomcat使用8080端口，不同于Apache
EXPOSE 8080

启动脚本如下：

#!/bin/bash
sleep 1
find /var/lib/mysql -type f -exec touch {} ; && service mysql start
chmod +x /root/tomcat/bin/startup.sh
# 启动Tomcat服务器
/root/tomcat/bin/startup.sh
sqlfile=/root/wafwtf.sql
if [ -f $flagfile ]; then
    mysqladmin -u root password "root"
    mysql -uroot -proot < $sqlfile
    rm -f $sqlfile
fi
# 容器保活
tail -f /root/tomcat/conf/server.xml

系列教程

全部文章RSS订阅

Docker系列

Docker 分类 RSS 订阅