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

Kubernetes クラスタを作成し、Jenkins が Google Cloud サービスと Google Artifact Registry にアクセスできるようにします。

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 は Google Cloud サービスと Google Artifact Registry にアクセスできるようになります。

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 は Google Cloud サービスと Google Artifact Registry にアクセスできるようになります。

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

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

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

gcloud container clusters list

クラスタの認証情報を取得する

1. クラスタの認証情報を取得します。

gcloud container clusters get-credentials jenkins-cd

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

kubectl cluster-info

タスク 3. Helm を設定する

Helm は、Kubernetes アプリケーションの構成とデプロイを容易にするパッケージ管理システムです。Jenkins をインストールしたら、CI / CD パイプラインを設定できます。

このタスクでは、Helm を使用してチャート リポジトリから Jenkins をインストールします。

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

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 がクラスタと Google Cloud プロジェクトに接続できるようになります。

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

Kubernetes プラグインにより、Jenkins マスターからのリクエストに応じてビルダーノードが自動的に起動されます。処理が完了すると、ビルダーノードは自動的に終了し、リソースがクラスタのリソースプールに戻されます。

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

タスク 5. Jenkins に接続する

管理者パスワードを取得して、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 つのオペレーション モードに対応します。

• バックエンド モードでは、ポート 8080 をリッスンし、Compute Engine インスタンスのメタデータを JSON 形式で返します。
• フロントエンド モードでは、バックエンド 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 つ、カナリア リリース用が 1 つです（カナリア リリースへの変更は、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 パイプラインを作成する

このタスクでは、専用の Git サーバー上に Git リポジトリを設定し、Jenkins パイプラインを作成します。

• サンプル アプリケーションのソースコードを Git サーバーに push する
• サービス アカウントの認証情報を Jenkins に追加する
• Kubernetes 用に Jenkins Cloud を構成する
• Jenkins のマルチブランチ パイプライン ジョブを作成する

サンプル アプリのソースコードを Git サーバーに push する

1. Cloud Shell で、Git サーバーの外部 IP アドレスを取得します。

export GIT_SERVER_IP=$(gcloud compute instances describe git-server --zone={{{project_0.default_zone}}} --format='get(networkInterfaces[0].accessConfigs[0].natIP)') echo "Git Server IP: ${GIT_SERVER_IP}"

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

cd ~/continuous-deployment-on-kubernetes/sample-app git init git config --global user.email "student@qwiklabs.net" git config --global user.name "Student" git branch -m master

3. セルフホスト型 Git サーバーを指すリモート リポジトリを追加します。

git remote add origin http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/sample-app.git

4. ファイルを追加、commit して master ブランチに push します。

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

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

Jenkins がクラスタにアクセスしてリソースをデプロイできるように認証情報を構成します。

1. Jenkins ユーザー インターフェースの左側のパネルで [Manage Jenkins] をクリックし、[Security] の下の [Credentials] をクリックします。

2. [Stores scoped to Jenkins] で [System] をクリックします。

3. [Global credentials (unrestricted)] をクリックします。

4. [Add Credentials] をクリックします。

5. [Kind] で [Google Service Account from metadata] を選択して [Next] をクリックします。

6. [ID] フィールドにプロジェクト ID（）を入力し、[Create] をクリックします。

注: プロジェクト ID は、ラボの [接続の詳細] パネルに記載されています。

グローバル認証情報が追加されました。

Kubernetes 用に Jenkins Cloud を構成する

1. Jenkins ユーザー インターフェースで、[Manage Jenkins] > [Clouds]（または [System] > [Clouds]）を選択します。
2. [New cloud] をクリックします。
3. [Cloud name] に「kubernetes」と入力し、[Type] で [Kubernetes] を選択して [Create] をクリックします。
4. [Jenkins URL] フィールドに「http://cd-jenkins:8080」と入力します。
5. [Jenkins tunnel] フィールドに「cd-jenkins-agent:50000」と入力します。
6. [Save] をクリックします。

Jenkins ジョブを作成する

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

1. 左側のパネルで [Jenkins] > [New Item] をクリックします。

2. 項目名に「sample-app」と入力し、[Multibranch Pipeline] オプションを選択して [OK] をクリックします。

3. 次のページの [Branch Sources] セクションで、[Add source] プルダウンから [Git] を選択します。

4. [Project Repository] フィールドにリポジトリのクローン URL を入力します。

http://{{{project_0.startup_script.git_server_ip}}}:3000/giteaadmin/sample-app.git 注: 変数が入力されていない場合は、[GIT_SERVER_IP] を Git サーバーの IP に置き換えて http://[GIT_SERVER_IP]:3000/giteaadmin/sample-app.git と入力します。

5. [Credentials] は [- none -] のままにします。

6. [Scan Multibranch Pipeline Triggers] セクションで、[Periodically if not otherwise run] チェックボックスをオンにし、[Interval] の値を [1 minute] に設定します。

7. 他のオプションはすべてデフォルト値のままにして、[Save] をクリックします。

これらの手順を完了すると、Branch indexing というジョブが実行されます。このメタジョブは、リポジトリ内のブランチを特定し、既存のブランチに変更が発生していないことを確認します。ナビゲーションで [sample-app] をクリックすると、master ジョブが表示されます。

注: 次のステップでコードをいくつか変更するまで、master ジョブの初回実行は失敗する可能性があります。

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

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

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

開発ブランチを作成する

機能ブランチから開発環境を作成する場合は、ブランチを Git サーバーに push すると、Jenkins によって環境がデプロイされます。

注: Cloud Shell でエラーが表示された場合は、CTRL+C キーを押して、次のコマンドを実行してください。

• 開発ブランチを作成して、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. 2 か所にある <div class="card blue"> を次のように変更します。

<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

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

[進行状況を確認] をクリックして、実行したタスクを確認します。new-feature ブランチのビルドが正常に開始された場合は、評価スコアが表示されます。

new-feature ブランチをビルドする

タスク 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 Engine での Jenkins ソリューションについてさらに詳しく学ぶ
• Jenkins を使用して Kubernetes Engine への継続的デリバリーを可能にする方法を学ぶ
• Google Cloud ドキュメントの DevOps ソリューションと DevOps ガイドを確認する
• Jenkins コミュニティと交流する

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

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

マニュアルの最終更新日: 2026 年 5 月 20 日

ラボの最終テスト日: 2026 年 2 月 26 日

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