はじめに

doda マイクロサービスグループ所属の山田と申します。今年の 10 月に中途入社し、現在は doda のマイクロサービス基盤を運用しております。本記事では、doda のマイクロサービス基盤で IaC として使用している CDK で、スナップショットテストを導入した際に発生したエラー、解決までのプロセス、解決方法について記載します。

背景

私が所属している doda マイクロサービスグループでは、IaC に CDK を使用しています。私が入社して間もなく、CDK のコードのリファクタリングやライブラリのアップデートによる想定外の変更を検出できるようにするという目的で、CDK にスナップショットテストを導入することになりました。スナップショットテストとは、CDK のスナップショットファイルを出力し、CDK の変更前後のスナップショットファイルを比較することで、CDK の変更前後の差分を検出できるようにするものです。
　スナップショットテスト実行のフローは以下の通りにしました。

CDK 変更のコミットが GitHub に push されたタイミングで、 GitHub Actions のワークフローが実行されます。
ワークフロー内でスナップショットテストを実行することで、変更後のスナップショットファイルが作成されます。
ワークフロー内で変更後のスナップショットファイルを作業ブランチにコミットします。

利用環境

利用環境は以下の通りです。

CDK のコードは TypeScript 4.9.5 で書かれています。
ワークフローの実行には Actions Runner Controller を使用しており、 EKS の pod 上で実行されます。

発生したエラーとそれに対して行ったこと

発生したエラー 1

CDK のスナップショットテストを GitHub Actions で実行すると、まず下記のような WARNING が出続けて、ワークフローが完了しないという事象が発生しました。

#5 249.4 WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<pip._vendor.urllib3.connection.HTTPSConnection object at [MEMORY_ADDRESS]>: Failed to establish a new connection: [Errno 101] Network is unreachable')': /simple/pip/
#5 313.4 WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<pip._vendor.urllib3.connection.HTTPSConnection object at [MEMORY_ADDRESS]>: Failed to establish a new connection: [Errno 101] Network is unreachable')': /simple/pip/
#5 454.2 WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<pip._vendor.urllib3.connection.HTTPSConnection object at [MEMORY_ADDRESS]>: Failed to establish a new connection: [Errno 101] Network is unreachable')': /simple/pipenv/

pip や pipenv 関連のエラーで、コネクションを確立できない旨のエラーが出ています。これだけでは詳細な原因が分からなかったので、もう少し前の時刻のログを見てみると、下記のような Dockerfile のコマンドらしきログが出ていました。

#5 [2/2] RUN     python -m venv /usr/app/venv &&     mkdir /tmp/pip-cache &&     chmod -R 777 /tmp/pip-cache &&     pip install --upgrade pip &&     mkdir /tmp/poetry-cache &&     chmod -R 777 /tmp/poetry-cache &&     pip install pipenv==2022.4.8 poetry==1.5.1 &&     rm -rf /tmp/pip-cache/* /tmp/poetry-cache/*

以上のログから、スナップショットテストを実行した際にコンテナを起動しようとしており、その際に pip や pipenv をインストールしようとして、インストール先との間でコネクションを確立できずに失敗していることが分かりました。

コードは TypeScript で書かれており、ワークフローの処理でコンテナを起動させていないにも関わらず、なぜこのような Python や docker に関するログが出たかというと、コード内で使用している、 aws-lambda-python-alpha というライブラリに関係していました。 doda のマイクロサービス基盤では、AWS Lambda を使用しており、AWS Lambda の関数を Python で実装しています。 AWS Lambda で使用している Python コードを CDK で管理してデプロイするために aws-lambda-python-alpha の PythonFunction を使用しています。この PythonFunction の内部の処理で、コンテナを起動させて、Python コードをバンドルしています。その際に、pip や pipenv などをインストールしようとして、インストール先に接続できずにエラーになっているという状況でした。

なぜ、pip や pipenv のインストール時にインストール先に接続できなかったかというと、社内のネットワークポリシーにより AWS 外部のネットワークに接続する場合に指定したプロキシを経由する必要があったためでした。

まず aws-lambda-python-alpha の公式ドキュメントを読んでみると、プロキシを指定できる方法が用意されていました。ライブラリでは Custom Bundling というものが用意されており、この中の buildArgs というプロパティでコンテナの起動時の引数を指定できるようになっていました。この buildArgs で HTTPS_PROXY にプロキシの URL を設定することでこのエラーを解決できました。

発生したエラー 2

1 つ目のエラーを解決した後に GitHub Actions のワークフローを実行すると、今度は以下のようなエラーが発生しました。

    Failed to bundle asset <Stack名>/<PythonFunction()で指定したID>/Code/Stage, bundle output is located at /tmp/cdk.out[文字列]/asset.[文字列]-building: Error: docker exited with status 23
    --> Command: docker run --rm -u "1001:1001" -v "/home/runner/_work/<Pythonコードのあるディレクトリのパス>:/asset-input:delegated" -v "/tmp/cdk.out[文字列]/asset.[文字列]-building:/asset-output:delegated" -w "/asset-input" cdk-[文字列] bash -c "rsync -rLv /asset-input/ /asset-output && cd /asset-output"

エラーメッセージの Command: 以降の箇所を読むと PythonFunction 内の処理においてコンテナ内で rsync を実行した際にエラーが発生したことが分かります。実行した rsync のコマンドを見てみると、 /asset-input/ を /asset-output に同期していることが分かります。ここで、rsync のログより少し前のログを見てみると、 docker run --rm -u "1001:1001" -v "/home/runner/_work/<Pythonコードのあるディレクトリのパス>:/asset-input:delegated" という記載があります。ここでは、ホスト側の /home/runner/_work/<Pythonコードのあるディレクトリのパス> をコンテナ側の /asset-input にマウントしています。つまりマウントしたディレクトリに rsync でアクセスした際にエラーが発生している状態です。ここで、確証はないですがマウントしたディレクトリのパーミッションの問題でエラーが発生していると推測しました。ライブラリの公式ドキュメントを参照すると、ライブラリ側で回避策のようなものが用意されていました（ドキュメント）。 1 つ目のエラーの解決の際にも使用した Custom Bundling に bundlingFileAccess というプロパティがあり、このプロパティに BundlingFileAccess.VOLUME_COPY を指定することで、このエラーを解決できました。