12 Commits
Author SHA1 Message Date
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
9 changed files with 358 additions and 54 deletions
+8 -39
View File
@@ -248,7 +248,7 @@ jobs:
echo "Release v${APP_VERSION} created with asset ${PACKAGE_FILE}"
fi
- name: Update Helm Repository Index
- name: Publish to Gitea Package Registry
if: steps.check_update.outputs.wp_updated == 'true'
run: |
set -e
@@ -256,46 +256,15 @@ jobs:
CHART_NAME=$(grep '^name:' Chart.yaml | awk '{print $2}')
PACKAGE_FILE="${CHART_NAME}-${APP_VERSION}.tgz"
echo "Preparing Helm repository update..."
echo "🚀 Publishing ${PACKAGE_FILE} to Gitea Package Registry..."
# パッケージファイルを一時ディレクトリに移動
mkdir -p /tmp/helm-repo
cp "${PACKAGE_FILE}" /tmp/helm-repo/
curl --fail-with-body \
-u "${{ secrets.REGISTRY_USER }}:${{ secrets.REGISTRY_TOKEN }}" \
-X POST \
--upload-file "${PACKAGE_FILE}" \
"https://git.cafepieters.com/api/packages/helmchart/helm/api/charts"
# gh-pagesブランチの処理
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
echo "✅ Chart published successfully to Gitea Package Registry"
- name: Summary
if: always()
+72
View File
@@ -0,0 +1,72 @@
# CLAUDE.md — WordPress Helm Chart
## リポジトリ概要
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コードは含まれない。
## Git コミット情報
| 項目 | 値 |
|------|-----|
| 名前 | Claude |
| メール | claude@cafepieters.com |
| SSH キー | `P:\Claude\.ssh\id_claude` |
## 作業完了のルール(重要)
1. **機能を追加・変更した場合は、必ず README.md を更新すること。** 追加・変更した機能の説明を反映してから作業完了とする。
2. **変更は必ず Git Commit / Push まで行うこと。** 作業単位ごとにコミットし、origin(main) へ push するまでが作業完了。
3. **Commit メッセージに Claude クレジット(Co-Authored-By 等)を追記することは禁止。** `user.name = Claude` でコミットされるため、ユーザー名で判別可能。
4. `git pull` で取り込まれた変更は必ず尊重し、revert して push することは禁止(既存の共通ルールと同じ)。
## クラスタ構成メモ(実運用環境)
- ノード: `cpi11`(control-plane, 192.168.9.9/物理IF)、`wpi21`/`wpi22`/`wpi23`(worker)。全てRaspberry Pi(Ubuntu 25.04)。
- CNI: **Cilium**kube-proxyなし、eBPFベース)。`cilium-envoy` Podが動作しており、Cilium組み込みIngress ControllerEnvoyベース)が利用可能。
- Pod CIDR: `10.0.0.0/8`系、ノードごとに `/24` を割り当て(例: cpi11→`10.0.0.0/24`、wpi22→`10.0.1.0/24`、wpi21→`10.0.2.0/24`、wpi23→`10.0.3.0/24`)。
- 外部公開: **kube-vip**ARP方式、静的Pod `kube-vip-cpi11`)。物理ルーターのグローバルIP配下、`192.168.9.0/24` セグメント内でVIPを払い出す。このセグメントはルーターがLAN機器(スマホ/PC等)にDHCP払い出しする範囲と重複しないよう、ルーター側で範囲を絞って共存させている。**IPが希少なため濫用できない。**
- 各WordPress/PHPFPMリリースは現状、`service.type: ClusterIP` + `kube-vip.io/loadbalancerIPs`/`kube-vip.io/vipHost` アノテーションを**Helm管理外で手動付与**し、リリースごとに個別のVIPを得る運用になっている(本チャートの `templates/service.yaml` にはannotationsのテンプレート化自体が存在しないため)。
- **既知の問題**: この構成では、kube-vipがL2 ARP応答に加えて自前でTCPコネクションをプロキシしてしまうため、`externalTrafficPolicy`LoadBalancer/NodePort専用でありClusterIPには無効という制約とは別に、そもそもkube-vipの時点で)実クライアントIPが失われる。詳細はREADME.mdの「kube-vip等でグローバルIP/VIPが限られている環境での実IP取得(共有Ingress Controller構成)」を参照。
- 今後、実IP取得のためCilium組み込みIngress Controller(またはingress-nginx)へ移行する方針で合意済み(2026-08-08時点、ユーザーが選択)。ただし全リリース(wordpress-nginx系だけでなくphpfpm系も含む)の移行が必要な大掛かりな作業のため、本セッションではWordPressチャート側の対応(`ingress.yaml`/`forwardRealIP`は既存機能で対応済み、README migration手順を追記)のみ実施。実際のCilium Ingress有効化・各リリースのhelm upgradeはユーザー側の作業。
## チャート改修履歴
### 実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
description: WordPress with Nginx and PHP-FPM on Kubernetes
type: application
version: 6.9.4
appVersion: "6.9.4"
version: 7.1.0
appVersion: "7.1.0"
keywords:
- wordpress
- nginx
+99
View File
@@ -126,12 +126,74 @@ helm install my-wordpress ./wordpress-nginx -f custom-values.yaml
| `wordpress.adsTxt.enabled` | ads.txtを有効化 | `false` |
| `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.from` | 送信元メールアドレス(固定) | `noreply@example.com` |
| `smtp.tls.verify` | TLS証明書検証 | `true` |
| `smtp.tls.allowSelfSigned` | 自己署名証明書を許可 | `false` |
有効化すると、WordPressコンテナ起動時に `msmtp` を導入し、PHPの `sendmail_path``msmtp` 経由に設定します。`wp_mail()` はコード変更なしにそのままSMTP経由で送信されるようになります。
**設定例**:
```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)でコンテナが起動します。
### Service設定
| パラメータ | 説明 | デフォルト値 |
|-----------|------|-------------|
| `service.type` | Serviceタイプ | `LoadBalancer` |
| `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-vipARP方式)で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やCDNCloudflareなど)、外部LBのように **X-Forwarded-For ヘッダーを付与するリバースプロキシを前段に置く場合にのみ**有効にしてください。本チャートのデフォルト構成(Service直下にPodがぶら下がる構成)ではX-Forwarded-Forを付与する層が存在しないため、`forwardRealIP` を有効にしても効果はなく、`service.externalTrafficPolicy: Local` のみで実IPが取得できます。
### Ingress設定
@@ -293,6 +355,43 @@ ingress:
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
+48
View File
@@ -0,0 +1,48 @@
{{- if .Values.smtp.enabled }}
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 }}
+62 -9
View File
@@ -69,15 +69,10 @@ spec:
$_SERVER['HTTPS'] = 'on';
}
{{- if .Values.nginx.forwardRealIP.enabled }}
// Add Trusted Proxy - Extract Real Client IP from X-Forwarded-For header
if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {
$forwarded_ips = explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']);
$_SERVER['REMOTE_ADDR'] = trim($forwarded_ips[0]);
} elseif (isset($_SERVER['HTTP_X_REAL_IP'])) {
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_REAL_IP'];
}
{{- end }}
// 実クライアントIPの解決はNginx側(real_ipモジュール)で完結しており、
// fastcgi_param REMOTE_ADDR として渡されるためPHP側での再判定は行わない。
// ここでX-Forwarded-Forを無条件に信頼して上書きすると、Nginxの信頼済み
// プロキシ判定を迂回してクライアントがIPを詐称できてしまうため実施しない。
$protocol = 'http';
if ( isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
@@ -291,10 +286,38 @@ spec:
- name: wordpress
image: "{{ .Values.image.wordpress.registry }}/{{ .Values.image.wordpress.repository }}:{{ .Values.image.wordpress.tag }}"
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
echo "SMTP configured: {{ .Values.smtp.host }}:{{ .Values.smtp.port }}"
exec php-fpm
{{- else }}
command: ["php-fpm"]
securityContext:
runAsUser: 82
runAsGroup: 82
{{- end }}
env:
- name: WORDPRESS_DB_HOST
value: {{ .Values.wordpress.dbHost | quote }}
@@ -314,6 +337,16 @@ spec:
mountPath: /var/www/html
- name: wordpress-persistent
mountPath: /var/www/html/wp-content
{{- if .Values.smtp.enabled }}
- name: smtp-config
mountPath: /etc/smtp-config
readOnly: true
{{- if .Values.smtp.auth.enabled }}
- name: smtp-secrets
mountPath: /etc/smtp-secrets
readOnly: true
{{- end }}
{{- end }}
resources:
{{- toYaml .Values.resources.wordpress | nindent 12 }}
volumes:
@@ -334,6 +367,26 @@ spec:
configMap:
name: {{ include "wordpress-nginx.fullname" . }}-adstxt
{{- end }}
{{- if .Values.smtp.enabled }}
- name: smtp-config
configMap:
name: {{ include "wordpress-nginx.fullname" . }}-smtp-config
items:
- key: msmtprc
path: msmtprc
{{- if .Values.smtp.auth.enabled }}
- name: smtp-secrets
secret:
secretName: {{ include "wordpress-nginx.fullname" . }}-smtp
items:
- key: password
path: password
# 0600だとSecretボリュームの所有者はroot、
# msmtpはPHP-FPMワーカー(www-data等の非root)から実行されるため読めない
# → 全ユーザー読み取り可にする(ボリュームはPod内にしか存在しないため許容範囲)
mode: 0644
{{- end }}
{{- end }}
{{- with .Values.nodeSelector }}
nodeSelector:
{{- toYaml . | nindent 8 }}
+13
View File
@@ -0,0 +1,13 @@
{{- if .Values.smtp.enabled }}
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 }}
spec:
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:
- port: {{ .Values.service.port }}
targetPort: http
+49 -4
View File
@@ -5,12 +5,12 @@ image:
nginx:
registry: docker.io
repository: nginx
tag: "1.29.6-alpine-perl"
tag: "1.31.4-alpine-perl"
pullPolicy: IfNotPresent
wordpress:
registry: docker.io
repository: wordpress
tag: "6.9.4-php8.5-fpm-alpine"
tag: "7.1.0-php8.5-fpm-alpine"
pullPolicy: IfNotPresent
# WordPress設定
@@ -44,9 +44,47 @@ wordpress:
# ads.txt content
# 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: ""
# 送信元アドレス(固定値。wp-config.phpやプラグイン側の指定より優先されます)
from: "noreply@example.com"
# TLS/SSL設定
tls:
# 証明書検証を有効化(本番環境では true を推奨)
verify: true
# 自己署名証明書を許可する場合(テスト環境のみ)
allowSelfSigned: false
nginx:
# ベアメタルクラスター等でリアルIPを取得する設定
# ローカルIP(ベアメタル等)から訪問者のリアルIPを取得する場合に有効にします
# Ingress ControllerやCDN(Cloudflare等)、外部LB等、X-Forwarded-Forヘッダーを
# 付与するリバースプロキシを前段に置く場合にのみ有効にしてください。
# 本チャートのデフォルト構成(Service直下にPodがぶら下がるベアメタル/MetalLB構成)では
# X-Forwarded-For を付与する層が存在しないため、この設定を有効にしても効果はありません。
# その場合は下記の service.externalTrafficPolicy: Local を使用してください。
forwardRealIP:
enabled: false
# 信頼できるプロキシのIPレンジを追加してください
@@ -66,6 +104,13 @@ service:
# type: ClusterIP
port: 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: