生產環境部署¶
現在是時候將您的 DAG 部署到生產環境了。要做到這一點，首先，您需要確保 Airflow 本身已準備好用於生產環境。讓我們看看您需要採取哪些預防措施。
資料庫後端¶
Airflow 預設配備 SQLite 後端。這允許使用者在沒有任何外部資料庫的情況下執行 Airflow。但是，這種設定僅適用於測試目的；在生產環境中執行預設設定可能會在多種情況下導致資料遺失。如果您想要執行生產級的 Airflow，請確保您設定後端為外部資料庫，例如 PostgreSQL 或 MySQL。
您可以使用以下組態變更後端
[database]
sql_alchemy_conn = my_conn_string
變更後端後，airflow 需要建立操作所需的所有表格。建立一個空的 DB，並授予 Airflow 的使用者 CREATE/ALTER 權限。完成後，您可以執行 -
airflow db migrate
migrate 會追蹤已套用的遷移，因此您可以根據需要經常執行它。
注意
在 Airflow 2.7.0 版本之前，airflow db upgrade 用於套用遷移，但是，它已被棄用，改用 airflow db migrate。
多節點叢集¶
Airflow 預設使用 SequentialExecutor。但是，就其性質而言，使用者最多只能一次執行一個任務。Sequential Executor 也會在執行任務時暫停排程器，因此不建議在生產環境設定中使用。對於單一機器，您應該使用 LocalExecutor。對於多節點設定，您應該使用 Kubernetes executor 或 Celery executor。
設定執行器後，必須確保叢集中的每個節點都包含相同的組態和 DAG。Airflow 發送簡單的指令，例如「執行 DAG Y 的任務 X」，但不發送任何 DAG 檔案或組態。您可以使用簡單的 cronjob 或任何其他機制來同步節點之間的 DAG 和組態，例如，每 5 分鐘從 git 儲存庫檢出所有節點上的 DAG。
記錄¶
如果您在叢集中使用可拋棄式節點，請將記錄儲存設定為分散式檔案系統 (DFS)，例如 S3 和 GCS，或外部服務，例如 Stackdriver Logging、Elasticsearch 或 Amazon CloudWatch。這樣，即使節點關閉或被替換，記錄仍然可用。請參閱 任務記錄 以取得組態資訊。
注意
記錄僅在任務完成後才會顯示在您的 DFS 中。您可以在 UI 本身中檢視任務執行時的記錄。
組態¶
Airflow 捆綁了一個預設的 airflow.cfg 組態檔。您應該對跨部署變更的組態使用環境變數，例如 metadata DB、密碼等。您可以使用格式 AIRFLOW__{SECTION}__{KEY} 來完成此操作
AIRFLOW__DATABASE__SQL_ALCHEMY_CONN=my_conn_id
AIRFLOW__WEBSERVER__BASE_URL=http://host:port
某些組態（例如 Airflow 後端連線 URI）也可以從 bash 指令衍生而來
sql_alchemy_conn_cmd = bash_command_to_run
生產環境容器映像檔¶
我們提供 適用於 Apache Airflow 的 Docker 映像檔 (OCI)，以便在容器化環境中使用。考慮使用它來保證軟體無論部署在哪裡都始終以相同的方式執行。
Kubernetes 的 Helm Chart¶
Helm 提供了一種將軟體部署到 Kubernetes 叢集的簡單機制。我們維護 官方 Helm chart for Airflow，可協助您定義、安裝和升級部署。Helm Chart 使用 我們的官方 Docker 映像檔和 Dockerfile，它們也由社群維護和發佈。
Airflow 線上升級¶
Airflow 在設計上是一個分散式系統，雖然基本 Airflow 部署 通常需要完全重新啟動 Airflow 才能升級，但當您在分散式部署中執行 Airflow 時，可以無需停機即可升級 Airflow。
當 Airflow metadata 資料庫結構描述沒有變更時，這種線上升級是可能的，因此當您升級相同次要 Airflow 版本的修補程式級別 (bugfix) 版本，或在檢閱發佈說明和資料庫遷移參考並確認它們之間沒有資料庫結構描述變更後，在相鄰的次要版本 (功能) 之間升級 Airflow 時，您應該以此為目標。
在某些情況下，當資料庫遷移不顯著時，這種線上遷移也可能在先升級 Airflow 資料庫並在次要版本之間進行的情況下實現，但是，這不建議使用，您應該自行承擔風險執行此操作，仔細檢閱要套用於資料庫結構描述的修改，並評估這種升級的風險 - 它需要深入了解 Airflow 資料庫資料庫 ERD 結構描述 並檢閱資料庫遷移參考。您應該始終先在預備環境中徹底測試這種升級。通常，與這種線上升級準備相關的成本將高於 Airflow 短暫停機的成本，因此我們強烈建議不要進行這種線上升級。
在生產環境中執行之前，請務必在預備環境中測試這種線上升級程序，以避免任何意外和副作用。
當涉及到線上升級 Webserver、Triggerer 元件時，如果您在獨立環境中執行它們，並且每個元件都有多個執行個體，您可以逐個滾動重新啟動它們，而不會造成任何停機時間。這通常應該作為您升級程序的第一步來完成。
當您執行具有獨立 DAG 處理器 的部署時，在獨立 DAG 處理部署中，DAG 處理器 不是水平擴展的 - 即使您有更多處理器，每個特定資料夾一次通常也只有一個 DAG 處理器 正在執行，因此您可以停止它並啟動新的處理器 - 但由於 DAG 處理器 不是關鍵元件，因此它可以承受短暫的停機時間。
當涉及到升級排程器和工作節點時，您可以使用您使用的執行器的線上升級功能
對於 本機執行器，您的任務作為排程器的子程序執行，如果您不停止排程器，則無法升級排程器。您可以暫停所有 DAG 並等待正在執行的任務完成，或者只是停止排程器並終止它執行的所有任務 - 然後您需要在升級完成後手動清除並重新啟動這些任務（或依賴於為停止的任務設定的
retry）。對於 Celery 執行器，您必須先將您的工作節點置於離線模式（通常是透過向工作節點設定單個
TERM訊號），等待工作節點完成所有正在執行的任務，然後升級程式碼（例如透過替換工作節點執行的映像檔並重新啟動工作節點）。您可以透過flower監控工具監控您的工作節點，並查看正在執行的任務數量降至零。工作節點升級完成後，它們將自動置於線上模式並開始接收新任務。然後，您可以以滾動重新啟動模式升級Scheduler。對於 Kubernetes 執行器，您可以以滾動重新啟動模式升級排程器觸發器、Web 伺服器，通常您不必擔心工作節點，因為它們由 Kubernetes 叢集管理，並且在升級和重新啟動後將自動被
Schedulers採用。對於 :doc:
CeleryKubernetesExecutor <apache-airflow-providers-celery:celery_kubernetes_executor>，您遵循與CeleryExecutor相同的程序 - 您將工作節點置於離線模式，等待正在執行的任務完成，升級工作節點，然後以滾動重新啟動模式升級排程器、觸發器和 Web 伺服器 - 這也應該採用透過執行器的KubernetesExecutor部分執行的任務。
大多數滾動重新啟動升級場景都在 Apache Airflow 的 Helm Chart 中實作，因此您可以使用它來升級您的 Airflow 部署而不會造成任何停機時間 - 特別是當您執行 Airflow 的修補程式級別升級時。
Kerberos 驗證的工作節點¶
Apache Airflow 具有用於驗證與 KDC（金鑰發佈中心）操作的內建機制。Airflow 有一個單獨的指令 airflow kerberos，它充當權杖重新整理器。它使用預先設定的 Kerberos Keytab 在 KDC 中進行驗證以取得有效的權杖，然後在目前的權杖到期視窗內定期重新整理有效的權杖。
每個重新整理請求都使用設定的主體，並且只有對指定主體有效的 keytab 才能檢索驗證權杖。
在這種情況下實作正確安全機制的最佳實務是確保工作節點工作負載無法存取 Keytab，而只能存取定期重新整理的臨時驗證權杖。這可以在 Docker 環境中透過在單獨的容器中執行 airflow kerberos 指令和工作節點指令來實現 - 其中只有 airflow kerberos 權杖可以存取 Keytab 檔案（最好組態為秘密資源）。這兩個容器應共用一個磁碟區，臨時權杖應由 airflow kerberos 寫入，並由工作節點讀取。
在 Kubernetes 環境中，這可以透過 sidecar 的概念來實現，其中 Kerberos 權杖重新整理器和工作節點都是同一個 Pod 的一部分。只有 Kerberos sidecar 可以存取 Keytab 秘密，並且同一個 Pod 中的兩個容器共用磁碟區，臨時權杖由 sidecar 容器寫入，並由工作節點容器讀取。
此概念在 Apache Airflow 的 Helm Chart 中實作。
Google Cloud 上的安全伺服器與服務存取¶
本節介紹當您的 Airflow 環境部署在 Google Cloud 上，或您連線到 Google 服務，或您連線到 Google API 時，安全存取伺服器和服務的技術和解決方案。
IAM 和服務帳戶¶
您不應依賴內部網路分段或防火牆作為我們的主要安全機制。為了保護您組織的資料，您發出的每個請求都應包含發送者身分。在 Google Cloud 的情況下，身分由 IAM 和服務帳戶 提供。每個 Compute Engine 執行個體都有一個關聯的服務帳戶身分。它提供密碼編譯憑證，您的工作負載可以使用這些憑證在呼叫 Google API 或第三方服務時證明其身分。每個執行個體僅能存取短效憑證。如果您使用 Google 管理的服務帳戶金鑰，則私密金鑰始終託管，並且永遠無法直接存取。
如果您使用 Kubernetes Engine，則可以使用 Workload Identity 為個別 pod 指派身分。
有關 Airflow 中服務帳戶的更多資訊，請參閱 Google Cloud 連線
模擬服務帳戶¶
如果您需要存取其他服務帳戶，您可以模擬其他服務帳戶，以將權杖與預設身分交換為另一個服務帳戶。因此，帳戶金鑰仍然由 Google 管理，並且您的工作負載無法讀取。
不建議產生服務帳戶金鑰並將其儲存在 metadata 資料庫或秘密後端中。即使使用後端秘密，服務帳戶金鑰也可用於您的工作負載。
存取 Compute Engine 執行個體¶
如果您想要建立與 Compute Engine 執行個體的 SSH 連線，您必須擁有此執行個體的網路位址和存取憑證。為了簡化此任務，您可以使用 ComputeEngineHook 而不是 SSHHook
ComputeEngineHook 支援使用 Google OS Login 服務進行授權。這是一種極其穩健的方式來正確管理 Linux 存取，因為它將短效 ssh 金鑰儲存在 metadata 服務中，提供用於存取和 sudo 權限檢查的 PAM 模組，並提供 nsswitch 使用者查閱到 metadata 服務中。
它也解決了隨著基礎架構增長而出現的探索問題。您可以使用執行個體名稱而不是網路位址。
存取 Amazon Web Service¶
由於 Web Identity Federation，您可以將 Google Cloud Platform 身分交換為 Amazon Web Service 身分，這實際上意味著可以存取 Amazon Web Service 平台。如需更多資訊，請參閱：使用 Web Identity Federation 從 Google Cloud 進行 AWS 身份驗證