HelmとGitOpsの連携（後半）

今回は、GitOpsに関しての記事を書きます。長い記事なので、前半と後半の２つに分けて投稿いたします。今回は後半です。この投稿では、Kubernetesのパッケージ管理に使用され、テンプレート化も提供するツールであるHelmについて詳しく述べたいと思います。Helmは、Kubernetesアプリケーションのデプロイをサポートするユーティリティを提供します。

GitOpsとは？

GitOps は、アプリケーション開発のワークフローからシステムの運用基盤に至るまで適用されるベストプラクティスを取り入れたパラダイムです。

GitOpsのメリットには、以下のようなものがあります。

- より速く、より頻繁にデプロイできる

- より簡単で迅速なエラー処理とリカバリ

- デプロイメントのセルフドキュメンテーション

- 開発者の生産性が向上し、チームのエクスペリエンスが向上する

- 開発した機能のライフサイクルの可視化

こういったメリットがあるため、アプリケーションの取り扱いが容易になり、チームは高品質のソフトウェアをより早く提供することができます。

GitOpsは、宣言的なコンフィギュレーションとアクティブなリコンシリエーションのための単一の真実のソースとして、Gitに依存しています。GitOpsの手法を採用することで、クラスタにデプロイされたアプリケーションの設定と、Gitに存在するコンフィギュレーションの間に透明性を持たせることができます。

このGitベースのワークフローというアプローチに沿ったGitOpsツールにArgo CDがあります。これはKubernetes用の継続的デリバリーツールで、本質的には双方向の同期を行うGitOpsコントローラです。Argoは実行中のアプリケーションを継続的に監視し、ライブの状態とGitにある望ましい状態を比較し、クラスタに適用します。さらに、コンテナレジストリの新しいイメージを監視し、デプロイメントポリシーに基づきワークロード定義を更新します。

この投稿で再びArgo CDについて触れますが、すでにワークフロー内にインストールされ、導入されていると考えてよいでしょう！

GitOps は既存のすべてのツールと連動する

Helm がどのようなもので、どのような機能を持つのかがわかったところで、GitOps を既存あるいは将来のアプリケーションに適用することを検討したいと思いませんか？

ここでは、GitOpsをHelmと併用する方法と併用しない方法について、様々なアプローチを探ってみましょう。

1. Helmだけを使う (GitOpsを使わない)