繼docker之後podman容器技術崛起

Posted on by

一、什麼是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容器技術的資料請關註WalkonNet其它相關文章！

推薦閱讀：