Day 20: Helm入門:複雑なアプリケーションを簡単にデプロイする ⚙️
皆さん、こんにちは!30日集中講座、Day 20へようこそ。
昨日までに、Kubernetesの基本的なリソース(Pod, Deployment, Serviceなど)を学びました。しかし、Webアプリケーション、データベース、キャッシュサーバーなど、複数のコンポーネントからなる複雑なアプリケーションをデプロイする場合、それぞれのYAMLファイルを手動で管理するのは非常に手間がかかります。
そこで今回は、KubernetesのパッケージマネージャーであるHelmについて学びます。Helmを使うことで、複雑なアプリケーションのデプロイ、管理、バージョンアップを簡単に自動化できるようになります。例えば、WordPressサイトをデプロイする場合を考えてみましょう。
-
手動: Deployment、Service、Secret、PersistentVolumeClaimなど、10個以上のYAMLファイルを個別に管理し、
kubectl applyを何度も実行する必要があります。 -
Helm:
helm install my-wordpress bitnami/wordpressとコマンド一行で完了します。
1. Helmとは?
Helmは、Kubernetesのアプリケーションをパッケージ化し、一元管理するためのツールです。Linuxのパッケージマネージャー(aptやyum)を想像すると分かりやすいでしょう。
- Chart (チャート): Kubernetesアプリケーションのパッケージです。
- Release (リリース): Helm ChartがKubernetesクラスターにデプロイされたインスタンスです。Helmはリリースごとに履歴を管理し、簡単にロールバックできます。
Helm 3以降では、以前のサーバーコンポーネント(Tiller)が廃止され、シンプルなクライアント専用ツールになりました。
2. Helm Chartの構造とvalues.yamlの活用
Helm Chartは、以下のようなディレクトリ構造で構成されます。
my-chart/
├── Chart.yaml # チャートに関するメタデータ
├── values.yaml # 設定可能な変数(デフォルト値)
├── templates/ # KubernetesリソースのYAMLテンプレート
│ ├── deployment.yaml
│ └── service.yaml
└── charts/ # 依存する他のチャート
依存関係の管理
Chart.yamlに依存関係を定義することで、他のChartを簡単に組み込めます。
# Chart.yaml での依存関係定義例
dependencies:
- name: postgresql
version: "11.6.12"
repository: "https://charts.bitnami.com/bitnami"
condition: postgresql.enabled
helm dependency updateコマンドで、依存Chartをcharts/ディレクトリにダウンロードできます。
テンプレートとvalues.yamlの連携例
templates/deployment.yamlに以下のようなテンプレートを記述すると、values.yamlに定義された値で置き換えられます。
# templates/deployment.yaml (一部)
spec:
replicas: {{ .Values.replicaCount }}
containers:
- name: my-app
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
これに対応するvalues.yamlの例は以下の通りです。
# values.yaml の例
replicaCount: 3
image:
repository: nginx
tag: "1.21"
Helm Valuesの優先順位
複数のvaluesを指定する場合、以下の優先順位で適用されます。
--setコマンドライン引数 > -fで指定したファイル > Chart.yaml内のデフォルト値
3. Helmの基本コマンドと実践
Chart作成とデプロイの基本フロー
# Chartのひな形を作成
helm create my-app
cd my-app
# 構文チェックとテンプレート確認
helm lint .
helm template . --debug
# Bitnamiリポジトリを追加
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
カスタム値でのデプロイ
custom-values.yamlファイルを作成し、helm installでデプロイします。
# custom-values.yaml
cat <<EOF > custom-values.yaml
replicaCount: 2
service:
type: NodePort
EOF
# カスタム値でデプロイ
helm install my-nginx bitnami/nginx -f custom-values.yaml
アプリケーションの更新と管理
インストール後のアプリケーションを更新する場合は、helm upgradeコマンドを使います。
# レプリカ数を5に変更してリリースを更新
helm upgrade my-nginx bitnami/nginx --set replicaCount=5
# リリース履歴の確認
helm history my-nginx
# 履歴からバージョン1にロールバック
helm rollback my-nginx 1
トラブルシューティング
-
Helm特有の診断コマンド:
helm status my-nginx # リリース状態確認 helm get values my-nginx # 現在の設定値確認 helm get manifest my-nginx # 実際にデプロイされたYAML確認 -
よくあるエラーパターンと対処法:
# 1. ImagePullBackOff (イメージが取得できない) kubectl describe pod <pod-name> # イベントログで原因確認 # 2. CrashLoopBackOff (コンテナが起動に失敗) kubectl logs <pod-name> --previous # 前回実行ログ確認 # 3. Pending状態 kubectl get events --sort-by='.metadata.creationTimestamp' # スケジューリング制約確認
4. セキュリティとベストプラクティス
-
--dry-runオプション:helm install --dry-run --debugコマンドで、デプロイ前にYAMLファイルをレンダリングして確認できます。 -
シークレット管理:
values.yamlにパスワードなどの機密情報を直接書くのは絶対に避けてください。以下のコマンド例のように、既存のSecretを参照するのが安全です。
# ❌ Bad: values.yamlに直接書く
# database:
# password: "hardcoded-password"
# ✅ Good: 既存のSecretを参照
database:
existingSecret: "db-credentials"
passwordKey: "password"
- セキュリティの誤解: Kubernetes SecretはBase64でエンコードされるだけで、暗号化はされていません。Secretへのアクセスは、RBAC(Role-Based Access Control)によって厳格に制御されます。
5. 手動YAML管理 vs Helm
| 項目 | 手動YAML管理 | Helm |
|---|---|---|
| 複数リソース管理 | 個別にkubectl apply
|
helm installで一括管理 |
| バージョン管理 | Git履歴に頼る | 内蔵機能でリリース履歴を管理 |
| ロールバック | 手動で前のYAMLを再適用 |
helm rollbackで簡単に復旧 |
| 設定管理 | 複数のYAMLファイル | 単一のvalues.yamlでテンプレート化 |
6. 演習課題
-
helm create my-appで新しいChartを作成してください。 -
values.yamlを編集してレプリカ数を変更し、helm installでデプロイしてください。 -
helm upgradeで設定を変更し、Podの数が増えることを確認してください。 -
helm rollbackで前のバージョンに戻してください。
✅ 理解度チェック
- Chartとは何か、説明できますか?
-
values.yamlの役割は? - アプリケーションをロールバックする方法は?
次回の予告
Day 21: 第3週のまとめ:EKSでのWebアプリデプロイ実践
それでは、また明日お会いしましょう!