前言

Docker容器技術相信大家或多或少都聽說過吧，現在可謂是紅極一時，它的優勢主要有以下幾點：

不需要再啟動內核，所以應用擴縮容時可以秒速啟動，
資源利用率高，直接使用宿主機內核調度資源，性能損失小，
一鍵啟動所有依賴服務，鏡像一次編譯，隨處使用，測驗和生產環境高度一致，
應用的運行環境和宿主機環境無關，完全由鏡像控制，一臺物理機上部署多種環境的鏡像測驗，
實作了持續的交付和部署，

但是我們在學習一樣東西時不能僅僅停留于表面的命令，更重要的是深入進去理解，Docker的核心技術主要基于Linux的namespace，cgroup和Union Fs檔案系統，以及Docker自身的網路，

今天的這篇文章主要是介紹Docker的核心技術namespace，cgroup，Union FS（docker的網路后續會出），總結一下這段時間的學習，

Namespace

Linux Namespace是Linux Kernel提供的資源隔離方案：

系統可以為行程分配不同的namespace，每個行程都會有自己的namespace
并保證不同的namespace資源獨立分配，行程彼此隔離，即不同的namespace下的行程互不干擾

為了隔離不同的資源，Linux Kernel提供了六種不同型別的namespace:

注：UTS全稱：UNIX Time Sharing UNIX分時作業系統

Linux對namespace的實作

既然namespace和行程相關，那么我們可以在task_struct結構體中看到包含和namespace相關聯的變數，

## \kernel\msm-4.4\include\linux\sched.h
struct task_struct {  // 當然task_struct中還包含關于行程的其他資訊  比如行程狀態等
... 
/* namespaces */
	struct nsproxy *nsproxy;
...
}

其中nsproxy結構體包含了關于各種命名空間實作

# \kernel\msm-4.4\include\linux\nsproxy.h
/*
 * A structure to contain pointers to all per-process
 * namespaces - fs (mount), uts, network, sysvipc, etc.
 *
 * The pid namespace is an exception -- it's accessed using
 * task_active_pid_ns.  The pid namespace here is the
 * namespace that children will use.
 *
 * 'count' is the number of tasks holding a reference.
 * The count for each namespace, then, will be the number
 * of nsproxies pointing to it, not the number of tasks.
 *
 * The nsproxy is shared by tasks which share all namespaces.
 * As soon as a single namespace is cloned or unshared, the
 * nsproxy is copied.
 */
struct nsproxy {
	atomic_t count;
	struct uts_namespace *uts_ns;
	struct ipc_namespace *ipc_ns;
	struct mnt_namespace *mnt_ns;
	struct pid_namespace *pid_ns_for_children;
	struct net 	     *net_ns;
};
extern struct nsproxy init_nsproxy;  // init_nsproxy是對除了.mnt_ns之外的namespace進行系統初始化

Linux對namespace的操作方法

主要是三個命令：clone，setns，unshare

clone

// linux中輕量級的行程是由clone()函式創建的
/*
fn	當一個新行程通過clone創建時，它通過呼叫fn所指向的函式開始執行
child_stack	為子行程分配的堆疊空間
flags	在創建新行程的系統呼叫時可以通過flags引數指定需要新建的namespace型別
		CLONE_NEWIPC		對應IPC命名空間
		CLONE_NEWNET		對應NET命名空間
		CLONE_NEWNS 		對應Mount命名空間
		CLONE_NEWPID 		對應PID命名空間
		CLONE_NEWUSER 		對應User命名空間
		CLONE_NEWUTS		對應UTS命名空間
		
		CLONE_NEWCGROUP		對應cgroup命名空間，使行程有一個獨立的cgroup控制組，始于Linux 4.6
*/
int clone(int (*fn)(void *), void *child_stack, int flags, void *arg)

clone創建一個新的行程加入到新的命名空間中，不會影響當前行程，而且clone創建的子行程可以共享父行程的虛擬空間地址，檔案描述符，信號處理表等，

注：

（1） clone和fork的呼叫方式很不相同，clone呼叫需要傳入一個函式int (*fn)(void *)，該函式在子行程中執行，

（2）clone和fork最大不同在于clone不再復制父行程的堆疊空間，而是自己創建一個新的，（void *child_stack,）也就是第二個引數，需要分配堆疊指標的空間大小，所以它不再是繼承或者復制，而是全新的創造，

setns

/*
fd	指向/proc/[pid]/ns命名空間的檔案描述符
nstype 對應命名空間的flags  如果為0表示允許進入任何一個命名空間
*/
int setns(int fd, int nstype)
// 舉例
int fd = pidfd_open(1234, 0);
setns(fd, CLONE_NEWUSER | CLONE_NEWNET | CLONE_NEWUTS);

呼叫某個執行緒（單執行緒即行程）加入指定的namespace

unshare

int unshare(int flags)

可以將呼叫行程移動到新的namespace，是當前行程退出當前的命名空間，進入新的命名空間，注意與clone()的區別，

關于namespace常用的操作

查看當前系統的 namespace： lsns –t <type>

[root@aliyun ns]# lsns -t mnt
        NS TYPE NPROCS   PID USER   COMMAND
4026531840 mnt      88     1 root   /usr/lib/systemd/systemd --system --deserialize 17
4026531856 mnt       1    13 root   kdevtmpfs
4026532151 mnt       1   541 chrony /usr/sbin/chronyd

查看某行程的 namespace： ll /proc/<pid>/ns/

# 先查出行程id
[root@aliyun proc]# docker inspect 97649934abf3 | grep -i pid
            "Pid": 26103,
            "PidMode": "",
            "PidsLimit": null,
# 查看某行程的namespace
[root@aliyun proc]# ll /proc/26103/ns
total 0
lrwxrwxrwx 1 root root 0 Aug 31 15:19 ipc -> ipc:[4026532163]
lrwxrwxrwx 1 root root 0 Aug 31 15:19 mnt -> mnt:[4026532161]
lrwxrwxrwx 1 root root 0 Aug 31 15:17 net -> net:[4026532166]
lrwxrwxrwx 1 root root 0 Aug 31 15:19 pid -> pid:[4026532164]
lrwxrwxrwx 1 root root 0 Aug 31 15:19 user -> user:[4026531837]
lrwxrwxrwx 1 root root 0 Aug 31 15:19 uts -> uts:[4026532162]

進入某 namespace 運行命令： nsenter -t <pid> -n ip addr 其中-t引數表示目標行程id，-n引數表示net命名空間，nsenter相當于在setns的示例程式上做了一層封裝，是我們無需指定命名空間的檔案描述符，而是指定行程號即可，

nsenter可以在指定行程的命令下運行指定程式的命令，因為大多數的容器為了輕量級是不包含較為基礎的命令的，這就為除錯容器網路帶來了很大的困擾，只能通過docker inspect 容器id獲取容器的ip，以及無法測驗和其他網路的連通性（其實可以通過docker網路的管理），nsenter命令可以進入該容器的網路命名空間，使用宿主機命令除錯網路，

# 在宿主機下使用ip addr查看容器中的網路資訊
[root@aliyun proc]# docker inspect 97649934abf3 | grep -i pid
            "Pid": 26103,
            "PidMode": "",
            "PidsLimit": null,
[root@aliyun proc]# nsenter -t 26103 -n ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
10: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever

# 容器中的網路資訊  可以發現完全相同
[root@97649934abf3 /]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
10: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever

namespace練習

# 在新的network namespace中執行sleep指令
[root@aliyun proc]# unshare -fn sleep 60
# 查看sleep行程ip
[root@aliyun /]# ps -ef | grep sleep
root     27992  2567  0 15:47 pts/0    00:00:00 unshare -fn sleep 60
root     27993 27992  0 15:47 pts/0    00:00:00 sleep 60
root     28000 25995  0 15:47 pts/1    00:00:00 grep --color=auto sleep
# 查看sleep的net namespace
[root@aliyun /]# lsns -t net
        NS TYPE NPROCS   PID USER COMMAND
4026531956 net      92     1 root /usr/lib/systemd/systemd --system --deserialize 17
4026532160 net       2 27992 root unshare -fn sleep 60
# 通過nsenter進入sleep的net namespace查看網路資訊（注意操作需要在sleep行程的存活時間內完成60s）
[root@aliyun /]# nsenter -t 27992 -n ip addr
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

Cgroup

Cgroup（control groups）是linux下用于對一個或一組行程進行資源限制和監控的機制，可以對諸如 CPU 使用時間、記憶體、磁盤 I/O 等行程所需的資源進行限制，舉個簡單的例子，我系統中跑了一個while(true)程式，系統的cpu資源立馬爆了，這時候我們可以通過cgroup對它限制cpu資源的使用，

Cgroup 在不同的系統資源管理子系統中以層級樹（Hierarchy）的方式來組織管理：每個 Cgroup 都可以包含其他的子 Cgroup，因此子 Cgroup 能使用的資源除了受本 Cgroup 配置的資源引數限制，還受到父 Cgroup 設定的資源限制，

Linux對cgroup的實作

同樣我們可以在task_struct結構體中看到cgroups相關聯的變數

## \kernel\msm-4.4\include\linux\sched.h
struct task_struct {
	/* Control Group info protected by css_set_lock: */
	struct css_set __rcu *cgroups;
	/* cg_list protected by css_set_lock and tsk->alloc_lock: */
	struct list_head cg_list;
}

struct css_set { 
    /* 
    * Set of subsystem states, one for each subsystem. This array is 
    * immutable after creation apart from the init_css_set during 
    * subsystem registration (at boot time).
    */
	struct cgroup_subsys_state *subsys[CGROUP_SUBSYS_COUNT];
}

Cgroup下的子系統

在/sys/fs/cgroup下我們可以看到cgroup所包含的子系統：

blkio：這個子系統設定限制每個塊設備的輸入輸出控制，例如:磁盤，光碟以及 USB 等等；
cpu：這個子系統使用調度程式為 cgroup 任務提供 CPU 的訪問；
cpuacct：產生 cgroup 任務的 CPU 資源報告；
cpuset：如果是多核心的CPU，這個子系統會為 cgroup 任務分配單獨的 CPU 和記憶體；
devices：允許或拒絕 cgroup 任務對設備的訪問；
freezer：暫停和恢復 cgroup 任務；
memory：設定每個 cgroup 的記憶體限制以及產生記憶體資源報告；
net_cls：標記每個網路包以供 cgroup 方便使用；
ns：名稱空間子系統；
pid: 行程標識子系統，

比較重要和常用的就是cpu子系統和memory子系統

CPU子系統

cpu子系統中的主要內容如下

Go語言演示cgroup對cpu的限制

撰寫一個test.go測驗檔案并運行

package main

func main(){
    i := 0
    go func(){
        for {
            i++
        } 
    }()
    
    for {
        i++
    }
}

使用top查看cpu在沒有限制下的占用率，可以看到test檔案占到90%多的cpu資源

在cgroup cpu子系統中建立檔案夾，并使用cgroup進行限制

[root@aliyun test]# mkdir /sys/fs/cgroup/cpu/test
[root@aliyun test]# cd /sys/fs/cgroup/cpu/test
[root@aliyun test]# ls
cgroup.clone_children  cpuacct.stat          cpu.cfs_period_us  cpu.rt_runtime_us  notify_on_release
cgroup.event_control   cpuacct.usage         cpu.cfs_quota_us   cpu.shares         tasks
cgroup.procs           cpuacct.usage_percpu  cpu.rt_period_us   cpu.stat
# 將cpu.cfs_quota_us的值設定為2000 cpu.cfs_period_us時間片默認的值還是為100000，可以將test.go執行的行程對cpu的利用率降低到2%左右
[root@aliyun test]# ehco 2000 > cpu.cfs_quota_us
# 將test的行程id加入到cgroup.procs中
[root@aliyun test]# ehco 31944 > cgroup.procs

此時再用top查看行程資源資訊就可以看到test測驗檔案對cpu的占用資源瞬間下降到2%作用，效果明顯！

? 注：

? 關于 tasks 和 cgroup.procs，網上很多文章將 cgroup 的 Task 簡單解釋為 OS 行程，這其實不夠準確，更精確地說，cgroup.procs 檔案中的 PID 串列才是我們通常意義上的行程串列，而 tasks 檔案中包含的 PID 實際上可以是 Linux 輕量級行程(Light-Weight-Process,LWP) 的 PID，而由于 Linux pthread 庫的執行緒實際上輕量級行程實作的，簡單來說：Linux 行程主執行緒 PID = 行程 PID，而其它執行緒的 PID (LWP PID)則是獨立分配的

? 當要向某個 Cgroup 加入 Thread 時，將Thread PID 寫入 tasks 或 cgroup.procs 即可，cgroup.procs 會自動變更為該 task 所屬的 Proc PID，如果要加入 Proc 時，則只能寫入到 cgroup.procs 檔案，tasks 檔案會自動更新為該 Proc 下所有的 Thread PID，通過tasks，我們可以實作執行緒級別的管理，

Memory子系統

cgroup的memory子系統全稱為 Memory Resource Controller ，它能夠限制cgroup中所有任務的使用的記憶體和交換記憶體進行限制，并且采取control措施：當OOM時，是否要kill行程，

Go語言演示cgroup對memory的限制

撰寫一個mem.go檔案

package main

// 參考《自動動手寫Docker》

import (
	"fmt"
	"io/ioutil"
	"os"
	"os/exec"
	"path"
	"strconv"
	"syscall"
)

const CgroupMemoryHierarchyMount = "/sys/fs/cgroup/memory"

func main() {
	if os.Args[0] == "/proc/self/exe" {
		fmt.Println("---------- 2 ------------")
		fmt.Printf("Current pid: %d\n", syscall.Getpid())

		// 創建stress子行程，施加記憶體壓力
		allocMemSize := "99m" // 
		fmt.Printf("allocMemSize: %v\n", allocMemSize)
		stressCmd := fmt.Sprintf("stress --vm-bytes %s --vm-keep -m 1", allocMemSize)
		cmd := exec.Command("sh", "-c", stressCmd)
		cmd.SysProcAttr = &syscall.SysProcAttr{}
		cmd.Stdin = os.Stdin
		cmd.Stdout = os.Stdout
		cmd.Stderr = os.Stderr

		if err := cmd.Run(); err != nil {
			fmt.Printf("stress run error: %v", err)
			os.Exit(-1)
		}
	}

	fmt.Println("---------- 1 ------------")
	cmd := exec.Command("/proc/self/exe")
	cmd.SysProcAttr = &syscall.SysProcAttr{
		Cloneflags: syscall.CLONE_NEWUTS | syscall.CLONE_NEWNS | syscall.CLONE_NEWPID,
	}
	cmd.Stdin = os.Stdin
	cmd.Stdout = os.Stdout
	cmd.Stderr = os.Stderr

	// 啟動子行程
	if err := cmd.Start(); err != nil {
		fmt.Printf("/proc/self/exe start error: %v", err)
		os.Exit(-1)
	}

	cmdPid := cmd.Process.Pid
	fmt.Printf("cmdPid: %d\n", cmdPid)

	// 創建子cgroup
	memoryGroup := path.Join(CgroupMemoryHierarchyMount, "test_memory_limit")
	os.Mkdir(memoryGroup, 0755)
	// 設定記憶體限制
	ioutil.WriteFile(path.Join(memoryGroup, "memory.limit_in_bytes"),
		[]byte("100m"), 0644)
	// 將行程加入cgroup
	ioutil.WriteFile(path.Join(memoryGroup, "tasks"),
		[]byte(strconv.Itoa(cmdPid)), 0644)

	cmd.Process.Wait()
}

函式解讀（在啟動時，stress占99M記憶體，cgroup限制最多使用100M記憶體）

一開始我們使用go run mem.go或者go build .運行時，并不滿足if os.Args[0] == "/proc/self/exe"的條件，所以跳過，
然后函式cmd := exec.Command("/proc/self/exe")創建了一個/proc/self/exe的子行程
在/sys/fs/cgroup/memory/創建test_memory_limit檔案，設定記憶體限制為100M
把子行程加入到task檔案中
等待子行程結束
子行程其實還是當前的程式，不過它的名字為proc/self/exe，符合最初的if陳述句判斷，之后會創建stress子行程，然后運行stress，

啟動

下面進入test_memory_limit目錄查看記憶體最大限制和task，發現記憶體最大限制與我們設計的一樣，

[root@aliyun test_memory_limit]# cat memory.limit_in_bytes 
104857600  // 剛好為100M
[root@aliyun test_memory_limit]# cat cgroups.proc
3599  // proc/self/exe行程
3602
3603  // stress行程

可以通過top查看資源占有率

cgroup.procs下為cgrouptest_memory_list中的行程，這些是真實的行程，可以通過pstree -p查看

下面看看將stress的記憶體超過100M的限制，是否會OOM掉，

修改代碼，將記憶體設定為110M，再運行

可以發現整個行程直接被KILL -9殺掉了，這就是cgroup對于memory的限制，

Docker演示cgroup限制cpu和memory

# 啟動一個nginx鏡像
docker run -d --cpu-shares 513 --cpus 0.2 --memory 1024M --memory-swap 1234M --memory-swappiness 7 -p 8081:80 nginx
# 引數決議
-d	docker容器在后臺運行·
--cpu-shares 513	表示相對分配的配額
--cpus 0.2	其實就是通過cpu.cfs_period_us和cpu.cfs_quota_us的比率來限制對cpu資源的利用率
--memory 1024  其實就是memory.limit_in_byte
--memory-swap 1234M   其實就是memory.memsw.limit_in_byte
--memory-swappiness	7   其實就是memory.swappiness
-p 8081:80（暴露在外的宿主機埠:nginx埠）
# 查看容器id
f4437f9db69d

下面我們進入cgroup下cpu子系統中可以發現有一個docker檔案，進入docker檔案中可以看到以剛才容器id命名的檔案夾

進入該檔案夾下，可以發現與我們之前的test.go案例非常一致，

剛剛docker啟動時配置的引數--cpu-shares 513能在cpu.shares檔案中體現

而引數--cpus 0.2就是 cpu.cfs_quota_us和cpu.cfs_period_us的比率，

同理進入cgroup下memory子系統中也可以發現一個docker檔案，與之對應也有一個容器id命名的檔案夾

進入該檔案夾下，查看與docker引數相對于的配置資訊

docker啟動時配置的引數--memory 1024能在memory.limit_in_bytes中體現

而引數--memory-swap 1234M能在memory.memsw.limit_in_byte中體現

引數--memory-swappiness 7能在memory.swappiness中體現

以上就是對于cgroup中最重要的兩個子系統cpu子系統和memory子系統進行分析~

Union FS

Docker鏡像里面其實是一層層的檔案系統，叫做Union FS（聯合檔案系統），UnionFS可以將幾層目錄掛載到一起，形成一個虛擬檔案系統，（舉個簡單的例子：我們有兩個檔案夾a和b，a檔案夾下又包含a1.txt a2.txt，b檔案夾下又包含b1.txt b2.txt，我們通過創建一個新的檔案夾c，通過Union FS就可以在c檔案夾下訪問到a1.txt a2.txt b1.txt b2.txt，這樣就把a，b兩個檔案夾聯合起來了）

從基本看一個典型的Linux檔案系統由bootfs和rootfs兩部分組成：

bootfs(boot file system)主要包含bootloader和kernel，bootloader主要引導加載kernel，linux剛啟動時會加載bootfs檔案系統，當boot加載完成之后整個內核就都在記憶體中了，記憶體的使用權已由bootfs轉交給內核，此時bootfs會被umount掉，在Docker鏡像的最底層就是bootfs，
rootfs(root file system)在bootfs之上，包含的就是典型的Linux系統中的/dev、/proc、/bin、/etc等標準目錄和檔案，rootfs就是各種不同的作業系統發行版，比如Ubuntu，CentOS等，

Mount命令實作聯合檔案系統案例

# 創建檔案夾
[root@aliyun uniontest]# mkdir lower upper merge work
# 在lower和upper檔案下內寫入檔案
[root@aliyun uniontest]# echo "from lower" > lower/in_lower.txt
[root@aliyun uniontest]# echo "from upper" > upper/in_upper.txt
[root@aliyun uniontest]# echo "from lower" > lower/in_both.txt
[root@aliyun uniontest]# echo "from upper" > upper/in_both.txt
# 使用mount命令掛載
[root@aliyun uniontest]# mount -t overlay overlay -o lowerdir=lower/,upperdir=upper/,workdir=work merge
# 查看聯合掛載后的檔案
[root@aliyun uniontest]# tree
.
├── lower
│   ├── in_both.txt
│   └── in_lower.txt
├── merge
│   ├── in_both.txt
│   ├── in_lower.txt
│   └── in_upper.txt
├── upper
│   ├── in_both.txt
│   └── in_upper.txt
└── work
    └── work

5 directories, 7 files
# 可以看到顯示的是upper層
[root@aliyun uniontest]# cat merge/in_both.txt 
from upper

Overlay2

先來區分幾個概念，

OverlayFS 指的是 Linux 的內核驅動
overlay/overlay2 指的是 Docker 的存盤驅動，

在上述圖中可以看到三個層結構，即：lowerdir、upperdir、merged，其中lowerdir是只讀的image layer，其實就是rootfs，image layer可以分很多層，所以對應的lowerdir是可以有多個目錄，而upperdir則是在lowerdir之上的一層，這層是讀寫層，在啟動一個容器時候會進行創建，所有的對容器資料更改都發生在這里層，最后merged目錄是容器的掛載點，也就是給用戶暴露的統一視角，而這些目錄層都保存在了/var/lib/docker/overlay2/

下面我們從下載一個容器進行分析，可以發現只有一層檔案

下面進入/var/lib/docker/overlay2中查看，可以發現確實只有一層檔案

小寫的l檔案夾是對這層的符號連接，只是為了減少mount引數可能達到的限制作用

進入到e757開頭的檔案夾中查看，可以發現diff檔案夾中是當前層的鏡像內容，link檔案中是短名稱

下面啟動一個鏡像后再進行查看可以發現多了兩層檔案

下面查看一下聯合掛載的情況，我們可以看出，overlay2將lowerdir、upperdir、workdir聯合掛載，形成最終的merged掛載點，其中lowerdir是鏡像只讀層，upperdir是容器可讀可寫層，workdir是執行涉及修改lowerdir執行copy_up操作的中轉層（例如，upperdir中不存在，需要從lowerdir中進行復制）

根據這個掛載我們可以分析一下掛載程序：

首先VKYIMVSFFSVOAWCBIZZQ6RNFB4短鏈接對應的是8cbdc1ab4a0567cf7841b3a6326bbbec185850b56dff309a572a6cff5be7742f-init/diff鏡像組態檔夾（標記為①）

4LISVLHRVBORTVPCSNCJHBMVSZ短鏈接對應的是e75746dca68dcf02f7fd5dc90a5828066c4d66ab8e6719030362e546e98bdc62/diff鏡像檔案夾（標記為②）且①和②都是屬于lowerdir層，只讀層，
查看①中的資訊

可以看到diff檔案中的內容

查看②中對應dev和etc檔案夾中的資訊

最后查看upperdir和merged的檔案

下面我們再做個測驗，進入剛剛啟動的ubuntu容器中，創建一個test.txt檔案

接下來我們查看容器的容器的可讀寫層，可以在容器層本身存放內容的diff檔案夾和merged檔案夾檔案中都可以看到test.txt，而在鏡像的只讀層卻沒有看到，說明分析的是正確的，

總結

以上就是對Docker核心的三個技術進行的分析操作，花費了大概三四天的時間，不過對于個人來說還是很有識訓的，以前對于這些也聽過，但是了解不是很深入，這次強迫自己認真的去學習一番，希望日后都可以進入這種深入的學習，文章可能有點長~哈哈

有問題的地方，希望大家多多指正，我會加以更改的~

參考檔案：

https://staight.github.io/2019/09/23/nsenter命令簡介/

https://www.cnblogs.com/sammyliu/p/5886833.html

https://wudaijun.com/2018/10/linux-cgroup/

https://lessisbetter.site/2020/09/01/cgroup-3-cpu-md/

https://lessisbetter.site/2020/08/30/cgroup-2-memory/

https://www.jianshu.com/p/274af1c0163e

https://zhuanlan.zhihu.com/p/41958018

https://www.cnblogs.com/wdliu/p/10483252.html

《趣談Linux作業系統》
本文由博客一文多發平臺 OpenWrite 發布！

整理制作了一份golang的面試題系列，已上傳GitHub，方便大家查看，歡迎star~，地址：https://github.com/zmk-c/GolangGuide

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/297483.html

標籤：其他

上一篇：約瑟夫環問題（通過觀察得出遞推式從而建立遞回求解）

下一篇：95后，剛作業2-3年就年薪50W+ ，才發現打敗我們的，從來不是年齡···

Dokcer核心技術

前言