はじめに
ビットキーで bitkey platform を開発しています otakakot です。
以前、 CloudNative Days Tokyo 2023 での登壇や記事にて bitkey platform の DevOps について紹介しました。
これらは Kubernetes (ArgoCD) を使っている前提の話です。
しかし、リリースするものがすべてコンテナでよしなにできるわけではありません。
管理方法によると思いますが、フロントエンドのリソースなどはコンテナとして扱わないこともあるかと思います。
このようなリソースをみなさんはどのようにリリースしているでしょうか？
デプロイ先に CLI ツールで（コマンド操作して）リリースすることになると思います。
こちらのコマンド、どのタイミングで実行しますか？
bitkey platform では ArgoCD のリリースフローの流れと同一となるようにフロントエンドのリリースを工夫しています。
リリースの流れを同一にしておくことでリリース時の認知負荷の低減が期待できます。
（管理コストは増えるかもしれませんが ... ）
そんな bitkey platform でのフロントエンドのリソース管理についてご紹介します。
※ 現在、記事を執筆しつつフローも修正している箇所もあるのですべてがこの通りではありません。ご了承ください。
前提知識 : GitOps と CIOps
デプロイ方式として GitOps と CIOps という形式があります。
詳しい話は以下の記事をご参考いただきたいです。
今回紹介するフロントエンドのリリースは ArgoCD のように管理するので GitOps かと思われるかもしれませんが、 CIOps にあたります。
リポジトリ
ざっくりと bitkey platform が管理するリポジトリは下記の通りです。
- resource ( Go コード や フロントエンド が複数 )
- manifest ( Kubernetes マニフェスト )
ArgoCD は manifest リポジトリを監視し GitOps にて各環境へと自動でリリースしています。
bitkey platform の環境
bitkey platform は以下の環境を管理しています。
| 環境名 | environment | 用途 |
|---|---|---|
| 開発 | develop | bitkey platform 開発用 |
| ステージング | staging | ビットキー社内開発/検証用 |
| 本番ミラー | production-mirror | リリース前最終検証用 |
| 本番 | production |
ArgoCD を使った DevOps
ざっくりと GitHub リポジトリと GitHUb Actions, ArgoCD の関係を図にすると下記のようになります。
各環境にリリースされるまでの流れは以下の表の通りです。
表の項目は左から
- Step
- Which ... どのリポジトリで
- When ... どのタイミングで
- What ... どんなことをして
- To ... 次の Job 呼び出し先リポジトリ
で整理しています。
開発環境
| Which (Repo) | When | What (Job) | To (Repo) | |
|---|---|---|---|---|
| 1 | resource | on push (main merge) | コンテナデリバリー, repository_dispatch | manifest |
| 2 | manifest | repository_dispatch | マニフェスト更新 | - |
ステージング環境
| Which (Repo) | When | What (Job) | To (Repo) | |
|---|---|---|---|---|
| 1 | recource | cron | タグ作成 | resource |
| 2 | resource | on push (tag trigger) | コンテナデリバリー, repository_dispatch | manfiest |
| 3 | manifest | repository_dispatch | マニフェスト更新 | - |
本番ミラー環境
| Which (Repo) | When | What (Job) | To (Repo) | |
|---|---|---|---|---|
| 1 | manifest | repository_dispatch | マニフェスト更新 | - |
※ ジョブの詳細は以下の記事をご参照ください。
本番環境
| Which (Repo) | When | What (Job) | To (Repo) | |
|---|---|---|---|---|
| 1 | scheduler | cron | create tag | resource |
| 2 | resource | on push (tag trigger) | コンテナデリバリー, repository_dispatch | manifest |
| 3 | manifest | repository_dispatch | マニフェスト更新 | - |
ArgoCD に合わせたフロントエンドの DevOps
ここから本題である ArgoCD に合わせたフロントエンドの DevOps について示します。
ArgoCD と同様に、ざっくりと GitHub リポジトリと GitHUb Actions、 ホスティング先である Firebase の関係を下記のように図として示します。
ArgoCD のときにはなかった scheduler が登場していますが、 resource で cron トリガーを引いていた GitHub Actions が移動しただけです。責務を分けたかったのでこのように整理しています。
開発環境
| Which (Repo) | When | What (Job) | To (Repo) | |
|---|---|---|---|---|
| 1 | resource | on push (main merge) | repository_dispatch | manifest |
| 2 | manifest | repository_dispatch | マニフェスト更新 | - |
| 3 | manifes | on push (main merge) | リリース | - |
ステージング環境
| Which (Repo) | When | What (Job) | To (Repo) | |
|---|---|---|---|---|
| 1 | scheduler | cron | タグ作成 | resource |
| 2 | resource | on push (tag trigger) | repository_dispatch | manfiest |
| 3 | manifest | repository_dispatch | マニフェスト更新 | - |
| 4 | manifes | on push (main merge) | リリース | - |
本番ミラー環境
| Which (Repo) | When | What (Job) | To (Repo) | |
|---|---|---|---|---|
| 1 | manifest | repository_dispatch | マニフェスト更新 | - |
| 2 | manifest | on push (open pr) | リリース | - |
本番環境
| Which (Repo) | When | What (Job) | To (Repo) | |
|---|---|---|---|---|
| 1 | scheduler | cron | タグ作成 | resource |
| 2 | resource | on push (tag trigger) | repository_dispatch | manifest |
| 3 | manifest | repository_dispatch | マニフェスト更新 | - |
| 4 | manifest | on push (main merge) | リリース | - |
リリース方法
ArgoCD と異なり、フロントエンドは manifest リポジトリの GitHub Actions にて直接リリース用のコマンドを実行しています。
何か特別なことをしているかと言われるとそんなことはなく、ただ manifest リポジトリにデプロイの責務を寄せているだけです！
一方で現在困っているのがリリースのコマンドを誰が知っておくべきかということです。
デプロイの責務を manifest リポジトリに寄せていますが、現状はフロントエンドを管理するリポジトリにコマンドを記載しておき manifest リポジトリにて該当リポジトリを clone して実行しています。
このコマンドを manifest リポジトリに記載すべきかフロントエンドを管理するリポジトリに置いておくべきかは迷っています。
順番制御の自動化はできていない
フロントエンドは上流下流を考えると一番最後にリリースするかと思います。
バックエンドは後方互換性を保つために最初にリリースしていきます。
本番環境においては、 PR をマージしたタイミングでリリースが動き出します。
（本番環境以外は厳密にコントロールしていません。）
ArgoCD で完結することができればコントロールは可能になりますが、CIOps も加わってくるとコントロールができません。
リソースごとのマニフェスト更新 PR を個別に設定しておけばマージする順番 = リリースする順番 にコントロールできますが、まだ自動化はできていません。
おわりに
この管理をすることで manifest リポジトリにどのバージョンがリリースされたのか情報を集約することができます。
しかし bitkey platform にはまだ以下のようなリソースがありこの仕組みに集約はできていません。
- Cloud Functions
- Google Cloud Storage
頻繁に発生しないので手動でリリースしていますが、たまにでも手動リリースはめんどくさいです。
これらも自動化に組み込もうと思います。
今回記事を執筆およびフローを整備するにあたり下記のサンプルリポジトリも用意してあります。
詳細な yaml ファイルなどが気になった方はご参照ください。
また、ジョブ起動では必須となる repository_dispatch についても下記の記事を共有しているのでご参照ください。
Discussion