まあ、実はKubernetesではないWordPressでも大丈夫なのですが。
オンプレミスで構築したWebサービス、例えばkubernetesで起動したWordPressなど。インターネットにサーバをホスティング(公開)する場合、SSL化が問題になります。
先日、Raspberry Piでリバースプロキシサーバを起動してみました。SSL証明書の自動更新、Let’s EncryptとZeroSSLに対応しています。
こちらを使用して、リバースプロキシによるSSL化を行い、Kubernetesで構築したWordPressをインターネットにホスティングしたいと思います。
何をどこまでできるのでしょう？ポート番号は？接続のURLは？
そのあたりの個人的な実験の記録になります。
目次
WordPressのCaddyによるSSLホスティング設定例
サーバホスティング環境の構築
自宅のおうちKubernetesで構築したWordPressサイトを、インターネット側から利用したいという流れです。
しかし、自宅のインターネット回線はIPv6 IPoE(transix)で接続しており、サーバのホスティングはできません。
このため、Rasbperry Piを使用してIPv4 PPPoE接続を行い、ppp0側にてホスティングする構成になります。
図のRaspberry Piはホスティング専用になります。別途、KubernetesがおなじおうちLAN内で稼働しております。
SSLのドメイン、ホスト名ですが。ダイナミックDNSサービスのNo-IPを使用させて頂き、インターネット側からアクセス可能なホスト名を割り当てています。
発行されるSSL証明書の対象ホスト名は、ダイナミックDNSサービスに登録したホスト名になります。
マシンはRaspberry Pi 4 + RHEL9互換 Rocky Linux 9を使用
ホスティング、リバースプロキシ、SSL化に使用するマシンですが。
Raspberry Pi 4にスティックSSDを取り付けまして。RHEL9互換のRocky Linux 9を起動しました。microSDカードは使用しません。動作速度はSSDとmicroSDカードで全く異なります。
タイムゾーン設定や静的IP設定など、初期設定はこちらの記事になります。
すぐに壊れるmicroSDカードと異なり、SSDということで長期間使用できるわけですが。SSDの寿命が気になる場合、zramの設定をお勧めします。
ステップ1 IPv4 PPPoEにてインターネットに直接接続
Kubernetesのサービスを、外出先からインターネットを経由して使用するにあたり、IPv4 PPPoE接続を行い、グローバルIPアドレスを割り当てました。
NetworkManagerのPPPoEコネクションに対して、常時接続の設定が可能です。マシンを再起動しても、自動でPPPoE接続されて、インターネットから利用可能になります。
ステップ2 No-IP DUCにてダイナミックDNSのIPアドレスを自動登録
外出先からホスト名でアクセスできるように、No-IPを使用させて頂きました。
IPアドレスの自動登録は、こちらの記事になります。
ステップ3 SSL証明書はCaddyで自動更新
Webサーバ/リーバスプロキシサーバとして、Caddyをインストールさせて頂きました。
Caddyは2つのあくみー(ACME)に対応しているそうです。
- Let’s encrypt
- ZeroSSL
SSL証明書は自動で更新されるため、何か購入や契約や更新など、特に何か気にする必要がありません。大変ありがたいです。
SSLリバースプロキシに使用できるTCPポート番号は443のみを想定
少し実験した感触ですと。
任意のTCPポート番号でリバースプロキシを動かしてアクセスできれば、応用範囲、自由度は高いのですが。
CaddyのSSLの場合、標準のTCPポート番号443のみ、リーバースプロキシの起動が可能でした。(現状のわたしのおうち環境では
たとえばTCP 10443や8443等で、リバースプロキシを起動しようとすると、エラーで起動できない感じです。
そのような理由から、httpsのTCPポート番号443のみで運用したいと思います。
KubernetesのWordPressサイト構築
Helmを使用させて頂き、WordPressをおうちKubernetesへデプロイしました。
MetalLBのロードバランサにより、WordPressのWebポッドにIPアドレスが割り当てられます。おうちLANの中では、そのIPアドレスにて、WordPressにアクセスが可能です。
Kubernetesの構築は、Kubesprayを使用させて頂きました。
KubesprayのKubernetes。
HelmのWordPress。
ともにプロ仕様(プロダクション・グレ～ド
でも手探り(ハンドメ～イド
おまけに自宅(ホームメ～イド
設定例1 WordPressのみホスティングする場合は設定１行で完了
WordPressサイトのURLを、そっくりそのまま、ダイナミックDNSに登録したホスト名でホスティングする場合。
設定はとてもとても簡単でした。
WebブラウザのURL欄を見ると、鍵のマークが表示されています。
鍵マークをクリックして、SSL証明書を確認できますが、既定のCaddyの設定では、Let’s Encryptによる証明書が発行されていました。
WordPressのみホスティングする場合の/etc/caddy/Caddfile
この場合の、/etc/Caddyfileは下記の内容になります。
sudo vi /etc/caddy/Caddyfile内容はほぼ１行でした。
<ダイナミックDNSサービスで取得したホスト名> {
reverse_proxy <WordPressのURL>:80
}あとはcaddy.serviceをリロードすれば、設定変更が反映されます。
sudo systemctl reload caddy.service外出先からは、httpsでアクセスします。
https://<ダイナミックDNSサービスに登録したホスト名>この場合、URLが完全にWordPress専用となります。
設定例2 複数のサービスをホスティングするためにサブディレクトリ化
サブディレクトリでホスティングするサービスを分けてみる
WordPressだけではなく、他のサービスをホスティングしたい場合。
URLのサブディレクトリを使用して、リバースプロキシを切り替える方法が考えられます。
- WordPress
- https://ホスト名/blog/
- Nextcloud
- https://ホスト名/nextcloud/
- Vaultarden
- https://ホスト名/bitwarden/
この場合、すべてのサービスのURLを、サブディレクトリに移す必要があります。
しかし、サイトのサブディレクトリ化は結構面倒です。サイト側の設定を変えずに、リバースプロキシでURL変換したい。それは可能でしょうか？
Caddyの設定としてroute,handle,handle_pathどれを使うか
Caddyのマニュアルを拝見しますと。
route、handle、handle_path、handle_errorsの違いがキーになりそうです。
- route
- 重複して定義可能
- handle
- routeのように他のディレクティブと重ねて使用可能。
- handle同士はお互いにブロックする
- handleを入れ子にしても順に動作する
- handle_path
- handleと同じ動作
- しかしハンドル前に、リクエストからマッチング部分を削除する
- rewrite+handleと同じ動作
- handle_erros
- handleと同じ動作
- しかしリクエストハンドリングのエラー時のみ動作
理屈では、handle_pathやrewriterを使用すると、URLのサブディレクトリ部分(プレフィックス)を削って、リバースプロキシへのアクセスが可能です。
しかし、実際はうまく動作しないケースが多そうです。期待した動作で完璧に動くケースは少ない感触でした。
WordPressに関しても、Caddy側の工夫だけでは、うまくホスティングできませんでした。
WordPress側のURLを、ルートディレクトリからサブディレクトリに移動してからホスティングします。
helmのWordPressをサブディレクトリに移すのはサポート範囲外
WordPressをサブディレクトリに移して運用する必要がありますが。helmでは、そのような移動はサポート対象外になります。
WordPressのダッシュボードを確認すると、該当の設定欄がグレー表示になっていて変更できません。 
しかし、サブディレクトリへの移動の要望があり、こちらの記事に具体的に手順が記載されていました。
設定変更は、下記の流れになります。
- Webポッドにて、/opt/bitnami/wordpressディレクトリに、サブディレクトリを作成。
- ファイルのコピーや移動ではなく、シンボリックリンクを作成
- /bitnami/wordpress/wp-config.phpファイルを編集
- define(‘WP_SITEURL’)
- define(‘WP_HOME’)
- define(‘WP_CONTENT_URL’)
- mariadbポッドにて、wp_optionテーブルを変更
- siteurl
- home
サブディレクトリのシンボリックリンク作成
WordPressのWebポッドにてbashを起動し、サブディレクトリを作成します。
ここでは「blog」というサブディレクトリにしたいと思います。
sudo kubectl exec -it <Webポッド名> -- bash
cd /opt/bitnami/wordpress
ln -s /opt/bitnami/wordpress ./blog
手順では/opt/bitnami/wordpressになっていますが。バージョンが違う影響でしょうか。
手元のWordPressは、/bitnami/wordpressが正解でした。
別途、/opt/bitnami/wordpressもありました。両方とも、シンボリックを作っておきました。
wp-config.phpのサブディレクトリ対応化
helmのWordPressは、既定でnon rootモードで動作します。Webポッドでは管理ユーザが使用できない→エディタが起動・インストールできない→wp-config.phpを編集できない状況です。
このため、wp-config.phpファイルをいちどWebポッドの外にコピーし、編集後にポッドに上書きしています。
sudo kubectl cp <Webポッド名>:bitnami/wordpress/wp-config.php ./wp-config.php
sudo vi wp-config.php
sudo kubectl cp wp-config.php <Webポッド名>:bitnami/wordpress/
173行目付近に、WP_HOMEの設定がありました。ホスト名の後ろにサブディレクトリをつけます。
- ‘/’ → ‘/blog/’
WP_SITEURLも書き換えましたが、WP_CONTENT_URLは見当たりませんでした。
mariadbポッドのwp_optionテーブル変更
テーブルの変更は、phpMyAdminポッドをデプロイして、そちらで行いました。
wp_optionsテーブルのsiteurl行とhome行を変更して、サブディレクトリを追加しました。
画面キャプチャは、データベースがbitnami_wordpressではなくwordpressになっていますが、これは別のサイトからデータベースをリストアしたためです。
サブディレクトリのWordPressをホスティングする場合の/etc/caddy/Caddfile
サブディレクトリ化したURLにて、WordPressに正常にアクセスできるかどうか確認します。
Caddyでホスティングする場合の設定は下記になります。
file_serverを有効にして、CaddyはWebサーバとして動かします。
sudo vi /etc/caddy/Caddyfileそして/blogサブディレクトリへのアクセス時に、リバースプロキシとしてWordPressに接続する設定になります。
<ダイナミックDNSホスト名> {
root * /usr/share/caddy
file_server
handle /blog* {
reverse_proxy <WordPressのURL>:80
}
}編集完了後、caddy.serviceをリロードします。
sudo systemctl reload caddy.service
このような感じで、問題なく外出先からアクセスできるようになりました。
この設定の場合、サブディレクトリを付けずにURLにアクセスした場合、CaddyのWebサーバのトップページが表示されてしまいます。
セキュリティ強化のため、クローラー対策やリダイレクト用の.htaccessファイルを作る等、何か対策したほうが良いと思います。
以上のような感じで、Kubernetesで構築したWordPressサイトに、外出先からSSLで接続できるようになりました。
WordPressをサブディレクトリ化したため、他のサービス、例えばNextcloudやVaultwarden等の別のサービスを、同じホスト名でホスティングできる見通しになりました。(まだ実際に試していませんが
アクセス速度ですが、IPv4 PPPoE接続は、アップロードとダウンロードの速度が非対称の契約が多いと思います。
インターネットへのアクセス(ダウンロード)は高速ですが、インターネット側へのファイルの転送(アップロード)の速度は制限がある場合が多いと思います。
とはいえ、SSLの証明書は自動更新されるため、快適なサーバホスティング環境と言って良いと思います。
さて。実用性は使ってみなければわかりません。使って見ながら、追々、別のサービスもホスティングしたいと思います。