事実上の標準ツールとなっているKubernetes向けデプロイツール「Helm」入門

近年ではKubernetesクラスタ上で動作させるアプリケーションにおいて、そのデプロイに「Helm」と呼ばれるツールを使用する例が増えている。Helmは設定ファイルを元にアプリケーションのデプロイを自動実行するツールで、Kubernetesアプリケーション向けのパッケージマネージャとも言われている。今回はこのHelmの概要、使い方、設定ファイルの書き方などを紹介する。

Kubernetes上にアプリケーションをデプロイするための事実上の標準的ツールとなっている「Helm」
Helmのインストール
公開されているChartを使ってアプリケーションをデプロイする
Chartの作成と変更
新たなChartを作成する
リポジトリでChartを公開する
Kubernetes上へのデプロイ管理ツールとして必要十分、ただ設定関連には慣れが必要

Kubernetes上にアプリケーションをデプロイするための事実上の標準的ツールとなっている「Helm」

近年ではコンテナクラスタ技術であるKubernetesを活用したサービスの運用が増えており、Kubernetes上で動かすことを前提とするソフトウェアも登場している。一方で、Kubernetes上でのアプリケーションのデプロイについては課題も多い。

Kubernetesはサービスを複数の小規模コンポーネントに分割して実装するマイクロサービスアーキテクチャと相性が良い。そういった構成のサービスでは、それぞれのコンポーネントを個別にクラスタ上にデプロイする必要がある。また、サービスを外部に公開したり、各種設定を行ったりするためにKubernetesクラスタ上に「リソース」を作成して設定を行う必要もある。こういった作業は時に複雑になるため、Kubernetesクラスタでのデプロイを支援したり、デプロイされたコンテナを管理したりするためのさまざまなツールが登場している。

今回紹介するHelmは、そういったKubernetesクラスタへのアプリケーションのデプロイを支援するツールの1つだ（図1）。

昨今のOSやプログラミング言語の多くでは、第三者が作成したソフトウェア（パッケージ）を集積して公開するサービス（リポジトリ）が提供されており、そこで公開されているソフトウェアの検索やダウンロード、インストールなどを簡単な操作で行える「パッケージマネージャ」と呼ばれるソフトウェアが用意されている。HelmはKubernetes向けのパッケージマネージャとも呼ばれており、OSやプログラミング言語のパッケージマネージャと類似した機能を備えている。Helmによって提供される具体的な機能を簡単にまとめると、次のようになる。

「Chart」と呼ばれる設定ファイルに基づいた各種リソースの自動作成
デプロイされたアプリケーションの削除・更新といった管理
リポジトリで公開されているChartの検索やダウンロード、インストール
Chartのパッケージ化やリポジトリへのアップロード

Kubernetesのベースとなっているコンテナ技術のDockerでは、すでにコンテナイメージを提供するリポジトリ機構が用意されている。そのため、Helmではイメージ自体は直接扱わず、「Chart」（チャート）と呼ばれる設定ファイルのみをリポジトリで管理する仕組みになっている。その点を除けば、Helmが提供する機能は一般的なパッケージマネージャが備える機能とほぼ同じで、「helm」と呼ばれるコマンドラインツールを使ってChartをダウンロードしたり、それに基づいてクラスタ内に自動的にアプリケーションをデプロイしたりできるようになっている。

また、Helmでは「stable」や「incubator」という名称の公式リポジトリが提供されているほか、サードパーティによるリポジトリも多く提供されている。これらのリポジトリで公開されているChartは、Helm Hubというサイトで横断的に検索できるようになっている（図2）。

Helmの歴史とコミュニティ

Helmは2016年2月にv1.0がリリースされ、現在までに2度のメジャーアップデートが行われている。最新版は2020年2月にリリースされたv3.1.0だ。

当初はKubernetesのサブプロジェクトとして開発が進められていたが、その後Linux Foundation傘下の非営利団体であるCloud Native Computing Foundation（CNCF）傘下となり、現在もその体制で開発が進められている。CNCFはクラウド関連技術の開発を推進する団体で、Kubernetes自体もCNCFの傘下で開発が進められている。こういった歴史的背景のため、HelmはKubernetesの（事実上の）公式パッケージマネージャとも言われている。

Helmプロジェクト自身が提供する「stable」や「incubator」などの公式リポジトリではすでにさまざまなアプリケーションのChartが公開されているほか、有志によって作成されたChartも多く公開されている。また、以前紹介したKubernetes関連ツールのIstioやJenkins Xといったソフトウェアでも、Helmが公式のインストール手段として採用されている。

なお、helmは船舶などで使われる「舵（かじ）」を意味する単語だ。また、chartは「海図」に由来している。

Helmのインストール

helmコマンドはGitHubのリリースページから入手が可能で、ここではソースコードのほかWindowsおよびLinux、macOS向けのバイナリも提供されている。配布アーカイブ内にはバイナリファイル（「helm」）がそのまま格納されているので、これを、Helmを利用したいマシン上にダウンロードし、展開後にパスの通ったディレクトリにコピーすればインストール完了だ。

また、macOSのHomebrewやWindowsのChocolateyといったパッケージマネージャ経由でもインストールできる。これらについて詳しくはドキュメントを参照して欲しい。

なお、helmコマンドはKubernetesクラスタへのアクセスにkubectlコマンドを利用するため、helmコマンドを実行するマシン上にkubectlコマンドがインストールされており、さらにkubectlコマンドでKubernetesクラスタにアクセスできるよう設定を行っておく必要がある。

サポートするKubernetesクラスタのバージョンについては明記されていないが、「Kubernetesの最新安定版」との組み合わせが推奨となっている。とはいえ、古いバージョンのKubernetesだからといって直ちに利用できなくなることはないようだ。ただし、Kubernetes 1.6以前では役割（ロール）ベースのアクセスコントロール（RBAC）関連設定で制限があるとされている。

ちなみに、Helmのv2系ではhelmコマンドに加えてKubernetes上で動作する「tiller」というアプリケーションが必要だったが、v3ではtillerは廃止され、helmコマンドのみが必要なように変更されている。

公開されているChartを使ってアプリケーションをデプロイする

前述のように、HelmではChartと呼ばれる設定ファイルに基づいてアプリケーションのデプロイを実行する。Chartはhelmコマンドを実行するローカルマシン上に用意されたものだけでなく、リポジトリで公開されているChartを直接ダウンロードして利用することも可能だ。まずはHelmによるアプリケーションのデプロイ例として、リポジトリで公開されているChartを利用する流れを紹介しよう。

前述のとおり、公開されているChartはHelm Hubというサイトで検索できる。Helm Hubでは「＜リポジトリ名＞/＜Chart名＞」という形式でChartが表示されており、そのうちリポジトリ名が「stable」や「incubator」になっているものがHelmの公式リポジトリで提供されているChartで、リポジトリ名がそれ以外のものになっているものはサードパーティが提供しているChartだ。同一の名称のChartが異なるリポジトリで公開されていることもあるが、それらは提供元が異なっているという点に注意したい。

さて、リポジトリ経由でChartをインストールする場合、まずはそのChartを提供しているリポジトリをローカルマシン上に登録する必要がある。Helmのインストール直後はいずれのリポジトリも登録されていない状態になっているはずなので、公式リポジトリで提供されているChartを利用する場合でもリポジトリの追加作業が必要となる。

リポジトリの追加は、「helm repo add ＜リポジトリ名＞ <URL＞」コマンドで実行できる。たとえば公式の「stable」リポジトリを追加する場合、以下のように実行する。

$ helm repo add stable https://kubernetes-charts.storage.googleapis.com/
"stable" has been added to your repositories

ちなみにLinux環境では、使用するリポジトリの設定はホームディレクトリ以下の.config/helmディレクトリ以下に、リポジトリで公開されているChart一覧のキャッシュはホームディレクトリ以下の.cache/helm/repositoryディレクトリ内に格納される。これらの情報は「helm -h」コマンドで表示できるhelmコマンドのヘルプに記載されているので、必要に応じて確認しておこう。

$ helm -h
The Kubernetes package manager
  ：
  ：
+------------------+---------------------------+--------------------------------+-------------------------+
| Operating System | Cache Path                | Configuration Path             | Data Path               |
+------------------+---------------------------+--------------------------------+-------------------------+
| Linux            | $HOME/.cache/helm         | $HOME/.config/helm             | $HOME/.local/share/helm |
| macOS            | $HOME/Library/Caches/helm | $HOME/Library/Preferences/helm | $HOME/Library/helm      |
| Windows          | %TEMP%\helm               | %APPDATA%\helm                 | %APPDATA%\helm          |
+------------------+---------------------------+--------------------------------+-------------------------+

リポジトリの登録後は、「helm search」コマンドでリポジトリに登録されているChartを検索できる。

helm search repo [＜検索するキーワード＞]

キーワードを省略した場合、登録されているリポジトリで提供されているすべてのChartが出力される。

$ helm search repo
NAME                                    CHART VERSION   APP VERSION             DESCRIPTION
stable/acs-engine-autoscaler            2.2.2           2.1.1                   DEPRECATED Scales worker nodes within agent pools
stable/aerospike                        0.3.2           v4.5.0.5                A Helm chart for Aerospike in Kubernetes
  ：
  ：

登録したリポジトリの情報はローカルにキャッシュされるため、時間が経つと古くなっている可能性がある。「helm repo update」コマンドを実行することで、リポジトリのキャッシュを最新のものに更新できる。

$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "stable" chart repository
Update Complete. ? Happy Helming!?

Helmでは、Chartを使ってアプリケーションをデプロイすることを「install（インストール）と呼び、インストールされたアプリケーションのインスタンスは「Release（リリース）」と呼ぶ。また、各インスタンスはそれぞれに固有の名前（Release名）を持つ。Release名が重複しない限り、同一のChartから複数のReleaseを作成することも可能だ。

さて、リポジトリで公開されているChartを使ってアプリケーションをインストール（デプロイ）するには、「helm install ＜Release名＞＜Chart名＞」コマンドを実行する。

次の例は、「stable/wordpress」というChartを「wordpress」というRelease名でデプロイしたものだ。デプロイに成功すると、そのアプリケーションに関するメモなどを含む「NOTES」が表示される。

$ helm install wordpress stable/wordpress
NAME: wordpress
LAST DEPLOYED: Mon Feb 17 19:42:51 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
1. Get the WordPress URL:

  NOTE: It may take a few minutes for the LoadBalancer IP to be available.
        Watch the status with: 'kubectl get svc --namespace default -w wordpress'
  export SERVICE_IP=$(kubectl get svc --namespace default wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}")
  echo "WordPress URL: http://$SERVICE_IP/"
  echo "WordPress Admin URL: http://$SERVICE_IP/admin"

2. Login with the following credentials to see your blog

  echo Username: user
  echo Password: $(kubectl get secret --namespace default wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)

デプロイは現在のKubernetesのコンテキストに対して行われるため、特定のネームスペースを使用したい場合などは事前に「kubectl config」コマンドなどでコンテキストの設定を行っておこう。

なお、このstable/wordpress Chartでは永続化ストレージを利用するため、クラスタ内でデフォルトのStorage Classが設定されている必要がある。Storage Classの設定方法は使用しているKubernetesクラスタによって異なるが、独自で作成したクラスタの場合は以前の記事『Kubernetes環境に特化したCI/CDツール「Jenkins X」を試してみる』内で「インストール作業2：KubernetesのStorage Classの作成」として紹介しているので、そちらを参照してほしい。

デプロイされたReleaseの一覧は「helm list」コマンドで確認できる。

$ helm list
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART           APP VERSION
wordpress       default         1               2020-02-06 20:38:52.212353733 +0900 JST deployed        wordpress-8.1.2 5.3.2

ここで作成されたPodを「kubectl get po」コマンドで確認すると、次のように「wordpress-8bcc6cf8c-4nr2l」と「wordpress-mariadb-0」の2つのPodが作成されていることが分かる（環境に応じて「8bcc6cf8c-4nr2l」の部分は変わる）。

$ kubectl get po
NAME                                      READY   STATUS    RESTARTS   AGE
nfs-client-provisioner-78b7d65564-kkzw4   1/1     Running   0          15m
wordpress-8bcc6cf8c-4nr2l                 1/1     Running   0          5m9s
wordpress-mariadb-0                       1/1     Running   0          5m9s

このうち「wordpress-8bcc6cf8c-4nr2l」は「wordpress」というDeployment（deploy）によって作成されたもので、また「wordpress-mariadb-0」は「wordpress-mariadb」というStatefulsetで作成されている。

$ kubectl get deploy
NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
nfs-client-provisioner   1/1     1            1           14m
wordpress                1/1     1            1           4m54s

$ kubectl get statefulset
NAME                READY   AGE
wordpress-mariadb   1/1     7m24s

各種設定を保存するリソースであるConfigMag（cm）についても、「wordpress-mariadb」と「wordpress-mariadb-tests」というものが作成されている。

$ kubectl get cm
NAME                      DATA   AGE
wordpress-mariadb         1      12m
wordpress-mariadb-tests   1      12m

デプロイされたサービスにアクセスするためのIPアドレスは、「kubectl get svc」コマンドでKubernetesのServiceリソースの情報を表示することで確認できる。

$ kubectl get svc
NAME                TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
kubernetes          ClusterIP      10.96.0.1        <none>        443/TCP                      117d
wordpress           LoadBalancer   10.101.202.201   <pending>     80:32404/TCP,443:30919/TCP   8m23s
wordpress-mariadb   ClusterIP      10.102.21.63     <none>        3306/TCP                     8m23s

ここで「wordpress」が今回デプロイされたWordPressに紐付けられたServiceとなる。今回使用したKubernetes環境はingressの設定を行っていないため「EXTERNAL-IP」は「<pending>」となっているが、curlコマンドなどで「CLUSTER-IP」で表示されているIPアドレス（今回の例の場合は「10.101.202.201」）にアクセスすると、WordPressのトップページを確認できるはずだ。

デプロイ時にパラメータ設定を行う

Helmではアプリケーションのデプロイ時にさまざまなパラメータを与えて設定を行う仕組みが用意されている。これらパラメータは、「helm install」コマンドの実行時に「--set ＜パラメータ名＞=＜値＞」オプションで指定するか、もしくはYAML形式でファイルに記述し、「-f ＜YAMLファイル＞」オプションでそのファイルを指定することで設定できる。また、「--set」オプションでは「--set ＜パラメータ名＞=＜値＞, ＜パラメータ名＞=＜値＞」のようにカンマ区切りで複数のパラメータと値を同時に指定することもできる。

使用できるパラメータはChartごとに異なるが、多くの場合アプリケーションの挙動を変更するためのパラメータや、Kubernetesクラスタへのデプロイ時の挙動を変更するためのパラメータなどが用意されている。たとえば前述の「stable/wordpress」Chartでは、「global.storageClass」では使用するKubernetesのストレージクラスを、「image.repository」ではイメージ名を指定できる。また、「wordpressEmail」ではWordPressの管理者のメールアドレスを、「mariadb.db.name」ではデプロイされるMariaDBで作成されるデータベースのデータベース名を指定できる。詳しくはドキュメントを参照して欲しい。

Releaseのアップグレードを行う

Helmでは、デプロイしたアプリケーションのアップグレードやロールバックといった機能も提供されている。これを利用して、Chartのアップデートにあわせてアプリケーションを更新したり、またデプロイ時（「helm install」コマンドの実行時）に指定したパラメータを変更する（もしくはパラメータを追加する）といったことができる。

たとえば、先に「stable/wordpress」Chartを使ってインストールしたWordPressについて、新たに「wordpressBlogName」パラメータを追加したい場合、次のように実行する。ここでは、このパラメータに対し「foobar」という値を指定している。

$ helm upgrade wordpress stable/wordpress --set wordpressBlogName=foobar

「helm upgrade」コマンドでアップグレードを行った場合、その履歴はすべて記録されるようになっており、任意のタイミングでロールバックを実行できる。この履歴は、「helm history ＜Release名＞」コマンドで確認できる。

$ helm history wordpress
REVISION        UPDATED                         STATUS          CHART           APP VERSION     DESCRIPTION
1               Mon Feb 17 19:48:14 2020        superseded      wordpress-8.1.3 5.3.2           Install complete
2               Mon Feb 17 20:05:18 2020        deployed        wordpress-8.1.3 5.3.2           Upgrade complete

ここでは最初に「helm install」コマンドでインストールしたReleaseがリビジョン（REVISION）1、続いて「helm upgrade」コマンドで更新を行ったReleaseがリビジョン2となっている。

Releaseのロールバックを行うには、「helm rollback ＜Release名＞＜リビジョン＞」コマンドを使用する。たとえば「wordpress」というRelease名でデプロイされたアプリケーションをリビジョン1に戻すには、次のように実行する。

$ helm rollback wordpress 1
Rollback was a success! Happy Helming!

デプロイされたアプリケーションを削除するには、「helm uninstall ＜Release名＞」コマンドを実行する。たとえば「wordpress」というRelease名でデプロイされたアプリケーションを削除するには、次のように実行する。

$ helm uninstall wordpress

このように、Helmでは単一のChartからコマンド1つでアプリケーションの動作に必要な複数のKubernetesリソースを作成したり、それらをアップグレード/ロールバック/削除したりできる点が特徴となっている。

Chartの作成と変更

Helm向けのChartはすでにさまざまなものが公開されているが、使いたいアプリケーション向けのChartがなかったり、また独自に修正・改良を加えたい、というケースも当然ながらあるだろう。そのため、続いては既存のChartを改変したり、新しいChartを作成したりするための手順を紹介していく。

なお、Chartに関する情報はドキュメントの「Charts」というページにまとめられているので、こちらもあわせて参照して欲しい。

既存のChartをダウンロードする

リポジトリで公開されている既存のChartを修正して使いたいという場合、「helm pull ＜Chart名＞」コマンドでそのChartをローカルのマシン上にダウンロードできる。たとえば「stable/wordpress」というChartをダウンロードするには、次のようにする。

$ helm pull stable/wordpress

「helm pull」コマンドでダウンロードしたChartはtarおよびgzipで圧縮されているので、適宜展開しよう。

$ ls wordpress-8.1.2.tgz
$ tar xvzf wordpress-8.1.2.tgz
$ ls wordpress

なお、ローカルに保存されたChartからデプロイを行うには、次のようにそのディレクトリを指定して「helm install」コマンドを実行すれば良い。

$ helm install wordpress ./wordpress

Chartの構造

それでは、Chartの構造について見てみよう。Chartには、表1のファイルおよびディレクトリが含まれている。なお、備考が「必須」になっていないものは用意せずともかまわない。

表1 Chartを構成するファイルおよびディレクトリ
ファイル/ディレクトリ名	ファイルの内容	備考
Chart.yaml	Chartに関する各種メタデータなどが格納されている	必須
LICENSE	Chartのライセンス
README.md	Chartのドキュメント（いわゆるREADMEファイル）
values.yaml	Chartのデフォルトパラメータ	必須
values.schema.json	パラメータの定義
charts/	依存するChartを格納するディレクトリ
crds/	カスタムリソース定義（Custom Resource Definitions）のためのマニフェストファイルを格納するディレクトリ
templates/	Kubernetesのマニフェストファイルを生成するためのテンプレートファイルを格納するディレクトリ	必須
templates/NOTES.txt	備考（note）などを記述する。このファイルはChartのインストール時に表示される

まずChart.yamlファイルだが、ここではChartの名前や説明、ホームページ、メンテナといった情報をYAML形式で記述する。たとえば先のstable/wordpressでは、このファイルの内容は次のようになっている。

apiVersion: v1
appVersion: 5.3.2
description: Web publishing platform for building blogs and websites.
engine: gotpl
home: http://www.wordpress.com/
icon: https://bitnami.com/assets/stacks/wordpress/img/wordpress-stack-220x234.png
keywords:
- wordpress
- cms
- blog
- http
- web
- application
- php
maintainers:
- email: containers@bitnami.com
  name: Bitnami
name: wordpress
sources:
- https://github.com/bitnami/bitnami-docker-wordpress
version: 8.1.2

なお、この設定ファイルのapiVersionは「v1」となっており、1つ前のバージョンのフォーマットで記述されている点に注意したい（現行のバージョンは「v2」）。apiVersionがv1のChartは現在のHelmでもサポートされているものの、v2とは若干ではあるが仕様が異なっている。v1とv2を比較した場合での大きな変更点としては、v1では「requirements.yaml」というファイルでChartの依存関係が定義されていたが、v2ではこれらがChart.yamlファイルの「dependencies」フィールドに統合されている点がある（後述）。

さて、ここで設定すべき項目は表2の通りだ。

表2 Chart.yamlファイルで設定する項目
項目名	説明	備考
apiVersion	ChartのAPIバージョン。現行では「v2」	必須
name	Chart名	必須
version	Chartのバージョン。SemVer 2形式で指定する	必須
kubeVersion	必須とするKubernetesのバージョン
description	Chart内容を説明する文章
type	Chartのタイプ（「application」もしくは「library」）	デフォルトは「application」
keywords	検索などの際に使用されるキーワードをリスト形式で指定する
home	ChartのホームページなどのURL
sources	Chartで使用しているソースコードを公開しているURLなどをリスト形式で指定
dependencies	Chartが依存するChartについての情報をリスト形式で指定
maintainers	Chartのメンテナに関する情報をリスト形式で指定
icon	Helm Hubなどでの表示時に使用されるアイコン画像のURLを指定（SVGもしくはPNGが使用可能）
appVersion	このChartで提供されるアプリケーションのバージョン
deprecated	Chartが廃止予定（deprecated）かどうかをbool形式（trueもしくはfalse）で指定

このうちdependenciesフィールドについては後述する。また、maintainersフィールドについては表3の要素をもつハッシュのリストで指定する。

表3 maintainersフィールドで指定するパラメータ
パラメータ名	説明	備考
name	メンテナ名	必須
email	メンテナのメールアドレス
url	メンテナのURL

Chartのパラメータ

前述のように、「helm install」コマンドの実行時には「--set」オプションもしくは「-f ＜YAMLファイル＞」オプションでパラメータおよびその値を指定できるようになっている。そのChartでどのようなパラメータを利用できるかを指定するのが、「values.yaml」ファイルと「values.scheme.json」ファイルだ。

まず「values.yaml」ファイルは、パラメータおよびそのデフォルト値の組み合わせをYAML形式で記述したものだ。たとえばstable/wordpressの場合、次のようになっている（一部のみ抜粋）。

## Bitnami WordPress image version
## ref: https://hub.docker.com/r/bitnami/wordpress/tags/
##
image:
  registry: docker.io
  repository: bitnami/wordpress
  tag: 5.3.2-debian-10-r0
  ## Specify a imagePullPolicy
  ## Defaults to 'Always' if image tag is 'latest', else set to 'IfNotPresent'
  ## ref: http://kubernetes.io/docs/user-guide/images/#pre-pulling-images
  ##
  pullPolicy: IfNotPresent
  ## Optionally specify an array of imagePullSecrets.
  ## Secrets must be manually created in the namespace.
  ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
  ##
  # pullSecrets:
  #   - myRegistryKeySecretName
：
：

ここでは、「image.registry」や「image.repository」、「image.tag」、「image.pullPolicy」などのパラメータと、そのデフォルト値が定義されている。

また、「values.schema.json」ファイルはvalues.yamlファイルで指定されたパラメータについて、その型や必須とするパラメータなどを指定するものだ。このファイルはJSON Schema形式で記述するようになっている。記述方法について詳しくはこのJSON Schemaのドキュメントを参照して欲しいが、たとえば次のように指定した場合、「image」というプロパティはオブジェクト形式で、文字列型の「repo」および「tag」というプロパティを持つ、といったことが定義できる。

{
  "$schema": "https://json-schema.org/draft-07/schema#",
  "properties": {
    "image": {
      "description": "Container Image",
      "properties": {
        "repo": {
          "type": "string"
        },
        "tag": {
          "type": "string"
        }
      },
      "type": "object"
    },
：
：

Chartの依存関係

アプリケーションの実行時にほかのアプリケーションが必要となる場合、必要なアプリケーションをデプロイするための設定を別のChartに分離しておくことで、メンテナンス性や再利用性が向上する。このようなChartの依存関係は、Chart.yamlファイルの「dependencies」要素で指定できる。なお、Helmにおいてはこのようにあるチャートが依存するChartのことを「Subchart（サブチャート）」などと呼ぶ。

たとえば先に説明したstable/wordpress Chartでは、WordPressを利用するために必要となるMariaDBをデプロイするためのSubchartが含まれている。これによって、「helm install」コマンドでstable/wordpress Chartをデプロイすると、WordPressだけでなくデータベースのMariaDBも同時にデプロイされる仕組みになっている。

Subchartは、Chart.yaml内（apiVersionが「v1」の場合は「requirements.yaml」という別ファイル内）の「dependencies」プロパティに記述したうえで「charts」ディレクトリにそのChartを格納することで利用できるようになる。

たとえば前述のstable/wordpress Chartでは、「requirements.yaml」内に以下のように記述されている。

dependencies:
- name: mariadb
  version: 7.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - wordpress-database

これはapiVersionがv1の場合の例だが、v2の場合でもこのrequirements.yaml内のdependencies要素がChart.yamlファイル内に移動されただけで、記述する内容は同じだ。また、stable/wordpress Chartのchartsディレクトリ内にはこれに対応する「mariadb」というChartが含まれている。

$ ls charts
mariadb

ちなみに、Chart.yamlがあるディレクトリ上で「helm dependency update」コマンドを実行すると、dependenciesの情報を元に対応するChartの最新版を自動でダウンロードしてchartsディレクトリ内に格納してくれる。

$ helm dependency update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "stable" chart repository
Update Complete. ?Happy Helming!?

Saving 1 charts
Downloading mariadb from repo https://kubernetes-charts.storage.googleapis.com/
Deleting outdated charts

さて、このdependencies要素では、表4の要素を持つハッシュのリストという形で依存するChartの情報を指定するようになっている。

表4 dependenciesフィールドで指定するパラメータ
パラメータ名	説明	備考
name	依存するChartの名前	必須
version	依存するChartのバージョン	必須
repository	依存するChartのリポジトリのURL	必須
condition	依存Chartの有効/無効を切り替えるために使用する設定パラメータ名
tags	依存Chartの有効/無効を切り替えるために使用するタグ名をリスト形式で指定する
enabled	Chartの有効/無効をbool形式（true/false）で指定する
import-values	使用するChartに渡す設定パラメータ。リスト形式で指定する
alias	Chartにエイリアスとして割り当てる名前をここで指定する

たとえばstable/wordpress Chartの例では、依存するSubchartとして「https://kubernetes-charts.storage.googleapis.com/」というリポジトリで公開されている「mariadb」というChartのバージョン7.x.xが指定されており、stable/wordpress ChartをインストールするとデフォルトではこのChartも自動的にインストールされる。この際にはパラメータとして親Chart（この場合はstable/wordpress）内で設定されているパラメータおよびその値がこのChartにも渡される仕組みになっている。

「condition」要素は「helm install」コマンドの実行時にSubchartをデプロイするかどうかを判断するパラメータを指定するものだ。特に設定がされていない場合、Chartのインストール時にはSubchartも自動的にデプロイされる。stable/wordpress Chartでは「condition: mariadb.enable」と指定されているが、この場合stable/wordpress Chartのインストール時に「--set」オプションもしくは「-f ＜YAMLファイル＞」オプションで「mariadb.enable」パラメータの値をfalseに設定すると、このSubchartはデプロイされなくなる。

「tags」要素もconditions要素に似た要素だが、設定パラメータの「tags」要素でSubchartをデプロイするかどうかを判断する点が異なる。たとえば次のように「foo」と「bar」というタグが設定されていた場合、パラメータの「tags」で「foo」もしくは「bar」に「false」が指定されるとそのSubchartはデプロイされなくなる。

tags:
  - foo
  - bar

Chartの各種設定ファイルやパラメータからKubernetesのマニフェストファイルを生成するテンプレート

Helmでは、Chartのvalues.yamlファイルで指定されたパラメータや、「helm install」コマンドの実行時に与えられたパラメータをtemplatesディレクトリ内に格納されているテンプレートに与えてKubernetesのマニフェストファイルを作成し、それを適用（apply）することで各種リソースを作成する仕組みになっている。これはGo言語のテンプレート機能（text/template）を使用して実装されており、テンプレートはこの機能でサポートされる書式に従って記述する必要がある。

Go言語のテンプレート機能については「静的サイトジェネレータ「Hugo」と技術文書公開向けテーマ「Docsy」でOSSサイトを作る」という記事内の「Go言語のテンプレート機構」節でも簡単に説明しているので今回は割愛する。詳細についてはGo言語のドキュメントも参照して欲しい。

たとえばstable/wordpress Chartでは、以下の設定ファイルが用意されている。

NOTES.txt
_helpers.tpl
deployment.yaml
externaldb-secrets.yaml
ingress.yaml
pvc.yaml
secrets.yaml
servicemonitor.yaml
svc.yaml
tests/test-mariadb-connection.yaml
tls-secrets.yaml

このうち、「NOTES.txt」ファイルはChartのインストール時（「helm install」コマンドの実行時）にユーザーに表示する文章を記述するテンプレートで、「_helpers.tpl」ファイルはChart内で複数回利用されるようなテンプレートや値を定義しておくヘルパーファイルだ。

さて、これらテンプレート内では、values.yamlファイルや「helm install」コマンドの実行時に指定したパラメータに対し、「.Values」というオブジェクト経由でアクセスできる。たとえば「image.registry」というパラメータに対しては「.Values.image.registry」と指定することでその値を参照できる。

また、values.yamlファイルや「helm install」コマンド実行時に指定したパラメータ以外にもいくつかの値が定義済みの値として提供される。これらもテンプレート内で利用が可能だ（表5）。これらについてもドキュメントにまとめられているので、そちらも参照して欲しい。

表5 テンプレート内で利用できる定義済みの値
名前	説明
.Release.Name	helm installコマンドの引数で指定されたリリース名
.Release.Namespace	デプロイ先のKubernetesのネームスペース
.Release.IsUpgrade	リリースを管理するサービス
.Release.IsInstall	upgradeもしくはrollback時にtrue、そうでない場合はfalse
.Chart	Chart.yamlファイルの中身がそのまま格納されたオブジェクト
.Files	Chart内に含まれるファイルの一覧が格納されているオブジェクト
.Capabilities	使用しているKubernetes環境の情報が格納されたオブジェクト

たとえばstable/wordpressのdeployment.yamlテンプレートは次のようになっている（一部抜粋）。

apiVersion: {{ template "wordpress.deployment.apiVersion" . }}
kind: Deployment
metadata:
  name: {{ template "wordpress.fullname" . }}
  labels:
    app: "{{ template "wordpress.fullname" . }}"
    chart: "{{ template "wordpress.chart" . }}"
    release: {{ .Release.Name | quote }}
    heritage: {{ .Release.Service | quote }}
spec:
  selector:
    matchLabels:
      app: "{{ template "wordpress.fullname" . }}"
      release: {{ .Release.Name | quote }}
  {{- if .Values.updateStrategy }}
  strategy: {{ toYaml .Values.updateStrategy | nindent 4 }}
  {{- end }}
  replicas: {{ .Values.replicaCount }}
  template:
    metadata:
      labels:
        app: "{{ template "wordpress.fullname" . }}"
        chart: "{{ template "wordpress.chart" . }}"
        release: {{ .Release.Name | quote }}
：
：

ちなみにstable/wordpress Chartでは、次のように_helpers.tplファイル内でパラメータを元に「wordpress.name」や「wordpress.fullname」といった変数を定義して使用するようになっている。

{{/*
Expand the name of the chart.
*/}}
{{- define "wordpress.name" -}}
{{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" -}}
{{- end -}}

{{/*
Create a default fully qualified app name.
We truncate at 63 chars because some Kubernetes name fields are limited to this (by the DNS naming spec).
*/}}
{{- define "wordpress.fullname" -}}
{{- if .Values.fullnameOverride -}}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" -}}
{{- else -}}
{{- $name := default .Chart.Name .Values.nameOverride -}}
{{- if contains $name .Release.Name -}}
{{- .Release.Name | trunc 63 | trimSuffix "-" -}}
{{- else -}}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" -}}
{{- end -}}
{{- end -}}
{{- end -}}
：
：

anotationによるフック指定

Helmでは、テンプレートの「metadata.annotaions」プロパティで「helm.sh/hook」というプロパティを追加し、そこで実行タイミングを指定する値を指定することで、特定のタイミングで作成したいリソースを定義できるようになっている。この仕組みは「hook（フック）」と呼ばれている。

helm.sh/hookプロパティで指定できる値は表6のとおりだ。

表6 helm.sh/hookプロパティで指定できるフックの種別
指定する値	関連する処理	実行タイミング
pre-install	インストール	リソースの作成前
post-install	インストール	リソースの作成完了後
pre-delete	削除	リソースの削除前
post-delete	削除	リソースの削除完了後
pre-upgrade	アップグレード	リソースのアップグレード前
post-upgrade	アップグレード	リソースのアップグレード完了後
pre-rollback	ロールバック	リソースのロールバック前
post-rollback	ロールバック	リソースのロールバック完了後
test	テスト	「helm test」コマンドの実行時

Kubernetesでは、常時実行されるのではなく、処理が完了したら終了するようなコンテナ（ジョブ）を管理するために「Job」というタイプのリソースが用意されており、これとHelmのhook機能を組み合わせることで、特定のタイミングで実行できるジョブを定義することができる。たとえばChartのインストール完了後に実行したいジョブなら、テンプレート内の「metadata.annotations」部分で「"helm.sh/hook": post-install」と指定すれば良い。なお、apiVersionが「v1」のChartではCRDのインストール時（「crd-install」）やテスト時（「test-failure」と「test-success」）を指定するフックが用意されていたが、これらはv2では廃止予定となっている。

hookはJob以外のリソースでも利用可能だ。たとえばstable/mysql Chartでは、templates/tests/test-mariadb-connection.yamlテンプレートでhookを使用したテスト用のPodが定義されている。

{{- if .Values.mariadb.enabled }}
apiVersion: v1
kind: Pod
metadata:
  name: "{{ .Release.Name }}-credentials-test"
  annotations:
    "helm.sh/hook": test-success
spec:
  containers:
  *[：]
  *[：]

ここでは「metadata.annotations」プロパティで「"helm.sh/hook": test-success」と指定されているため、このPodはChartのインストール後、「helm test」コマンドの実行時に作成される。「helm test」コマンドはこのように定義されたリソースを作成してテストを実行するためのコマンドだ。

たとえば、stable/wordpress Chartを「wordpress」というRelease名でデプロイしていた場合、次のようにしてテストを実行できる。

$ helm test wordpress
Pod wordpress-credentials-test pending
Pod wordpress-credentials-test pending
Pod wordpress-credentials-test succeeded
Pod wordpress-mariadb-test-cxvx8 pending
Pod wordpress-mariadb-test-cxvx8 pending
Pod wordpress-mariadb-test-cxvx8 pending
Pod wordpress-mariadb-test-cxvx8 pending
Pod wordpress-mariadb-test-cxvx8 succeeded
NAME: wordpress
LAST DEPLOYED: Tue Feb 18 17:58:11 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE:     wordpress-credentials-test
Last Started:   Tue Feb 18 18:06:04 2020
Last Completed: Tue Feb 18 18:06:05 2020
Phase:          Succeeded
TEST SUITE:     wordpress-mariadb-test-cxvx8
Last Started:   Tue Feb 18 18:06:06 2020
Last Completed: Tue Feb 18 18:06:20 2020
Phase:          Succeeded
  ：
  ：

ここでは「wordpress-credentials-test」と「wordpress-mariadb-test-cxvx8」の2つのテストが実行され、いずれも成功していることが分かる。

なお、テストについて詳しくはドキュメントを参照して欲しい。

CRDの定義

Kubernetesでは独自のリソースを定義できる「CustomResourceDefinitions」（CRD）という仕組みが用意されている。独自のCRDを定義したり、それらを使用するようなChartを作成したりする場合は、「crds」ディレクトリ内にCRDを作成するためのマニフェストファイルを格納しておく。このディレクトリ内に格納されたファイルは、templatesディレクトリ以下に配置されているマニフェストファイルが処理される前に、直接YAML形式のKubernetesマニフェストとして処理される。templatesディレクトリ以下のファイルとは異なり、テンプレートによる変数展開などは利用できない点に注意が必要だ。

さらに、HelmではCRDのインストールのみが可能で、再インストールやアップグレード、ロールバックといった処理は行えない。そのため、CRDのアップグレードや削除は手作業で実行する必要がある。

新たなChartを作成する

ここまででChartの基本的な仕様をすべて説明したので、続いては実際に独自のChartを作成してみよう。

helmコマンドでChartのひな形を作成する

helmコマンドでは、Chartを新規に作成するためのひな形を作成する「helm create ＜Chart名＞」コマンドが用意されている。まずはこのコマンドを使ってChartに必要なファイルを生成すると良い。

次の例は、「example」というChart名を指定して「helm create」コマンドを実行したものだ。このコマンドを実行するとChart名と同一のディレクトリが作成され、そこにChartとして利用するために最低限必要なファイルが作成される。

$ helm create example
Creating example

$ ls -R example/
example/:
Chart.yaml  charts  templates  values.yaml

example/charts:

example/templates:
NOTES.txt  _helpers.tpl  deployment.yaml  ingress.yaml  service.yaml  serviceaccount.yaml  tests

example/templates/tests:
test-connection.yaml

ここでは基本的な設定ファイルやテンプレートに加えて、templates/_helpers.tplといったヘルパーファイルや、テストを記述するtemplates/test/test-connection.yamlといったファイルも作成されていることが分かる。

「helm create」コマンドで作成されたChartには必要な最低限の設定がすべて記述されており、デフォルトではnginxのコンテナイメージをデプロイするよう指定されている。そのため、特に手を加えなくても次のようにインストールが可能だ。

$ helm install example ./example
NAME: example
LAST DEPLOYED: Fri Feb 14 17:41:59 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=example,app.kubernetes.io/instance=example" -o jsonpath="{.items[0].metadata.name}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl --namespace default port-forward $POD_NAME 8080:80

$ helm uninstall example

また、templatesディレクトリ内にはDeploymentを使ってコンテナをデプロイしたり、ルーティングを行うためのServiceリソースを定義したり、外部からサービスにアクセスするためのIngressリソースを定義するための設定ファイルが一通り用意されている。これらはパラメータ設定ファイル（values.yaml）内で定義されているパラメータを参照するようになっており、シンプルなサービスであればこのvalues.yamlファイルを編集するだけで動作するChartが完成する。

これらテンプレートの詳細についてはテンプレートファイル自体やパラメータ設定ファイルのvalues.yamlを見てもらうのが確実だが、values.yamlで定義されているパラメータは次の表7のとおりだ。ただし、今後ひな形ファイルの更新等で仕様が変わる可能性がある点には注意したい。

表7 helm createコマンドで作成されたvalues.yamlファイルで定義されているパラメータ
パラメータ名	説明	対応するプロパティ
replicaCount	デプロイ時のレプリカ数	Deploymentのspec.replicas
image.repository	デプロイするコンテナイメージ	Deploymentのspec.template.spec.containers.image
image.pullPolicy	デプロイ時のPull Policy	Deploymentのspec.template.spec.containers.imagePullPolicy
imagePullSecrets	コンテナイメージをPullする際に使用するDockerレジストリのアカウント情報	Deploymentのspec.template.spec.imagePullSecrets
nameOverride	作成する各種リソースの名前。ここで指定した名前の前にリリース名とハイフンを付けたものが実際の名前となる	（後述）
fullnameOverride	作成する各種リソースの名前。こちらを指定した場合、これがそのまま名前として使われる	（後述）
serviceAccount.create	trueを指定した場合、ServiceAccountが作成される
serviceAccount.annotations	ServiceAccount作成時に指定するannotationsパラメータ	ServiceAccountのmetadata.annotations
serviceAccount.name	作成するServiceAccount名	（後述）
podSecurityContext	Deployment作成時に指定するPodのsecurityContext	Deploymentのspec.template.spec.securityContext
securityContext	Deployment作成時に指定するコンテナのsecurityContext	Deploymentのspec.template.spec.containers.securityContext
service.type	作成するServiceリソースのタイプ	Serviceのspec.type
service.port	作成するServiceリソースに割り当てるポート番号	Serviceのspec.ports.port
ingress.enabled	trueを指定した場合、Ingressリソースが作成される
ingress.annotations	Ingress作成時に指定するannotationsパラメータ	Ingressのmetadata.annotations
ingress.hosts	Ingress作成時に指定するホストルール	Ingressのspec.rules
ingress.tls	Ingress作成時に指定するTLS設定ルール	Ingressのspec.tls
resources	コンテナのリソース設定パラメータ	Deploymentのspec.template.spec.containers.resources
nodeSelector	PodのnodeSelectorパラメータ	Deploymentのspec.template.spec.nodeSelector
tolerations	Podのtolerationsパラメータ	Deploymentのspec.template.spec.tolerations
affinity	Podのaffinityパラメータ	Deploymentのspec.template.spec.affinity

ここでnameOverrideやfullnameOverrideといったパラメータは作成されるリソースの名前を指定するもので、これらパラメータを元に_helpers.tplファイル内で実際に指定する名前を組み立てるようになっている。具体的には、これらのパラメータが指定されていない場合は「＜リリース名＞-＜Chart名＞」が作成される各種リソースの名前になる。nameOverrideパラメータが指定されていた場合、nameOverrideパラメータで指定された値がChart名の代わりに使用される（「＜リリース名＞-＜nameOverrideパラメータで指定された値＞」がリソース名になる）。一方、fullnameOverrideパラメータが指定されていた場合、それがそのままリソース名として使われる。

serviceAccount.nameパラメータについては、これが指定されていない場合はほかのリソースの同じ名前が、指定されていた場合はその値が作成されるServiceAccountの名前として使われる。

また、使用するコンテナイメージはimage.repositoryパラメータで指定できるのだが、タグとしてChart.yamlで記載したappVersionの値が指定される点に注意したい（「＜image.repository＞:＜appVersion＞」というコンテナイメージが使われる）。Chart.yaml内のappVersionパラメータで忘れずに使用するタグを指定しておこう。

これらを踏まえ、実際に独自のChartを作成する際には次のような手順で設定ファイルの修正を行っていけば良い。

Chart.yamlファイルを編集し、Chartの基本的な情報やappVersionを指定する
values.yamlファイルを編集し、使用するコンテナイメージファイルやServiceに割り当てるポート番号、ServiceAccountおよびIngressを作成するかどうかを指定する
templates/deployment.yamlを編集し、作成するPodのパラメータなどを変更する
templates.service.yamlを編集し、使用するポートなどの情報を変更する
必要に応じてserviceaccount.yamlやingress.yamlを編集してパラメータや設定を変更する

もちろんこれ以外のリソース定義が必要な場合や、依存するChartがある場合はそれらに関しての設定変更や設定ファイル編集が必要だ。また、デフォルトのDeployment設定では、「http://＜コンテナのIPアドレス＞/」というURLにアクセスしてコンテナの死活監視を行う設定になっている。必要に応じてURLを変更するか、無効にしておこう。

たとえば次の例は、HTTPでのリクエストに対し指定したテキストを返すだけのテスト用コンテナイメージであるhttp-echo:0.2.3をデプロイするChartを作成するものだ。

1. Chart.yamlを編集し、descriptionなどを変更するとともに、appVersionを0.2.3に変更する

# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application.
appVersion: 0.2.3

2. values.yamlでimage.repositoryを「hashicorp/http-echo」に、service.portを「5678」に設定する。また、http-echoでは「-text」という引数でレスポンスとして送信する文字列を指定できるようになっているので、httpEcho.textというパラメータを追加し、適当なデフォルト文字列（今回は"hello"）を指定する

httpEcho:
  text: "hello"

image:
  repository: hashicorp/http-echo
  pullPolicy: IfNotPresent
：
：
service:
  type: ClusterIP
  port: 5678

3. templates/deployment.yamlを編集し、Pod作成時の引数を指定するspec.template.spec.containers.argsの追加や使用するポートの変更、spec.template.spec.containers.livenessProbeおよびspec.template.spec.containers.readinessProbeの設定変更を行う

：
：
      containers:
        - name: {{ .Chart.Name }}
          securityContext:
            {{- toYaml .Values.securityContext | nindent 12 }}
          image: "{{ .Values.image.repository }}:{{ .Chart.AppVersion }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - name: http
              containerPort: 5678
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /
              port: 5678
          readinessProbe:
            httpGet:
              path: /
              port: 5678
          resources:
            {{- toYaml .Values.resources | nindent 12 }}
          args: [ "-text=\"{{ .Values.httpEcho.text }}\"" ]
       {{- with .Values.nodeSelector }}
：
：

4. templates/service.yamlを編集し、コンテナ側のポート番号を5678に変更する

apiVersion: v1
kind: Service
metadata:
  name: {{ include "example.fullname" . }}
  labels:
    {{- include "example.labels" . | nindent 4 }}
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: 5678
      protocol: TCP
      name: http
  selector:
    {{- include "example.selectorLabels" . | nindent 4 }}

以上の作業完了後、「helm install」コマンドでChartをインストールすると、アプリケーションのデプロイが行われる。

$ helm install example example
NAME: example
LAST DEPLOYED: Fri Feb 14 19:43:24 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=example,app.kubernetes.io/instance=example" -o jsonpath="{.items[0].metadata.name}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl --namespace default port-forward $POD_NAME 8080:80

これで「example」というDeploymentやServiceが作成され、それによってPodが作成される。

$ kubectl get deploy example
NAME      READY   UP-TO-DATE   AVAILABLE   AGE
example   1/1     1            1           16m

$ kubectl get svc example
NAME      TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
example   ClusterIP   10.106.8.38   <none>        5678/TCP   16m

また、ServiceのIPアドレス（この例の場合10.106.8.38）の5678番ポートにHTTPでアクセスすると、values.yamlで指定した文字列がレスポンスとして返される。

$ curl 10.106.8.38:5678
"hello"

今回作成したChartでは、「httpEcho.text」というパラメータで返される文字列を変更できるようになっている。たとえば次のようにしてパラメータを指定して「helm upgrade」コマンドを実行すると、実際に文字列が変更されることが確認できる。

$ helm upgrade example example --set httpEcho.text="foobar"

$ curl 10.106.8.38:5678
"foobar"

リポジトリでChartを公開する

HelmではChartを公開するための独自リポジトリを容易に作成できるようになっており、これを利用すれば簡単に最新バージョンのChartをネットワーク経由でダウンロードしてインストールできるようになる。最後に、このリポジトリの作成方法を紹介しておこう。

Helmで使用するリポジトリ（Chartリポジトリ）では特別なソフトウェアなどは不要で、公開するChartの情報を含む「index.yaml」というインデックスファイルと、tar.gz形式で圧縮したChartをHTTP（もしくはHTTPS）で公開するだけで良い。helmコマンドにはこれらを行うためのサブコマンドも用意されている。

たとえば、先で作成した「example」Chartを公開するリポジトリを作成するには、まずこのChartのディレクトリを丸ごと含むアーカイブファイルを「helm package ＜ディレクトリ＞」コマンドで作成する。

$ helm package example/
Successfully packaged chart and saved it to: /home/hylom/helm_test/mychart/example-0.1.0.tgz

また、index.yamlファイルは「helm repo index ＜ディレクトリ＞」コマンドで作成できる。カレントディレクトリを対象にindex.yamlファイルを作成するには、次のように実行する。

$ helm repo index .

これで、ディレクトリ内にtar.gz形式で圧縮されたChartと、index.yamlが作成された。あとはこれらのファイルを適当なWebサーバーで公開すれば良い。

$ ls
example-0.1.0.tgz  index.yaml

このようにして公開されたChartを利用するには、ほかのChartレポジトリを利用する場合と同様にまず「helm repo add」コマンドでリポジトリを追加する必要がある。たとえば次の例では、「mycharts」という名前でリポジトリの登録を行っている。

$ helm repo add mycharts ＜リポジトリのURL＞

リポジトリの登録後、「helm search repo」コマンドでリポジトリを検索すると、先ほど作成した「example」Chartが利用できるようになっていることが分かる。

$ helm search repo mycharts
NAME                    CHART VERSION   APP VERSION     DESCRIPTION
mycharts/example        0.1.0           0.2.3           A Helm chart for Kubernetes

また、次のように「mycharts/example」と指定して「helm install」コマンドを実行することで、このChartをインストールできる。

$ helm install example mycharts/example

なお、Chartを不特定多数に公開するようなリポジトリを作成する場合にはリポジトリをHTTPSで公開したり、作成者を保証できるようにしたりするための「provenance record」（直訳すると「起源記録」）と呼ばれる情報を記録したファイルをリポジトリ内に用意することが推奨されている。これについて詳しくはドキュメントのHelm Provenance and Integrityページを参照して欲しい。

Kubernetes上へのデプロイ管理ツールとして必要十分、ただ設定関連には慣れが必要

ここまでで解説してきたとおり、Helmの本質はパラメータとテンプレートを使ったマニフェストファイルの自動生成であり、提供している機能は非常にシンプルだ。とはいえ、Kubernetesクラスタにアプリケーションを柔軟性のある形でデプロイするという問題に対しては十分な解決手段となっている。ただ、多くのChartでは設定できるパラメータが膨大になっているという問題もある。柔軟性を確保するためには仕方がないのかもしれないが、ユーザービリティとしてはあまり好ましくない。

一方で、ひな形の自動生成機能を活用することで、シンプルなものであれば比較的容易に独自のChartを作成できる点は便利だ。また、アップグレードやロールバックの仕組みが用意されている点も有用だ。既存のChartを使わず、単に独自のアプリケーションのデプロイツールとして利用するだけでも十分に利用価値がある。すでにHelmはKubernetesの事実上標準的なデプロイ管理ツールとなっていることもあり、習得しておいて損はないだろう。