Dec 18, 2018

はじめてみよう〜DevOps編〜

● GCP アカウントをまだ作成されてない方は、下記リンクの p12 からの手順を参考に、GCP アカウントを作成ください。

http://goo.gl/ua5fQw

● クーポンコードを有効にするためには、GCP アカウントを無料トライアルから有料アカウントへアップグレードする必要があります。

● アカウントをアップグレードすると、クレジットを使い切った時点、またはクレジットが期限切れになった時点で自動的に請求されます。

はじめるまえに

本日のアジェンダ

1. Google が考える DevOps

2. ハンズオン準備編

3. GKE 入門編

4. トラブルシュート編

5. ビルド・デプロイ自動化編

6. (Optional) 高度なデプロイ編

7. Clean up 編

01Google が考えるDevOps

製品ライフサイクル

コンセプト ビジネス 開発 運用 一般公開

製品ライフサイクル

コンセプト ビジネス 開発 運用 一般公開

アジャイル DevOps

DevOps における２つの観点

文化: 開発と運用を高速に繰り返し行うための組織や考え方

技術: DevOps 文化を支えるための技術やツール

本日はこちらを中心に

DevOps における技術要件の変化

1. 手動から自動化へ

a. オペレーション数削減

b. 再現性の向上

2. 自動化からアーキテクチャ最適化へ

a. オペレーションしやすいアーキテクチャへの変更

DevOps を支える技術

1. マイクロサービスアーキテクチャ

2. コンテナとオーケストレーション

3. CI / CD

4. 高度な監視（フィードバックループの実現)

マイクロサービスアーキテクチャとは？従来のモノリシック(一枚岩)なアプリケーションとは異なり、

役割や責務ごとに機能を小さなサービスに分割し、それらのサービスが

一つのシステムとして動作する状態を目指したアーキテクチャ。

モノリシック マイクロサービス

User/AuthProductPayment

User/Auth

Product

Payment

マイクロサービスアーキテクチャのメリット

● ビルド・デプロイプロセスがサービス単位でシンプルに

● コードベースが小さく、エンジニアの初期学習コスト低

● サービス間が疎結合になっているので新たな技術を導入しやすい

DevOps 的に開発と運用を高速に繰り返すには最適なアーキテクチャ

コンテナとは？

コンテナはアプリケーションコードとその依存性を一

つのユニットとしてまとめる

これにより、アプリケーションとインフラを疎結合にする

ことができる

• コンテナはアプリケーションとその依存性がまとまっているので、例え

ば、開発環境、テスト環境、本番環境をまたいだデプロイが容易にな

る

• オンプレミス、プライベートクラウド、パブリッククラウド等ことなる実行

環境間の移動が容易になる

コンテナ イメージ

依存性

アプリケーション コード

VM vs コンテナ

VM

コンテナ

DevOps とも親和性が高いコンテナ

軽量仮想マシンに比べて

軽量でシンプル。数十ミリ秒で起動

ポータブル様々な実行環境に対応し、

デプロイメントが容易

効率性リソース使用量が少なく、コンピュートリソースを細分化して効率的に利用可能

コンテナ管理の課題

Cluster

● 複数のノードに対するコンテナのデプロイは？

● ノード障害が発生した場合は？

● コンテナ障害が発生した場合は？

● アプリケーションのアップグレードはどうやって管理する？

Node NodeNode

???

コンテナ コンテナ コンテナ コンテナコンテナコンテナ

Kubernetes(k8s)

OSS のコンテナオーケストレーションシステム

Google 内部で使われている Borg をインスパイア

オンプレでもクラウドでも運用可能

kubernetesの特徴

● 複数のコンテナに対する管理機構

● manifest による宣言的な定義/管理

● オートスケール

● ローリングアップデート・自己修復

Google Kubernetes Engine (a.k.a GKE)

● GCP 上で動作する kubernetes のマネージドサービス

● マスターノードの管理は全て Google が行う

● 自動アップグレード

● GCP の各種サービスとのインテグレーション

CI / CD とは？

継続的インテグレーション（ CI: Continuous Integration）一日に何度もビルドを実行し、ソフトウェアをインテグレーションした時に発生する様々な問題を早期に検出する。フィードバッ

クループを短くし、ソフトウェア開発の品質と生産性を向上させる

継続的デリバリー（CD: Continuous Delivery）ソフトウェア全体のライフサイクルを通じて、常に本番環境にリリースできる状態を保つ

リリースまでの期間を短縮することで、フィードバックループを短くできる

Trunk, Releasebranch/tag

git flow

CD

CILocal env, Feature

branch/PR

deploy to test envint teststrigger build +

unit test

artifact registry

bake/package sys tests deploy to

qa/staging/prodtriggerint teststrigger build + unit test

引用: [改訂第3版]Jenkins実践入門

GCP で CI / CD

ソースコード ビルド＆テスト ストレージ デプロイ

1 2 3 4 5

モニタリング

Container RegistryCloud BuildSource

Repository

Cloud Storage

Cloud Build Stackdriver

← フィードバックループ

Cloud Build

サーバーレスな CI/CD プラットフォーム

お客様が VM を用意したりキャパシティの管理をする必要はない

柔軟なビルドステップ

あらゆるサーバーレス CLI ツールをビルドステップとして

組み込むことが可能

デベロッパーフレンドリー

開発者が使い慣れた Git のイベントに応じたトリガー

Spinnaker との連携

GKE 環境での B/G デプロイ、カナリーリリースへの対応

Cloud Build によるワークフロー

workspace

git pushPull request

Trigger

Container Registry

Cloud Storage

Cloud Functions Firebase

KubernetesEngine

App Engine

go docker gcloud kubectl

ビルダーイメージ

Stackdriver

サーバーレスの統合監視プラットフォーム

Monitoring や Logging、APM など豊富な機能を一括で提供

高度な故障分析機能

アプリケーション動作環境にまで踏み込んだデバッグや

サービス間のトレーシング

マイクロサービス間の可視化を容易に

Isitoとの連携によりマイクロサービス間を可視化

Stackdriverの主な機能

Monitoring

Logging

Debug Trace

Error Reporting Profiler

ステージング環境

本番環境開発環境

ハンズオンのシステム構成

Cloud Shell Profiler Trace Logging

Kubernetes Engine

Cloud Source Repositories

Container RegistryCloud Build

commit, push

trigger register

deploy hook

Get container

Send telemetry

deploy hooknew imagedetect

02ハンズオン準備編

● Cloud Build API● Cloud Source Repositories API● Cloud Container Registry API● Resource Manager API● Kubernetes Engine API● Stackdriver Trace API● Stackdriver Profiler API● Stackdriver Logging API

ハンズオンで利用する API を有効化する

[APIとサービス ] > [ライブラリ] から、サーチボックスで以下のサービスを検索の上、有効化

1. [IAMと管理] > [サービスアカウント ] から [サービスアカウントを作成 ] をクリック

2. dohandson というIAMユーザーを作成し、project の編集者 アクセス権を付与する .

IAM の設定を行う

2. [キーを作成]をクリックし、キーのタイプを

JSONにし[作成]をクリックする。

するとdohandson ユーザーの認証情報

(Credential)がPCにダウンロードされる。

サービスアカウント作成ページ、一番下の [完了]をクリックする。

IAMの設定を行う

3. [IAMと管理] > [IAM] から先程作成した

”dohanson@****.iam.gserviceaccount.com”の画面右端に表示されている鉛筆ボタンから Source Repository 読み取り と Kubernetes Engine 管理者 の権限に付与し [保存]をクリックする。

IAMの設定を行う

画面右上のCloud Shell起動ボタンをクリック。

PCにダウンロードした認証情報 ( dohandsonユーザーの認証情報 ) をCloud Shellに転送する

IAM 認証情報を Cloud Shell に転送する

ハンズオン用アプリの動作確認

$ go get -u cloud.google.com/go/cmd/go-cloud-debug-agent github.com/astaxie/beego github.com/astaxie/beego/context github.com/beego/bee go.opencensus.io/trace contrib.go.opencensus.io/exporter/stackdriver cloud.google.com/go/profiler github.com/sirupsen/logrus

$ cp <project-name>-xxxxxx.json gopath/src/devops-handson/gcp-credentials/auth.json

$ curl https://storage.googleapis.com/devops-handson/devops-handson.zip -O$ unzip devops-handson.zip -d gopath/src/

1. 必要パッケージをCloud Shell環境にインストール

2. ハンズオン用アプリのダウンロードと展開

3. 先程作成したサービスアカウントのクレデンシャルをコピーしてハンズオン用アプリに配置

ハンズオン用アプリの動作確認を Cloud Shell上で行います。

＃赤字のところはそれぞれの環境のファイル名に置き換えてください。

ハンズオン用アプリの動作確認

$ cd gopath/src/devops-handson/$ vim conf/app.conf # gcpprojectの値を自身の環境に合わせて変更する$ vim gke-config/deployment.yaml # ProjectID (samuraitaiga-demo) の値を自身の環境に合わせて変更する

6. 以下のURLにアクセスできることを確認する● /● /bench1

5. ハンズオン用アプリの起動、 localのTCP8080で上がるのでCloud Shellの以下メニューからアクセス

4. 先ハンズオン用アプリに配置の設定ファイルの修正

$ GOOGLE_APPLICATION_CREDENTIALS=./gcp-credentials/auth.json go run main.go

7. 確認後、CTRL + Cで終了

03GKE入門編

● コンテナの作成

● レジストリへの登録

● GKEへのデプロイ

この章で行うこと

ステージング環境

本番環境開発環境

Cloud Shell Profiler Trace Logging

Kubernetes Engine

Container Registry

1. コンテナビルド

コンテナ取得

Send telemetry

2. コンテナ登録3. デプロイコマンド実行

クラスタ作成

$ gcloud container --project "$GOOGLE_CLOUD_PROJECT" clusters create "k8s-devops-handson" \--zone "asia-northeast1-c" \--enable-autoupgrade \--enable-autorepair \--username "admin" \--cluster-version "1.11.4-gke.8" \--machine-type "n1-standard-1" \--image-type "COS" \--disk-type "pd-standard" \--disk-size "100" \--scopes "https://www.googleapis.com/auth/cloud-platform" \--num-nodes "3" \--enable-cloud-logging --enable-cloud-monitoring \--enable-ip-alias \--network "projects/$GOOGLE_CLOUD_PROJECT/global/networks/default" \--subnetwork "projects/$GOOGLE_CLOUD_PROJECT/regions/asia-northeast1/subnetworks/default" \--addons HorizontalPodAutoscaling,HttpLoadBalancing

1. GKEクラスターを作成する。手動で作成する場合は以下 2点を設定すること● Allow full access to all Cloud APIs● Enable VPC-native (using alias IP)

クラスタの認証情報取得

$ gcloud container clusters get-credentials k8s-devops-handson --zone asia-northeast1-c --project $GOOGLE_CLOUD_PROJECT

1. GKE クラスター作成後、当該クラスターから認証情報を取得する。作成後、数分を置いて実施すること。

コンテナの作成

$ cd ~/gopath/src/devops-handson$ docker build -t gcr.io/$GOOGLE_CLOUD_PROJECT/devops-handson:v1 .$ docker push gcr.io/$GOOGLE_CLOUD_PROJECT/devops-handson:v1

以下コマンドを実行し、コンテナの作成とコンテナレジストリへの登録を行う

コンテナのデプロイ

$ cd ~/gopath/src/devops-handson$ kubectl create -f gke-config/deployment.yaml

以下コマンドを実行し、コンテナレジストリへ登録されているコンテナを GKEへデプロイする

デプロイに関する設定ファイルの説明

apiVersion: extensions/v1beta1kind: Deploymentmetadata: name: devops-hands on-deploymentspec: replicas: 2 template: metadata: labels: app: devops-handson spec: containers: - name: myapp image: gcr.io/samuraitaiga-demo/devops-handson:v1 ports: - containerPort: 8080

---apiVersion: v1kind: Servicemetadata: name: devops-handsonspec: type: NodePort selector: app: devops-handson ports: - name: myapp port: 8080 targetPort: 8080

---apiVersion: extensions/v1beta1kind: Ingressmetadata: name: devops-handson-ingressspec: backend: serviceName: devops-handson servicePort: 8080

接続確認

$ kubectl get ingressNAME HOSTS ADDRESS PORTS AGEdevops-handson-ingress * xx.xxx.xx.xxx 80 1d

2. ブラウザでコマンドで確認したアドレスにアクセスし、画面が表示できることを確認する。アクセスできるまで5 - 10分ほど掛かる。

1. こちらのコマンドで ingressのIPアドレスを取得する、 IPアドレスの表示まで少し時間が掛かるときがあるので、その際は再度コマンドを実行する。

プログラムの修正とデプロイ

1. プログラムに変更を加え、 Cloud Shell上で動作確認を行う。

2. v2というタグでコンテナを再作成し、 Container RegistryへPushする。

3. GKEにコンテナをデプロイし、想定通り動作することを確認する。

演習

views/index.tpl に以下変更を加える事が簡単でおすすめ

変更前 : <h1 class="header center orange-text">{{.WebsiteTitle}}</h1>変更後 : <h1 class="header center orange-text">{{.WebsiteTitle}} v2 </h1>

ヒント

すでにGKEに上にデプロイ済みコンテナに変更を行う際に使うコマンド

$ kubectl apply -f xxxx.yaml

もしくは

$ kubectl set image deployment/xxxxx \ myapp=gcr.io/$GOOGLE_CLOUD_PROJECT/xxxxxxxx:v2

演習

● Dockerコマンドを使い、コンテナのビルド・レジストリへの登録を行うことができる

○ レジストリへの登録時はタグを設定し、タグを利用したデプロイを行うことが望ましい

● GKEへのデプロイはkubectlを利用して行うことができる

○ 構成ファイル(yaml)を利用したデプロイ、コマンドによるデプロイ、両方実施可能。環境や組織、

チームにとって最適なやり方を選択することが重要

ここまでのまとめ

04トラブルシュート編

● Stackdriver Trace, Profiler, Loggingを使ったサービスの管理・分析方法

この章で行うこと

ステージング環境

本番環境開発環境

Cloud Shell Profiler Trace Logging

Kubernetes Engine

Container Registry

1. コンテナビルド

コンテナ取得

Send telemetry

2. コンテナ登録3. デプロイコマンド実行

プロダクトの関連、データフロー

Go App(Container)

GCLB(Ingress)

リクエスト転送HTTP Header (X-Cloud-Trace-Context :

traceid/spanid )

Profiler

Trace

Logging

APIプロファイル情報

Kubernetes Engine

STDOUT{“logging.googleapis.com/trace” :

“traceid”, … }

APIトレース情報 ( traceid, spanid )

APIログ情報

Traceid, spanidで情報を紐づけ

Go App(Container)

RPC, gRPCHTTP Header (X-Cloud-Trace-Context :

traceid/spanid )

トラブルがあるページの確認

1. Chrome DevTools を開くa. Chrome メニューから [More Tools] >

[Developer Tools] を選択します。b. ページ要素を右クリックして、[Inspect] を

選択します。c. キーボード ショートカットの Ctrl+Shift+I

キー（Windows）または Cmd+Opt+I キー（Mac）を使用します。

d. [Network]タブを選択します。

2. ブラウザで http://<INGRESS-IP>/bench1 にアクセスし、画面表示にかかる時間を確認する。

ページの読み込みが遅い。。。

ブラウザがChromeではない方は、実際にページを開いてみてどのくらい遅いか確認してください

トラブルのあるページの確認

後のステップで確認する Stackdriver Profilerのサンプル数を稼ぐため、

Apache Benchを使い複数回、 /bench1へのアクセスを行う。

Timeoutエラーが出た場合は -tの値を増やしてみてください。 (Timeout値)

$ sudo apt-get install apache2-utils$ ab -n 30 -c 5 -t 60 http://[INGRESS_IP]/bench1

Stackdriver Traceで確認

1. トレース -> トレースリストを

開き、リクエスト フィルタに /bench1 を入力する。

2. リクエストが遅い Span を確

認する。

3. ログを表示をクリック

4. “I” と表示されるアイコンをク

リックして、連携された

Stackdriver loggingのログ

を確認する

Stackdriver Loggingでログを確認する

Traceのページで /bench1 のトレースを表示し、Logの横に表示されている View リンクをクリックする。

Stackdriver Profilerでの確認

[ プロファイラ ] を開き、どこの処理にリソースが使われているか確認する。

閲覧時は、ゾーンに “asia-northeast1-c”、バージョンに “1.0.0” を設定する。

プログラムの確認と修正

● ~/gopath/src/devops-handson/routers/router.go (初期化処理)● ~/gopath/src/devops-handson/controllers/default.go (HTTPリクエストの処理 )

● Stackdriver Trace Overview● Stackdriver Profiler - Profiling Go code● GKE Logging Best Practices● Stackdriver Loggingへのインプットフォーマット

ヒント：● Stackdriver Profilerに関するコードに入っているバージョンを変更すること

により、前後の比較ができるようになる。● フィボナッチ数列の計算回数は 2000000000に変更するとProfilerで比較を

閲覧可能。Profilerでの比較が不要な場合はそれより低く設定しても問題ない。

演習

以下2つのプログラムを修正し、処理の遅延を修正する。

(Optional) プログラムの確認と修正

● ~/gopath/src/devops-handson/controllers/default.go (HTTPリクエストの処理 )

● GKE Logging Best Practices● Stackdriver Loggingへのインプットフォーマット

演習

default.goにあるMethodLoggingを修正し、Stackdrive loggingにキーをmethod_name、バリューをmethod名として出力できるよう修正を行う。

コンテナのビルドとデプロイ

前章のコマンドを参考に修正後のコードを入れたコンテナを作成し、 GKEへデプロイする。

コンテナをビルドする時に指定するタグは v3とする。

演習

Stackdriver Traceで確認

1. ブラウザで http://<INGRESS-IP>/bench1 にアクセスし、画面表示にかかる時間を確認する。

2. Stackdriver Traceで処理時間が短くなっている事を確認する。

演習

Stackdriver Profilerで確認

1. Stackdriver Profilerで処理時間が短くなっている事を確認する。確認時は、Version比較により確認を行うこと。

演習

(Optional) Stackdriver loggingの確認

演習

Stackdriver Loggingにmethod名が出力されていることを確認する。

● Stackdriver Trace, Profiler, Loggingを利用するとサービスの管理・分析が簡単に行える

○ Stackdrier Traceを利用する時は、Stackdriver Loggingでtrace, spanIdをつけてログを出力する

とより分析を効率的に行うことができる。

○ マイクロサービスアーキテクチャを採用し、他のサービスを呼び出す(RPC, gRPC)際もトレースに

関するHTTPヘッダーをサービス間で送り合うことにより、サービス全体で一貫したトレーシングを

行うことができる。

○ GKEとStackdriver Loggignを利用する場合、標準出力にJSONフォーマットでログを出力するとロ

グが構造され、フィールドをカスタマイズすることにより分析時のフィルタリングが効率的になる。

ここまでのまとめ

05ビルド・デプロイ自動化編

この章で行うこと

ステージング環境

本番環境開発環境

Cloud Shell Profiler Trace Logging

Kubernetes Engine

Cloud Source Repositories

Container RegistryCloud Build

commit, push

trigger register

deploy hook

Get container

Send telemetry

deploy hooknew image

detect

● コンテナの自動ビルド

● コンテナの自動登録

● コンテナの自動リリース

Cloud Source Repositoryでレポジトリを作成するhttps://source.cloud.google.com/ にアクセスする。

画面右上の[新しいレポジトリ]を選択する。

“新しいレポジトリを作成”にチェックを入れ、[続行]をクリックする。

# Cloud ConsoleからもSource Repositoryにアクセスできますが、古いUIのため、

今回は新しいSource Repositoryに直接アクセス頂きます。

Cloud Source Repositoryでレポジトリを作成する

レポジトリ名に “devops-handson” を設定し、作成ボタンをクリックする。

Git レポジトリに資材を登録する

Cloud Shellより以下コマンドを実行する

$ cd ~/gopath/src/devops-handson/$ git init .$ git config --global credential.https://source.developers.google.com.helper gcloud.sh$ git remote add google https://source.developers.google.com/p/$GOOGLE_CLOUD_PROJECT/r/devops-handson$ git config --global user.name "USERNAME" # 自身のユーザ名を設定

$ git config --global user.email "USERNAME@EXAMPLE.com" # 自身のメールアドレスを設定

$ git add --all$ git commit -m "initial commit"$ git push google master

Cloud Source Repositoryに資材が登録されていることを確認するトップページから[View all repositories]をクリックし、先程作成したレポジトリを選択する。

Cloud Build で自動ビルドを設定する

Cloud Consoleに戻り、サイドバーから[ Cloud Build ] > [トリガー] から [トリガーを作成]を選択する

Cloud Build で自動ビルドを設定する

Cloud Build で自動ビルドを設定する

Cloud Buildのサービスアカウントに必要な権限を付与

サイドメニューの[IAMと管理]から[IAM]を選択、xxxxxx@cloudbuild.gserviceaccount.comを見つけ、右端の鉛筆ボタンをクリック、Kubernetes Engine管理社の役割を追加し、[保存]をクリックする。

リポジトリに cloudbuild.yaml を登録し、自動ビルドを行う。

演習

1. ビルドの定義ファイル(cloudbuild.yaml)を作成する

2. リポジトリに追加、コミット、プッシュする

3. 自動ビルドが実行され、成功する事を確認する。

4. GKE上のアプリケーションにアクセスし、アプリケーションにアクセスできる事

を確認する

5. (Optional) コード(P.41のviewなど)を修正し、2-4を繰り返す。

コンテナのビルド、レジストリへの登録、GKEへのデプロイを行うビルド定義ファイルを作成する。

参考資料● Cloud Build - Quickstart for Docker● Cloud Build - Building, testing, and deploying artifacts● Cloud Build - Cloud builders

cloudbuild.yamlのサンプル

steps:- name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/$PROJECT_ID/devops-handson:$SHORT_SHA', '.']- name: 'gcr.io/cloud-builders/docker' args: ['push', 'gcr.io/$PROJECT_ID/devops-handson:$SHORT_SHA']- name: 'gcr.io/cloud-builders/kubectl' args: - 'set' - 'image' - 'deployment/devops-handson-deployment' - 'myapp=gcr.io/$PROJECT_ID/devops-handson:$SHORT_SHA' env: - 'CLOUDSDK_COMPUTE_ZONE=asia-northeast1-c' - 'CLOUDSDK_CONTAINER_CLUSTER=k8s-devops-handson'

演習

● Cloud Source Repository, Cloud Buildを用いると簡単に自動ビルド、自動リリースが実現できる

○ Cloud Buildにはビルドを行うためのビルダーが多数用意されているため、必要な物を利用するこ

とにより、より多くのビルドに関するワークロードをCloud Build上で処理することができる。

○ Cloud Buildのワーカーはフルマネージドかつ並列処理実行可能なため、ビルドがボトルネックに

なりずらい。

○ Cloud BuildはGithubとも連携しているため、今回と同じ事をGithubを用いて行うことが可能。

ここまでのまとめ

06(Optional)高度なデプロイ編

● Spinnakerのハンズオンを行います。

● GKEのクラスターにHelmを使ってSpinnakerをインストールします。

● Spinnakerを使ってカナリーリリースを行う、CI / CD パイプラインを作成しま

す。

この章で行うこと

Spinnakerとは？

● Netflix が開発した OSS のマルチクラウド

Continous Delivery プラットフォーム

● Google も 2014 年から開発に参加

● CD はパイプラインで管理する

● CI 連携は git イベント、Jenkins、他の Spinnaker

パイプライン、などなど

● Immutable Infrastructure - デフォルトで

Blue/Gree (R/B) をサポート

作成する CI/CD パイプライン

SourceRepository

Container Registry

CloudBuild

Kubernetes Engine

開発者

$ git commit$ git tag$ git push build

trigger push new image

Detect New Image

Manual Approval

Deploy to Canaly

Kubernetes Engine

Deploy to Production

Integration Test

大まかなハンズオンの流れ

Spinnaker をクラス

ターにデプロイ

Cloud Buildのトリ

ガーを設定

パイプラインの動作

させてみる

1 2 3 4 5

環境設定

（IDおよびアクセス管

理等）

GKEクラスタの確認

環境設定

1. サービスアカウントを作成します

2. 後のコマンドで使用するために、サービス アカウントのメールアドレスと現在のプロジェクト ID

を環境変数に格納します。

ID およびアクセス管理を設定する

gcloud iam service-accounts create spinnaker-storage-account \ --display-name spinnaker-storage-account

サービス アカウントを作成して Spinnaker に権限を委任し、Cloud Storage にデータを保存できるようにします。

export SA_EMAIL=$(gcloud iam service-accounts list \ --filter="displayName:spinnaker-storage-account" \ --format='value(email)')export PROJECT=$(gcloud info --format='value(config.project)')

3. storage.admin 役割をサービス アカウントにバインドします。

4. サービス アカウント キーをダウンロードします。後のステップで Spinnaker をインス

トールして、このキーを Kubernetes Engine にアップロードします。

ID およびアクセス管理を設定する

gcloud projects add-iam-policy-binding \ $PROJECT --role roles/storage.admin --member serviceAccount:$SA_EMAIL

サービス アカウントを作成して Spinnaker に権限を委任し、Cloud Storage にデータを保存できるようにします。

gcloud iam service-accounts keys create spinnaker-sa.json --iam-account

$SA_EMAIL

※Cloud Shell のカレントディレクトリに spinnaker-sa.json が作成されます。

Spinnaker を GKE クラスターにデプロイする

1. helm バイナリをダウンロードしてインストールします。

2. ファイルをローカル システムに解凍します。

3. Helm のサーバー側である Tiller に対して、cluster-admin 役割を付与します。

Helm をインストールする

wget https://storage.googleapis.com/kubernetes-helm/helm-v2.7.2-linux-amd64.tar.gz

Helm を使用して Charts レポジトリから Spinnaker をデプロイします。Helm は、Kubernetes アプリケーションの設定とデプロイに使用可能なパッケージ マネージャです。

kubectl create clusterrolebinding user-admin-binding --clusterrole=cluster-admin --user=$(gcloud config get-value account)kubectl create serviceaccount tiller --namespace kube-systemkubectl create clusterrolebinding tiller-admin-binding --clusterrole=cluster-admin --serviceaccount=kube-system:tiller

tar zxfv helm-v2.7.2-linux-amd64.tar.gzcp linux-amd64/helm .

4. Spinnaker に対して cluster-admin 役割を与え、全てのネームスペースにリソースをデプロ

イできるようにします。

5. Helm のサーバー側である Tiller をクラスタにインストールするために Helm を初期化しま

す。

Helm をインストールする

kubectl create clusterrolebinding --clusterrole=cluster-admin --serviceaccount=default:default spinnaker-admin

./helm init --service-account=tiller

./helm update

6. 次のコマンドを実行して、 Helm が正しくインストールされていることを確認します。 Helm が正

しくインストールされている場合は、クライアントとサーバーの両方に v2.7.2 が表示されます。

表示例）

Helm をインストールする

./helm version

Client: &version.Version{SemVer:"v2.7.2",GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6",GitTreeState:"clean"}Server: &version.Version{SemVer:"v2.7.2",GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6",GitTreeState:"clean"}

1. Spinnaker でパイプライン設定を保存するためのバケットを作成します。

2. Cloud Shell で次のコマンドを実行して、設定ファイルを作成します。

Spinnaker のデプロイ設定ファイルを作成する

export PROJECT=$(gcloud info \ --format='value(config.project)')export BUCKET=$PROJECT-spinnaker-configgsutil mb -c regional -l us-central1 gs://$BUCKET

export SA_JSON=$(cat spinnaker-sa.json)export PROJECT=$(gcloud info --format='value(config.project)')export BUCKET=$PROJECT-spinnaker-configcat > spinnaker-config.yaml <<EOFstorageBucket: $BUCKETgcs: enabled: true project: $PROJECT jsonKey: '$SA_JSON'

# Disable minio the defaultminio: enabled: false

# Configure your Docker registries hereaccounts:- name: gcr address: https://gcr.io username: _json_key password: '$SA_JSON' email: 1234@5678.comEOF

※先ほど作成した spinnaker-sa.json が保存されているディレクトリで実行してください

1. Helm コマンドライン インターフェースを使用して、設定セットとともに Spinnaker をデプロ

イします。このコマンドは完了するまでに 5 〜 10 分程度かかります。

2. コマンドが完了したら、次のコマンドを実行して、 Cloud Shell から Spinnaker UI へのポー

ト転送をセットアップします。

./helm install -n cd stable/spinnaker -f spinnaker-config.yaml --timeout 600 \ --version 0.3.1

Helm を使用して Spinnaker をデプロイする

export DECK_POD=$(kubectl get pods --namespace default -l "component=deck" \ -o jsonpath="{.items[0].metadata.name}")kubectl port-forward --namespace default $DECK_POD 8080:9000 >> /dev/null &

3. Spinnaker ユーザー インターフェースを開くには、 Cloud Shell で [ウェブでプレビュー ] をクリックし、[ポート 8080 でプレビュー] をクリックします。

4. ようこそ画面が表示されてから、 Spinnaker UI が表示さ

れるはずです。

参考：Helm とは

「Helm」はKubernetes用のパッケージ管理ツールです 。パッケージ

そのものは「Chart」と呼ばれるYAMLファイルの集合体で，独自の

パッケージリポジトリとして「 Kubernetes Charts」を提供していま

す。

Helmでは，kubectlコマンドが使うYAMLファイルから設定可能な部

分を別YAMLファイルとして分離できます。テンプレートエンジンを

使って，インストール時にサイト固有の設定を kubectlコマンドに提

供するYAMLファイルに反映するのです。また， Hook機能によって

パッケージのライフサイクルや定義済みのイベントの途中に，別の

処理を行うことも可能ですし，他のパッケージ（ Chart）との依存関

係も構築できます。

参考：Helmとは用語 役割

helm yum, aptに相当するパッケージマネージャー

chart deb, rpmに相当するパッケージ、Kubernetesのマニフェストのテンプレート (jsonかYamlファイル) をまとめたもの

tiller デプロイを担うサーバーコンポーネント

Package Helmを使って Kubernetes 上にインストールアプリケーション

Release Kubernetes 上にインストールされたパッケージ

Repository チャートが保存される場所

Docker イメージのビルド

1. ソースコードをダウンロードします。

2. ソースコードを解凍します。

3. ディレクトリをソースコードに変更します。

4. このレポジトリの Git commit にユーザー名とメールアドレスを設定します。[EMAIL_ADDRESS] を Git メールアドレスに置き換え、[USERNAME] を Git ユーザー名に置き換えます。

ソースコードレポジトリを作成する

wget https://gke-spinnaker.storage.googleapis.com/sample-app.tgz

アプリケーション ソースコードの変更を検出し、 Docker イメージをビルドしてから、 Container Registry に push するように Cloud Buildを設定します。

tar xzfv sample-app.tgz

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

cd sample-app

5. ソースコード レポジトリへの最初の commit を行います。

6. コードをホストするレポジトリを作成します。

7. 新しく作成したレポジトリをリモートとして追加します。

8. コードを新しいレポジトリのマスター ブランチに push します。

9. コンソールにソースコードが表示されることを確認します。https://console.cloud.google.com/code/develop/browse/sample-app/master

ソースコードレポジトリを作成する

git initgit add .git commit -m "Initial commit"

export PROJECT=$(gcloud info --format='value(config.project)')git remote add origin https://source.developers.google.com/p/$PROJECT/r/sample-app

gcloud source repos create sample-appgit config credential.helper gcloud.sh

git push origin master

1. Cloud Console の Cloud Buildメニューから [Triggers] を選

択し、[Add Trigger]をクリックします。

2. [Cloud Source Repository] を選択し、[Continue] をクリッ

クします。

3. リストから新しく作成した sample-app レポジトリを選択し、

[Continue] をクリックします。

4. 次のトリガー設定を指定します。

○ Name: sample-app-tags○ Trigger type: タグ

○ Tag(regex): v.*○ Build Configuration: cloudbuild.yaml○ cloudbuild.yaml location: /cloudbuild.yaml

5. [Create Trigger] をクリックします。

ビルドトリガーを設定するGit タグがソース レポジトリに push されるたびに Docker イメージをビルドして push するように Cloud Build を設定します。Cloud Build は、自動的にソースコードをチェックして、レポジトリ内の Dockerfile から Docker イメージをビルドし、そのイメージを Container Registry に push します。

1. Cloud Shell でソースコード フォルダに移動します。

2. Git タグを作成します。

3. タグを push します。

4. Cloud Build で、[History] をクリックして、ビルドがトリガーされたことを確認します。トリガーされていない場合は、前のセクションでトリガーが正しく設定されていることを確認します。

イメージをビルドする

cd ~/sample-app

文字 "v" が先頭に付いている Git タグをソースコード レポジトリに push すると、Cloud Build は、自動的に、アプリケーションをビルドして、 Docker イメージとして Container Registry に push します。

git tag v1.0.0

git push --tags

パイプラインの設定

1. Spinnaker UI で、[Actions] をクリックしてから、

[Create Application] をクリックします。

2. [New Application] ダイアログで、次のフィールドを入

力します。

○ Name: sample○ Owner Email: [あなたのメールアドレス]

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

Spinnakerで “アプリケーション” を作成するこれまでの手順で、イメージが自動的にビルドされるようになりました。ここからは、 Kubernetes クラスタにデプロイするパイプラインの設定を Spinnaker 上で行っていきます。

1. Cloud Shell で、sample-app ルート ディレクトリから次のコマンドを実行します。

cd ~/sample-a

サービスロードバランサを作成するKubernetes コマンドライン インターフェースを使用してサービス用のロードバランサを作成します。なおこの操作は Spinnaker UI でを実行することもできます。

kubectl apply -f k8s/services

※sample-app/k8s/services に格納されている4つの yaml ファイルで定義されたロードバランサが作成されます。

cat sample-frontend-prod.yamlapiVersion: v1kind: Servicemetadata: labels: app: sample-frontend-prod name: sample-frontend-prodspec: ports: - name: 80-80 port: 80 protocol: TCP targetPort: 8080 selector: load-balancer-sample-frontend-prod: "true" sessionAffinity: None type: LoadBalancer

1. Cloud Shell の新しいタブを開き、ソースコード ディレクトリで次のコマンドを実行し、パイプラインの例を Spinnaker インスタンスにアップロードします。

2. Spinnaker UI で、上部ナビゲーション バーの [Pipelines] をクリックします。

3. Deploy パイプラインで [Configure] をクリックします。継続的デリバリー パイプラインの設定が UI に表示されます。

デプロイメントパイプラインを作成する

export PROJECT=$(gcloud info --format='value(config.project)')sed s/PROJECT/$PROJECT/g spinnaker/pipeline-deploy.json | curl -d@- -X \ POST --header "Content-Type: application/json" --header \ "Accept: /" http://localhost:8080/gate/pipelines

次に、デプロイメント パイプラインを作成します。このチュートリアルでは、 "v" という接頭辞が付いた Docker イメージが Container Registry に到着したことを検出するようにパイプラインが設定されます。

パイプラインを手動で実行する

1. [Pipelines] をクリックして、パイプライン ページに戻ります。

2. [Start Manual Execution](手動実行を開始) をクリックします。

3. [tag] プルダウン リストから v1.0.0 タグを選択し、[Run] をクリックします。

パイプラインを手動で実行するいま作成したパイプラインの設定には接頭辞の "v" が付いた新しい Git タグが push されたときにパイプラインを開始するトリガーが含まれています。まずは、パイプラインを手動で実行してテストします。その次に、 Git タグを push し、パイプラインが自動的に実行されるのを観察することによってテストします。

4. パイプラインが開始したら、[Details] をクリックして、ビルドの進捗状況の詳細を表示します。このセクションでは、デプロイメント パイプラインのステータスとその手順を示します。青色のステップは現在実行中、緑色のステップは正常に完了、赤色のステップは失敗を示します。ステージをクリックすると、その詳細が表示されます。

3 〜 5 分後に統合テストフェーズが完了し、パイプラインがデプロイメントを続行するための手動承認を要求します。

5. 黄色の「人物」アイコンにカーソルを合わせ、[続行] をクリックします。

ロールアウトが本番環境フロントエンドと本番環境バックエンドのデプロイメントに進みます。これは数分後に完了します。

パイプラインを手動で実行する

6. アプリケーションを表示するには、Spinnaker UI の右上にある [Load Balancers] をクリックします。

7. ロードバランサのリストをスクロール ダウンし、[sample-frontend-prod] の下で [DEFAULT] をクリックします。

8. 右側の詳細ウィンドウをスクロール ダウンし、Ingress IP 上のクリップボード ボタンをクリックして、アプリケーションの IP アドレスをコピーします。# httpでアクセスしてください。

パイプラインを手動で実行する

9. アドレスをブラウザに貼り付けると、アプリケーションの本番環境バージョンが表示されます。

これで、アプリケーションをビルド、テスト、デプロイするパイプラインを手動でトリガーできました。

パイプラインを手動で実行する

パイプラインのトリガーを動かす

1. Cloud Shell で、sample-app ルート ディレクトリから次のコマンドを実行し、アプリケーションの色をオレンジ色から青色に変更します。

2. 変更にタグを付け、ソースコード レポジトリに push します。

3. 新しいビルドが Cloud BuildのHistoryに表示されます。4. Spinnakerの[Pipelines] をクリックして、パイプラインがイメージのデプロイを開始するのを監視

します。デプロイが開始されない場合はブラウザのページを更新してみてください。5. 実際はここでアプリケーションのテストをします。テストが完了したら、[Spinnaker] タブに戻り、

デプロイメントを承認します。

デプロイメントパイプラインを作成する

sed -i 's/orange/blue/g' cmd/gke-info/common-service.go

コードの変更、Git タグの push 、レスポンスでのパイプライン実行の監視を通して、パイプラインをエンドツーエンドでテストします。

git add cmd/gke-info/common-service.gogit commit -a -m "Change color to blue"git tag v1.0.1git push --tags

6. パイプラインが完了すると、アプリケーションが次のスクリーンショットのようになります。コードが変更されたために色が青に変わったことと、[バージョン] フィールドに v1.0.1 と表示されていることに注意してください。

これで、アプリケーションを本番環境全体に正常にロールアウトできました。

7. （オプション）前回の commit を元に戻して、この変更をロールバックすることができます。ロールバックすると新しいタグ (v1.0.2) が追加され、v1.0.1 をデプロイするときに使用したのと同じパイプラインを通してタグが戻されます。

デプロイメントパイプラインを作成する

git revert v1.0.1git tag v1.0.2git push --tags

クリーンアップ（終わり）

作成したリソースを削除する本ハンズオンで作成したリソースについて課金を回避するために削除する手順は次の通りです。あるいは、プロジェクトまるごと削除して頂いても結構です。

1. Spinnaker のインストールを削除します。

2. サンプル アプリケーション サービスを削除します。

3. サービス アカウントを削除します。

4. Kubernetes Engine クラスタを削除します。

5. レポジトリを削除します。

../helm delete --purge cd

kubectl delete -f k8s/services

export SA_EMAIL=$(gcloud iam service-accounts list \--filter="displayName:spinnaker-storage-account" --format='value(email)')gcloud iam service-accounts delete $SA_EMAIL

gcloud container clusters delete spinnaker-tutorial

gcloud source repos delete sample-app

作成したリソースを削除する6. バケットを削除します。

7. コンテナ イメージを削除します。

8. 上記のオプションのロールバック ステップで v1.0.2 を作成した場合は、そのコンテナ イメージを削除します。

export PROJECT=$(gcloud info --format='value(config.project)')export BUCKET=$PROJECT-spinnaker-configgsutil -m rm -r gs://$BUCKET

export PROJECT=$(gcloud info --format='value(config.project)')gcloud container images delete gcr.io/$PROJECT/sample-app:v1.0.0gcloud container images delete gcr.io/$PROJECT/sample-app:v1.0.1

gcloud container images delete gcr.io/$PROJECT/sample-app:v1.0.2

ここまでのまとめ

● Spinnakerを使うことで、ブルー／グリーンデプロイメントやカナリーリリースな

ど、より高度なデプロイを行うことが可能です。

● Manual approveなど実際に現場に即した要素をパイプラインに組み込むこと

が出来ます。

07Clean up編

● プロジェクトを削除してください。作成したリソースは全て削除されます。

○ [IAMと管理] > [設定] > [シャットダウン ]

本ハンズオン後に不用な課金を避けるため

Confidential & Proprietary

Thank you