最近の適当な覚書
k8s を使っていた。調べた一部しか実際には使わなかったので項目だけでもメモしとく。 調べた範囲が広くて、時間をかけて書く気が起きないので列挙で済ませる。 空いた時間はアルゴリズムとかトランザクションとか英語とか子供と遊ぶとかとか友達と会うとか他のことに当てたい。
要望
元々GCP Cloud Buildでステージング環境がGKEクラスタ上に自動構築されていた。 即興で作られて放置されていて一部の機能しなかったりと不完全な状態だった。 で、色々と開発や検証を楽にしたいし直してって話が来た。 大きな要望は本番環境と(ほぼ)同じデータでステージング環境を構築する。
- 本番環境に近いステージング環境がGitブランチごとに欲しい
- ステージング環境の構築に時間かけない
- QAはmasterブランチに対応させる
- QAはCloud SQLを利用する
- HTTPSは大事
- どの環境もデータベースの内容は本番を追いかける
あたり。
やったこと
実現しました。おしまい。色々と調べたり悩んだけれど、やってしまえば難しくない。 k8s 便利だ。サービスメッシュとか試してないけれど、それぞれのプルリクに対応した環境が作られ不要になれば破棄される。めでたしめでたし。
一番悩んだのは k8s マニフェストの管理場所。いまのところデプロイパイプライン専用ツールは検討していない。 そもそも、まだ普通に k8s の環境実現が完成していないのとツール慣れが足りなくて観点が整理できなかった。 なので Cloud Build で押し通した。
k8s のマニフェストの置き場所
候補は2つ。
- 開発対象のリポジトリに含めて各環境の定義はそれぞれのブランチに対応させる
- アプリケーションと紐づくコンテナの利用仕方を一緒に管理できる
- 開発対象のリポジトリと分けて管理して、各環境はディレクトリに対応させる
- 全ての環境は単一ブランチ内で横断的に確認できる
いまは2つめで進めている。すでにアプリケーションコードと別れていたのが大きい。 まずはマニフェスト用のリポジトリのコミットヒストリに混乱が少なく、現在の状態が一望できるようにすることにした。
これで安定して、時間に余裕があれば1つ目に近づけるつもり。 やはりアプリケーション・コンテナ定義・Pod定義は一緒に管理したい。
調べたこと
- GCPでディスクを生成する
- GCPディスクをGKEのPersistentVolumeに対応させる
- 存在するブランチ名を使って削除するnamespaceを決定する
- kustomizeでbasesに複数指定する
- kustomizeのpatchは2種類ある
- YAMLのnull(~)を使うとbasesで定義されているリソースの属性を削除できる
- ACMEのDNS-01チャレンジだとワイルドカード証明書を発行できる
- cert-manager 便利で色々なDNSサービスに対応している
- ingress-nginx でデフォルトTLS証明書を上書きでワイルドカード証明書を利用した
- RBACはGCPのIAMに似てる
- GCPのロールをGKEのサービスアカウントに付与できる(beta)
- Podのコンテナ定義でメモリやCPUにlimitを付けるの大事
- Helmは簡単で便利だけど、数コンポーネントのためだけに採用する気は起きない
- 久しぶりにデバイスまっぱとかLVMとか調べた(使わなかったけど)
感想
なんとなく繋がったりしてるけど、アップアップしてて消化できてない。早く定着させたい。