この Helm 完全ガイドでは、Helm の概要とユースケースに加え、Kubernetes プロジェクトに Helm を導入するメリットなどを詳しく解説します。
Helm とは？
Helm とは、Kubernetes 設定ファイルを 1 つの再利用可能なパッケージにまとめて、Kubernetes アプリケーションの作成、パッケージ化、構成、デプロイを自動化するツールです。
マイクロサービスアーキテクチャでは、アプリケーションが成長するほどマイクロサービスの数が増え、管理が難しくなっていきます。オープンソースの コンテナオーケストレーション テクノロジーである Kubernetes を使うと、複数のマイクロサービスを 1 つのデプロイにまとめて、プロセスを簡素化できます。しかし、開発ライフサイクルを通じて Kubernetes アプリケーションを管理する際にも、バージョン管理、リソース割り当て、更新、ロールバックなど、特有の課題がいくつも発生します。
このような問題の最も手軽な解決策の 1 つが Helm です。Helm を使うと、デプロイの一貫性、再現性、信頼性を高めることができます。
Helm を使用した Kubernetes 管理の簡素化
コンテナは、アプリケーションとその依存関係を 1 つのイメージファイルにバンドルした軽量なソフトウェアコンポーネントです。コンテナは異なる環境間の移植性に優れているため、アプリケーションの起動時間を短縮し、素早くスケーリングできます。
Kubernetes のデプロイには、YAML 設定ファイルを使用します。デプロイが複雑で頻繁に更新が行われる場合、これらのファイルのバージョンすべてを追跡するのは困難です。Helm は、デプロイ用 YAML ファイル 1 つとバージョン情報を管理する便利なツールです。このファイルを使うと、複雑な Kubernetes クラスタを少しのコマンドでセットアップおよび管理できます。以降のセクションでは、Helm のさまざまなコンポーネントを確認してから、それらを活用して Kubernetes 管理を簡素化する方法について説明します。
Helm chart とは？
Helm chart とは、アプリケーションを Kubernetes クラスタにデプロイするのに必要なリソースをすべて含んだパッケージです。パッケージには、デプロイ、サービス、シークレット、および所定のアプリケーションの状態を定義した構成マップの各種 YAML 設定ファイルが含まれます。
Helm チャートはこれらの YAML ファイルとテンプレートをパッケージ化したものであり、これらを使うことで、パラメーター化した値に基づいて追加の設定ファイルを生成できます。こうしたしくみのため、さまざまな環境に合うように設定ファイルをカスタマイズしたり、複数のデプロイに再利用可能な設定ファイルを作成したりできます。さらに、各 Helm チャートは個別にバージョン設定と管理ができるため、設定の異なる複数バージョンのアプリケーションを簡単に管理できます。
config ファイル
config ファイルにはアプリケーションの設定が含まれ、通常は YAML ファイルに保存します。Kubernetes クラスタのリソースは、この値に基づいてデプロイされます。
リリース
チャートを実行するインスタンスのことを、リリースと呼びます。helm install コマンドを実行すると、config ファイルとチャートファイルが取得され、すべての Kubernetes リソースがデプロイされます。
アーキテクチャ
Helm のコンセプトを把握したところで、次は Helm のアーキテクチャを見てみましょう。Helm のアーキテクチャには、クライアントとライブラリという 2 つの主要なコンポーネントがあります。
Helm クライアントは、ローカルでのチャート開発やリポジトリとリリースの管理を行うためのエンドユーザー用コマンドラインユーティリティです。MySQL コマンドの実行に MySQL データベースクライアントを使うように、Helm コマンドの実行には Helm クライアントを使います。
Helm ライブラリは、メインの処理をすべて担います。このライブラリには、Helm コマンドで指定された処理を実行するための実際のコードが含まれています。Helm ライブラリによって、config とチャートファイルの組み合わせが処理され、リリースが作成されます。
Helm アーキテクチャは、バージョン 2 から 3 にかけて大幅な改良が加えられました。バージョン 2 では、Tiller サーバーを使って Helm クライアントと Kubernetes API サーバーを仲介していました。また、Helm で作成したすべてのリソースを追跡していました。バージョン 3 では、クライアントのみのアーキテクチャを志向して Tiller サーバーが取り除かれ、API 直接接続で Kubernetes API サーバーとやり取りするようになりました。
Helm のしくみ
Helm アプリケーションライブラリでは、チャートを使用して Kubernetes アプリケーションの定義、作成、インストール、アップグレードを行います。Helm チャートを使用すると、クラスタを制御するために Kubernetes コマンドラインインターフェース (CLI) を使う必要も、複雑な Kubernetes コマンドを思い出す必要もなく、Kubernetes マニフェストを管理できます。
Helm が役に立つ現実的なシナリオを考えてみましょう。本番環境に、10 個のレプリカを持つアプリケーションをデプロイしたいとします。この仕様をアプリケーションの YAML ファイルで指定し、kubectl コマンドを使ってデプロイを実行します。
次は、同じアプリケーションをステージング環境で実行します。ただし、ステージング環境には 3 つのレプリカが必要であること、ステージング環境では内部アプリケーションビルドを実行することが要件です。この場合は、デプロイ用 YAML ファイルのレプリカ数と Docker image タグを更新し、更新後のファイルをステージング Kubernetes クラスタで使用します。
アプリケーションが複雑になるほど、YAML ファイルの数は増えます。結果として、YAML ファイルの設定フィールドも増加します。1 つのアプリをさまざまな環境にデプロイするために多数の YAML ファイルを更新していたのでは、すぐに行き詰ってしまいます。
Helm を使うと、環境に応じてフィールドをパラメーター化できます。前の例で言えば、レプリカ数と Docker イメージに静的値を指定せずに、それらの値を別のファイルから指定します。別のファイルとは、values.yaml です。
このしくみを利用すると、環境ごとに values ファイルを用意して、それぞれのファイルに適切な値を設定するだけで済みます。Helm では、実際の YAML 設定と、設定フィールドの値の管理を分離できるのです。
Helm リポジトリ
Helm リポジトリは、Helm チャートをアップロードする場所です。プライベートリポジトリを作成して、組織内でチャートを共有することもできます。Artifact Hub という、さまざまな用途のチャートを検索してインストールできる機能を備えたグローバル Helm リポジトリもあります。端的に言えば、Docker イメージにとっての Docker Hub が、Helm チャートにとっての Artifact Hub です。
Helm を使ったデプロイとロールバック
Helm チャートを作成したら、アプリのデプロイは簡単に行えます。Kubernetes リソースすべてをデプロイするのに必要なのは、2 ～ 3 個の Helm コマンドを実行することだけです。
実際の例を考えてみましょう。Helm チャートを使ってデプロイした Kubernetes クラスタで、アプリケーションを実行中であるとします。このアプリケーションに、Prometheus のような監視ソリューションを構成しましょう。選択肢は以下の 2 つです。
- Prometheus アプリケーション用のデプロイとサービスのすべてをゼロから作成する: 時間がかかります。
- Artifact Hub で Prometheus チャートを探し、自分の要件に応じて設定を更新して、インストールする: Docker Hub で既存の Docker イメージ探し、Dockerfile の
FROMステートメントに指定するのと同様です。
以下の手順で、任意の Helm チャートをインストールできます。
- Helm チャートの取得元の場所を Helm ライブラリが特定できるように、Helm リポジトリをローカルに登録する
- 設定したリポジトリで使用可能な Helm チャートすべてをフェッチする
values.yamlファイルを (必要に応じて) 更新し、helm installコマンドを使用して特定の Helm チャートをインストールする
Helm を使用するもう 1 つのメリットは、ロールバックプロセスが簡単になることです。
Helm はアプリケーションレベルで動作します。つまり、実行中のアプリケーション (「リリース」) の状態が維持されます。アプリケーションの新バージョンをデプロイしたが、期待どおりに動作しない状況を考えてください。helm rollback コマンドを使うと、以前の安定したリリースに戻すことができます。このコマンドは、すべてのデプロイ、サービス、Kubernetes リソースをロールバックします。
Helm がなければ、これほど簡単にロールバックを行うことはできません。Kubernetes リソースごとにロールバックを行う必要があるので、複雑なアプリケーションの管理が難しくなります。
Helm と CI/CD
Helm を活用すると、継続的インテグレーション & 継続的デリバリー (CI/CD) パイプラインでの Kubernetes アプリケーションのビルドとテストが大幅に簡単になります。アプリケーションを任意の環境に自動でデプロイして、ビルド時間を短縮できます。パイプラインでセルフホストランナーを使えば、ビルド環境とテスト環境の柔軟性を高められます。
CircleCI のセルフホストランナー を使うと、ユーザーが管理する環境で CI/CD ジョブを実行できます。つまり、スタンドアロンの仮想マシンや、Kubernetes のようなクラスタ全体を実行環境として使えます。コンテナランナーを使うと、Helm チャートを使い、コンテナ化したワークロードをプライベート Kubernetes クラスタにデプロイし、ニーズの程度に応じて環境をスケーリングできます。
Helm を使うメリットとデメリット
Helm には、使うと効果を発揮するユースケースと、そうでもないユースケースの両方があります。このセクションでは、Helm が役立つユースケースと役立たないユースケースを確認し、Helm が役立つかどうかを見分けるポイントをいくつか示します。
Helm が適しているケース
Helm は、多数のマイクロサービスを含む複雑なアプリケーションを Kubernetes で実行するプロジェクトに有効です。Helm を使うと、アプリケーションのデプロイと管理を簡単に自動化して、手作業を減らし、システムの信頼性と安定性を改善できます。また、事前構成済みのパッケージが数多く揃ったリポジトリを利用できるため、アプリケーションへの新機能追加が簡単になります。
Helm を使い、インストールおよびアップグレードしやすいモジュール型のチャートにアプリケーションのコンポーネントを整理すると、アプリケーションコンポーネントの管理プロセスを簡素化できます。また、アプリケーションの保守に必要な手作業の量が減るので、複雑なシステムを手動で管理する際に発生しがちなエラーや不統一を回避できます。
Helm は、複数環境 (開発、ステージング、本番など) へのコンテナのデプロイもサポートしているので、開発プロセス全体を通じたコンテナのライフサイクル管理が簡単になります。
Helm が適していないケース
Helm は、サーバーにデプロイする必要があるコンテナが 1 つだけのプロジェクトには向いていません。この場合、コンテナのデプロイの管理を Helm で行う必要はなく、Helm を使うとかえってプロセスが複雑になる可能性があります。Helm は複数のコンテナデプロイを 1 単位として管理するために作られており、このシナリオでは効果を発揮しません。
少数の Kubernetes アプリケーションを、パッケージマネージャーを使わずに手動で管理できている場合も、Helm に大きなメリットはありません。
また、Helm などのサードパーティツールの使用を禁止する厳しいセキュリティポリシーが定められている環境では、そもそも Helm を使うことはできないでしょう。
Helm を導入する理由
プロジェクトに Helm を使うとメリットがあるかどうかを見分けるポイントはいくつかあります。たとえば、まとめて管理、デプロイする必要のある複数の Kubernetes アプリケーションがプロジェクトに含まれているケースです。この場合、Helm を使ってそれらのアプリケーションを 1 つのチャートにパッケージ化すると、まとめて管理およびデプロイしやすくなります。
プロジェクトで Kubernetes アプリケーションの更新とデプロイを頻繁に行うケースも、Helm が役立ちます。Helm には、アプリケーションのライフサイクル (デプロイ、更新、ロールバックなど) を管理するツールが揃っているからです。そのため、アプリケーションの更新の管理とデプロイがずっと簡単になります。
最後は、プロジェクトに複数のチームやメンバーが携わり、Kubernetes アプリケーションの開発とデプロイを共同で行う必要があるケースです。この場合、Helm のバージョン管理機能とチャートの共有機能が役立ち、チームの共同作業や、デプロイ間の一貫性の維持が簡単になります。
まとめ
この記事では、Helm の概要と、Helm によって Kubernetes のデプロイを簡素化するしくみを説明しました。また、Helm チャート、リポジトリ、デプロイなど、Helm の中核的なコンセプトについても紹介しました。
Helm は、複数のコンテナのデプロイを 1 つの単位として管理できる有益なツールです。Helm を使う主なメリットは、複雑なマイクロサービスベースアプリケーションのデプロイを簡単に管理する機能、一貫した体系的な方法でデプロイプロセスを管理する機能、複数環境へのコンテナのデプロイを管理する機能が用意されていることです。これらの機能を備えた Helm は、コンテナベースのアプリケーションを使う組織にとって欠かせないツールです。
今回学んだ知識があれば、Helm を利用してアプリを Kubernetes にデプロイする準備は万端です。Helm をインストールして最初の Helm チャートを作成する方法は、こちらのクイックスタートガイドを参照してください。また、Helm リポジトリに自分のチャートをアップロードして、コミュニティと共有してみてください。
