OpenFaaS無伺服器框架深度解析

– 10 分鐘閱讀

OpenFaaS 框架以其簡潔的架構和易用性，降低了無伺服器應用開發的門檻。它支援多種容器協調平台，並允許開發者使用任何程式語言編寫函式。透過函式看門狗機制，OpenFaaS 簡化了函式與底層平台的互動，並實作自動擴充套件等功能。其 CLI 工具提供便捷的函式管理方式，而多階段建置則能有效最佳化容器映像，提升佈署效率。

OpenFaaS：建構無伺服器應用的強大框架

OpenFaaS是一種專為建構無伺服器應用程式而設計的框架和基礎架構系統。最初源自Docker Swarm中的無伺服器框架，如今已擴充套件支援其他型別的基礎架構後端，如Kubernetes或Hyper.sh。OpenFaaS中的函式本質上是容器，利用Docker的容器技術，幾乎任何程式語言編寫的程式都可以被封裝成一個函式。這種設計使得我們能夠充分重複利用現有程式碼，以回應各種Web服務事件，而無需進行重寫。對於現代化舊系統以適應雲端基礎架構，OpenFaaS是一個極具價值的工具。

OpenFaaS的核心特性

在眾多的無伺服器框架中，OpenFaaS由原作者Alex Ellis提出並解決了多個關鍵問題。其主要驅動因素和引人注目的功能包括：

簡易性

許多無伺服器框架由於由大公司開發且作為無伺服器服務，佈署複雜。OpenFaaS則旨在成為一種足夠簡單的無伺服器堆積疊，使開發人員和小公司能夠在其自有硬體上佈署和使用。此外，OpenFaaS提供了一個即用型的UI門戶，允許使用者在瀏覽器中嘗試函式呼叫。OpenFaaS內建自動擴充套件功能，能夠自動測量函式呼叫的負載，並根據需求動態調整例項數量。

可移植性

容器生態系統中有多個協調引擎，如Docker Swarm和Google的Kubernetes。OpenFaaS最初設計為在Swarm上執行，後來擴充套件至支援Kubernetes。其函式在這些協調引擎之間具有可移植性。由於OpenFaaS函式本質上是一個普通的Docker容器，這意味著任何型別的工作負載都可以被重新封裝為函式容器，並簡單地佈署在OpenFaaS叢集上。OpenFaaS能夠在任何基礎架構上執行，包括本地硬體、私有雲和公共雲。

簡潔的架構設計

OpenFaaS的架構設計簡單，主要由API閘道器組成，用於接收請求。API閘道器將請求傳遞給叢集內的容器，即帶有看門狗的函式。看門狗是OpenFaaS的一個重要元件，將在後續章節中詳細討論。閘道器還負責跟蹤函式呼叫的次數。當請求量增大時，閘道器會觸發協調引擎按需擴充套件函式副本。

開放與可擴充套件性

OpenFaaS設計為開放且可擴充套件的。隨著時間的推移，OpenFaaS支援的FaaS後端數量不斷增加，因為任何人都可以為OpenFaaS貢獻新的後端。例如，若希望直接在容器執行時（如containerd）中執行函式以提高效能，可以透過為OpenFaaS撰寫新的containerd後端來實作擴充套件。

語言無關性

可以使用Linux或Windows支援的任何語言編寫OpenFaaS函式，然後將其封裝為Docker或OCI容器映像。這種靈活性使得開發人員可以使用熟悉的程式語言進行開發，而無需擔心底層實作細節。

架構演進

過去，我們習慣使用單體架構構建系統。現在，我們傾向於採用微服務架構。微服務可以進一步分解為更小的函式。顯然，函式代表了架構演進的下一步。

單體架構

單體架構是一種軟體架構，包含可區分的軟體模組。所有服務都被構建到單一的佈署模組中。

微服務架構

相比之下，微服務架構將單一單體模組中的緊密相關服務分離出來，成為外部鬆散耦合的服務。

函式即服務（FaaS）

FaaS代表了進一步的解耦。在這種架構中，微服務被拆分為更細粒度的單元——函式。

  graph LR
    A[單體架構] --> B[微服務架構]
    B --> C[函式即服務]
    C --> D[更細粒度的函式]

圖表翻譯： 此圖示展示了從單體架構到微服務架構，再到函式即服務的架構演進過程。單體架構首先演變為微服務架構，然後進一步細分為函式即服務，實作了更高的模組化和靈活性。

OpenFaaS元件

本文將介紹OpenFaaS的主要元件，包括API閘道器、函式看門狗和Prometheus例項。所有這些元件都執行在Docker Swarm或Kubernetes協調引擎之上。API閘道器和Prometheus例項作為服務執行，而函式看門狗則作為函式容器的一部分執行。容器執行時可以是任何現代版本的Docker或containerd。

  graph LR
    A[使用者端] -->|HTTP請求|> B[API閘道器]
    B -->|轉發請求|> C[函式容器]
    C -->|包含|> D[函式看門狗]
    C -->|包含|> E[函式程式]
    D -->|監控|> E
    B -->|監控|> F[Prometheus]

圖表翻譯： 此圖示展示了OpenFaaS的內部基礎架構。使用者端透過HTTP請求與API閘道器互動，API閘道器負責將請求轉發給後端的函式容器。函式容器中包含函式看門狗和實際的函式程式。API閘道器還與Prometheus配合，進行監控和資料收集。

函式看門狗

函式看門狗是OpenFaaS的一個關鍵元件，負責將實際的工作程式碼包裝在函式程式周圍。函式程式只需透過標準輸入（stdin）接受輸入，並將結果列印到標準輸出（stdout）。

API閘道器透過疊加網路與函式容器連線。每個函式容器包含以下元件：

  • 函式看門狗（fwatchdog）
  • 使用任意語言編寫的函式程式

在描述函式容器的Dockerfile中，必須設定fprocess環境變數，指向函式程式名稱和引數。

FROM openfaas/of-watchdog:0.8.1
ENV fprocess="my_function"
COPY my_function /usr/bin/my_function
RUN chmod +x /usr/bin/my_function
CMD ["fwatchdog"]

內容解密：

  1. FROM指令：使用openfaas/of-watchdog:0.8.1作為基礎映像，這是OpenFaaS提供的看門狗元件。
  2. ENV指令：設定fprocess環境變數，指定實際執行的函式程式名稱。
  3. COPY指令：將本地的my_function檔案複製到容器內的/usr/bin/my_function。
  4. RUN指令：為複製到容器內的函式程式新增執行許可權。
  5. CMD指令：指定容器啟動時執行的命令，即啟動fwatchdog。

命令列介面（CLI）

OpenFaaS提供了命令列介面（CLI）作為另一種使用OpenFaaS的方式。可以直接從https://cli.openfaas.com的安裝指令碼取得最新版本的CLI。對於Linux和macOS，可以使用以下命令安裝CLI：

curl -sL https://cli.openfaas.com | sudo sh

目前，安裝指令碼支援在ARM、ARM64和x64晶片上執行的macOS和Linux。CLI的設計目的是管理OpenFaaS函式的生命週期。可以使用CLI提供的子命令來構建、佈署和呼叫函式。

CLI實際上是透過API閘道器公開的一組控制平面API來控制OpenFaaS。

# 使用CLI佈署函式
faas-cli deploy -f function.yml

內容解密：

  1. faas-cli deploy命令：用於佈署函式。
  2. -f function.yml選項：指定包含函式組態的YAML檔案。
  3. 佈署流程：CLI會讀取function.yml檔案中的組態，將函式封裝並佈署到OpenFaaS叢集。

隨著雲原生技術的不斷發展，無伺服器架構已成為企業實作敏捷開發和高效維運的重要選擇。OpenFaaS作為無伺服器框架的佼佼者，將繼續在以下幾個方面進行創新和改進：

  1. 增強可移植性：進一步簡化跨不同雲平台和本地環境的佈署流程，使得函式能夠在更多樣的基礎架構上無縫執行。
  2. 提升效能最佳化：透過最佳化函式執行環境和資源管理，提高函式執行的效率和回應速度，降低冷啟動時間。
  3. 加強安全性和合規性：引入更強大的安全機制和合規性檢查，確保函式在執行過程中符合企業的安全政策和法規要求。
  4. 豐富生態系統：擴充套件OpenFaaS的生態系統，透過社群貢獻更多的函式範本和後端支援，降低開發者的上手門檻，加速創新應用開發。

透過持續的技術創新和生態擴充套件，OpenFaaS將進一步鞏固其在無伺服器領域的領先地位，為企業和開發者提供更強大、更靈活的無伺服器解決方案，推動雲端計算技術的廣泛應用和發展。

OpenFaaS：無伺服器框架的深度解析與應用實踐

OpenFaaS（Function as a Service）是一種流行的無伺服器框架，它允許開發者將函式封裝成容器並佈署到 Kubernetes 或 Docker Swarm 等容器協調平台上。本文將探討 OpenFaaS 的架構、安裝、函式準備和佈署等內容，並結合實際案例進行詳細分析。

OpenFaaS 的架構與核心元件

OpenFaaS 的核心元件包括 API Gateway、Function Watchdog 和 Prometheus 等。其中，API Gateway 負責接收外部請求並將其路由到相應的函式，Function Watchdog 則負責監控函式的執行狀態並將其輸出傳回給 API Gateway。此外，Prometheus 則負責收集函式的 metrics 並提供監控和報警功能。

API Gateway 的工作原理

API Gateway 是 OpenFaaS 的核心元件之一，負責接收外部請求並將其路由到相應的函式。其工作原理如下：

  1. 當外部請求到達 API Gateway 時，它會根據請求的 URL 和方法（GET、POST 等）將請求路由到相應的函式。
  2. API Gateway 會將請求的輸入資料傳遞給函式，並監控函式的執行狀態。
  3. 當函式執行完成後，API Gateway 會將函式的輸出傳回給客戶端。

Function Watchdog 的作用

Function Watchdog 是 OpenFaaS 的另一個重要元件，負責監控函式的執行狀態並將其輸出傳回給 API Gateway。其作用如下：

  1. 當函式被呼叫時，Function Watchdog 會啟動一個新的程式來執行函式。
  2. Function Watchdog 會監控函式的執行狀態，並在函式執行完成後將其輸出傳回給 API Gateway。

安裝 OpenFaaS

安裝 OpenFaaS 非常簡單，只需幾個步驟即可完成。首先，需要安裝 Docker 17.05 或更高版本。然後，可以使用以下命令初始化一個 Swarm 叢集：

$ docker swarm init

如果 Swarm 無法初始化，可以指定 IP 地址或介面名稱：

$ docker swarm init --advertise-addr <IP 地址或介面名稱>

接下來，可以使用以下命令克隆 OpenFaaS 的 GitHub 倉函式庫並佈署 OpenFaaS：

$ git clone https://github.com/openfaas/faas \
  cd faas \
  git checkout 0.6.5 \
  ./deploy_stack.sh

驗證 OpenFaaS 的安裝

佈署完成後，可以使用以下命令驗證 OpenFaaS 的安裝：

$ docker stack ls
NAME SERVICES
func 11

$ docker stack services func --format "table {{.Name}}\t{{.Ports}}"
NAME PORTS
func_hubstats
func_markdown
func_echoit
func_webhookstash
func_prometheus *:9090->9090/tcp
func_gateway *:8080->8080/tcp
func_decodebase64
func_base64
func_wordcount
func_alertmanager *:9093->9093/tcp
func_nodeinfo

準備函式

在佈署函式之前，需要準備一個二進製程式並將其封裝成容器。以下是準備函式的步驟：

  1. 建立一個 Dockerfile，包含 FROM 指令，以衍生自基礎映像。
  2. 將函式 watchdog 二進位制檔案新增到映像中，使用 ADD 指令。
  3. 將函式程式新增到映像中，使用 COPY 指令。
  4. 定義環境變數 fprocess，使用 ENV 指令，指向函式程式。
  5. 暴露埠 8080，使用 EXPOSE 指令。
  6. 定義容器映像的入口點，使用 ENTRYPOINT 指令，指向 fwatchdog。

使用多階段構建封裝 C 程式

以下是一個使用多階段構建封裝 C 程式的例子：

###############
# Stage 0
###############
FROM alpine:3.6
RUN apk add --no-cache gcc musl-dev
COPY main.c /
RUN gcc -static main.c -o main
###############
# Stage 1
###############
FROM alpine:3.6
RUN apk add --no-cache ca-certificates
COPY --from=0 /main /
ENV fprocess="/main"
EXPOSE 8080
HEALTHCHECK --interval=5s CMD [ -e /tmp/.lock ] || exit 1
CMD ["fwatchdog"]

內容解密：

  1. 多階段構建：Dockerfile 使用多階段構建技術，第一階段（Stage 0）負責編譯 C 程式，第二階段（Stage 1）負責封裝函式容器。
  2. 編譯 C 程式：在第一階段，使用 gcc 編譯 C 程式，並使用 -static 選項將程式靜態連結，以避免依賴分享函式庫。
  3. 封裝函式容器：在第二階段，將編譯好的程式複製到容器中，並設定環境變數 fprocess 指向該程式。
  4. 暴露埠：暴露埠 8080，以便函式容器可以接收請求。
  5. 健康檢查：使用 HEALTHCHECK 指令檢查容器是否健康。

使用多階段建置最佳化 OpenFaaS 函式容器映像

在現代軟體開發中，容器化技術已經成為不可或缺的一部分。OpenFaaS 是一個流行的無伺服器框架，允許開發者將函式封裝成容器並進行佈署。在本文中，我們將探討如何使用 Docker 的多階段建置功能來最佳化 OpenFaaS 函式的容器映像大小和安全性。

多階段建置的基本概念

多階段建置是 Docker 17.05 版本引入的一個功能，允許開發者在單一 Dockerfile 中定義多個建置階段。每個階段可以使用不同的基礎映像，並且可以從前一階段中複製檔案到當前階段。這種方法使得開發者能夠將建置過程與執行環境分離，從而產生更小、更安全的映像。

建立多階段 Dockerfile

以下是一個範例 Dockerfile，它使用多階段建置來建立一個 OpenFaaS 函式容器映像：

###############
# Stage0
###############
FROM alpine:3.6 AS builder
RUN apk update && apk add gcc musl-dev
COPY main.c /root/
WORKDIR /root/
RUN gcc -static -o main main.c

###############
# Stage1
###############
FROM alpine:3.6
ADD https://github.com/openfaas/faas/releases/download/0.6.5/fwatchdog /usr/bin/
RUN chmod +x /usr/bin/fwatchdog
EXPOSE 8080
COPY --from=builder /root/main /usr/bin/func_c
ENV fprocess="/usr/bin/func_c"
ENTRYPOINT ["/usr/bin/fwatchdog"]

內容解密：

  1. 多階段建置：Dockerfile 分為兩個階段：Stage0（別名為 builder）和 Stage1。Stage0 用於編譯 C 程式，而 Stage1 用於建立最終的函式容器映像。
  2. Stage0：使用 alpine:3.6 作為基礎映像，安裝必要的編
玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。