チェックポイント
Set up your environment
/ 10
Deploy the Spinnaker chart using Kubernetes Helm
/ 20
Building the Docker image
/ 20
Create service load balancers
/ 20
Deploy an image to production
/ 10
Triggering pipeline from code changes
/ 20
Spinnaker と Kubernetes Engine を使用した継続的デリバリー パイプライン
GSP114
概要
このハンズオンラボでは、Google Kubernetes Engine、Google Cloud Source Repositories、Google Cloud Container Builder、Spinnaker を使用して継続的デリバリー パイプラインを作成する方法を学びます。サンプル アプリケーションを作成したら、そのサービスを自動的にビルド、テスト、デプロイするように構成します。アプリケーション コードを変更すると、継続的デリバリー パイプラインがトリガーされ、新しいバージョンが自動的に再ビルド、再テスト、再デプロイされます。
目標
- Google Cloud Shell を起動して、Kubernetes Engine クラスタを作成し、ID とユーザー管理スキームを構成することによって、環境をセットアップする。
- サンプル アプリケーションをダウンロードして、Git リポジトリを作成してから、Google Cloud Source Repositories のリポジトリにアップロードする。
- Helm を使用して Spinnaker を Kubernetes Engine にデプロイする。
- Docker イメージをビルドする。
- アプリケーションが変更されたときに Docker イメージを作成するためのトリガーを作成する。
- アプリケーションを Kubernetes Engine に確実かつ継続的にデプロイするように、Spinnaker パイプラインを構成する。
- コード変更をデプロイしてパイプラインをトリガーし、本番環境へのロールアウトを監視する。
パイプライン アーキテクチャ
アプリケーション更新を継続的にユーザーに配布するには、ソフトウェアを確実にビルド、テスト、更新する自動プロセスが必要です。コード変更は、アーティファクトの作成、単体テスト、機能テスト、本番環境ロールアウトで構成されたパイプラインを自動的に通過する必要があります。場合によっては、コード更新をユーザーベース全体に配布する前にユーザーのサブセットにのみ適用し、実際の動作を確認したいケースもあるでしょう。これらのカナリア リリースのいずれかで不十分なことが判明した場合は、ソフトウェア変更を自動的な手順ですばやくロールバックできる必要があります。
Kubernetes Engine と Spinnaker を使用すると、堅牢な継続的デリバリー フローを作成できます。これにより、ソフトウェアを開発して検証したらすぐに出荷できるようになります。迅速なイテレーションが最終目標ですが、各アプリケーションのリビジョンが本番環境ロールアウトの候補になる前に、必ず自動検証をすべて通過する必要があります。特定の変更を自動化によって検査してから、アプリケーションを手動で検証し、さらにプレリリース テストを実施することもできます。
アプリケーションが本番環境用として準備が整ったとチームが判断したら、チームメンバーの 1 人が本番環境デプロイメント用として承認できます。
アプリケーション デリバリー パイプライン
このラボでは、次の図に示される継続的デリバリー パイプラインを構築します。
設定と要件
[ラボを開始] ボタンをクリックする前に
こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、Google Cloud のリソースを利用できる時間を示しています。
このハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境を使ってご自身でラボのアクティビティを行うことができます。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。
このラボを完了するためには、下記が必要です。
- 標準的なインターネット ブラウザ(Chrome を推奨)
- ラボを完了するために十分な時間を確保してください。ラボをいったん開始すると一時停止することはできません。
ラボを開始して Google Cloud コンソールにログインする方法
-
[ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側の [ラボの詳細] パネルには、以下が表示されます。
- [Google コンソールを開く] ボタン
- 残り時間
- このラボで使用する必要がある一時的な認証情報
- このラボを行うために必要なその他の情報(ある場合)
-
[Google コンソールを開く] をクリックします。 ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。
ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。
注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。 -
必要に応じて、[ラボの詳細] パネルから [ユーザー名] をコピーして [ログイン] ダイアログに貼り付けます。[次へ] をクリックします。
-
[ラボの詳細] パネルから [パスワード] をコピーして [ようこそ] ダイアログに貼り付けます。[次へ] をクリックします。
重要: 認証情報は左側のパネルに表示されたものを使用してください。Google Cloud Skills Boost の認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。 -
その後次のように進みます。
- 利用規約に同意してください。
- 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
- 無料トライアルには登録しないでください。
その後このタブで Cloud Console が開きます。
Cloud Shell をアクティブにする
Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。
- Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン をクリックします。
接続した時点で認証が完了しており、プロジェクトに各自の PROJECT_ID が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。
gcloud
は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。
- (省略可)次のコマンドを使用すると、有効なアカウント名を一覧表示できます。
-
[承認] をクリックします。
-
出力は次のようになります。
出力:
- (省略可)次のコマンドを使用すると、プロジェクト ID を一覧表示できます。
出力:
出力例:
gcloud
ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。
タスク 1. 環境を設定する
このラボに必要なインフラストラクチャと ID を構成します。最初に、Spinnaker とサンプル アプリケーションをデプロイするための Kubernetes Engine クラスタを作成します。
- デフォルトのコンピューティング ゾーンを設定します。
- Spinnaker チュートリアルのサンプル アプリケーションを使用して Kubernetes Engine クラスタを作成します。
クラスタの作成が完了するまでに、5~10 分ほどかかります。クラスタがプロビジョニングを完了するのを待って、次に進みます。
完了すると、クラスタの詳細(名前、ロケーション、バージョン、IP アドレス、マシンタイプ、ノード バージョン、ノード数、実行中であることを示すステータス)が記載されたレポートが表示されます。
ID およびアクセス管理を構成する
Cloud Identity and Access Management(Cloud IAM)サービス アカウントを作成して Spinnaker に権限を委任し、Cloud Storage にデータを保存できるようにします。Spinnaker は、パイプライン データを Cloud Storage に保存することで、信頼性と復元力を確保します。Spinnaker のデプロイメントが予期せず失敗した場合は、オリジナルと同じパイプライン データへのアクセス権を持つ同じデプロイメントを数分で作成できます。
次の手順で起動スクリプトを Cloud Storage バケットにアップロードします。
- サービス アカウントを作成します。
- 後のコマンドで使用するために、サービス アカウントのメールアドレスと現在のプロジェクト ID を環境変数に格納します。
-
storage.admin
ロールをサービス アカウントにバインドします。
- サービス アカウント キーをダウンロードします。後のステップで Spinnaker をインストールして、このキーを Kubernetes Engine にアップロードします。
出力:
タスク 2. Spinnaker パイプラインをトリガーする Cloud Pub/Sub を設定する
- Container Registry からの通知に使用する Cloud Pub/Sub トピックを作成します。
- イメージの push についての通知を受け取れるように、Spinnaker から読み取ることができるサブスクリプションを作成します。
- Spinnaker のサービス アカウントに、gcr-triggers サブスクリプションからの読み取り権限を付与します。
完了したタスクをテストする
[進行状況を確認] をクリックして、実行したタスクを確認します。環境が正常に設定されている場合は、評価スコアが表示されます。
タスク 3. Helm を使用して Spinnaker をデプロイする
このセクションでは、Helm を使用して Charts リポジトリから Spinnaker をデプロイします。Helm は、Kubernetes アプリケーションの構成とデプロイに使用可能なパッケージ マネージャです。
Helm は、Cloud Shell にインストール済みです。
Helm を構成する
- Helm にクラスタの cluster-admin ロールを付与します。
- Spinnaker に
cluster-admin
ロールを付与し、すべての名前空間にリソースをデプロイできるようにします。
- Helm の使用可能なリポジトリに stable チャートのデプロイを追加します(Spinnaker も含まれています)。
Spinnaker を構成する
- 引き続き Cloud Shell で、Spinnaker のパイプライン構成を保存するためのバケットを作成します。
- 次のコマンドを実行して、Helm による Spinnaker のインストール方法を記述する
spinnaker-config.yaml
ファイルを作成します。
Spinnaker チャートをデプロイする
- Helm コマンドライン インターフェースを使用して、構成セットとともにチャートをデプロイします。
- コマンドが完了したら次のコマンドを実行して、Cloud Shell から Spinnaker へのポート転送を設定します。
- Spinnaker ユーザー インターフェースを開くには、Cloud Shell ウィンドウの最上部で [ウェブでプレビュー]、[ポート 8080 でプレビュー] の順にクリックします。
ウェルカム画面に続いて、Spinnaker のユーザー インターフェースが表示されます。
このタブは開いたままにしておいてください。後ほど、ここから Spinnaker UI にアクセスします。
完了したタスクをテストする
[進行状況を確認] をクリックして、実行したタスクを確認します。Kubernetes Helm を使用して Spinnaker チャートが正常にデプロイされている場合は、評価スコアが表示されます。
タスク 4. Docker イメージのビルド
このセクションでは、アプリ ソースコードの変更を検出して Docker イメージをビルドしてから、Container Registry に push するように Cloud Build を構成します。
ソースコード リポジトリを作成する
- Cloud Shell のタブで、サンプル アプリケーションのソースコードをダウンロードします。
- ソースコードを展開します。
- ディレクトリをソースコードに変更します。
- このリポジトリの Git commit にユーザー名とメールアドレスを設定します。
[USERNAME]
は作成するユーザー名で置き換えます。
- ソースコード リポジトリへの最初の commit を行います。
- コードをホストするリポジトリを作成します。
- 新しく作成したリポジトリをリモート リポジトリとして追加します。
- コードを新しいリポジトリのマスター ブランチに push します。
-
ナビゲーション メニュー > [Source Repositories] をクリックして、コンソールにソースコードが表示されることを確認します。
-
[sample-app] をクリックします。
ビルドトリガーを構成する
Git タグがソース リポジトリに push されるたびに Docker イメージをビルドして push するように、Container Builder を構成します。Container Builder はソースコードを自動的にチェックアウトして、リポジトリ内の Dockerfile から Docker イメージをビルドし、そのイメージを Google Cloud Container Registry に push します。
-
Google Cloud コンソールで、ナビゲーション メニュー > [Cloud Build] > [Triggers] をクリックします。
-
[トリガーを作成] をクリックします。
-
次のトリガー設定を指定します。
-
名前:
sample-app-tags
- イベント: 新しいタグを push する
- 新しく作成した
sample-app
リポジトリを選択する。 -
タグ:
.*(任意のタグ)
-
構成:
Cloud Build 構成ファイル(yaml または json)
-
Cloud Build 構成ファイルの場所:
/cloudbuild.yaml
- [作成] をクリックします。
これ以降、ソースコード リポジトリに Git タグ(.*)を push すると、Cloud Builder が自動的にアプリケーションをビルドして、Docker イメージとして Container Registry に push します。
Spinnaker で使用するために Kubernetes マニフェストを準備する
Spinnaker は、クラスタにデプロイするために Kubernetes マニフェストにアクセスする必要があります。このセクションでは、Cloud Build での CI プロセス中にマニフェストを保存する Cloud Storage バケットを作成します。マニフェストが Cloud Storage に保存されると、Spinnaker はパイプラインの実行中にマニフェストをダウンロードして適用できます。
- バケットを作成します。
- バケットに対するバージョニングを有効にして、マニフェストの履歴を取得できるようにします。
- kubernetes デプロイメント マニフェストに正しいプロジェクト ID を設定します。
- リポジトリに変更を commit します。
イメージをビルドする
次の手順で最初のイメージを push します。
- Cloud Shell で、引き続き
sample-app
ディレクトリから Git タグを作成します。
- タグを push します。
出力:
- Google Cloud コンソールに移動します。引き続き Cloud Build で、左側のペインの [履歴] をクリックして、ビルドがトリガーされたことを確認します。トリガーされていない場合は、前のセクションでトリガーが正しく構成されているかどうかを確認します。
ビルドが完了するまでこのページで待機します。完了したら、次のセクションに進みます。
ビルド
に失敗した場合、ビルド ID
をクリックすると [ビルドの詳細] ページが開くので、[再試行] をクリックします。
完了したタスクをテストする
[進行状況を確認] をクリックして、実行したタスクを確認します。Docker イメージが正常にビルドされている場合は、評価スコアが表示されます。
タスク 5. デプロイメント パイプラインを構成する
これでイメージが自動的にビルドされるようになりました。イメージは Kubernetes クラスタにデプロイする必要があります。
統合テストに備えてスケールダウンされた環境にデプロイします。統合テストに合格したら、コードを本番環境サービスにデプロイするための変更を手動で承認する必要があります。
Spinnaker を管理する spin CLI をインストールする
spin は、Spinnaker のアプリケーションとパイプラインを管理するためのコマンドライン ユーティリティです。
- バージョン 1.14.0 の
spin
をダウンロードします。
-
spin
を実行可能にします。
デプロイメント パイプラインを作成する
- spin を使用して、Spinnaker 内に sample という名前のアプリを作成します。このアプリのオーナーのメールアドレスを設定します。
次に、継続的デリバリー パイプラインを作成します。このチュートリアルでは、文字「v」で始まるタグが付いた Docker イメージが Container Registry に到着したことを検出するようにパイプラインが構成されます。
-
sample-app
ソースコード ディレクトリから次のコマンドを実行します。これにより、サンプル パイプラインが Spinnaker インスタンスにアップロードされます。
パイプラインの実行を手動でトリガーして確認する
ここまでの手順で作成した構成では、新しくタグ付けされたイメージが push された際の通知を利用して Spinnaker パイプラインをトリガーします。前のステップでは、タグを Cloud Source Repositories に push しました。これによって、Cloud Build でイメージのビルドと Container Registry への push がトリガーされます。このパイプラインを確認するために、手動でトリガー
してみましょう。
- Spinnaker UI が表示されているブラウザタブに切り替えます。
見つからない場合は、Cloud Shell ウィンドウで [ウェブでプレビュー] > [ポート 8080 でプレビュー] を選択すると、このタブをもう一度表示できます。
- Spinnaker UI で、画面の上部にある [Applications] をクリックし、マネージド アプリケーションのリストを表示します。
sample が作成したアプリケーションです。sample が表示されない場合は、Spinnaker の [Applications] タブを更新してみてください。
-
[sample] をクリックしてアプリケーション デプロイメントを表示します。
-
上部にある [Pipelines] をクリックして、アプリケーションのパイプラインのステータスを表示します。
-
[Start Manual Execution] をクリックし、[Select Pipeline] で [Deploy] を選択します。次に、[Run] をクリックしてパイプラインを初めてトリガーします。
-
[Execution Details] をクリックして、パイプラインの進行状況の詳細を表示します。
進行状況バーで、デプロイメント パイプラインのステータスとそのステップを確認できます。
青色のステップは現在実行中です。緑色は正常に完了したステップ、赤色は失敗したステップを示します。
- ステージをクリックして、その詳細を表示します。
3~5 分後に統合テストフェーズが完了すると、デプロイメントの続行を手動で承認するようパイプラインから要求されます。
- 黄色の「人物」アイコンにカーソルを合わせ、[続行] をクリックします。
ロールアウトが本番環境フロントエンドと本番環境バックエンドのデプロイメントに進みます。これは数分後に完了します。
-
アプリを表示するには、Spinnaker UI の上部で [Infrastructure] > [Load Balancers] を選択します。
-
ロードバランサのリストを下にスクロールし、
service sample-frontend-production
の下の [Default] をクリックします。ロードバランサの詳細がページの右側に表示されます。表示されない場合は、ブラウザを更新する必要があります。 -
右側の詳細ペインをスクロール ダウンし、Ingress IP のクリップボード ボタンをクリックしてアプリの IP アドレスをコピーします。Spinnaker UI から Ingress IP へのリンクではデフォルトで HTTPS が使用される場合がありますが、このアプリケーションは HTTP を使用するように構成されています。
- コピーしたアドレスを新しいブラウザタブに貼り付けて、アプリケーションを表示します。canary バージョンが表示される場合がありますが、画面を更新すると production バージョンも表示されます。
これで、アプリケーションをビルド、テスト、デプロイするためのパイプラインを手動でトリガーしました。
完了したタスクをテストする
[進行状況を確認] をクリックして、実行したタスクを確認します。サービス ロードバランサが正常に作成されている場合は、評価スコアが表示されます。
完了したタスクをテストする
[進行状況を確認] をクリックして、実行したタスクを確認します。イメージが正常に本番環境にデプロイされている場合は、評価スコアが表示されます。
タスク 6. コードの変更によりパイプラインをトリガーする
ここで、コードの変更、Git タグの push、レスポンスでのパイプライン実行の監視を通して、パイプラインをエンドツーエンドでテストします。"v" で始まる Git タグを push すると、新しい Docker イメージをビルドして Container Registry に push するための Container Builder がトリガーされます。Spinnaker は新しいイメージタグが "v" で始まることを検出すると、イメージをカナリアにデプロイしてテストを実行し、同じイメージをデプロイメント内のすべての Pod にロールアウトするためのパイプラインをトリガーします。
- sample-app ディレクトリから次のコマンドを実行して、アプリの色をオレンジ色から青色に変更します。
- 変更にタグを付け、ソースコード リポジトリに push します。
- コンソールで [Cloud Build] > [履歴] を開き、新しいビルドが表示されるまで数分待ちます。必要であればページを更新します。新しいビルドが完了するまで待ってから次のステップに進みます。
ビルド
に失敗した場合、ビルド ID
をクリックして [再試行] をクリックしてください。- Spinnaker UI に戻り、[Pipelines] をクリックして、イメージのデプロイを開始するパイプラインの動作を監視します。自動的にトリガーされたパイプラインは、表示されるまでに数分かかります。必要であればページを更新します。
完了したタスクをテストする
[進行状況を確認] をクリックして、実行したタスクを確認します。コードの変更によるパイプラインのトリガーが正常に行われた場合は、評価スコアが表示されます。
タスク 7. カナリア デプロイを観察する
-
デプロイが一時停止し、本番環境へのロールアウトを待機している間に、実行中のアプリケーションを表示しているウェブページに戻ります。アプリが表示されているタブを繰り返し更新してください。バックエンドのうちの 4 つがアプリの以前のバージョンを実行しており、カナリアを実行しているバックエンドは 1 つだけです。5 回更新するごとにアプリの新しい青色バージョンが表示されるはずです。
-
パイプラインが完了すると、アプリは次のスクリーンショットのようになります。コードを変更したため、色は青色に変わっています。また、[バージョン] フィールドには
canary
と示されるようになっています。
これで、アプリを本番環境全体に正常にロールアウトできました。
- 必要に応じて前回の commit を元に戻し、この変更をロールバックできます。ロールバックすると新しいタグ(v1.0.2)が追加され、v1.0.1 をデプロイするときに使用したのと同じパイプラインを通してタグが戻されます。
Ctrl+O、Enter、Ctrl+X キーの順に押します。
- ビルドとパイプラインが完了したら、ロールバックを確認します。[Infrastructure] > [Load Balancers] をクリックしてから、service sample-frontend-production の [Default] をクリックして Ingress IP アドレスをコピーします。このアドレスを新しいタブに貼り付けます。
アプリがオレンジ色に戻り、production
バージョン番号を確認できます。
お疲れさまでした
これで、「Spinnaker と Kubernetes Engine による継続的デリバリー パイプライン」ラボが完了しました。
クエストを完了する
このセルフペース ラボは、「Google Cloud Solutions I: Scaling Your Infrastructure」と「DevOps Essentials」クエストの一部です。クエストとは学習プログラムを構成する一連のラボのことで、完了すると成果が認められてバッジが贈られます。バッジは公開して、オンライン レジュメやソーシャル メディア アカウントにリンクできます。このラボの修了後、このラボが含まれるクエストに登録すれば、すぐにクレジットを受け取ることができます。受講可能なすべてのクエストについては、Google Cloud Skills Boost カタログをご覧ください。
次のラボを受講する
「Running Dedicated Game Servers in Google Kubernetes Engine」でクエストを続行してください。
次のステップと詳細情報
- Jenkins による継続的デプロイメントについて理解する
- Compute Engine への Spinnaker のデプロイについて理解する
- Jenkins を Kubernetes Engine にデプロイする
- Spinnaker と Ansible を使用して継続的デリバリーを実行する
Google Cloud トレーニングと認定資格
Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。
マニュアルの最終更新日: 2023 年 11 月 21 日
ラボの最終テスト日: 2023 年 11 月 21 日
Copyright 2024 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。