こんにちは、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つのレポジトリに集約させました。
特徴は以下の通りです。
- kustomizeを使用, secretsもkubesecで暗号化してgit管理
- overlaysを使用して環境ごとに読み込むsecretsの変更やコンテナのリソース調整を管理
- CronJobも同一テンプレートからスケジュールごとにmanifestを生成(参考: Kustomize で CronJob を同一テンプレートからスケジュール毎に生成する - Qiita)
ディレクトリはざっくりこんな感じになりました。
. ├── 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、 各環境へのデプロイ になります。
デプロイまでの流れは以下です。
- 各アプリケーションで
git tagを打ち、リモートリポジトリにtagをpush - container registry専用のprojectにあるCloud Buildが発火, imageをbuild
- manifest専用レポジトリでimage tagを編集, deployブランチへプルリクを出す
- 3.のプルリクがマージされたら任意のprojectCloud Buildが発火しデプロイ
ZEALSではstgへのdeployブランチにマージされたらステージングのprojectのCloud Buildが発火、masterへマージされたらプロダクションのCloud Buildが発火し、デプロイが開始するようになっています。
さいごに
動きました！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！
Kubernetesの導入経緯については、ZEALSにテクノロジーお師匠さんとして携わっていただいている元株式会社MUGENUP CTOの横山師匠に対談をしていただきました。よろしければ、そちらもぜひご覧ください！
