はじめに
昨今の開発では、アプリケーションのビルド、サーバ環境へのデプロイを自動化し、早期にコンパイル・単体テストを実行して問題を把握したり、サーバにおけるアプリケーションの確認・テストのサイクルを迅速に回したりといった継続的インテグレーション・継続的デリバリ（CI/CD）が当たり前になっています。
CI/CDのパイプラインは、CI/CDにおけるビルド、デプロイ、テストなどの処理をステージ化し、それらをつなぎ合わせて自動化を実現するものです。IBM CloudでCI/CDのパイプラインを実装する場合、Continuous Deliveryサービス、および、それに含まれるToolchainを利用します。
当記事では、Toolchainを用いて、GitHub上のReactアプリケーションのソースコードからDockerイメージをビルドし、IBM Cloud Kubernetes Service（IKS）に対してデプロイする処理を自動化してみます。
デプロイ対象のアプリケーションとして、IBMが提供しているReactのサンプルアプリケーションを使用します。
前提事項
当記事の手順を実施するにあたり、以下を前提とします。
- IKSのクラスターを既に作成済みである（無料クラスターで可）
- IBM Cloud Container Registryのインスタンスを作成し、名前空間を作成済みである
- IBM Cloud CLIが導入済みである
上記が未実施の場合、別記事「QuarkusアプリをIBM Cloud Kubernetes Service(IKS)で動かしてみる」の該当箇所を実施ください。
APIキーの作成
手順の中で、IBM CloudのAPIキーを利用する場面がありますので事前に作成しておきます。
IBM Cloud CLIでログインします。
ibmcloud login -a cloud.ibm.com -r us-south
ログイン完了後、APIキーを生成します。
ibmcloud iam api-key-create api_key -d "this is my API key" --file key_file
上記により、「api_key」という名前でAPIキーが作成され、APIキーの値がコマンドを実行したディレクトリの「key_file」ファイルに格納されます。このファイルはJSON形式となっており、その中の「apikey」という項目の値をメモしておいてください。
Toolchainの作成
Continuous Deliveryの作成ページにアクセスします。
「リージョン」で「ダラス」を選択し、「作成」ボタンをクリックします。
Continuous Deliveryのインスタンスが作成され、以下の画面が表示されます。
次にToolchainを作成します。
Toolchainの作成ページにアクセスします。
画面下部にある「Build your ownツールチェーン」をクリックします。
Toolchainの名前を入力し、「リージョン」で「ダラス」を選択し、「作成」ボタンをクリックします。
ToolchainへのGitHubの組み込み
Toolchainが作成されるので、画面右側の「ツールの作成」ボタンをクリックします。
「GitHub」を選択します。
「認証」ボタンをクリックします。
すると、GitHubのサイトに遷移し、GitHubへのアクセス権限付与の承認ダイアログが表示されるので、承認します。
Toolchainのページに帰ってくるので、「リポジトリー・タイプ」に「既存」、「リポジトリーURL」に「https://github.com/IBM/deploy-react-kubernetes.git」（サンプルのReactアプリケーションのGitリポジトリ）を入力し、「統合の作成」ボタンをクリックします。
ToolchainへのDelivery Pipelineの組み込み
ToolchainにGitHubが組み込まれたので、次にビルド・デプロイ処理を盛り込んでいきます。
「ツールの作成」ボタンをクリックします。
「Delivery Pipeline」をクリックします。
「パイプライン・タイプ」として「Classic」を選択し、「統合の作成」ボタンをクリックします。
ビルド・デプロイステージの定義
「Delivery Pipeline」がToolchainに組み込まれたので、これをクリックします。
ここから、Dockerイメージをビルドする「Build Image」、ビルドしたイメージをIKSにデプロイする「Deploy to Cluster」という2つのステージをパイプラインに定義します。
「ステージの追加」ボタンをクリックします。
ステージの名前を「Build Image」に変更します。
ビルド対象の「ブランチ」を「master」に設定します。
「ステージ・トリガー」として、「このステージが手動で実行されたときにのみジョブを実行」を選択します。
（※masterにマージされたタイミングなどで自動的に実行するように構成するためには、対象のGitHubリポジトリに対する権限が必要となります。これを実現するためには、今回の対象のGitHubリポジトリをforkする必要があります）
「ジョブ」タブを選択し、「ジョブの追加」→「ビルド」を選択します。
「ビルダー・タイプ」として「Container Registry」を選択します。これにより、ビルドしたDockerイメージをContainer Registryに格納することになります。
また、「APIキー」のフィールドをクリックします。
APIキーの入力ダイアログが表示されるので、上記でメモしておいたAPIキーを入力し、「認証」ボタンをクリックします。
APIキーを入力すると、自動的にContainer Registryの情報が取得され、表示されます。
リージョンが正しいことを確認し、「Container Registry名前空間」に自身で作成した名前空間を指定し、「Dockerイメージ名」に任意のイメージ名を入力し、画面下部の「保存」ボタンをクリックします。
イメージをビルドするステージが追加されました。
赤枠部分のアイコンをクリックして（テスト目的の）ビルドを開始します。
ビルドが開始され、数分間待つと、以下のようにビルドが終了し、「ステージは成功」と表示されます。
これにより、指定したGitHubリポジトリからソースコードが取得され、ビルドされたイメージがContainer Registryに格納されます。
さらに、IKSへのデプロイを実行するステージを追加するため、「ステージの追加」ボタンをクリックします。
ステージの名前を「Deploy to Cluster」に変更します。
「Build Image」ステージでビルドされたDockerイメージを入力とするため、下記赤枠部分の通りに設定します（自動で設定されます）。
「ジョブ」タブを選択し、「ジョブの追加」→「デプロイ」を選択します。
「デプロイヤー・タイプ」として「Kubernetes」を選択します。
「APIキー」をクリックすると、「Build Image」ステージと同様にAPIキーの入力ダイアログが表示されるので、先ほどと同じAPIキーを入力します。
APIキーの入力後、デプロイ対象のIKSクラスターを選択します。
「IBM Cloud リージョン」でIKSのリージョンを指定します（無料クラスターの場合は「US South」）。
「クラスター名」でクラスターの名前を指定します。
当画面では「デプロイ・スクリプト」というフィールドに、このステージで実行されるデプロイ処理のスクリプトが表示されています。
通常であれば、スクリプト中でdocker inspectによりアプリケーションのポート番号を取得し、それをKubernetesのマニフェストファイル生成で使用するのですが、対象のサンプルアプリケーションではそれが正常に動作しないため、以下のようにPORT=3000と明示的に設定します。
その後、画面下部の「保存」ボタンをクリックします。
以下のように、「Build Image」に続けて、「Deploy to Cluster」というステージを構成することができました。
ビルドしたイメージをIKSにデプロイするため、「Deploy to Cluster」の実行ボタンをクリックします。
しばらく待つと、デプロイステージが完了し、以下のように「ステージは成功」と表示されます。
アプリケーションは自動的にNodePortサービスで公開されています。
デプロイのログにURLが出力されていますので、「ログおよび履歴の表示」をクリックします。
ログの最下部にポート番号付きのURLが出力されていますので、そのURLにアクセスしてください。
以下のような画面が表示されればデプロイ成功です。
IKSのPod、Servieを見てみると、Toolchainでビルドしたコンテナがデプロイされていることが分かります。
❯ kubectl get pods --all-namespaces | grep toolchain
default kubernetes-toolchain-01-6fd8df79c9-lfpj6 1/1 Running 0 2m58s
❯ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP xxx.xxx.xxx.xxx <none> 443/TCP 17d
kubernetes-toolchain-01 NodePort xxx.xxx.xxx.xxx <none> 3000:31745/TCP 4m58s
quarkus-getting-started NodePort xxx.xxx.xxx.xxx <none> 8080:32423/TCP 17d
※なお、このアプリケーションは、外部サイトへのAPI呼び出しにより検索処理を実現しています。
本来であれば、GitHubリポジトリをforkしたうえでgit cloneし、外部サイトへのAPIのキーを設定する必要があり、それを実施していない場合は検索処理がエラーとなります。