arrow_back

Kubernetes Engine での Jenkins を使用した継続的デリバリー

参加 ログイン

Kubernetes Engine での Jenkins を使用した継続的デリバリー

1時間 15分 クレジット: 5

GSP051

Google Cloud セルフペース ラボ

概要

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

overview.png

Kubernetes で Jenkins を実行する方法について詳しくは、こちらをご覧ください。

演習内容

このラボでは、次のタスクを行います。

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

前提事項

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

準備ができたら下にスクロールして、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 のリソースを利用できる時間を示しています。

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

必要なもの

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

  • 標準的なインターネット ブラウザ(Chrome を推奨)
  • ラボを完了するために十分な時間

注: すでに個人の Google Cloud アカウントやプロジェクトをお持ちの場合でも、ラボでは使用しないでください。

注: Chrome OS デバイスを使用している場合は、シークレット ウィンドウを開いてこのラボを実行してください。

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

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

    • [Google コンソールを開く] ボタン
    • 残り時間
    • このラボで使用する必要がある一時的な認証情報
    • このラボを行うために必要なその他の情報(ある場合)
  2. [Google コンソールを開く] をクリックします。 ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。

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

    注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。
  3. 必要に応じて、[ラボの詳細] パネルから [ユーザー名] をコピーして [ログイン] ダイアログに貼り付けます。[次へ] をクリックします。

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

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

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

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

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

Google Cloud Shell の有効化

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

GCP Console の右上のツールバーにある [Cloud Shell をアクティブにする] ボタンをクリックします。

Cloud Shell アイコン

[続行] をクリックします。

cloudshell_continue

環境のプロビジョニングと接続には少し時間がかかります。接続すると、すでに認証されており、プロジェクトは PROJECT_ID に設定されています。例えば:

Cloud Shell 端末

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

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

gcloud auth list

出力:

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

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

gcloud config list project
	

出力:

[core]
project = <project_ID>
	

出力例:

[core]
project = qwiklabs-gcp-44776a13dea667a6
	

ソースコードをダウンロードする

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

gcloud config set compute/zone us-east1-d

ラボのサンプルコードのクローンを作成します。

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

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

cd continuous-deployment-on-kubernetes

Jenkins をプロビジョニングする

Kubernetes クラスタを作成する

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

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

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

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

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

Kubernetes クラスタを作成する(ゾーン: us-east1-d)

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

gcloud container clusters list

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

gcloud container clusters get-credentials jenkins-cd

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

kubectl cluster-info

Helm をセットアップする

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

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

helm repo add jenkins https://charts.jenkins.io
  1. リポジトリが最新であることを確認します。

helm repo update

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

Jenkins をインストールする場合、ファイルをテンプレートとして使用し、セットアップに必要な値を提供できます。

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

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

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

  1. カスタムファイルをダウンロードします。
gsutil cp gs://spls/gsp330/values.yaml jenkins/values.yaml
  1. Helm CLI を使用して、構成設定でチャートをデプロイします。
helm install cd jenkins/jenkins -f jenkins/values.yaml --wait

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

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

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

Jenkins を構成、インストールする
  1. コマンドが完了したら、Jenkins Pod が Running 状態になり、コンテナが READY 状態になっていることを確認します。

kubectl get pods

出力例:

NAME                          READY     STATUS    RESTARTS   AGE
cd-jenkins-7c786475dd-vbhg4   1/1       Running   0          1m
  1. クラスタにデプロイできるように Jenkins サービス アカウントを構成します。

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

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

clusterrolebinding.rbac.authorization.k8s.io/jenkins-deploy created
  1. 次のコマンドを実行して、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 &
  1. Jenkins サービスが適切に作成されたことを確認します。

kubectl get svc

出力例:

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

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

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

Jenkins に接続する

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

printf $(kubectl get secret cd-jenkins -o jsonpath="{.data.jenkins-admin-password}" | base64 --decode);echo
  1. Jenkins ユーザー インターフェースを表示するには、Cloud Shell で [ウェブでプレビュー] をクリックし、[ポート 8080 でプレビュー] をクリックします。

web_prev.png

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

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

アプリケーションについて理解する

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

90fb779a65809b9e.png

2 つのオペレーション モードに対応するこのアプリケーションは、マイクロサービスに似た機能を提供します。

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

fc22b68ab20dfe0e.png

アプリケーションをデプロイする

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

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

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

cd sample-app

Kubernetes 名前空間を作成して、デプロイする環境を論理的に隔離します。

kubectl create ns production

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 つのレプリカが常時実行されるようにします。

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

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

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

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

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

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

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

kubectl get service gceme-frontend -n production

出力例:

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

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

backend_card.png

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

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

ブラウザでフロントエンドの外部 IP アドレスを開き、両方のサービスが正常に動作していることを確認します。次のコマンドを実行して、サービスのバージョンを確認します(1.0.0 と表示されるはずです)。

curl http://$FRONTEND_SERVICE_IP/version

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

Jenkins パイプラインを作成する

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

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

gcloud source repos create default

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

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

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

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

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

git config credential.helper gcloud.sh

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

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

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

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

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

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

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

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

ステップ 1: Jenkins ユーザー インタフェースで、左側のナビゲーションにある [Manage Jenkins] をクリックしたあとで [Manage Credentials] をクリックします。

ステップ 2: [Jenkins] をクリックします。stored_scoped_cred.png

ステップ 3: [Global credentials (unrestricted)] をクリックします。

ステップ 4: 左側のナビゲーションで [Add Credentials] をクリックします。

ステップ 5: [Kind] ドロップダウン メニューから [Google Service Account from metadata] を選択し、[OK] をクリックします。

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

global_cred.png

Jenkins ジョブを作成する

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

ステップ 1: 左側のナビゲーションで [New Item] をクリックします。

86e92964a4599231.png

ステップ 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] に設定します。

ステップ 7: ジョブの構成は次のようになります。

branch_source_jenkins.png

build_conf_jenkins.png

ステップ 8: 他の設定はすべてデフォルトのままにして [Save] をクリックします。

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

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

開発環境を作成する

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

開発ブランチを作成する

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

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

git checkout -b new-feature

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

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

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

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

vi Jenkinsfile

エディタを起動します。

i

REPLACE_WITH_YOUR_PROJECT_ID 値を実際の PROJECT_ID に置き換えます(PROJECT_ID はご自分の プロジェクト ID で、ラボの「接続の詳細」に表示されます。gcloud config get-value project を実行して確認することもできます)。

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

Jenkinsfile ファイルを保存します(vi では Esc キーを押して以下を実行します)。

:wq

サイトを変更する

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

html.go: を開きます。

vi html.go

エディタを起動します。

i

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

<div class="card orange">

html.go ファイルを保存します(Esc キーを押して以下を実行します)。

:wq

main.go: を開きます。

vi main.go

エディタを起動します。

i

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

const version string = "1.0.0"

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

const version string = "2.0.0"

main.go ファイルをもう一度保存します(Esc キーを押して以下を実行します)。

:wq

デプロイを開始する

変更を 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 分ほどかかります。

ビルドの実行後、左側のナビゲーションのビルドの横にある下矢印をクリックして、[Console output] を選択します。

6ea3b2ed776e3b29.png

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

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

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

kubectl proxy &

プロキシが停止した場合は、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

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

2.0.0

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

カナリア リリースをデプロイする

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

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

git checkout -b canary
git push origin canary

カナリア パイプラインが開始されたことが 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

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

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

本番環境にデプロイする

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

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

git checkout master
git merge canary
git push origin master

マスター パイプラインが開始されたことが Jenkins に表示されます。完了したら(数分かかる場合があります)、サービス 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

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 アプリケーションの情報カードが表示されるサイトに移動することもできます。カードの色は青からオレンジに変わっています。外部 IP アドレスを再度取得して確認する場合は、次のコマンドを実行します。

kubectl get service gceme-frontend -n production

出力例:

orange_card.png

理解度を確認する

以下の問題に取り組み、今回のラボで学習した内容の理解を深めましょう。正解を目指して頑張ってください。

ラボを完了する

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

お疲れさまでした

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

クエストを完了する

6d0798e24a18671b.png Cloud_Architecture.png

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

次のラボを受講する

Hello Node Kubernetes に進んでクエストを続けるか、以下のおすすめをご確認ください。

次のステップと詳細情報

Google Cloud Training & Certification

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

マニュアルの最終更新日: 2022 年 1 月 27 日
ラボの最終テスト日: 2022 年 1 月 27 日

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