ビットキー bitkey platform における Argo CD の導入と運用

ビットキーの bitkey platform は認証認可およびスマートロックに欠かせないデジタルキーを管理する機能を提供しています。 我々は DevOps をすべて自分たちで行います。 運用を行う中でリリース作業に課題があったため Argo CD の導入を行いました。

ツール導入前の課題

マイクロサービスごとに Jenkins からスクリプトを用いて kubectl apply (helm update) を実行しデプロイしていました。デプロイ作業はスクリプトだけでなく手作業が必要な箇所もありました。（ときどきリリースに失敗して環境自体を破壊してしまうこともありました）このようなスクリプト管理も含め、リリースに対する認知コストが高い状況でした。

どのような状態を目指していたか

認知コストおよび管理コストが低いリリースおよびロールバックの構築を目指しました。 また、リリースやロールバックにかかる時間の短縮（実30分以内）も目指しました。

• Jenkins による CIOps（既存）
• Argo CD による GitOps
• Flux による GitOps（実際に環境構築をして PoC を行ったわけではないです）

• デプロイ作業の認知コストを抑えられるか
• Web UI によってユーザーフレンドリーに扱えるか

Argo プロジェクトが CNCF を Graduated となったことは後押しとなりました。 The Cloud Native Computing Foundation Announces Argo has Graduated

改善したかった課題はどれくらい解決されたか

• ツール導入前の課題は概ね解消されました

どのような成果が得られたか

• リリース時間が２時間から5分へ短縮されました
• リリーススクリプトの管理および手動リリース作業から解放されました

• (Argo CD を採択したことによる影響ではないですが) Argo CD の環境を本番に構築した際に Load Balancer ( Kubernetes Ingress ) の設定が一部削除されてしまい 404 エラーを引き起こしました
• 開発環境・ステージング環境では上記設定の運用を行なっていなかったため検証できていませんでした

• チームトポロジーにおけるプラットフォームエンジニアリングチームが機能を提供するために Argo CD を採用するのは適していると思いますが、アプリケーション開発チームが運用改善のために Argo CD を採用するのは少々負荷が高い気がしています（ほかのサービスを利用して比較したわけではないです）
• コンテナデリバリーや manifest の更新は各自工夫をする必要があります
• App Of Apps Pattern を知っているとマイクロサービスの依存関係を意識したリリース順を制御できます
• Argo CD のリリースフローに合わせてフロントエンドのリリースも manifest 管理しようとすると複雑度が上がるのでやめた方がよいです
  • 私が以前執筆したArgo CD に合わせたフロントエンドの DevOpsはアンチパターンのため、アンチパターンとしてご参考にしてください
  • 現在はシンプルに CIOps でフロントエンドはリリースしています

ビットキーはメインクラウドとして Google Cloud にてプロダクトを運用しています。 今後、マルチクラウド対応が必要となった場合には Argo CD を活用しているため AWS や Azure AD に環境を構築するとなっても Argo CD を構築することが可能かと思っています。その際には Argo CD を採用していてよかったと感じるかもしれません。 一方で、現在のチーム状況やアプリケーション管理を考えるとそもそも Kubernetes で管理する必要があるのかということも考えています。それに伴い Argo CD からの脱却も視野に入れています。