IBM Cloud Docs
サービス・バインディングのマイグレーション

サービス・バインディングのマイグレーション

12 要素アプリの原則に従い、コードを簡素化および更新し、Cloud Foundry と Code Engine の両方のバージョンを作成する一般的なクラウド・ネイティブ・アプリを考えてみましょう。 これらのバージョンは、マイグレーション・ステップおよびデプロイメント・アスペクトの説明の例として役立ちます。

サンプルアプリはNode.jsJavaScript)で書かれ、Expressウェブフレームワークを使用した典型的なウェブアプリです。 IBM Cloudant NoSQL データベースは、アプリケーションによって表示されるデータを保管するバッキング・サービスとして機能します。 クラウド・ネイティブの 12 要素アプリの標準的なサンプル・アプリは、アプリ全体を構成するマイクロサービスとして機能する、個別の再使用可能なコンポーネントに基づいています。 デプロイされた Node.js プログラムとデータベースの両方を、個別にスケーリング、改善、または置換することができます。 これらのコンポーネントは、その構成方法と、明確に定義された API を使用することにより、連携して動作します。

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

IBM Cloudantデータベースは、Cloud Foundryと Code Engineにデプロイされたアプリのバージョンにアタッチされたリソースとして動作するように設定できます。 簡単にするために、ソリューションはこれらの 2 つのコンポーネントに保持されます。

サービス・バインドの作成

このサンプル・アプリケーションは、コンテンツを保管するために Cloudant データベースを必要とします。 環境変数を手動で注入することによって Cloudant へのアクセスを構成できますが、通常のプロセスはサービス・バインディングを介して行われます。 アプリケーションとそのバッキング・サービスの間の関係は明示的に記述されているため、資格情報が作成され、ランタイム環境に自動的に注入されます。 Cloud Foundry は、 VCAP_SERVICES オブジェクトの一部として資格情報を提供します。 Code Engine は、 CE_SERVICES 環境変数を使用してこのオブジェクトを模倣します。

Cloud Foundryと Code Engineアプリケーションの両方がデータベースサービスにアタッチする。 Code Engine にデプロイされたコードは、異なる新しいバージョンの Cloud Foundry アプリと見なすことができます。 これは引き続き同じデータベース・サービスにバインドされますが、他の手段によってバインドされます。

アプリのCode Engineバージョンをサービスにバインドする、

  1. Cloudant データベース・インスタンスにアクセスします。 所有していない場合は、作成します。
  2. 記述名を使用して Cloudant インスタンスのサービス資格情報 (IAM サービス・キー) を作成します。 Specify the IAM role (Manager, Writer, or Reader) for your app. アプリケーションに必要な最小レベルの特権を持つロールを選択します。
  3. 既存の資格情報を使用してサービスをアプリにバインドします。 Code Engine は、サービスのバインド時に資格情報を作成できます。 ただし、独自の資格情報を作成することで、 Code Engineとは無関係に特権を追跡し、変更することもできます。

データベース・サービスとして Cloudant を使用するこのサンプル・アプリの場合、以下のコマンドを実行して、Manager役割を持つサービス・キーCloudant-CF2CE-Managerを作成し、それを使用してサービスをバインドします。

ibmcloud resource service-key-create Cloudant-CF2CE-Manager Manager --instance-name Cloudant-CF2CE
ibmcloud ce app bind --name cf2ce-app --service-instance Cloudant-CF2CE --service-credential Cloudant-CF2CE-Manager

Cloud Foundry アプリが ユーザー提供サービスを介してサービスに接続する場合、 Code Engineの シークレット または 構成マップ を使用するアプリを作成します。 secretsとconfigmapsを使うことで、サービス・クレデンシャルをランタイム環境に注入し、Code Engineプロジェクト内で名前付きオブジェクトとして管理することができる。

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

通常、コード・マイグレーションは単純です。 例えば、VCAP_SERVICES forCloud Foundryと呼ばれる環境変数から読み込む代わりに、あなたのコードは CE_SERVICES forCode Engineから読み込まなければならない。 さらに、サービスがCloud Foundryではブローカーを通じて、Code EngineではIAMベースのリソース管理を通じて利用可能になるため、サービスの名前の付け方に微妙な違いがあることに注意してください。

プログラミング言語に応じて、コードはコード・ライブラリーまたはモジュールを使用して、Cloud Foundry ランタイム環境、ローカルで注入された構成 ("dotenv") などにアクセスできます。 これらのセクションは調整する必要があります。

これら 2 つのアプリケーション例で、server.jsファイル内のコードを比較します。

アプリケーション・マイグレーションのステージング

アプリケーションを Cloud Foundry から Code Engine に移行中にダウンさせることができない場合は、中間ステップを使用してコード・マイグレーションを実行することを検討してください。

  • 1cloudfoundry_base: 初期ソースとしての Cloud Foundry コード・ベース。 このアプリは Cloud Foundry でのみ実行されます。
  • 2cf_ce_intermediate_hybrid: Code Engine デプロイメントもサポートするコードを追加します。 このアプリケーションは、Cloud Foundry と Code Engine の両方で実行されます。
  • 3codeengine_target: 最後に、実際のプロジェクト・マイグレーションが完了した後、 Code Engineのみのコード・ベースに移動します。 このアプリケーションは、Code Engine でのみ実行されます。

デプロイメント環境とは独立して、マイグレーション・プロセス中にコード・ベースの保守または拡張を継続できるため、この方法は有益です。

コードのビルドとアプリの実行

サービス・バインドのセットアップ、コードのマイグレーション、およびマイグレーションのステージングの準備が完了したら、コードをビルドします。 最初のマイグレーション・チュートリアルの手順に従って、ローカル・ソースからコードをビルドします。 コンソールを使ってコードをビルドしたい場合は、コードがGitになければなりません。 詳しくは、ソース・コードからのアプリのデプロイを参照してください。

次のステップ

  1. マイグレーションを開始するだけですか? 入門をチェックアウトします。
  2. Cloud Foundry の用語を Code Engine と比較してください。
  3. ローカル・ビルド・チュートリアルを使用して Code Engine を試します。
  4. サービス・バインディングのマイグレーション (現行ページ)
  5. スケーリングとトラフィック管理について説明します。
  6. Cloud Foundry コマンドと同等の Code Engine を見つけます。
  7. まだご不明な点がありますか? Cloud Foundry アプリケーションの Code Engine FAQ へのマイグレーションを試してください。

その他の情報