maplenotes

WordPress を利用した静的サイトを構築する (1) の続き。

SSG プラグインの導入

特に特殊なことはせず、 WordPress の GUI から Simply Static を検索してインストールした。
https://ja.wordpress.org/plugins/simply-static/

プラグインをインストールすると、このプラグイン用の専用メニューが管理画面に追加される。

設定の変更と実行前提条件の確認

設定値

ページ生成した後に別サーバーに HTML を移動させて公開することを考えると、ページ URL が公開サーバーを参照するために正しく設定されているかが重要となる。 General ページの Replacing URLs が Relative Path で、 PATH の設定値が / になっていればおそらく問題なく表示できると思われる。

Deployment ページには、生成したページたちをどこに出力するのかを指定できる項目がある。好みのものを選べばよいが、とりあえず Local Directory の /var/www/html/public_static に出力するようにした。 /var/www/html は Docker でホストマシンと共有しているディレクトリになるので、デプロイ時などに必要があればホストマシンから参照することができる。

実行条件

Diagnostics ページには、プラグインを実行するための前提条件がそろっているかを確認できるステータスチェック表示がなされている。

確認できた限りだと、 SSL だけは Fail していても問題ない。 (少なくとも外部へのデプロイを自動的に実行しない限りは)
SSL 以外のすべての項目が Success (チェックマーク) になっていない場合、静的 HTML を生成する前提条件がそろっていないことになる。

必要に応じて、 WordPress や Docker コンテナの設定を見直すこと。

静的サイトの生成

管理メニュー内の Simply Static のページ内にある 「Generate Static Files」 ボタンを押下することで、静的 HTML が (設定ページで設定したディレクトリ内に) 出力される。

設定や実行環境に何らかの不備がある場合、特にエラーを発生させずに生成処理が終了しないでダンマリになる。 (結構ハマった)
生成処理が終わらず、Export Log の表示も変化がない場合、 Diagnostics ページを確認して問題が発生していないかチェックするとよい。

静的サイト提供に必要なデータを Simply Static がレンダリングするので、そこそこ時間がかかる。

サイトの公開

生成した静的サイト用のファイル群は、 Docker で WordPress を構築したサーバーのホストマシンから参照できるようになっているはずである。

WordPress を構築するために作成した compose.yaml があるディレクトリを基準として、 ./wp_data/public_static に生成したファイル群があるので、これをいったんそのマシン内の別の場所(~/site など)に一式をまるごとコピーする。

(実行環境によっては、該当ファイルの読み取り権限 (r) がないことがあるかもしれない (コンテナ内とホストマシンのユーザーの UID が異なることによる)。自分が手元で確認したケースでは問題なかったが、場合によっては自分が sudoers に所属していないとコピーできないことがあるかもしれない)

コピーしたファイル群は、それ単体で静的 web サイトとして成り立つようになっているので、Web サイトをホストするサーバーにデプロイすればよい。

実際のデプロイについては、デプロイ先の構成によって大きく異なるので割愛する。(とりあえず手動で SCP を使ってデプロイしてる)

最後に

本サイトを構築するにあたって実施した基本的な手順について、防備を兼ねて記載した。

WordPress のテーマを設定すれば静的サイト化した場合でもそれが維持されるので、既製テーマで済ませてしまえば手間をかけずに手軽に静的サイトを構築できる。

サーバー側の構成はやや複雑になるが、静的化するメリットは大きいので、状況に応じて選択したい。

ブログを開設するにあたって、外部から攻撃を受ける可能性を減らしつつ手軽に Web サイトを構築したかったので、WordPress とそのプラグインを使って静的サイトジェネレータとして利用することにした。

WordPress SSG (Static Site Generater) プラグインの選定

プラグインの選定と言いつつ最初に試した simply static がかなり感触よかったので、ほかに試して比較することなしにこれに決めた。

しっかりメンテナンスもされているようで、最新バージョンにも追従していたので、悪くなさそう。

PRO バージョンだと自動化タスクとして HTML への変換と自動デプロイ利用できるようになるみたいだが、個人で運営して記事数も多くならないだろうし、もしそうなったとしても自分でコード書ければよいので、必要になることはなさそう。

WordPress Server の構築

以下の compose ファイルを作成して起動する。
(https://docs.docker.jp/compose/wordpress.html (v24.0) に載っていたものを流用した (wordpress コンテナの volumes だけ追加した))。
余談だが、この compose ファイルは (公式ドキュメントなのに) compose specification に準拠していない。(動作自体は問題ない))

version: '3'

services:
  db:
    image: mysql:5.7
    volumes:
      - db_data:/var/lib/mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: somewordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress

  wordpress:
    depends_on:
      - db
    image: wordpress:latest
    volumes:
      - ./wp_data:/var/www/html
    ports:
      - "8000:80"
    restart: always
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress

WordPress サーバーはインターネットに露出していない場所に置きたいので、ファイアウォールの内側からのみアクセス可能な場所にデプロイする。

docker compose up -d コマンド (環境によっては docker-compose up -d かもしれない) を打ち込んで、サーバーを起動する。しばらくして、 `{対象のマシンの IP アドレス}:8080` などにアクセスして、意図通りに WordPress が起動していることが確認できれば OK。

ここまでのまとめ

ここまでの手順を実施すれば、すでに WordPress のサーバーインスタンスは立ち上がっている。静的 Web サイトにする必要なければ、この時点で最低限のブログ運用環境が立ち上がったことになる。

肝心の静的化が済んでないので、次は静的なサイトを生成するための手順を記載する。