Question 1

なぜOpenTelemetryが有効な状態でDeadlineAlertがトリガーされると、Airflow Triggererが 'unhashable type: dict' でクラッシュするのですか？

Accepted Answer

これはAirflow 3.2.1における既知のバグで、コールバック属性内のunhashable dictが原因でOpenTelemetry metrics integrationが失敗します。恒久的な修正は後のリリース（PR #67527）に含まれています。この修正を含むバージョンにアップグレードしてください。一時的な回避策として、airflow.cfgで`[metrics] otel_on = False`を設定するか、OTEL設定を削除してOpenTelemetryを無効にします。

Question 2

Apache AirflowでContent Security Policyを使用している場合、DAG詳細ページが「Loading」のまま止まってしまうのはなぜですか？

Accepted Answer

これはAirflow 3.2.1における既知の問題で、MonacoエディタがCDNから読み込まれていたため、Content Security Policy (CSP) 設定に違反していました。解決策は、Apache Airflowバージョン3.2.2以降にアップグレードすることです。このバージョンではPR #66647によりMonacoが外部から読み込まずにバンドルされるようになり、CSP違反が解消され、UIが正しく読み込まれるようになりました。

Question 3

Airflow SSHRemoteJobOperatorにおける環境変数の値を介したOSコマンドインジェクション（RCE）を修正する方法

Accepted Answer

影響を受けるバージョン: apache-airflow-providers-ssh 4.3.0 から 6.1.0。`build_posix_wrapper_command` メソッドは `environment` の値をシングルクォートで一度しかエスケープせず、その後それらをさらにシングルクォートで囲まれた `job_script='...'` リテラルの内部に埋め込むため、外側のリモートシェルでは値がクォートされない状態になります。その結果、値に含まれる `$( )`、バッククォート、`;` が SSH 接続のサービスアカウントの権限で実行されます。修正方法: 各値を `shlex.quote()` でクォートし、その後 export ブロック全体を外側の `job_script` リテラル用にもう一度エスケープします(コマンドにすでに施されているのと同じ処理です)。同じ変更を `build_windows_wrapper_command` にも適用してください。パッチ適用までの緩和策: 修正版がリリースされ次第、SSH プロバイダーをアップグレードしてください。トリガー時のユーザー入力(例: `dag_run.conf`)を `environment` に直接渡さないでください。まず Dag 内で検証・サニタイズを行ってください(文字を許可リストに限定し、シェルのメタ文字を拒否する)。また、Dag のトリガー権限は信頼できるロールのみに制限してください。Dag をトリガーできる低権限の `USER` ロールが、この脆弱性を悪用してリモート SSH ホスト上でコマンドを実行する可能性があるためです。

Question 4

Airflow DAG run または task instance をクリアする際に "TypeError: unsupported type for timedelta seconds component: dict" を修正する方法は？

Accepted Answer

これは、DAG が DeadlineReference.DAGRUN_QUEUED_AT を使用する場合に Airflow 3.3.0+ に影響します。deadline_alert.interval 列は現在 JSON serde エンベロープとして保存されますが、クリア経路はその dict を直接 timedelta(seconds=...) に渡します。回避策: UI でクリアする代わりにタスクインスタンスを削除する、またはクリアする前に DAG から deadline パラメータを一時的に削除する。恒久的なコード修正は airflow-core/src/airflow/models/taskinstance.py にあります: _recalculate_dagrun_queued_at_deadlines() は、他の deadline コンシューマーと同様に、timedelta を呼び出す前に deadline_alert.interval をデシリアライズする必要があります。

Question 5

Airflow KubernetesExecutor のタスクが Queued のまま停止し、'Invalid executor_config' と表示されるのをどう修正すればよいですか？

Accepted Answer

レガシーのネストされた executor_config 形式は Airflow 3.x ではもはや有効ではありません。KubernetesExecutor ラッパーをモダンな pod_override キーに置き換えてください：

executor_config={
    "pod_override": {
        "apiVersion": "v1",
        "kind": "Pod",
        "spec": {
            # コンテナ、リソース、アノテーションなどの Pod オーバーライド
        },
    }
}

使用しないでください：

executor_config={"KubernetesExecutor": {"config_file": "/some/path/kubeconfig.yaml"}}

スケジューラにカスタム kubeconfig を使用させる必要がある場合は、pod_override 経由ではなくグローバルに設定してください。airflow.cfg で：

[kubernetes_executor]
kube_config_path = /some/path/kubeconfig.yaml

あるいは、次を設定します：

export KUBECONFIG=/some/path/kubeconfig.yaml

その後、Airflow スケジューラを再起動します。スケジューラログの Invalid executor_config は拒否されたレガシー形式を示しています。executor_config を修正すると、タスクが Queued のままスタックし続けるのを防げます。

Apache Airflow

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト