今回は、GitOpsに関しての記事を書きます。長い記事なので、前半と後半の2つに分けて投稿いたします。今回は後半です。この投稿では、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を使わない)

2. GitOpsを使う (Helmを使わない)

3. HelmとGitOpsを併用する

これらの異なるアプローチをコードベースの観点から検討したい場合は、GitHubのサンプルプロジェクトを参照してください

GitHub にあるサンプルプロジェクトで、この方法をより深く掘り下げています。

  • Helm を使ってアプリケーションをインストールし、ローカルにデプロイする
  • Argo CD でアプリケーションをインストールし、UI とコマンドラインの両方でローカルにデプロイする。

異なるアプローチをコードベースの観点から検討したくないという方は、以下にこれらのアプローチを紹介します!

アプローチ#1: GitOpsを使わずにHelmだけを使う

Helm を使いたいけれども、まだ GitOps のワークフローを導入する準備ができていないという場合でも、まったく問題ありません。HelmはGitOpsの方法論が実現する前に作られましたが、それでもGitOpsと連携することができます(後述します)。

このワークフローでは、Helm リポジトリからチャートを検索してクラスタにインストールし、リリースを作成することができます。このプロセスにより、クラスタ上でアプリケーションのデプロイメントを実行することができます。KubernetesオブジェクトのYAMLマニフェストのメンテナンスは従来通りです。Helmリリースは、各チャートのインストールと変更のバージョン履歴を追跡するもので、以前のクラスタバージョンへのロールバックも引き続き可能です。チャートをインストールすると新しいパッケージのリリースが作成され、HelmアプリケーションをデプロイするのはこのHelmリリースです。

Helmを使用する際に便利な強力なコマンドがいくつかあります。

新しいパッケージをインストールするためには:

helm install  

現在デプロイされているリリースを表示するには:

helm list

もしくは

helm ls

特定のリリースのリビジョン番号を表示するには

helm history 

これらのコマンドの詳細や使用方法については、GitHubのサンプルプロジェクトを参照してください。

アプローチその2:Helmを使わずにGitOpsを使う

GitOps のアイデアに納得したのなら、Helm を使えない場合や使わない場合に使える代替ツールがあります。

ArgoCD を単体で使用することができます。これはかなり柔軟で、他のテンプレート化ソリューションや、プレーンなマニフェストでも動作させることができます。Helmの代わりに使える別のテンプレート化ツールにKustomizeがあります。このツールはkubectlに組み込まれており、Kubernetesにネイティブです。Kubernetes APIリソースファイルのみを使用して、Kubernetesのコンフィギュレーションをカスタマイズすることができます。

では、3つ目のアプローチとして、HelmとArgo CDを使ってGitOpsを実現する方法を探ってみましょう…。

アプローチ#3: Helm と GitOps の併用

GitOps を Helm なしで適用する方法について見てきましたが、次は Helm と一緒に GitOps を使う方法について見ていきましょう。

まず、Helmのチャートとアプリケーションの変更は、クラスタに適用される前にGitでコミットする必要があります。つまり、YAML形式のワークロード定義、Helmチャート、そしてクラスタの望ましい状態を定義するその他のKubernetesカスタムリソースをすべてレポにコミットする必要があるのです。こうすることで、ロールバックやログにアクセスでき、本番の状態を簡単に復元することができます。

Argo CD 内では、HTTPS を使って Git リポジトリに接続し、URLを直接追加することができます。これにより、自動同期を有効にして、クラスタをGitリポジトリの希望の状態に自動的に同期させることができます。同期に成功すると、アプリケーションの状態はHealthyと認識されます。そうでない場合、アプリケーションが OutOfSync になっていれば、ロールバックするかリリース履歴を見ることで問題を解決することができます。

ここでは、Argo CD UIでHealthyなアプリケーションを実現する例を紹介します。

None

アプリケーションの実行中は、そのリソース コンポーネント、ログ、イベント、およびヘルス ステータスを表示できます。

参考までに、Argo CD の UI で、本番状態がターゲット状態から逸脱した場合の OutOfSync アプリケーションのビジュアルを以下に示します。

None

上記の例のように、アプリケーションにエラーが発生したり、OutOfSyncになった場合、アプリケーションのデプロイ履歴を見ることができるargo historyコマンドを実行することができます。

argocd app history 

その後、デプロイメントをロールバックする必要がある場合は、このコマンドを実行することで行うことができます。

argocd app rollback  

基本的に、これらのコマンドは、Gitリポジトリからの追跡を可能にすることで、より速く、よりセキュアなデプロイメントを活用します。また、アクティブなKubernetesリソースやイベントのトラッキングも可能です。

ですから、このようなソース管理の使い方は、このアプリケーションのデプロイメントをGitOpsに分類するものです!

つまり、パッケージ化された Helm チャートを直接接続することができ、Argo CD はその新しいバージョンを監視します。この場合、Helm チャートはもはや Helm チャートとして機能せず、代わりに Argo CD のアプリケーションマニフェストを使用して、Argo をインストールしたときに Helm テンプレートでレンダリングされます。

その後、Argo CD は両方の状態が同一になるまでアプリケーション コンポーネントのデプロイと監視を行います。アプリケーションはもはや Helm アプリケーションではなく、Argo アプリケーションとして認識され、Argo CD によってのみ動作することができるようになります。したがって、helm list コマンドを実行すると、Helm メタデータはもはや存在しないので、helm リリースを表示することはできないはずです。

以下はコマンド出力の例です。このように、Argo CDアプリケーションはHelmアプリケーションとして検出されません。

None

まとめ

HelmはKubernetesのデプロイでよく使われる強力なツールで、これにより各リリースのトラッキングが可能になります。これにより、開発チームは信頼性の高い、迅速なデプロイを実現できるのです。

そのため、Helmを全く知らない方は、こちらのドキュメントを参考にしてみてください。

- Helmの導入環境

- Helmのベストプラクティス

- KubernetesのHelmデプロイをシンプルにする方法

次回は、開発システムやインフラシステムに GitOps プロセスを導入する際に役立つその他のツールについて説明します。

Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。