繼docker之後podman容器技術崛起

2022-03-08 19:00:04

一、什麼是podman與OCI

Podman是一個無守護行程、開源的原生容器工具，旨在基於 Open Containers Initiative ( OCI )組織及規範，讓映象容器能夠輕鬆查詢、執行、構建、共用和部署應用程式。

提到podman就不能不說說OCI，這個組織有點意思。Docker容器技術出現並且迅速風靡全球，為傳統的持續整合與持續釋出領域帶來了革命性的變化。這個時候各個大佬們（谷歌，Redhat、微軟、IBM、Intel、思科）就有點坐不住了，大家一起喝喝茶聊聊天就決定要成立一個新的組織：OCI。這個組織成立的目的很明顯，就是要防止容器技術被docker一家壟斷。docker方面雖然心不甘、情不願，但是也沒有什麼太好的辦法，也加入了該組織，畢竟胳膊擰不過大腿。另外還有以下幾個原因

docker的容器概念和設計很新穎，但是底層實現並不是什麼高精尖的技術，很容易被模仿。
docker方面希望被推廣使用，離不開大佬們的支援。
docker本身還存在幾個硬傷，確實容易被超越和追趕。

有的朋友說podman是docker執行、構建、共用的輔助工具，這麼說並不正確哈，podman目前的發展其本身就是一種獨立的容器技術，其執行時環境不依賴於docker。

二、docker有什麼硬傷？

硬傷一：docker存在一個名為dockerd 的程序，會佔用比較多的CPU資源。同時一個dockerd守護行程還可能導致單點故障的問題，該守護行程掛掉了，容器也就無法正常提供服務。

硬傷二：docker守護行程以root使用者執行，這給作業系統的安全性和容器安全性帶來了非常大的挑戰。

然而Podman 不需要以 root 身份執行的守護行程，Podman 容器的執行許可權與啟動它們的linux使用者相同，這解決了一個重大的安全問題。Podman 是一個無守護行程的容器引擎，並且Podman 不需要守護行程來啟動和管理容器。這是兩個開源專案之間的一個最重要區別。這也是筆者看好podman未來會代替docker成為主流容器技術的核心原因。

三、從docker過度到podman非常easy

如果你使用過docker的CLI命令列，podman幾乎沒有任何的區別，只需要把docker換成podman即可，引數順序、含義都是一樣的。如：

docker pull nginx
換成
podman pull nginx
即可

如果你不想將docker命令換成podman，因為這樣需要修改以往的指令碼。也可以通過對映命令alias docker=podman來實現，這樣就可以無縫的將docker遷移到podman環境下使用。

另外容器映象格式方面在 Docker 和 Podman 之間也是完全相容的。所以現有的映象，不論是docker官方映象，還是我們以往自己構建的docker映象，都可以在podman環境下使用。

四、上手podman

4.1.安裝

下面我們就來簡單的搞一搞，在CentOS作業系統可以直接使用yum命令安裝podman。事先說明的是我這個是一臺新的最小化安裝的CentOS7虛擬機器器，並不包含docker，也不曾安裝。

yum -y install podman    # root使用者安裝

檢視版本

# podman version
Version:            1.6.4
RemoteAPI Version:  1
Go Version:         go1.12.12
OS/Arch:            linux/amd64

新建podman使用者，後續使用該使用者執行容器。

adduser podman   # root使用者新建podman使用者

adduser podman   # root使用者新建podman使用者

4.2.CentOS7環境下需要做的特殊處理

出於上文中所說的安全性考慮，我們不使用root使用者操作映象及容器。所以需要做如下的一些設定。

如果你使用CentOS7，需要做如下的一些特殊處理。其他的作業系統可能需要不同的解決方案，這些解決方案基本大同小異。

如果你使用root使用者執行映象容器，這些特殊處理就不需要做，直接就可以用

CentOS7預設關閉使用者namespace，將它開啟

echo 10000 > /proc/sys/user/max_user_namespaces;
grubby --args="user_namespace.enable=1" --update-kernel="$(grubby --default-kernel)";
echo "user.max_user_namespaces=10000" >> /etc/sysctl.conf;

4.3. 設定非root使用者id及組id範圍

嘗試在linux宿主機作業系統新建使用者podman使用者環境下執行nginx映象拉取

su - podman                               # 切換使用者為podman
podman pull docker.io/library/nginx   # 執行拉取映象

如果你有如下的報錯資訊

su - podman                               # 切換使用者為podman
podman pull docker.io/library/nginx   # 執行拉取映象

或者如下報錯資訊

 Error processing tar file(exit status 1): there might not be enough IDs available in the namespace

請退出podman使用者切換回到root使用者（exit命令），執行下列命令，podman為執行容器的一個非root使用者

echo "podman:100000:65536" >> /etc/subuid
echo "podman:100000:65536" >> /etc/subgid

這段設定的作用就是設定一個容器內的作業系統與宿主機作業系統使用者的uid、gid之間的對映關係。如上所示 100000 - 165535(100000 + 65535) 在宿主機的id就對映到容器內的 0-65535的使用者。設定完之後執行如下命令

podman system migrate

官方解釋上面的命令可以讓設定生效，但是不知道什麼原因，筆者執行該命令設定並未生效，而是重啟了一下作業系統才生效。

五、在非root使用者下容器映象的使用

同樣的先把root切換到宿主機的podman使用者

su - podman

拉取映象命令

$ podman pull docker.io/library/nginx

Trying to pull docker.io/library/nginx...
Getting image source signatures
Copying blob 1ae07ab881bd done  
Copying blob 091c283c6a66 done  
Copying blob 78091884b7be done  
Copying blob 5eb5b503b376 done  
Copying blob b559bad762be done  
Copying blob 55de5851019b done  
Copying config c316d5a335 done  
Writing manifest to image destination
Storing signatures
c316d5a335a5cf324b0dc83b3da82d7608724769f6454f6d9a621f3ec2534a5a

檢視映象列表（在x使用者下拉取的映象，在y使用者下是檢視不到的）

$ podman images
REPOSITORY                TAG      IMAGE ID       CREATED       SIZE
docker.io/library/nginx   latest   c316d5a335a5   2 weeks ago   146 MB

執行容器映象

podman run -p 8080:80 -d docker.io/library/nginx

其他的命令就不一一的列舉了，和docker命令執行方式是一模一樣的，引數順序、名稱也是一摸一樣的。

總結

在單機環境下docker可以無縫的切換到podman環境，對docker-swarm或dcoker-compose支援需要驗證，但筆者幾乎從來不用這兩個東西，所以暫時沒有驗證的動力。至於與k8s的相容性，我想這是一定的，而且會越來越好，因為OCI組織的首席大佬就是谷歌，不可能不支援自己的產品之間的相容性。

如果你使用root使用者操作podman容器，與docker幾乎是一模一樣的，甚至連命令列都不需要改。但是我們用podman代替docker的主要原因我想就是使用非root使用者，來提升容器安全性。所以不同的作業系統及版本需要針對非root使用者的許可權做一些額外設定，從而來滿足使用要求。

以上就是繼docker之後podman容器技術崛起的詳細內容，更多關於podman容器技術的資料請關注it145.com其它相關文章！