本記事は IBM Cloud Code Engineを用いてWebアプリケーションをデプロイしてみる ~事前準備編~ の続編となります。
概要編や事前準備編をご覧になっていない方は、以下の記事をご参照ください。
記事一覧
- 概要編
- 事前準備編
- バックエンド編 【本記事】
- フロントエンド編（完成）/ つまずき集
はじめに
本記事では社内研修で作成したAI Chat Bot のバックエンド側のアプリケーションをIBM Cloud Code Engine を使用してビルド・デプロイしていきます。
ここから本格的に IBM Cloud Code Engine を使ってアプリケーションをビルド・デプロイしていきます。
IBM Cloud Code Engine を使用してバックエンドのビルド・デプロイ
7-1. Code Engine アプリケーションの作成
Code Engine にアクセスして、 作成開始 ボタンを押します。
7-2. コンポーネント・タイプ
今回はアプリケーションのデプロイであるため、アプリケーションを選択します。
その他コンポーネントタイプの説明と使用例の補足をしておきます。
アプリケーション：
HTTP に応答するコードを実行するもの
（使用例）: Web アプリのフロントエンド・サーバなど
ジョブ：
コードを実行してタスク処理を行うもの
（使用例）給与計算処理、メール添付ファイルの PDF 作成など
関数：
関数があらかじめ用意された実行環境で、呼び出された瞬間に即座に処理を行うもの
（使用例）Web フック・ターゲット（外部サービスから送られた通知を受け取って処理）、グルー・コード（複数のサービスやAPIをつなぐ中間処理）など
Fleet：
計算負荷の大きい処理（複数の仮想マシンやGPUが必要なもの）まとめて実行するもの
（使用例）シミュレーション、機械学習など
7-3. 名前
アプリケーションの名前を記入します。
今回はバックエンド側なので tdc-rehorenso-backend と記載します。
7-4. コードのビルド
今回はGitHubからコードを簡単にビルドできる ソース・コードからコンテナ・イメージをビルドする を選択します。
他の方法については以下に補足します。
既存のコンテナ・イメージを使用：
Docker Hub や IBM Cloud Container Registry などに保存されているコンテナ・イメージをビルドする方法
ソースコードからコンテナ・イメージをビルドする：
- Dockerfile を基にコンテナ・イメージをビルドする方法
- Cloud Native Buildpacks を使用して
Dockerfileなしでコンテナ・イメージをビルドする方法
の2種類があります。
7-5. ビルドの詳細の指定
ビルドの詳細の指定 を選択し、入力します。
今回は、リポジトリの中に複数の Dockerfile があるため、詳細の指定を選択します。
7-6. ビルドの詳細の指定 (1/3)
パラメータは以下のように設定しました。
| 項目 | 値 |
|---|---|
| コード・リポジトリURL | GitHubのURL |
| SSHシークレット | 6-5で作成したSSHの秘密鍵(tdc-ssh-key) |
| ブランチ名 | main |
| コンテキスト・ディレクトリー | backend/ |
ここで、
SSHシークレットは、Gitリポジトリにアクセスするための秘密鍵となっています。
ブランチ名は GitHub でビルドしたいブランチ名を記載します。
コンテキスト・ディレクトリーはリポジトリー内のソース（Dockerfileがあるパス）を指定します。
今回は以下のディレクトリ構造になっているため、
フロントエンドは frontend/
バックエンドは backend/
と記載します。
C:.
│
├─backend
│ └─ Dockerfile
│
└─frontend
└─ Dockerfile
7-7. ビルドの詳細の指定 (2/3)
ここでは、GitHubのリポジトリ内で指定するコンテナ化のファイル等を指定します。
今回のリポジトリは Dockerfile を使用し、ファイル名 Dockerfile であるため、以下の表の通りに設定します。また、構成も大きくないため、ビルド用のソースは一番小さいSを利用します。
| 項目 | 値 |
|---|---|
| 戦略 | Dockerfile |
| Dockerfile | Dockerfile |
| タイムアウト | 10m |
| ビルド用のリソース | S (0.5 vCPU / 2 GB) |
7-8. ビルドの詳細指定 (3/3)
ビルドしたコンテナを保存する項目について指定をします。
値は以下の通りに設定します。
| 項目 | 値 |
|---|---|
| レジストリ・サーバー | private.jp.icr.io (東京) |
| レジストリ・シークレット | 4-3で作成したレジストリ・シークレット (tdc-reg-key) |
| 名前空間 | 2-2で作成した名前空間 |
| リポジトリー（イメージ名） | rehorenso-backend |
| タグ | 空欄 |
レジストリ・サーバーは4-3で作成したレジストリ・シークレットのロケーション（今回はprivate.jp.icr.io (東京)）を指定します。
これでビルドに必要な情報は揃いました。
7-9. インスタンス・リソース
インスタンスリソースでは、1つのインスタンスで使用するCPU、メモリー、一時ストレージを設定します。
今回はデプロイして動作を確認するだけであるため、CPUおよびメモリー・一時ストレージは最小構成の以下の通りに設定しました。
| 項目 | 値 |
|---|---|
| CPUおよびメモリー | 0.125個のvCPU / 0.25GB |
| 一時ストレージ (GB) | 0.4 |
インスタンス・リソースの量の補足
- CPU およびメモリーは処理の負荷が大きい（機械学習やシミュレーション）ほどリソース量を大きくなる
- 一時ストレージは動画像データや大量のデータを利用する（画像処理や機械学習）ほどリソース量が大きくなる
インスタンス・リソースはビルド後でも修正することができるため、スモールスタートで作成し、処理負荷に応じて増やしていくことがおすすめします。
7-10. 自動スケーリング・インスタンスのスケーリング範囲
今回は、実際にデプロイができるのかの確認を行うため、以下の設定で行いました。
| 項目 | 値 |
|---|---|
| インスタンスの最小数 | 0 |
| インスタンスの最大数 | 1 |
各項目の内容について以下に補足します。
自動スケーリング：
トラフィックが 7-10 のインスタンスリソースを超える場合に自動でインスタンスリソースの数を増やしてパフォーマンスを最適化するものです。
スケーリング範囲：
自動スケーリングをした際のスケーリングの上限値、下限値を設定するもの
また、
インスタンスの最小数を０にするとトラフィックがない場合は停止状態となり、最初のアクセスの際に起動時間が少しかかってしまいます。
常に起動していたい場合はインスタンスの最小数を１以上にすることをお勧めします。
7-11. 自動スケーリング・要求の並行性とタイミングの設定
今回は、実際にデプロイができるのかの確認を行うため、以下の設定で行いました。
| 項目 | 値 |
|---|---|
| ターゲット並行性 | 100 (デフォルト) |
| 最大並行性 | 100 (デフォルト) |
| 要求タイムアウト（秒） | 300 (デフォルト) |
| スケールダウン遅延（秒） | 0 (デフォルト) |
各項目の内容について以下に補足します。
ターゲット並行性
1台あたり何件の同時リクエストでスケールアップを始めるかを決める目安であり、平均が100件以上になった場合、新しいインスタンスを作成します。
最大並行性
1台のインスタンスが同時に処理できるリクエスト数の上限であり、上限を超えたら新しいインスタンスを作成します。
要求タイムアウト
アプリケーションが要求に応答する時間であり、この時間を超えた場合処理が失敗します。
スケールダウン遅延
最大並行性とターゲット並行性が指定値から低下した際の連続経過時間の基準であり、この基準を超えたら自動的にスケールダウン（インスタンスの削除）をします。
0秒の場合は最大並行性とターゲット並行性が指定値が少しでも低下した瞬間にスケールダウンをすることを示します。
7-12. ドメイン・マッピング
バックエンド処理はセキュリティの観点から内部アクセスのみ可能にするため、プライベートを選択します。
| 項目 | 値 |
|---|---|
| オプションの選択 | プライベート |
7-13. オプションの設定
その他オプションの設定では、環境変数とイメージ始動オプションの設定を行います。
7-14. 環境変数の設定 (1/2)
まず、watsonx.ai と連携するために5-4で設定したプロジェクトIDの configmap を連携します。
| 項目 | 値 |
|---|---|
| 定義タイプ | configmap内のキー参照 |
| 名前のオーバーライド | 空欄 |
| Configmap | 5-4で設定した Configmap名(watsonx-project-id) |
| キー | 5-4で設定したキー(WATSONX_PROJECT_ID) |
名前のオーバーライドとは、設定したキーの値を変更したい場合に設定します。
7-15. 環境変数の設定(2/2)
同様に、watsonx.ai と連携するために 3-4 で設定したAPIキーを watsonx-api-keyに連携します。
| 項目 | 値 |
|---|---|
| 定義タイプ | シークレット内のキー参照 |
| 名前のオーバーライド | 空欄 |
| シークレット | 3-4で設定したAPIキー(watsonx-api-key) |
| キー | 3-4で設定したAPIキー( WATSONX_API_KEY) |
7-16. リスニングポートの設定
ここではバックエンドのリスニングポートを設定します。
今回作成したバックエンドは5000番ポートを利用しているため、この値を5000番ポートに変更します。
ここのポート番号とソースコードで利用するポート番号が一致しないとリビジョン失敗とエラーが出るので注意！
7-17. Code Engineの作成！（バックエンド）
作成ボタンを押してデプロイができるか確認しましょう。
次のような画面になり、 対応可能 と出ることでバックエンドの実装は終了です。
無事バックエンドのデプロイは完了しました。
構成を選択すると、作成した際のリソースおよびスケーリングや環境変数、Volume mounts、イメージ始動オプションなどを変更し、リビルドすることができます。
7-18. バックエンドアクセス用のURL (外部システム・ドメイン・マッピング)を取得
ここでは、フロントエンドがバックエンドにアクセスするための URL (外部システム・ドメイン・マッピング) を取得する方法を説明します。
作成手順
作成したtdc-rehorenso-backendを開いて、ドメイン・マッピングを選択し、 プライベートのURL をコピーします。
この設定を行わないとフロントエンドとバックエンドの連携ができません。
7-19. 取得した外部バックエンドアクセス用の URL を configmap に登録
4-1参照し、バックエンドアクセス用の URL を以下に示すように configmap に登録します。
| 項目 | 値 |
|---|---|
| 定義タイプ | Configmap |
| Configmap名 | backend-api-url |
| キー | BACKEND-API-URL |
| 値 | バックエンド編7-18 で取得したバックエンドアクセス用のURL |
これでバックエンドのデプロイは完了しました。
まとめ
今回はIBM Cloud Code Engine を使用してバックエンド側のアプリケーションをビルド・デプロイしました。
次回は、フロントエンド側アプリケーションのデプロイから、フロントエンド・バックエンド連携を行い、完成させます。また、筆者がつまずいた点についても記載します。ぜひ、ご覧ください。
次の記事はこちら【IBM Cloud Code Engineを用いてWebアプリケーションをデプロイしてみる ~フロントエンド編（完成）/ つまずき集~】