Helm リリースを管理する

12 分

Helm テンプレートで関数を使用する方法

Helm テンプレート言語によって、values.yaml ファイルから値を変換するために使用する関数が定義されます。関数の構文は、{{ functionName arg1 arg2 ... }} という構造に従います。 quote 関数を例として、この構文を使用する方法を見てみましょう。

quote 関数では、string の使用を示すために、値を引用符で囲みます。次の values.yaml ファイルを定義するとします。

apiVersion: v2
name: webapp
description: A Helm chart for Kubernetes
ingress:
  enabled: true

イングレスマニフェストを生成する必要があるかどうかを判断するときのブール値として、ingress.enabled 値を使用することにします。 enabled 値をブール値として使用するには、{{ .Values.ingress.enabled }} を使用して値を参照します。

後で、フィールドを templates/Notes.txt ファイルで文字列として表示することに決めます。 YAML の型の強制型変換規則によりテンプレート内のバグを見つけるのが難しくなる可能性があるため、ガイダンスに従い、テンプレートに文字列を含めるときは明示的に行うことにします。たとえば、enabled: false は enabled: "false" と同じではありません。

値を文字列として表示するには、{{ quote .Values.ingress.enabled }} を使用して、ブール値を文字列として参照します。

Helm テンプレートでパイプラインを使用する方法

値を操作するために複数の関数が必要な場合は、パイプラインを使用します。パイプラインを使用すると、値または関数の結果を別の関数に "送信する" ことができます。たとえば、上の quote 関数は、{{ .Values.ingress.enabled | quote }} と書き換えることができます。 | は、値を quote 関数に "送信する" ことを示していることに注目してください。

次に別の例を示します。値を大文字に変換し、引用符で囲みたいとします。ステートメントは {{ .Values.ingress.enabled | upper | quote }} のように記述できます。値が upper 関数によって処理された後、quote 関数によって処理されることに注目してください。

テンプレート言語に含まれる 60 以上の関数を使用して、テンプレート内の値とオブジェクトを公開、検索、変換することができます。

Helm テンプレートで条件付きフロー制御を使用する方法

条件付きフロー制御を使用すると、生成されるマニフェストファイルに含める構造またはデータを決定できます。たとえば、デプロイターゲットに基づいて異なる値を含めたり、マニフェストファイルを生成するかどうかを制御したりすることができます。

if / else ブロックはそのような制御フロー構造であり、次のレイアウトに準拠しています。

{{ if | pipeline | }}
  # Do something
{{ else if | other pipeline | }}
  # Do something else
{{ else }}
  # Default case
{{ end }}

特定のケースでのみチャートのイングレスマニフェストファイルを作成することにします。 if ステートメントを使用してそれを行う方法を次に示します。

{{ if .Values.ingress.enabled }}
apiVersion: extensions/v1
kind: Ingress
metadata:
  name: ...
  labels:
    ...
  annotations:
    ...
spec:
  rules:
    ...
{{ end }}

プレースホルダーを使用して、テンプレートにメタデータを設定できることを思い出してください。テンプレートファイルは、テンプレート言語によって上から下に順番に解析および評価されます。前の例では、.Values.ingress.enabled の値が true の場合にのみ、テンプレートエンジンによってマニフェストファイルの内容が生成されます。

テンプレートエンジンで、ステートメントが処理されるときに、{{ }} 構文内で宣言されている内容が削除されて、残りの空白はそのままになります。この構文を使用すると、テンプレートエンジンによって if ステートメント行に改行が組み込まれます。前のファイルの内容をそのままにすると、YAML には空の行があり、イングレスマニフェストファイルが生成されることがわかります。

YAML によって空白文字に意味が与えられます。 "タブ"、"スペース"、"改行文字" が重要と見なされるのはそのためです。不要な空白の問題を解決するには、次のようにファイルを書き直します。

{{- if .Values.ingress.enabled -}}
apiVersion: extensions/v1
kind: Ingress
metadata:
  name: ...
  labels:
    ...
  annotations:
    ...
spec:
  rules:
    ...
{{- end }}

ステートメントの開始 {{- と終了 -}} シーケンスの一部として - 文字が使用されていることに注目してください。 - 文字によって、空白文字を削除するようパーサーに指示されます。 {{- により行の先頭にある空白が削除され、-}} により改行文字を含めて行の末尾にある空白が削除されます。

Helm テンプレート内の値のコレクションを反復処理する方法

YAML を使用すると、項目のコレクションを定義し、テンプレート内の値として個々の項目を使用できます。コレクション内の項目には、インデクサーを使用してアクセスできます。ただし、Helm テンプレート言語によって、range 演算子を使用する値のコレクションの反復処理がサポートされています。

追加のイングレスホストを示す値のリストが values.yaml ファイルで定義されているとします。値の例を以下に示します。

ingress:
  enabled: true
  extraHosts:
    - name: host1.local
      path: /
    - name: host2.local
      path: /
    - name: host3.local
      path: /

range 演算子を使用すると、テンプレートエンジンで .Values.ingress.extraHosts を反復処理できます。次のコードスニペットに、range 演算子を使用する例の抜粋を示します。

{{- if .Values.ingress.enabled -}}
apiVersion: extensions/v1
kind: Ingress
metadata:
  ...
spec:
  rules:
    ...
    {{- range .Values.ingress.extraHosts }}
    - host: {{ .name }}
      http:
        paths:
          - path: {{ .path }}
            ...
    {{- end }}
  ...
{{- end }}

Helm テンプレートで値のスコープを制御する方法

複数レイヤーの深さで値を定義している場合、テンプレートにこれらの値を含めると、構文が長くなり、煩雑になることがあります。 with アクションを使用すると、テンプレート内の変数のスコープを制限できます。

Helm テンプレートで . を使用して現在のスコープを参照することを思い出してください。たとえば、.Values は、現在のスコープ内の Values オブジェクトを検索するようにテンプレートエンジンに指示します。前の values.yaml ファイルを使用して構成マップマニフェストファイルを作成しているとします。

ingress:
  enabled: true
  extraHosts:
    - name: host1.local
      path: /
    - name: host2.local
      path: /
    - name: host3.local
      path: /

{{ .Values.ingress.extraHosts.path }} を使用して各項目の path の値にアクセスするのではなく、with アクションを使用できます。次のコードスニペットに、range 演算子を使用して構成マップマニフェストファイルを生成する例を示します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  {{- with .Values.ingress.extraHosts }}
  hostname: {{ .name }}
  path: {{ .path }}
  {{ end }}

{{- with .Values.ingress.extraHosts }} により、値のスコープが .Values.ingress.extraHosts 配列に制限されます。

with アクションによってスコープが制限されます。親スコープから他のオブジェクトにアクセスすることはできません。また、with コードブロック内でチャートの {{ .Release.Name }} にもアクセスしたいとします。親オブジェクトにアクセスするには、$ 文字を使用するか、コードを書き直して、ルートスコープを指定する必要があります。 $ 文字を使用して親オブジェクトを含める方法を示す更新されたコードを以下に示します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  {{- with .Values.ingress.extraHosts }}
  hostname: {{ .name }}
  path: {{ .path }}
  release: {{ $.Release.Name}}
  {{ end }}

Note

フローを制御するために、Helm テンプレート言語で複数の構造を使用できます。このモジュールのまとめのユニットには、詳細な Helm ドキュメントへのリンクが記載されたセクションがあります。

チャートの依存関係を Helm で定義する方法

チャートにより、メインアプリケーションをサポートするための依存関係を宣言が可能になり、インストールされるリリースの一部が形成されます。

A diagram shows how Helm deploys all subcharts as dependencies of the main chart to a Kubernetes cluster.

サブチャートを作成するには、helm create コマンドを使用するか、/charts フォルダー内に新しいチャートの場所を指定するか、helm dependency コマンドを使用します。 /charts フォルダーに、メインチャートのリリースの一部としてデプロイされるサブチャートを含めることができるのを思い出してください。

helm dependency コマンドを使用すると、Helm リポジトリから含まれる依存関係を管理できます。そのコマンドによって、チャートの values ファイルの dependencies セクションで定義されているメタデータが使用されます。名前、バージョン番号、サブチャートのインストール元のリポジトリを指定します。依存関係として MongoDB チャートが一覧表示されている values.yaml ファイルからの抽出を以下に示します。

apiVersion: v2
name: my-app
description: A Helm chart for Kubernetes
...
dependencies:
  - name: mongodb
    version: 10.27.2
    repository: https://marketplace.azurecr.io/helm/v1/repo

依存関係のメタデータを定義したら、helm dependency build コマンドを実行して、tar パッケージ化されたチャートをフェッチします。チャートビルドコマンドにより、チャートが charts/ フォルダーにダウンロードされます。

helm dependency build ./app-chart

サブチャートは、メインチャートとは別に管理され、新しいリリースが使用可能になったら更新が必要になる場合があります。サブチャートを更新するコマンドは helm dependency update です。このコマンドを使って、古いパッケージを削除し、新しいバージョンのサブチャートをフェッチします。

helm dependency update ./app-chart

チャートの依存関係が他のアプリケーションに限定されるわけではないことにご注意ください。チャート全体でテンプレートロジックを再利用し、特にこのロジックをチャートの依存関係として管理するために依存関係を作成するように決定できます。この戦略の例については、次の演習で示します。

Helm リリースをアップグレードする方法

Helm を使用すると、チャートとその依存関係に適用されるすべての変更の差分として、既存のリリースをアップグレードできます。

A diagram shows how the Helm upgrade command creates a delta of all changed items in a Helm chart to upgrade a release and create a new release revision on a Kubernetes cluster.

たとえば、このユニットの webapp のの例の開発チームが、Web サイトの機能にのみ影響を与えるコード変更を行うとします。チームは、新しいバージョンのアプリケーションを反映するように、Chart.yaml ファイルに対して次の更新を行います。

Web アプリのコンテナーイメージを更新し、コンテナーレジストリにイメージをプッシュするときに、イメージに webapp: linux-v2 というタグを付けます。
チャートの values ファイルで、dockerTag の値を linux-v2 に、チャートのバージョンの値を 0.2.0 に、それぞれ更新します。

更新された values.yaml ファイルの例を次に示します。

apiVersion: v2
name: my-app
description: A Helm chart for Kubernetes

type: application

version: 0.2.0
appVersion: 1.0.0

registry: "my-acr-registry.azurecr.io"
dockerTag: "linux-v2"
pullPolicy: "Always"

現在のリリースをアンインストールするのではなく、helm upgrade コマンドを使用して、既存の Helm リリースをアップグレードします。

helm upgrade my-app ./app-chart

リリースをアップグレードするときは、Helm で、Helm チャートに対して行われた変更の差分が生成されることを覚えておいてください。そのため、Helm のアップグレードでは、差分に示されているコンポーネントのみがアップグレードされます。この例では、Web サイトだけが再デプロイされます。

アップグレードが完了すると、リリース名を指定した helm history コマンドを使用して、リリースのデプロイ履歴を確認できます。

helm history my-app

次の出力例に示すように、history コマンドからは、リリースを説明するいくつかのフィールドが返されます。

REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Mon Oct 11 17:25:33 2021        deployed        aspnet-core-1.3.18      3.1.19          Install complete

結果の revision フィールドに注目してください。 Helm により、Helm チャートに対して行われたすべてのリリースのリリース情報が追跡されます。新しいバージョンの Helm チャートをインストールすると、リビジョン番号が 1 だけ大きくなり、新しいリリース情報がそのリビジョンと照合されます。

以下に示すのは、Web アプリの新しいバージョンをインストールした後で同じ history コマンドを実行した場合の例です。

REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Mon Oct 11 17:25:33 2021        superseded      aspnet-core-1.3.18      3.1.19          Install complete
2               Mon Oct 11 17:35:13 2021        deployed        aspnet-core-1.3.18      3.1.19          Upgrade complete

Helm リリースをロールバックする方法

Helm によって、既存の Helm リリースを以前にインストールしたリリースにロールバックできます。前述のとおり、Helm により Helm チャートのすべてのリリースのリリース情報が追跡されることを思い出してください。

特定の Helm リリースリビジョンにロールバックするには、helm rollback コマンドを使用します。このコマンドにより 2 つのパラメーターが使用されます。 1 番目のパラメーターではリリースの名前を示し、2 番目のパラメーターではリリースのリビジョン番号を示します。

helm rollback my-app 2

helm rollback コマンドを使用すると、アプリのリリースバージョンが指定したリビジョンにロールバックされ、アプリのリリース履歴が更新されます。続いて helm history コマンドを実行すると、最新のリリースエントリとして最新のアクティブなリビジョン番号が表示されます。

たとえば、このユニットの webapp の例の開発チームは、ドローン追跡 Web アプリケーションのバグを検出し、以前のリリースにロールバックする必要があるとします。現在のリリースをアンインストールし、以前のバージョンをインストールする代わりに、作業中のリリースにロールバックします。

helm rollback my-app 1

ロールバックが完了すると、helm history コマンドを使用してデプロイの履歴を確認できます。

REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Mon Oct 11 17:25:33 2021        superseded      aspnet-core-1.3.18      3.1.19          Install complete
2               Mon Oct 11 17:35:13 2021        superseded      aspnet-core-1.3.18      3.1.19          Rolled back to 1
3               Mon Oct 11 17:38:13 2021        deployed        aspnet-core-1.3.18      3.1.19          Upgrade complete

変更を追跡しやすいよう、description フィールドにロールバックのリビジョン番号が表示されていることに注目してください。

自分の知識をチェックする

たとえば、Web アプリケーションと、オンライン注文を処理するサービスという 2 つの重要なコンポーネントを含むソフトウェアソリューションがあるとします。両方のコンポーネントはどちらもオンライン注文処理パイプラインの一部ですが、相互に依存関係はありません。 Helm を使用してこれら 2 つのアプリケーションをデプロイするときに最適な方法はどちらですか?

両方のアプリケーションで 1 つの Helm チャートを作成するが、どちらのチャートも他方の依存関係として設定しない。

アプリケーションごとに 1 つずつ、2 つの別々の Helm グラフを作成する。

両方のアプリケーションに対して 1 つの Helm チャートを作成し、注文を処理するサービスを依存チャートとして設定する。

たとえば、Web サイトを重要なコンポーネントの 1 つとして含むソフトウェアソリューションがあるとします。 Web サイトは、キャッシュサービスに依存する唯一のコンポーネントです。 Helm を使用してこれら 2 つのアプリケーションをデプロイするときに最適な方法はどちらですか?