Zeals TECH BLOG

チャットボットでネットにおもてなし革命を起こす、チャットコマース『Zeals』を開発する株式会社Zealsの技術やエンジニア文化について発信します。

Kubernetesにおけるmanifestファイル, imageの管理について

f:id:zeals-engineer:20190603114959p:plain

こんにちは、CTOの島田です。

弊社サービスであるfanpでは、定期バッチ含む全サービスがGKE上で起動しています。

今回は Kubernetesのmanifestファイルやイメージを効率よく管理するための取り組みを紹介したいと思います。 Kubernetesを本番運用しているところだと基本的なことが中心の内容かと思いますが、お付き合いいただけますと幸いです。

Kubernetes化にあたって意識したこと

環境の差異, manifestの再利用性

  • ステージング環境とプロダクション環境でそれぞれ異なる環境変数が定義されている
  • ステージング環境はプロダクション環境よりも少ないマシンリソースで運用したい

一方で、

  • 同じようなmanifest fileを大量に書きたくない
  • 別サービスの同環境で同じsecretを使いまわしたい

という思いがありました。

後者はcloud_sql_proxyのコンテナ起動に使用するJSONデータなどが該当するかと思います。
(複数サーバーで同一DBを参照する場合)

CD(Continuous Delivery)の効率化

数分で完了するデプロイ、大して複雑でないパイプラインを構築する上で、極力シンプルなCDツールを目指すことにしました。
CDツールを自分たちで構築/運用した場合, 定期的なバージョンアップも行わなければいけなかったりと手間がかかってしまいます。

また, 未だにKubernetesにおいてCDツールのデファクトは存在しないと考えています。
そのため、ツール依存の設定が増えてJenkinsおじさん的な事象が発生するのは避けかったという意図もありました。 

ZEALSでの取り組み

container registry専用のprojectを作成した

アプリケーションのコードを元にbuildしたimageを置くためだけのprojectです。
このcontainer registryでは環境依存のものは配置せず、再利用可能なイメージのみを設置します。

GCPは権限の設定がとても楽です。
Cloud Buildで別projectにあるContainer Registryからimageをpullするのも, Cloud Buildのサービスアカウントをcontainer registryのあるprojectに追加し, ストレージ オブジェクト閲覧者を付与したら動作します。

manifest file専用のレポジトリを作成した

全サービスのmanifest fileを1つのレポジトリに集約させました。
特徴は以下の通りです。

ディレクトリはざっくりこんな感じになりました。

.
├── bin/
│   └── gen_kustomize.sh
├── service1/
│   ├── base/
│   │   ├── deployment.yaml
│   │   ├── kustomization.yaml
│   │   └── service.yaml
│   └── overlays/
│       ├── fanp-prd/
│       │   ├── deployment.yaml
│       │   └── kustomization.yaml
│       └── fanp-stg/
│           ├── deployment.yaml
│           └── kustomization.yaml
├── service2/
│   ├── base/
│   │   ├── deployment.yaml
│   │   ├── kustomization.yaml
│   │   └── service.yaml
│   └── overlays/
│       ├── fanp-prd/
│       │   ├── deployment.yaml
│       │   └── kustomization.yaml
│       └── fanp-stg/
│           ├── deployment.yaml
│           └── kustomization.yaml
├── secrets/
│   ├── prd/
│   │   ├── kustomization.yaml
│   │   ├── secret-hogehoge.yaml
│   ├── stg/
│   │   ├── kustomization.yaml

Cloud Buildで継続的デリバリ

結果的にCloud Buildを使用しました。
Cloud Buildの使いところは、アプリケーションのimage build各環境へのデプロイ になります。 デプロイまでの流れは以下です。

  1. 各アプリケーションでgit tagを打ち、リモートリポジトリにtagをpush
  2. container registry専用のprojectにあるCloud Buildが発火, imageをbuild
  3. manifest専用レポジトリでimage tagを編集, deployブランチへプルリクを出す
  4. 3.のプルリクがマージされたら任意のprojectCloud Buildが発火しデプロイ

ZEALSではstgへのdeployブランチにマージされたらステージングのprojectのCloud Buildが発火、masterへマージされたらプロダクションのCloud Buildが発火し、デプロイが開始するようになっています。

さいごに

動きました!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Kubernetesの導入経緯については、ZEALSにテクノロジーお師匠さんとして携わっていただいている元株式会社MUGENUP CTOの横山師匠に対談をしていただきました。よろしければ、そちらもぜひご覧ください!

flxy.jp

flxy.jp