19 Commits
Author SHA1 Message Date
Gitea Actions Bot 1d8fb1a308 chore: update to WordPress 7.1.3, nginx 1.31.6-alpine-perl 2026-10-11 00:00:17 +00:00
Gitea Actions Bot d75d1942e5 chore: update to WordPress 7.1.2, nginx 1.31.6-alpine-perl 2026-09-27 00:00:16 +00:00
Gitea Actions Bot af13a13ae0 chore: update to WordPress 7.1.1, nginx 1.31.6-alpine-perl 2026-09-20 00:00:14 +00:00
claude 6d1b7bc8d6 feat: 外部Secret連携(extraEnvFrom / extraEnv / SMTP existingSecret)を追加
Helm Chart Release / release-chart (push) Successful in 6s
helmchart/secret-manager が各ネームスペースへ配布する cred-* Secret を
WordPress 側から参照できるようにする(phpfpm と同一方針)。
- extraEnvFrom / extraEnv: 既存 Secret/ConfigMap を wordpress コンテナへ env 注入
- smtp.auth.existingSecret / existingSecretKey: パスワードファイルだけ既存 Secret から取得
- smtp.existingMsmtprcSecret / existingMsmtprcSecretKey: 完成済み msmtprc を
  そのままマウント(指定時は configmap-smtp を生成せず host/port/auth.* は無視)
既定値は全て空のため既存挙動は不変。手動リリース 7.1.0-b。
2026-09-08 14:16:14 +09:00
Gitea Actions Bot f16184f98d chore: update nginx to 1.31.5-alpine-perl (no release) 2026-09-06 00:00:14 +00:00
claude d1dea3de7d docs: CLAUDE.md を階層化した共通ルールに合わせて整理し、GEMINI.md と .agents/rules(Antigravity 用参照)を追加
Helm Chart Release / release-chart (push) Successful in 5s
2026-09-04 13:23:56 +09:00
claude 30e377d4ec fix: Hello Dolly等のデフォルトプラグインが再起動のたびに復活する不具合を修正
Helm Chart Release / release-chart (push) Successful in 5s
wordpress-init initContainerのコアファイルコピー処理(cp -r /usr/src/wordpress/* /var/www/html/)が
wp-contentを除外しておらず、PVC上の既存wp-contentへイメージ同梱のデフォルトファイル
(hello.php、akismet/、デフォルトテーマ)を毎回上書きマージしていた。
コピー対象からwp-contentを除外し、PVC上のwp-contentは新規インストール時以外
一切触れないよう修正。
2026-08-26 11:13:48 +09:00
Gitea Actions Bot 93432e2613 chore: update to WordPress 7.1.0, nginx 1.31.4-alpine-perl 2026-08-23 00:00:19 +00:00
Gitea Actions Bot 2d6516037d chore: update to WordPress 7.0.4, nginx 1.31.3-alpine-perl 2026-08-16 00:00:20 +00:00
claude 8241812d84 docs: kube-vip環境での実IP喪失原因と共有Ingress Controller移行手順を追記
Helm Chart Release / release-chart (push) Successful in 6s
mikoto-wordpress-nginxの調査で、type: ClusterIP + kube-vipアノテーション
による手動VIP付与構成では、kube-vip自体がTCP接続をプロキシするため
externalTrafficPolicyを設定しても実クライアントIPが失われることが判明。
共有Ingress Controller(Cilium組み込み等)へ移行する場合の具体的な
values設定とhelm upgradeコマンド例をREADMEに追加。
クラスタ構成の調査結果をCLAUDE.mdに記録。
2026-08-09 16:20:40 +09:00
claude 40ca516249 fix: 実IPアドレス取得とメール送信の不具合を修正
Helm Chart Release / release-chart (push) Successful in 6s
- service.externalTrafficPolicy: Local を追加し、kube-proxyのSNATによる
  実IPアドレス消失を解消(ベアメタル/MetalLB構成向け)
- wp-config.php内の危険な二重REMOTE_ADDR上書き処理を削除
  (Nginx real_ipモジュールの信頼境界を迂回できるIP詐称の余地があった)
- smtp.* 設定を追加し、msmtp経由の外部SMTPリレー送信に対応
  (helmchart/phpfpm と同一の実装パターンを踏襲)
- README.md / CLAUDE.md を更新
2026-08-08 00:24:05 +09:00
Gitea Actions Bot 2d698e6148 chore: update to WordPress 7.0.2, nginx 1.31.3-alpine-perl 2026-07-28 09:22:59 +00:00
Gitea Actions Bot f6980d92df chore: update to WordPress 7.0.0, nginx 1.31.1-alpine-perl 2026-05-24 00:00:59 +00:00
Gitea Actions Bot ea0cca53a6 chore: update nginx to 1.31.0-alpine-perl (no release) 2026-05-17 00:00:18 +00:00
Gitea Actions Bot 1982218ab2 chore: update nginx to 1.30.0-alpine-perl (no release) 2026-04-19 00:00:23 +00:00
Gitea Actions Bot 999f0ae02b chore: update nginx to 1.29.8-alpine-perl (no release) 2026-04-12 00:00:47 +00:00
Gitea Actions Bot 07e55191f9 chore: update nginx to 1.29.7-alpine-perl (no release) 2026-03-29 00:00:23 +00:00
pieter 449d87c314 Chart.yaml を更新
Helm Chart Release / release-chart (push) Successful in 5s
Update Docker Image Tags and Release Helm Chart / update-and-release (push) Successful in 10s
2026-03-21 22:20:13 +00:00
claudeandClaude Sonnet 4.6 34c74db6f7 fix: publish Helm chart to Gitea Package Registry instead of gh-pages
Helm Chart Release / release-chart (push) Successful in 6s
gh-pagesブランチへの独自index.yaml生成を廃止し、
helm-release.yamlと同じGitea Package Registry
(https://git.cafepieters.com/api/packages/helmchart/helm/)
への直接publishに統一。

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-03-19 21:07:41 +09:00
12 changed files with 545 additions and 64 deletions
+7
View File
@@ -0,0 +1,7 @@
---
trigger: always_on
description: Read the CLAUDE.md hierarchy via GEMINI.md before doing anything in this workspace
---
最初に、このディレクトリの `GEMINI.md` を読み、そこに列挙された CLAUDE.md を上から順にすべて読んで従うこと。
Read `GEMINI.md` in this directory first, then read and follow every CLAUDE.md it lists, in order.
+8 -39
View File
@@ -248,7 +248,7 @@ jobs:
echo "Release v${APP_VERSION} created with asset ${PACKAGE_FILE}" echo "Release v${APP_VERSION} created with asset ${PACKAGE_FILE}"
fi fi
- name: Update Helm Repository Index - name: Publish to Gitea Package Registry
if: steps.check_update.outputs.wp_updated == 'true' if: steps.check_update.outputs.wp_updated == 'true'
run: | run: |
set -e set -e
@@ -256,46 +256,15 @@ jobs:
CHART_NAME=$(grep '^name:' Chart.yaml | awk '{print $2}') CHART_NAME=$(grep '^name:' Chart.yaml | awk '{print $2}')
PACKAGE_FILE="${CHART_NAME}-${APP_VERSION}.tgz" PACKAGE_FILE="${CHART_NAME}-${APP_VERSION}.tgz"
echo "Preparing Helm repository update..." echo "🚀 Publishing ${PACKAGE_FILE} to Gitea Package Registry..."
# パッケージファイルを一時ディレクトリに移動 curl --fail-with-body \
mkdir -p /tmp/helm-repo -u "${{ secrets.REGISTRY_USER }}:${{ secrets.REGISTRY_TOKEN }}" \
cp "${PACKAGE_FILE}" /tmp/helm-repo/ -X POST \
--upload-file "${PACKAGE_FILE}" \
"https://git.cafepieters.com/api/packages/helmchart/helm/api/charts"
# gh-pagesブランチの処理 echo "✅ Chart published successfully to Gitea Package Registry"
if git ls-remote --heads origin gh-pages | grep gh-pages; then
echo "gh-pages branch exists, checking out..."
git fetch origin gh-pages
git checkout gh-pages
else
echo "Creating new gh-pages branch..."
git checkout --orphan gh-pages
git rm -rf . || true
echo "# Helm Repository" > README.md
git config user.name "Gitea Actions Bot"
git config user.email "actions@git.cafepieters.com"
git add README.md
git commit -m "Initialize gh-pages branch"
git push origin gh-pages
fi
# パッケージファイルをコピー
cp /tmp/helm-repo/"${PACKAGE_FILE}" .
# index.yamlを生成/更新
helm repo index . --url "https://git.cafepieters.com/${GITHUB_REPOSITORY}/raw/branch/gh-pages"
# コミットしてプッシュ
git config user.name "Gitea Actions Bot"
git config user.email "actions@git.cafepieters.com"
git add "${PACKAGE_FILE}" index.yaml
git commit -m "chore: add ${CHART_NAME} v${APP_VERSION}" || echo "No changes to commit"
git push origin gh-pages
echo "Helm repository updated successfully"
# mainブランチに戻る
git checkout main
- name: Summary - name: Summary
if: always() if: always()
+2
View File
@@ -0,0 +1,2 @@
# Claude Code local settings
.claude/
+90
View File
@@ -0,0 +1,90 @@
# CLAUDE.md — WordPress Helm Chart
> **共通ルール(要約)** — 詳細は `P:\Claude\CLAUDE.md`(全体共通)と `P:\Claude\HelmChart\CLAUDE.md`(Helm チャート共通: リリースフロー・ワークフロー・クラスタ構成)を参照。
> 作業前に pull / 機能変更時は README 更新 / 作業単位ごとに commit → push まで / コミットに AI クレジットを付けない / pull で入った変更を revert しない / Helm・PHP はローカル実行不可(Python のみ可)。
## リポジトリ概要
Raspberry Pi などのベアメタルで稼働することを想定した、Kubernetes 上で動作する Alpine Nginx + WordPress (PHP-FPM) の Helm チャート。
- **Gitea リポジトリ**: `ssh://git@192.168.9.65/helmchart/wordpress`
- **Helm リポジトリ**: `https://git.cafepieters.com/api/packages/helmchart/helm`
## 実行環境について
WordPress本体はイメージ内蔵のもの(`docker.io/wordpress:<tag>-fpm-alpine`)をemptyDirにコピーして使い捨てで起動し、`wp-content`のみPVCで永続化する(bitnami方式)。PHPの実行環境はこのイメージに依存し、本リポジトリにPHPコードは含まれない。
## 設計上の注意(このチャート固有)
- `templates/service.yaml` には annotations のテンプレート化が存在しないため、kube-vip 用アノテーションは Helm 管理外で手動付与する運用になっている(クラスタ全体の事情は組織 CLAUDE.md「実運用クラスタ構成」を参照)。
- 実 IP 取得(`ingress.yaml` / `nginx.forwardRealIP`)は既存機能で対応済み。Cilium Ingress への移行手順は README に記載。
## チャート改修履歴
### 外部Secret連携(extraEnvFrom / extraEnv / SMTP existingSecret)を追加(2026-09-08, v7.1.0-b)
**背景**: 別リポジトリの `helmchart/secret-manager` チャートが各ネームスペースへ配布する
`cred-<名前>` Secret(メールの msmtprc / API キー)を WordPress 側から参照する口が無かった。
phpfpm チャートと同一方針で受け口を追加(ユーザー指定によりパターンを踏襲)。
**修正内容**:
- `values.yaml` に `extraEnvFrom`(`envFrom` 配列)と `extraEnv`(生の env エントリ配列)を追加。
稼働中の `wordpress` コンテナにのみ注入(`wordpress-init` initContainer には入れない)。
- `smtp.auth.existingSecret` / `existingSecretKey`: msmtprc はチャート生成のまま、パスワード
ファイルだけ既存 Secret から取得。
- `smtp.existingMsmtprcSecret` / `existingMsmtprcSecretKey`: 完成済み msmtprc を持つ既存 Secret を
そのまま `/etc/smtp-config/msmtprc` にマウント。指定時は `configmap-smtp` を生成せず
host/port/auth.* は無視、`smtp-secrets` ボリュームも張らない。起動ログの echo も出し分け。
- `templates/secret-smtp.yaml` / `templates/configmap-smtp.yaml` を上記フラグで出し分け。
- 既定値は全て空 → 既存挙動は不変(`helm template` の全シナリオで確認済み)。
- 主アプリ(WordPress 7.1.0)は変わらないため手動リリース `7.1.0-b`。
**対象ファイル**: `values.yaml`, `templates/deployment.yaml`, `templates/configmap-smtp.yaml`,
`templates/secret-smtp.yaml`, `Chart.yaml`, `README.md`, `CLAUDE.md`
### Hello Dolly等のデフォルトプラグインが削除しても復活する不具合の修正(2026-08-08, v7.1.0-a)
※自動更新ワークフローがこの作業と並行してWordPress 7.1.0への正式リリース(v7.1.0)を実行したため、本修正はそのタグの上に手動リリース `7.1.0-a` として適用した。
**症状**: WP管理画面からHello Dolly(`hello.php`)を削除しても、Pod再起動のたびに復活する。
**原因**: `templates/deployment.yaml` の `wordpress-init` initContainerで、WordPressコアファイルをemptyDirにコピーする処理が `cp -r /usr/src/wordpress/* /var/www/html/` という実装になっており、`wp-content` を除外していなかった。`/var/www/html/wp-content` はPVCマウントの別ボリュームだが、`cp -r` はワイルドカード展開で `wp-content` ディレクトリ自体も対象に含めてしまうため、イメージ同梱のデフォルトwp-content(`hello.php`、`akismet/`、デフォルトテーマ群)がPod再起動のたびにPVC上の既存wp-contentへ**無条件に上書きマージ**されていた。直後にある「PVCが空の場合のみ初期化する」条件分岐(`if [ ! -d /var/www/html/wp-content/themes ]`)は、この最初の `cp -r` の副作用までは防げていなかった。
**対象**: Hello Dolly(`hello.php`)だけでなく、Akismet(`wp-content/plugins/akismet/`)も同じ理由で同様に復活する。**本チャート自身が明示的に`wp plugin install`等でプラグインを追加している箇所は存在しない**(該当するのはWordPressコア配布物に同梱されているこの2つのみ)。
**修正内容**: コアファイルのコピーを `/usr/src/wordpress/` 直下を1件ずつ列挙し、`wp-content` をスキップするループに変更。これによりPVC上のwp-contentは、新規インストール時(PVCが空=`wp-content/themes` が存在しない場合)以外は一切触れなくなった。
**対象ファイル**: `templates/deployment.yaml`, `README.md`, `Chart.yaml`
### 実IP取得の修正 + SMTP経由メール送信の追加(2026-08-08, v7.0.2-a)
**背景**: ルーター(グローバルIP)配下の 192.168.9.x セグメントにコントロールプレーン/ワーカーノードがあり、その上のPodでWordPressが稼働する構成において、(1) 訪問者の実IPアドレスが正しく取得できない、(2) `wp_mail()` によるメール送信が失敗する、という2つの不具合が報告された。
**(1) 実IPアドレス取得の不具合**
原因は2つ複合していた:
- Service(`LoadBalancer`/MetalLB想定)はデフォルトの `externalTrafficPolicy: Cluster` のため、kube-proxyが送信元IPをノード内部IPにSNATしてしまい、Nginxの `$remote_addr` が実IPではなくノードIPになっていた。
- 本チャートの `nginx.forwardRealIP`(X-Forwarded-Forを信頼するreal_ipモジュール設定)は、Ingress ControllerやCDNなど**XFFヘッダーを付与するリバースプロキシが前段にある場合**にのみ機能する設計だが、このベアメタル構成ではService直下にPodがぶら下がるだけでXFFを付与する層が存在せず、機能していなかった(`trustedProxies` に `192.168.0.0/16` が含まれるためSNAT後のノードIPを「信頼済みプロキシ」とみなしてしまうが、そのIPがXFFを付与するわけではないので `$real_ip` は結局SNAT後のIPのままになる)。
さらに、`wp-config.php` 生成テンプレート内でPHP側が生のX-Forwarded-Forヘッダーを無条件に信頼してREMOTE_ADDRを上書きする処理があり、Nginxのreal_ip信頼境界を迂回してクライアントがIPを詐称できる状態だった(副次的なセキュリティ上の問題)。
**修正内容**:
- `values.yaml`: `service.externalTrafficPolicy: Local` をデフォルト追加(SNATを回避し実IPをそのまま透過させる。MetalLB L2モード等と組み合わせる想定。ClusterIPでは無視される)。
- `templates/service.yaml`: `externalTrafficPolicy` を条件付きで出力するよう変更。
- `templates/deployment.yaml`: `wp-config.php` 内のPHP側REMOTE_ADDR再判定処理を削除(NginxのfastcgiパラメータでREMOTE_ADDRは既に正しく渡っているため不要かつ危険だった)。
- `values.yaml`/`README.md`: `nginx.forwardRealIP` は本当にXFFを付与するリバースプロキシが前段にある場合のみ有効化する旨を明記。
**(2) メール送信の不具合**
原因: 使用しているAlpineベースのWordPressイメージには、PHPの `mail()`(`wp_mail()` が内部的に利用)を実際に配送するMTA(sendmail相当)が同梱されておらず、`sendmail_path` の送信先が存在しなかった。
**修正内容**([helmchart/phpfpm](https://git.cafepieters.com/helmchart/phpfpm) チャートと同一の手法を採用。ユーザー指定によりphpfpmの実装パターンをそのまま踏襲):
- `values.yaml` に `smtp.*` セクションを追加(`enabled`/`host`/`protocol`/`port`/`auth.*`/`from`/`tls.*`)。
- `templates/configmap-smtp.yaml`(新規): `/etc/msmtprc` を生成するConfigMap。
- `templates/secret-smtp.yaml`(新規): SMTPパスワードを格納するSecret。
- `templates/deployment.yaml`: `smtp.enabled: true` の場合のみ、`wordpress` コンテナの起動コマンドをシェルラッパーに変更し、`apk add msmtp ca-certificates` → `/etc/msmtprc` 配置(`chmod 644`、www-dataから読めるように) → PHPの `sendmail_path` を `msmtp -t` に向ける `99-smtp.ini` を生成 → `exec php-fpm` という順で起動する。
- `apk add` にrootが必要なため、SMTP有効時のみ既存の `securityContext: runAsUser/runAsGroup: 82` を外している(PHP-FPMワーカー自体はイメージ標準の `www.conf` によりuid82で動作するため、実際のPHPコード実行権限は変わらない)。`smtp.enabled: false`(デフォルト)では従来どおり非rootで起動する。
- msmtpのパスワードはmsmtprcに直書きせず `passwordeval "cat /etc/smtp-secrets/password"` で別ファイル参照(phpfpmの `CHANGELOG-8.5.6-f/g.md` で判明した「Secret/ConfigMapの権限が0600だとwww-dataから読めない」問題を踏まえ、最初から `0644` で実装済み)。
- WordPress本体は `wp_mail()` が自動的に `mail()`/`sendmail_path` を経由するため、phpfpmと異なりPHPコード側の変更(ヘルパークラスの読み込み等)は不要。
**対象ファイル**: `values.yaml`, `templates/service.yaml`, `templates/deployment.yaml`, `templates/configmap-smtp.yaml`(新規), `templates/secret-smtp.yaml`(新規), `README.md`, `Chart.yaml`
+2 -2
View File
@@ -2,8 +2,8 @@ apiVersion: v2
name: wordpress-nginx name: wordpress-nginx
description: WordPress with Nginx and PHP-FPM on Kubernetes description: WordPress with Nginx and PHP-FPM on Kubernetes
type: application type: application
version: 6.9.4 version: 7.1.3
appVersion: "6.9.4" appVersion: "7.1.3"
keywords: keywords:
- wordpress - wordpress
- nginx - nginx
+24
View File
@@ -0,0 +1,24 @@
# GEMINI.md — Antigravity (Gemini) 用エントリポイント(HelmChart\WordPress)
このディレクトリのルールはすべて **`CLAUDE.md`** に記載されている。本ファイルにはルール本文を書かず、読むべき CLAUDE.md への参照だけを置く(正本は常に CLAUDE.md)。
## 必ず最初に実行すること
以下のファイルを**上から順に**読み込み、すべての指示に従うこと。上位ほど広い範囲に適用される共通ルールで、下位は上位を前提とした補足・例外である。
1. `P:\Claude\CLAUDE.md` — 全組織共通ルール(Git 運用・コミット書式・実行環境・情報記載の原則)
2. `P:\Claude\HelmChart\CLAUDE.md` — HelmChart 組織共通ルール
3. `P:\Claude\HelmChart\WordPress\CLAUDE.md` — WordPress リポジトリ固有ルール(このディレクトリ)
> Antigravity はワークスペース(または git ルート)直下のルールしか自動で読まず、親フォルダを遡らない。そのため上位階層のパスをここに明示している。`P:\Claude` はクラウド同期されており、デスクトップ・ノート PC とも同じパスで存在する。
## 読み替え
- CLAUDE.md 中の「Claude」「Claude Code」は、Antigravity で作業する場合は Gemini 自身のことと読み替える。
- Git のコミット者は Antigravity でも `user.name = Claude` / `user.email = claude@cafepieters.com` のまま使う(変更しない)。コミットメッセージに AI クレジットを付けない。
- Claude Code 固有の機能(`.claude/` 設定、スキル、メモリ等)に関する記述は無視してよい。
## 保守ルール
- ルールの追加・変更は **CLAUDE.md にのみ**行う。本ファイルと `.agents/rules/claude-md.md` は参照だけを保持し、内容を増やさない。
- CLAUDE.md を新しいディレクトリに追加したときは、同じ形式の `GEMINI.md` と `.agents/rules/claude-md.md` も併置する。
+165 -9
View File
@@ -126,12 +126,130 @@ helm install my-wordpress ./wordpress-nginx -f custom-values.yaml
| `wordpress.adsTxt.enabled` | ads.txtを有効化 | `false` | | `wordpress.adsTxt.enabled` | ads.txtを有効化 | `false` |
| `wordpress.adsTxt.content` | ads.txtの内容 | `""` | | `wordpress.adsTxt.content` | ads.txtの内容 | `""` |
### SMTP設定(メール送信)
WordPressコンテナ内にはメール送信を行うMTA(sendmail相当のプログラム)が存在しないため、デフォルトのままではパスワードリセットメールやコメント通知などの `wp_mail()` によるメール送信ができません。外部SMTPリレー(Gmail、SendGrid、自前のメールサーバー等)経由で送信する場合は以下を設定してください。
| パラメータ | 説明 | デフォルト値 |
|-----------|------|-------------|
| `smtp.enabled` | SMTP機能有効化 | `false` |
| `smtp.host` | SMTPサーバーホスト名 | `smtp.example.com` |
| `smtp.protocol` | プロトコル(auto/starttls/tls) | `auto` |
| `smtp.port` | ポート番号 | `587` |
| `smtp.auth.enabled` | 認証有効化 | `true` |
| `smtp.auth.username` | SMTPユーザー名 | `smtp-user@example.com` |
| `smtp.auth.password` | SMTPパスワード | `""`(Secretで指定) |
| `smtp.auth.existingSecret` | パスワードを取得する既存 Secret 名(`smtp.auth.password` と自作 Secret の代わり) | `""` |
| `smtp.auth.existingSecretKey` | 上記 Secret 内のキー名 | `password` |
| `smtp.existingMsmtprcSecret` | 完成済み `msmtprc` を持つ既存 Secret 名。指定時はチャートの msmtprc 生成を行わず host/port/auth.* は無視(`from` のみ使用) | `""` |
| `smtp.existingMsmtprcSecretKey` | 上記 Secret 内の `msmtprc` キー名 | `msmtprc` |
| `smtp.from` | 送信元メールアドレス(固定) | `noreply@example.com` |
| `smtp.tls.verify` | TLS証明書検証 | `true` |
| `smtp.tls.allowSelfSigned` | 自己署名証明書を許可 | `false` |
有効化すると、WordPressコンテナ起動時に `msmtp` を導入し、PHPの `sendmail_path` を `msmtp` 経由に設定します。`wp_mail()` はコード変更なしにそのままSMTP経由で送信されるようになります。
#### secret-manager チャートとの連携(メール設定の一元管理)
別リポジトリの **secret-manager** チャートが `cred-gmail` などに生成する完成済み `msmtprc` を
そのまま使う場合(メール設定の変更は secret-manager 側だけで済みます):
```yaml
smtp:
enabled: true
from: "no-reply@your-domain.com" # PHP の sendmail_from 用に必要
existingMsmtprcSecret: "cred-gmail" # このSecretの msmtprc キーをそのまま利用
```
サーバ設定は values に残し、パスワードだけ一元管理したい場合:
```yaml
smtp:
enabled: true
host: "smtp.gmail.com"
port: 587
auth:
enabled: true
username: "no-reply@your-domain.com"
existingSecret: "cred-gmail"
existingSecretKey: "SMTP_PASSWORD"
```
**設定例**:
```yaml
smtp:
enabled: true
host: "smtp.gmail.com"
protocol: "starttls"
port: 587
auth:
enabled: true
username: "your-email@gmail.com"
password: "" # --set smtp.auth.password='your-app-password' で指定
from: "noreply@your-domain.com"
```
```bash
helm upgrade --install my-wordpress . \
-f values.yaml \
--set smtp.auth.password='your-app-password'
```
**よくある設定**:
| プロバイダ | ホスト | ポート | プロトコル |
|-----------|-------|--------|----------|
| Gmail | smtp.gmail.com | 587 | starttls |
| Office365 | smtp.office365.com | 587 | starttls |
| Sendgrid | smtp.sendgrid.net | 587 | starttls |
| Amazon SES | email-smtp.region.amazonaws.com | 587 | starttls |
**注意**: `smtp.enabled: true` の場合、msmtpのインストール(`apk add`)のためWordPressコンテナはrootとして起動し、セットアップ完了後に `php-fpm` へexecします。PHP-FPMのワーカープロセス自体はイメージ標準の設定により引き続き `www-data`(非root)で動作するため、実際のPHPコード実行権限は変わりません。`smtp.enabled: false`(デフォルト)の場合は従来どおり非rootユーザー(uid82)でコンテナが起動します。
### 追加の環境変数(extraEnvFrom / extraEnv)
WordPress(php-fpm)コンテナに任意の環境変数を渡します。プラグインが読む API キー等を、
別リポジトリの **secret-manager** チャートが配布する `cred-<名前>` Secret から注入する用途を
想定しています。認証情報の変更は secret-manager 側を更新するだけで反映できます。
| パラメータ | 説明 | デフォルト値 |
|-----------|------|-------------|
| `extraEnvFrom` | 既存の Secret / ConfigMap をまるごと環境変数として注入(`envFrom` 配列) | `[]` |
| `extraEnv` | 個別の環境変数を追加(生の `env` エントリ配列。`valueFrom`/`secretKeyRef` 可) | `[]` |
```yaml
extraEnvFrom:
- secretRef:
name: cred-gemini # GEMINI_API_KEY 等が丸ごと環境変数になる
extraEnv:
- name: ANTHROPIC_API_KEY
valueFrom:
secretKeyRef:
name: cred-claude
key: ANTHROPIC_API_KEY
```
PHP 側では `getenv('GEMINI_API_KEY')` で取得できます(初期化用の initContainer には注入されず、
稼働中の WordPress コンテナにのみ渡ります)。
### Service設定 ### Service設定
| パラメータ | 説明 | デフォルト値 | | パラメータ | 説明 | デフォルト値 |
|-----------|------|-------------| |-----------|------|-------------|
| `service.type` | Serviceタイプ | `LoadBalancer` | | `service.type` | Serviceタイプ | `LoadBalancer` |
| `service.port` | Serviceポート | `80` | | `service.port` | Serviceポート | `80` |
| `service.externalTrafficPolicy` | 外部トラフィックポリシー(`LoadBalancer`/`NodePort`のみ有効) | `Local` |
**実クライアントIPの取得について(ベアメタル/MetalLB構成)**:
このチャートのデフォルト構成(ルーター → MetalLB等のLoadBalancer Service → Pod)では、`service.externalTrafficPolicy` が `Cluster`(Kubernetesのデフォルト)だと、kube-proxyが送信元IPをノードの内部IPにSNATしてしまい、Nginx/WordPressが実際の訪問者IPを取得できません。本チャートではデフォルトで `externalTrafficPolicy: Local` を設定し、SNATを回避することで `$remote_addr` に実IPがそのまま渡るようにしています。
- **注意**: `Local` にすると、リクエストを受けたノードにPodが存在しない場合はそのノードでの接続が失敗します。MetalLB L2モードなど、Podが存在するノードにのみトラフィックが向く構成と組み合わせて使用してください(複数ノードにPodを分散させることを推奨)。
- `service.type: ClusterIP` の場合、`externalTrafficPolicy` は無視されます(Kubernetes仕様上ClusterIPには適用不可のため)。
- **kube-vip(ARP方式)でServiceに直接VIPを払い出している場合は要注意**: kube-vipはL2 ARP応答に加えて自前でTCP接続をプロキシする実装のため、`externalTrafficPolicy: Local` を設定してもkube-vipの時点で送信元IPが失われ、効果がありません(`type: ClusterIP` + kube-vipアノテーションによる手動VIP付与構成は特に該当します)。この場合は下記「kube-vip等でグローバルIP/VIPが限られている環境での実IP取得」の共有Ingress Controller構成を参照してください。
`nginx.forwardRealIP` は、Ingress ControllerやCDN(Cloudflareなど)、外部LBのように **X-Forwarded-For ヘッダーを付与するリバースプロキシを前段に置く場合にのみ**有効にしてください。本チャートのデフォルト構成(Service直下にPodがぶら下がる構成)ではX-Forwarded-Forを付与する層が存在しないため、`forwardRealIP` を有効にしても効果はなく、`service.externalTrafficPolicy: Local` のみで実IPが取得できます。
### Ingress設定 ### Ingress設定
@@ -293,6 +411,43 @@ ingress:
EOF EOF
``` ```
### kube-vip等でグローバルIP/VIPが限られている環境での実IP取得(共有Ingress Controller構成)
kube-vip(ARP方式)でVIPを払い出す構成の場合、各Serviceを個別に `type: LoadBalancer`(またはClusterIP+kube-vipアノテーションの手動払い出し)にすると、kube-vipが自前でTCP接続をプロキシする関係上、Nginxに到達する時点で送信元IPが失われ、`nginx.forwardRealIP` を有効にしても実IPは取得できません(kube-vipはL2 ARP+自前プロキシであり、X-Forwarded-Forを付与するリバースプロキシではないため)。
これを避けつつ、限られたIP/VIPプールの消費も抑えたい場合は、**Ingress Controllerを1つだけLoadBalancer公開し、各WordPress/PHPFPMリリースはClusterIPのままIngress経由でぶら下げる**構成を推奨します。外部消費IPはIngress Controllerの1個のみに集約され、Ingress ControllerがX-Forwarded-Forを正しく付与するため、本チャート既存の `nginx.forwardRealIP` がそのまま機能します。
**Ingress Controllerの選択**: 既にCilium CNIを使用している場合(`cilium-envoy` Podが動作している環境)は、追加コンポーネントなしでCilium組み込みのIngress Controllerを有効化できます。
```bash
# Cilium組み込みIngress Controllerが有効か確認
kubectl get cm -n kube-system cilium-config -o yaml | grep -i ingress-controller-enabled
# 未設定の場合、Ciliumをupgradeして有効化(既存のCilium Helm valuesに追加)
helm upgrade cilium cilium/cilium -n kube-system --reuse-values \
--set ingressController.enabled=true \
--set ingressController.loadbalancerMode=shared \
--set ingressController.service.type=LoadBalancer \
--set ingressController.service.externalTrafficPolicy=Local
```
Cilium Ingressを使わない場合は `ingress-nginx` 等の一般的なIngress Controllerでも構いません。その場合もController自体のServiceに `externalTrafficPolicy: Local` を設定し、kube-vipでVIPを1つだけ払い出してください。
**各リリースの移行例**(`mikoto-wordpress-nginx` の場合):
```bash
helm upgrade mikoto . -n website \
--set service.type=ClusterIP \
--set ingress.enabled=true \
--set ingress.className=cilium \
--set ingress.hostname=mikoto.example.com \
--set nginx.forwardRealIP.enabled=true
```
移行後は、これまで手動で付与していた `kube-vip.io/loadbalancerIPs` 等のServiceアノテーションは不要になります(Helm管理外のアノテーションのため、`kubectl annotate <svc> kube-vip.io/loadbalancerIPs- kube-vip.io/vipHost-` 等で削除してください)。DNS(またはルーターの名前解決)側で各ホスト名をIngress ControllerのVIP 1個に向ける設定も必要です。
`nginx.forwardRealIP.trustedProxies` のデフォルトには `10.0.0.0/8` が含まれているため、Cilium/Flannel等のPod CIDRがこの範囲内であれば追加設定は不要です。異なるPod CIDRを使用している場合は values.yaml で調整してください。
### リソース制限のカスタマイズ ### リソース制限のカスタマイズ
```bash ```bash
@@ -304,20 +459,19 @@ helm install my-wordpress ./wordpress-nginx \
## 初期化の動作 ## 初期化の動作
### 新規インストール時 ### 新規インストール時
1. WordPress本体ファイルをemptyDirにコピー(使い捨て領域) 1. WordPressコアファイル(wp-content以外)をemptyDirにコピー(使い捨て領域)
2. wp-contentディレクトリをPVCに作成(永続化領域) 2. wp-contentディレクトリのPVCが空の場合のみ、イメージ同梱のデフォルトwp-content(デフォルトテーマ、Akismet、Hello Dolly等)で初期化(永続化領域)
3. シンボリックリンクで wp-content を接続 3. wp-config.phpをSecretから生成
4. wp-config.phpをSecretから生成 4. データベース接続を確認
5. データベース接続を確認 5. テーブルが存在しない場合:
6. テーブルが存在しない場合:
- WP-CLIを使用してWordPressをインストール - WP-CLIを使用してWordPressをインストール
- 管理者アカウントを作成 - 管理者アカウントを作成
- パスワードが未指定の場合は16文字のランダム生成 - パスワードが未指定の場合は16文字のランダム生成
7. ads.txtが有効な場合は配置(使い捨て領域) 6. ads.txtが有効な場合は配置(使い捨て領域)
### アップデート/再起動時 ### アップデート/再起動時
1. WordPress本体ファイルを新しくコピー(常にクリーン) 1. WordPressコアファイル(wp-content以外)を新しくコピー(常にクリーン)
2. 既存のwp-content(PVC)をシンボリックリンクで接続 2. 既存のwp-content(PVC)はそのまま利用(**wp-content配下は一切上書きしない**。デフォルトプラグイン等を削除していればその状態を維持)
3. wp-config.phpを再生成 3. wp-config.phpを再生成
4. データベーステーブルの存在を確認 4. データベーステーブルの存在を確認
5. テーブルが存在する場合: 5. テーブルが存在する場合:
@@ -326,6 +480,8 @@ helm install my-wordpress ./wordpress-nginx \
- 必要に応じてデータベーススキーマをアップデート - 必要に応じてデータベーススキーマをアップデート
6. 既存データ(wp-content)を保持したまま起動 6. 既存データ(wp-content)を保持したまま起動
**注意(v7.1.0-aで修正)**: それ以前は、WordPressコアファイルのコピー処理が `cp -r /usr/src/wordpress/* /var/www/html/` という実装になっており、`wp-content` を除外していませんでした。このため、Pod再起動のたびにイメージ同梱のデフォルトwp-content(Hello Dolly、Akismet、デフォルトテーマ等)がPVC上の既存wp-contentへ**毎回上書きマージ**され、ユーザーが削除したはずのプラグインが復活する不具合がありました。v7.1.0-aでコアファイルのコピーからwp-contentを除外し、PVC上のwp-contentは新規インストール時(PVCが空の場合)以外は一切触らないよう修正しています。
### セキュリティ更新の適用方法 ### セキュリティ更新の適用方法
```bash ```bash
+48
View File
@@ -0,0 +1,48 @@
{{- if and .Values.smtp.enabled (not .Values.smtp.existingMsmtprcSecret) }}
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ include "wordpress-nginx.fullname" . }}-smtp-config
labels:
{{- include "wordpress-nginx.labels" . | nindent 4 }}
data:
msmtprc: |
# msmtp設定ファイル
# PHPのsendmail_pathから呼び出される(wp_mail()経由の送信もこれを使用)
defaults
{{- if .Values.smtp.tls.verify }}
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
{{- else }}
tls off
{{- end }}
{{- if .Values.smtp.tls.allowSelfSigned }}
tls_certcheck off
{{- else }}
tls_certcheck on
{{- end }}
account default
host {{ .Values.smtp.host }}
port {{ .Values.smtp.port }}
{{- if eq .Values.smtp.protocol "starttls" }}
protocol smtp
{{- else if eq .Values.smtp.protocol "tls" }}
protocol smtps
{{- else if eq (int .Values.smtp.port) 465 }}
protocol smtps
{{- else }}
protocol smtp
{{- end }}
{{- if .Values.smtp.auth.enabled }}
auth on
user {{ .Values.smtp.auth.username }}
passwordeval "cat /etc/smtp-secrets/password"
{{- else }}
auth off
{{- end }}
from {{ .Values.smtp.from }}
{{- end }}
+94 -10
View File
@@ -28,7 +28,18 @@ spec:
echo "=== WordPress Initialization Started ===" echo "=== WordPress Initialization Started ==="
echo "Copying WordPress to emptyDir..." echo "Copying WordPress to emptyDir..."
cp -r /usr/src/wordpress/* /var/www/html/ # wp-contentは別マウントのPVCのため、ここではコアファイルのみコピーする。
# "cp -r /usr/src/wordpress/* /var/www/html/" のようにwp-contentを含めて
# 丸ごとコピーすると、既存のPVC上のwp-contentディレクトリにイメージ同梱の
# デフォルトファイル(hello.php等)が毎回上書きマージされてしまい、
# ユーザーが削除したはずのプラグインがPod再起動のたびに復活する原因になる。
for item in /usr/src/wordpress/*; do
name=$(basename "$item")
if [ "$name" = "wp-content" ]; then
continue
fi
cp -r "$item" /var/www/html/
done
echo "WordPress files copied" echo "WordPress files copied"
if [ ! -d /var/www/html/wp-content/themes ]; then if [ ! -d /var/www/html/wp-content/themes ]; then
@@ -69,15 +80,10 @@ spec:
$_SERVER['HTTPS'] = 'on'; $_SERVER['HTTPS'] = 'on';
} }
{{- if .Values.nginx.forwardRealIP.enabled }} // 実クライアントIPの解決はNginx側(real_ipモジュール)で完結しており、
// Add Trusted Proxy - Extract Real Client IP from X-Forwarded-For header // fastcgi_param REMOTE_ADDR として渡されるためPHP側での再判定は行わない。
if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) { // ここでX-Forwarded-Forを無条件に信頼して上書きすると、Nginxの信頼済み
$forwarded_ips = explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']); // プロキシ判定を迂回してクライアントがIPを詐称できてしまうため実施しない。
$_SERVER['REMOTE_ADDR'] = trim($forwarded_ips[0]);
} elseif (isset($_SERVER['HTTP_X_REAL_IP'])) {
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_REAL_IP'];
}
{{- end }}
$protocol = 'http'; $protocol = 'http';
if ( isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) { if ( isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
@@ -291,10 +297,42 @@ spec:
- name: wordpress - name: wordpress
image: "{{ .Values.image.wordpress.registry }}/{{ .Values.image.wordpress.repository }}:{{ .Values.image.wordpress.tag }}" image: "{{ .Values.image.wordpress.registry }}/{{ .Values.image.wordpress.repository }}:{{ .Values.image.wordpress.tag }}"
imagePullPolicy: {{ .Values.image.wordpress.pullPolicy }} imagePullPolicy: {{ .Values.image.wordpress.pullPolicy }}
{{- if .Values.smtp.enabled }}
# SMTP有効時はapk addでmsmtpを導入する必要があるためrootで起動し、
# セットアップ後にphp-fpmへexecする(ワーカープロセス自体はイメージ標準の
# www.confによりwww-data(uid82)で動作するため実処理は非rootのまま)
command: ["/bin/sh", "-c"]
args:
- |
set -e
echo "Configuring SMTP for mail sending..."
apk add --no-cache msmtp ca-certificates
# msmtpはPHP-FPMワーカー(www-data等の非root)から実行されるため、
# rootが作成するこのファイルも読み取り可にする必要がある
# (実パスワードはpasswordeval経由で別ファイルから取得するため、
# msmtprc自体に平文パスワードは含まれない)
cp /etc/smtp-config/msmtprc /etc/msmtprc
chmod 644 /etc/msmtprc
cat > /usr/local/etc/php/conf.d/99-smtp.ini << 'PHP_SMTP_EOF'
; SMTP設定 - msmtp経由でメール送信
sendmail_path = "/usr/bin/msmtp -t"
sendmail_from = "{{ .Values.smtp.from }}"
PHP_SMTP_EOF
{{- if .Values.smtp.existingMsmtprcSecret }}
echo "SMTP configured from existing secret: {{ .Values.smtp.existingMsmtprcSecret }}"
{{- else }}
echo "SMTP configured: {{ .Values.smtp.host }}:{{ .Values.smtp.port }}"
{{- end }}
exec php-fpm
{{- else }}
command: ["php-fpm"] command: ["php-fpm"]
securityContext: securityContext:
runAsUser: 82 runAsUser: 82
runAsGroup: 82 runAsGroup: 82
{{- end }}
env: env:
- name: WORDPRESS_DB_HOST - name: WORDPRESS_DB_HOST
value: {{ .Values.wordpress.dbHost | quote }} value: {{ .Values.wordpress.dbHost | quote }}
@@ -309,11 +347,28 @@ spec:
key: db-password key: db-password
- name: WORDPRESS_TABLE_PREFIX - name: WORDPRESS_TABLE_PREFIX
value: {{ .Values.wordpress.tablePrefix | quote }} value: {{ .Values.wordpress.tablePrefix | quote }}
{{- with .Values.extraEnv }}
{{- toYaml . | nindent 12 }}
{{- end }}
{{- with .Values.extraEnvFrom }}
envFrom:
{{- toYaml . | nindent 12 }}
{{- end }}
volumeMounts: volumeMounts:
- name: wordpress-data - name: wordpress-data
mountPath: /var/www/html mountPath: /var/www/html
- name: wordpress-persistent - name: wordpress-persistent
mountPath: /var/www/html/wp-content mountPath: /var/www/html/wp-content
{{- if .Values.smtp.enabled }}
- name: smtp-config
mountPath: /etc/smtp-config
readOnly: true
{{- if and .Values.smtp.auth.enabled (not .Values.smtp.existingMsmtprcSecret) }}
- name: smtp-secrets
mountPath: /etc/smtp-secrets
readOnly: true
{{- end }}
{{- end }}
resources: resources:
{{- toYaml .Values.resources.wordpress | nindent 12 }} {{- toYaml .Values.resources.wordpress | nindent 12 }}
volumes: volumes:
@@ -334,6 +389,35 @@ spec:
configMap: configMap:
name: {{ include "wordpress-nginx.fullname" . }}-adstxt name: {{ include "wordpress-nginx.fullname" . }}-adstxt
{{- end }} {{- end }}
{{- if .Values.smtp.enabled }}
- name: smtp-config
{{- if .Values.smtp.existingMsmtprcSecret }}
# 完成済み msmtprc を持つ既存 Secret(secret-manager の cred-* 等)を利用
secret:
secretName: {{ .Values.smtp.existingMsmtprcSecret }}
items:
- key: {{ .Values.smtp.existingMsmtprcSecretKey | default "msmtprc" }}
path: msmtprc
{{- else }}
configMap:
name: {{ include "wordpress-nginx.fullname" . }}-smtp-config
items:
- key: msmtprc
path: msmtprc
{{- end }}
{{- if and .Values.smtp.auth.enabled (not .Values.smtp.existingMsmtprcSecret) }}
- name: smtp-secrets
secret:
secretName: {{ .Values.smtp.auth.existingSecret | default (printf "%s-smtp" (include "wordpress-nginx.fullname" .)) }}
items:
- key: {{ .Values.smtp.auth.existingSecretKey | default "password" }}
path: password
# 0600だとSecretボリュームの所有者はroot、
# msmtpはPHP-FPMワーカー(www-data等の非root)から実行されるため読めない
# → 全ユーザー読み取り可にする(ボリュームはPod内にしか存在しないため許容範囲)
mode: 0644
{{- end }}
{{- end }}
{{- with .Values.nodeSelector }} {{- with .Values.nodeSelector }}
nodeSelector: nodeSelector:
{{- toYaml . | nindent 8 }} {{- toYaml . | nindent 8 }}
+13
View File
@@ -0,0 +1,13 @@
{{- if and .Values.smtp.enabled (not .Values.smtp.existingMsmtprcSecret) (not .Values.smtp.auth.existingSecret) }}
apiVersion: v1
kind: Secret
metadata:
name: {{ include "wordpress-nginx.fullname" . }}-smtp
labels:
{{- include "wordpress-nginx.labels" . | nindent 4 }}
type: Opaque
data:
{{- if .Values.smtp.auth.enabled }}
password: {{ .Values.smtp.auth.password | b64enc }}
{{- end }}
{{- end }}
+5
View File
@@ -6,6 +6,11 @@ metadata:
{{- include "wordpress-nginx.labels" . | nindent 4 }} {{- include "wordpress-nginx.labels" . | nindent 4 }}
spec: spec:
type: {{ .Values.service.type }} type: {{ .Values.service.type }}
{{- if and .Values.service.externalTrafficPolicy (ne .Values.service.type "ClusterIP") }}
# ベアメタル環境(MetalLB等)でkube-proxyのSNATを回避し、クライアントの実IPを
# $remote_addr にそのまま渡すための設定。LoadBalancer/NodePortでのみ有効。
externalTrafficPolicy: {{ .Values.service.externalTrafficPolicy }}
{{- end }}
ports: ports:
- port: {{ .Values.service.port }} - port: {{ .Values.service.port }}
targetPort: http targetPort: http
+87 -4
View File
@@ -5,12 +5,12 @@ image:
nginx: nginx:
registry: docker.io registry: docker.io
repository: nginx repository: nginx
tag: "1.29.6-alpine-perl" tag: "1.31.6-alpine-perl"
pullPolicy: IfNotPresent pullPolicy: IfNotPresent
wordpress: wordpress:
registry: docker.io registry: docker.io
repository: wordpress repository: wordpress
tag: "6.9.4-php8.5-fpm-alpine" tag: "7.1.3-php8.5-fpm-alpine"
pullPolicy: IfNotPresent pullPolicy: IfNotPresent
# WordPress設定 # WordPress設定
@@ -44,9 +44,85 @@ wordpress:
# ads.txt content # ads.txt content
# google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0 # google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0
# SMTP設定(wp_mail()/PHPのmail()関数によるメール送信用)
# コンテナ内にはメール送信を行うMTA(sendmail相当)が存在しないため、
# デフォルトのままではWordPressからのメール(パスワードリセット、通知等)は送信できません。
# 外部SMTPリレー(Gmail、SendGrid、自前のメールサーバー等)経由で送信する場合に有効化してください。
smtp:
enabled: false
# SMTPサーバー設定
host: "smtp.example.com"
# プロトコルとポート設定
# - auto: 自動判定(推奨)
# - starttls: STARTTLS(ポート587)
# - tls: SSL/TLS(ポート465)
protocol: "auto"
port: 587
# 認証設定
auth:
enabled: true
username: "smtp-user@example.com"
# password はSecretで管理する
# helm install ... --set smtp.auth.password='your-password' 等で指定
password: ""
# 【外部Secret連携】チャートで msmtprc を生成しつつ、パスワードファイルだけ
# 既存 Secret から取りたい場合に指定する。
# 例: secret-manager チャートが配布する cred-<プロバイダ> の SMTP_PASSWORD キー
# existingSecret: "cred-gmail"
# existingSecretKey: "SMTP_PASSWORD"
# 指定時は smtp.auth.password と自作の -smtp Secret は使われない。
existingSecret: ""
existingSecretKey: "password"
# 送信元アドレス(固定値。wp-config.phpやプラグイン側の指定より優先されます)
from: "noreply@example.com"
# TLS/SSL設定
tls:
# 証明書検証を有効化(本番環境では true を推奨)
verify: true
# 自己署名証明書を許可する場合(テスト環境のみ)
allowSelfSigned: false
# 【外部Secret連携】完成済みの msmtprc がまるごと入っている既存 Secret を使う。
# 指定するとチャート内の msmtprc 生成(configmap-smtp)は行わず、
# host / port / protocol / auth.* / tls.* は無視される(from だけ PHP の
# sendmail_from 用に使用)。
# secret-manager チャートが cred-<プロバイダ> に生成する msmtprc キーを
# そのまま利用できる:
# existingMsmtprcSecret: "cred-gmail"
# existingMsmtprcSecretKey: "msmtprc"
existingMsmtprcSecret: ""
existingMsmtprcSecretKey: "msmtprc"
# 既存の Secret / ConfigMap をまるごと環境変数として wordpress コンテナへ注入する(envFrom)。
# 別リポジトリの secret-manager チャートが各ネームスペースへ配布する
# cred-<名前> Secret(API キー等)をそのまま読み込む用途を想定。
# 変更は secret-manager 側を更新するだけで全プロジェクトに反映できる。
extraEnvFrom: []
# - secretRef:
# name: cred-gemini
# - secretRef:
# name: cred-openai
# 個別の環境変数を追加する(生の env エントリ配列。value / valueFrom(secretKeyRef 等) 使用可)。
extraEnv: []
# - name: OPENAI_API_KEY
# valueFrom:
# secretKeyRef:
# name: cred-openai
# key: OPENAI_API_KEY
nginx: nginx:
# ベアメタルクラスター等でリアルIPを取得する設定 # Ingress ControllerやCDN(Cloudflare等)、外部LB等、X-Forwarded-Forヘッダーを
# ローカルIP(ベアメタル等)から訪問者のリアルIPを取得する場合に有効にします # 付与するリバースプロキシを前段に置く場合にのみ有効にしてください。
# 本チャートのデフォルト構成(Service直下にPodがぶら下がるベアメタル/MetalLB構成)では
# X-Forwarded-For を付与する層が存在しないため、この設定を有効にしても効果はありません。
# その場合は下記の service.externalTrafficPolicy: Local を使用してください。
forwardRealIP: forwardRealIP:
enabled: false enabled: false
# 信頼できるプロキシのIPレンジを追加してください # 信頼できるプロキシのIPレンジを追加してください
@@ -66,6 +142,13 @@ service:
# type: ClusterIP # type: ClusterIP
port: 80 port: 80
targetPort: 80 targetPort: 80
# ベアメタルクラスター(MetalLB等)でクライアントの実IPを取得するための設定。
# kube-proxyはデフォルト(Cluster)だと送信元IPをノードIPにSNATしてしまうため、
# Local にすることでSNATを回避し、Nginxの$remote_addrに実IPがそのまま渡ります。
# 注意: Local にすると、Podが存在しないノードへのアクセスは失敗するため、
# DaemonSetまたは全ノードにPodが分散する構成を推奨します。
# LoadBalancer / NodePort でのみ有効(ClusterIPでは無視されます)。
externalTrafficPolicy: Local
# Ingress設定 # Ingress設定
ingress: ingress: