Cloud Foundry アプリケーションの Code Engine FAQ へのマイグレーション

Cloud Foundry アプリケーションの Code Engine へのマイグレーションに関する一般的な質問に対する回答。

Code Engine でカスタム URL を使用できますか?

はい。 Code Engine コンソールからカスタム・ドメイン・マッピングを作成することで、独自のカスタム URL を Code Engine アプリケーションにマッピングすることができます。また、次のようなインターネットサービスプロバイダーを通じて、カスタム URL を割り当てることもできます。 IBM Cloud Internet Services. IBM Cloud Internet Services を介したカスタムドメイン付きアプリのデプロイの詳細については、可用性の高いアプリケーションの構成を参照してください。 Cloud Internet Services (CIS)、カスタム・ドメインでアプリをデプロイする方法の詳細については、カスタム・ドメインとそのTLS証明書および秘密鍵を取得するを参照してください。

アプリに特定の経路が含まれています。同じ経路を使用できますか?

制御する限り、同じカスタム経路またはカスタム・ドメインを使用できます。経路が別のソース (例えば、 mybluemix.net などの IBM提供の経路) からのものである場合は、 Code Engine によって提供されるドメインを使用するか、新しいカスタム・ドメインをアプリにマップする必要があります。

アプリを停止できますか?

アプリを直接停止することはできませんが、アプリの可視性を project に設定し、0 にスケーリングできるようにすることで、アプリがトラフィックを受信しないようにすることができます。詳しくは、アプリがトラフィックを受信しないようにするにはどうすればよいですか? を参照してください。

アプリ・インスタンスの数が多いのはなぜですか?

アプリを更新すると、 Code Engine によって新しいリビジョンが自動的に作成されます。リビジョンが使用可能になると、トラフィックは新規インスタンスにルーティングされます。リビジョンが拡大してトラフィックが転送される一方で、元のアプリ・インスタンスは引き続きトラフィックを処理します。リビジョンがスケールアップされ、すべてのトラフィックがそのリビジョンにルーティングされると、元のアプリがスケールダウンされます。また、トラフィックの必要に応じて、アプリが自動的にスケールアップ/スケールダウンします。後で確認して、アプリが正しい数のインスタンスを実行していることを確認してください。詳しくは、アプリケーション・スケーリングの構成を参照してください。

アプリの応答が遅いのはなぜですか?

アプリケーションはデフォルトでゼロにスケールされるため、スケールアップする間の応答が遅くなる可能性があります。この動作を変更するには、コンソールまたは CLI でアプリケーションを更新し、最小スケールを1に設定します。

例えば、CLI からmyappというアプリケーションの最小スケールを1に設定するには、以下のようにします。

ibmcloud ce app update --name myapp --min-scale 1

アプリケーションが更新されると、1 つのインスタンスが常に実行されます。料金が適用される可能性があることに注意してください。詳しくは、Code Engine の料金を参照してください。

特定のアプリケーション・インスタンスに要求をルーティングできますか?

いいえ。この機能は現在サポートされていません。この機能は、 Knative トラフィック分割を使用して概算できます。 Knativeを Code Engine で使用する方法については、 Knativeを Code Engine で使用するを参照してください。

Cloud Foundry アプリでグローバル・ロード・バランサーを使用しています。 Code Engineにマイグレーションできますか?

はい。証明書チェーンおよび対応する秘密鍵にアクセスできる場合は、 Code Engine アプリを指すようにグローバル・ロード・バランサーを更新できます。以下のステップでは、 Cloud Internet Services (CIS)を使用していることを前提としていますが、これらのステップは独自のグローバル・ロード・バランサーに適合させることができます。

これらのステップでは、コンソールを使用します。

アプリのドメイン・マッピングを作成します。ドメイン・マッピングを作成するときに、ドメインの秘密鍵と証明書チェーン全体を指定します。詳しくは、アプリのカスタム・ドメイン・マッピングの構成を参照してください。すべてのプロジェクトのドメイン・マッピングが Ready 状態を示すまで待ちます。
各ドメイン・マッピングの詳細を開き、 CNAME 値 ( custom.<your-random-id>.us-south.codeengine.appdomain.cloud や custom.<your-other-random-id>.us-east.codeengine.appdomain.cloud など) を記録します。
各アプリケーションの詳細ページにナビゲートし、 「ドメイン・マッピング」 タブを選択してから、システム・ドメイン・マッピング・セクションで No external system domain mapping を選択します。このステップにより、このプロジェクトの外部から呼び出された場合に、カスタム・ドメインを介してのみアプリケーションにアクセスできるようになります。
Cloud Internet Services (CIS) インスタンスで、 「信頼性」にナビゲートします。 >「グローバル・ロード・バランサー」>「オリジン・プール」 を選択し、オリジン・アドレスを以前に記録した CNAME に変更して、既存のオリジン・プールを編集します。

グローバル・ロード・バランサーが Code Engine アプリを指すようになりました。

アプリは仕様に従う必要がありますか?

アプリは、 12 要素アプリの方法論に従う必要があります。

Code Engineではどのようなタイプのワークロードを使用できますか?

Code Engineは、アプリケーションとバッチ・ジョブの 2 つのタイプのワークロードをサポートします。

アプリケーション (アプリ) は、HTTP 要求を処理するコードを実行します。 IBM Cloud® Code Engine は、従来型の HTTP 要求に加えて、通信プロトコルとして WebSocket を使用するアプリケーションもサポートします。アプリの実行中のインスタンス数は、入ってくるリクエストとコンフィギュレーション設定に基づいて自動的にスケールアップまたはスケールダウン（ゼロに）されます。アプリには、1 つ以上のリビジョンが含まれています。リビジョンとは、アプリの構成プロパティーの変更不可能なバージョンの 1 つを表します。アプリの構成プロパティーが更新されるたびに、アプリの新規リビジョンが作成されます。

ジョブは、あなたの実行コードの1つ以上のインスタンスを並列に実行します。 HTTP 要求を処理するアプリケーションとは異なり、ジョブは一度実行したら終了するように設計されています。ジョブを作成するときには、ジョブの実行時に毎回使用するワークロードの構成情報を指定できます。

必要なワークロードのタイプを判別する

ほとんどの Cloud Foundry アプリケーションは、Code Engine にマイグレーションできます。ただし、Cloud Foundry アプリケーションが着信 HTTP 要求を待機しない場合は、ジョブを選択することをお勧めします。詳しい説明と例については、Code Engineの計画を参照してください。

マニフェスト・ファイルを使用します。 Code Engineで使用可能な同様のオプションはありますか?

Cloud Foundry アプリケーションにマニフェスト・ファイルを使用する場合は、マニフェスト属性を対応するCode Engine機能または CLI オプションにマップします。

Markdown テーブルコーディング
マニフェスト属性	`ibmcloud ce app create`または`app update`コマンドで同等の Code Engine
`command`	`--command`オプション
`disk_quota`	Code Engineによって暗黙的に設定されます。
`docker`	Code Engineでは必要ありません。
`health-check-http-endpoint`	Code Engineでは必要ありません。デフォルトでは、TCP プローブを使用して、アプリケーションがいつ正常かつ作動可能になるかを認識します。
`health-check-invocation-timeout`	Code Engineでは必要ありません。
`instances`	`--min-scale`および`--max-scale`オプション
`memory`	`--memory`オプション
`metadata`	現在サポートされていません。
`no-route`	`--cluster-local` オプションでは、アプリケーションはプロジェクト内の他のワークロードからアクセス可能ですが、アプリケーションに関連するインターネットからアクセス可能な URL は含まれません。
`path`	現在は適用されません。
`processes`	Code Engineでは必要ありません。アプリケーションは、実行時に追加のプロセスを作成できる。
`random-route`	Code Engineでは必要ありません。各プロジェクトには固有のサブドメインがあり、アプリケーション名は URL の一部であるため、URL は固有であることが保証されます。
`routes`	カスタム経路は現在サポートされていませんが、 IBM Cloud Internet Service(CIS)または Cloudflare を使用して、カスタム・ドメインでアプリケーションをフロントエンドできます。
`sidecars`	現在サポートされていません。
`stack`	Code Engineによって暗黙的に管理されます。
`timeout`	Code Engineでは必要ありません。
環境変数	`-env`オプション
サービス	`ibmcloud ce app bind`コマンドを参照してください。

Code Engineは、自動スケーリングの管理方法など、Cloud Foundry では使用できない多くのオプションをサポートしています。 Code Engineでのアプリケーションの操作およびアプリケーション・スケーリングの構成を参照してください。

Cloud Foundry を使用してアプリをデプロイする方法を知っています。 Code Engineでアプリをデプロイするには何を知っておく必要がありますか?

Cloud Foundry を使用してアプリをデプロイする方法を知っている場合は、 Code Engineでアプリをデプロイするために何を知っておく必要があるかを確認してください。

プッシュ・コード

Code Engineを使用すると、Git リポジトリーまたはローカル・システム (CLI-only) をソースとするコードをビルドできます。さらに、Cloud Foundry (cf push) と同様に、CLI と Code Engine コンソールの両方を使用して、単一ステップでアプリをビルドおよびデプロイできます。詳しくは、コードを Code Engine アプリケーション・コンポーネントとして実行するにはどうすればよいですか?を参照してください。

デプロイメント・コンテキスト

Cloud Foundry では、コードをアプリケーションにプッシュするためにOrgとSpaceが必要です。すべての Cloud Foundry ユーザーは、デフォルトで、自分用に作成されたOrgとSpaceを受け取ります。ただし、新しいターゲットを追加するには、以下の例のようなOrgおよび Spaceターゲットをセットアップしなければなりません。

ibmcloud cf create-org MyOrg
ibmcloud target -o <ORGNAME>
ibmcloud target -s dev

その後、Cloud Foundry を使用してアプリをデプロイすると、そのOrgとSpaceがデプロイメントのターゲットになります。

Code Engineは、IBM Cloudリソース・グループとCode Engineプロジェクトの概念を使用します。

ibmcloud target -g <RESOURCE-GROUP>
ibmcloud ce project create --name <PROJECTNAME>

これらのコマンドは、プロジェクトを作成するだけでなく、プロジェクトの「ターゲット」も作成します。後続のすべてのCode Engineコマンドは、 **project select**コマンドを使用して別のプロジェクトをターゲットにするまで、このプロジェクトのコンテキストで実行されます。詳しくは、プロジェクトの管理を参照してください。

ログ

Code Engineは、アプリ、ジョブ、およびビルドのログを提供して、デプロイメントが適切に実行されないときに何が発生したかを判別できるようにします。以下の例のようなコマンドを実行すると、ログを見つけることができます。

ibmcloud ce app logs -n <APPNAME>
ibmcloud ce jobrun logs -n <JOBRUN-NAME>
ibmcloud ce buildrun logs -n <BUILDRUN_NAME>

また、ログメッセージをより長期的に保存するために、 IBM Cloud Logs。詳しくは、ログの表示を参照してください。

サービスの作成

マネージド・サービスのインスタンスの作成は、 Cloud Foundry と Code Engine で似ている。

Cloud Foundry アプリケーションで使用する新規サービスを作成するには、以下のコマンドを使用します。

ibmcloud cf create-service cloudantNoSQLDB lite myNameCloudant

Code Engineアプリケーションで使用する新規サービスを作成するには、以下のようにします。

ibmcloud resource service-instance-create myNameCOS cloud-object-storage lite global

サービス・バインディング

アプリケーションを作成した後、アプリケーションをサービスに「バインド」できます。

Cloud Foundry を使用して、以下のコマンドを実行します。

ibmcloud cf bind-service appName instanceName

Code Engineを使用する場合:

ibmcloud ce app bind --name appName --service-instance instanceName

サービス・インスタンス資格情報 (座標) は、環境変数を使用してアプリ (またはジョブ) に注入されます。 Code EngineのVCAP_SERVICESと同等なものは Cloud Foundry ではCE_SERVICESです。詳しくは、IBM Cloudサービスとサービス・バインディングの統合を参照してください。

アプリまたはジョブの更新

アプリケーションまたはジョブを作成した後、update コマンドを使用してワークロードのプロパティーを更新できます。例えば、Code Engineでアプリケーションを更新するには、以下のようにします。

ibmcloud ce app update --name <APPNAME> ...

アプリケーションまたはジョブの作成時に使用可能な任意のプロパティーを更新できます。詳細は以下のトピックを参照。

ランタイム・サポート

Code Engine は、がサポートしているランタイムの多くをサポートしている。 Cloud Foundry Code Engineでサポートされるランタイムのリストについては、 Cloud Native ビルドパックを参照してください。例えば、 Swift や Liberty など、サポートされていないランタイムを使いたい場合は、 Code Engine から直接イメージをビルドしなくても、自分でアプリをコンテナイメージとしてパッケージ化し、そのイメージを Code Engine にデプロイすることができます。

次のステップ

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

その他の情報

Code Engine 料金について説明します。
他の Code Engine チュートリアルを試してください。
他の Code Engine のトピックを探索します。