1. >>
  2. 2023年 10月

2023年 10月 の投稿一覧

WordPress を利用した静的サイトを構築する (2)

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

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

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

ブログを開設するにあたって、外部から攻撃を受ける可能性を減らしつつ手軽に 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 サイトにする必要なければ、この時点で最低限のブログ運用環境が立ち上がったことになる。

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

Postgresql の開発環境の作成

Postgresql の開発環境を構築する。

ソースコードの入手

postgresql のソースコードは git 上で管理されており `https://git.postgresql.org/git/postgresql.git` に存在するので、これを拾ってくる。

必要なライブラリのインストール

そのままではビルドが通らないので、ビルドに必要な開発パッケージをインストールする。
(https://wiki.postgresql.org/wiki/Compile_and_Install_from_source_code)

$ sudo apt-get install build-essential libreadline-dev zlib1g-dev flex bison libxml2-dev libxslt-dev libssl-dev libxml2-utils xsltproc ccache

ビルド

ライブラリのインストールが済んだら、 ./configure コマンドを発行して問題が起きないか確認する。個人的な話だが、手動でビルドしたプログラムは ~/.usr に配置するようにしたいので、その設定も行う。(もちろん PATH は通してある)

$ ./configure --prefix="${HOME}/.usr"
$ make
$ make install

configure: error: ICU library not found が発生する

master ブランチが 17devel の作業を行っているとき、 ./configure を実行したら configure: error: ICU library not found が発生した。正確には、 ICU はあるけれども icu-uc と icu-i18n がないよ、という内容。 (ICU すらないといわれた場合、 libicu-dev をインストールする必要がある)

checking whether to build with ICU support... yes
checking for icu-uc icu-i18n... no
configure: error: ICU library not found
If you have ICU already installed, see config.log for details on the
failure.  It is possible the compiler isn't looking in the proper directory.
Use --without-icu to disable ICU support.

ICU 自体は見つかるのに icu-uc と icu-i18n が見つからないらしいけどなんでだろう…… と思ったら、ここ (https://stackoverflow.com/questions/76477533/installing-age-pg16-beside-postgresql-v16beta1-giving-bison-is-missing-while-it) に解決策があった。

$ sudo apt update
$ sudo apt install libicu-dev pkgconf

確認

$ ls -1 ~/.usr/bin/
clusterdb
createdb
# --- OMMITED ---
postgres
psql
reindexdb
vacuumdb

$ ls -1 ~/.usr/lib/
libecpg.a
libecpg_compat.a
# --- OMMITED ---
libpq.a
libpq.so
libpq.so.5
libpq.so.5.17
pkgconfig
postgresql

$ psql
psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: No such file or directory
        Is the server running locally and accepting connections on that socket?

サーバー自体はまだ起動していないので応答しないが、 psql はちゃんと読み込めているみたい。

command not found が発生する

ソフトウェアにパスが通ってない可能性がある。 ~/.bashrc などに export PATH=/home/username/.usr/bin:$PATH などの記述をする必要がある。 source ~./bashrc で設定を読み直し、 which psql などで意図した位置のファイルが見えることを確認する。

cannot open shared object file が発生する

共有ライブラリにパスが通っていない可能性がある。 ~/.bashrc などに export LD_LIBRARY_PATH=/home/username/.usr/lib:$LD_LIBRARY_PATH などの記述をする。 ( LD_LIBRARY_PATH を正しく設定する)

最後に

./postgres/src ディレクトリ以下には postgresql のソースコードが存在するので、煮るなり焼くなりして改造できる。

git 上では 1日 10コミット程度ツリーが進んでいるので、それを追いかけるのも悪くない。