はじめに

本書の内容

本書は@pospomeがサーバサイドアプリケーションのデプロイフローに関してまとめたものです。

著者

pospome。サーバサイドエンジニア。DDD、実装パターンのようなアプリケーションアーキテクチャが専門。最近は認証認可に興味がある。Twitterは@pospome。ブログは「pospomeのプログラミング日記」。共にアプリケーションアーキテクチャ、Go言語、GCPを中心にアウトプットしている。キャラクターは羊ではなくポメラニアン。

誤字脱字報告フォーム

誤字脱字、不自然な日本語、図やサンプルコードの参照ミスを見つけた場合は以下のフォームから報告していただけると嬉しいです。

誤字脱字報告フォームはこちら。

免責事項

本書に記載された内容は、情報の提供のみを目的としています。したがって、本書を用いた開発、製作、運用は、必ずご自身の責任と判断によって行ってください。これらの情報による開発、製作、運用の結果について、著者はいかなる責任も負いません。

第1章　デプロイフローについて

本書では図1.1のデプロイフローを扱います。（画像は拡大して見てください）

図1.1:

解説対象となる技術は以下です。

  • Docker
  • GitHub
  • CircleCI
  • GCR(Google Container Registry)
  • GKE(Google Kubernetes Engine)
  • Spinnaker

第2章　デプロイフローを一通り体験する

2.1　はじめに

本章はアプリケーションのデプロイフローを一通り体験することができるチュートリアルです。最低限必要な基礎知識を説明しながら可能な限り最短でアプリケーションをデプロイすることを目的としています。各技術の細かい設定は他の章で説明しているのでそちらを参照してください。

2.2　GoでWebサーバを作成する

最初にデプロイ対象となるアプリケーションを作成しましょう。本書では筆者が使い慣れているGoのWebサーバを対象としますが、デプロイ対象はDockerのイメージであればGoのWebサーバである必要はありません。Goのインストールは省略します。

リスト2.1がWebサーバの実装です。"Hello"という文字列を表示するだけのシンプルな実装です。

リスト2.1: 

package main

import (
  "fmt"
  "net/http"
)

func main() {
  http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello")
  })
  http.ListenAndServe(":8080", nil)
}

リスト2.1をmain.goというファイル名で保存しましょう。ディレクトリ構造はリスト2.2のようになります。

リスト2.2: 

$GOPATH/src/github.com/pospome/go-web-server/
└── main.go

ローカルマシンでWebサーバを起動してみましょう。（リスト2.3）

リスト2.3: 

$go run main.go

Webサーバが起動できたらcurlで動作確認しましょう。"Hello"という文字列が表示されれば成功です。（リスト2.4）

リスト2.4: 

$curl localhost:8080
Hello%

2.3　Dockerfileを作成する

Dockerfileを作成します。Dockerのインストールは省略します。

Dockerfileは"Start a Go instance in your app"を参考にします。Dockerfileはリスト2.5です。

リスト2.5: 

FROM golang:1.11-alpine

WORKDIR /go/src/go-web-server
COPY . .

RUN go get -d -v ./...
RUN go install -v ./...

CMD ["go-web-server"]

Dockerfileを配置したディレクトリ構造はリスト2.6です。

リスト2.6: 

$GOPATH/src/github.com/pospome/go-web-server/
├── Dockerfile
└── main.go

Dockerfileが正しいことを確認するためにローカルマシンでDockerイメージを作成します。リスト2.7のコマンドを実行してください。

リスト2.7: 

$docker build -t go-web-server ./

作成したDockerイメージを確認します。リスト2.8のコマンドを実行してください。

リスト2.8: 

$docker images --format "table {{.Repository}}" go-web-server
REPOSITORY
go-web-server

Dockerイメージが正しく起動することを確認するためにローカルマシンで起動します。リスト2.9のコマンドを実行してください。

リスト2.9: 

$docker run -it --rm --name running-go-web-server -p 80:8080 go-web-server

Dockerイメージが起動していることを確認します。リスト2.10のコマンドを実行してください。

リスト2.10: 

$docker ps --format "table {{.Names}}"
NAMES
running-go-web-server

curlで動作確認します。リスト2.11のコマンドを実行して"Hello"という文字列が出力されれば成功です。

リスト2.11: 

$curl localhost
Hello%

2.4　GitHubリポジトリを作成する

GoのWebサーバ実装とDockerfileを配置したディレクトリをGitHubのリポジトリにpushしてください。ここではプライベートリポジトリを作成します。（図2.1）

図2.1:

2.5　CLOUD SDKをセットアップする

本書ではGCP(Google Cloud Platform)を利用するのでCLOUD SDKをセットアップする必要があります。Cloud SDKはコマンドラインでGCPのリソースを操作できるSDKです。Cloud SDKをインストールすると"gcloud"コマンドを実行することができます。こちらから任意のOSを選択してCLOUD SDKをインストールしてください。筆者はMacを利用しているのでこちらの手順でインストールしました。"gcloud の主要なコマンドの実行"まで進めてリスト2.12,リスト2.13のコマンドにてアカウントが正しく設定されていることを確認できればセットアップ完了です。

リスト2.12: 

$gcloud auth list
   Credentialed Accounts
ACTIVE  ACCOUNT
*       xxx@gmail.com

To set the active account, run:
    $ gcloud config set account `ACCOUNT`

リスト2.13: 

$gcloud config list
[core]
account = xxx@gmail.com
disable_usage_reporting = True

Your active configuration is: [default]

2.5.1　GCPプロジェクトを作成する

ここに利用するGCPプロジェクトを作成します。GCPにおけるプロジェクトなどのリソースの概念はこちらに載っています。プロジェクトについてはこちらに載っています。プロジェクトの上位には"組織リソース"が存在しますが、組織リソースを持つのはG SuiteまたはCloud Identityのユーザーだけです。個人でGCPを利用する場合はプロジェクトが最上位のリソースになるでしょう。

GCPのプロジェクトを作成するためにプロジェクトIDを決めます。組織リソースが存在しない場合、プロジェクトIDは他のユーザーも含めたGCP全体でユニークでなければいけません。例えば"sample"のようなありきたりな名前を指定してプロジェクトを作成するとリスト2.14のエラーが発生します。

リスト2.14: 

$gcloud projects create sample
ERROR: (gcloud.projects.create) Project creation failed. The project ID you specified is already in use by another project. Please try an alternative ID.

筆者はプロジェクトIDとして"pospome-deployflow-project"を指定してプロジェクトを作成します。皆さんもユニークなプロジェクトIDを指定してGCPプロジェクトを作成してください。プロジェクトの作成はリスト2.15のコマンドを実行してください。

リスト2.15: 

$gcloud projects create pospome-deployflow-project

本書の中でGCPのプロジェクトIDに依存しているコマンドやURLには"pospome-deployflow-project"のような個人に依存する値が含まれています。それらのコマンドやURLは随時自分のプロジェクトIDに置き換えてください。

2.5.2　CLOUD SDKでプロジェクトとゾーンを固定する

GCPにはゾーンという概念が存在します。ゾーンを一言で説明するとリソースのホスト先です。例えばGCPにおける仮想マシンであるGCE(Google Compute Engine)を利用する場合、その仮想マシンをホストする場所としてゾーンを選択する必要があります。当然ながらホスト先が地理的に近ければ近いほどリソースへのアクセスは高速になります。例えば日本でWebサービスを展開する場合は日本のゾーンを選択した方がよいでしょう。しかし、ゾーンによっては特定のリソースをサポートしていないことがあるので注意しましょう。ゾーンについて詳しく知りたい場合はこちらを参照してください。

CLOUD SDKは複数のプロジェクトと複数のゾーンを扱うことができるので、プロジェクトとゾーンに依存する操作では対象となるプロジェクトとゾーンを指定する必要があります。ゾーンを指定せずにコマンドを実行した場合はリスト2.16のエラーが発生します。

リスト2.16: 

$gcloud compute instances create sample-gce
ERROR: (gcloud.compute.instances.create) The required property [project] is not currently set.
You may set it for your current workspace by running:

  $ gcloud config set project VALUE

or it can be set temporarily by the environment variable [CLOUDSDK_CORE_PROJECT]

プロジェクトとゾーンの指定方法は2つあります。1つ目はリスト2.17のように"--project","--zone"オプションで指定する方法です。

リスト2.17: 

$gcloud compute instances create sample-gce --project=pospome-deployflow-project --zone=asia-east1-b

2つ目はリスト2.18のようにデフォルト値としてセットしておく方法です。

リスト2.18: 

$gcloud config set project pospome-deployflow-project
$gcloud config set compute/zone asia-east1-b

本書ではコマンドごとに異なるプロジェクトとゾーンを扱うことはありません。プロジェクトとゾーンを毎回指定するのは面倒なのでここではデフォルト値としてセットします。ここではゾーンとして"asia-east1-b"を利用します。リスト2.18のコマンドを実行してプロジェクトとゾーンをデフォルト値としてセットしてください。プロジェクトIDとして指定している"pospome-deployflow-project"は自分が作成したプロジェクトIDに置き換えてください。リスト2.18を実行し終わったらリスト2.19を実行してゾーンとプロジェクトがセットされていることを確認してください。

リスト2.19: 

$gcloud config list
[compute]
zone = asia-east1-b //セットされている
[core]
account = xxx@gmail.com
disable_usage_reporting = True
project = pospome-deployflow-project //セットされている

2.5.3　GCPの各種APIの有効化について

GCPではCLOUD SDKにて初めて操作するリソースに対してAPIを有効にする必要があります。例えばリスト2.20は利用可能なゾーンの一覧を表示するコマンドですが、今までGCEのリソースに対する操作をしたことがない場合、APIを有効にするかを確認するメッセージが表示されます。

リスト2.20: 

$gcloud compute zones list
API [compute.googleapis.com] not enabled on project [984882888172].
Would you like to enable and retry (this will take a few minutes)?
(y/N)?

ここではAPIの有効化を省略しているのでリスト2.20のようなメッセージが表示された場合、"y"を入力してAPIを有効にしてください。

2.5.4　プロジェクトに対して課金設定をする

ここではGCPの課金設定を有効にする必要があります。こちらを参考にGCPの請求先アカウントを作成してください。請求先アカウントを作成したらリスト2.21のコマンドを実行して確認します。

リスト2.21: 

$gcloud beta billing accounts list

請求先アカウントが確認できたらリスト2.22のコマンドを実行して請求先アカウントとGCPプロジェクトを紐づけましょう。"--billing-account"のオプションにはリスト2.21で表示される"ACCOUNT_ID"を指定します。

リスト2.22: 

$gcloud beta billing projects link pospome-deployflow-project --billing-account XXXXXX-XXXXXX-XXXXXX

請求先アカウントとGCPプロジェクトを紐付けることができたら利用可能なゾーンの一覧を表示してみましょう。リスト2.23のコマンドを実行してください。課金設定とGCEのAPIを有効にするとゾーンの一覧が表示されるはずです。

リスト2.23: 

$gcloud compute zones list

課金設定がされていない場合はリスト2.24のようなエラーが表示されます。

リスト2.24: 

Enabling service [compute.googleapis.com] on project [984882888172]...
ERROR: (gcloud.compute.zones.list) FAILED_PRECONDITION: Operation does not satisfy the following requirements: billing-enabled {Billing must be enabled for activation of service '' in project 'pospome-deployflow-project' to proceed., https://console.developers.google.com/project/pospome-deployflow-project/settings}

2.6　GitHubとCircleCIを連携する

GitHubのリポジトリへのpushをCircleCIが検知できるようにします。

2.6.1　GitHubとCircleCIを連携する

GitHubとCircleCIを連携します。まずはCircleCIにログインしてください。今回はGitHubを利用しているのでGitHubアカウントを利用してログインします。（図2.2）

図2.2:

ログインすると図2.3のような画面が表示されます。

図2.3:

左メニューの"ADD PROJECTS"から連携対象となるCircleCIリポジトリの"Set Up Project"ボタンをクリックします。（図2.4）

図2.4:

図2.5のような"Set Up Project"のページが表示されれば連携は完了です。

図2.5:

2.6.2　ジョブを動かす

GitHubのリポジトリへのpushをトリガーにCircleCIでジョブを動かしてみましょう。"Set Up Project"のページ内の一番下には"Sample .yml File"というセクションがあり、リスト2.25のようなYAMLが表示されていると思います。

リスト2.25: 

# Golang CircleCI 2.0 configuration file
#
# Check https://circleci.com/docs/2.0/language-go/ for more details
version: 2
jobs:
  build:
    docker:
      # specify the version
      - image: circleci/golang:1.9

      # Specify service dependencies here if necessary
      # CircleCI maintains a library of pre-built images
      # documented at https://circleci.com/docs/2.0/circleci-images/
      # - image: circleci/postgres:9.4

    #### TEMPLATE_NOTE: go expects specific checkout path representing url
    #### expecting it in the form of
    ####   /go/src/github.com/circleci/go-tool
    ####   /go/src/bitbucket.org/circleci/go-tool
    working_directory: /go/src/github.com/{{ORG_NAME}}/{{REPO_NAME}}
    steps:
      - checkout

      # specify any bash command here prefixed with `run: `
      - run: go get -v -t -d ./...
      - run: go test -v ./...

リスト2.25はCircleCIで実行するジョブの定義ファイル（YAML形式）です。リスト2.25はサンプルということもあり、シンプルなジョブです。具体的には"circleci/golang:1.9"というGo1.9のDockerイメージで、"go get -v -t -d ./...","go test -v ./..."を実行しているだけです。つまり、Goのテストを実行しているだけのジョブです。リスト2.25を今回のWebサーバ用に書き直したものがリスト2.26です。

リスト2.26: 

version: 2
jobs:
  build:
    docker:
      - image: circleci/golang:1.11

    working_directory: /go/src/github.com/pospome/go-web-server
    steps:
      - checkout
      - run: go get -v -t -d ./...
      - run: go test -v ./...

修正点は以下です。

  • "{{ORG_NAME}}"を"pospome"（GitHubのユーザー名）に変更。
  • "{{REPO_NAME}}"を"go-web-server"（GitHubのリポジトリ名）に変更。
  • "image"に指定されている"circleci/golang:1.9"を"circleci/golang:1.11"に変更。
  • コメントを全て削除。

"{{ORG_NAME}}","{{REPO_NAME}}は環境変数で渡す必要がないのでハードコーディングに変更しました。ジョブを実行するDockerイメージはGo1.9からGo1.11に変更しました。ここでデプロイするgo-web-serverにはテストが存在しないので"go test"を実行する意味もないのですが、"go test"を実行してジョブが失敗することもないので削除せず残しています。

CircleCIはGitHubリポジトリのルートディレクトリに存在する".circleci/config.yml"を参照し、そのファイルに記載されている処理を実行します。リスト2.26をGitHubリポジトリのルートディレクトリに".circleci/config.yml"として設置してください。ディレクトリ構造はリスト2.27になります。

リスト2.27: 

$GOPATH/src/github.com/pospome/go-web-server/
├── .circleci
│   └──config.yml
├── Dockerfile
└── main.go

config.ymlの設置が終わったらそれらをcommitしてリポジトリのmasterブランチにpushしてください。CircleCIのジョブはpushをトリガーにして実行されるので、ジョブが実行されるはずです。CircleCIのジョブはCircleCIの左メニューの"JOBS"で確認することができます。ジョブが正しく実行されればCircleCIとGitHubの連携は完了です。

ちなみにCircleCIがGitHubのプライベートリポジトリをチェックアウトできるのは、GitHubとCircleCIが連携した際にCircleCIがGitHubのリポジトリの"読み取り権限"を持つからです。具体的にはGitHubが公開鍵を持ち、CircleCIが秘密鍵を持ちます。GitHubの公開鍵は対象リポジトリの"Settings"→"Deploy keys"で確認できます。CircleCIの秘密鍵は"Settings"→"Projects"→"対象プロジェクトの右上にある歯車アイコン"→"Checkout SSH keys"で確認できます。

2.7　CircleCIからGCRにDockerイメージをpushする

GitHubとCircleCIの連携が完了したのでCircleCIからGCRにDockerイメージをpushできるようにします。

2.7.1　CLOUD SDKの認証を設定する

CircleCIからGCRにDockerイメージをpushするためにはCircleCIのジョブでCLOUD SDKを利用する必要があります。そこで解決しなければならない問題がCircleCIからGCRへDockerイメージをpushする際の認証です。CircleCIのジョブ内でインストールしたCLOUD SDKに認証を設定する必要があります。CLOUD SDKの認証を設定するためのサンプルはこちらにあります。おそらくリスト2.28のようなジョブ定義だと思います。

リスト2.28: 

version: 2
jobs:
  deploy:
    docker:
      - image: google/cloud-sdk
    steps:
      - run: |
          echo $GCLOUD_SERVICE_KEY | gcloud auth activate-service-account --key-file=-
          gcloud --quiet config set project ${GOOGLE_PROJECT_ID}
          gcloud --quiet config set compute/zone ${GOOGLE_COMPUTE_ZONE}

ジョブを実行する"google/cloud-sdk"イメージにはCLOUD SDKが含まれているのでジョブで明示的にCLOUD SDKをインストールする必要はありません。"$GCLOUD_SERVICE_KEY"にはGCLOUD SDKの認証設定に利用する"サービスアカウント"という秘密鍵を指定します。CircleCIからDockerイメージをGCRへpushするためにはサービスアカウントを理解する必要があります。

GCPでは各リソースに対する権限管理の仕組みとしてCloudIAMというサービスが存在します。サービスアカウントはCloudIAMが提供する認証方法の1つです。エンドユーザーに対する権限管理ではなく、GCP上にホストされているリソース同士のアクセスや外部サービスからのアクセスの権限管理に利用します。ここの"CircleCIからGCRにDockerイメージをpushする"という要件は外部サービスからGCPへのアクセスなので、サービスアカウントによる認証を利用します。CircleCI以外の外部サービスとGCPを連携させる場合もサービスアカウントを利用することになります。例えば本書で扱うSpinnakerはGCPへアクセスする必要があるので、サービスアカウントを利用します。

サービスアカウントを作成します。リスト2.29のコマンドを実行してください。

リスト2.29: 

$gcloud iam service-accounts create circleci --display-name circleci

作成したサービスアカウントはリスト2.30のコマンドで確認できます。

リスト2.30: 

$gcloud iam service-accounts list

CloudIAMには"Role"と"Permisson"という概念が存在します。Permissonは各リソースに対する権限です。そしてRoleはPermissonの集合体です。RoleとPermissonの関係性はこちらの具体例を確認するとわかりやすいと思います。例えば"roles/androidmanagement.user"というRoleはリスト2.31にあるPermissonを持ちます。

リスト2.31: 

androidmanagement.*
serviceusage.quotas.get
serviceusage.services.get
serviceusage.services.list

1つのサービスアカウントに1つのPermissonのみ付与するというユースケースは少ないでしょう。おそらく複数のPermissonを付与するはずです。そのためサービスアカウントはRole単位で権限を持ちます。Roleは複数持つことが可能です。そしてサービスアカウントにはPermissonを直接付与することはできません。例えばリスト2.31の"serviceusage.quotas.get"という1つのPermissonをサービスアカウントに付与することはできません。

しかし、CloudIAMにはCustomRoleという任意のPermissonを組み合わせたRoleを作成する仕組みがあります。そのため"serviceusage.quotas.get"という1つのPermissonだけを持つCustomRoleを作成し、サービスアカウントに付与することで、サービスアカウントに"serviceusage.quotas.get"のPermissonのみ持たせることが可能です。

サービスアカウントに付与されているRoleはリスト2.32のコマンドで確認できます。サービスアカウントを作成するだけではRoleが付与されないので"etag"のみ表示されるはずです。

リスト2.32: 

$gcloud projects get-iam-policy pospome-deployflow-project

さきほど作成したサービスアカウントにGCRへpushするためのRoleを付与しましょう。少しややこしいのですが、実はGCR用のRoleというものは存在しません。GCRに対する権限管理はGCS(Google Cloud Storage)のRoleを利用します。GCRへDockerイメージをpushするには"roles/storage.admin"というRoleが必要です。リスト2.33のコマンドを実行してください。

リスト2.33: 

$gcloud projects add-iam-policy-binding pospome-deployflow-project --member serviceAccount:circleci@pospome-deployflow-project.iam.gserviceaccount.com --role roles/storage.admin

リスト2.34のコマンドで付与されたRoleを確認することができます。

リスト2.34: 

$gcloud projects get-iam-policy pospome-deployflow-project

サービスアカウントをCircleCIに登録します。CircleCIに登録するサービスアカウントの実体はJSON形式の秘密鍵です。そのためCircleCIには環境変数としてJSON文字列を登録します。秘密鍵はリスト2.35のコマンドで作成することができます。

リスト2.35: 

$gcloud iam service-accounts keys create --iam-account circleci@pospome-deployflow-project.iam.gserviceaccount.com ./circleci.json

CircleCIに秘密鍵を環境変数として登録しましょう。CircleCIの左メニュー"SETTINGS"→Projectsにて対象リポジトリの右上の歯車アイコンをクリックします。（図2.6）

図2.6:

設定ページの"Environment Valiables"の"Add Valiable"をクリックします。（図2.7）

図2.7:

図2.8のようなフォームが表示されるので、"Name"にジョブの環境変数名である"GCLOUD_SERVICE_KEY"を入力し、"Value"に秘密鍵（JSON文字列）をそのまま入力します。

図2.8:

CircleCIではこのように環境変数を登録することでジョブから参照することができます。

2.7.2　ジョブを書く

リスト2.28を参考にGCRへpushするジョブを書くとリスト2.36になります。

リスト2.36: 

version: 2
jobs:
  build:
    working_directory: /go/src/github.com/pospome/go-web-server
    docker:
      - image: google/cloud-sdk
    steps:
      - checkout
      - setup_remote_docker:
          version: 18.06.0-ce
      - run:
          name: Setup CLOUD SDK
          command: |
            echo  $GCLOUD_SERVICE_KEY | gcloud auth activate-service-account --key-file=-
            gcloud --quiet config set project pospome-deployflow-project
            gcloud --quiet config set compute/zone asia-east1-b
            gcloud --quiet auth configure-docker
      - run:
          name: Push docker image
          command: |
            docker build -t go-web-server .
            TAG=gcr.io/pospome-deployflow-project/go-web-server:pushed-`date +%Y%m%d%H%M%S`
            docker tag go-web-server $TAG
            docker push $TAG
            LATEST_TAG=gcr.io/pospome-deployflow-project/go-web-server:latest
            docker tag go-web-server $LATEST_TAG
            docker push $LATEST_TAG

"$GCLOUD_SERVICE_KEY"は環境変数として登録したサービスアカウント（JSON文字列）になります。"gcloud auth activate-service-account --key-file=-"はCLOUD SDKの認証にサービスアカウントを利用するための設定です。CLOUD SDKの認証にサービスアカウントを利用するという方法は自社のオンプレサーバやGCP以外のクラウドプラットフォームのサーバからGCPにアクセスする際に便利なので覚えておくと良いでしょう。

"setup_remote_docker"はCircleCI上でdockerコマンド、docker-composeコマンドを利用する際に設定します。"setup_remote_docker"で指定するDockerの"version"についてはこちらに載っています。安定版のバージョンはこちらから確認できますが、CircleCIで最新のバージョンを利用できるとは限りません。サポート外のversionを指定した場合、ジョブ実行時にリスト2.37のエラーが発生します。

リスト2.37: 

Allocating a remote Docker Engine
failed to create host: rpc error: code = Unknown desc = image docker-18.06.3-ce is not supported

ここではドキュメント上のサンプルで指定している"18.06.0-ce"を指定します。（図2.9）

図2.9:

"gcloud --quiet auth configure-docker"はDockerの"Credential helpers"を利用するためのコマンドです。Credential helpersはGCRのような特定のDocker Registry向けの認証を"docker login"コマンドを利用せずに提供する仕組みです。AWSにも"Amazon ECR Docker Credential Helper"というCredential helpersが存在します。GCPの場合はサービスアカウントによって設定したCLOUD SDKの認証情報を利用して、"docker push"コマンドにてGCRにDockerイメージをpushすることができるようになります。Dockerイメージをpushする方法は他にもあるので興味のある方は確認してみてください。

"name: Push docker image"はdockerコマンドを利用してDockerイメージをpushしているだけなので説明は省略します。

CircleCIからGCRにDockerイメージをpushするためにGCRのAPIを有効にします。リスト2.38のコマンドを実行してください。

リスト2.38: 

$gcloud services enable containerregistry.googleapis.com

ちなみにGCRのAPIを有効にする前にCLOUD SDKからGCRを操作するとリスト2.39のようなエラーが発生します。

リスト2.39: 

$gcloud container images list
ERROR: (gcloud.container.images.list) Bad status during token exchange: 403
{"errors":[{"code":"DENIED","message":"Token exchange failed for project 'pospome-deployflow-project'. Please enable or contact project owners to enable the Google Container Registry API in Cloud Console at https://console.cloud.google.com/apis/api/containerregistry.googleapis.com/overview?project=pospome-deployflow-project before performing this operation."]}}

有効になっているAPIはリスト2.40で確認することができます。

リスト2.40: 

$gcloud services list --enabled

GCRのAPIを有効にしたらリスト2.36のジョブ定義を".circleci/config.yml"に上書きしてmaster branchにpushしましょう。CircleCIでビルドが走り、GCRにイメージがpushされるはずです。

GCRにpushされたDockerイメージはリスト2.41のコマンドで確認できます。

リスト2.41: 

$gcloud container images list
NAME
gcr.io/pospome-deployflow-project/go-web-server

指定したイメージのタグはリスト2.42のコマンドで確認できます。

リスト2.42: 

$gcloud container images list-tags gcr.io/pospome-deployflow-project/go-web-server
DIGEST        TAGS                   TIMESTAMP
aa0ceb6cf1fd  pushed-20190306141228  2019-03-06T23:12:29

これでDockerイメージをGCRにpushすることができました。

2.8　Spinnakerを構築する

GCR上のDockerイメージをGKEにデプロイするためにSpinnakerを利用します。SpinnakerはCD(Continuous Delivery)を実現するOSSです。ソフトウェアをデプロイする際に必要となる機能を備えているだけではなく、マルチクラウドに対応しているという特徴を持っています。つまり、本書で扱うGKEに対するデプロイだけではなく、AWS。Spinnakerを利用するメリットについてはこちらの記事が参考になります。

Spinnakerを構築する前に第4章「Spinnaker Tips」の「4.9 Spinnakerトラブルシューティング」に目を通しておくことをおすすめします。

2.8.1　Spinnakerのインストール方法について

Spinnakerのインストール方法には大きく分けて2つあります。1つ目はクイックスタートです。クイックスタートにも複数のインストール方法があるのですが、GCPであれば"Google Cloud Launcher"でインストールすることが可能です。2つ目は"Halyard"というSpinnaker専用のコマンドラインツールを利用する方法です。

Spinnakerのドキュメント上にはクイックスタートは本番環境で利用するものではないという記載があるので、実際に業務で利用する際にはHalyardを利用して構築することになります。そのためここでは"Halyard"を利用する通常の構築方法でSpinnakerを構築します。Halyardを利用したSpinnakerの構築方法はこちらです。ここではこれを参考にSpinnakerの構築を進めます。

試し読みはここまでです。
この続きは、製品版でお楽しみください。