GSP051

概要

このラボでは、Kubernetes Engine で Jenkins を使用して継続的デリバリー パイプラインを設定する方法を学びます。Jenkins とは、共有リポジトリに頻繁にコードを統合するデベロッパーによく利用されているオートメーション サーバーです。このラボでは、次の図のようなソリューションを構築していきます。

Kubernetes で Jenkins を実行する方法について詳しくは、Cloud アーキテクチャ センターの Kubernetes Engine での Jenkins をご覧ください。

ラボの内容

このラボでは、次のタスクを行って Kubernetes での Jenkins の実行について学習します。

• Jenkins アプリケーションを Kubernetes Engine クラスタにプロビジョニングする
• Helm パッケージ マネージャーを使用して Jenkins アプリケーションを設定する
• Jenkins アプリケーションの機能を試す
• Jenkins パイプラインを作成して実行する

前提事項

このラボは上級者向けです。受講する前に、少なくともシェル プログラミング、Kubernetes、Jenkins の基礎を理解しておく必要があります。こうした基礎は、以下のラボで効率的に習得できます。

• Docker の概要
• Hello Node Kubernetes
• Kubernetes Engine によるデプロイの管理
• Kubernetes Engine での Jenkins の設定

準備ができたら下にスクロールして、Kubernetes、Jenkins、継続的デリバリーについて詳しく学んでいきましょう。

Kubernetes Engine とは

Kubernetes Engine は、高度なクラスタ マネージャーでありコンテナのオーケストレーション システムである Kubernetes の Google Cloud のホスト バージョンです。Kubernetes はオープンソースのプロジェクトで、ノートパソコンや可用性の高いマルチノード クラスタ、仮想マシンからベアメタルまで、さまざまな環境で利用できます。前述のように、Kubernetes アプリはコンテナ上に構築される、実行に必要なすべての依存関係とライブラリがバンドルされた軽量アプリケーションです。この基本的な構造により、Kubernetes アプリケーションの高可用性、安全性、迅速なデプロイといった、クラウド デベロッパーが理想とするフレームワークが実現します。

Jenkins とは

Jenkins は、ビルド、テスト、デプロイ用パイプラインの柔軟なオーケストレーションを可能にするオープンソースのオートメーション サーバーです。Jenkins を使用すれば、継続的デリバリーに起因するオーバーヘッドの問題を気に掛けることなく、プロジェクトに対して迅速に反復処理を行うことができます。

継続的デリバリーと継続的デプロイについて

継続的デリバリー（CD）パイプラインを設定する必要がある場合、Kubernetes Engine での Jenkins のデプロイには、標準の VM ベースのデプロイよりも大きなメリットがあります。

ビルドプロセスでコンテナを使用すると、1 つの仮想ホストが複数のオペレーティング システムでジョブを実行できます。Kubernetes Engine が提供するエフェメラル ビルド エグゼキュータは、ビルドがアクティブに実行されている場合にのみ使用されるため、バッチ処理ジョブなど、クラスタ内の他のタスク用にリソースを確保できます。エフェメラル ビルド エグゼキュータのもう 1 つの利点はスピードで、わずか数秒で起動します。

また、Kubernetes Engine には Google のグローバル ロードバランサが組み込まれており、これを使用してインスタンスへのウェブ トラフィックのルーティングを自動化することもできます。ロードバランサは SSL 終端処理を行い、Google のバックボーン ネットワーク（ユーザーのウェブフロントに結合）で構成されたグローバル IP アドレスを利用します。このロードバランサにより、ユーザーは常に最短パスでアプリケーション インスタンスに接続されます。

Kubernetes と Jenkins、および CD パイプラインにおける両者の関係についてある程度理解したところで、今度は実際に構築してみましょう。

設定と要件

[ラボを開始] ボタンをクリックする前に

こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、Google Cloud のリソースを利用できる時間を示しています。

このハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境を使ってご自身でラボのアクティビティを行うことができます。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

このラボを完了するためには、下記が必要です。

• 標準的なインターネット ブラウザ（Chrome を推奨）

注: このラボの実行には、シークレット モードまたはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生することを防ぎます。

• ラボを完了するために十分な時間を確保してください。ラボをいったん開始すると一時停止することはできません。

注: すでに個人の Google Cloud アカウントやプロジェクトをお持ちの場合でも、このラボでは使用しないでください。アカウントへの追加料金が発生する可能性があります。

ラボを開始して Google Cloud コンソールにログインする方法

1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側の [ラボの詳細] パネルには、以下が表示されます。

   • [Google コンソールを開く] ボタン
   • 残り時間
   • このラボで使用する必要がある一時的な認証情報
   • このラボを行うために必要なその他の情報（ある場合）

2. [Google コンソールを開く] をクリックします。 ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。

   ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

   注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。

3. 必要に応じて、[ラボの詳細] パネルから [ユーザー名] をコピーして [ログイン] ダイアログに貼り付けます。[次へ] をクリックします。

4. [ラボの詳細] パネルから [パスワード] をコピーして [ようこそ] ダイアログに貼り付けます。[次へ] をクリックします。

   重要: 認証情報は左側のパネルに表示されたものを使用してください。Google Cloud Skills Boost の認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

5. その後次のように進みます。

   • 利用規約に同意してください。
   • 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
   • 無料トライアルには登録しないでください。

その後このタブで Cloud Console が開きます。

注: 左上にある [ナビゲーション メニュー] をクリックすると、Google Cloud のプロダクトやサービスのリストが含まれるメニューが表示されます。

Cloud Shell をアクティブにする

Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン をクリックします。

接続した時点で認証が完了しており、プロジェクトに各自の PROJECT_ID が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。

2. （省略可）次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

3. [承認] をクリックします。

4. 出力は次のようになります。

出力:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. （省略可）次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project = <project_ID>

出力例:

[core] project = qwiklabs-gcp-44776a13dea667a6 注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。

タスク 1. ソースコードをダウンロードする

1. まず、Cloud Shell で新しいセッションを開き、次のコマンドを実行してゾーン を設定します。

gcloud config set compute/zone {{{project_0.default_zone}}}

2. ラボのサンプルコードをコピーします。

gsutil cp gs://spls/gsp051/continuous-deployment-on-kubernetes.zip . unzip continuous-deployment-on-kubernetes.zip

3. 適切なディレクトリに移動します。

cd continuous-deployment-on-kubernetes

タスク 2. Jenkins をプロビジョニングする

Kubernetes クラスタを作成する

1. 次に、以下のコマンドを実行して Kubernetes クラスタをプロビジョニングします。

gcloud container clusters create jenkins-cd \ --num-nodes 2 \ --machine-type e2-standard-2 \ --scopes "https://www.googleapis.com/auth/source.read_write,cloud-platform"

この手順の完了には数分かかることがあります。追加のスコープで、Jenkins が Cloud Source Repositories と Google Container Registry にアクセスできるようになります。

完了したタスクをテストする

[進行状況を確認] をクリックして、実行したタスクを確認します。Kubernetes クラスタが正常に作成されている場合は、評価スコアが表示されます。

Kubernetes クラスタを作成する（ゾーン: )

2. 続行する前に、次のコマンドを使用してクラスタが実行されていることを確認します。

gcloud container clusters list

3. 次に、クラスタの認証情報を取得します。

gcloud container clusters get-credentials jenkins-cd

4. Kubernetes Engine はこれらの認証情報を使用して、新たにプロビジョニングされたクラスタにアクセスします。次のコマンドを実行して、クラスタに接続できることを確認してください。

kubectl cluster-info

タスク 3. Helm を設定する

このラボでは、Helm を使用して Charts リポジトリから Jenkins をインストールします。Helm は、Kubernetes アプリケーションの構成とデプロイを容易にするパッケージ管理システムです。Jenkins をインストールすると、CI / CD パイプラインを設定できるようになります。

1. Helm の stable チャート リポジトリを追加します。

helm repo add jenkins https://charts.jenkins.io

2. リポジトリが最新であることを確認します。

helm repo update

タスク 4. Jenkins を構成、インストールする

Jenkins のインストール時に、設定に必要な値をテンプレートとして提供する values ファイルを使用できます。

カスタムの values ファイルを使用して Kubernetes クラウドを自動的に構成し、以下の必要なプラグインを追加します。

• Kubernetes:latest
• Workflow-multibranch:latest
• Git:latest
• Configuration-as-code:latest
• Google-oauth-plugin:latest
• Google-source-plugin:latest
• Google-storage-plugin:latest

これにより、Jenkins がクラスタと GCP プロジェクトに接続できるようになります。

1. Helm CLI を使用して、構成設定とともにチャートをデプロイします。

helm install cd jenkins/jenkins -f jenkins/values.yaml --wait

このコマンドは完了までに数分かかる場合があります。

完了したタスクをテストする

[進行状況を確認] をクリックして、実行したタスクを確認します。Jenkins チャートが正常に構成されている場合は、評価スコアが表示されます。

Jenkins を構成、インストールする

2. コマンドが完了したら、Jenkins Pod が Running 状態になり、コンテナが READY 状態になっていることを確認します。

kubectl get pods

出力例:

NAME READY STATUS RESTARTS AGE cd-jenkins-7c786475dd-vbhg4 2/2 Running 0 1m

3. クラスタにデプロイできるように Jenkins サービス アカウントを構成します。

kubectl create clusterrolebinding jenkins-deploy --clusterrole=cluster-admin --serviceaccount=default:cd-jenkins

次の出力が表示されます。

clusterrolebinding.rbac.authorization.k8s.io/jenkins-deploy created

4. 次のコマンドを実行して、Cloud Shell から Jenkins UI へのポート転送を設定します。

export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/component=jenkins-master" -l "app.kubernetes.io/instance=cd" -o jsonpath="{.items[0].metadata.name}") kubectl port-forward $POD_NAME 8080:8080 >> /dev/null &

5. Jenkins サービスが適切に作成されたことを確認します。

kubectl get svc

出力例:

NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE cd-jenkins 10.35.249.67 8080/TCP 3h cd-jenkins-agent 10.35.248.1 50000/TCP 3h kubernetes 10.35.240.1 443/TCP 9h

Jenkins マスターがリクエストしたときに必要に応じて自動的にビルダーノードが起動するように、Kubernetes プラグインを使用しています。処理が完了するとノードが自動的に終了し、リソースがクラスタのリソースプールに戻されます。

このサービスでは、selector に一致するすべての Pod のポート 8080 と 50000 が公開されることに注意してください。ここでは、Kubernetes クラスタ内の Jenkins ウェブ UI ポートとビルダー / エージェント登録ポートが公開されます。また、jenkins-ui サービスは ClusterIP を使用して公開されるため、クラスタ外からはアクセスできません。

タスク 5. Jenkins に接続する

1. Jenkins チャートによって管理者パスワードが自動的に作成されます。このパスワードを取得するには、以下を実行します。

printf $(kubectl get secret cd-jenkins -o jsonpath="{.data.jenkins-admin-password}" | base64 --decode);echo

2. Jenkins ユーザー インターフェースを表示するには、Cloud Shell でウェブでプレビュー アイコンをクリックし、[ポート 8080 でプレビュー] をクリックします。

3. ユーザー名「admin」と自動生成されたパスワードでログインします。

これで、Kubernetes クラスタに Jenkins が設定されました。次のセクションでは、自動化した CI / CD パイプラインを Jenkins によって実行します。

タスク 6. アプリケーションについて理解する

継続的デプロイ パイプラインにサンプル アプリケーション gceme をデプロイします。このアプリケーションは Go 言語で作成され、リポジトリの sample-app ディレクトリに保存されます。Compute Engine インスタンスで gceme バイナリを実行すると、アプリの情報カードにインスタンスのメタデータが表示されます。

2 つのオペレーション モードに対応するこのアプリケーションは、マイクロサービスの挙動を模倣します。

• バックエンド モードでは、gceme がポート 8080 をリッスンし、Compute Engine インスタンスのメタデータを JSON 形式で返します。
• フロントエンド モードでは、gceme がバックエンド gceme サービスにクエリを送信し、ユーザー インターフェースに JSON を表示します。

タスク 7. アプリケーションをデプロイする

アプリケーションを 2 つの異なる環境にデプロイします。

• 本番環境: ユーザーがアクセスする公開サイト。
• カナリア環境: 少量のユーザー トラフィックが振り向けられる、キャパシティの小さいサイト。この環境は、ソフトウェアをすべてのユーザーにリリースする前に、ライブ トラフィックを使って検証する場合に使用します。

1. Google Cloud Shell で、サンプル アプリケーションのディレクトリに移動します。

cd sample-app

2. Kubernetes Namespace を作成して、デプロイする環境を論理的に隔離します。

kubectl create ns production

3. kubectl apply コマンドを使用して、本番デプロイメント、カナリア デプロイメント、サービスを作成します。

kubectl apply -f k8s/production -n production kubectl apply -f k8s/canary -n production kubectl apply -f k8s/services -n production

完了したタスクをテストする

[進行状況を確認] をクリックして、実行したタスクを確認します。デプロイメントが正常に作成されている場合は、評価スコアが表示されます。

本番デプロイメントとカナリア デプロイメントを作成する

デフォルトでは、フロントエンドのレプリカが 1 つだけデプロイされます。kubectl scale コマンドを使用して、少なくとも 4 つのレプリカが常時実行されるようにします。

4. 次のコマンドを実行して、本番環境のフロントエンドをスケールアップします。

kubectl scale deployment gceme-frontend-production -n production --replicas 4

5. フロントエンド用に 5 つの Pod、本番トラフィック用に 4 つの Pod、カナリア リリース用に 1 つの Pod が実行されていることを確認します（カナリア リリースへの変更は 5 人中 1 人（20%）のユーザーにのみ影響します）。

kubectl get pods -n production -l app=gceme -l role=frontend

6. また、バックエンド用に 2 つの Pod（1 つは本番用、もう 1 つはカナリア用）があることも確認してください。

kubectl get pods -n production -l app=gceme -l role=backend

7. 本番環境サービスの外部 IP を取得します。

kubectl get service gceme-frontend -n production 注: ロードバランサの外部 IP アドレスが表示されるまでに数分かかる場合があります。

出力例:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE gceme-frontend LoadBalancer 10.79.241.131 104.196.110.46 80/TCP 5h

外部 IP をブラウザに貼り付けると、以下のような情報カードが表示されます。

8. 次に、環境変数にフロントエンド サービスのロードバランサの IP を保存して、後で使用できるようにします。

export FRONTEND_SERVICE_IP=$(kubectl get -o jsonpath="{.status.loadBalancer.ingress[0].ip}" --namespace=production services gceme-frontend)

9. ブラウザでフロントエンドの外部 IP アドレスを開き、両方のサービスが正常に動作していることを確認します。

10. 次のコマンドを実行して、サービスのバージョンを確認します（1.0.0 と表示されるはずです）。

curl http://$FRONTEND_SERVICE_IP/version

これで、サンプル アプリケーションが正常にデプロイされました。次は、継続的かつ確実に変更をデプロイするためのパイプラインを設定します。

タスク 8. Jenkins パイプラインを作成する

サンプルアプリのソースコードをホストするリポジトリを作成する

1. gceme サンプルアプリのコピーを作成して、Cloud Source Repositories に push します。

gcloud source repos create default

表示される警告は無視してください。このリポジトリの使用料を請求されることはありません。

完了したタスクをテストする

[進行状況を確認] をクリックして、実行したタスクを確認します。ソース リポジトリが正常に作成されている場合は、評価スコアが表示されます。

リポジトリを作成する git init

2. sample-app ディレクトリを独自の Git リポジトリとして初期化します。

git config credential.helper gcloud.sh

3. 次のコマンドを実行します。

git remote add origin https://source.developers.google.com/p/$DEVSHELL_PROJECT_ID/r/default

4. Git commit にユーザー名とメールアドレスを設定します。[EMAIL_ADDRESS] を Git メールアドレスに置き換え、[USERNAME] を Git ユーザー名に置き換えてください。

git config --global user.email "[EMAIL_ADDRESS]" git config --global user.name "[USERNAME]"

5. ファイルの追加、commit、push を行います。

git add . git commit -m "Initial commit" git push origin master

サービス アカウントの認証情報を追加する

Jenkins がコード リポジトリにアクセスできるように認証情報を構成します。Jenkins はクラスタのサービス アカウント認証情報を使用して、Cloud Source Repositories からコードをダウンロードします。

1. Jenkins のユーザー インターフェースで、左側のナビゲーションにある [Manage Jenkins（Jenkins の管理）] をクリックし、[Security（セキュリティ）] > [Credentials（認証情報）] をクリックします。

2. [System（システム）] をクリックします。

3. [Global credentials (unrestricted)（グローバル認証情報（制限なし））] をクリックします。

4. 右上にある [Add Credentials（認証情報を追加）] をクリックします。

5. [Kind（種類）] プルダウンから [Google Service Account from metadata（メタデータからの Google サービス アカウント）] を選択し、[OK] をクリックします。

これでグローバル認証情報が追加されました。認証情報の名前は、ラボの [接続の詳細] セクションにあるご自分のプロジェクト ID です。

Kubernetes 用に Jenkins Cloud を構成する

1. Jenkins のユーザー インターフェースで、[Manage Jenkins（Jenkins の管理）] > [Nodes（ノード）] を選択します。
2. 左側のナビゲーション パネルで [Clouds（クラウド）] をクリックします。
3. [New cloud（新規クラウド）] をクリックします。
4. [Cloud name（クラウド名）] に任意の名前を入力してから [Type（タイプ）] に [Kubernetes] を指定します。
5. [Create（作成）] をクリックします。
6. [Kubernetes Cloud Details（Kubernetes クラウドの詳細）] をクリックします。
7. [Jenkins URL] フィールドに、次の値を入力します。http://cd-jenkins:8080
8. [Jenkins tunnel（Jenkins トンネル）] フィールドに、次の値を入力します。cd-jenkins-agent:50000
9. [Save（保存）] をクリックします。

Jenkins ジョブを作成する

Jenkins のユーザー インターフェースに移動し、次の手順でパイプライン ジョブを構成します。

1. 左側のパネルで [Dashboard（ダッシュボード）] > [New Item（新しいアイテム）] をクリックします。

2. プロジェクトに「sample-app」という名前を付けて [Multibranch Pipeline（マルチブランチ パイプライン）] オプションを選択し、[OK] をクリックします。

3. 次のページの [Branch Sources（ブランチソース）] のセクションで、[Add Source（ソースの追加）] プルダウンから [Git] を選択します。

4. Cloud Source Repositories 内にある sample-app リポジトリの HTTPS クローン URL を [Project Repository（プロジェクト リポジトリ）] 欄に貼り付けます。[PROJECT-ID] は実際のプロジェクト ID に置き換えてください。

https://source.developers.google.com/p/[PROJECT_ID]/r/default

5. [Credentials（認証情報）] プルダウンで、前の手順でサービス アカウントを追加する際に作成した認証情報の名前を選択します。

6. [Scan Multibranch Pipeline Triggers（スキャン マルチブランチ パイプライン トリガー）] の [Periodically if not otherwise run（実行されない場合は定期的に実行）] をオンにして、[Interval（間隔）] の値を [1 minute（1 分）] に設定します。

7. ジョブの構成は次のようになります。

8. 他の項目はすべてデフォルトのままにして [Save（保存）] をクリックします。

以上の手順が完了すると、Branch indexing という名前のジョブが実行されます。このメタジョブはリポジトリのブランチを認識し、既存のブランチで変更が行われていないことを確認します。左上の sample-app をクリックすると、master ジョブが表示されます。

注: 次の手順でコードを変更しないと、マスタージョブの初回実行は失敗します。

これで、Jenkins パイプラインの作成が完了しました。次に、継続的インテグレーションのための開発環境を作成します。

タスク 9. 開発環境を作成する

開発ブランチは、デベロッパーがコードの変更を公開サイトに統合する前にテストを行うための一連の環境です。これは実際の環境をスケールダウンしたものですが、ライブ環境と同じ方法でデプロイする必要があります。

開発ブランチを作成する

機能ブランチから開発環境を作成する場合は、ブランチを Git サーバーに push して、Jenkins で環境をデプロイできます。

• 開発ブランチを作成して、Git サーバーに push します。

git checkout -b new-feature

パイプラインの定義を変更する

パイプラインを定義する Jenkinsfile は Jenkins Pipeline Groovy 構文で記述されます。Jenkinsfile を使用すると、ビルド パイプライン全体を 1 つのファイルで表し、ソースコードと一緒に公開できます。パイプラインは並列化などの強力な機能をサポートしていますが、ユーザーによる承認が必要です。

パイプラインを想定どおりに機能させるには、Jenkinsfile ファイルを編集してプロジェクト ID を設定する必要があります。

1. vi などのターミナル エディタで Jenkinsfile を開きます。

vi Jenkinsfile

2. エディタを開きます。

i

3. REPLACE_WITH_YOUR_PROJECT_ID 値を実際の PROJECT_ID に置き換えます（PROJECT_ID は、ラボの [接続の詳細] セクションにあるご自分のプロジェクト ID です。また、gcloud config get-value project を実行して確認することもできます）。

4. CLUSTER_ZONE の値を に変更します。この値を取得するには、gcloud config get compute/zone を実行します。

PROJECT = "REPLACE_WITH_YOUR_PROJECT_ID" APP_NAME = "gceme" FE_SVC_NAME = "${APP_NAME}-frontend" CLUSTER = "jenkins-cd" CLUSTER_ZONE = "{{{project_0.default_zone}}}" IMAGE_TAG = "gcr.io/${PROJECT}/${APP_NAME}:${env.BRANCH_NAME}.${env.BUILD_NUMBER}" JENKINS_CRED = "${PROJECT}"

5. Jenkinsfile ファイルを保存します（vi では Esc キーを押し、以下のコマンドを入力します）。

:wq

サイトを変更する

アプリケーションの変更を演習するために、gceme カードを青からオレンジに変更します。

1. html.go: を開きます。

vi html.go

2. エディタを開きます。

i

3. 次のように <div class="card blue"> の 2 つのインスタンスを変更します。

<div class="card orange">

4. html.go ファイルを保存します（Esc キーを押し、以下のコマンドを入力します）。

:wq

5. main.go: を開きます。

vi main.go

6. エディタを開きます。

i

7. バージョンが次の行で定義されています。

const version string = "1.0.0"

以下のように更新します。

const version string = "2.0.0"

8. main.go ファイルをもう一度保存します（Esc キーを押し、以下のコマンドを入力します）。

:wq

タスク 10. デプロイを開始する

1. 変更を commit して push します。

git add Jenkinsfile html.go main.go git commit -m "Version 2.0.0" git push origin new-feature

これにより、開発環境のビルドが開始されます。

変更が Git リポジトリに push されたら、Jenkins のユーザー インターフェースに移動し、new-feature ブランチのビルドが開始されていることを確認します。変更が反映されるまでに最長で 1 分ほどかかります。

2. ビルドの実行後、左側のナビゲーションのビルドの横にある下矢印をクリックして、[Console Output（コンソール出力）] を選択します。

3. ビルドの出力を数分間観察し、「kubectl --namespace=new-feature apply...」メッセージを確認します。これで、new-feature ブランチがクラスタにデプロイされます。

注: 開発では、外部に接続しているロードバランサは使用しません。アプリケーションを保護するには、kubectl プロキシを使用します。プロキシは Kubernetes API で自らの認証を行い、ローカルマシンからのリクエストをクラスタ内のサービスにリダイレクトします。サービスがインターネットに公開されることはありません。

Build Executor に何も表示されなくても問題はありません。Jenkins ホームページ > sample-app に移動して、new-feature パイプラインが作成されていることを確認できます。

4. すべて完了したら、バックグラウンドでプロキシを開始します。

kubectl proxy &

5. プロキシが停止した場合は、Ctrl+C キーを押して終了します。localhost にリクエストを送信して kubectl プロキシからサービスに転送し、アプリケーションがアクセス可能であることを確認します。

curl \ http://localhost:8001/api/v1/namespaces/new-feature/services/gceme-frontend:80/proxy/version

現在実行中のバージョンである 2.0.0 が返されます。

次のようなエラーが表示された場合:

{ "kind": "Status", "apiVersion": "v1", "metadata": { }, "status": "Failure", "message": "no endpoints available for service \"gceme-frontend:80\"", "reason": "ServiceUnavailable", "code": 503

6. これは、frontend エンドポイントがまだ伝播していないことを意味します。少し待ってから再度 curl コマンドを試してください。以下の出力が表示されたら次に進みます。

2.0.0

これで、開発環境の設定が完了しました。次は、前のモジュールで学んだことを踏まえ、カナリア リリースをデプロイして新しい機能をテストします。

タスク 11. カナリア リリースをデプロイする

開発環境でアプリが最新のコードを実行することが確認できたので、今度はそのコードをカナリア環境にデプロイしてみましょう。

1. カナリア ブランチを作成して、Git サーバーに push します。

git checkout -b canary git push origin canary

2. カナリア パイプラインが開始されたことが Jenkins に表示されます。完了したら、サービス URL を確認して、一部のトラフィックが新しいバージョンで処理されていることを確かめます。リクエストが 5 つあればそのうち約 1 つ（順序は不規則）でバージョン 2.0.0 が返されます。

export FRONTEND_SERVICE_IP=$(kubectl get -o \ jsonpath="{.status.loadBalancer.ingress[0].ip}" --namespace=production services gceme-frontend) while true; do curl http://$FRONTEND_SERVICE_IP/version; sleep 1; done

3. 1.0.0 しか表示されない場合は、上記のコマンドをもう一度実行してください。適切に動作することを確認したら、Ctrl+C キーを押してコマンドを終了します。

これで、カナリア リリースのデプロイが完了しました。次は、新しいバージョンを本番環境にデプロイします。

タスク 12. 本番環境にデプロイする

カナリア リリースが成功し、お客様からも苦情が寄せられていないと想定して、本番環境へのデプロイを開始します。

1. カナリア ブランチを作成して、Git サーバーに push します。

git checkout master git merge canary git push origin master

マスター パイプラインが開始されたことが Jenkins に表示されます。

2. 完了したら（数分かかる場合があります）、サービス URL を確認して、すべてのトラフィックが新しいバージョン 2.0.0 で処理されていることを確かめます。

export FRONTEND_SERVICE_IP=$(kubectl get -o \ jsonpath="{.status.loadBalancer.ingress[0].ip}" --namespace=production services gceme-frontend) while true; do curl http://$FRONTEND_SERVICE_IP/version; sleep 1; done

3. 1.0.0 のインスタンスが表示される場合は、上記のコマンドを再度実行してください。このコマンドを停止するには、Ctrl+C キーを押します。

出力例:

gcpstaging9854_student@qwiklabs-gcp-df93aba9e6ea114a:~/continuous-deployment-on-kubernetes/sample-app$ while true; do curl http://$FRONTEND_SERVICE_IP/version; sleep 1; done 2.0.0 2.0.0 2.0.0 2.0.0 2.0.0 2.0.0 ^C

gceme アプリケーションの情報カードが表示されるサイトに移動することもできます。カードの色は青からオレンジに変わっています。

4. 外部 IP アドレスを取得する場合も、以下のコマンドを実行します。外部 IP を新規のタブに貼り付けると情報カードが表示されます。

kubectl get service gceme-frontend -n production

出力例:

タスク 13. 理解度を確認する

今回のラボで学習した内容の理解を深めていただけるよう、以下の選択式問題を用意しました。正解を目指して頑張ってください。

ラボを完了する

本番環境にアプリケーションが正常にデプロイされました。

お疲れさまでした

このハンズオンラボでは、Kubernetes Engine で Jenkins を使ってデプロイすることで、継続的デリバリー パイプラインと継続的デプロイ パイプラインを有効にしました。Kubernetes Engine に重要な DevOps ツールをデプロイし、本番環境用に構成することもできました。さらに、kubectl コマンドライン ツールを使用して YAML ファイルのデプロイ構成を処理し、開発プロセスとデプロイ プロセス用に Jenkins パイプラインを設定する方法について学びました。今後は、これらのツールを実際の DevOps 環境で自信を持って活用していただけるでしょう。

クエストを完了する

このセルフベース ラボは、「Kubernetes in Google Cloud」、「Cloud Architecture」、「DevOps Essentials」クエストの一部です。クエストとは学習プログラムを構成する一連のラボのことで、完了すると成果が認められて上のようなバッジが贈られます。バッジは公開して、オンライン レジュメやソーシャル メディア アカウントにリンクできます。このラボの修了後、このラボが含まれるクエストに登録すれば、すぐにクレジットを受け取ることができます。受講可能なすべてのクエストについては、Google Cloud Skills Boost カタログをご覧ください。

次のラボを受講する

Hello Node Kubernetes に進んでクエストを続けるか、以下の Google Cloud Skills Boost ラボをご確認ください。

• Kubernetes を使った Cloud のオーケストレーション
• Kubernetes Engine によるデプロイの管理

次のステップと詳細情報

• Kubernetes Engine での Jenkins ソリューションを参照する
• Jenkins を使用して Kubernetes Engine への継続的デプロイを有効にする方法を学ぶ
• Google Cloud ドキュメントの DevOps ソリューションと DevOps ガイドを参照する
• Jenkins コミュニティと交流する

Google Cloud トレーニングと認定資格

Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2023 年 9 月 20 日

ラボの最終テスト日: 2023 年 9 月 20 日

Copyright 2024 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。