GitOps K8s 自動化佈署：應用封裝的標準方式

容器是封裝應用程式的標準格式，這種格式是由開放容器倡議（Open Container Initiative, OCI）推廣的開放標準。OCI 是一個開放治理結構，專門為建立容器格式和執行時的開放行業標準而設立。這種格式的開放性確保了跨不同作業系統、廠商、平台或雲端的可攜性和互操作性。

容器映像的核心概念

容器映像是一種分層結構，包含基礎作業系統和額外的層，如執行時環境、函式庫用程式。每個容器映像提供容器的基礎層，而任何更新只是在基礎上增加的額外層。

在深入容器建立方法之前，先了解幾個核心概念：

1. 容器映像（Container Image）：應用程式的可執行套件，包含執行所需的一切（程式碼、執行時、系統工具、系統函式庫
2. 容器引擎（Container Engine）：負責建立和管理容器映像的工具
3. 執行時（Runtime）：執行容器的環境

使用 Docker 建立容器映像

Docker 是最廣泛使用的開放原始碼容器引擎和執行時，可以透過指定名為 Dockerfile 的清單生成容器映像。

Dockerfile 基本結構

一個典型的 Dockerfile 包含以下指令：

FROM registry.access.redhat.com/ubi8/python-39
ENV PORT 8080
EXPOSE 8080
WORKDIR /usr/src/app
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
ENTRYPOINT ["python"]
CMD ["app.py"]

這個 Dockerfile 定義了一個 Python 應用的容器：

• FROM：指定基礎映像，這裡使用 Red Hat Universal Base Image (UBI) 8 with Python 3.9
• ENV：設定環境變數，這裡設定 PORT=8080
• EXPOSE：對容器網路開放連線埠，這裡開放 TCP 8080 連線埠
• WORKDIR：設定容器內的工作目錄
• COPY：從主機複製檔案到容器映像層
• RUN：在容器內執行命令，這裡安裝 Python 依賴項
• ENTRYPOINT：定義容器啟動時執行的程式，這裡是 Python 直譯器
• CMD：指定傳遞給 ENTRYPOINT 的引數，這裡執行 app.py

建立容器映像

有了 Dockerfile 後，可以使用以下命令建立容器映像：

docker build -f Dockerfile -t quay.io/your-username/pythonapp:latest .

請將 quay.io/your-username/pythonapp:latest 替換為你自己的映像名稱，包含登入檔、使用者名和儲存函式庫

更多容器建立工具選擇

雖然 Docker 是最常見的容器建立工具，但還有其他無需守護程式的替代方案：

Jib：針對 Java 應用的容器建立工具

Jib 是 Google 開發的工具，專為 Java 應用設計，無需 Docker 守護程式即可建立容器：

<!-- Maven 設定範例 -->
<plugin>
    <groupId>com.google.cloud.tools</groupId>
    <artifactId>jib-maven-plugin</artifactId>
    <version>3.2.1</version>
    <configuration>
        <to>
            <image>quay.io/your-username/javaapp:latest</image>
        </to>
    </configuration>
</plugin>

執行 mvn compile jib:build 即可建立並推播容器映像。

Buildah：無守護程式的容器建立工具

Buildah 是一個無需守護程式的容器建立工具，特別適合自動化環境：

# 從基礎映像啟動容器
container=$(buildah from registry.access.redhat.com/ubi8/python-39)

# 設定環境變數和工作目錄
buildah config --env PORT=8080 --workingdir /usr/src/app $container

# 複製檔案並執行命令
buildah copy $container requirements.txt .
buildah run $container pip install --no-cache-dir -r requirements.txt
buildah copy $container . .

# 設定啟動命令
buildah config --entrypoint '["python", "app.py"]' $container

# 完成並提交映像
buildah commit $container quay.io/your-username/pythonapp:latest

Buildpacks：更高層級的容器抽象

Buildpacks 提供了一種更高層級的抽象，可以自動檢測應用類別並建立適當的容器：

pack build quay.io/your-username/myapp:latest \
    --builder paketobuildpacks/builder:base \
    --path ./my-application

這個命令會自動檢測應用類別（如 Java、Node.js、Python 等），並建立適當的容器映像。

Kubernetes 中的容器映像建立

Kubernetes 本身不提供建立容器映像的原生機制，但其高度可擴充套件的架構允許與外部工具互操作。Shipwright 是一個開放原始碼框架，用於在 Kubernetes 上建立容器映像，提供一種抽象，可以使用 kaniko、Buildpacks 或 Buildah 等工具建立容器映像。

安裝 Shipwright 後，可以定義建立策略：

apiVersion: shipwright.io/v1alpha1
kind: BuildStrategy
metadata:
  name: buildpacks-v3
spec:
  buildSteps:
    - name: build-and-push
      image: gcr.io/paketo-buildpacks/builder:base
      command:
        - /lifecycle/creator
      args:
        - -app=$(params.shp-source-root)
        - -layers=/layers
        - -cache-dir=/cache
        - -uid=1000
        - -gid=1000
        - $(params.shp-output-image)

然後定義建立資源：

apiVersion: shipwright.io/v1alpha1
kind: Build
metadata:
  name: buildpacks-python-build
spec:
  source:
    url: https://github.com/your-username/python-app
    contextDir: .
  strategy:
    name: buildpacks-v3
    kind: BuildStrategy
  output:
    image: quay.io/your-username/python-app:latest

容器技術選擇的考量因素

在選擇容器建立工具時，有幾個因素需要考慮：

開發環境與工作流程

1. 開發體驗：Docker 提供最直觀的開發體驗，適合初學者
2. CI/CD 整合：無守護程式工具（如 Buildah、Buildpacks）在 CI/CD 管道中更適合
3. 語言特定需求：如果專注於特定語言（如 Java），專用工具（如 Jib）可能更適合

安全與合規性

1. 基礎映像選擇：優先考慮有安全更新支援的基礎映像（如 UBI）
2. 最小化攻擊面：使用多階段建構減少最終映像大小
3. 映像掃描：整合容器映像掃描工具檢測安全漏洞

效能與資源使用

1. 建構時間：不同工具在建構速度上有差異，特別是在處理大型應用時
2. 快取機制：評估各工具的層快取效率
3. 資源消耗：Docker 守護程式在資源受限環境中可能是個考量

容器化最佳實踐

多年來，玄貓在容器化應用時發現了一些關鍵最佳實踐：

映像最佳化

1. 多階段建構：使用多階段 Dockerfile 減少最終映像大小

   # 建構階段
   FROM node:14 AS builder
   WORKDIR /app
   COPY package*.json ./
   RUN npm install
   COPY . .
   RUN npm run build
   
   # 執行階段
   FROM nginx:alpine
   COPY --from=builder /app/build /usr/share/nginx/html
   

2. **最小化層數

容器映像的建構與管理：從Docker到無Docker解決方案

在現代軟體開發與佈署過程中，容器技術已成為標準配備。無論是開發環境的一致性、CI/CD流程的自動化，還是生產環境的佈署，容器都扮演著關鍵角色。而容器映像（Container Image）的建構則是整個容器化過程的起點。本文將探討兩種主要的容器映像建構方法：傳統的Docker方式以及無需Docker的Jib解決方案。

容器映像建構的基本概念

容器映像是一個輕量級、可執行的軟體套件，包含了應用程式及其所有依賴項。它實際上是一個分層式檔案系統，每一層都代表著Dockerfile中的一個指令或操作。這種分層架構不僅使映像建構更有效率，也大幅減少了儲存和傳輸的成本。

當談到映像建構時，值得理解的是，我們實際上是在建立一個多層結構，而非單一的整體檔案。每一層都建立在前一層之上，只有變更的部分會形成新的層。這就是為何在多次建構過程中，大部分層可以被重複利用，大幅加快建構速度。

使用Docker建構容器映像

Docker建構流程深度解析

當你執行Docker建構命令時，Docker引擎會從Dockerfile讀取指令並逐一執行。每個指令執行後都會形成一個新的映像層。這個過程包含了從公共容器倉函式庫DockerHub、Quay或Red Hat Registry）取得基礎層，然後在其上增加自定義層。

以下是典型的建構過程示範：

docker build -t myapp:latest .

在執行此命令時，Docker會：

1. 解析Dockerfile中的指令
2. 檢查本地快取是否有所需的基礎映像層
3. 如果沒有，從指定的倉函式庫這些層
4. 執行每條指令並建立新的映像層
5. 最終生成一個完整的容器映像

詳解Docker建構步驟

讓我們分析一個實際的建構過程。以下是建構Python應用程式容器的步驟：

STEP 1: FROM registry.access.redhat.com/ubi8/python-39

這一步Docker會從Red Hat Registry取得Python 3.9的基礎映像。如果本地沒有這個映像，Docker會下載它的所有層。

STEP 2: ENV PORT 8080
STEP 3: EXPOSE 8080
STEP 4: WORKDIR /usr/src/app

這些步驟設定了容器的環境變數、暴露的埠口以及工作目錄。每一步都會建立一個新的映像層，但這些層通常很小。

STEP 5: COPY requirements.txt ./
STEP 6: RUN pip install --no-cache-dir -r requirements.txt

這兩步驟將依賴項清單複製到容器中，然後安裝所有所需的Python套件。特別是RUN指令會產生較大的映像層，因為它包含了所有安裝的套件。

STEP 7: COPY . .
STEP 8: ENTRYPOINT ["python"]
STEP 9: CMD ["app.py"]

最後的步驟複製應用程式碼，設定進入點和預設命令。這些定義了容器啟動時的行為。

管理與使用Docker映像

一旦映像建構完成，你可以使用以下命令檢視本地映像：

docker images

這會列出所有本地可用的容器映像，包括你剛建構的映像。

若要推播映像到公共倉函式庫需要先登入：

docker login quay.io

登入成功後，即可推播映像：

docker push quay.io/gitops-cookbook/pythonapp:latest

推播過程會將每一層上載到容器倉函式庫果倉函式庫有某些層（例如基礎映像層），則只會上載新的或修改過的層。

執行Docker容器

要執行容器，使用以下命令：

docker run -p 8080:8080 -ti quay.io/gitops-cookbook/pythonapp:latest

這個命令有幾個重要選項：

• -p 8080:8080：將容器內的8080埠對映到主機的8080埠
• -t：分配一個終端（TTY）
• -i：啟用互動模式
• -d：（如使用）在背景執行容器

docker run命令實際上做了幾件事：

1. 從指定的映像建立一個新的容器例項
2. 分配檔案系統和網路介面
3. 設定主機名
4. 執行在映像中指定的命令
5. 透過埠口對映使容器內的服務可從主機存取

一旦容器執行，你可以透過連線埠測試應用：

curl http://localhost:8080

如果一切正常，你應該會收到應用的回應，例如：Hello, World!

無Docker解決方案：使用Jib建構容器

為何選擇無Docker解決方案

雖然Docker非常流行與功能強大，但它也有一些限制：

1. 需要在系統上安裝Docker引擎
2. Docker daemon需要root許可權執行
3. 需要撰寫和維護Dockerfile
4. 在某些環境中可能受到安全政策限制

這些因素促使了無Docker建構工具的發展，其中Jib是Java生態系統中最受歡迎的解決方案之一。

Jib簡介

Jib是Google開發的開放原始碼工具，專為Java應用程式設計，可以建構OCI標準相容的容器映像，而無需安裝Docker或任何容器執行時。它可以直接整合到Maven或Gradle專案中，無需編寫Dockerfile。

Jib提供了三個主要優勢：

1. 純Java體驗：無需Docker或Dockerfile知識，只要增加Jib作為外掛即可
2. 速度最佳化：將應用程式分為多個層，分離依賴項和類別，只更新有變更的層
3. 可重現性：相同內容始終生成相同的映像，避免不必要的更新

使用Maven整合Jib

最簡單的方法是透過命令列增加Jib外掛：

mvn compile com.google.cloud.tools:jib-maven-plugin:3.2.0:build -Dimage=<MY IMAGE>

或者，你可以在pom.xml中增加Jib作為外掛：

<project>
  ...
  <build>
    <plugins>
      ...
      <plugin>
        <groupId>com.google.cloud.tools</groupId>
        <artifactId>jib-maven-plugin</artifactId>
        <version>3.2.0</version>
        <configuration>
          <to>
            <image>myimage</image>
          </to>
        </configuration>
      </plugin>
      ...
    </plugins>
  </build>
  ...
</project>

這個XML設定義了Jib外掛的基本設定：

• groupId和artifactId指定了外掛的坐標
• version確定使用的Jib版本
• configuration區塊包含映像目標位置等外掛設定
• to/image指定了映像的名稱和標籤

實際使用Jib建構映像

下面是將Spring Boot應用程式建構為容器映像並推播到Quay.io的完整命令：

mvn compile com.google.cloud.tools:jib-maven-plugin:3.2.0:build \
-Dimage=quay.io/gitops-cookbook/jib-example:latest \
-Djib.to.auth.username=<USERNAME> \
-Djib.to.auth.password=<PASSWORD>

這個命令執行了以下操作：

1. 編譯Java程式碼
2. 透過Jib外掛建構容器映像
3. 使用提供的憑證直接推播映像到Quay.io容器倉函式庫. 映像標記為quay.io/gitops-cookbook/jib-example:latest

Jib會自動處理：

• 建立適當的容器映像層
• 分離應用程式依賴項和類別檔案到不同層
• 設定適當的入口點
• 直接推播到遠端倉函式庫### Jib與Docker的比較分析

在實際專案中，選擇Jib還是Docker取決於多種因素。以下是我對兩種方法的比較分析：

容器映像建構的最佳實踐

無論使用Docker還是Jib，以下最佳實踐都能幫助你建構更高效、更安全的容器映像：

1. 最小化映像大小

較小的映像不僅下載更快，而與攻擊面也更小：

• 使用輕量級基礎映像（如Alpine或distroless）
• 移除不必要的依賴項和工具
• 利用多階段建構減少最終映像大小
• 在一個RUN指令中合併多個命令，減少層數

2. 最佳化層次結構

理解並最佳化層次結構可以顯著提高建構和佈署效率：

• 將較少變更的內容（如依賴項）放在較早的層
• 將頻繁變更的內容（如應用程式碼）放在較後的層
• 避免在層中包含臨時檔案或日誌

3. 確保安全性

安全性是容器化過程中的關鍵考量：

• 使用特定版本標籤而非latest標籤
• 實施映像掃描，檢測漏洞
• 避免在映像中包含敏感資訊
• 以非root使用者執行應用程式

4. CI/CD整合

將容器建構整合到CI/CD流程中：

• 在每次程式碼提交後自動建構映像
• 實施自動化測試驗證映像
• 使用適當的標籤策略（如git commit hash或語意化版本）
• 考慮使用容器倉函式庫的自動建構功能

容器倉函式庫的利用

除了本地建構映像外，許多公共容器倉函式庫uay.io也提供了直接從Dockerfile建構映像的功能。這些功能可以：

• 減輕本地機器的建構負擔
• 提供一致的建構環境
• 自動觸發建構（如當程式碼倉函式庫時）
• 整合安全掃描和漏洞檢測

利用這些功能可以進一步簡化容器映像的建構和管理流程，特別是在團隊環境中。

容器映像的分層原理與效率

容器映像的分層結構是其核心優勢之一。當我分析容器建構過程時，發現這種分層機制提供了三個關鍵優勢：

1. 增量更新：只有變更的層需要重新建構和推播，大幅減少了建構和佈署時間。
2. 快取分享：相同的層可以在不同映像間分享，節省儲存空間和網路傳輸。
3. 平行下載：多層可以平行下載，加快映像提取速度。

在實踐中，我發現合理規劃層次結構可以將應用程式更新時間從分鐘級降到秒級，特別是在頻繁佈署的環境中。

容器建構過程是容器化工作流程的根本。無論選擇傳統的Docker方式還是無Docker的Jib解決方案，理解映像的分層結構和最佳實踐都能幫助開發團隊建立更高效、更安全的容器化應用程式。隨著容器技術的不斷演

無需Docker也能構建容器：Jib與Buildah實戰

現代容器化開發環境中，Docker已成為標準工具。然而，在特定場景下，安裝或管理Docker可能面臨各種限制。幸運的是，開放原始碼社群提供了多種替代方案，讓我們能在無Docker環境中依然可以高效構建容器映像。今天，我將探討兩個強大的無Docker容器構建工具：Google的Jib與Red Hat的Buildah。

容器構建的新選擇：為什麼需要無Docker方案？

在我多年的容器化實踐中，發現以下場景特別需要無Docker的容器構建方案：

1. CI/CD自動化環境中，避免安裝Docker daemon可減少安全風險
2. 在受限環境下開發，如企業內部禁止安裝Docker
3. 需要更高效率的構建流程，尤其是Java應用程式
4. 希望減少對單一廠商工具的依賴

Jib：Java應用的容器化利器

Jib的工作原理與核心優勢

Jib是Google開發的開放原始碼工具，專為Java應用容器化設計。它的核心優勢在於能夠將Java應用直接封裝成容器映像，而無需安裝Docker、編寫Dockerfile或瞭解容器構建最佳實踐。

在技術實作上，Jib將容器構建過程分解為多個步驟：

1. 分析應用程式依賴並將它們分層
2. 僅重建有變更的層，大幅提高構建速度
3. 直接與容器登入檔通訊，無需本地Docker daemon

使用Jib構建Java容器映像的實際效果

當使用Jib構建容器映像時，整個過程非常流暢。以下是一個實際的構建輸出範例：

[INFO] Scanning for projects...
[INFO]
[INFO] --------------------------< com.redhat:hello >--------------------------
[INFO] Building hello 0.0.1-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
...
[INFO] Containerizing application to quay.io/gitops-cookbook/jib-example...
[INFO] Using credentials from <to><auth> for quay.io/gitops-cookbook/jib-example
[INFO] The base image requires auth. Trying again for eclipse-temurin:11-jre...
[INFO] Using base image with digest:
sha256:83d92ee225e443580cc3685ef9574582761cf975abc53850c2bc44ec47d7d943O]
[INFO]
[INFO] Container entrypoint set to [java, -cp, @/app/jib-classpath-file,
com.redhat.hello.HelloApplication]FO]
[INFO]
[INFO] Built and pushed image as quay.io/gitops-cookbook/jib-example
[INFO] Executing tasks:
[INFO] [==============================] 100,0% complete
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 41.366 s
[INFO] Finished at: 2022-01-25T19:04:09+01:00
[INFO] ------------------------------------------------------------------------

構建過程中，Jib執行了以下核心步驟：

1. 掃描並分析專案依賴
2. 指定容器映像目標位置為quay.io/gitops-cookbook/jib-example
3. 使用設定的認證資訊進行身份驗證
4. 選擇eclipse-temurin:11-jre作為基礎映像
5. 設定容器的入口點為Java應用程式的主類別
6. 構建並推播映像到指定的容器登入檔

Jib的獨特之處：本地無映像

使用Jib的一個有趣特點是，當構建完成後，如果執行docker images指令，你不會在本地快取中看到這個映像！這是因為Jib完全繞過了Docker daemon，直接將映像推播到容器登入檔。

這種設計對CI/CD系統特別有價值，因為：

1. CI節點不需要安裝Docker
2. 不需要Dockerfile即可建立標準OCI格式映像
3. 構建過程更快與更安全（沒有特權daemon）

實際測試Jib構建的容器

讓我們從登入檔提取並執行剛才構建的映像：

docker run -p 8080:8080 -ti quay.io/gitops-cookbook/jib-example

執行後的輸出：

Trying to pull quay.io/gitops-cookbook/jib-example:latest...
Getting image source signatures
Copying blob ea362f368469 done
Copying blob d5cc550bb6a0 done
Copying blob bcc17963ea24 done
Copying blob 9b46d5d971fa done
Copying blob 51f4f7c353f0 done
Copying blob 43b2cdfa19bb done
Copying blob fd142634d578 done
Copying blob 78c393914c97 done
Copying config 346462b8d3 done
Writing manifest to image destination
Storing signatures
. ____ _ __ _ _
/\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
\\/ ___)| |_)| | | | | || (_| | ) ) ) )
' |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
:: Spring Boot :: (v2.6.3)
2022-01-25 18:36:24.762 INFO 1 --- [ main] com.redhat.hello.HelloApplication
: Starting HelloApplication using Java 11.0.13 on a719cf76f440 with PID 1
(/app/classes started by root in /)
2022-01-25 18:36:24.765 INFO 1 --- [ main] com.redhat.hello.HelloApplication
: No active profile set, falling back to default profiles: default
2022-01-25 18:36:25.700 INFO 1 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer
: Tomcat initialized with port(s): 8080 (http)
2022-01-25 18:36:25.713 INFO 1 --- [ main] o.apache.catalina.core.StandardService
: Starting service [Tomcat]
2022-01-25 18:36:25.713 INFO 1 --- [ main] org.apache.catalina.core.StandardEngine
: Starting Servlet engine: [Apache Tomcat/9.0.56]
2022-01-25 18:36:25.781 INFO 1 --- [ main] o.a.c.c.C.[Tomcat].[localhost].[/]
: Initializing Spring embedded WebApplicationContext
2022-01-25 18:36:25.781 INFO 1 --- [ main]
w.s.c.ServletWebServerApplicationContext
: Root WebApplicationContext: initialization completed in 947 ms
2022-01-25 18:36:26.087 INFO 1 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer
: Tomcat started on port(s): 8080 (http) with context path ''
2022-01-25 18:36:26.096 INFO 1 --- [ main] com.redhat.hello.HelloApplication
: Started HelloApplication in 1.778 seconds (JVM running for 2.177)

測試應用程式的端點：

curl localhost:8080/hello
{"id":1,"content":"Hello, World!"}

Jib構建的容器映像執行正常，證明瞭無需Docker也能有效構建並佈署容器應用。

Buildah：更靈活的容器構建方案

開放容器標準與模組化工具鏈

OCI（Open Container Initiative）規範是一個開放標準，促進了多種開放原始碼容器實作的發展。在Red Hat主導的工具生態系統中，容器相關功能被分割為不同的專用工具：

• Podman：執行和管理容器
• Buildah：專注於構建容器映像
• Skopeo：容器映像的傳輸與管理

這種模組化設計與Docker的單體架構形成鮮明對比，每個工具專注於特定功能，提供了更好的安全性和靈活性。

Buildah的設計理念

Buildah與Docker的主要區別在於：

1. 無守護程式設計：不需要持續執行的daemon
2. 輕量級：最小化資源使用
3. 無需root許可權：支援無特權容器構建
4. 靈活API：支援Dockerfile但不限於此

這種設計使Buildah特別適合CI/CD環境，可以在不安裝Docker的Linux節點上輕鬆增加容器構建功能。

使用Buildah構建容器映像

Buildah支援兩種構建方式：使用Dockerfile或透過命令直接構建。讓我們看如何不使用Dockerfile來建立一個簡單的HTTPD容器映像。

首先，從基礎映像開始：

buildah from centos

輸出結果：

Resolved short name "centos" to a recorded short-name alias
(origin: /etc/containers/registries.conf.d/shortnames.conf)
Getting image source signatures
Copying blob 926a85fb4806 done
Copying config 2f3766df23 done
Writing manifest to image destination
Storing signatures
centos-working-container

這裡，centos-working-container是容器映像ID，我們將用它來建立其他層。

接下來，安裝HTTPD套件：

buildah run centos-working-container yum install httpd -y

執行結果：

CentOS Linux 8 - AppStream 9.0 MB/s | 8.4 MB 00:00
CentOS Linux 8 - BaseOS 436 kB/s | 4.6 MB 00:10
CentOS Linux 8 - Extras 23 kB/s | 10 kB 00:00
Dependencies resolved.
===============================================================================
Package Arch Version Repository Size
===============================================================================
Installing:
httpd x86_64 2.4.37-43.module_el8.5.0+1022+b541f3b1
Installing dependencies:
apr x86_64 1.6.3-12.el8
apr-util x86_64 1.6.1-6.el8
brotli x86_64 1.0.6-3.el8
centos-logos-httpd noarch 85.8-2.el8

httpd-filesystem noarch 2.4.37-43.module_el8.5.0+1022+b541f3b1
httpd-tools x86_64 2.4.37-43.module_el8.5.0+1022+b541f3b1
mailcap noarch 2.1.48-3.el8
mod_http2 x86_64 1.15.7-3.module_el8.4.0+778+c970deab
Installing weak dependencies:
apr-util-bdb x86_64 1.6.1-6.el8
apr-util-openssl x86_64 1.6.1-6.el8
Enabling module streams:

這個過程展示了Buildah如何透過命令式方法逐步構建容器：

1. buildah from centos - 從CentOS基礎映像建立工作容器
2. buildah run centos-working-container yum install httpd -y - 在工作容器中執行命令安裝HTTP伺服器

與Dockerfile的宣告式方法不同，Buildah允許我們以更靈活的方式構建容器層，就像在一般Linux系統上安裝軟體一樣直觀。

Buildah的進階操作

在實際使用中，Buildah還提供了許多進階功能：

1. 設定容器屬性：

   buildah config --port 80 centos-working-container
   

2. 增加自定義檔案：

   buildah copy centos-working-container ./index.html /var/www/html/
   

3. 設定啟動命令：

   buildah config --cmd "/usr/sbin/httpd -DFOREGROUND" centos-working-container
   

4. 提交映像：

   buildah commit centos-working-container my-httpd-image
   

5. 推播到登入檔：

   buildah push my-httpd-image docker://quay.io/myuser/my-httpd:latest
   

兩種方案的比較與選擇

在實際專案中，如何選擇Jib和Buildah？根據我的經驗，有這些考量因素：

Jib適合的場景

1. Java應用開發團隊：無需學習容器知識
2. 追求構建速度：增量構建非常快
3. Maven/Gradle工作流程：無縫整合現有構建流程
4. 跨平台需求：支援Windows、Mac和Linux

Buildah適合的場景

1. 需要精細控制：對容器構建過程有特殊需求
2. 多語言環境：不限於Java應用
3. Linux環境：目前主要支援Linux系統
4. 指令碼化自動化：適合Shell指令碼整合

無Docker容器構建的最佳實踐

根據在多個專案中的實踐，我總結了一些無Docker容器構建的最佳實踐：

容器映像製作的進階之路：超越Docker的選擇

在容器技術快速發展的今天，Docker雖然仍是主流，但並非唯一選擇。作為一位長期在容器技術領域鑽研的開發者，我發現許多團隊正在尋找更靈活、更安全的容器映像建置方案。本文將探討兩個強大的工具：Buildah與Buildpacks，它們各自解決了容器建置過程中的不同痛點。

Buildah：安全與靈活的容器映像建置工具

Buildah以其無守護程式設計和強大的安全特性，成為許多企業級環境的首選。不同於Docker需要執行守護程式，Buildah採用了更加輕量級的設計模式，同時提供了更精細的映像層控制能力。

Buildpacks：無Dockerfile自動化構建的革新

另一方面，Cloud Native Buildpacks則徹底改變了我們思考容器構建的方式。透過自動檢測應用程式原始碼並選擇合適的構建策略，它讓開發者能夠專注於應用邏輯而非容器化細節。

這兩種工具代表了容器技術發展的不同方向，讓我們深入瞭解如何有效地使用它們。