【ITニュース解説】Free, self-hosted, instant Nx remote cache with Docker and Cacheiro Instants. Ready for S3, GCS, Azure and disk

ソフトウェア開発の世界では、複数のプロジェクトを一つのリポジトリで管理する「モノレポ」という手法がよく利用される。このモノレポで「Nx」や「Lerna」といったツールを使うと、プロジェクト間の依存関係を効率的に管理し、開発プロセスをスムーズに進めることができる。しかし、プロジェクトが増えたり、開発者が多くなったりすると、アプリケーションのビルド（ソースコードを実行可能な形に変換する作業）に時間がかかり、開発効率が落ちるという課題が発生しがちである。

この課題を解決する強力な手段が「リモートキャッシュ」である。リモートキャッシュとは、一度実行されたビルド結果や計算結果をネットワーク上の共有ストレージに保存し、他の開発者や自動テスト環境（CI: 継続的インテグレーション）が同じ処理を再実行する必要がある場合に、その保存された結果を再利用することで、処理時間を大幅に短縮する仕組みである。例えば、ある開発者がモジュールAをビルドした場合、その結果はリモートキャッシュに保存される。次に別の開発者がモジュールAを含むアプリケーションをビルドしようとした際には、キャッシュから結果を読み込むだけで済み、再ビルドの必要がなくなる。これにより、開発者の待ち時間が減り、CIの実行時間も短縮され、プロジェクト全体の生産性が向上する。

しかし、このリモートキャッシュを導入するには課題があった。NxやLernaに対応したキャッシュサーバーを運用しようとすると、一般的には高額なマネージドサービス（サービス提供者がサーバーの管理・運用を行う有料サービス）を利用するか、あるいは自前でサーバーをゼロから構築する必要があった。特に自前でのサーバー構築は、設定や運用に専門知識と手間がかかるため、多くの開発チームにとって負担となっていた。

このような背景から生まれたのが、「Cacheiro（カシェイロ）」という無料かつオープンソースのリモートキャッシュサーバーである。Cacheiroは、NxやLernaがリモートキャッシュを利用するための標準的なインターフェース（OpenAPI仕様）を実装しているセルフホスト型のサーバーであり、自分で管理・運用できる自由度の高さが特徴である。このサーバーは、ファイルシステム、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storageといった主要なストレージサービスに対応しており、既存のインフラに合わせて柔軟に選択できる。Cacheiroが開発された直接のきっかけは、以前Nxが公式に提供していたセルフホスト型キャッシュパッケージに、キャッシュを不正に操作される深刻なセキュリティ脆弱性（CVE-2025-36852）が発見され、その公式サポートが終了したことにある。公式の選択肢が有料サービスか自作サーバーの二択になった状況で、Cacheiroは後者の「自作サーバー」を手軽に導入できる解決策として提供された。

Cacheiroの使い方は非常にシンプルである。自身の開発環境（ワークスペース）でCacheiroサーバーを利用するには、サーバーのアドレスをNX_SELF_HOSTED_REMOTE_CACHE_SERVERという環境変数に、そしてアクセスするための認証トークンをNX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKENという環境変数に設定するだけである。トークンはオプションだが、公開環境では必ず設定すべきだ。これらを一度設定すれば、あとは普段通りnx run-many -t buildやlerna run buildのようなビルドコマンドを実行するだけで、Cacheiroが自動的にリモートキャッシュとして機能する。

Cacheiroは当初、開発者が既存のシステムに組み込んだり、動作を細かくカスタマイズしたりできるように、ライブラリという形で提供されていた。しかし、多くの開発チーム、特にインフラ運用を担当するDevOpsチームは、そこまでのカスタマイズ性は求めず、単にキャッシュサーバーを手軽に起動して使いたいと考えていた。このニーズに応えるため、プロジェクトは「Cacheiro Runner」という、すぐに使える参照アプリケーションを提供したが、これもストレージの種類（S3、GCSなど）を切り替えるにはソースコードの編集が必要だった。

そこで登場したのが、Cacheiro Instantsである。これは、開発者や運用チームの手間を完全に排除するために作られた「100%すぐに使えるDockerイメージ」として提供される。Dockerイメージとは、アプリケーションとその実行に必要な環境（OSやライブラリなど）を全てまとめてパッケージ化したものであり、このイメージを実行するだけで、キャッシュサーバーがすぐに使えるようになる。Cacheiro Instantsを使えば、サーバーのビルド、コードでの設定、特別なデプロイ（配置）作業などは一切不要になる。

Cacheiro Instantsは、対応するストレージの種類に応じて「ファイルシステム(fs)」「Amazon S3(s3)」「Google Cloud Storage(gcs)」「Azure Blob Storage(azure)」の4つのフレーバー（種類）が用意されている。それぞれのイメージには、そのストレージに対応する最小限の機能とライブラリのみが含まれているため、余計なものがなく軽量である。例えば、ファイルシステム用のイメージには、AWSやGoogle、AzureのSDK（ソフトウェア開発キット）は含まれていない。

これらのDockerイメージを動かすには、一般的なdocker runコマンドを使用する。基本設定として、すべてのフレーバーでサーバーはポート3000、ホストアドレス0.0.0.0で動作するように設定済みである。認証はCACHEIRO_AUTH_TOKENという環境変数にベアートークン（HTTPヘッダーに含める認証情報）を設定することで行われる。このトークンを設定しない場合は認証が無効になるため、外部に公開する環境では必ず設定するべきである。

最もシンプルな「ファイルシステム(fs)」フレーバーでは、docker runコマンドでポート3000を公開し、CACHEIRO_AUTH_TOKENで認証トークンを設定し、さらに-vオプションを使ってホストOSの特定のディレクトリ（例:$(pwd)/cache）をコンテナ内の/cacheディレクトリに接続（ボリュームマウント）する。これにより、キャッシュデータはホストOS上に保存され、コンテナが停止してもデータが失われない。ファイルシステムフレーバーでは、キャッシュされたデータはデフォルトで7日後に自動的に期限切れになる。

「Amazon S3(s3)」フレーバーでは、S3バケット名、リージョン、AWSの認証情報を環境変数として渡す。S3互換のストレージサービス（MinIO、Cloudflare R2など）も、追加の環境変数S3_ENDPOINTを設定することで利用可能である。「Google Cloud Storage(gcs)」フレーバーは、GCSバケット名と、サービスアカウントファイルなどの認証情報ファイルをボリュームマウントして利用する。「Azure Blob Storage(azure)」フレーバーは、Azureコンテナ名と接続文字列、またはアカウント名を環境変数で指定する。

Cacheiro Instantsには、開発の効率とセキュリティを高めるためのいくつかの便利な機能も備わっている。例えば、「読み取り専用トークン」機能を使えば、CACHEIRO_AUTH_READ_ONLY_TOKENという別の環境変数を設定することで、読み取りのみが許可される認証トークンを発行できる。これにより、メインのCIにはフルアクセス権限のトークンを、開発者やプルリクエストのCIには読み取り専用のトークンを与えるといった、よりきめ細やかなアクセス制御が可能になる。

また、Dockerの標準機能である「ヘルスチェック」が組み込まれており、サーバーが正常に稼働しているかを/healthエンドポイントを通じて自動的に確認する。この結果はdocker psコマンドで簡単に確認でき、Docker Composeなどのオーケストレーターツールもこの情報を使ってサーバーの準備完了を判断できる。設定ミスを防ぐため、すべての設定は環境変数から読み込まれ、サーバー起動前に厳密に検証される。必須の設定が不足していたり、無効な値が指定されていたりする場合には、コンテナはすぐにエラーを出して停止し、問題点をまとめて表示してくれるため、トラブルシューティングが容易である。さらに、CACHEIRO_TLS_CERT_FILEとCACHEIRO_TLS_KEY_FILEという環境変数で証明書と秘密鍵のファイルを指定し、それらをボリュームマウントすることで、ネイティブでHTTPS（TLS暗号化）通信を有効にすることもできる。

Cacheiro Instantsのイメージは、常に最新の状態に保たれるよう設計されており、同時に予測可能なバージョン管理が行われている。本番環境での利用には、特定のバージョンに固定された「バージョンタグ（例: 0.4.0）」の使用が推奨される。このタグは一度公開されると内容が変更されることがないため、安定した運用が可能である。一方、「latest」タグは常に最新のビルドを指すため、試用には便利だが、予期せず変更される可能性がある点に注意が必要である。これらのイメージは、IntelベースのPCだけでなく、Apple Silicon MacやARMサーバーなど、異なるCPUアーキテクチャ（マルチアーキテクチャ）にも対応しているため、幅広い環境で利用できる。

最終的に、どのようなCacheiroを利用すべきかという選択については、単純にキャッシュサーバーをすぐに起動して使いたいだけであれば、設定不要で手軽なCacheiro Instantsが最適な選択肢となる。もし、Cacheiroの動作を細かくカスタマイズしたい、独自のストレージバックエンドを実装したい、またはCacheiroサーバーを別のアプリケーションに組み込みたいといった高度なニーズがある場合は、Cacheiroのライブラリと、その参照実装であるCacheiro Runnerを起点として開発を進めるべきである。

Cacheiroは、モノレポでの開発におけるビルド時間の課題を、手軽かつ安全に解決するための強力なツールである。Cacheiro Instantsを利用すれば、リモートキャッシュの導入は、利用したいストレージの種類を選び、いくつかの環境変数を設定し、Dockerコンテナを実行するだけで完了する。NxやLernaを利用している開発者は、ぜひ一度試してみてほしい。一度目のビルドでキャッシュが生成され、二度目のビルドでその価値が実感できるだろう。