CIチーム向けS3テストフィクスチャ — NetDriveでAmazon S3をドライブ化

あるバックエンドチームは、データベースのスナップショット、事前レンダリング済みのメディアファイル、大容量の参照データセットなど、合計40GBのバイナリテストフィクスチャをAmazon S3に保存しています。統合テストスイートはこれらを通常のファイルパスとして読み込みます。フィクスチャが更新されるたびに、従来のワークフローは決まって同じでした。aws s3 cp で各CIランナーに数ギガバイトをダウンロードし、パイプラインを実行する人はテストが始まる前に25分待たされます。NetDriveでS3バケットをローカルドライブとしてマウントすれば、このコピー作業自体が不要になります。テストは T:\fixtures\ のようなパスを通じてS3から直接読み込み、ローカルへのダウンロードステップは一切発生しません。

S3をドライブレターとしてマウント — ダウンロード不要、コード変更不要

NetDrive を使えば Google Drive、OneDrive、S3、SFTP、WebDAV などが Windows と macOS でネイティブドライブとして表示されます — 同期も、まるごとダウンロードも不要です。

• ファイルパスを読み込むあらゆるアプリがそのまま動作
• 起動時の自動マウントでログイン前からドライブを利用可能に
• WasabiやMinIOもAmazon S3と同じ方法で利用可能

WindowsmacOS

NetDriveをダウンロード →

無料トライアル。永久ライセンスとサブスクリプションプランあり。

CIにおけるファイルパス互換性が重要な理由

ほとんどのテストスイートは、フィクスチャをローカルパスから読み込むように書かれています。すべてのフィクスチャ参照をS3のURLに書き換えると、数十のファイルに手を入れることになり、ローカルの開発体験まで壊しかねません。よりクリーンな解決策は、S3をローカルドライブのように見せかけ、既存のパスを変更せずそのまま使えるようにすることです。

NetDriveはS3バケットを、CIランナーの要件に応じてネットワークドライブ、読み取り専用ドライブ、またはローカルディスクボリュームとしてマウントします。Windowsではこれがドライブレター(T:、S:など)となり、マシン上のあらゆるプロセスから読み取れます。macOSでは/Volumes/配下、あるいは任意のパスにFUSEボリュームとして表示されます。テストスイートから見えるのはファイルシステムであり、S3 APIの呼び出しはNetDriveがバックグラウンドで処理します。

大容量のフィクスチャファイルも、NetDriveがデータをチャンク単位でストリーミングし、ネットワークの一時的な不調時には自動的にリトライするため、信頼性高く動作します。5GBを超えるファイルはS3のマルチパート転送を利用します(NetDrive 3.5.434以降で利用可能)。そのため、フィクスチャサイズに実質的な上限はありません。

S3バケットをドライブとしてセットアップする

1. NetDriveを開き、ドライブマネージャーで**+ Add Drive**をクリックします。
2. プロバイダー一覧からAmazon S3を選択します。
3. AWS Access Key IDとSecret Access Keyを入力します。最小権限の専用IAMロールを使用してください。フィクスチャ用バケットは読み取り専用、テストが成果物を生成する場所のみ書き込み権限を付与します。
4. Bucket Nameを入力します。NetDrive 3.19.7以降ではバケットの設定からリージョンが自動検出されるため、上書きが必要な場合を除きリージョン欄は空欄のままで構いません。
5. Drive Typeで、通常の読み書きマウントにはNetwork driveを、CIランナーからフィクスチャ用バケットへの書き込みを一切禁止したい場合はRead-only driveを選択します。
6. Mount onをBootに設定します。これが開発者のワークステーション設定との重要な違いです。起動時マウントにより、ユーザーがログインする前からドライブが利用可能になり、まさにヘッドレスなCIサーバーに求められる動作となります。
7. Mountをクリックします。

ドライブレター(Windows)またはボリュームパス(macOS)は、ユーザーセッションが有効でなくても、CIエージェントを含むマシン上のあらゆるプロセスからアクセス可能になります。

ログイン不要の自動マウント — ヘッドレスCIサーバーの設定

Mount on Bootオプションこそ、NetDriveをCI基盤で実用的にしている機能です。ほとんどのCIランナー(Jenkinsエージェント、GitHub Actionsのセルフホストランナー、GitLabエージェント)は、ユーザーセッションとしてではなくシステムサービスとして起動します。ユーザーのログイン時にのみマウントされるドライブは、こうしたエージェントからは見えません。

起動時マウントを有効にしておけば、OSの起動が完了した時点でS3ドライブが用意されています。CIエージェントはそれを自動的に検出します。ログインも、マウントコマンドを実行するスクリプトも、エージェント起動とドライブ出現の間の競合状態も、一切発生しません。

マウントをプログラムから実行する必要がある場合、例えばブランチ名やパイプライン変数に応じてマウントするバケットを動的に切り替えたい場合、NetDriveにはスクリプトによるドライブ管理を可能にするコマンドラインツールnd3cmdが含まれています(NetDrive 3.8.921で追加)。バージョンによって使用可能なフラグが異なるため、最新のnd3cmdコマンドリファレンスはNetDrive support forumを参照してください。

テストが成果物(カバレッジレポート、レンダリング結果、ベンチマーク結果など)を生成する場合も、同じマウント済みドライブが書き込みに使えます。NetDriveのbackground uploadモードは、まずローカルキャッシュに書き込み、その後非同期でS3にアップロードするため、アップロード完了を待ってテストプロセスがブロックされることはありません。

オンプレミスS3: MinIOとWasabi

すべてのチームがAWSを直接使っているわけではありません。フィクスチャデータをパブリッククラウド外に置くためオンプレミスでMinIOを運用するチームもあれば、コスト最適化されたコールドストレージとしてWasabiを使うチームもあります。NetDriveは3.4.398からS3互換ストレージプロバイダーをサポートしており、3.15.450でMinIOの明示的なサポートも追加されました。

S3互換エンドポイントを接続する手順は以下の通りです。

1. + Add Driveをクリックし、(Amazon S3ではなく)S3 Compatibleを選択します。
2. MinIOクラスターまたはWasabiリージョンのカスタムエンドポイントURLを入力します。
3. これまでと同様にバケット名と認証情報を入力します。
4. ドライブタイプとマウントトリガーも同様に設定します。

残りのセットアップは同一です。テストスイートから見れば、バックエンドがAWS us-east-1であろうと、Wasabiのバケットであろうと、CIランナーと同じデータセンター内で稼働するMinIOクラスターであろうと、T:\fixtures\は変わらずT:\fixtures\です。

まとめ

S3をドライブレターとしてマウントすることは、オブジェクトストレージに保存された大容量のフィクスチャライブラリへ、コード変更なしでCIパイプラインからアクセスできるようにする方法です。テストスイートはローカルパスを読み込み続けるだけで、S3への変換はNetDriveが処理します。起動時マウントにより、手作業での介入なしに、CIエージェントが必要とする瞬間には常にドライブが用意されています。

開発者用MacでのS3アクセス設定については、Mount Amazon S3 on macOS with NetDriveを参照してください。古いフィクスチャ向けにコスト効率の良いコールドストレージ層も必要な場合は、Mount Backblaze B2 on Windows with NetDriveでBackblazeのS3互換APIを使った同様のセットアップを紹介しています。

— Alex, NetDrive