2018年3月2日酔いどれGCPUG で発表してきました

はじめに

「GKE始めるにあたって最初に知っておきたかったこと」というタイトルで発表しました。

※ GKE = Google Kubernetes Engine

LTをした動機は、KubernetesをGoogle Cloud Platformで使うにあたって、参入障壁がだいぶ高かったので、もっといろんな人が使って、情報を発信してくれるといいな、というところからです。

説明しきれなかった部分などがあるので、補足的に載せておきます。

GKEを使う時に必要な知識

GKEを使うにあたっては大きく以下の2つの知識が必要です。

Gogle Cloud Platform (略称 GCP)
Kubernetes (略称 k8s)

GCP

GCPを初めて使った当初は公式のチュートリアルをコツコツとやって、このサービスはこれができるのか、あれができるのか、でもお金はこれだけかかるのか、とかいろいろ試してみると分かります。

Kubernetes

Kubernetesは実際にコンテナを載せて、ロードバランサーの設定から、 Podの構成を考えたり、開発環境と本番環境をどうやって切り替えるか、といったところを実際に手を動かしてやってみるのですが、量が多いです。（慣れてしまえば、実際にはそうでもないのですが）

どちらにせよ、学習コストが結構かかります。なので、発表では最初にこれを知っておけば楽ができる、ということにフォーカスを当てています。

それぞれの章について

次のような章立てで資料を構成しています。

Helm
組み合わせ
周辺ツール
情報源

それぞれの章について、もっともっと話したいことがたくさんあったのですが、今回はぐっとこらえて、全体感を大雑把に説明しました。

ただ、ここでは文字をたくさん書けるので、次に何をやるといいの、というところまで載せて置こうと思います。

一度資料を見た人は復習しながら、初めての人は追加情報としてこれ以降をご覧ください。

1. Helm

Helmというkubernetesのパッケージマネージャーがあります。Emacsのhelmではありません(笑)。

helmは何を解決してくれるかというと、設定ファイルをテンプレート化してくれるということです。

helmを使わない場合の例

具体的に説明します。Podという単位でKubernetes上にコンテナをデプロイするのですが、 1つのコンテナに対して様々な設定を書く必要があります。

コンテナに関してはdockerを利用するのですが、仮にhello-worldをデプロイしようとすると、デプロイメントという設定ファイルを記述していきます。

deployment.yamlというファイル名で以下の設定を記述します。

# この設定で動くかどうか確認していませんが、設定内容自体は正しいはずです
apiVersion: extensions/v1beta1     # Version
kind: Deployment                   # マニフェストの種類
metadata:
  name: docker-hello-world         # 名前
  labels:
    app: docker-hello-world        # Deploymentのラベル
spec:
  replicas: 1                      # podのレプリカ数
  template:
    metadata:
      labels:
        app: docker-hello-world    # ラベル
    spec:
      containers:
        - name: docker-hello-world # コンテナの名前
          image: hello-world:linux # イメージ名とタグ

Kubernetesへの適用は

kubectl apply deployment.yaml

とすれば完了です。

さて、ここで本番環境、開発環境を切り分けたいとき、同じ設定ファイルを使うのですが、これをコピーして2つのデプロイメントファイルを作る、ということを想像してみて下さい。

かなり嫌です。

一番変えたいのはコンテナのイメージのタグだけだったりするのに、他の項目まで面倒をみるとなると叫びたくたくなります。

これを解決してくれるのがhelmです。

helmを使った場合の例

早速テンプレート化していきます。今回はイメージだけテンプレート化します。テンプレートはhelmコマンドで作成できます。

helm create hello-world-sapmle

ここで作成されるテンプレートは次のようになります。

hello-world-sample/
├── Chart.yaml
├── charts
├── templates              # テンプレート化したい設定ファイルをここに溜める
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   ├── ingress.yaml
│   └── service.yaml
└── values.yaml

ただ、今回の説明ではdeploymentだけあればいいので、次のようにしておきます。

hello-world-sample/
├── Chart.yaml
├── charts
├── templates
│   ├── NOTES.txt
│   ├── deployment.yaml
└── values.yaml

deployment.yamlを書き直します。

# この設定で動くかどうか確認していませんが、設定内容自体は正しいはずです
apiVersion: extensions/v1beta1     # Version
kind: Deployment                   # マニフェストの種類
metadata:
  name: docker-hello-world         # 名前
  labels:
    app: docker-hello-world        # Deploymentのラベル
spec:
  replicas: 1                      # podのレプリカ数
  template:
    metadata:
      labels:
        app: docker-hello-world    # ラベル
    spec:
      containers:
        - name: docker-hello-world # コンテナの名前
          image: {{ .Values.image.repo }}:{{ .Values.image.tag }} # イメージ名とタグ

凄くシンプルなのですが、

image: hello-world:linux

が

yaml: {{ .Values.image.repo }}:{{ .Values.image.tag }}

に変わりました。別途values.yaml というファイルに、実際に入れる値を記入します

image:
  repo: hello-world
  tag: linux

ローカル環境からkubernetesに対して設定を適用するためには

$ helm install ./hello-world-sample --name=hello-my-sample

とすれば完了です。helm createコマンドではじめに作られるvalues.yamlはデフォルト設定を記述しますが、値を切り替えたい場合は次のようにします。仮に、another-values.yamlというファイルに別の設定を書いた場合、

$ helm install -f ./another-values.yaml ./hello-world-sample --name=hello-my-sample

# アップグレードする場合は、helm upgradeコマンドを使用します
$ helm upgrade hello-my-sample -f ./another-values.yaml ./hello-world

とすれば適用できます。設定ファイルだけを切り替えるだけで良いので、例えばブランチ名をprefixとしてvalues.yamlファイルを切り替えるなどするとCIの設計が簡単になります。

次にやること

テンプレート化が完了すると非常に開発効率が上がります。それに伴い、様々なことが自動化しやすくなるので次のことをやっていくといいでしょう。

KubernetesのNamespaceの設計
Githubのブランチ名の設計(KubernetesのNamespaceと対応させる等)
CIツールでデプロイ/テストフローの設計
Helmのホスティング(Public/Private)
Helm以外のツールを探す(参考資料)

つまり、デプロイフローの設計を行うことで、開発ルールの全般的な設計ができるようになります。

参考資料

2. 組み合わせ

主にGCPのサービスとの組み合わせの話です。今回、Container BuilderとCloud SQL、Cloud Storageを中心としたざっくりとした話をしました。

Kubernetesと何をどう連携させていくか、というのをかる〜〜〜く説明したスライドになっています。ちょっとだけ補足説明を加えておきます。

Container Builder

120回/1日までBuildが無料でできます（超えたとしても小額）。ただ、Buildが成功したかどうか通知させたいとき、そのイベントをPub/Subの方に投げられるので、それをトリガーにCloud FunctionからSlackに通知を投げさせています。

Cloud Storage

データの永続化と言われれば、必ず出てきますが、今回はhelmのPrivateホスティングで利用しました。 helmのパッケージはChartと呼ばれますが、Chartはウェブ上で公開することが可能です。例えば次のようにbitnami/chartsをhelmの探索リポジトリとして加えることができます。

$ helm repo add bitnami-incubator https://charts.bitnami.com/incubator

ただ、やはり構成管理とかはPrivateにしておくべきものです。Google Cloud Storage(GCS)でそれが可能です。 viglesiasce/helm-gcsという非公式のプラグインが存在します。実際に使うときは、これをほんの少しだけ改造してGCSにhelmをホスティングし、 gcloud authで認証を通した後にhelmから自前のchartを呼び出せるようにしています。

一貫してGCPを使う場合におすすめです。

Cloud SQL

これ、本当はもうちょっとサービスの内容を語りたかったのですが、本題とそれてしまうので、さくっとchartsを紹介するだけになってしまいました。

何を話たかったかというと、Cloud SQLってそれだけで従量課金なんですよね(当たり前だろ、と思う人はすみません)。以外に一番低いインスタンスを立ち上げても数千円飛んでいってしまうと。それに、PostgreSQLはベータ版です。

要件にも依るのですが、実験的にDBを使いたい場合などPodにMySQLサーバーやPostgreSQLサーバーを立ち上げて、 Persistent VolumeをマウントさせたほうがGKEの稼働料金のみで済むということです。無論、その分のスペックは持って行かれますが。

kubernetes/chartsには

が存在します。つまり、

$ helm install stable/postgresql --name=test-psql

とするだけで、Persistent Volumeの要求が自動的に行われ、

$ helm delete --purge test-psql

とすれば、Persistent Volumeごと削除されます。ここで伝えたい内容が2つ有ります。

1. Cloud SQLを使わなくてもいいかもしれない例

例えばですが、redashはユーザー管理にPostgresを利用しています。使い方にもよりますが、分析系は内部の人間のみしか使わないので、Cloud SQLは必要ない、と判断できなくもありません。

2. KubernetesのVolumeの勉強になる

kubernetes/charts - MySQLを見てみると分かるのですが、 Persitent Volume Claim(PVC)の設定しか記述がありません。

Persistent Volume(PV)はただのボリュームで、 PVCはPVを要求するためだけのものです。PVCの設定でstorageClassNameを明示的に記入した場合、既存のPVが要求されますが、無記名("")、の場合、ランダムな名前のPVがGCSに生成されてマウントされます。

つまり、AWSのS3やAzureなどのボリュームをマウントしたい場合、予めPVで作成しておき、PVCはstorageClassNameでPVを参照することをするだけでよくなります。

次にやること

プロダクトとサービス - Google Cloud Platformを可能な限りたくさん触る
Volume関連
- CLOUD DATA TRANSFER
- StatefulSet Basics

GKEとその他のサービス連携は

コンテナを利用するだけで解決できるもの(helm installで終わりなど)
Kubernetesのマニフェストを書き換えるだけで解決できるもの(Volume関連)

と区別できると思います。やはり、それを知るためにはいろいろと試してみることが手っ取り早いので、スキマ時間にチュートリアルをバンバンやっておきましょう(自戒)。

3. 周辺ツール

GCPのアイコンセットと、draw.ioは知っておくと便利ですよ〜、というぐらいです。

komposeはdocker-composeからkubernetesのマニフェストに移行する時に使う程度

https://github.com/kubernetes/kompose

docker edge版を利用するとkubernetes環境がローカルに手に入るのも知っていれば、そうだね、という程度のもの。デフォルトでkubernetesが使えるのはうれしいですね。

https://www.docker.com/kubernetes

4. 情報源

ただのサイト紹介程度です。古くなっていたらTwitterでぼやいていただけると....

スライド中のリンク

日本語の資料

Kubernetesに入門したい by Hiroaki ONO Kubernetesの用語など、図付きでわかりやすく説明されています。

発表系

カテゴライズした記事を別途用意しようかなと思います。

終わりに

GCPUGの運営の皆さん、お疲れ様でした、そして、ありがとうございました。 gcpugのslackはいつも見ていますが、ためになる情報ばかりで勉強になります。

GCPはまだまだひよっこですが、初めて触ってるときにしかわからないつまづきなどを共有して、色んな人と情報交換できるようなればいいなと思って発表しました。

開発者が消耗せず、よりクリエイティブなことができる世界に貢献できていれば幸いです。おわり。

GCPUGの情報

はじめに​

GKEを使う時に必要な知識​

それぞれの章について​

1. Helm​

helmを使わない場合の例​

helmを使った場合の例​

次にやること​

2. 組み合わせ​

次にやること​

3. 周辺ツール​

4. 情報源​

終わりに​

はじめに

GKEを使う時に必要な知識

それぞれの章について

1. Helm

helmを使わない場合の例

helmを使った場合の例

次にやること

2. 組み合わせ

次にやること

3. 周辺ツール

4. 情報源

終わりに