Kubernetes へのアプリのデプロイ
このチュートリアルでは、さまざまなデプロイメント戦略を使用してオープン・ツールチェーンを作成する方法について学習します。 また、ツールチェーンが IBM Cloud® Continuous Delivery サービスに実装される方法、およびツールチェーンを使用して単純な Web アプリケーション (アプリ) の開発およびデプロイの方法についても学びます。
このチュートリアルはブラウザー・ベースです。 IBM Cloud Terraform プロバイダーの例 ibm-cd-toolchain-simple-helmに示されているように、Terraform で同様のオープン・ツールチェーンを作成することもできます。
このチュートリアルでは、デプロイメント・ターゲットとして Kubernetes を使用するデプロイメント戦略を使用します。 このチュートリアルで使用するツールチェーンは、コード・スキャン、受け入れテスト、 Git リポジトリー、継続的統合機能、継続的デリバリー機能などの標準 DevOps プラクティスを実装します。 Kubernetes クラスターとツールチェーンを作成した後、アプリのコードを変更し、その変更を Git Repos and Issue Tracking リポジトリーにプッシュします。 リポジトリーに変更をプッシュすると、Tekton ベースの delivery pipeline が自動的にコードをビルドしてデプロイします。
Tekton は、ベンダーに依存しないオープン・ソースの Kubernetesネイティブ・フレームワークであり、アプリケーションのビルド、テスト、およびデプロイに使用できます。 Tektonは、継続的インテグレーションと継続的デリバリーシステムを構築するための共有コンポーネント群を提供する。 オープンソースプロジェクトとして、Tektonは Continuous DeliveryFoundationによって管理されている。 この目標は、パイプライン、ワークフロー、およびその他のビルディング・ブロックの業界仕様の提供による、継続的デリバリーの最新化です。 Tekton を使用すると、基礎となる実装の詳細を抽象化することにより、複数のクラウド・プロバイダーやオンプレミス・システムにわたって構築、テスト、およびデプロイを行えます。 Tekton パイプラインは、 Continuous Deliveryに組み込まれています。
このチュートリアルで使用するテンプレートは、Kubernetes の標準プランまたはライト・プランのいずれかで機能します。 標準プランでは、DNS 名を使用してアプリにアクセスできます。 ライト・プランでは、 ノード・ポートを使用してアプリにアクセスできます。
デプロイメント戦略を使用して、実稼働環境内のアプリケーションを制御された方法で更新できます。 デプロイメント戦略を使用すると、以下の利点があります:
- アプリケーションのダウンタイムを回避します。
- 顧客に影響を与えることなく、新機能の実稼働テストを可能にします。
- 実稼働の問題の影響をユーザーのサブセットに制限します。
- 問題が見つかった場合は、前のバージョンへの迅速なロールバックが有効になります。
使用可能なデプロイメント戦略は多数あります。 一般に、アプリケーションの複数インスタンスの実行と、各種インスタンスの更新方法の管理に依存します。 Continuous Delivery では、以下の一般的なデプロイメント戦略を事前構成できます:
- 基本
- 実行中のすべてのインスタンスを同時に停止および更新してダウンタイムを発生させて、新規リリースをデプロイします。 ロールバックの場合は、前のバージョンを再度デプロイする必要があります。これにより、追加のダウンタイムが発生します。 この戦略は単純で高速で、ランタイム・リソース要件が低いものですが、リスクが最も高いため、ダウンタイムが発生します。 高可用性を必要とする重要なアプリケーションに対しては、基本的なデプロイメント戦略は推奨されません。
- ローリング・アップデート
- 基本戦略と同様に、このデプロイメント戦略は単純で高速で、ランタイム・リソース要件が低くなっています。 ただし、実行中の各インスタンスは個別に停止および更新されるため、ダウンタイムを回避するため、ロールバックでは前のリリースを再度デプロイする必要があります。 この時間のかかるアプローチでは、実稼働中のアプリの現行バージョンが破損した場合に問題が発生する可能性があります。
- Blue-Green デプロイメント (blue-green deployment)
- 2 つの別個の永続的な実稼働環境 (blue と green ) を作成し、そのうちの 1 つの環境のみが一度にトラフィックを受信するようにします。 現行リリースは常にアイドル環境にデプロイされ、デプロイメントの完了後にトラフィックがそのリリースに切り替えられます。ダウンタイムは発生しません。 変更されていない環境にトラフィックを切り替えるだけで済むため、ロールバックによってダウンタイムが発生することはありません。 この戦略は 2 つの完全な実稼働環境を必要とするため、リソース要件は高くなります。 ただし、この戦略により、お客様のトラフィックを許可する前に実稼働環境で新しいアプリケーション・バージョンをテストする機能などの、強力な開発者フローが可能になります。 Blue-Green デプロイメントも高速ロールバックをサポートしています。
- Canary (カナリア) リリース
- ダウンタイムなしで、元の実稼働環境 (Blue-Green に類似) と並行して新規リリースをデプロイします。 更新されたインスタンスと元のインスタンスの両方に送信されるトラフィックの量は、デプロイメントの進行中に、ユーザーの制御されたサブセットが新しいバージョンを使用できるように管理されます。 時間の経過とともに、新しいバージョンに送信されるトラフィックは、すべてのトラフィックがそこに送信されるまで増加します。その時点で、古い実稼働環境を停止できます。 デプロイメントの進行中の迅速なロールバックのために、すべてのトラフィックを元の実稼働環境にルーティングできます。 この戦略では、デプロイメント時にのみ 2 つの完全な実稼働環境が必要になるため、リソース全体の使用量は Blue-Green デプロイメントの場合よりも低くなります。 カナリア・リリース・デプロイメント戦略は、デプロイされているソフトウェアの前のリリースから現行リリースへの移行が最も遅い戦略です。 カナリア・デプロイメントにより、組織は実稼働で 2 つの異なるソフトウェア・バージョンを横並びでテストできます。
開始前に
このチュートリアルを開始する前に、以下のリソースが用意されていることを確認してください:
-
IBM Cloud アカウント。 IBM Cloud アカウントのタイプによっては、特定のリソースへのアクセスが制限される場合があります。 アカウント・プランの制限によっては、一部のデプロイメント戦略で必要な特定の機能が使用できない場合があります。 IBM Cloudアカウントの詳細については、IBM Cloudアカウントの設定 および アカウントのアップグレード を参照してください。
-
Kubernetes クラスター および API キー。 これらのリソースは、UI または CLI のいずれかを使用して作成できます。 クラスターのプロビジョンには時間がかかることがあります。 クラスターが作成されると、「デプロイ中」、「保留中」、および「準備完了」の各ステージが進行します。 Kubernetes クラスターの詳細については、 Kubernetes クラスターを参照してください。 ライト・プランの場合はローリング・デプロイメントと Blue-Green デプロイメントを使用できますが、標準プランの場合は Kubernetes クラスターを作成する必要があります。
-
Continuous Delivery サービスのインスタンスです。
-
オプション。 シークレット管理ボールトに保管され、単一の場所から一元的に管理されるシークレット。 さまざまなシークレット管理オファリングおよびデータ保護オファリングからの選択の詳細については、 IBM Cloud シークレットの管理を参照してください。 選択したシークレット管理ボールト・プロバイダーのインスタンスがまだ存在しない場合は作成してください。
-
オプション。 container registry コマンド・ラインを使用して作成される名前空間。 名前空間を作成するには、コマンド・ラインから以下のコマンドを入力します:
ibmcloud cr namespace-add <my namespace>あるいは、 Container Registry ページで名前空間を作成することもできます。 このロケーションでの名前空間の作成の詳細については、 IBM Cloud Container Registry サービスを参照してください。
ツールチェーンを作成する
このステップでは、 Kubernetes アプリの開発 ツールチェーンを作成します。 ターゲット Kubernetes クラスターは、ツールチェーンのセットアップ時に IBM Cloud API キーと Kubernetes クラスター名を使用して構成されます。 これらの設定は、後で Delivery Pipeline 構成の更新で変更できます。 ターゲット Git リポジトリー・ブランチにマージされるコードはすべて、自動的にビルドされ、検証され、Kubernetes クラスターにデプロイされます。
Kubernetes アプリの開発 ツールチェーンを作成するには、以下をクリックします
または、IBM Cloudコンソールから、メニューアイコンの 
>DevOps をクリックします。 **「ツールチェーン」ページで、「ツールチェーンの作成」**をクリックします。 Create a Toolchain ページで、Develop aKubernetesapp をクリックします。
ツールチェーン名とリージョンの構成
ツールチェーン設定のデフォルト情報を確認します。 ツールチェーンの名前は、そのツールチェーンを IBM Cloud 内で識別するためのものです。 IBM Cloud の同じリージョン、同じリソース・グループのツールチェーンにおいてツールチェーン名が固有になるようにしてください。
ツールチェーンのリージョンは、クラスターおよびレジストリーのリージョンとは違っていてもかまいません。
デプロイメント戦略の選択
ツールチェーンは、 IBM Cloud® Kubernetes Service にアプリケーション Docker イメージをデプロイするための継続的デプロイメント・パイプラインを作成します。 使用したいデプロイメント戦略を選択します。 どのデプロイメント戦略 (ローリング、Blue-Green 、またはカナリア) を選択するかに基づいて、詳細を指定する必要があります。
-
ツールチェーンに使用するデプロイメント・ストラテジーをクリックします。
Deployment strategies -
「続行」 をクリックします。
アプリケーション・ソース・コード・リポジトリーの構成
アプリケーション・ステップでは、アプリケーション・ソース・コード・リポジトリーの推奨オプションがデフォルトで表示されます。 基礎となる Git 統合で使用可能なすべてのオプションを表示するには、 拡張オプションをクリックします。 デフォルトでは、ツールチェーンはサンプル・アプリを IBM がホストする Git Repos and Issue Tracking リポジトリーとして複製するデフォルトのサンプルを使用します。
アプリ・リポジトリーの名前を変更できます。 リポジトリーのリージョンは、ツールチェーンのリージョンと同じままになります。
ツールチェーン・テンプレートは、 サンプル NodeJS アプリケーションを提供します。 ツールチェーンの既存のアプリケーション・リポジトリーをリンクする場合は、 独自のアプリの持ち込み を選択し、リポジトリーの URL を指定します。 ツールチェーンは、既存の Git Repos and Issue Tracking リポジトリーへのリンクのみをサポートします。
デフォルトでは、アプリケーション・リポジトリー・テンプレートは Git Repos and Issue Tracking org に複製されます。 org を変更するには、 拡張オプション を有効にして、リポジトリーの所有者を指定します。
インベントリー・リポジトリーを構成します
インベントリー・リポジトリーは、継続的統合ツールチェーンによってビルドされた成果物の詳細を記録します。 インベントリー・リポジトリ・テンプレートのクローンである新しいインベントリー・リポジトリを作成するか、ツールチェーン間で共有する既存のインベントリー・リポジトリを使用することができます。
デフォルトでは、インベントリー・リポジトリー・テンプレートは Git Repos and Issue Tracking org に複製されます。 org (組織) を変更するには、 拡張オプション を選択し、リポジトリー所有者を指定します。
シークレットの安全な保管
このツールチェーン内のいくつかのツールは、 IBM Cloud API キーなどのシークレットを必要とします。 すべてのシークレットをシークレット・ボールトに安全に保管し、ツールチェーンの要求に従ってそれらのシークレットを参照する必要があります。
IBM Cloud を使用して、さまざまなシークレット管理およびデータ保護のオファリングから選択できます。これらのオファリングは、機密データの保護とシークレットの一元化に役立ちます。 「シークレット (Secrets)」ステップでは、ツールチェーンに追加またはツールチェーンから削除するシークレット・ボールト統合を指定できます。 前提条件を含むボールト統合の追加と削除、およびヒント使用の詳細については、 IBM Cloud シークレットの管理を参照してください。
テンプレート内でのヒントの使用により、ツールチェーンには事前構成されたシークレットが自動的に取り込まれます。ツールチェーンに付加されたボールト統合からシークレットを手動で選択する必要はありません。
このチュートリアルでは、 IBM Secrets Manager をシークレット・ボールトとして使用します。
IBM Secrets Manager は、ツールチェーンの一部である API キー、イメージ・シグニチャー、または HashiCorp 資格情報などのシークレットを安全に保管して適用します。
IBM Key Protect または HashiCorp でのシークレットの管理の詳細については、 IBM Key Protect または HashiCorp を参照してください。
デプロイメント・ターゲットの構成
アプリのデプロイ先のターゲット Kubernetes クラスターを構成します。 アプリがビルド、テスト、およびスキャンのフェーズに合格すると、パイプラインはビルドされたアプリ・イメージをターゲット Kubernetes クラスターにデプロイします。 このデプロイメントは、受け入れテストまたは統合テストの準備ができました。
API キーに必要なアクセス権限がある場合、作成された API キー、ボールトから取得された API キー、または手動で指定された API キーを使用して、以下のフィールドが自動的にロードされます。 API キーが有効な場合は、 Container registry リージョンと名前空間クラスター・リージョン、名前、名前空間、およびリソース・グループの値が自動的に取り込まれます。 これらのフィールドはいずれも、ご使用の構成に合わせて更新できます。
-
アプリ名: アプリの名前です。 デフォルトのアプリ名は
hello-containersです。 -
IBM Cloud API キー: いくつかのタスクで
ibmcloudCLI ツールとの対話に使用される API キーです。 以下のいずれかの方法を使用して、使用したい API キーを指定します。- 選択したシークレット・ボールトから既存の API キーをインポートするには、キー・アイコンをクリックします。
- 既存の API キーをコピーしてペーストします。
- 新規 をクリックして API キーを作成します。
- 既存の API キーがない場合は、新規の
api-keyを生成します。
生成された API キーは、選択した既存のシークレット・ボールトに直ちに保存できます。
アプリは、指定したデプロイメント戦略を使用してデプロイされます。 以下の例は、ローリング・デプロイメントまたは Blue-Green デプロイメントの詳細を示しています。
カナリア・デプロイメント戦略を選択した場合は、追加のデプロイメント・ターゲットの詳細を指定する必要があります。
-
カナリア・ステップ・サイズ: カナリア・デプロイメントの新規リリースにリダイレクトするトラフィックの量を定義します。
-
カナリア・ステップ間隔: カナリア・デプロイメントの新規リリースに移動する各カナリア・テスト間の時間間隔を定義します。
オプションのツール統合の追加
追加の構成を行うことなく、 IBM Cloud® DevOps Insights ツール統合をツールチェーンに追加できます。
DevOps Insights は、作成されたツールチェーンに含まれています。 DevOps Insights の構成ステップを指定する必要はありません。 継続的統合パイプラインは、ツールチェーンに含まれている DevOps Insights インスタンスを自動的に使用します。 DevOps Insights は、コード、テスト、ビルド、およびデプロイメントのデータを集約して、すべてのチームおよびリリースの速度と品質を可視化します。
「続行」 をクリックします。
ツールチェーンのセットアップを完了します
「要約」ページで、 作成をクリックします。 以下のようにいくつかのステップが自動的に実行されて、ツールチェーンがセットアップされます。
パイプラインの作成後に、個々のツールチェーン統合を構成できます。
新しいツールチェーンを探索する
ツールチェーンの作成後、ツールチェーンの一部となる各ツール統合が図に示されます。
パイプラインを探索する
パイプラインを探索すると、ツールチェーンの流れや、各パイプライン内で実行されるさまざまな処理について理解することができます。 作成したばかりのツールチェーンには、以下の 3 つのパイプラインが含まれています:
- プル・リクエスト・パイプライン: 開発者が開発ブランチからマスター・ブランチ、またはリポジトリー内の他のいずれかのブランチに変更をマージすると実行されます。 プル要求パイプラインは、単体テストおよび静的スキャンをアプリケーション・ソース・コードに対して実行します。
- 継続的統合パイプライン: アプリケーション・ソース・コード・リポジトリーのマスター・ブランチに変更をマージすると実行されます。 継続的統合パイプラインは、アプリケーション・ソース・コード、 CIS チェック、および部品表 (BOM) チェックで単体テスト、コード・カバレッジ、および静的スキャンを実行します。 また、継続的デリバリー・パイプラインは、バイナリー・ビルド成果物を生成し、ツールチェーンで構成されているとおりにそれらを IBM Cloud® Kubernetes Service にアップロードします。 また、継続的統合パイプラインは、ビルド成果物のメタデータを生成し、それをインベントリー・リポジトリーに保管します。
- 継続的デプロイメント・パイプライン: ビルド成果物をデプロイメント環境にデプロイします。 パイプラインは、ヘルス・チェックを実行して、アプリの正常なデプロイメントを検証します。 継続的統合パイプラインが正常に完了した後に、このパイプラインを手動でトリガーする必要があります。 選択したデプロイメント戦略に応じて、継続的デリバリー・パイプラインにさらにトリガーが追加されます。
プル・リクエストと継続的統合パイプラインの実行。
プル・リクエスト・パイプラインを開始するには、アプリ・リポジトリーでマージ・リクエストを作成します:
- ツールチェーンの「概要」ページの**「リポジトリー」**カードで、
compliance-app-<timestamp>アプリ・リポジトリーをクリックします。 - マスター・リポジトリーから、ブランチを作成します。
- サンプル・ノード・アプリまたは README ファイルの一部のコードを更新して、これらの変更を保存します。
- マージ・リクエストを送信します。
- ツールチェーンの「概要」ページの**「リポジトリー」**カードで、
pr-pipelineリポジトリーをクリックしてプル・リクエスト・パイプラインを開始します。 プル・リクエスト・パイプラインのすべてのステージが正常に完了するまで、アプリ・リポジトリー内の対応するマージ要求は保留状態のままになります。 - プル・リクエスト・パイプラインが正常に実行されたら、それを選択して、完了したステップを探索できます。
継続的統合パイプラインを開始するには、アプリ・リポジトリーに継続的統合マージ・リクエストをマージします:
- マージ・リクエストに移動します。
- リクエストをマージして、変更がアプリ・リポジトリーのマスター・ブランチにコピーされるようにします。 継続的統合パイプラインが自動的にトリガーされます。
- 継続的統合ツールチェーンの「概要」ページの**「リポジトリー」**カードで、
ci-pipelineリポジトリーをクリックして継続的統合パイプラインを開始します。 - 継続的な統合パイプラインが正常に実行されたら、パイプラインの実行をクリックして、完了したステップを探索できます。
シフト・レフト・プラクティス
セキュアなアプリケーション開発の世界では、レフト・シフトは、障害やセキュリティーの脆弱性などの問題を防止して検出し、ソフトウェア・デリバリー・プロセスの早い段階でコンプライアンス・チェックを実行するプラクティスです。 レフト・シフトには、以下のプラクティスが含まれます。
- コードまたはリポジトリー自体に対して実行でき、ビルドされたイメージをできるだけ早くは必要としないチェックを実行します。 これらの検査により、非準拠コードがリポジトリーのマスター・ブランチにマージされないようにします。 証拠はプル・リクエスト・パイプラインからは収集されないので、その目的は、コンプライアンス検査をできるだけレフト・シフトすることです。
- すべてのチェックは、パイプラインの実行ごとに実行されます。 前の検査が失敗すると、パイプラインは次の検査に進みます。 実行に失敗があるかどうかの評価では、パイプライン・エバリュエーターがあるパイプラインの最終ステップを確認します。
単体テストおよび脆弱点スキャンの結果は、ツールチェーン内の DevOps Insights インスタンスに公開されます。 これらの結果を確認するには、ツールチェーン内の DevOps Insights タイルをクリックし、「品質ダッシュボード」ページに移動します。
パイプラインの実行に失敗があるかどうかの評価では、パイプライン・エバリュエーターがあるパイプラインの最終ステップを確認します。
継続的デリバリー・パイプラインの詳細はこちら
プル・リクエストと継続的統合パイプラインは、すべてのデプロイメント戦略で共通です。 継続的デリバリー・パイプラインの設計および実装の変更は、このチュートリアルで以前に選択したデプロイメント戦略に基づいています。
このチュートリアルでは、サンプル・アプリを使用してローリング・デプロイメント戦略がどのように機能するかを説明します。
ローリング・デプロイメントの詳細はこちら
このチュートリアルで使用するローリング・デプロイメント戦略は、 Continuous Delivery サービスでデプロイメント戦略を使用して Kubernetes で実稼働ワークロードを実行する方法を示しています。 継続的デリバリー・パイプラインは、ローリング・デプロイメント用に 2 つのトリガーを提供します。 継続的デリバリー・パイプラインは、以下のいずれかの方法で開始できます:
- 継続的デリバリー・パイプラインを手動でトリガーします。
- インベントリー・リポジトリー内の各
Mergeアクションの後に、継続的デリバリー・パイプラインを自動的にトリガーします。 マージ後に、継続的デリバリー・パイプライン実行を手動でトリガーする必要があります。
Git Repos and Issue Tracking トリガーは、自動継続的デリバリー・パイプラインをトリガーするようにセットアップされていますが、デフォルトでは無効になっています。 初めて変更をプロモートした後で、このトリガーを有効にできます。
{: caption="*継続的デリバリー・パイプラインにおけるローリングデプロイのトリガー
ローリング・デプロイメント戦略により、すべての実稼働インスタンスが新しいソフトウェア・バージョンでインクリメンタルに更新されるため、ダウンタイムは発生しません。 ただし、ロールバック・デプロイメントの戦略では、以前のリリースを再デプロイする必要があります。これは完了するまでしばらく時間がかかる場合があります。
継続的デリバリー・パイプラインが正常に実行されたら、継続的デリバリー・パイプラインの perform deployment ステップ内でアプリ URL を見つけられます。
{: caption="のURL
次のステップ
Kubernetes で実行されているサンプル・アプリを削除したい場合は、Kubernetes クラスターをクリーンアップする必要があります:
-
Kubernetes Cluster のホーム・ページに移動します。
-
サンプル・アプリが実行されているクラスターを選択します。
-
**「Kubernetes ダッシュボード (Kubernetes dashboard)」**をクリックします。
-
サンプル・アプリケーションが実行されているロケーションから、 名前空間を選択します。
Kubernetes namespace -
選択した名前空間内にリストされている関連するデプロイメント、サービス、および Ingress を削除します。
なにかお困りですか ?
Slackで参加して、 IBM Cloud® Continuous Delivery 開発チームからヘルプを入手します。
その他のサポート・オプションについては、Continuous Delivery のヘルプおよびサポートの利用を参照してください。