---
title: "高度な Helm のテクニック"
description: "Helm パワーユーザー向けのさまざまな高度な機能について説明します"
weight: 9
---

このセクションでは、Helm を使用するためのさまざまな高度な機能とテクニックについて説明します。
このセクションの情報は、チャートとリリースの高度なカスタマイズと操作を行いたい
Helm の「パワーユーザー」を対象としています。
これらの高度な機能にはそれぞれ独自のトレードオフと警告があり、
Helm の深い知識を駆使して慎重に使用する必要があります。
言い換えれば、[ピーター・パーカーの原則](https://en.wikipedia.org/wiki/With_great_power_comes_great_responsibility)
を覚えておいてください

## ポストレンダリング
ポストレンダリングにより、チャートインストーラーは、Helm によってインストールされる前に、
レンダリングされたマニフェストを手動で操作、構成、または検証することができます。
これにより、高度な構成を持つユーザーは、[`kustomize`](https://kustomize.io) などのツールを使用して、
パブリックチャートをフォークしたり、
チャートのメンテナーがソフトウェアの最後の構成オプションをすべて指定したりする必要なく、
構成の変更を適用できます。
エンタープライズ環境での一般的なツールやサイドカーの注入、
展開前のマニフェストの分析のユースケースもあります。

### 前提条件
- Helm 3.1+

### 使い方
ポストレンダラーは、STDIN でレンダリングされた Kubernetes マニフェストを受け入れ、
STDOUT で有効な Kubernetes マニフェストを返す任意の実行可能ファイルです。
失敗した場合は、0 以外の終了コードを返します。
これは、2つのコンポーネント間の唯一の "API" です。
これにより、ポストレンダリングプロセスで実行できる操作に大きな柔軟性がもたらされます。

ポストレンダラーは、`install`、`upgrade`、および `template` で使用できます。
ポストレンダラーを使用するには、
使用するレンダラー実行可能ファイルへのパスで `--post-renderer` フラグを使用します。

```shell
$ helm install mychart stable/wordpress --post-renderer ./path/to/executable
```

パスにセパレータが含まれていない場合は、$PATH で検索されます。
それ以外の場合は、相対パスが完全修飾パスに解決されます。

複数のポストレンダラーを使用したい場合は、それらをすべてスクリプトで呼び出すか、
ビルドしたバイナリツールで一緒に呼び出します。
bash では、これは `renderer1 | renderer2 | renderer3` のように単純です。

`kustomize` をポストレンダラーとして使用する例は
[here](https://github.com/thomastaylor312/advanced-helm-demos/tree/master/post-render)で見ることができます。

### Caveats
When using post renderers, there are several important things to keep in mind.
The most important of these is that when using a post-renderer, all people
modifying that release **MUST** use the same renderer in order to have
repeatable builds. This feature is purposefully built to allow any user to
switch out which renderer they are using or to stop using a renderer, but this
should be done deliberately to avoid accidental modification or data loss.

One other important note is around security. If you are using a post-renderer,
you should ensure it is coming from a reliable source (as is the case for any
other arbitrary executable). Using non-trusted or non-verified renderers is NOT
recommended as they have full access to rendered templates, which often contain
secret data.

### Custom Post Renderers
The post render step offers even more flexibility when used in the Go SDK. Any
post renderer only needs to implement the following Go interface:

```go
type PostRenderer interface {
    // Run expects a single buffer filled with Helm rendered manifests. It
    // expects the modified results to be returned on a separate buffer or an
    // error if there was an issue or failure while running the post render step
    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)
}
```

For more information on using the Go SDK, See the [Go SDK section](#go-sdk)

## Go SDK
Helm 3 debuted a completely restructured Go SDK for a better experience when
building software and tools that leverage Helm. Full documentation can be found
at [https://pkg.go.dev/helm.sh/helm/v3](https://pkg.go.dev/helm.sh/helm/v3), but a brief overview of some of the most
common packages and a simple example follow below.

### Package overview
This is a list of the most commonly used packages with a simple explanation
about each one:

- `pkg/action`: Contains the main “client” for performing Helm actions. This is
  the same package that the CLI is using underneath the hood. If you just need
  to perform basic Helm commands from another Go program, this package is for
  you
- `pkg/{chart,chartutil}`: Methods and helpers used for loading and manipulating
  charts
- `pkg/cli` and its subpackages: Contains all the handlers for the standard Helm
  environment variables and its subpackages contain output and values file
  handling
- `pkg/release`: Defines the `Release` object and statuses

Obviously there are many more packages besides these, so go check out the
documentation for more information!

### Simple example
This is a simple example of doing a `helm list` using the Go SDK:

```go
package main

import (
    "log"
    "os"

    "helm.sh/helm/v3/pkg/action"
    "helm.sh/helm/v3/pkg/cli"
)

func main() {
    settings := cli.New()

    actionConfig := new(action.Configuration)
    // You can pass an empty string instead of settings.Namespace() to list
    // all namespaces
    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil {
        log.Printf("%+v", err)
        os.Exit(1)
    }

    client := action.NewList(actionConfig)
    // Only list deployed
    client.Deployed = true
    results, err := client.Run()
    if err != nil {
        log.Printf("%+v", err)
        os.Exit(1)
    }

    for _, rel := range results {
        log.Printf("%+v", rel)
    }
}

```

## Storage backends

Helm 3 changed the default release information storage to Secrets in the namespace
of the release. Helm 2 by default stores release information as ConfigMaps in the
namespace of the Tiller instance. The subsections which follow show how to
configure different backends. This configuration is based on the `HELM_DRIVER` 
environment variable. It can be set to one of the values: `[configmap, secret]`.

### ConfigMap storage backend

To enable the ConfigMap backend, you'll need to set the environmental variable
`HELM_DRIVER` to `configmap`.

You can set it in a shell as follows:

```shell
export HELM_DRIVER=configmap
```

If you want to switch from the default backend to the ConfigMap
backend, you'll have to do the migration for this on your own. You can retrieve
release information with the following command:

```shell
kubectl get secret --all-namespaces -l "owner=helm"
```

**PRODUCTION NOTES**: The release information might contain sensitive data
(like passwords, private keys, and other credentials) that needs to be protected
from unauthorized access. When managing Kubernetes authorization, for instance with 
[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), it
is possible to grant broader access to ConfigMap resources, while restricting
access to Secret resources. For instance, the default
[user-facing role](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)
"view" grants access to most resources, but not to Secrets. Furthermore, secrets data can be
configured for [encrypted storage](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/).
Please keep that in mind if you decide to switch to the ConfigMap backend, as it
could expose your application's sensitive data.
