Helmとは？ Kubernetesプロジェクト管理、ユースケース
Helmとは？
Helmは、Kubernetes構成ファイルを1つの再利用可能なパッケージに統合し、Kubernetesアプリケーションの作成、パッケージング、構成、デプロイを自動化するツールである。
マイクロサービスアーキテクチャでは、アプリケーションが大きくなるほどマイクロサービスの数が増え、管理が難しくなる。オープンソースのコンテナオーケストレーション技術であるKubernetesを使うと、複数のマイクロサービスを1つのデプロイにまとめてプロセスを簡素化できる。しかし、Kubernetesアプリケーションの開発ライフサイクルを管理するときにも、バージョン管理、リソース割り当て、更新、ロールバックなど、固有の問題がいくつも発生する。
これらの問題に対する最も簡単な解決策の一つがHelmであり、Helmを使うとデプロイの一貫性、反復性、安定性を高められる。
Helmを使ってKubernetes管理を簡素化する
コンテナは、アプリケーションとその依存関係を1つのイメージファイルにまとめた軽量なソフトウェアコンポーネントである。コンテナは異なる環境間での移植性が高く、アプリケーションの起動時間を短縮し、すばやく拡張できる。
KubernetesデプロイはYAML設定ファイルを使用する。デプロイが複雑で頻繁に更新される場合、これらのファイルのすべてのバージョンを追跡するのは難しい。Helmは、1つのデプロイ用YAMLファイルとバージョン情報を管理できる便利なツールである。このファイルを使用すると、簡単なコマンドで複雑なKubernetesクラスタを設定、管理できる。ここではHelmのさまざまな構成要素を見て、それを活用してKubernetes管理を簡素化する方法を確認する。
Helm chartとは？
Helm chartは、アプリケーションをKubernetesクラスタにデプロイするために必要なすべてのリソースを含むパッケージである。パッケージには、Deployment、Service、Secret、特定アプリケーションの状態を定義するConfig Mapなど、さまざまなYAML設定ファイルが含まれる。
Helm chartはこれらのYAMLファイルとテンプレートをパッケージ化したものであり、パラメータ化された値に応じて追加の設定ファイルを生成できる。この方式により、さまざまな環境に合わせて設定ファイルをカスタマイズしたり、複数のデプロイで再利用できる設定ファイルを生成したりできる。また、各Helm chartを個別にバージョン管理できるため、異なる設定を持つ複数バージョンのアプリケーションを簡単に管理できる。
configファイル
configファイルにはアプリケーションの設定が含まれており、通常はYAMLファイルに保存される。Kubernetesクラスタのリソースはこの値に従ってデプロイされる。
release
Chartを実行するインスタンスをReleaseと呼び、helm installコマンドを実行すると、configファイルとChartファイルを取得してすべてのKubernetesリソースをデプロイする。
アーキテクチャ
Helmの概念を理解したら、次はHelmのアーキテクチャを見ていく。Helmのアーキテクチャには、クライアントとライブラリという2つの主要構成要素がある。
Helmクライアントは、ローカルChart開発、リポジトリ、Release管理のためのエンドユーザー向けコマンドラインユーティリティであり、MySQLコマンドを実行するためにMySQLデータベースクライアントを使うのと同じように、Helmコマンドを実行するためにHelmクライアントを使用する。
Helmライブラリはすべての主要処理を担当する。このライブラリには、Helmコマンドで指定された処理を実行するための実際のコードが含まれており、HelmライブラリはconfigとChartファイルの組み合わせを処理してReleaseを作成する。
Helmアーキテクチャはバージョン2から3へ移行する中で大きく改善された。バージョン2では、TillerサーバーがHelmクライアントとKubernetes APIサーバーを仲介する役割を果たした。また、Helmが作成したすべてのリソースを追跡した。バージョン3ではクライアント専用アーキテクチャを志向し、Tillerサーバーをなくし、API直接接続を通じてKubernetes APIサーバーと相互作用するようになった。
Helmの動作原理
Helmアプリケーションライブラリは、Chartを使ってKubernetesアプリケーションを定義、作成、インストール、アップグレードできる。Helm Chartを使用すると、Kubernetesコマンドラインインターフェースを使わなくてもクラスタを制御でき、複雑なKubernetesコマンドを覚えなくてもKubernetesマニフェストを管理できる。
Helmが有用な現実的なシナリオを考えてみよう。プロダクション環境に10個のレプリカを持つアプリケーションをデプロイすると仮定する。アプリケーションのYAMLファイルにこの仕様を指定し、kubectlコマンドを使ってデプロイを実行する。
次に、ステージング環境で同じアプリケーションを実行する。しかし、ステージング環境には3個のレプリカが必要であり、ステージング環境では内部アプリケーションビルドを実行する必要がある。この場合、デプロイ用YAMLファイルのレプリカ数とDocker imageタグを更新し、ステージングKubernetesクラスタで更新済みファイルを使用する。
アプリケーションが複雑になるほどYAMLファイルの数は増える。1つのアプリをさまざまな環境にデプロイするために多数のYAMLファイルを更新するのは非常に面倒であり、結果としてYAMLファイルの設定フィールドも増える。Helmを使うと、環境に応じてフィールドをパラメータ化できる。前の例では、レプリカ数とDockerイメージに静的値を指定せず、別のファイルでその値を指定する。その別のファイルがvalues.yamlである。
この方式を使うと、環境ごとにvaluesファイルを用意し、各ファイルに適切な値を設定すればよい。Helmでは、実際のYAML設定と設定フィールド値の管理を分離できる。
Helmリポジトリ
HelmリポジトリはHelm Chartをアップロードできる場所である。個人リポジトリを作成して組織内でChartを共有することもでき、Artifact HubというグローバルHelmリポジトリを通じて、さまざまな用途のChartを検索してインストールする機能もある。簡単に言えば、DockerイメージにおけるDocker Hubが、Helm ChartにおけるArtifact Hubである。
Helmでデプロイおよびロールバックする
Helm Chartを作成した後、アプリをデプロイするのは非常に簡単であり、すべてのKubernetesリソースをデプロイするために2から3個のHelmコマンドを実行するだけでよい。
実際の例として、Helm Chartを使ってデプロイしたKubernetesクラスタでアプリケーションを実行していると仮定する。このアプリケーションにPrometheusのような監視ソリューションを構成してみよう。選択肢は2つある。
- Prometheusアプリケーション用のすべてのDeploymentとServiceを最初から作成する場合、時間がかかる。
- Artifact HubでPrometheus Chartを探し、自分の要件に合わせて設定を更新してインストールする。Docker Hubで既存のDockerイメージを探し、DockerfileのFROM文に指定するのと似ている。
次の手順で目的のHelm Chartをインストールできる。
- HelmライブラリがHelm Chartを取得する場所を把握できるように、Helmリポジトリをローカルに登録する。
- 設定したリポジトリから利用可能なすべてのHelm Chartを取得する。
values.yamlファイルを必要に応じて更新し、helm installコマンドを使って特定のHelm Chartをインストールする。
Helmを使うもう一つの利点は、ロールバックプロセスが簡単なことである。
Helmはアプリケーションレベルで動作する。つまり、実行中アプリケーションの状態、すなわちReleaseが維持される。アプリケーションの新バージョンをデプロイしたが期待どおりに動作しない場合、helm rollbackコマンドを使って以前の安定したReleaseに戻せる。このコマンドはすべてのDeployment、Service、Kubernetesリソースをロールバックする。
Helmがなければ、このように簡単にはロールバックできず、各Kubernetesリソースごとにロールバックを実行する必要があるため、複雑なアプリケーションの管理がより難しくなる。
HelmとCI/CD
Helmを活用すると、CI/CD（Continuous Integration & Continuous Delivery）パイプラインでKubernetesアプリケーションのビルドおよびテストがはるかに簡単になる。アプリケーションを任意の環境へ自動的にデプロイしてビルド時間を短縮できる。パイプラインでセルフホストランナーを使用すると、ビルドおよびテスト環境の柔軟性を高められる。
CircleCIのセルフホストランナーを使うと、ユーザーが管理する環境でCI/CDジョブを実行できる。つまり、独立した仮想マシンやKubernetesのようなクラスタ全体を実行環境として使える。コンテナランナーを使うと、Helm Chartを使用してコンテナ化されたワークロードをプライベートKubernetesクラスタへデプロイし、必要に応じて環境を拡張できる。
Helm使用の長所と短所
Helmには役立つユースケースと、そうでないユースケースがある。このセクションでは、Helmが役立つユースケースと役立たないユースケースを確認し、Helmが役立つかどうかを区別するいくつかのポイントを示す。
Helmが適している場合
Helmは、多数のマイクロサービスを含む複雑なアプリケーションをKubernetesで実行するプロジェクトに有用である。Helmを使うと、アプリケーションのデプロイと管理を簡単に自動化でき、手作業を減らしてシステムの信頼性と安定性を向上できる。また、事前構成されたさまざまなパッケージで構成されたリポジトリにより、アプリケーションへ新しい機能を簡単に追加できる。
Helmを使ってアプリケーションコンポーネントを、インストールとアップグレードが容易なモジュール型Chartとして構成すると、アプリケーションコンポーネント管理プロセスを簡素化できる。また、アプリケーション保守に必要な手作業が減り、複雑なシステムを手動管理するときに発生するエラーや不整合を防止できる。
Helmは複数環境、たとえば開発、ステージング、プロダクションなどへコンテナをデプロイできるよう支援するため、開発プロセス全体でコンテナのライフサイクルを簡単に管理できる。
Helmが適していない場合
Helmは、サーバーにデプロイするコンテナが1つだけのプロジェクトには適していない。この場合、Helmでコンテナデプロイを管理する必要はなく、むしろHelmを使うとプロセスが複雑になる可能性がある。Helmは複数コンテナのデプロイを1つの単位として管理するために作られているため、このシナリオには適していない。
パッケージマネージャーを使わずに少数のKubernetesアプリケーションを手動で管理できる場合にも、Helmは大きな助けにはならない。
また、Helmのようなサードパーティツールの使用を禁止する厳格なセキュリティポリシーがある環境では、Helmを使用できないだろう。
Helmを導入すべき理由
プロジェクトにHelmを使うことが役立つかどうかを判断できるポイントがいくつかある。たとえば、プロジェクトに複数のKubernetesアプリケーションが含まれており、それらを統合的に管理してデプロイする必要がある場合である。この場合、Helmを使ってこれらのアプリケーションを1つのChartとしてパッケージングすると、管理とデプロイが容易になる。
プロジェクトでKubernetesアプリケーションを頻繁に更新し、デプロイする場合にも、Helmはアプリケーションのライフサイクル、つまりデプロイ、更新、ロールバックなどを管理できるツールを備えているため役立つ。そのため、アプリケーション更新管理とデプロイがはるかに簡単になる。
最後は、プロジェクトに複数のチームとメンバーが参加し、共同でKubernetesアプリケーションを開発してデプロイする必要がある場合である。この場合、Helmのバージョン管理とChart共有機能が役立ち、チーム間の協業とデプロイ間の一貫性維持が容易になる。