requirements.txt での Python 依存関係の管理 - Amazon Managed Workflows for Apache Airflow
Amazon MWAA CLI ユーティリティを使用した DAG のテストPyPI.org 要件ファイルフォーマットを使用した Python 依存関係のインストールAmazon MWAA コンソールでログを有効にします。CloudWatch Logs コンソールでログにアクセスするApache Airflow UI でエラーにアクセスするrequirements.txt シナリオ例

requirements.txt での Python 依存関係の管理

このトピックでは、Amazon Managed Workflows for Apache Airflow 環境の requirements.txt ファイルに Python の依存関係をインストールして管理する方法について説明します。

Amazon MWAA CLI ユーティリティを使用した DAG のテスト

  • コマンドラインインターフェイス (CLI) ユーティリティは、Amazon Managed Workflows for Apache Airflow 環境をローカルに複製します。

  • CLI は、Amazon MWAA のプロダクションイメージに似た Docker コンテナイメージをローカルでビルドします。Amazon MWAA にデプロイする前に、ローカルの Apache Airflow 環境を実行して DAG、カスタムプラグイン、依存関係を開発およびテストできます。

  • CLI を実行するには、GitHub の aws-mwaa-docker-images を参照してください。

PyPI.org 要件ファイルフォーマットを使用した Python 依存関係のインストール

次のセクションでは、PyPI.org 要件ファイル形式 に従って Python 依存関係をインストールするさまざまな方法について説明します。

オプション 1: Python Package インデックスからの Python 依存関係

次のセクションでは、requirements.txt ファイルの Python Package インデックス から Python 依存関係を指定する方法について説明します。

Apache Airflow v3

  1. ローカルでテストします。requirements.txt ファイルを作成する前に、ライブラリを繰り返し追加してパッケージとバージョンの適切な組み合わせを見つけてください。Amazon MWAA CLI ユーティリティを実行するには、GitHub の aws-mwaa-docker-images を参照してください。

  2. Apache Airflow パッケージのエクストラを確認してください。Amazon MWAA で Apache Airflow v3 用にインストールされているパッケージのリストにアクセスするには、GitHub ウェブサイトの aws-mwaa-docker-images requirements.txt を参照してください。

  3. 制約ステートメントを追加します。Apache Airflow v3 環境用の制約ファイルを requirements.txt ファイルの先頭に追加します。Apache Airflow の制約ファイルには、Apache Airflow のリリース時点で利用可能なプロバイダーのバージョンが指定されています。

    次の例では、{environment-version} をお使いの環境のバージョン番号に、{Python-version} を環境と互換性のある Python のバージョンに置き換えます。

    Apache Airflow 環境と互換性のある Python のバージョンについては、Apache Airflow のバージョン を参照してください。

    --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-{Airflow-version}/constraints-{Python-version}.txt"

    制約ファイルが xyz==1.0 パッケージが環境内の他のパッケージと互換性がないと判断した場合、pip3 install は環境に互換性のないライブラリがインストールされるのを防ぐために失敗しま す。いずれかのパッケージのインストールが失敗した場合、CloudWatch Log の対応するログストリームで、各 Apache Airflow コンポーネント (スケジューラ、ワーカー、ウェブサーバー) のエラーログにアクセスできます。ログタイプの詳細については、Amazon CloudWatch の Airflow ログへのアクセス を参照してください。

  4. Apache Airflow パッケージ。パッケージエクストラとバージョン (==) を追加します。これにより、同じ名前で異なるバージョンのパッケージが環境にインストールされるのを防ぐことができます。

    apache-airflow[package-extra]==2.5.1

  5. Python ライブラリ パッケージ名とバージョン (==) を requirements.txt ファイルに追加します。これにより、PyPI.org からの将来の重大な更新が自動的に適用されるのを防ぐことができます。

    library == version
    例 Boto3 と psycopg2-binary

    この例は、デモンストレーションのみを目的としています。boto および psycopg2-binary ライブラリは、Apache Airflow v3 のベースインストールに含まれており、requirements.txt ファイルで指定する必要はありません。

    boto3==1.17.54
boto==2.49.0
botocore==1.20.54
psycopg2-binary==2.8.6

    パッケージがバージョンなしで指定されている場合、Amazon MWAA は PyPI.org からパッケージの最新バージョンをインストールします。このバージョンは、お客様の requirements.txt 内の他のパッケージと競合できます。

Apache Airflow v2

  1. ローカルでテストします。requirements.txt ファイルを作成する前に、ライブラリを繰り返し追加してパッケージとバージョンの適切な組み合わせを見つけてください。Amazon MWAA CLI ユーティリティを実行するには、GitHub の aws-mwaa-docker-images を参照してください。

  2. Apache Airflow パッケージのエクストラを確認してください。Amazon MWAA で Apache Airflow v2 にインストールされているパッケージのリストにアクセスするには、GitHub ウェブサイトの aws-mwaa-docker-images requirements.txt にアクセスしてください。

  3. 制約ステートメントを追加します。Apache Airflow v2 環境用の制約ファイルを requirements.txt ファイルの先頭に追加します。Apache Airflow の制約ファイルには、Apache Airflow のリリース時点で利用可能なプロバイダーのバージョンが指定されています。

    Apache Airflow v2.7.2 から、要件ファイルには --constraint ステートメントを含める必要があります。制約を指定しない場合、要件に記載されているパッケージが使用している Apache Airflow のバージョンと互換性があることを確認するため、Amazon MWAA はお客様に代わって制約を指定します。

    次の例では、{environment-version} をお使いの環境のバージョン番号に、{Python-version} を環境と互換性のある Python のバージョンに置き換えます。

    Apache Airflow 環境と互換性のある Python のバージョンについては、Apache Airflow のバージョン を参照してください。

    --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-{Airflow-version}/constraints-{Python-version}.txt"

    制約ファイルが xyz==1.0 パッケージが環境内の他のパッケージと互換性がないと判断した場合、pip3 install は環境に互換性のないライブラリがインストールされるのを防ぐために失敗しま す。いずれかのパッケージのインストールが失敗した場合、CloudWatch Log の対応するログストリームで、各 Apache Airflow コンポーネント (スケジューラ、ワーカー、ウェブサーバー) のエラーログにアクセスできます。ログタイプの詳細については、Amazon CloudWatch の Airflow ログへのアクセス を参照してください。

  4. Apache Airflow パッケージ。パッケージエクストラとバージョン (==) を追加します。これにより、同じ名前で異なるバージョンのパッケージが環境にインストールされるのを防ぐことができます。

    apache-airflow[package-extra]==2.5.1

  5. Python ライブラリ パッケージ名とバージョン (==) を requirements.txt ファイルに追加します。これにより、PyPI.org からの将来の重大な更新が自動的に適用されるのを防ぐことができます。

    library == version
    例 Boto3 と psycopg2-binary

    この例は、デモンストレーションのみを目的としています。boto と psycopg2 のバイナリライブラリは Apache Airflow v2 のベースインストールに含まれており、requirements.txt ファイルで指定する必要はありません。

    boto3==1.17.54
boto==2.49.0
botocore==1.20.54
psycopg2-binary==2.8.6

    パッケージがバージョンなしで指定されている場合、Amazon MWAA は PyPI.org からパッケージの最新バージョンをインストールします。このバージョンは、お客様の requirements.txt 内の他のパッケージと競合できます。

オプション 2: Python wheel (.whl)

Python wheel は、コンパイルされたアーティファクトをライブラリに同梱するために設計されたパッケージ形式です。Amazon MWAA に依存関係をインストールする方法として、ホイールパッケージにはいくつかの利点があります。

  • より速いインストール — WHL ファイルは 1 つの ZIP としてコンテナにコピーされ、ローカルにインストールされます。各ファイルをダウンロードする必要はありません。

  • より少ないコンフリクト — パッケージのバージョン互換性を事前に判断できます。その結果、pip が互換性のあるバージョンを再帰的に調べる必要がなくなります。

  • 耐障害性の向上 — 外部でホストされているライブラリでは、ダウンストリームの要件が変更され、Amazon MWAA 環境上のコンテナ間でバージョン互換性がなくなる可能性があります。依存関係を外部ソースに依存しないことで、各コンテナがいつインスタンス化されたかに関係なく、上のすべてのコンテナに同じライブラリが割り当てられます。

requirements.txt の Python wheel アーカイブ (.whl) から Python 依存関係をインストールするには、次の方法をお勧めします。

Amazon S3 バケット上の plugins.zip ファイルを使用する

Apache Airflow スケジューラー、ワーカー、ウェブサーバー (Apache Airflow v2.2.2 以降用) は、起動時に、/usr/local/airflow/plugins/* でお使いの環境の AWS マネージド Fargate コンテナーでカスタムプラグインを検索します。このプロセスは、Python 依存関係および Apache Airflow サービスの起動のための Amazon MWAA の pip3 install -r requirements.txt 前に始まります。plugins.zip ファイルは、環境実行中に継続的に変更されたくないファイル、またはDAGを作成するユーザーにアクセス権を与えたくないファイルに使用できます。例えば、Python ライブラリのホイールファイル、証明書 PEM ファイル、設定 YAML ファイルなどです。

次のセクションでは、plugins.zip ファイルにあるホイールを Amazon S3 バケットにインストールする方法について説明します。

  1. 必要な WHL ファイルをダウンロードします。Amazon MWAA aws-mwaa-docker-imagesまたは別の Amazon Linux 2 コンテナにある既存の requirements.txt と pip download を使用して、必要な Python wheel ファイルを解決してダウンロードできます。

    pip3 download -r "$AIRFLOW_HOME/dags/requirements.txt" -d "$AIRFLOW_HOME/plugins"
cd "$AIRFLOW_HOME/plugins"
zip "$AIRFLOW_HOME/plugins.zip" *

  2. requirements.txt でパスを指定します。次のコードに示すように、requirements.txt の先頭に --find-links を使用してプラグインディレクトリを指定し、pip に他のソースからインストールしないように --no-index を用いて指示します。ースからインストールしないように指示します。

    --find-links /usr/local/airflow/plugins
--no-index
    例 requirements.txt 内のホイール

    次の例では、Amazon S3 バケットのルートにある plugins.zip ファイルにホイールをアップロードしたことを前提としています。例:

    --find-links /usr/local/airflow/plugins
--no-index

numpy

    Amazon MWAA は plugins フォルダから numpy-1.20.1-cp37-cp37m-manylinux1_x86_64.whl ホイールを取得し、環境にインストールします。

URL にホストされている WHL ファイルを使用する

次のセクションでは、URL でホストされるホイールをインストールする方法について説明します。URL は、パブリックにアクセス可能であるか、Amazon MWAA 環境用に指定したカスタム Amazon VPC 内からアクセスできる必要があります。

  • URL を指定してください。requirements.txt 内のホイールの URL を指定します。

    例 公開 URL でのホイールアーカイブ

    次の例では、公開サイトからホイールをダウンロードします。

    --find-links https://files.pythonhosted.org/packages/
--no-index

    Amazon MWAA は、指定した URL からホイールを取得し、お使いの環境にインストールします。

    注記

    Amazon MWAA v2.2.2 以降では、要件をインストールするプライベートウェブサーバーから URL にアクセスすることはできません。

DAG から WHL ファイルを作成

Apache Airflow v2.2.2 以降を使用するプライベートウェブサーバーがあり、環境が外部リポジトリにアクセスできないために要件をインストールできない場合は、次の DAG を使用して既存の Amazon MWAA 要件を取得し、Amazon S3 にパッケージ化できます。

from airflow import DAG
 from airflow.operators.bash_operator import BashOperator
 from airflow.utils.dates import days_ago
					
 S3_BUCKET = 'my-s3-bucket'
 S3_KEY = 'backup/plugins_whl.zip' 
					
 with DAG(dag_id="create_whl_file", schedule_interval=None, catchup=False, start_date=days_ago(1)) as dag:
 cli_command = BashOperator(
 task_id="bash_command",
 bash_command=f"mkdir /tmp/whls;pip3 download -r /usr/local/airflow/requirements/requirements.txt -d /tmp/whls;zip -j /tmp/plugins.zip /tmp/whls/*;aws s3 cp /tmp/plugins.zip s3://amzn-s3-demo-bucket/{S3_KEY}"
)

DAG を実行したら、この新しいファイルを Amazon MWAA plugins.zip として使用します。オプションで、他のプラグインと一緒にパッケージ化することもできます。次に、--constraint を追加せずに --find-links /usr/local/airflow/plugins および --no-index の前に requirements.txt を更新してください。

この方法では、同じライブラリをオフラインで使用できます。

オプション3: PyPI/PEP-503 準拠のプライベートリポジトリでホストされている Python の依存関係

次のセクションでは、認証付きのプライベート URL でホストされている Apache Airflow エクストラをインストールする方法について説明します。

  1. ユーザー名とパスワードを Apache Airflow 設定オプション として追加します。例:

    • foo.user : YOUR_USER_NAME

    • foo.pass : YOUR_PASSWORD

  2. requirements.txt ファイルを作成します。次の例のプレースホルダーは、プライベート URL と Apache Airflow 設定オプション として追加したユーザー名とパスワードに置き換えてください。例:

    --index-url https://${AIRFLOW__FOO__USER}:${AIRFLOW__FOO__PASS}@my.privatepypi.com

  3. その他のライブラリを requirements.txt ファイルに追加します。例:

    --index-url https://${AIRFLOW__FOO__USER}:${AIRFLOW__FOO__PASS}@my.privatepypi.com
my-private-package==1.2.3

Amazon MWAA コンソールでログを有効にします。

Amazon MWAA 環境の 実行ロール には、CloudWatch Logs にログを送信するためのアクセス許可が必要です。実行ロールのアクセス許可を更新するには、Amazon MWAA 実行ロール を参照してください。

Apache Airflow ログは INFO、WARNING、ERROR または CRITICAL レベルで有効にできます。ログレベルを選択すると、Amazon MWAA はそのレベルとそれ以上の重要度レベルのすべてのログを送信します。例えば、INFO レベルでログを有効にすると、Amazon MWAA は INFO ログと WARNING、ERROR、CRITICAL のログレベルを CloudWatch Logs に送信します。requirements.txt で受信したログをスケジューラーにアクセスできるように、INFO レベルで Apache Airflow ログを有効にすることをお勧めします。

この画像は、INFO レベルでログを有効にする方法を示しています。

CloudWatch Logs コンソールでログにアクセスする

ワークフローのスケジュール設定と dags フォルダーの解析を行うスケジューラーの Apache Airflow ログにアクセスできます。次のステップでは、Amazon MWAA コンソールでスケジューラーのロググループを開き、CloudWatch Logs コンソールで Apache Airflow ログにアクセスする方法について説明します。

requirements.txt のログにアクセスするには

  1. Amazon MWAA コンソールで、環境ページ を開きます。

  2. 環境を選択します。

  3. モニタリング ペインで Airflow スケジューラーロググループ を選択します。

  4. ログストリーム の requirements_install_ip ログを選択します。

  5. /usr/local/airflow/.local/bin で環境にインストールされたパッケージのリストについて参照してください。例:

    Collecting appdirs==1.4.4 (from -r /usr/local/airflow/.local/bin (line 1))
Downloading https://files.pythonhosted.org/packages/3b/00/2344469e2084fb28kjdsfiuyweb47389789vxbmnbjhsdgf5463acd6cf5e3db69324/appdirs-1.4.4-py2.py3-none-any.whl  
Collecting astroid==2.4.2 (from -r /usr/local/airflow/.local/bin (line 2))

  6. パッケージのリストを確認し、インストール中にエラーが発生したパッケージがないか確認してください。何か問題が発生した場合、以下のようなエラーが表示されることがあります。

    2021-03-05T14:34:42.731-07:00
No matching distribution found for LibraryName==1.0.0 (from -r /usr/local/airflow/.local/bin (line 4))
No matching distribution found for LibraryName==1.0.0 (from -r /usr/local/airflow/.local/bin (line 4))

Apache Airflow UI でエラーにアクセスする

Apache Airflow UI をチェックして、エラーが別の問題に関連しているかどうかを確認することもできます。Amazon MWAA の Apache Airflow で発生する可能性のある最も一般的なエラーは次のとおりです。

Broken DAG: No module named x

Apache Airflow UI にこのエラーが表示される場合は、requirements.txt のファイルに必要な依存関係が欠けている可能性があります。

Apache Airflow へのログイン

Apache Airflow UI にアクセスするためには、AWS Identity and Access Management (IAM) で AWS アカウント に対して Apache Airflow UI アクセスポリシー: AmazonMWAAWebServerAccess のアクセス許可が必要です。

Apache Airflow UI にアクセスするには

  1. Amazon MWAA コンソールで、環境ページ を開きます。

  2. 環境を選択します。

  3. Airflow UI を開く を選択します。

requirements.txt シナリオ例

requirements.txt では異なるフォーマットを組み合わせることができます。次の例では、さまざまな方法を組み合わせてエクストラをインストールしています。

例 PyPI.org のエクストラとパブリック URL

パブリック URL 上のパッケージ (PEP 503 準拠のカスタム repo URL など) に加えて、PyPI.org からパッケージを指定する場合は、--index-url のオプションを使用する必要があります。

aws-batch == 0.6
				phoenix-letter >= 0.3
				
				--index-url http://dist.repoze.org/zope2/2.10/simple
				zopelib