⛑️
What is Helm?
OverView
- 一言で表現するとKubernetes用パッケージマネージャー
| パッケージマネージャー | パッケージ | |
|---|---|---|
| 主にJava | maven | jar,war,ear |
| Linux | yum | rpm package |
| Kubernetes | helm | (helm)chart |
- 開発者／運用者はアプリケーションやサービスのパッケージ化、設定、Kubernetesクラスタへの展開を容易に行うことが可能となる
- CNCF Graduated Project(卒業済)
Helm was accepted to CNCF on June 1, 2018 at the Incubating maturity level and then moved to the Graduated maturity level on May 1, 2020.
- Helmのlogo
登場した背景
- Kubernetesには以下の弱点がある
- そもそもYAMLのパッケージコントロールする術がない。
- 各YAML単体のバージョン管理はGitで可能だが、各オブジェクトを纏めてバージョン管理することは出来ない。
- YAMLの依存関係を制御する仕組みがなく、人手に頼る必要があり、NameSpace→PostgreSQL→PVなど複数のオブジェクトを１つのYAMLに記載することは可能だが、大量に存在するオブジェクトをコマンド１つで削除することは不可能である。
- 多くのYAMLファイルを作成することは煩雑であるため、「wall of YAML」、「YAML地獄に陥る」などネガティブな言葉も囁かれている。
- Helmが上記の問題を解決してくれる
- Kubernetes単体だと各オブジェクトのYAMLを作成・順序性を意識して実行・メンテナンスする必要があるが、Chartという形式にパッケージ化することで、１つのインストールコマンドを実行するだけでアプリや環境構築が可能となる。これにより誰がどこの環境（オンプレ／パブリッククラウド）で実行しても同じ環境を再現可能となる。
- 主要なパッケージ（例えばJenkinsなど）はChartが公開されているため、ダウンロードしてオンプレ／パブリッククラウドなど任意の環境にて実行し環境構築を行うことが可能である。
- Kubernetesとの連携によりChartにて作成した環境やアプリのアップグレード・ロールバックもコマンド１つで実行可能。Chart以外で実行した設定変更についても新旧のChartと現在の設定を比較して整合性を確保した上でさらに環境変更することが可能（3-wayマージ）
Helmのコンポーネントと実行環境
- コンポーネント
- Chart
- Kubernetesのリソースを事前定義したHelmのパッケージ。
- アプリケーション・環境構築を行う際に必要となるYAMLを纏めたパイプライン、ジョブネットのようなイメージ
- クライアントサイドで作成したChartをKubernetesのAPIを介してインストール（目的のアプリ構築や環境構築が完了）する。同じチャートを実行すれば異なる環境、異なる人が実行しても同じ環境の再現が可能となる。
- repository
- Chartの保管場所。単純なファイルサーバでもOKだしGitHubにて管理するでもOK。Jenkinsであればhttps://charts.jenkins.ioが正式なrepositoryとなる。
- Release
- Helm Chartのインストールが完了すると構成情報などを含むReleaseが作成される。同じ環境にChartを複数実行することも可能なため、ChartとReleaseは１：Nの関係となる場合がある。イメージとしては同じChartを開発環境用、本番環境用など複数環境を構築した場合にChartとReleaseが１：Nとなる。
- Relaseの実態はKubernetesのSecretとして保管される。
- Chart
- 実行環境
- 別途サーバ等の構築は不要（旧バージョンは必要だった）
- Kubernetesクラスタのアーキテクチャーに影響を与えずに利用可能。ReleaseのSecretが保存されるのみ
- クライアント
- CLI実行用のユーザ向けクライアント
- Chart作成、repository管理、ChartのPull・Download、Release情報の確認、既存ReleaseのUpdate/Uninstallなどの機能がある
Helm Chartファイル構成
<チャート名ディレクトリ>/
Chart.yaml # チャートの概要が記述されたYAMLファイル(ファイル名は予約)
LICENSE # オプション:このチャートのライセンス情報
README.md # オプション: チャートの説明
requirements.yaml # オプション: このチャートが利用する(依存する)他のチャートの一覧。(ファイル名は予約)
values.yaml # このチャートのデフォルト設定値が定義されたYAMLファイル。ファイル名は予約)
charts/ # このチャートが依存するチャートをコピー配置するディレクトリ(ディレクトリ名は予約)
templates/ # チャートの本体ともいえる、KubernetesオブジェクトのリソースYAMLのテンプレート群を配置するディレクトリ(ディレクトリ名は予約)
templates/NOTES.txt # オプション:利用方法を生成するテキストファイル
tests/ # オプション:helm testで実行されるテスト用YAMLを配置するディレクトリ(ディレクトリ名は予約)
環境構築
クライアントインストール
- Helmクライアントの準備
curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-amd64 -o /usr/local/bin/helm chmod +x /usr/local/bin/helm helm version
リポジトリの追加
- k8s公式リポジトリ追加例。その他Redhatが公開しているリポジトリなどもある。
$ helm repo add stable https://kubernetes-charts.storage.googleapis.com/ $ helm repo update
OpenShift LocalにGitHub runnerを構築
- こちらを参考にhelmによる構築を実施。
https://github.com/redhat-actions/openshift-actions-runner-chart - 各製品の構築はhelmを利用するケースが多いと思うが、helmインストール→github runnerリポジトリ登録（helm repo add）→helm installで必要な環境変数設定→helm installにてrunnerで必要なpod作成まで自動で完了。
- リポジトリ追加・リポジトリアップデート
helm repo add openshift-actions-runner \
https://redhat-actions.github.io/openshift-actions-runner-chart \
&& helm repo update
- インストール（runner pod作成、GitHub runner登録まで実施）
# Installing using PAT Auth
helm install $RELEASE_NAME openshift-actions-runner/actions-runner \
--set-string githubPat=$GITHUB_PAT \
--set-string githubOwner=$GITHUB_OWNER \
--set-string githubRepository=$GITHUB_REPO \
&& echo "---------------------------------------" \
&& helm get manifest $RELEASE_NAME | oc get -f -
参考
Discussion