Skaffold と Kustomize を使って、マイクロサービスを検証用クラスタにデプロイする

f:id:nmu0:20191022151903p:plain — 引用元: https://raw.githubusercontent.com/GoogleContainerTools/skaffold/master/logo/skaffold.png

テクノロジー開発部の村上です。弊社で現在開発中のシステムは、Kubernetesを用いてマイクロサービスで構築しております。
基本的にはSpinnakerでCDを実施しているのですが、今回は検証用にローカルからデプロイしたい場合にSkaffoldを使う方法を紹介したいと思います。

背景

アーキテクチャ担当者として、ログや認証、他のクラウドサービスとの接続など色々試すことがあります。
しかしその試行錯誤のために、Pull Requestを上げてマージしてとやっていると、手間がかかる上にコミットやPull Requestの履歴が汚れてしまいます。
その一方で、ローカルのみで試すには、環境が違いすぎるのとマイクロサービスではリソースを使いすぎるので非現実的です。
そこで検証用のクラスタを用意して、ローカルからデプロイしたいというのが目的となります。
その際の手間を簡略化するためにSkaffoldとKustomizeを使用します。
ちなみにKustomizeは検証用以外のマニフェスト管理にも一貫して使用していますので、別の機会に詳しくご紹介出来ればと思います。

Skaffoldについて

Skaffold はGoogleが開発したツールで、開発時の、ビルド、マニフェスト作成・変更、デプロイのサイクルを簡略化することが目的となります。
各サイクルで方法をカスタマイズすることが出来、例えばビルドではローカルでビルドするかGCPのCloud Buildでビルドするかなど選ぶことが出来ます。
マニフェスト部分も純粋にKubernetesのマニフェストを書くか、Helmを使うかKustomizeを使うかなどを選ぶことが出来ます。
そのことが公式の図でわかりやすく表されていまして、青い枠が縦軸で揃っている部分は、そのどれかを選ぶことが出来るという意味となっています。

f:id:nmu0:20191022151517p:plain — 引用元: https://skaffold.dev/images/architecture.png

また、開発用に便利な特徴として、ファイルの変更を検知して自動でビルドからデプロイまでを変更箇所に関して行ってくれる機能があります。
Scalaのsbtや、Vue.jsなどで使用するwebpack-dev-serverのホットリロードと同じイメージです。
これを使うと試行錯誤する際に非常に楽になります。

事前準備

Skaffoldを公式のインストールページに従ってインストールするだけとなります。
それに加えてKustomizeやGCPなど、他にSkaffoldと一緒に使用したいソフトウェアやサービスの準備をしておきます。

実践

ページの下に掲載しますが、公式がマイクロサービスの例を用意してくれているので、それを参考にすると良いです。
まず、以下のようなskaffold.yamlファイルを作成します。

apiVersion: skaffold/v1beta10
kind: Config
build:
  artifacts:
  - image: <IMAGE1>
    context: /path/to/repository1
    docker:
      dockerfile: Dockerfile
      buildArgs:
        key1: value1
  - image: <IMAGE2>
    context: /path/to/repository2
    docker:
      dockerfile: Dockerfile
      buildArgs:
        key1: value1
  googleCloudBuild:
    projectId: <PROJECT_ID>
deploy:
  kustomize:
    path: overlays/dev

ポイントは、artifactを複数指定することと、各artifactでcontextを指定することです。
マイクロサービスなので複数artifactが必要となるのと、contextで各マイクロサービスへのリポジトリへのパスを指定する必要があります。
1リポジトリの場合はskaffold.yamlをそのリポジトリのルートに配置すれば、別にcontextを指定する必要はありません。
パスは絶対パスでも問題ないと思いますが、Gitで管理することを考慮して相対パスが良いかと思います。
ちなみにdocker部分は単にDockerfileを使っている場合は不要です。弊社では1リポジトリに複数Dockerfileがあるケースや、buildArgsを渡すケースがあるために指定しています。
最後のdeploy部分で、今回デプロイしたいマニフェストが配置されたKustomizeのoverlayの検証用環境へのパスを指定しています。

この設定を書けば、後は skaffold dev を叩けばビルドからデプロイまでが開始されます。
そして各リポジトリやマニフェストを変更すれば、それを自動検知してホットリロードされます。
実用上のちょっとしたtipsとして、試したい内容に必要な最小構成のマイクロサービスに絞るというものがあります。
マイクロサービスの数が多いとビルドなどに時間がかかるので、手元でskaffold.yamlを編集して調整すると良いと思います。
マイグレーションやシード配布などにKubernetesのジョブを使っているときは、更新がなければそこをコメントアウトするといった調整です。
基本は検証用途なので、手元で色々変えられるのが利点のひとつとなります。

まとめ

いかがでしたでしょうか。私も最初はSkaffoldなしで横着してみたのですが、やはり試行錯誤のたびの手間が大きくてSkaffold無しだと立ち行かなくなりました。
1つの設定ファイルを書くだけで気軽に導入できるので、参考にして頂けたら幸いです。

参考資料

GoogleContainerTools/skaffold/examples/microservices
- 前述したGoogleによる、マイクロサービスでのskaffoldの使用例です
- GoogleContainerTools/skaffold/examplesには他にも色々な例があるのでとても参考になります