Dokcer核心技術


前言

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

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

但是我們在學習一樣東西時不能僅僅停留於表面的命令,更重要的是深入進去理解,Docker的核心技術主要基於Linux的namespacecgroupUnion Fs文件系統,以及Docker自身的網絡

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

Namespace

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

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

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

image-20210831133937805

注: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的操作方法

主要是三個命令:clonesetnsunshare

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子系統中的主要內容如下

image-20210901102949900

Go語言演示cgroup對cpu的限制

編寫一個test.go測試文件並運行

package main

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

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

image-20210831165337062

在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%作用,效果明顯!

image-20210831165931718

注:

​ 關於 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進程。

image-20210904110306768

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內存)

  1. 一開始我們使用go run mem.go或者go build .運行時,並不滿足if os.Args[0] == "/proc/self/exe"的條件,所以跳過。
  2. 然后函數cmd := exec.Command("/proc/self/exe")創建了一個/proc/self/exe的子進程
  3. /sys/fs/cgroup/memory/創建test_memory_limit文件,設置內存限制為100M
  4. 把子進程加入到task文件中
  5. 等待子進程結束
  6. 子進程其實還是當前的程序,不過它的名字為proc/self/exe,符合最初的if語句判斷,之后會創建stress子進程,然后運行stress。

啟動

image-20210901204046560

下面進入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查看資源占有率

image-20210901202822042

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

image-20210901204754246

下面看看將stress的內存超過100M的限制,是否會OOM掉。

修改代碼,將內存設置為110M,再運行

image-20210901205605014

可以發現整個進程直接被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命名的文件夾

image-20210901110628943

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

剛剛docker啟動時配置的參數--cpu-shares 513能在cpu.shares文件中體現

而參數--cpus 0.2就是 cpu.cfs_quota_uscpu.cfs_period_us的比率。

image-20210901111641162

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

image-20210901112331131

進入該文件夾下,查看與docker參數相對於的配置信息

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

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

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

image-20210901113507785

以上就是對於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文件系統由bootfsrootfs兩部分組成:

  • 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等。

img

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 的存儲驅動。

img

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

下面我們從下載一個容器進行分析,可以發現只有一層文件

image-20210902155059110

下面進入/var/lib/docker/overlay2中查看,可以發現確實只有一層文件

image-20210902155219263

小寫的l文件夾是對這層的符號連接,只是為了減少mount參數可能達到的限制作用

image-20210902155305786

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

image-20210902160200901

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

image-20210902155523593

image-20210902155607814

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

image-20210902161259469

根據這個掛載我們可以分析一下掛載過程:

  1. 首先VKYIMVSFFSVOAWCBIZZQ6RNFB4短鏈接對應的是8cbdc1ab4a0567cf7841b3a6326bbbec185850b56dff309a572a6cff5be7742f-init/diff鏡像配置文件夾(標記為①)

    4LISVLHRVBORTVPCSNCJHBMVSZ短鏈接對應的是e75746dca68dcf02f7fd5dc90a5828066c4d66ab8e6719030362e546e98bdc62/diff鏡像文件夾(標記為②)且①和②都是屬於lowerdir層,只讀層。

  2. 查看①中的信息

image-20210902163326115

可以看到diff文件中的內容

  1. 查看②中對應devetc文件夾中的信息

image-20210902164320285

  1. 最后查看upperdirmerged的文件

image-20210902164827996下面我們再做個測試,進入剛剛啟動的ubuntu容器中,創建一個test.txt文件

image-20210902165238467

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

image-20210902165402994

image-20210902165911005

總結

以上就是對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 發布!


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM