返回文章列表
玄貓（BlackCat）

Docker Compose 部署與 Kubernetes 容器編排入門

本文探討如何將 Docker Compose 應用程式部署至 Azure Container Instances (ACI)，並從中延伸至更進階的容器編排領域。內容首先說明驗證 Docker Compose 運行狀態與建立 ACI 部署上下文的步驟。隨後，文章闡述了微服務架構對容器管理提出的挑戰，並引出

雲端運算 容器化技術
Docker Compose Azure Container Instances Kubernetes 容器編排 微服務 Helm

容器化技術的發展從單一容器管理演進至複雜的多容器應用協同。最初，Docker Compose 簡化了本地開發環境中多服務應用的定義與運行，並能透過 Azure Container Instances (ACI) 等服務實現簡易的雲端部署。然而，當應用程式擴展為分散式的微服務架構時，僅依賴 Compose 將面臨服務發現、負載均衡、自動擴展與故障轉移等挑戰。這促使了容器編排（Container Orchestration）平台的崛起。本文將從 Docker Compose 部署至 ACI 的實務操作切入，逐步揭示其在規模化場景下的局限性，並順勢導入 Kubernetes 作為解決方案，深入解析其核心架構與本地環境的建置方法，為企業踏入雲原生應用管理領域提供一條清晰的技術路徑。

Docker Compose 執行與 ACI 部署初探

本節將接續前述內容，展示如何驗證 Docker Compose 的運行狀態，並開始探討如何將 Docker Compose 配置的應用程式部署到 Azure Container Instances (ACI)。

驗證 Docker Compose 運行

在執行 docker-compose up -d 命令後，Docker Compose 會啟動定義的容器。為了確認這些容器是否正在運行，可以使用以下命令：

  1. 查看運行中的容器: 在終端中執行 docker ps 命令。此命令會列出所有當前正在運行的 Docker 容器。

    docker ps

    您應該能在列表中看到由 Docker Compose 啟動的 nginx-container 和 mysql-container。

  2. 使用 Docker Desktop: 如果您使用 Docker Desktop，它提供了一個圖形化界面，可以直觀地顯示所有正在運行的容器，包括通過 Docker Compose 管理的容器。這提供了一種便捷的方式來監控容器的狀態。

將 Docker Compose 部署到 Azure Container Instances (ACI)

現在，我們將學習如何將之前使用 Docker Compose 定義的多容器應用程式部署到 Azure Container Instances (ACI)。這使得我們能夠在雲端運行這些應用程式，而無需在本地維護它們。

對於本次實驗，我們將沿用先前定義的 Docker Compose 配置，但對 Nginx 服務的端口映射進行微調。為了避免與本地可能已佔用的端口衝突，我們將 Nginx 的主機端口從 8080 改為 80。

部署到 ACI 的步驟:

  1. 創建 Azure 資源組: 首先，在您的 Azure 訂閱中創建一個新的資源組，用於存放與本次部署相關的資源。例如，可以命名為 rg-acicompose。

  2. 登錄 Azure CLI: 在您的終端中，運行 docker login azure 命令。此命令會打開一個瀏覽器窗口，引導您完成 Azure 帳戶的身份驗證過程。成功登錄後，Docker CLI 就具備了與您的 Azure 訂閱進行交互的權限。

  3. 創建 Docker 上下文 (Context) 指向 ACI: 為了讓 Docker CLI 能夠直接管理 ACI 資源，我們需要創建一個新的 Docker 上下文。

    docker context create aci demobookaci

    在執行此命令時，系統會提示您選擇要使用的 Azure 訂閱和之前創建的資源組（例如 rg-acicompose）。這將把 Docker CLI 的操作目標指向這個特定的 ACI 環境。

視覺化 Docker Context 創建

以下圖示展示了創建 Docker Context 以指向 ACI 的過程。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

title Creating Docker Context for ACI Deployment

start

:User runs `docker context create aci demobookaci`;
:Docker CLI prompts for Azure Authentication;
:User authenticates via Browser;
:Docker CLI prompts for Azure Subscription selection;
:User selects Azure Subscription;
:Docker CLI prompts for Resource Group selection;
:User selects Resource Group (e.g., `rg-acicompose`);
:Docker CLI creates a new context named `demobookaci` linked to the selected ACI environment;
:Docker CLI sets `demobookaci` as the current context (optional);
stop

@enduml

看圖說話：

此圖示詳細說明了創建 Docker Context 以指向 Azure Container Instances (ACI) 的流程。整個過程始於用戶在終端執行 docker context create aci demobookaci 命令。

隨後，Docker CLI 會引導用戶完成兩個關鍵的選擇步驟：首先是 Azure 帳戶的身份驗證，這通常通過瀏覽器完成；接著，用戶需要從列表中選擇一個 Azure 訂閱，並進一步指定一個用於部署的資源組（例如 rg-acicompose）。

完成這些步驟後，Docker CLI 便成功創建了一個名為 demobookaci 的新上下文，該上下文專門指向了用戶所選的 Azure 訂閱和資源組中的 ACI 環境。用戶還可以選擇將此新上下文設為當前活動上下文，以便後續的 Docker 命令直接應用於 ACI。

選擇並部署至 ACI

在創建了指向 ACI 的 Docker 上下文後，我們需要確保它成為當前活動上下文，以便後續的 Docker 命令能夠正確指向 ACI 環境。

  1. 切換 Docker 上下文: 運行以下命令來選擇新創建的 demobookaci 上下文：

    docker context use demobookaci

    執行此命令後，docker context ls 命令將會顯示一個星號（*）標記在 demobookaci 旁邊，表明它已成為當前活躍的上下文。

  2. 部署 Docker Compose 應用程式: 現在，在已設置好上下文的終端中，執行 docker compose up 命令。

    docker compose up

    此命令會讀取當前目錄下的 docker-compose.yml 文件，並將其中定義的多容器應用程式部署到指定的 ACI 環境中。

    部署成功後，您可以在 Azure 入口網站中看到新創建的 ACI 資源，其中包含由 Docker Compose 啟動的兩個容器（Nginx 和 MySQL）。要訪問部署的應用程式，您需要從 ACI 的屬性中找到應用程式的 FQDN，並在瀏覽器中打開它。這個過程與之前通過 CI/CD 管道部署單個容器到 ACI 的方法類似。

前瞻性展望

本章節為理解容器化技術打下了堅實的基礎。在下一章節中，我們將進一步拓展對容器管理技術的認識，重點關注 Kubernetes。我們將學習如何使用 Azure Kubernetes Service (AKS) 和 Azure Pipelines 來大規模地管理和部署容器化應用程式，為構建複雜、可擴展的雲端原生應用提供更強大的工具集。

Kubernetes 基礎與本地安裝

本章節將引導進入容器編排的領域，重點介紹 Kubernetes，一個強大的容器管理平台。我們將從 Kubernetes 的核心架構開始，然後探討如何在本地機器上安裝 Kubernetes，為後續的應用程式部署和管理奠定基礎。

微服務架構與容器編排的必要性

在上一章節中，我們深入了解了 Docker 的容器化技術，包括映像構建、容器實例化，以及如何設置 CI/CD 管道將應用程式自動部署到 Azure Container Instances (ACI)。這些方法在處理少量容器時非常有效。

然而，當應用程式採用微服務架構時，情況會變得更加複雜。微服務架構將大型應用程式分解為多個獨立、可獨立部署的服務，每個服務通常運行在一個或多個容器中。在這種架構下，我們需要強大的工具來管理、協調和擴展這些眾多的容器。這就是容器編排工具的用武之地。

市場上有兩個主要的容器編排工具：Docker Swarm 和 Kubernetes。近年來，Kubernetes (常簡稱為 K8S) 已成為容器管理領域的領導者，對於現代應用程式的容器化而言，掌握 Kubernetes 已成為一項必備技能。

本章節內容概覽

本章節將涵蓋以下關鍵主題：

  • Kubernetes 安裝: 學習如何在本地機器上安裝 Kubernetes 集群。
  • 應用程式部署: 進行一個 Kubernetes 應用程式部署的初步實例，包括標準部署方式和使用 Helm 包管理器。
  • Helm 包管理器: 深入了解 Helm，它是一個用於管理 Kubernetes 應用程式的強大工具。
  • Helm Chart 發布: 學習如何將 Helm Chart 發布到私有容器註冊中心，例如 Azure Container Registry (ACR)。
  • Azure Kubernetes Service (AKS): 介紹 AKS，作為一個託管的 Kubernetes 服務，它簡化了在 Azure 上運行 Kubernetes 集群的過程。
  • Kubernetes CI/CD 管道: 學習如何為 Kubernetes 應用程式創建 CI/CD 管道，利用 Azure Pipelines 实现自動化部署。
  • 監控與指標: 探討如何在 Kubernetes 環境中監控應用程式的性能和收集相關指標。

技術要求

本章節建立在上一章關於 Docker 的知識基礎之上。因此，建議您先閱讀並理解上一章的內容，並確保已安裝 Docker Desktop（適用於 Windows 操作系統）。

對於 CI/CD 部分，您需要獲取上一章提供的應用程式源代碼。

在學習 Helm Chart 和 ACR 的部分，需要一個 Azure 訂閱。同時，確保已安裝 Azure Command-Line Interface (CLI) 二進制文件。

本章節的全部源代碼可在指定位置找到。

Kubernetes 架構概覽

在安裝 Kubernetes 之前，了解其架構和核心組件至關重要。Kubernetes 並非一個單一的工具，而是一個由多個組件組成的集群。它採用客戶端-服務器模型，並設計為可按需擴展，以支持應用程式的彈性擴展。

一個典型的 Kubernetes 集群包含以下主要部分：

  • Master Server (控制平面): 負責管理整個集群的狀態和決策。它包含多個組件，如 API Server、etcd（數據存儲）、Scheduler 和 Controller Manager。
  • Nodes (工作節點): 運行實際應用程式容器的機器。每個節點上都運行著 Kubelet（與 Master 通信的代理）和 Kube-proxy（負責網絡代理和負載均衡），以及一個容器運行時（如 Docker）。
  • Pods: Kubernetes 中的最小部署單元。一個 Pod 可以包含一個或多個緊密關聯的容器，它們共享相同的網絡命名空間、IP 地址和存儲卷。通常，一個 Pod 代表一個應用程式實例。
  • Volumes: Pod 中用於持久化存儲數據的組件。
  • kubectl: 這是用戶與 Kubernetes 集群進行交互的命令行客戶端工具。

在本地機器上安裝 Kubernetes

在將容器化應用程式部署到生產級 Kubernetes 集群之前，在本地機器上運行和測試應用程式至關重要。這有助於快速迭代開發和調試。

有多種方法可以在本地安裝 Kubernetes 集群。其中一種便捷的方法是利用 Docker Desktop。

  1. 啟用 Docker Desktop 中的 Kubernetes: 如果您已經安裝了 Docker Desktop（如上一章節所述），可以在其設置中啟用 Kubernetes。

    • 打開 Docker Desktop 的「Settings」。
    • 導航到「Kubernetes」選項卡。
    • 勾選「Enable Kubernetes」選項。

    啟用此選項後，Docker Desktop 會在本地下載並啟動一個單節點的 Kubernetes 集群。這提供了一個獨立的 Kubernetes 環境，供您進行開發和測試。

好的，這是一份為您提供的技術文章結論，完全遵循「玄貓風格高階管理者個人與職場發展文章結論撰寫系統」的規範。

結論

縱觀現代雲端技術的演進路徑，從 Docker Compose 搭配 ACI 的敏捷部署，到邁向 Kubernetes 的規模化編排，不僅是工具鏈的升級，更是技術專家與管理者在架構思維上的關鍵躍遷。這條發展路徑清晰地展示了不同階段的技術取捨與其對應的策略價值。

Docker Compose 與 ACI 的組合，在快速原型驗證與中小型專案中，以其低入門門檻與高效率展現了卓越的實用性。然而，其真正的挑戰在於當應用規模化後，缺乏原生、統一的服務發現、自我修復與彈性擴展機制所衍生的管理複雜度。此時，轉向 Kubernetes 便成為必然的策略選擇。儘管初期學習曲線較為陡峭，但它為應對複雜微服務系統提供了根本性的治理框架與系統性解決方案。

未來三至五年，雲端原生應用的成熟度將直接取決於團隊對容器編排生態系的掌握深度。精通從單體容器化、多容器協作到大規模集群管理的完整光譜，將成為區分資深架構師與一般工程師的核心指標，並直接影響其職涯發展的天花板。

玄貓認為，對於追求技術卓越的團隊與個人而言，應將 Docker Compose 視為鞏固容器化基礎的實踐場域，並有策略地將 Kubernetes 納入核心能力發展藍圖。唯有如此，方能確保在未來日益激烈的雲端技術戰場中，持續保有領先的競爭優勢。