它比虛擬機輕量、啟動快，是現代雲端開發的核心基礎。

只要你理解它的概念，Docker、Kubernetes 這些詞就不會再讓你頭痛。

容器技術的定義

一種「把應用程式和它需要的所有東西打包在一起」的技術，確保程式在任何環境都能穩定執行。

這個「所有東西」包含：

1. 程式碼本身
2. 執行環境 (不同程式需要的環境都不一樣)
3. 相依套件 (像是函式庫 Library 或模組，沒有裝就不能順利跑起來，像 python 要處理資料就要再裝 pandas)
4. 容器設定檔 (Dockerfile)

打包完之後，這個容器可以在任何支援容器的機器上執行。

不管你的作業系統是 Ubuntu、CentOS 還是 Windows Server，甚至在你的 Mac 電腦，只要先裝好 Docker，同一個容器都可以順利跑起來。

容器和「貨櫃」的關係：生活化比喻

容器的英文是 Container，這個字本來就是「貨櫃」的意思。

以前船運貨物，每次都要重新裝箱、綁繩、確認尺寸，而每艘船、每個港口規格不同，搬運過程很容易出錯。

貨櫃標準化之後，不管是船運、火車還是卡車，同一個貨櫃直接搬上去就能走，裡面的東西不需要重新整理。

容器技術做的事情一模一樣：把你的應用程式裝進一個標準化的「盒子」，這個盒子搬到哪裡都能直接執行。

容器技術解決了什麼問題？

在它出現之前，工程師最常遇到這個情境：

開發環境裝的是 Python 3.8，測試環境是 Python 3.6，上線環境是 Python 3.11。

程式在開發機跑得好好的，一到正式環境就報錯，花兩天找問題，最後發現程式根本沒寫錯，而是套件版本不對。

容器從根本解決這個問題：開發、測試、上線用的是同一個容器映像檔，環境完全一致，不會出現版本差異。

容器技術的運作原理

容器是怎麼隔離環境的？

容器使用 Linux 核心內建的兩個機制來做隔離：

1. Namespace：讓每個容器有自己的「視角」，容器 A 看不到容器 B 的處理程序、網路介面、檔案系統。
2. Cgroups（Control Groups）：限制每個容器能用多少 CPU、記憶體、磁碟 I/O，避免一個容器把整台機器的資源吃光。

這兩個機制讓多個容器可以同時在同一台機器上執行，彼此不干擾，也不互搶資源。

如果你是初學者來，不需要記住 Namespace 和 Cgroups 的細節。

只要記住一件事：容器的隔離是靠作業系統核心直接支援的，不是靠模擬出另一台電腦。這就是容器比虛擬機輕量的根本原因。

為什麼容器可以這麼輕量？

虛擬機要模擬一整台電腦，包含硬體層、作業系統、核心。

光是一個虛擬機就要佔用 10–20 GB 的空間，啟動需要 30 秒到幾分鐘，所以開機才這麼慢。

容器不模擬硬體，也不需要自己的作業系統核心，直接借用宿主機（Host）的 Linux 核心。

一個容器映像檔大約只有 100–200 MB，啟動時間在 1–3 秒以內。

這個差異在大規模部署時非常明顯：一台實體機器可能只能跑 10–20 個虛擬機，但可以輕鬆跑超過 100 個容器。

容器映像檔（Image）是什麼？

容器映像檔（Image）是容器的「範本」，是一個唯讀的打包檔案，裡面包含程式碼和所有執行環境，用來啟動容器實例。

「實例」這個名詞有點難解釋，你可以理解爲一臺虛擬的小電腦，隨時可以產生出來或刪除掉。

你可以把 Image 想成「食譜」，容器是「用這份食譜做出來的菜」。

同一份食譜可以做出很多份菜，同一個 Image 可以啟動很多個容器實例，彼此獨立、互不影響。

你也可以把 Image 想成遊戲光碟片，那容器就是光碟片開始轉，裡面的遊戲檔被讀出來執行的樣子。

Image 採用分層結構：

1. 底層是作業系統基礎（例如 Ubuntu slim）
2. 上面一層是語言環境（例如 Node.js 18）
3. 最上面才是你的應用程式

如果你第一次打包映像檔，它會先上網下載作業系統環境的相關檔案；然後第二層再下載你的程式語言所需要的環境檔案，以及一些相依性的套件。

由於它每一層都可以快取 (暫存在你電腦裡面)，如果你的程式碼有改，更新容器只需要重新打包有變動的那層，不用再下載作業系統跟程式語言環境，效率很高。

容器 vs 虛擬機：哪裡不一樣？

容器（Container）和虛擬機（Virtual Machine，VM）都是用來隔離執行環境的技術，但架構完全不同：

容器共用宿主機的 OS 核心，虛擬機則模擬出一整台獨立的電腦。這個差異直接決定了兩者在速度、體積和資源消耗上的巨大差距。

架構差異一次看懂

啟動速度與資源佔用的比較

容器啟動快，不是因為硬體更好，而是架構不同。

虛擬機每次啟動的流程：

1. 初始化虛擬硬體
2. 載入 BIOS
3. 啟動 OS 核心
4. 載入系統服務
5. 才能執行你的程式

容器啟動的流程：

1. 在宿主機核心上建立隔離空間
2. 載入映像檔
3. 執行程式

跳過了模擬硬體和啟動 OS 這兩個最耗時的步驟，所以快。

在資源佔用方面：一台 8 GB RAM 的伺服器，跑虛擬機時每個 VM 至少需要 1–2 GB RAM 給 OS 本身；

跑容器時 OS 的 RAM 消耗幾乎為零，幾乎所有記憶體都給應用程式用。

什麼情況該用容器？什麼情況該用虛擬機？

適合容器的情況：

1. 微服務架構，需要大量部署小型服務
2. CI/CD 流程，需要快速啟動、測試、銷毀環境
3. 開發環境一致性，多人協作的專案
4. 雲端部署，需要彈性擴充和縮減的應用程式

適合虛擬機的情況：

1. 需要完整 OS 隔離（例如執行不信任的第三方程式）
2. Windows 應用程式（容器對 Windows 的支援較複雜）
3. 需要模擬不同作業系統進行相容性測試
4. 對安全隔離要求極高的金融或醫療系統

兩者不是非此即彼的關係。

實際生產環境中，常見做法是：虛擬機作為底層基礎設施，容器在虛擬機上運行。

Docker 容器：最主流的容器工具

Docker 是什麼？和容器的關係

容器技術這個概念在 Docker 之前就存在，但當時提供容器技術的廠商非常多，而且操作複雜、工具不統一，只有少數工程師會用。

Docker 是目前最主流的容器工具，由 Docker Inc. 於 2013 年發布。

它讓開發者可以用簡單的指令打包、分發、執行容器，大幅降低容器技術的使用門檻。

並且提供統一的指令介面、映像檔格式，以及 Docker Hub 這個映像檔共享平台。

所以 Docker 幾乎一統江湖，成為容器技術的獨佔廠商。

容器技術是概念，Docker 則是最受歡迎的容器廠商。

現在說「用容器部署」，90% 的情況都是在用 Docker 或基於 Docker 格式的工具。

Docker Hub：映像檔從哪裡來？

Docker Hub 是 Docker 官方的映像檔倉庫（Repository），可以把它想成「容器的 App Store」。

想跑一個 MySQL 資料庫？不需要自己安裝，一行指令就能從 Docker Hub 下載官方的 MySQL 映像檔，直接啟動。

Docker Hub 上有超過 1,000 萬個映像檔，包含：

• 各種語言的執行環境（Python、Node.js、Go）
• 資料庫（MySQL、PostgreSQL、Redis）
• Web 伺服器（Nginx、Apache）

你也可以把自己打包好的映像檔推上去，私有或公開都支援。

用 Docker 跑第一個容器：3 個步驟

假設你已經安裝好 Docker，跑第一個 Docker 容器只需要：

1. 開啟終端機，輸入 docker pull nginx，從 Docker Hub 下載 Nginx 的映像檔
2. 輸入 docker run -d -p 8080:80 nginx，啟動容器並把 8080 port 對應到容器內的 80 port
3. 開啟瀏覽器，前往 http://localhost:8080，看到 Nginx 歡迎頁面就代表成功

從下載到執行，整個過程在 30 秒內完成。你不需要安裝、設定 Nginx，只要這三步就有一個完整運行的 Web 伺服器。這就是 Docker 容器改變開發流程的地方。

Kubernetes 容器編排：容器多了之後怎麼管？

為什麼需要 Kubernetes？

3–5 個容器，Docker 指令就夠用。300 個容器分散在 20 台伺服器上，Docker 指令完全不夠用。你需要解決：

• 某個容器掛掉，要怎麼自動重啟？
• 流量暴增，要怎麼自動增加容器數量？
• 新版本要怎麼在不停機的情況下更新？
• 20 台伺服器的資源要怎麼統一分配？

這些問題就是「容器編排」要解決的事。

Kubernetes（簡稱 K8s）是目前最主流的容器編排平台，由 Google 於 2014 年開源，現在由 CNCF（雲端原生運算基金會）維護，是大規模容器化應用的業界標準。

Kubernetes 和 Docker 的分工

Docker 負責：建立和執行單個容器。

Kubernetes 負責：管理大量容器的生命週期，包含排程、擴縮、自我修復、網路和儲存配置。

兩者是互補關係，不是競爭關係。在大多數生產環境中，Kubernetes 會呼叫容器執行時（Container Runtime）來實際啟動和停止容器，Docker 就是最常見的容器執行時之一。

容器編排解決的三個核心問題

Kubernetes 解決了容器規模化之後最常見的三個痛點：

1. 自我修復（Self-healing）：容器掛掉，Kubernetes 在幾秒內自動重新啟動，不需要人工介入
2. 水平擴展（Horizontal Scaling）：CPU 使用率超過 80% 時，Kubernetes 自動新增容器副本；流量下降後自動縮減，節省成本
3. 滾動更新（Rolling Update）：新版本部署時，Kubernetes 逐步替換舊容器，零停機時間，出問題可以一鍵回滾到上一版

容器技術的實際應用場景

開發環境一致性：再也不會「我電腦上可以跑」

這是最直接、最普遍的應用場景。

10 人的開發團隊，每個人的電腦環境都不一樣：Windows、macOS、不同版本的 Linux，不同版本的 Node.js、Python、資料庫。

用容器技術，把開發環境定義在一個 docker-compose.yml 檔案中。新成員加入團隊，執行一個指令就能啟動和資深工程師完全相同的開發環境，從加入到開始寫程式只需要 15 分鐘，而不是過去光設定環境就要花一整天的「環境設定地獄」。

微服務架構與容器化應用

微服務架構是把一個大型應用程式拆成很多個小型、獨立的服務，每個服務負責一個功能，可以獨立開發、部署、擴展。容器化應用是微服務架構的最佳搭配：每個微服務打包成一個容器，可以用不同的程式語言撰寫、獨立部署、獨立擴展。

舉個例子：一個電商平台有訂單服務、庫存服務、推薦系統、金流服務各自獨立。促銷期間推薦系統需要大量 CPU，你可以只針對推薦系統的容器擴展，不需要把整個平台都擴展，省下大量成本。

CI/CD 流程中的容器角色

CI/CD（持續整合 / 持續交付）是現代軟體開發的標準流程：工程師提交程式碼後，自動執行測試、打包、部署，不需要人工介入。

容器在 CI/CD 流程中扮演關鍵角色：

1. 測試環境用容器啟動，每次測試都在乾淨的環境中執行，不受之前測試殘留的狀態影響
2. 打包成容器映像檔，確保開發、測試、正式環境用完全相同的產物
3. 部署時直接替換容器，速度快、可回滾，比傳統部署方式風險低很多

容器技術的限制與常見誤解

容器不是萬能的：三種不適合用容器的情境

它很強，但不是所有情境都適合：

1. 需要 GUI 的桌面應用程式：容器設計上是無頭（Headless）的，跑有圖形介面的軟體需要額外設定
2. 需要直接存取硬體的應用程式：例如需要存取特定 GPU、USB 裝置，容器的隔離層會增加複雜度
3. 狀態複雜的單體式舊系統（Legacy System）：把有幾十年歷史的大型系統容器化，往往需要大量改寫，成本超過效益

容器技術最適合「雲端原生（Cloud Native）」的應用程式——從設計之初就考慮到分散式部署、無狀態、水平擴展的架構。

容器安全性：常見疑慮與對應做法

容器的隔離比虛擬機弱——這是事實，但不代表容器不安全。

常見的安全疑慮和對應做法：

1. 容器逃逸（Container Escape）：攻擊者從容器內部突破隔離，存取宿主機。
   對應方式：不以 root 身分執行容器、定期更新容器映像檔、使用 Seccomp 和 AppArmor 限制系統呼叫
2. 映像檔安全性：從 Docker Hub 下載的映像檔可能包含漏洞或惡意程式。
   對應方式：只使用官方映像檔或自建基礎映像、在 CI/CD 流程中加入映像檔掃描（例如 Trivy、Snyk）
3. 密鑰管理：不要把密碼、API Key 直接寫進映像檔。
   對應方式：使用 Kubernetes Secret 或 HashiCorp Vault 管理敏感資訊

容器安全是可以管理的問題，只要遵守基本的安全實踐，風險完全在可接受的範圍內。

學容器的建議路徑

從 Docker 開始還是從概念開始？

建議先從概念開始，再動手。

很多人第一步就打開終端機跑 Docker 指令，結果遇到錯誤不知道為什麼，也不知道自己在做什麼，很快就放棄。

理解「容器是什麼、解決什麼問題、和虛擬機有什麼差別」之後，再開始動手，每一個指令都有清楚的脈絡，遇到問題也更容易判斷方向。

推薦的學習順序與資源

從零開始學容器技術，建議依這個順序：

1. 理解概念：搞清楚容器 vs 虛擬機、Image vs 容器的關係（本文就是起點）
2. 安裝 Docker Desktop：官網提供 Windows 和 macOS 的圖形化安裝包，10 分鐘內完成
3. 跑第一個容器：用 docker run hello-world 確認環境正常，再跑 Nginx 或 Python 應用程式
4. 學習 Dockerfile：學會自己撰寫 Dockerfile，把自己的應用程式打包成映像檔
5. 學習 Docker Compose：用 YAML 檔案定義多容器環境，例如「應用程式 + 資料庫」的組合
6. 入門 Kubernetes：理解 Docker 之後再學 K8s，不要跳過 Docker 直接學 K8s

每個階段大約需要 1–2 週，有實作練習的情況下，2–3 個月可以達到在工作中使用容器技術的基本水準。

結語：容器技術值得學嗎？

值得，而且越早學越好。

容器技術已經不是「進階技能」，而是現代後端工程師和 DevOps 工程師的基本配備。

人才需求中出現 Docker、Kubernetes 的頻率，在過去五年內增加了超過三倍。

從理解容器的概念開始，裝好 Docker，跑幾個練習專案，這樣就夠了。Kubernetes 和進階的容器編排，等你對容器有基本掌握之後再學，不會太晚。

容器技術的學習曲線在前兩週最陡，一旦度過那段，後面會越來越順。

常見問題（FAQ）

Q1：容器技術是什麼？用一句話說明。
A：容器技術是一種把應用程式和它的執行環境打包在一起的技術，確保程式在任何機器上都能穩定執行，不受底層作業系統差異影響。
它比虛擬機輕量、啟動更快，是現代雲端部署的核心基礎。
尤其是它在開發、測試、上線環境完全一致，是容器技術解決的最核心問題。

Q2：一個容器可以同時跑多個應用程式嗎？
A：技術上可以，但不建議。容器的設計哲學是「一個容器、一個程序」，這樣才能充分發揮容器的輕量性和獨立性。
如果你需要跑多個應用程式，應該用多個容器，再用 Docker Compose 或 Kubernetes 讓它們協同工作。

Q3：容器和 Serverless 有什麼關係？
A：Serverless（如 AWS Lambda、GCP Cloud Functions）是更高階的抽象，你不需要管理伺服器或容器，只要上傳函數程式碼就好。
但實際上，很多 Serverless 平台的底層就是用容器技術來隔離和執行函數，只是這個細節被平台隱藏起來了。
最有名的就是 Cloud Run，它可以直接讓你的容器跑起來。

Q4：Docker 和 Podman 有什麼差別？
A：Podman 是 Red Hat 推出的容器工具，最大差別是不需要常駐的 Daemon（背景服務），以及預設不需要 root 權限執行，安全性稍高。
指令格式和 Docker 幾乎完全相同，可以直接替換使用。
對初學者來說，先學 Docker 就好，兩者概念完全通用。Podman 知名度低很多。

Q5：容器映像檔更新了，跑起來的容器會自動更新嗎？
A：不會。已經在跑的容器使用的是啟動時的映像檔版本，不會自動套用新映像檔。
你需要停止舊容器、拉取新映像檔、再啟動新容器。
這也是為什麼 Kubernetes 的滾動更新（Rolling Update）功能很重要，它可以幫你自動完成這個過程，而且不停機。

Q6：容器的資料存放在哪裡？容器刪掉資料會不見嗎？
A：預設情況下，容器內部產生的資料在容器刪除後就消失了。這是容器「無狀態」設計的一部分。如果你需要持久保存資料（例如資料庫的資料），要使用 Volume（磁碟掛載），把資料存在宿主機的指定路徑，容器刪除後資料仍然存在。

Q7：學容器技術需要先學 Linux 嗎？
A：不需要精通，但需要基本熟悉。你需要能看懂基本的 Linux 指令（ls、cd、cat、chmod）、了解檔案系統結構，以及知道什麼是 Port 和環境變數。
如果這些概念對你完全陌生，建議先花 1–2 週補一下 Linux 基礎，之後學容器技術會順很多。

Q8：免費使用 Docker 有限制嗎？
A：Docker Desktop（桌面版）對個人使用和小型公司（員工數少於 250 人、年營收低於 1,000 萬美元）免費。超過這個規模需要付費訂閱。
Docker Engine（命令列版本，在 Linux 伺服器上使用）則是完全免費且開源的。Docker Hub 免費帳號有 Image 下載次數限制，付費帳號則無限制。

Q9：GCP、AWS、Azure 上的容器服務有什麼差別？
A：三大雲端平台都提供託管的 Kubernetes 服務：GCP 是 GKE（Google Kubernetes Engine）、AWS 是 EKS（Elastic Kubernetes Service）、Azure 是 AKS（Azure Kubernetes Service）。
三者核心功能相似，差異在於和各自雲端生態系的整合程度。GKE 因為 Kubernetes 本身就是 Google 開發的，整合度和功能被認為是最成熟的。

Q10：公司說要「容器化」現有的系統，這有多難？
A：難度差異很大，取決於現有系統的架構。
如果是相對現代的應用程式（有明確的相依套件清單、設定可以用環境變數注入），架構清晰的應用程式， 1–3 週就能完成基礎版本。
如果是有幾十年歷史的大型單體式系統，深度依賴特定硬體或作業系統功能，容器化可能需要數個月甚至不值得做。
建議先評估系統架構，再決定是否容器化以及容器化的範圍，有可能需要大幅的更動甚至重寫程式碼。

The post 容器 (Container) 技術是什麼？從零開始看懂 Docker 與容器化應用 first appeared on 東東 GCP 教學 - GCP 實戰講師.

Artifact Registry 是 Google Cloud 中專門的容器映像檔儲存庫，當時在 Artifact Registry 推出之前，己經有 Container Registry，但 Container Registry 只支援 Docker 映像檔，並且功能較為簡單，也沒有細緻的權限管理機制，所以 Google 在 2020 年推出 Artifact Registry，作為 Container Registry 的全面升級。

Artifact Registry 除了 Docker 映像外，還支援 Maven Artifacts（Java）、Npm Packages、Python Packages、Helm Charts 等等。

建立容器映像檔示範

準備 Nodejs 程式檔案

接著我們就開始打造一個容器映像檔，並上傳到 Artifact Registry 吧！

首先我們一樣開啟 Cloud Shell，建立一個資料夾例如 nodejs01，然後先建立第一個檔案 server.js

var http = require('http');
var handleRequest = function(request, response) {
  response.writeHead(200);
  response.end("Hello World from Dongdong Nodejs!!");
}
var www = http.createServer(handleRequest);
www.listen(8080);

然後測試程式能否運作，輸入 node server.js，可以點擊預覽網頁的按鈕，看看網頁是否秀出內容：

準備 Dockerfile

如果確認沒問題，再按下 ctrl + C 取回游標，接著準備第二個檔案 Dockerfile 內容如下：

FROM node:6.9.2
EXPOSE 8080
COPY server.js .
CMD node server.js

Dockerfile 是說明檔，告訴 Docker 要如何打包這個 Image，包含這個容器使用什麼程式語言、對外開放哪個 Port、程式的檔案在哪裡、用什麼指令來跑程式等等。

現在我們已經準備好兩個檔案如下：

建立 Artifact Registry 存放區

接著我們回到 Google Cloud Console，去 Artifact Registry 建立一個存放區：

我們命名「nodejs-1」，格式選擇 Docker，Region 選在 asia-east1，再按下「建立」。 完成之後就會看到它顯示在存放區的列表：

取得憑證

點擊「設定操作說明」，它會開啟一個視窗，並提供一個 gcloud 指令，把它複製起來，這樣之後才能從 Cloud Shell 直接推送映像檔上去：

直接將指令貼到 Cloud Shell 並執行，等它完成即可，你會看到它說 gcloud credentials 註冊成功：

建立 Docker 容器映像檔

接下來準備 Docker image 的完整名稱，它同時也是存放在 Artifact Registry 的路徑，格式如下：

[位置]/[project-id]/[repo_name]/[image_name]:v1

我的映像檔名字就像這樣：

asia-east1-docker.pkg.dev/dong-dong-gcp-2-bigquery/nodejs-1/nodejs-web:v1

準備好之後，就執行以下指令：

docker build -t  [位置]/[project-id]/[repo_name]/[image_name]:v1

我的範例指令：

docker build -t asia-east1-docker.pkg.dev/dong-dong-gcp-2-bigquery/nodejs-1/nodejs-web:v1 . 

你注意指令最後有一個句點，代表要把當前資料夾 (nodejs01) 內的檔案都打包進這個映像檔。

測試 Docker Image 運作

我們再直接使用 Image 跑一次容器，確認應用程式正常

docker run -d -p [port]:[port] [位置]/[project-id]/[repo_name]/[image_name]:v1

我的範例指令：

docker run -d -p 8080:8080 asia-east1-docker.pkg.dev/dong-dong-gcp-2-bigquery/nodejs-1/nodejs-web:v1    

參數 -d ，指的是背景執行

參數 -p 8080:8080 ，指的是把主機的 8080 Port 所有流量轉發到 web 這個Container 的 8080 Port

然後我們點擊 Cloud Shell 視窗右上角的預覽按鈕，可以看到網頁已經正常顯示：

停止 Docker 應用程式

確認無誤的話，我們要停止 Container 運作之前，要先查詢目前正在運作 Container 的 ID： 

docker ps 

取得 ID 之後，停止指定的 Container

docker stop [container-id]

推送 Docker Image 到 Artifact Registry

現在就可以正式 Push Docker Image 到 Artifact Registry 了，執行以下指令：

docker push [位置]/[project-id]/[repo_name]/[image_name]:v1

我的範例指令：

docker  push asia-east1-docker.pkg.dev/dong-dong-gcp-2-bigquery/nodejs-1/nodejs-web:v1  

我們看到映像檔已經推上去了，我們可以回到 Console 上按重新整理：

現在我們有一個映像檔在上面，之後就可以部署到 Cloud Run 或 Google Kubernetes Engine 囉！

影片版教學：

The post 儲存容器映像檔的 Artifact Registry 簡介與上傳 Docker 映像檔教學 first appeared on 東東 GCP 教學 - GCP 實戰講師.

雖然 App Engine 和 Cloud Run Functions 都提供了無需管理基礎設施的便利性，但兩者在應用場景上有著重要差異。App Engine 適合部署完整的 Web 應用程式，而 Cloud Run Functions 則專注於輕量級的函式服務，讓開發人員能夠實現事件驅動的微服務架構。

什麼是 Cloud Run Functions？

Cloud Run Functions 原名叫 Cloud Function，是 Google Cloud 的 Functions as a Service (FaaS) 平台，讓你可以撰寫小型的、專注於單一任務的函式，不用管理機器。支援的程式語言包含 .Net、Go、Java、Node.js、PHP、Python 和 Ruby。

這些函式會在事件發生時自動執行，用完即停，真正實現了「用多少算多少」的理念。

想像一下，你經營一家網路商店，當客戶下單時需要：

• 發送確認郵件給客戶
• 更新庫存數量
• 記錄銷售資料到分析系統
• 通知物流部門準備出貨

在傳統單體式架構中，這些功能可能都寫在同一個應用程式中。但使用 Cloud Run Functions，你可以為每個任務建立獨立的函式，當訂單事件發生時，這些函式會自動被觸發 (Trigger) 執行，就是所謂的「事件驅動」特性。

另外 Cloud Run Functions 也能 Autoscale，當同時有大量事件需要處理時，平台會自動建立多個函式執行個體 (instance；指輕量級的容器) 來並行處理；當需求降低時，也會自動縮減執行個體數量，甚至降到零。

所以和 App Engine 一樣，你只需為函式實際執行的時間和資源消耗付費，沒有請求時完全不收費。

Cloud Run Functions 的觸發機制

關於觸發機制，Cloud Run Functions 可以透過多種方式被觸發：

HTTP Trigger：最常見的觸發方式，函式會曝露一個 HTTPS 端點，可以透過 REST API 呼叫。適合建立微服務 API、Webhook 處理器等。

Cloud Storage Trigger：當 Google Cloud Storage 中的檔案被建立、刪除或修改時觸發。適合檔案處理、圖片縮放、資料備份等場景。

Pub/Sub Trigger：當 Cloud Pub/Sub Topic 收到訊息時觸發。適合非同步訊息處理、事件串流處理等。

Firebase Trigger：與 Firebase 服務整合，可以因應 Firestore 資料庫變更、使用者註冊、帳號變更事件等。

Cloud Scheduler 觸發器：定時執行函式，類似 Cron Job 的功能。

建立 Cloud Run Functions 示範

接著我們來建立一個簡單的函式看看，點擊主選單「Clodu Run 函式」再點擊「編寫函式」：

給函式命名、設定地區和程式語言版本，你看到它有產生一個端點網址，那就是之後對外服務的網址：

往下看到驗證的部分，我們要讓所有網路上的任何人都可以存取，所以要取消「使用 IAM 驗證傳入要求」。另外在服務資源調度的部分，我們要把「執行個體數量下限」改成 0。

再來 Ingress 的部分，我們要勾選「全部」，這樣子才能開放外部進來存取喔！然後我們再點擊右下角的展開按鈕，查看進階設定：

大部分內容都可以保持預設，主要看的是資源的部分，在正式的環境當中，你可以調整記憶體和 CPU 的規格，在這裡我們保持預設就好：

「執行個體數量上限」預設是 100，如果擔心它真的開到 100 台，可以像我一樣調成 5 就好，其他保持預設，最後按下「建立」：

接下來畫面會自動跳轉到「來源」這個頁籤，你可以在下方編輯程式碼，在這裡我們就保持不變，直接按下「儲存並重新部署」：

接著它會在背景作業，將現有程式碼打包成容器，等它幾秒鐘後，就可以點擊網址，並且看到網頁了。

The post 上傳程式碼就能跑的微服務 – Cloud Run Functions 簡介與基本操作教學 first appeared on 東東 GCP 教學 - GCP 實戰講師.