• 首頁
• 管理 DAGs 檔案

管理 DAGs 檔案

當您建立新的或修改現有的 DAG 檔案時，必須將它們部署到環境中。本節將描述一些您可以使用的基本技術。

將 DAGs 烘焙至 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

然後將其發佈到可存取的 Registry 中

docker push my-company/airflow:8a0da78

最後，使用該映像檔更新 Airflow Pod

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 註解將確保 Pod 在 Helm 升級時重新整理。

如果您要從私有儲存庫部署映像檔，則需要建立一個 Secret，例如 gitlab-registry-credentials (詳細資訊請參閱 從私有 Registry 拉取映像檔)，並使用 --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 掛載 DAGs

此選項將使用具有 ReadWriteMany 存取模式的持久卷聲明 (Persistent Volume Claim)。Scheduler Pod 將每隔設定的秒數，從 Git 儲存庫將 DAGs 同步到 PVC 上。其他 Pod 將讀取已同步的 DAGs。並非所有卷插件都支援 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 掛載 DAGs

此選項將在每個 Scheduler、Webserver（如果 airflowVersion < 2.0.0）和 Worker Pod 上使用持續運行的 Git-Sync Sidecar。Git-Sync Sidecar 容器將每隔設定的秒數，從 Git 儲存庫同步 DAGs。如果您使用 KubernetesExecutor，Git-sync 將作為 Worker Pod 上的 Init Container 執行。

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 和持久性來管理 DAGs 是可行的，但通常不建議這樣做，除非部署管理員仔細考慮了它帶來的權衡。在某些情況下，不使用持久性的 git-sync 會有其他權衡（例如 DAGs 同步的延遲與 Git 伺服器的速率限制），這些權衡通常可以減輕（例如，當新提交被推送到儲存庫時，透過 Webhook 向 git-sync 容器發送訊號），但可能在某些情況下，您仍然可能希望同時選擇 git-sync 和持久性，但作為部署管理員，您應該意識到它帶來的一些後果。

git-sync 解決方案主要設計用於本地、符合 POSIX 標準的卷，以便將 Git 儲存庫簽出到其中。從 git-sync 同步提交的過程部分涉及在一個新建立的資料夾中簽出新版本的文件，並在簽出完成後將符號連結交換到新資料夾。這樣做是為了確保整個 DAGs 資料夾始終保持一致。git-sync 使用符號連結交換的方式，確保 DAGs 的解析始終在整個 DAG 資料夾中一組一致的（基於單次提交的）檔案上進行。

然而，當 git-sync 運作的資料夾不是本機卷，而是持久卷（因此實際上是網路化的、分散式卷）時，這種方法可能會產生不良的副作用。根據持久卷背後的技術，可能會以不同的方式處理 git-sync 方法，並產生不明顯的後果。各種 K8S 安裝都有許多持久性解決方案可用，並且每個解決方案都有不同的特性，因此您需要仔細測試和監控您的檔案系統，以確保這些不良的副作用不會影響您。這些影響可能會隨著時間的推移而改變，或者取決於 Dag 檔案處理器掃描檔案的頻率、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 掛載 DAGs

在這種方法中，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 儲存庫掛載 DAGs

如果您尚未建立私有儲存庫，請在 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，這樣您就不容易受到中間人攻擊。此過程記錄在 生產環境指南 中。

上一步 下一步

這個條目有幫助嗎？