Airflow® 安裝

本頁面描述您在考慮如何安裝 Airflow® 時可能使用的安裝選項。Airflow 由許多組件組成，這些組件通常分佈在許多實體或虛擬機器上，因此 Airflow 的安裝可能會非常複雜，具體取決於您選擇的選項。

您也應該查看 先決條件，這些條件在安裝 Airflow 時必須滿足，以及 支援版本，以了解支援 Airflow、Python 和 Kubernetes 的政策。

Airflow 需要安裝額外的 相依性 - 這可以透過 extras 和 providers 完成。

當您安裝 Airflow 時，您需要 設定資料庫，並且在 Airflow 升級時也必須保持資料庫更新。

警告

截至 2021 年 6 月，Airflow 1.10 已終止生命週期，即使是嚴重的安全性修復也不會再收到任何修復。請按照 從 1.10 升級到 2 了解如何將已終止生命週期的 1.10 升級到 Airflow 2。

使用發布的原始碼

更多詳細資訊：從原始碼安裝

此選項最適合的情況

目標使用者

  • 熟悉從原始碼安裝和建置軟體，並意識到他們使用的軟體的完整性和出處（直到最低層級）的使用者。

您需要處理的事項

  • 您需要自行建置和安裝 airflow 及其組件。

  • 您應該開發和處理 Airflow 所有組件的部署。

  • 您負責設定資料庫、使用 airflow db 命令建立和管理資料庫綱要、自動啟動和復原、維護、清理以及 Airflow 和 Airflow Providers 的升級。

  • 您需要設定系統監控，以便您可以觀察資源並對問題做出反應。

  • 您需要根據安裝監控和回饋迴路，為安裝設定和管理適當的資源（記憶體、CPU 等）。請參閱關於需求的注意事項。

Apache Airflow 社群為此方法提供的內容

  • 您有關於如何建置軟體的 指示，但由於您可能想要使用的各種環境和工具，您可能會預期會出現特定於您的部署和環境的問題，您將必須診斷和解決這些問題。

在哪裡尋求協助

  • Slack 上的 #user-troubleshooting 頻道可用於快速的一般疑難排解問題。如果您正在尋找更長的討論並且有更多資訊要分享，請使用 GitHub 討論區。

  • Slack 上的 #user-best-practices 頻道可用於詢問和分享關於使用和部署 airflow 的最佳實務。

  • 如果您可以提供關於 Airflow 軟體的可重現問題的描述，您可以在 GitHub issues 上開啟問題

  • 如果您想回饋 Airflow，請使用 #contributors slack 頻道來建置 Airflow 本身

使用 PyPI

更多詳細資訊：從 PyPI 安裝

此選項最適合的情況

  • 當您不熟悉容器和 Docker，並且想要在實體或虛擬機器上安裝 Apache Airflow，並且您習慣使用自訂部署機制安裝和執行軟體時，此安裝方法非常有用。

  • 唯一官方支援的安裝機制是透過使用約束機制的 pip。約束檔案由 Apache Airflow 發布管理員管理，以確保您可以從 PyPI 重複安裝 Airflow，並包含所有 Providers 和必要的相依性。

  • 如果透過 PyPI 安裝，您也可以按照安裝頁面上的描述驗證從 PyPI 下載的套件的完整性和出處，但是您從 PyPI 下載的軟體是為您預先建置的，以便您可以直接安裝而無需建置，並且您不會從原始碼建置軟體。

目標使用者

  • 熟悉安裝和設定 Python 應用程式、管理 Python 環境、相依性以及使用其自訂部署機制執行軟體的使用者。

您需要處理的事項

  • 您需要自行安裝 Airflow - 其所有組件。

  • 您應該開發和處理 Airflow 所有組件的部署。

  • 您負責設定資料庫、使用 airflow db 命令建立和管理資料庫綱要、自動啟動和復原、維護、清理以及 Airflow 和 Airflow Providers 的升級。

  • 您需要設定系統監控，以便您可以觀察資源並對問題做出反應。

  • 您需要根據安裝監控和回饋迴路，為安裝設定和管理適當的資源（記憶體、CPU 等）。

Apache Airflow 社群為此方法提供的內容

  • 您有關於如何安裝軟體的 從 PyPI 安裝 指示，但由於您可能想要使用的各種環境和工具，您可能會預期會出現特定於您的部署和環境的問題，您將必須診斷和解決這些問題。

  • 您有 快速入門，您可以在其中看到使用本地執行 Airflow 的快速入門範例，您可以使用它快速啟動 Airflow 以進行本地測試和開發。但是，這僅供參考。不要期望 快速入門 已準備好用於生產環境安裝，如果您遵循此方法，則需要建置自己的生產環境就緒部署。

在哪裡尋求協助

  • Airflow Slack 上的 #user-troubleshooting 頻道可用於快速的一般疑難排解問題。如果您正在尋找更長的討論並且有更多資訊要分享，請使用 GitHub 討論區。

  • Slack 上的 #user-best-practices 頻道可用於詢問和分享關於使用和部署 airflow 的最佳實務。

  • 如果您可以提供關於 Airflow 軟體的可重現問題的描述，您可以在 GitHub issues 上開啟問題

使用生產 Docker 映像檔

更多詳細資訊：Apache Airflow 的 Docker 映像檔

此選項最適合的情況

當您熟悉容器/Docker 堆疊時，此安裝方法非常有用。它提供了在與同一實體或虛擬機器上運行的其他軟體隔離的情況下運行 Airflow 組件的能力，並且易於維護相依性。

映像檔由 Apache Airflow 發布管理員建置，它們使用來自 PyPI 的官方發布套件和官方約束檔案 - 與從 PyPI 安裝 Airflow 時使用的相同。

目標使用者

  • 熟悉容器和 Docker 堆疊，並且了解如何建置自己的容器映像檔的使用者。

  • 了解如何使用約束從 PyPI 安裝 providers 和相依性（如果他們想要擴展或自訂映像檔）的使用者。

  • 知道如何透過將多個 Docker 容器連結在一起並維護此類部署來建立使用 Docker 的部署的使用者。

您需要處理的事項

  • 如果您想要新增額外的相依性，則需要能夠自訂或擴展容器/Docker 映像檔。您需要將由多個容器組成的部署（例如使用 docker-compose）組合在一起，並確保它們連結在一起。

  • 您負責設定資料庫、使用 airflow db 命令建立和管理資料庫綱要、自動啟動和復原、維護、清理以及 Airflow 和 Airflow Providers 的升級。

  • 您負責管理您自己的自訂項目和自訂相依性的擴展。使用官方 Airflow Docker 映像檔，參考映像檔中包含的 Airflow 和 Airflow Providers 的升級由社群處理 - 當發布新版本時，您需要確保透過升級基礎映像檔來取得這些變更。但是，您負責建立一個管道來建置您自己的自訂映像檔，其中包含您自己新增的相依性和 Providers，並且需要在發布新版本的 Airflow 映像檔時重複自訂步驟並建置您自己的映像檔。

  • 您應該選擇正確的部署機制。有許多可用的容器部署選項。您可以使用自己的自訂機制、自訂 Kubernetes 部署、自訂 Docker Compose、自訂 Helm charts 等，您應該根據您的經驗和期望來選擇它。

  • 您需要設定系統監控，以便您可以觀察資源並對問題做出反應。

  • 您需要根據安裝監控和回饋迴路，為安裝設定和管理適當的資源（記憶體、CPU 等）。

Apache Airflow 社群為此方法提供的內容

  • 您有指示：建置映像檔 關於如何建置和自訂您的映像檔。

  • 您有 在 Docker 中運行 Airflow，您可以在其中看到快速入門的範例，您可以使用它快速啟動 Airflow 以進行本地測試和開發。但是，這僅供參考。不要期望將此 docker-compose.yml 檔案用於生產環境安裝，如果您選擇 Docker Compose 進行部署，則需要熟悉 Docker Compose 及其功能，並使用它建置自己的生產環境就緒部署。

  • Docker 映像檔由建置 Airflow 的同一批人管理，他們致力於在發布 Airflow 的新功能和功能時保持更新。

在哪裡尋求協助

  • 對於關於官方 Docker 映像檔的快速問題，Airflow Slack 中有 #production-docker-image 頻道。

  • Airflow Slack 上的 #user-troubleshooting 頻道可用於快速的一般疑難排解問題。如果您正在尋找更長的討論並且有更多資訊要分享，請使用 GitHub 討論區。

  • Slack 上的 #user-best-practices 頻道可用於詢問和分享關於使用和部署 airflow 的最佳實務。

  • 如果您可以提供關於 Airflow 軟體的可重現問題的描述，您可以在 GitHub issues 上開啟問題

使用官方 Airflow Helm Chart

更多詳細資訊：Apache Airflow 的 Helm Chart

此選項最適合的情況

  • 當您不僅熟悉容器/Docker 堆疊，而且還使用 Kubernetes，並且想要使用社群管理的 Kubernetes 安裝機制透過 Helm chart 安裝和維護 Airflow 時，此安裝方法非常有用。

  • 它不僅提供了在與同一實體或虛擬機器上運行的其他軟體隔離的情況下運行 Airflow 組件和管理相依性的能力，而且還提供了更輕鬆地維護、配置和升級 Airflow 的能力，這種方式是標準化的，並且將由社群維護。

  • Chart 使用官方 Airflow 生產 Docker 映像檔來運行 Airflow。

目標使用者

  • 熟悉容器和 Docker 堆疊，並且了解如何建置自己的容器映像檔的使用者。

  • 了解如何使用約束從 PyPI 安裝 providers 和相依性（如果他們想要擴展或自訂映像檔）的使用者。

  • 使用 Kubernetes 管理其基礎架構，並使用 Helm Charts 在 Kubernetes 上管理其應用程式的使用者。

您需要處理的事項

  • 如果您想要新增額外的相依性，則需要能夠自訂或擴展容器/Docker 映像檔。您需要將由多個容器組成的部署（例如使用 Docker Compose）組合在一起，並確保它們連結在一起。

  • 您負責設定資料庫。

  • Helm Chart 管理您的資料庫綱要，自動化應用程式組件的啟動、復原和重新啟動，並將它們連結在一起，因此您無需擔心這些。

  • 您負責管理您自己的自訂項目和自訂相依性的擴展。使用官方 Airflow Docker 映像檔，參考映像檔中包含的 Airflow 和 Airflow Providers 的升級由社群處理 - 當發布新版本時，您需要確保透過升級基礎映像檔來取得這些變更。但是，您負責建立一個管道來建置您自己的自訂映像檔，其中包含您自己新增的相依性和 Providers，並且需要在發布新版本的 Airflow 映像檔時重複自訂步驟並建置您自己的映像檔。

  • 您需要設定系統監控，以便您可以觀察資源並對問題做出反應。

  • 您需要根據安裝監控和回饋迴路，為安裝設定和管理適當的資源（記憶體、CPU 等）。

Apache Airflow 社群為此方法提供的內容

  • 您有指示：建置映像檔 關於如何建置和自訂您的映像檔。

  • 您有 Apache Airflow 的 Helm Chart - 關於如何配置和安裝 Helm Chart 的完整文件。

  • Helm Chart 由建置 Airflow 的同一批人管理，他們致力於在發布 Airflow 的新功能和功能時保持更新。

在哪裡尋求協助

  • 對於關於官方 Docker 映像檔的快速問題，Airflow Slack 中有 #production-docker-image 頻道。

  • 對於關於官方 Helm Chart 的快速問題，Slack 中有 #helm-chart-official 頻道。

  • Airflow Slack 上的 #user-troubleshooting 頻道可用於快速的一般疑難排解問題。如果您正在尋找更長的討論並且有更多資訊要分享，請使用 GitHub 討論區。

  • Slack 上的 #user-best-practices 頻道可用於詢問和分享關於使用和部署 airflow 的最佳實務。

  • 如果您可以提供關於 Airflow 軟體的可重現問題的描述，您可以在 GitHub issues 上開啟問題

使用託管 Airflow 服務

請關注 生態系統 頁面，以查找所有 Airflow 的託管服務。

此選項最適合的情況

  • 當您希望其他人為您管理 Airflow 安裝時，可以使用託管 Airflow 服務。

目標使用者

  • 偏好讓他人為他們管理 Airflow 並願意為此付費的使用者。

您需要處理的事項

  • 託管服務通常提供運行 Airflow 所需的一切。有關詳細資訊，請參閱託管服務的文件。

Apache Airflow 社群為此方法提供的內容

  • Airflow 社群不提供任何關於託管服務的特定文件。有關詳細資訊，請參閱託管服務的文件。

在哪裡尋求協助

  • 您的首選應該是託管服務提供的支援。Apache Airflow Slack 中有一些專門針對不同使用者群體的頻道，如果您得出結論認為問題與 Airflow 的關聯性高於託管服務，則可以使用這些頻道。

使用第三方映像檔、圖表、部署

請關注 生態系統 頁面，以查找所有第三方部署選項。

此選項最適合的情況

  • 如果之前提到的任何官方方法都不適用於您，或者您過去曾使用過這些方法，則這些安裝方法非常有用。但是，建議您在考慮任何變更時，都應該考慮切換到 Apache Airflow 社群或託管服務官方支援的方法之一。

目標使用者

  • 過去曾使用其他安裝方法，或發現官方方法因其他原因而不足的使用者。

您需要處理的事項

  • 取決於第三方提供的內容。請查看第三方的文件。

Apache Airflow 社群為此方法提供的內容

  • Airflow 社群不提供任何關於第三方方法的特定文件。有關詳細資訊，請參閱託管服務的文件。

在哪裡尋求協助

  • 取決於第三方提供的內容。請查看您使用的第三方部署的文件。

關於最低需求的注意事項

經常有人問及生產系統的 Airflow 最低需求，但這個問題無法簡單回答。

Airflow 可能需要的需求取決於許多因素，包括（但不限於）：

  • 安裝 Airflow 的部署方式（請參閱上面安裝 Airflow 的方法）

  • 部署環境的需求（例如 Kubernetes、Docker、Helm 等），這些需求完全獨立於 Airflow（例如 DNS 資源、節點/資源共享），並且可能需要更多（或更少）的 pods 和容器，這可能取決於特定技術/雲端/監控整合等的選擇。

  • 資料庫、硬體、網路等的技術細節，您的部署正在其上運行

  • 您新增到 DAGS、組態設定、外掛程式、設定等中的程式碼的複雜性（請注意，Airflow 運行 DAG 作者和部署管理員提供的程式碼）

  • 您安裝和使用的 providers 的數量和選擇（Airflow 有超過 80 個 providers），這些 providers 可以由部署管理員選擇安裝，並且使用它們可能需要更多資源。

  • 您在調整 Airflow 時使用的參數選擇。Airflow 有許多組態設定參數可以根據您的需求進行微調

  • 您運行的 DagRuns 和任務實例的數量，以及每個實例的並行實例數

  • 您運行的任務有多複雜

上述「DAG」特性將隨著時間推移而改變，甚至會根據一天或一周中的時間而改變，因此您必須準備好持續監控系統並調整參數，使其順利運行。

雖然我們可以為某些開發「快速入門」提供一些特定的最低需求 - 例如在我們的 在 Docker 中運行 Airflow 快速入門指南中，但不可能為生產系統提供任何最低需求。

思考 Airflow 實例的資源分配的最佳方式是從製程控制理論的角度來思考 - 其中有兩種類型的系統

  1. 完全可預測，旋鈕和變數很少，您可以可靠地設定旋鈕的值，並且可以輕鬆確定系統的行為

  2. 複雜的系統，具有多個變數，難以預測，並且您需要監控系統並持續調整旋鈕，以確保系統順利運行。

Airflow（以及通常在雲端服務上運行的任何現代系統，具有多個負責資源的層級以及多個參數來控制其行為）是一個複雜的系統，它們更屬於第二類。如果您決定自行在生產環境中運行 Airflow，您應該準備好進行監控/觀察/調整回饋迴路，以確保系統順利運行。

擁有一個良好的監控系統，讓您可以監控系統並調整參數，對於將其付諸實踐至關重要。

您也可以使用一些指南來優化您的資源使用量。微調您的排程器效能 是一個很好的起點，可以微調您的排程器，您也可以遵循 最佳實務 指南，以確保您以最有效的方式使用 Airflow。

此外，託管 Airflow 服務提供的重要事項之一是，它們為您做出許多武斷的選擇並微調系統，因此您不必過於擔心。使用此類託管服務，通常可以轉動的旋鈕和可以做出的選擇要少得多，並且您付費的原因之一是託管服務提供商為您管理系統並提供付費支援，並允許您根據需要擴展系統並分配正確的資源 - 遵循在那裡做出的關於您可能擁有的部署種類的選擇。

這篇文章對您有幫助嗎？