容器和Open Container Initiative (OCI)是重要的開源應用程序打包和交付技術， Docker 和 Kubernetes 等項目使其流行起來。您對它們理解得越好，就越能夠使用它們來增強項目的一致性和可伸縮性。

在本文中，我將用簡單的術語描述這項技術，重點介紹鏡像和容器的基本方面以供開發人員理解，然后討論開發人員可以遵循的一些最佳實踐，以使他們的容器可移植。我還將引導您完成一個簡單的實驗，該實驗將演示如何構建和運行鏡像和容器。

什么是鏡像？

鏡像只不過是軟件的一種打包格式。一個很好的類比是 Java 的 JAR 文件或 Python 輪子。JAR（或 EAR 或 WAR）文件只是具有不同擴展名的 ZIP 文件，Python 輪子作為 gzip 壓縮包分發。它們都遵循一個標準的內部目錄結構。

鏡像被打包為tar.gz（gzipped tarballs），它們包括您正在構建或分發的軟件，但也就是僅有這點與 JAR 和輪子能夠類比的地方。一方面，鏡像不僅包含您的軟件，還包含運行您的軟件所需的所有支持依賴項，包括一個完整的操作系統。輪子和jar通常是作為依賴項構建的，但也可以是可執行的，而鏡像幾乎總是構建為可執行的，很少作為依賴項構建。

了解鏡像中內容的詳細信息對于了解如何使用鏡像或為它們編寫和設計軟件并不是必要的。從軟件的角度來看，重要的是要理解您創建的鏡像將包含一個完整的操作系統。因為從您希望運行的軟件的角度來看，鏡像被打包成一個完整的操作系統，所以它們必然比以更傳統方式打包的軟件大得多。

請注意，鏡像是不可變的。它們一旦構建就無法更改。如果您修改鏡像上運行的軟件，就必須構建一個全新的鏡像并替換舊鏡像。

標簽

在鏡像被創建時，通常都會使用一個唯一的哈希值來創建，但也會使用人類可讀的名稱標識它們。例如ubi、ubi-minimal、openjdk11等。但是，每個名稱都可以有不同版本的鏡像，并且通常通過標簽來區分。例如，openjdk11鏡像可能被標記為jre-11.0.14.1_1-ubi和jre-11.0.14.1_1-ubi-minimal，分別表示openjdk11軟件包版本11.0.14.1_1基于Red Hat ubi和ubi最小鏡像構建的鏡像。

什么是容器？

容器是在主機系統上實例化并運行的鏡像。從鏡像到運行容器分為兩步：創建和啟動。創建獲取鏡像并為其提供自己的 ID 和文件系統。Create(例如在docker Create中)可以重復多次，以創建一個鏡像的多個運行實例，每個實例都有自己的 ID 和文件系統。啟動容器將在主機上啟動一個隔離的進程，在容器中運行的軟件將表現得就像運行在自己的虛擬機中一樣。因此，容器是主機上的一個獨立的進程，具有自己的 ID 和獨立的文件系統。

從軟件開發人員的角度來看，使用容器有兩個主要原因：一致性和可伸縮性。這些是相互關聯的，它們共同允許項目使用近年來最有前途的軟件開發創新之一，即“一次構建，多次部署”的原則。

一致性

因為鏡像是不可變的，并且包含了從操作系統上運行軟件所需的所有依賴項，所以無論您選擇在何處部署它，都可以獲得一致性。這意味著無論您在開發、測試或任何數量的生產環境中將鏡像作為容器啟動，容器都將以完全相同的方式運行。作為軟件開發人員，您不必擔心這些環境是否運行在不同的主機操作系統或版本上，因為容器每次都運行相同的操作系統。這就是將軟件與其完整的運行時環境一起打包的好處，而不僅僅是因為缺乏必需的環境或依賴軟件，而無法運行的軟件。

這種一致性意味著在幾乎所有情況下，當在一個環境（例如，生產環境）中發現問題時，您可以確信自己能夠在開發或其他環境中重現該問題，因此您可以確認行為并專注于修復它。您的項目永遠不應該再次陷入“但是它可以在我的機器上工作”的可怕問題。

可伸縮性

鏡像不僅包含您的軟件，還包含運行您的軟件所需的所有依賴項，包括底層操作系統。這意味著在容器內運行的所有進程都將容器視為宿主系統，宿主系統對容器內運行的進程是不可見的，并且從宿主系統的角度來看，容器只是它管理的另一個進程。當然，虛擬機做的事情幾乎一樣，這就提出了一個合理的問題：為什么要使用容器技術而不是虛擬機？答案在于速度和規模。

容器只需運行支持獨立主機所需的軟件，而無需模擬硬件的開銷。虛擬機必須包含完整的操作系統并模仿底層硬件。后者是一個非常重量級的解決方案，它也會產生更大的文件。因為從主機系統的角度來看，容器只是另一個正在運行的進程，所以它們可以在幾秒鐘內而不是幾分鐘內啟動。當您的應用程序需要快速擴容時，容器每次都會在資源和速度上擊敗虛擬機。而且容器也更容易收縮。

從功能的角度來看，可伸縮性超出了本文的范圍，因此本實驗不會演示該特性，但是為了理解為什么容器技術代表了軟件打包和部署方面的重大進步，理解該原理是很必要的。

注意：雖然可以運行不包含完整操作系統的容器，但很少這樣做，因為可用的最小鏡像可能會引發其它問題。

如何發現和存儲鏡像

與所有其他類型的軟件打包技術一樣，容器也需要一個可以共享、發現和重用的地方。這些被稱為鏡像注冊表，類似于 Java Maven 和 Python 輪子存儲庫或 npm 注冊表。

以下是互聯網上可用的不同鏡像注冊表的例子：

Docker Hub: 最初的Docker注冊表，托管了許多在世界各地項目中廣泛使用的Docker官方鏡像，并為個人提供托管自己鏡像的機會。如adoptopenjdk就是在Docker Hub上托管鏡像的組織之一；可以點擊openjdk11查看其存儲倉庫以獲取該組織項目鏡像和標簽示例。

Red Hat Image Registry: 紅帽的官方鏡像注冊表，為那些有效紅帽訂閱者提供鏡像。

Quay: Red Hat 的公共鏡像注冊表托管了許多 Red Hat 的公共可用鏡像，并為個人提供了托管自己的鏡像的機會。

使用鏡像和容器

有兩個實用程序用于管理鏡像和容器：Docker和Podman。它們可用于 Windows、Linux 和 Mac 工作站。從開發人員的角度來看，它們在執行命令時是完全等價的。它們可以被認為是彼此的別名。您甚至可以在許多系統上安裝一個包，它會自動將 Docker 更改為 Podman 別名。本文檔中無論在哪里提到 Podman，都可以安全地替換 Docker，而不會改變結果。

您會立即注意到這些實用程序與 Git 非常相似，因為它們執行標簽、推送和拉取操作。您將經常使用或引用此功能。然而，它們不應與 Git 混淆，因為 Git 也管理版本控制，而鏡像是不可變的，它們的管理實用程序和注冊表沒有變更管理的概念。如果您將兩個具有相同名稱和標簽的鏡像推送到同一個存儲庫，則第二個鏡像將覆蓋第一個鏡像，而無法查看或理解發生了什么變化。

子命令

下面是你會經常使用或引用的Podman和Docker子命令的例子:

build: 構建鏡像

例子: podman build -t org/some-image-repo -f Dockerfile

image: 本地鏡像管理

例子: podman image rm -a 刪除所有本地鏡像

images: 列出本地存儲的鏡像

tag: 為鏡像打標簽

container: 容器管理

例子: podman container rm -a 刪除所有已停止的容器

run: 創建并啟動一個容器

還有 stop and restart

 pull/push: 從/向注冊表上的存儲庫拉/推和鏡像

Dockerfiles

Dockerfile 是定義鏡像的源文件，并使用build子命令進行處理。該文件將定義一個父鏡像或基礎鏡像，復制或安裝您希望在鏡像中運行的任何額外軟件，定義在構建或運行軟件過程中使用到的任何額外元數據，并有可能指定一個命令，該命令在鏡像實例化為容器后會立即執行。下面的實驗對 Dockerfile 的結構以及其中使用的一些更常用的命令進行了更詳細的描述。

Docker 和 Podman 的根本區別

Docker是類unix系統中的守護進程，是Windows系統中的服務。這意味著它一直在后臺運行，并且具有root或管理員權限。Podman是二進制的。這意味著它只能按需運行，并且可以作為非特權用戶運行。

這使得Podman對系統資源更安全、更高效。根據定義，以 root 權限運行任何東西都不太安全。在云端使用鏡像時，托管容器的云可以更安全地管理鏡像和容器。

Skopeo 和 Buildah

和 Docker 是一個單一的實用程序不同，Podman 在 GitHub 上有兩個由 Containers 組織維護的相關實用程序：Skopeo和Buildah。兩者都提供 Podman 和 Docker 不具備的功能，并且都是與Podman一起安裝在Red Hat系列Linux發行版上的容器工具包組的一部分。

在大多數情況下，鏡像構建可以通過 Docker 和 Podman 執行，但 Buildah 存在以防需要更復雜的鏡像構建。這些更復雜的構建的細節遠遠超出了本文的范圍，你很少會遇到需要它，但為了完整起見，我在這里提到了這個實用程序。

Skopeo 提供了 Docker 沒有的兩個實用功能：將鏡像從一個注冊表復制到另一個注冊表的能力以及從遠程注冊表中刪除鏡像的能力。同樣，此功能超出了本次討論的范圍，但該功能最終可能對您有用，尤其是在您需要編寫一些 DevOps 腳本時。

Dockerfiles 實驗

以下是一個非常短的實驗（大約 10 分鐘），它將教您如何使用 Dockerfiles 構建鏡像并將這些鏡像作為容器運行。它還將演示如何將容器配置外部化，以實現容器開發的全部優勢和“一次構建，多次部署”。

安裝

以下實驗室是在本地運行 Fedora 并在已安裝 Podman 和 Git的Red Hat 沙盒環境中創建和測試的。我相信在Red Hat沙箱環境中運行它會讓您從這個實驗中獲得最大的收獲，但是在本地運行它也是完全可以接受的。

您還可以在自己的工作站上安裝 Docker 或 Podman 并在本地工作。提醒一下，如果您安裝了 Docker，podman 和 docker對于這個實驗來說是完全可以互換的。

構建鏡像

1. 從 GitHub 克隆 Git 存儲庫：

$ git clone https://github.com/hippyod/hello-world-container-lab

2. 編輯 Dockerfile：

$ cd hello-world-container-lab
$ vim Dockerfile
1 FROM Docker.io/adoptopenjdk/openjdk11:x86_64-ubi-minimal-jre-11.0.14.1_1
2
3 USER root
4
5 ARG ARG_MESSAGE_WELCOME='Hello, World'
6 ENV MESSAGE_WELCOME=${ARG_MESSAGE_WELCOME}
7
8 ARG JAR_FILE=target/*.jar
9 COPY ${JAR_FILE} app.jar
10
11 USER 1001
12
13 ENTRYPOINT ["java", "-jar", "/app.jar"]

這個Dockerfile有以下特性:

FROM 語句（第 1 行）定義了構建這個新鏡像的基礎（或父）鏡像。

USER 語句（第 3 行和第 11 行）定義了在構建期間和執行時正在運行的用戶。起初，root 在構建過程中運行。在更復雜的 Dockerfile 中，我需要 root 才能安裝任何額外的軟件、更改文件權限等等，以完成新鏡像。在 Dockerfile 結束時，我切換到 UID 為 1001 的用戶，這樣，每當鏡像實例化為容器并執行時，用戶將不是 root，因此更安全。使用 UID 而不是用戶名，以便主機可以識別哪個用戶正在容器中運行，以防主機加強了安全措施，阻止容器用root用戶運行。

 ARG 語句（第 5 行和第 8 行）定義了只能在構建過程中使用的變量。

 ENV 語句（第 6 行）定義了一個環境變量和值，可以在構建過程中使用，但也可以在鏡像作為容器運行時使用。請注意它是如何通過引用前面 ARG 語句定義的變量來獲取其值的。

COPY 語句（第 9 行）將 Spring Boot Maven 構建創建的 JAR 文件復制到鏡像中。為了方便在未安裝 Java 或 Maven 的 Red Hat 沙箱中運行的用戶，我預先構建了 JAR 文件并將其推送到 hello-world-container-lab 存儲庫。在本實驗室中無需進行 Maven 構建。（注意：還有一個add命令可以替代 COPY。由于該add命令可能具有不可預知的行為，因此最好使用 COPY。）

最后，ENTRYPOINT 語句定義了容器啟動時應該在容器中執行的命令和參數。如果此鏡像成為后續鏡像定義的基礎鏡像并且定義了新的 ENTRYPOINT，它將覆蓋此鏡像。（注意：還有一個cmd命令可以代替 ENTRYPOINT。兩者之間的區別在此本文中無關緊要，超出了本文的范圍。）

鍵入:q并按Enter退出 Dockerfile 并返回到 shell。

3. 構建鏡像：

$ podman build --squash -t test/hello-world -f Dockerfile

你應該看到：

STEP 1: FROM docker.io/adoptopenjdk/openjdk11:x86_64-ubi-minimal-jre-11.0.14.1_1
Getting image source signatures
Copying blob d46336f50433 done  
Copying blob be961ec68663 done
...
STEP 7/8: USER 1001
STEP 8/8: ENTRYPOINT ["java", "-jar", "/app.jar"]
COMMIT test/hello-world
...
Successfully tagged localhost/test/hello-world:latest
5482c3b153c44ea8502552c6bd7ca285a69070d037156b6627f53293d6b05fd7

除了構建鏡像之外，這些命令還提供了以下說明：

--squash標志將通過確保在鏡像構建完成時僅向基礎鏡像添加一層來減小鏡像大小。多余的層會使最后生成的鏡像變得更大。FROM、RUN 和 COPY/ADD 語句都會添加一層，最佳實踐是在可能的情況下連接這些語句，例如：

RUN dnf -y --refresh update && \
    dnf install -y --nodocs podman skopeo buildah && \
    dnf clean all

上面的 RUN 語句不僅會運行每個語句才僅創建一個層，而且如果其中任何一個失敗，也會使構建失敗。

-t 用于命名鏡像。因為我沒有顯式地定義名稱的標簽（如test/hello-world:1.0)，所以默認將鏡像標記為latest。我也沒有定義注冊表（如quay.io/test/hello-world），所以默認的注冊表將是 localhost。

-f 標志用于明確聲明要構建的 Dockerfile。

當運行構建時，Podman 將跟蹤“blob”的下載。這些是您的鏡像將建立的鏡像層。它們最初是從遠程注冊表中提取的，它們將被緩存在本地以加速未來的構建。

Copying blob d46336f50433 done  
Copying blob be961ec68663 done
...
Copying blob 744c86b54390 skipped: already exists  
Copying blob 1323ffbff4dd skipped: already exists

4. 當構建完成時，列出鏡像以確認它已成功構建:

$ podman images

你應該看到：

REPOSITORY                                        TAG                                                      IMAGE ID      CREATED               SIZE
localhost/test/hello-world                 latest                                                    140c09fc9d1d  7 seconds ago  454 MB
docker.io/adoptopenjdk/openjdk11  x86_64-ubi-minimal-jre-11.0.14.1_1  5b0423ba7bec  22 hours ago   445 MB

運行容器

5. 運行鏡像：

$ podman run test/hello-world

你應該看到：

.   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::                (v2.5.4)

...
GREETING: Hello, world
GREETING: Hello, world

輸出將繼續每三秒打印"Hello, world"，直到退出:

crtl-c

6. 證明Java只安裝在容器中:

$ java -version

在容器內運行的 Spring Boot 應用程序需要 Java 才能運行，這也是我選擇基礎鏡像的原因。如果您在Red Hat 沙盒環境中運行這個實驗，這也證明 Java 僅安裝在容器中，而不是主機上：

-bash: java: command not found...

外部化配置

鏡像現在已構建，但是當我希望將鏡像部署到每個環境中的“Hello, world”消息都不同時會發生什么？例如，我可能想要更改它，因為環境是針對不同的開發階段或不同的語言環境。如果我更改 Dockerfile 中的值，我需要構建一個新鏡像才能看到消息，這破壞了容器最基本的好處之一——“一次構建，多次部署”。那么如何使我的鏡像真正可移植，以便可以將其部署在我需要的任何地方呢？答案在于外部化配置。

7. 使用新的外部歡迎消息運行鏡像：

$ podman run -e 'MESSAGE_WELCOME=Hello, world DIT' test/hello-world

你應該看到：

Output:
  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::                (v2.5.4)  
...
GREETING: Hello, world DIT
GREETING: Hello, world DIT

通過使用crtl-c停止，并調整消息后重新執行:

$ podman run -e 'MESSAGE_WELCOME=Hola Mundo' test/hello-world
.   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::                (v2.5.4)  
...
GREETING: Hola Mundo
GREETING: Hola Mundo

-e標志定義了在啟動時注入容器的環境變量和值。如您所見，即使該變量已內置到原始鏡像中（Dockerfile 中的語句ENV MESSAGE_WELCOME=${ARG_MESSAGE_WELCOME}），它也會被覆蓋。現在，您已經外部化了需要根據部署位置進行更改的數據(例如，在DIT環境中或針對說西班牙語的用戶)，從而使鏡像具有可移植性。

8. 使用文件中定義的新消息運行鏡像：

$ echo 'Hello, world from a file' > greetings.txt
$ podman run -v "$(pwd):/mnt/data:Z" \
    -e 'MESSAGE_FILE=/mnt/data/greetings.txt' test/hello-world

運行這個例子，您應該看到：

.   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::                (v2.5.4)  
...
GREETING: Hello, world from a file
GREETING: Hello, world from a file

重復，直到按ctrl -c停止

在這種情況下，-e標志定義了/mnt/data/greetings.txt 的文件路徑，該路徑通過-v 標志從主機的本地文件系統$(pwd)/greetings.txt(pwd是一個 bash 實用程序，輸出當前目錄的絕對路徑，在您的情況下應該是hello-world-container-lab)掛載到容器中。現在，您已經外部化了需要根據部署位置更改的數據，但這一次數據是在掛載到容器中的外部文件中定義的。如果環境變量數量不多，那么直接在命令行設置是可以的，但是當您要設置好幾個環境變量時，使用文件將環境變量注入容器是更有效的方式。

注意：:Z上述卷定義末尾的標志適用于使用SELinux的系統。SELinux 管理許多 Linux 發行版上的安全性，并且該標志允許容器訪問目錄。如果沒有這個標志，SELinux 會阻止讀取文件，并且容器中會拋出異常。刪除:Z標記后再次嘗試運行上面的命令以查看演示。

實驗到此結束。

容器開發：外部化配置

“一次構建，多次部署”之所以有效，是因為在不同環境中運行的不可變容器不必擔心支持特定軟件項目所需的硬件或軟件的差異。這一原則使軟件開發、調試、部署和持續維護變得更快、更容易。它也不是完美的，必須在編寫代碼的方式上進行一些小的更改，才能使容器真正可移植。

為容器化編寫軟件時，最重要的設計原則是決定要外部化什么。這些決定最終使您的鏡像可移植，因此它們可以完全實現“一次構建，多次部署”的范例。盡管這看起來很復雜，但在決定配置數據是否應該注入到運行的容器中時，有一些容易記住的因素需要考慮:

數據環境是否特定的？這包括任何需要根據容器運行位置配置的數據，無論環境是生產環境、非生產環境還是開發環境。此類數據包括國際化配置、數據存儲信息以及您希望應用程序在其下運行的特定測試配置文件。

數據發布是否獨立？ 這種類型的數據可以運行從功能標志到國際化文件再到日志級別的所有數據——基本上，您可能想要或需要在版本之間更改的任何數據，而無需構建和新部署。

數據是秘密嗎？憑證不應被硬編碼或存儲在鏡像中。憑證通常需要在與發布時間表不匹配的時間表上刷新，并且將機密嵌入存儲在鏡像注冊表中的鏡像中存在安全風險。

最佳實踐是選擇應該將配置數據外部化的位置（即在環境變量或文件中），并且只外部化那些滿足上述條件的部分。如果它不符合上述標準，最好將其保留為不可變鏡像的一部分。遵循這些準則將使您的鏡像真正可移植，并使您的外部配置保持合理的大小和可管理性。

總結

本文為剛接觸鏡像和容器的軟件開發人員介紹了四個關鍵概念和思路：

鏡像是不可變的二進制文件：鏡像是打包軟件以便以后重用或部署的一種方法。

容器是獨立的進程：當它們被創建時，容器是一個鏡像的運行時實例。當容器啟動時，它們成為主機上內存中的進程，這比虛擬機更輕、更快。在大多數情況下，開發人員只需要了解后者，但了解前者是有幫助的。

 “一次構建，多次部署”：這個原則使容器技術如此有用。鏡像和容器提供了部署的一致性和獨立于主機的獨立性，允許您跨許多不同的環境進行部署。由于這一原則，容器也很容易伸縮。

將配置外部化：如果您的鏡像具有特定于環境、獨立于發布或機密的配置數據，請考慮將該數據置于鏡像和容器之外。您可以通過注入環境變量或將外部文件掛載到容器中來將此數據注入正在運行的鏡像中。

譯者介紹

崔瑩峰，51CTO社區編輯，一名70后程序員，擁有10多年工作經驗，長期從事 Java 開發，架構設計，容器化等相關工作。精通Java，熟練使用Maven、Jenkins等Devops相關工具鏈，擅長容器化方案規劃、設計和落地。

原文標題：A hands-on guide to images and containers for developers，作者：Evan "Hippy" Slatis

鏈接：https://opensource.com/article/22/5/guide-containers-images