IBM Cloud FoundryからCode Engineへのマイグレーションに関するベスト・プラクティスの紹介：サービス・バインディングとコード

記事をシェアする:

Part1：Cloud Foundry アプリケーションを IBM Cloud Code Engine にマイグレーションするためのベスト・プラクティス

昨年、 Cloud Foundry のアプリケーションを IBM Cloud Code Engine にマイグレーションする経験で学んだ教訓をブログ掲載しました。その後、IBM Cloud Code Engine が進化し、サービスへのアプリケーションのマイグレーションも多く経験しました。このことを念頭に、 IBM Cloud Foundry からCode Engineへのアプリケーションのマイグレーションに関するベスト・プラクティスを紹介します。

私は、 Twelve-Factor Appの原則に基づいた共通のクラウド・ネイティブ・アプリケーションを利用し、コードをシンプルにして更新しました。また、Cloud Foundry版とCode Engine版の両方を作成しました。マイグレーション手順や開発側面から議論する際の事例を提供します。

このブログでは、主にサービス・バインディングと実際のコードのマイグレーションにもっともフォーカスしていきます。次に、ビルド・プロセスや DevOps の影響、スケーリングと高可用性のセットアップなどのトピックで見ていきます。そして、セキュリティーとコンプライアンスについて更に考えを共有します。

Simple cloud-native app with backend database service.
バックエンド・データベース・サービスを使用するシンプル・クラウド・ネイティブ・アプリケーション

概要

本ブログのサンプル・ソリューションは、標準的な Web アプリケーションです。 これは、 Node.js (JavaScript) で書かれ、 Express web frameworkを使用します。 IBM Cloudant NoSQL データベースは、アプリケーションによって表示されるデータを保管するためのバックエンド・サービスとして機能します。 クラウド・ネイティブ /Twelve-Factor Appの典型的な例として、サンプル・ソリューションは、アプリケーション全体を構成するためのマイクロサービスとして機能する、個別の再使用可能なコンポーネントに基づいています。 デプロイされた Node.js プログラムとデータベースの両方を、スケール変更、改良、または個別に置き換えることができます。これらは、適切に定義された APIを使用してどのように構成されているかによって連携して機能します。
このように、 IBM Cloudantデータベースは、 Cloud Foundry および Code Engine にデプロイされたアプリケーション・バージョンを使用して、接続されたリソースとして機能するように構成できます。 これは、上記のアーキテクチャー図に示されています。 簡略化のため、ソリューションはこれら 2 つのコンポーネントにとどめています。 Web ブラウザーからアクセスすると、以下のページがデータベースから取得された部分で表示されます。

Cloud Foundry およびCode Engine を組み合わせたコード・バージョンを使用してデータベース・コンテンツを提供するサンプル Web アプリケーション

既存のソリューションを Cloud Foundry からCode Engine にマイグレーションするには、いくつかの事柄（可能性）を考慮する必要があります。
・コード・マイグレーション
・サービス・バインディング
・ビルドおよびデプロイメント・プロセス ( 例 : コマンド、ツール・チェーン・インテグレーション、 DevOps)
・スケーリングとリソース・マネジメント( 高可用性を含む )
・ルーティング
・セキュリティーとコンプライアンス

上記の方法は、ソリューションの複雑さ、そのパフォーマンスと可用性の要件、組織的特性などによって異なります。コードのマイグレーションは、サービス・バインディングの方針に依存するため、まずサービス・バインディングについて説明します。

こちらは、 IBM Cloud Code Engine を既に検討済みであり、プロジェクト、ビルド、およびアプリケーションの基本概念に精通していることを前提としています。 そうでない場合は、Code EngineへのCloud Foundryアプリケーションのマイグレーションに関する資料から始めていただくのがおすすめです。

サービス・バインディングについて

アプリを正しく機能させるには、 Cloudant データベースが必要です。これは、環境変数を手動で入れることによって構成できますが、標準的なプロセスはサービス・バインディングを使用します。
アプリケーションとそのバックエンド・サービスとの関係は明示的に記述されるため、資格情報が作成され、ランタイム環境の環境変数として自動的に入ります。 Cloud Foundry は、 VCAP_SERVICES オブジェクトの一部としての資格情報を提供します。Code Engine は、 CE_SERVICES 環境変数を使用してそれを 模倣します。

既に述べたアーキテクチャー図は、データベース・サービスに接続された Cloud Foundry とCode Engine の両方のアプリケーションを示しているということです。
Code Engine にデプロイされたコードは、Cloud Foundry アプリケーションの別の新しいバージョンと考えることができます。 これは、引き続き同じデータベース・サービスにバインドされますが、他の方法でバインドされます。
アプリケーションのCode Engine バージョンをあるサービスにバインドするには、以下の方法をお勧めします。

・IAM サービス・キー (資格情報) を作成します。IAM の役割 ( 例えば、管理者、ライター、またはリーダー) を指定する必要があります。
・アプリケーションに対して動作するものの、特権が最も少ないものを選択してください。
・既存の資格情報を使用して、サービスをアプリケーションにバインドします。

Code Engine は、サービス・バインディング時に資格情報を作成できますが、私は自分で作成するのを好みます。 これにより、よりコントロール強化が出来、Code Engine から独立してそれらを容易に追跡・無効にすることさえできるようになります。もし、Code Engine に資格情報を作成させる場合は、必要な特権を割り当てる必要があります。

Cloudant をデータベース・サービスとして使用するサンプル・アプリケーションの場合、以下の 2 つのコマンドを使用して、サービス・キー「Cloudant-CF2CE-Manager」を管理者の役割で作成し、それをバインディングに使用する必要があります。

Cloud Foundry アプリケーションが、いわゆるユーザー提供サービスを介してサービスに接続する場合は、Code Engine へのsecretとconfigmapを使用することをお勧めします。そうすることで、サービス資格情報をランタイム環境に入れて、それらをCode Engineプロジェクト内の名前付きオブジェクトとして管理することができます。

コード・マイグレーション

ほとんどの場合、コード・マイグレーションは簡単で、比較的単純です。
Cloud Foundryの環境変数 VCAP_SERVICES からの読み取りではなく、Code Engine の CE_SERVICES となります。サービスのネーミングには、微妙な違いがある場合があります。
これにより、ブローカー経由で「Cloud Foundry」および「 IBM Cloud IAM ベースのリソース管理」にサービスを提供することが可能になります。プログラミング言語によっては、コード・ライブラリーまたはモジュールを使用して、 ローカルに構成 (dotenv)に入れられている、Cloud Foundry ランタイム環境にアクセスすることができます。これらのセクションは、適合させることが必要です。

中間ステップを踏み、コード・マイグレーションを実行することをお勧めします。

1 . 最初のソースとしての Cloud Foundry のコード・ベース。 詳細については、サンプルアプリの 1cloudfoundry_baseブランチを参照してください。
2 . Code Engine のデプロイメントをサポートするコードを追加します。 これは、2cf_ce_intermediate_hybrid ブランチに表示されます。
3 . 最後に、実際のプロジェクト・マイグレーションが完了した後に、Code Engine のみのコード・ベースに移動します。不要なコードを削除した3codeengine_targetブランチを参照してください。

このアプローチは、デプロイメント環境とは独立して、マイグレーション・プロセス中にコード・ベースを維持または拡張することができるため、有益です。
以下のスクリーン・ショットは、中間ブランチ上のハイブリッド・コード・セクションを示しています。
最初に、古いコードは、 Cloud Foundry 環境に存在する環境変数(VCAP_SERVICES)をチェックします。
次に、新しいコードは、Code Engine 環境を検索して環境変数(CE_SERVICES)をチェックします。

Cloud Foundry ランタイム環境またはCode Engineランタイム環境から構成を取得するための Node.js コード

最後に

本ブログでは、 Cloud Foundry からCode Engine へアプリケーションをマイグレーションする際に考慮すべきトピック概要を紹介しました。

サービス・バインディングおよびコード・マイグレーションについて議論するためのサンプル・アプリケーションとそのGitHubリポジトリーを紹介しました。

このアプリケーションは、ビルドとデプロイメントの側面、高可用性、セキュリティーとコンプライアンスを考慮するためのフォローアップ・ポストの基盤としても機能します。

・アプリケーションおよびその他のリソースについては、 GitHub リポジトリーを参照してください.
・昨年から投稿したブログ　“Cloud FoundryからCode Engineへのマイグレーション”

この投稿に関するご意見やご提案、またはご質問がある場合は、 Twitter (@data_henrik) または LinkedInに連絡してください。

この投稿は、2022年3月15日に、米国 IBM Cloud Blog に掲載されたブログ(英語)の抄訳です。