系列文章
Day 11: 繼續來玩一下 PID namespace
接續昨天的實驗，我們用 unshare 指令做出了一個新的 PID namespace，其 id 為 4026532207： $ sudo lsns -t pi...
Day 12: 來用 clone 建立新的 PID namespace
昨天我們用 unshare 建立了新的 namespace，今天我們換個方式，改用另外一個可以用來建立 namespace 的 API clone，我在 git...
Day 13: Mount Namespace 的坑
昨天試著用 clone API 加上 CLONE_NEWPID flag 去做出一個新的 PID namespace 時，發現在裡面執行 ps 指令的話，會看到...
Day 16: process 的族譜
昨天我們討論了 docker exec 是怎麼利用 setns 這個 API 讓 COMMAND 所啟動的這個新的 process 「進入」container...
Day 14: container 與 namespace
透過對 namespace 的討論，我們知道了所謂的「隔離」，其實就是建立各種不同種類的命名空間給我們要新執行的那個 process，如此一來這個 proces...
Day 15: docker exec 是怎麼辦到的呢？
有用過 docker 的人相信對 docker exec 這個指令並不陌生，這個指令可以讓我們「進入」一個 container，但 container 不是已經...
Day 17: 殭屍與孤兒
昨天我們討論到 Linux 上的 process 都是由現有的 process 去 fork 出來的，且這些 processes 之間會有父子關係。而當一個 p...
Day 18: container 中 PID 1 process 的 parent 是誰呢？
到目前，我們知道了 Linux 上的 processes 是有父子關係的、討論了 zombie process 跟 orphan process，也知道了 PI...
Day 19: Container 中 PID 1 的 process 會擔負起 init process 的責任嗎？
昨天討論到了 Docker 的流程如下: Docker CLI ==> dockerd ==> conatinerd ==> containe...
Day 20: 不負責任的 PID 1
昨天我們「似乎」證明了 container 中的 PID 1 有負起 init process 的責任，會接收子孫輩的 orphan process。 我們來換...