• 主頁
• 管理 DAG 檔案

管理 DAG 檔案

建立新 DAG 檔案或修改現有 DAG 檔案時，需要將其部署到環境中。本節將介紹一些您可以使用的基本技術。

將 DAG 檔案整合到 Docker 映象中

使用這種方法，您可以將 DAG 檔案和相關程式碼包含在 Airflow 映象中。

這種方法需要使用新的 Docker 映象重新部署 helm chart 中的服務，以便部署新的 DAG 程式碼。當 DAG 程式碼預計不會頻繁更改時，這種方法效果很好。

docker build --pull --tag "my-company/airflow:8a0da78" . -f - <<EOF
FROM apache/airflow

COPY ./dags/ \${AIRFLOW_HOME}/dags/

EOF

注意

在 2.0.2 版本之前的 Airflow 映象中，存在一個錯誤，需要使用稍長的 Dockerfile，以確保映象與 OpenShift 相容（即 DAG 具有與其它檔案類似的 root 組）。在 2.0.2 版本中，此問題已修復。

docker build --pull --tag "my-company/airflow:8a0da78" . -f - <<EOF
FROM apache/airflow:2.0.2

USER root

COPY --chown=airflow:root ./dags/ \${AIRFLOW_HOME}/dags/

USER airflow

EOF

然後將其釋出到可訪問的倉庫中

docker push my-company/airflow:8a0da78

最後，使用該映象更新 Airflow Pods

helm upgrade --install airflow apache-airflow/airflow \
  --set images.airflow.repository=my-company/airflow \
  --set images.airflow.tag=8a0da78

如果您正在部署具有固定標籤的映象，您需要確保每次都拉取該映象。

警告

使用固定標籤僅應用於測試/開發目的。使用相同的標籤是一種不良實踐，因為您將丟失程式碼的歷史記錄。

helm upgrade --install airflow apache-airflow/airflow \
  --set images.airflow.repository=my-company/airflow \
  --set images.airflow.tag=8a0da78 \
  --set images.airflow.pullPolicy=Always \
  --set airflowPodAnnotations.random=r$(uuidgen)

隨機生成的 Pod 註解將確保在進行 helm 升級時 Pods 被重新整理。

如果您正在從私有倉庫部署映象，您需要建立一個 Secret，例如 gitlab-registry-credentials（詳情請參閱 從私有倉庫拉取映象），並使用 --set registry.secretName 指定它

helm upgrade --install airflow apache-airflow/airflow \
  --set images.airflow.repository=my-company/airflow \
  --set images.airflow.tag=8a0da78 \
  --set images.airflow.pullPolicy=Always \
  --set registry.secretName=gitlab-registry-credentials

使用 git-sync

使用啟用持久化的 git-sync sidecar 掛載 DAG 檔案

此選項將使用一個訪問模式為 ReadWriteMany 的 Persistent Volume Claim。scheduler pod 將每隔配置的秒數將 DAG 檔案從 Git 倉庫同步到 PVC 上。其他 Pods 將讀取已同步的 DAG 檔案。並非所有卷外掛都支援 ReadWriteMany 訪問模式。詳情請參閱 持久卷訪問模式。

helm upgrade --install airflow apache-airflow/airflow \
  --set dags.persistence.enabled=true \
  --set dags.gitSync.enabled=true
  # you can also override the other persistence or gitSync values
  # by setting the  dags.persistence.* and dags.gitSync.* values
  # Please refer to values.yaml for details

使用未啟用持久化的 git-sync sidecar 掛載 DAG 檔案

此選項將在每個 scheduler、webserver (如果 airflowVersion < 2.0.0) 和 worker pod 上使用一個始終執行的 Git-Sync sidecar。Git-Sync sidecar 容器將每隔配置的秒數將 DAG 檔案從 Git 倉庫同步到。如果您正在使用 KubernetesExecutor，Git-sync 將作為 init 容器在您的 worker pods 上執行。

helm upgrade --install airflow apache-airflow/airflow \
  --set dags.persistence.enabled=false \
  --set dags.gitSync.enabled=true
  # you can also override the other gitSync values
  # by setting the  dags.gitSync.* values
  # Refer values.yaml for details

使用 apache-airflow >= 2.0.0 時，DAG 序列化 預設啟用，因此 Webserver 不需要訪問 DAG 檔案，所以 git-sync sidecar 不在 Webserver 上執行。

結合使用 git-sync 和持久化的注意事項

雖然可以將 git-sync 和持久化同時用於 DAG 檔案，但通常不建議這樣做，除非部署管理者仔細考慮了其帶來的權衡。在某些情況下，不使用持久化的 git-sync 也有其他權衡（例如 DAG 同步延遲與 Git 伺服器的速率限制），這些權衡通常可以緩解（例如當有新提交推送到倉庫時，透過 web-hooks 向 git-sync 容器傳送訊號），但在某些情況下，您仍然可能希望將 git-sync 和持久化結合使用，但作為部署管理者，您應該意識到它的一些後果。

git-sync 解決方案主要設計用於本地的、符合 POSIX 標準的卷，將 Git 倉庫檢出到其中。git-sync 同步提交過程的一部分涉及在新建立的資料夾中檢出新版本的檔案，並在檢出完成後將符號連結切換到新資料夾。這樣做是為了確保整個 dags 資料夾始終保持一致。git-sync 透過符號連結切換的方式，確保解析 dags 始終在整個 DAG 資料夾中一個一致的（基於單次提交的）檔案集合上工作。

然而，當 git-sync 工作的資料夾不是本地卷而是持久卷（因此實際上是一個網路分散式卷）時，這種方法可能會產生不良的副作用。取決於持久卷背後的技術，可能會以不同的方式處理 git-sync 方法併產生不明顯的後果。有許多適用於各種 K8S 安裝的持久化解決方案，它們各自具有不同的特性，因此您需要仔細測試和監控您的檔案系統，以確保這些不良副作用不會影響您。這些影響可能會隨時間變化，或取決於諸如 Dag File Processor 掃描檔案的頻率、您的 dags 的數量和複雜性、您的持久卷的遠端程度和分散式程度、您為某些檔案系統分配的 IOPS 數量（通常這類檔案系統的一個高價特性是您可以獲得的 IOPS 數量）以及許多其他因素。

git-sync 透過符號連結切換的方式工作，通常會導致吞吐量線性增長以及潛在的同步延遲。檢出產生的網路流量以突發形式出現，並且突發流量與倉庫中的檔案數量和大小呈線性比例，這使得它容易受到突然和意外的需求增長的影響。大多數持久化解決方案對於較小/較短的突發流量工作“足夠好”，但當它們超出特定閾值時，您需要升級網路到更強大且昂貴的選項。這很難控制且無法緩解，因此您可能突然面臨這樣的情況：需要為 IOPS/持久化選項支付更多費用，以使您的 dags 保持充分同步，從而避免不一致和同步延遲。

您可能觀察到的副作用

• 在新提交被檢出時出現的網路/通訊流量突發（因為快速連續進行刪除舊檔案、建立新檔案、符號連結切換的操作）。

• 在 DAGs 同步過程中，DAG 資料夾中的檔案之間暫時的不一致（由於在叢集中將更改分發到各個節點的單個檔案時存在延遲）。

• 當您的 DAG 數量增長時，持久化解決方案效能的明顯下降，這種下降可能會放大上述副作用。

• 一些持久化解決方案可能缺乏 git-sync 執行同步所需的檔案系統功能（例如更改許可權或建立符號連結）。雖然這些問題通常可以緩解，但僅推薦將 git-sync 與完全符合 POSIX 檔案系統標準的持久化檔案系統配合使用。

一般建議僅將 git-sync 與本地卷一起使用，如果您還想使用持久化，您需要確保您使用的持久化解決方案符合 POSIX 標準，並監控它可能產生的副作用。

使用 git-sync 同步多個 Git 倉庫

Helm Chart 中的 Airflow git-sync 整合不允許同時配置多個倉庫進行同步。DAG 資料夾必須來自單個 Git 倉庫。但是，可以使用 子模組 建立一個“傘形”倉庫，您可以使用它將多個 Git 倉庫一起檢出（使用 --submodules recursive 選項）。有 Airflow 使用者透過這種“傘形”倉庫方法將數百個倉庫作為子模組組織起來的成功案例。然而，當您選擇這種解決方案時，您需要找出如何連結子模組、何時在“子模組”倉庫更改時更新傘形倉庫，並找出版本控制方法並自動化它。這可能像始終使用所有子模組倉庫的最新版本一樣簡單，或者像跨多個團隊管理共享庫、dags 和程式碼的版本一樣複雜，並按照您的釋出流程進行。

這種複雜方法的一個例子可以在 Airflow Summit 的 大規模管理 dags 演講中找到。

從外部填充的 PVC 掛載 DAG 檔案

使用這種方法，Airflow 將從具有 ReadOnlyMany 或 ReadWriteMany 訪問模式的 PVC 讀取 dags。您必須確保 PVC 已填充/更新了所需的 dags（這不會由 chart 處理）。您將卷宣告的名稱傳遞給 chart。

helm upgrade --install airflow apache-airflow/airflow \
  --set dags.persistence.enabled=true \
  --set dags.persistence.existingClaim=my-volume-claim \
  --set dags.gitSync.enabled=false

使用 Git-Sync sidecar 從私有 GitHub 倉庫掛載 DAG 檔案

如果您尚未建立私有倉庫，請在 GitHub 上建立一個。

然後建立您的 SSH 金鑰。

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

將公鑰新增到您的私有倉庫中（在 Settings > Deploy keys 下）。

您必須將私有 SSH 金鑰轉換為 base64 字串。您可以像這樣轉換私有 SSH 金鑰檔案：

base64 <my-private-ssh-key> -w 0 > temp.txt

然後從 temp.txt 檔案中複製字串。接下來，您將其新增到您的 override-values.yaml 檔案中。

在此示例中，您將建立一個名為 override-values.yaml 的 yaml 檔案，以覆蓋 values.yaml 檔案中的值，而不是使用 --set。

dags:
  gitSync:
    enabled: true
    repo: git@github.com:<username>/<private-repo-name>.git
    branch: <branch-name>
    subPath: ""
    sshKeySecret: airflow-ssh-secret
extraSecrets:
  airflow-ssh-secret:
    data: |
      gitSshKey: '<base64-converted-ssh-private-key>'

不要忘記複製您的私鑰 base64 字串。

最後，在您的 Airflow Helm chart 目錄下，您可以安裝 Airflow。

helm upgrade --install airflow apache-airflow/airflow -f override-values.yaml

如果您正確完成了所有步驟，Git-Sync 將會獲取您在私有 GitHub 倉庫中對 dags 所做的更改。

您應該更進一步，並設定 dags.gitSync.knownHosts，以避免中間人攻擊。此過程已在 生產環境指南 中記錄。

上一頁 下一頁

本條目有幫助嗎？