このページでは、移行元の Cloud Foundry ビルドプロセスの概要と、OCI 準拠のコンテナをビルドするプロセスに移行する方法について説明します。
Cloud Foundry のビルドプロセスの概要
アプリケーションが Cloud Foundry に push されると、ビルドステージでソースコードが Cloud Foundry v2 Buildpack によってコンパイルされます。
Cloud Foundry ビルドプロセスの出力により、Droplet と呼ばれる実行可能なアーカイブが作成されます。Droplet は、Cloud Run でコンテナを実行するための Open Container Initiative(OCI)の仕様と直接の互換性がありません。
アプリケーションを Cloud Foundry から Cloud Run に移行する場合は、業界標準の OCI イメージ(Docker イメージ)を生成するようにアプリケーションのビルドプロセスを変更する必要があります。
OCI 準拠のイメージを実現するための戦略
OCI 準拠のコンテナをビルドするには、次の 3 つの移行方法を選択できます。
- 既存の Cloud Foundry アプリケーションを変更する(「リフト&シフト」とも呼ばれます)
- Cloud Native Buildpack を使用する
- セルフマネージド Dockerfile を使用する
Cloud Foundry アプリケーションの変更(リフト&シフト)
Cloud Foundry エコシステムのコア コンポーネント(v2 Buildpack、Stemcell など)はオープンソースです。つまり、コアビルド コンポーネントを Docker 化するためのガイドに従って、アプリケーションのコンテナ化プロセスを再作成し、OCI 準拠の新しいイメージを作成できます。
長所:
- アプリケーションのリファクタリングやカスタマイズが必要最小限になります。
- このプロセスは、すべてのアプリケーション インスタンスに対して繰り返すことができます。
短所:
- アプリケーション コンテナを構築するためのパイプラインがセルフマネージドです。
- 古い Cloud Foundry コンポーネントのメンテナンスとサポートは縮小されています。
- セキュリティの維持には、次のような継続的な費用が発生します。
- ビルド コンポーネントを定期的に再ビルドして、セキュリティ パッチが確実に適用されるようにする。
- 定期的に「Docker 化」されたアプリケーションを再ビルドし、再ビルドされたビルド コンポーネントからセキュリティ アップデートを適用します。
Cloud Native Buildpack の使用
Cloud Native Buildpacks(CNB)仕様は、Buildpack エコシステムをモダナイズして統合するために作成されました。CNB 仕様と互換性のあるビルダーはオープン標準に準拠し、OCI 準拠のイメージを作成します。一般的な CNB プロバイダは次の 3 つです。
長所:
- Buildpack のメンテナンス担当者とプラットフォーム プロバイダが Buildpack のメンテナンスを行います。
- Buildpack は、アプリケーション コンテナを再ビルドせずにセキュリティ アップデートを高速化するために、新しいイメージでコンテナのリベースをサポートします。
- Buildpack はポータブルな OCI イメージを生成します。
- CNB は Cloud Native Computing Foundation(CNCF)のインキュベーション プロジェクトで、メンテナンス担当者とコントリビューターが参加する活発なコミュニティがあります。
短所:
- v2 Buildpack と v3 Buildpack で機能と構成にギャップがあります。
- Java v2 Buildpacks でインストールされたフレームワークとインテグレーションは、Java CNB Buildpack で使用できない場合があります。
セルフマネージド Dockerfile の使用
まったく新しい Dockerfile を作成して、アプリケーションをコンテナ化できます。Cloud Run で使用できるコンテナ イメージについては、コンテナのビルドをご覧ください。
長所:
- 最も柔軟にアプリケーションを設計できます。
- 会社の既存のコンテナツールを利用して、戦略を構築できます。
短所:
- Docker 化とカスタム構成をアプリケーションごとに実行する必要があるため、デバッグと書き換えに時間がかかることがあります。
- 複数のチーム間で実装を標準化することが困難です。
- イメージにパッチを適用するには、完全な再ビルドと再デプロイが必要です。
推奨事項
リソースが制限され、可能な限り多くのアプリケーションを移行する場合は、まずリフト&シフト戦略で Cloud Foundry を変更することを検討してください。アプリケーションを OCI 準拠のイメージにモダナイズしたら、Cloud Native Buildpack かセルフマネージド Dockerfile の使用を検討することをおすすめします。
すぐに移行する準備ができているチームは、Cloud Native Buildpack を試してから、環境を高度に制御する必要がある場合は、セルフマネージド Dockerfile に移行する必要があります。
次のステップ
- リフト&シフト方式を使用するサンプル Spring Music 移行に従います。
- OCI コンテナに移行する