AWS | Task 、Task Definition 是什麼？如何啟動與監控一個 ECS 任務？

Facebook LinkedIn Tweet

更新日期： 2025 年 6 月 17 日

在 AWS ECS（Elastic Container Service）中，真正讓你的應用程式啟動並執行的核心單位就是 Task（任務）。

可以這樣理解：當你已經完成應用程式的撰寫、用 Docker 打包好映像檔（Image），甚至上傳到 ECR 或 Docker Hub 之後，這些都只是「準備工作」——但它們還沒真正「跑起來」。

這時，你需要一個機制來告訴 ECS：「我要用這個映像檔啟動一個實例，給它分配資源、設置環境變數、指定網路與執行條件，然後實際讓它運作」。

這個機制，就是透過定義一份 Task Definition，並以此為模板，啟動一個 Task。

你可以將 Task 想像成：

「把應用程式裝進容器裡，然後在雲端指定的地方打開這個容器，開始執行它的工作。」

每一個 Task 都是你應用邏輯的實體執行者，無論是 Web 伺服器、資料處理批次作業、排程任務、還是一次性的測試流程，這些應用程式的「執行實體」都會以 Task 的形式出現在 ECS 裡。

簡單來說：

映像檔（Image） 是靜態的、不能動的應用包裝
Task 則是那個應用「被打開並運行起來」的狀態
每次你啟動一個 Task，就像是「打開一個容器，讓程式開始工作」

這就是為什麼，我們說 Task 是 ECS 中真正負責執行應用程式的核心角色。

一切的部署與運行，最終都會落到 Task 上來完成。

Task 是 ECS 裡真正「執行中」的工作單位

在 ECS 中，Task 是根據 Task Definition 建立的實例，就像是照著食譜做出的一道料理。

每當你啟動一個 Task，就是在運行一個或多個 container，並處理你的應用邏輯。

graph BT
    TD[📋 Task Definition<br/>定義容器規格]

    subgraph Cluster["🖥️ Cluster"]
        subgraph Service["📋 Service"]
            Task1["📦 Task<br/>包含多個容器"]
            Task2["📦 Task<br/>包含多個容器"]
            Task3["📦 Task<br/>包含多個容器"]
        end
    end

    TD -->|建立| Task1
    TD -->|建立| Task2
    TD -->|建立| Task3

    style TD fill:#FF9900,color:#fff
    style Cluster fill:#4A5568,stroke:#FF9900,stroke-width:3px,color:#fff
    style Service fill:#2D3748,stroke:#FF9900,stroke-width:2px,color:#fff
    style Task1 fill:#1A202C,stroke:#48BB78,stroke-width:2px,color:#fff
    style Task2 fill:#1A202C,stroke:#48BB78,stroke-width:2px,color:#fff
    style Task3 fill:#1A202C,stroke:#48BB78,stroke-width:2px,color:#fff

Task 是由 Task Definition 派生出來的實例

在 AWS ECS 中，一個 Task 並不是隨意建立的，而是根據事先定義好的設定檔 —— Task Definition 所產生的實例。

你可以把這個概念類比成「食譜與料理」：

Task Definition 是完整的食譜，包含要用哪些食材（容器）、煮幾分鐘（資源限制）、加哪些調味料（環境變數）等設定。
Task 則是照著這份食譜實際煮出來的料理，是具體可執行的結果。

讓我們再結合下圖來說明 ECS 架構中各角色的關係：

從圖中你可以看到：

Task Definition 是設定檔：描述了容器組合、CPU/記憶體資源、網路模式、啟動類型等。
Task 是由這個設定檔衍生出來的實體：每當你執行一次任務，ECS 就會依據這份設定「實體化」出一組容器，這組容器會共同構成一個 Task。
Service 是一種控制器：它可以持續讓多個 Task 同時啟動與維運，確保應用程式不會因為某個 Task 掛掉就中斷（會自動補上新的）。
Cluster 是運行環境的集合：可以視為 Task 與 Service 所依賴的資源池，裡面包含主機（EC2 或 Fargate 資源）、網路設定、安全群組等。

一個 Task 裡面不一定只有一個容器

很多初學者會以為一個 Task 就是一個容器，但事實上：

一個 Task 可以包含多個 container，這些 container 會被當作一個組合「一起部署、一起啟動、一起終止」。

這種設計非常適合 sidecar 模式，例如：

一個主要的 web 應用 container
搭配一個負責 log 收集或 metrics 傳送的 sidecar container

這兩個 container 可以透過 localhost 溝通，並共享 Task 的 CPU、記憶體、網路資源。

Task 是怎麼定義的？—— Task Definition 結構一覽

在 AWS ECS 中，你無法直接「隨便」啟動一個 Task。

你必須事先定義好一份 Task Definition，這就像是一份完整的藍圖，列出 ECS 要如何部署並啟動這個任務。

換句話說，Task Definition 是你在 AWS 中描述一個容器應用該怎麼跑的設定檔，它會詳細記錄：

☑ 要跑什麼映像檔？
☑ 要配置多少 CPU 和記憶體？
☑ 容器彼此如何溝通？
☑ 任務要跑在什麼樣的基礎設施上？
☑ 使用什麼樣的網路模式與日誌設定？

Task Definition 欄位說明

Containers

一份 Task Definition 可以定義一個或多個容器（Container），這些容器會在 Task 啟動時同時被部署並啟動。

每個 container 都可以有自己的 image、環境變數、port 設定與掛載的 volume。

這讓你可以使用 sidecar 模式（如主程式 + log agent），把多個功能拆分到不同容器中執行，維護更彈性。

CPU / Memory

在定義中你可以指定這個 Task 總共可以使用的 vCPU 與記憶體資源，這決定 ECS 調度這個任務時會分配多少系統資源。

若使用 AWS Fargate，CPU/記憶體的配置會影響計費；若使用 EC2，則會影響資源可用性與限制。

Launch Type

這是你選擇要在哪一種基礎設施上執行你的 Task，有兩種主要選項：

EC2：自己管理 VM 群組，彈性高但需維運
Fargate：AWS 幫你管理底層主機，無伺服器模式，維運量低，適合快速部署與 scale

Network Mode

網路模式會決定容器之間怎麼通訊，以及是否會分配獨立 IP。主要選項包括：

awsvpc（推薦）：每個 Task 都分配一個 ENI（彈性網路介面），可直接使用 VPC 網路，像 EC2 一樣安全控管。
bridge：適用於 EC2 的預設模式，容器共用 host 的網路橋接
host：容器直接共用主機的 port，效能好但易產生衝突
none：完全無網路
default：根據你使用的啟動類型自動套用（通常是 awsvpc 或 bridge）

為什麼 Task Definition 如此關鍵？

因為 ECS 是基於這份設定檔來：

分派資源（CPU/記憶體）
調度容器執行
決定容器間的相對位置與通信方式
控制應用在雲端的安全性與可觀測性（透過 log 設定與網路模式）

只要建立好一份 Task Definition，你就可以隨時啟動任意數量的 Task，甚至交給 ECS Service 自動擴展。

這讓 Task Definition 不只是設定檔，更是一個可複製、可版本化的部署單元。

補充：Task Definition 還能設定什麼？

除了上述 4 個核心欄位，一份完整的 Task Definition 通常還包含：

環境變數（environment variables）
掛載資料卷（volumes & mountPoints）
log 設定（如 awslogs、FireLens）
port mappings（例如 container port 80 對應 host port）
command / entryPoint
health check 規則
IAM role 權限

這些細節會影響容器啟動行為、安全性、與外界互動方式。透過版本控制（revision），你可以持續優化並追蹤不同任務配置之間的變化。

如何啟動一個 ECS Task？

當你準備好一份 Task Definition 後，接下來的動作就是啟動一個 Task。

這代表：AWS 將會根據你的藍圖設定，實際建立一組容器並啟動執行。

整個過程就像「照著食譜做出一道菜」那樣簡單。

啟動 Task 有兩種常見方式：

使用圖形化介面（AWS Console）操作，適合手動測試與學習
使用 CLI（命令列）或程式碼自動啟動，適合自動化部署與 CI/CD

使用 AWS Console 手動啟動 Task（適合入門者）

這種方式是最直觀的方式，可以一步一步選擇設定：

登入 AWS 管理控制台（Console），進入「ECS」服務頁面。
選擇一個已存在的 Cluster，或事先建立一個新的 Cluster。
點選右上角「Run new task」按鈕開始建立任務。
接下來你需要選擇幾個關鍵設定：

Task Definition：選擇你剛才建立的 Task Definition 名稱與版本（例如 my-task:1）
Launch type：選擇你要在哪種平台上執行這個任務：
- FARGATE：無伺服器，AWS 自動管理底層基礎設施
- EC2：使用你自己管理的 EC2 執行資源（需事先配置）
Cluster：選擇任務要執行在哪個 Cluster 中
VPC、Subnets、Security Groups：指定任務使用哪個虛擬網路環境（若選用 Fargate，必須使用 awsvpc 網路模式）
Public IP 分配：是否需要分配公開 IP（如需對外提供 API 通訊建議開啟）

點擊「Run Task」後，ECS 就會依據這些設定，啟動一個新的 Task 實例。

📌 注意事項

若選擇 Fargate，必須使用 awsvpc 網路模式，並設定至少一個 Subnet 與 Security Group。
若使用 EC2，請確保 Cluster 中已經註冊 EC2 instance 作為 Container Instance，否則無法成功啟動任務。

使用 AWS CLI 啟動 Task（適合自動化或部署流程）

如果你希望把 ECS 任務納入 CI/CD 或大量自動部署流程中，使用 CLI 或程式碼會更加方便與可控。

以下是一個範例指令，使用 Fargate 啟動一個任務：

aws ecs run-task \
  --cluster my-cluster \
  --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-xxxxxx],securityGroups=[sg-xxxxxx],assignPublicIp=ENABLED}" \
  --task-definition my-task:1

🔍 各參數說明：

參數名稱	說明
--cluster	指定任務執行的 ECS Cluster 名稱
--launch-type	選擇 FARGATE 或 EC2 啟動類型
--task-definition	指定任務要使用的 Task Definition 名稱與版本（例如 my-task:3）
--network-configuration	Fargate 必填：指定 Subnet 與 Security Group，並是否要分配 Public IP
--count（選填）	要同時啟動幾個 Task，預設為 1

🧠 小技巧：

如果你有多個環境（例如 dev/staging/prod），可以透過不同的 Cluster、Security Group 或 Task Definition 版本分開部署。
此指令可整合進 Shell script、GitHub Actions、GitLab CI、CodePipeline 等工具中實現全自動化部署流程。

啟動後發生什麼事？

無論你使用哪種方式，當你「啟動 Task」後，ECS 將會根據你提供的設定進行以下流程：

分配資源（vCPU、Memory）
建立網路介面（若使用 awsvpc 模式）
拉取對應的 container image（從 ECR 或 Docker Hub）
啟動所有在 Task Definition 中定義的容器
開始執行容器命令，正式「跑起來」

你可以在 ECS Console 的「Task」頁面中，看到該任務的狀態（例如 PROVISIONING、PENDING、RUNNING），也可以連到 CloudWatch 查看日誌輸出。

如何監控 Task 狀態與日誌？

啟動 ECS Task 後，你會希望能掌握它當下的執行情況，並在發生錯誤時能快速找到原因。

這時你就需要學會兩件事：

查看 Task 的「狀態」
查看 Task 中各容器的「日誌」

這兩個動作不只幫助你除錯，也對日常監控與系統穩定性追蹤至關重要。

查詢 Task 狀態（使用 CLI）

若你知道某個 Task 的 ID，可以透過 AWS CLI 查詢它的詳細狀態與執行資訊：

aws ecs describe-tasks \
  --cluster my-cluster \
  --tasks <task-id>

回傳的結果是一段 JSON，裡面會包含 Task 的當前狀態、所使用的 Task Definition、啟動類型、執行容器的詳細資訊（如 IP、Port、狀態）等。

🚦 常見 Task 狀態說明：

狀態	說明
PROVISIONING	ECS 正在為 Task 分配資源（例如網路、IP、記憶體），還沒開始啟動容器
PENDING	Task 資源準備好了，但容器尚未開始啟動。通常是等待排程或初始化動作完成。
RUNNING	所有容器都已啟動且正在執行中，Task 已進入工作階段。
STOPPED	Task 已停止，可能是正常結束、排程時間到、或容器內部錯誤導致。可查看 stoppedReason 了解原因

🛠 小技巧：如何找出 Task ID？

你可以透過以下 CLI 指令列出最近啟動的 Task：

aws ecs list-tasks \
  --cluster my-cluster

或者若你使用 Service 啟動 Task，也可以這樣查：

aws ecs list-tasks \
  --cluster my-cluster \
  --service-name my-service

查看 Task 中容器的 Log（使用 CloudWatch）

ECS 預設本身不會自動收集日誌。

你必須在 Task Definition 中手動設定 log driver（建議使用 awslogs），才能讓容器輸出的 stdout/stderr 被收集到 CloudWatch Logs 中。

✅ 檢查你的 Task Definition 是否正確設定 log 驅動：

"logConfiguration": {
  "logDriver": "awslogs",
  "options": {
    "awslogs-group": "/ecs/my-task",
    "awslogs-region": "ap-northeast-1",
    "awslogs-stream-prefix": "ecs"
  }
}

🔍 透過 AWS Console 查看日誌：

前往 AWS Console
點選左側選單的「CloudWatch」
進入「Logs」區域
找到 log group 名稱（例如 /ecs/my-task）
點開對應的 log stream（通常命名為 ecs/容器名稱/Task ID）

你就能看到容器的 console 輸出，包含：

應用程式啟動記錄
錯誤訊息（Exception stack trace）
自行輸出的 log（例如 console.log、print() 等）

🧪 使用 CLI 查詢日誌內容（快速測試時很方便）

如果你不想開啟瀏覽器，也可以透過 CLI 抓取 CloudWatch Log 內容：

aws logs get-log-events \
  --log-group-name /ecs/my-task \
  --log-stream-name ecs/my-container-name/xxxxxxxxxxxxxxxx \
  --limit 20

這會顯示最近的 log 訊息，對於快速查看啟動錯誤、確認應用有無成功啟動非常有幫助。

⚠️ 注意事項：

每個 container 都會有一個獨立的 log stream，如果 Task 中有多個容器，請一一查看。
若沒看到 log，請確認：
Task Definition 中是否正確設定了 log driver
IAM Role 是否有 CloudWatch Logs 權限
容器內是否有 log 輸出行為

Task 適合哪些應用場景？

在 AWS ECS 中，Task 是最基本的執行單位。

每當你需要「啟動一組容器來完成某件事」，你就是在使用 Task。

不過，Task 本身沒有自動重啟、不中斷執行、維持長期可用性的機制，因此它特別適合用在「短期、一次性」的任務執行場景。

以下是幾種常見與實用的 Task 應用場景：

一次性任務（One-time Job）

這類任務的特點是「只要執行一次」，執行完畢後 Task 就可以自然停止，沒有持續運行的需求。

📌 範例情境：

系統每日清晨備份資料庫，將備份檔上傳到 S3
使用 AI 模型處理一次性的影像辨識任務
匯出 CSV 檔案並寄送至內部信箱
根據 webhook 觸發執行短暫任務（例如：用戶註冊後寄送歡迎通知）

📍 部署方式：可使用 CLI、SDK、或 EventBridge rule 自動觸發 run-task

批次任務（Batch Job / Scheduled Job）

這類任務具有「週期性執行」的需求，例如每天、每週、或每月固定執行一次，做完事情後就結束。

📌 範例情境：

每天凌晨進行銷售報表統計與產出
每週固定同步外部 API 資料（例如：匯率、庫存）
對大量資料進行批次轉換、重新格式化
自動化刪除過期的快取或中繼檔案

📍 部署方式：可結合 Amazon EventBridge 排程觸發，定期執行 run-task

臨時除錯與測試（Ad-hoc Debug）

ECS Task 也很適合用來做即時除錯、測試環境驗證或小規模功能檢查。

比起設定完整的 CI/CD 部署流程，你可以快速啟動一個 Task 來進行：

📌 範例情境：

想驗證剛建立的 Docker image 是否能成功啟動
測試某段 API call 是否能正確連接資料庫
臨時查看 Container 中的環境變數、日誌輸出
手動模擬某個定時任務的執行情境（例如提前執行明日的報表產生）

📍 部署方式：手動進入 AWS Console ➜ Run new task，或使用 CLI 即時啟動

補充說明：Task ≠ 長期服務

值得注意的是，Task 不會自動重啟。這代表如果：

程式出錯（crash）
主機發生故障
Task 執行完成

➡️ 這個 Task 就會終止，不會自己重啟，也不會持續維持一定數量的實例。

✅ 若需「長期運作」請改用 ECS Service

如果你的應用需要：

穩定長時間運作（例如：API Server、Web App、Socket Server）
自動重啟故障的 Task
依流量自動擴展 / 縮減容器數量
搭配 Load Balancer 接收用戶流量

👉 請使用 ECS Service，它是為了「長期執行且高可用」的情境設計的控制層，會確保你的 Task 數量穩定、不中斷服務。

小結：掌握 ECS Task 是學習容器部署的關鍵起點

透過本篇你已學會：

✅ ECS Task 是真正「執行」你的應用單位
✅ Task 是根據 Task Definition 建立的
✅ 可用 AWS Console 或 CLI 啟動
✅ 可透過 CloudWatch 監控與除錯

不論你是部署微服務、執行批次作業、還是打造 CI/CD，自動化啟動 Task 將會是你掌握雲端架構的第一步。

Task 是 ECS 裡真正「執行中」的工作單位

Task 是由 Task Definition 派生出來的實例

一個 Task 裡面不一定只有一個容器

Task 是怎麼定義的？—— Task Definition 結構一覽

Task Definition 欄位說明

Containers

CPU / Memory

Launch Type

Network Mode

為什麼 Task Definition 如此關鍵？

補充：Task Definition 還能設定什麼？

如何啟動一個 ECS Task？

使用 AWS Console 手動啟動 Task（適合入門者）

📌 注意事項

使用 AWS CLI 啟動 Task（適合自動化或部署流程）

🔍 各參數說明：

🧠 小技巧：

啟動後發生什麼事？

如何監控 Task 狀態與日誌？

查詢 Task 狀態（使用 CLI）

🚦 常見 Task 狀態說明：

🛠 小技巧：如何找出 Task ID？

查看 Task 中容器的 Log（使用 CloudWatch）

✅ 檢查你的 Task Definition 是否正確設定 log 驅動：

🔍 透過 AWS Console 查看日誌：

🧪 使用 CLI 查詢日誌內容（快速測試時很方便）

⚠️ 注意事項：

Task 適合哪些應用場景？

一次性任務（One-time Job）

批次任務（Batch Job / Scheduled Job）

臨時除錯與測試（Ad-hoc Debug）

補充說明：Task ≠ 長期服務

小結：掌握 ECS Task 是學習容器部署的關鍵起點

Similar Posts

發佈留言 取消回覆

關於本站

發佈留言取消回覆