このページでは、移行元の 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 Buildpack(CNB)仕様は、Buildpack エコシステムをモダナイズして統合するために作成されました。CNB 仕様と互換性のあるビルダーはオープン標準に準拠し、OCI 準拠のイメージを作成します。一般的な CNB プロバイダは次の 3 つです。
長所:
- Buildpack のメンテナンス担当者とプラットフォーム プロバイダが Buildpack のメンテナンスを行います。
- Buildpack は、アプリケーション コンテナを再ビルドせずにセキュリティ アップデートを迅速に行うため、新しいイメージでのコンテナのリベースをサポートしています。
- Buildpack はポータブルな OCI イメージを生成します。
- CNB は Cloud Native Computing Foundation(CNCF)のインキュベーション プロジェクトで、メンテナンス担当者とコントリビューターが参加する活発なコミュニティがあります。
短所:
- v2 Buildpack と v3 Buildpack で機能と構成にギャップがあります。
- Java v2 Buildpack でインストールされたフレームワークとインテグレーションが Java CNB Buildpack で使用できない場合があります。
セルフマネージド Dockerfile の使用
まったく新しい Dockerfile を作成して、アプリケーションをコンテナ化できます。Cloud Run で使用できるコンテナ イメージについては、コンテナのビルドをご覧ください。
長所:
- 最も柔軟にアプリケーションを設計できます。
- 会社の既存のコンテナツールを利用して、戦略を構築できます。
短所:
- Docker 化とカスタム構成をアプリケーションごとに行う必要があるため、デバッグと書き換えに時間がかかることがあります。
- 複数のチーム間で実装を標準化することが容易ではありません。
- イメージにパッチを適用するには、完全な再ビルドと再デプロイが必要です。
推奨事項
リソースが制限され、可能な限り多くのアプリケーションを移行する場合は、まずリフト&シフト戦略で Cloud Foundry を変更することを検討してください。アプリケーションを OCI 準拠のイメージにモダナイズしたら、Cloud Native Buildpack かセルフマネージド Dockerfile の使用を検討することをおすすめします。
すぐに移行する準備ができている場合は、まず Cloud Native Buildpack を試してください。その後、環境を高度に制御する必要がある場合は、セルフマネージド Dockerfile に移行します。
次のステップ
- リフト&シフト方式を採用している Spring Music のサンプルを移行する
- OCI コンテナに移行する