Backstageデプロイの定石：ビルド速度を上げ、イメージサイズを削減する5つの戦略

—

こんにちは！本日は、開発者ポータルの主流であるBackstage（バックステージ）をコンテナ化する際に最も懸念される「ビルド速度」と「イメージサイズ」の最適化戦略について深く掘り下げていきます。🚀

Backstageは強力である反面、依存関係が多く、ビルドプロセスが複雑になることがあります。本記事では、運用環境で迅速かつ軽量にデプロイするための主要な戦略をまとめました！💡

🏗️ Backstageコンテナ最適化、なぜ重要なのか？

Backstageは大規模なモノレポ（Monorepo）構造を持っており、何の最適化もせずにDockerビルドを行うと、以下の問題に直面します。

これらの問題を解決するための最高の戦略を一つずつ見ていきましょう！

最も基本的でありながら強力な戦略です。ビルド段階と実行段階を分離し、最終イメージには実行に本当に必要なファイルのみを残す方式です。

Build Stage：Node.jsの全環境、Python（一部のネイティブモジュールビルド用）、Yarnなど、全てのビルドツールを含めてyarn buildを実行します。
Production Stage：ビルドが完了した静的ファイルとコンパイルされたバックエンドバイナリのみをコピーします。通常、node:slimやalpineバージョンを使用してベースイメージサイズを最小化します。

これにより、ビルド用ライブラリ（例：gcc、make、python）が最終イメージから削除され、サイズが80%以上削減される可能性があります！📉

Dockerは変更されていないレイヤーを再利用します。しかし、順序を誤って配置すると、毎回全ての依存関係を新たにインストールすることになります。

依存関係ファイルを先にコピー：COPY . .を先に行うのではなく、package.jsonとyarn.lockだけを先にコピーし、yarn installを実行してください。ソースコードが変更されても、ライブラリレイヤーはキャッシュを維持できます。
Skeletonの活用：Backstageはyarn build時にskeleton.tar.gzとbundle.tar.gzを生成できます。skeletonには依存関係の構造のみが含まれており、キャッシュ効率を最大化します。🦴

イメージサイズを削減するためには、どのOSをベースにするかが重要です。


イメージタイプ	サイズ	特徴

—	—	—
Node Default	約900MB+	全てのツールが含まれており重い
Node Slim	約200MB	Debianベース、互換性が良く軽量
Node Alpine	約50MB	超軽量、musl libc使用により一部のネイティブモジュールと衝突する可能性あり

推奨戦略：互換性と安定性を考慮すると、node:20-slim（または最新のLTS slimバージョン）がBackstageの運用環境に最も適したバランスを示します。⚖️

現代のDocker環境では、BuildKitを有効にし、–mount=type=cacheオプションを使用することが必須です。

Dockerfile

# 例：Yarnキャッシュを活用したビルド
RUN --mount=type=cache,target=/root/.yarn/berry/cache 
    yarn install --immutable

この方式を使用すると、CI/CDパイプラインでビルドするたびに数百のパッケージを新たにダウンロードすることなく、ホストのキャッシュディレクトリを再利用することで、ビルド速度を劇的に向上させることができます。🏎️💨

イメージビルドコンテキストに含める必要のないファイルは徹底的に除外する必要があります。.dockerignoreファイルに以下の項目を必ず追加してください！

Backstageのコンテナ化を最適化する「黄金のレシピ」は以下の通りです。

これらの戦略を適用することで、より速く、より安全で、より軽量なBackstageサービスを運用できます！皆様のデプロイパイプラインがより軽くなることを願っています。😊