それに伴い、WordPressをホスト上で動かすのではなくローカルのSynology DS216にインストールして動かすことにしました。投稿するたびに htmlを出力してデプロイするようにセッティングしました。

詳しい方法や構成などは別のポストで紹介できればと思います。

というわけで Dockerfile の一行目を以下のように書き換えてビルドしなおしました。

FROM php:7.4-apache-bullseye

エラーが出ずにインストール完了しました。さっそくURLに /login を付けてログインしてみることにします。

ん？なんだかデザインが崩れているような。開発者ツールでコンソール出力を確認してみたところ、以下のようなエラーが。

Azureで生成される長いURLのせいで難しいことが書いてあるように見えますが、よくよく読むとスタイルシートの読み込みで https を使っていないことで怒られているようです。このせいでスタイルシートが読み込まれなかったようです。

デザイン崩れはしょうがないとして、ユーザIDとパスワードを入力してみたのですが、ログイン失敗になってしまいます。どうやらログインは ajaxで処理されていてそのエンドポイントのURLがこれまた https を使っていないことでエラーになっていました。

これはおそらく Azure App Service 側の問題のような気がしてきました。プログラム側からホストのURLを取得したときに https://… ではなく http://… と認識されてしまっているのかも？

いったんサービスを停止し、/backup/data 配下を確認してみることにします。（うまくスクリプトが動いていればコンテナ停止時にコンテナ内の /var/www/html 配下のファイルが /backup/data へ同期されて見えるようにっているはずです）

そこで config.php というファイルが作成されているのを見つけ開いてみると案の定、http:// で設定されていました。オンラインインストール時にこのURLで登録されたのでしょうか。

	// path
	$config['site_path'] = '/var/www/html';
	$config['site_url'] = "http://onethirdcms-g9gtarhtafc3dte9.japaneast-01.azurewebsites.net/";
	$config['site_ssl'] = "http://onethirdcms-g9gtarhtafc3dte9.japaneast-01.azurewebsites.net/";
	$config['files_path'] = '/var/www/html/files';
	$config['files_url'] = "http://onethirdcms-g9gtarhtafc3dte9.japaneast-01.azurewebsites.net/files/";

config.php の当該箇所を修正して再アップロード。サービスを起動しなおします。

開発ツールを起動しながらページを開くと、今度は Mixed Contentエラーは出なくなりました。スタイルシートのリンクも https://… に切り替わっています。:-)

これでイケるのかも！と思って /login へアクセスしてみたのですが何とエラーも何も出ずホームページのまま。ログイン画面へ遷移しなくなってしまいました。開発者ツールにはエラーは出ない。ログイン画面が表示されない。状況は悪化してしまいました。

これ以上は内部の仕組みを調べながらでないと難しそう。今度こそあきらめることにします。ここまで読んでいただきありがとうございました。ということで OneThirdCMSを動かしたい方は実績のあるレンタルサーバを使いましょう。さよなら。

OneThirdCMSを動かしてみたかった話 (1)

追記

ローカル環境ではログインしてCMSとして使えそうなので、ローカル環境で作成した資材を Azure App Service の公開フォルダへアップロード（config.phpを除いて）するという手が使えるかもしれません。ちょっと手間ですがローカルPC側の backup.sh で工夫すれば自動で同期をとるといった方法も使えるかもしれませんね。

追記2

少し稼働してみて気づいたこと。コンテナ起動時のスクリプトで停止シグナルはトラップするようにしており、手動でApp Serviceを停止したり再起動するときはトラップできているようですが、アクセスが途絶えて自動でシャットダウンするときには動いていないようです。

どうやら App Service on Linux はそうゆうものらしく、カスタムコンテナ以外ならスタートアップスクリプトに仕込むことで対処できるような話が見つかりました。

• App Service on Linux で Graceful shutdown #Docker – Qiita

今回はカスタムコンテナなので初っ端に docker run が動いてしまうので対処のしようが無さそうです。

Copilotに相談したらに Azure Container Apps を使えば？みたいな回答をいただきました。

すると福岡発の純国産CMSであるOneThirdCMS（公式ページ https://onethird.net/）を推してくるではありませんか。SQLiteもサポートしていてDBサーバを必須としていないところもポイント高い。というわけで、さっそく試してみることにしました。

結論から言うとうまく行かなかったのですが、紆余曲折あり長くなったので記録もかねてここに記しておきます。

Dockerコンテナで動かす

ダウンロード資材は2種類あって、1つはWindowsPCでWebサーバを起動してその上でOneThirdCMSを動かすもの。もう1つはWebサーバ上で動くオンラインインストーラ。

私のゴールは Azure の AppService(F1プラン)で単一コンテナで動かすことなので後者を使うことにします。Docker 公式の php の apacheコンテナを動かせばすぐに使えるかと思ったのですが・・・

• mod_rewrite が必須（＝Apacheで動かすことが前提）。これがクリア。
• SQLiteで稼働する予定でも pdo_mysql が有効になっている必要あり。
• オンラインインストールでzip展開するのでzipが有効になっている必要あり。
• PHP8.2 から導入された仕様「動的プロパティの作成が非推奨」により "Deprecated: Creation of dynamic property Ut::$circle is deprecated in /var/www/html/module/utility.php on line 296 OneThird CMS" というようなエラーが発生するので PHP8.1 で動かす。

ということで php:8.1-apache-bookworm をベースに Dockerfile を作成しました。

FROM php:8.1-apache-bookworm

# Install zip & mysql
# Install required packages
RUN apt-get update && apt-get install -y libzip-dev locales

# Install PHP extensions
RUN docker-php-ext-install zip pdo_mysql

# Set up Japanese locale
RUN sed -i '/^# *ja_JP.UTF-8 UTF-8/s/^# *//g' /etc/locale.gen && \
    locale-gen && \
    update-locale LANG=ja_JP.UTF-8

ENV LC_ALL=ja_JP.UTF-8

# Set timezone to Asia/Tokyo
RUN apt-get install -y tzdata && \
    ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime && \
    echo "Asia/Tokyo" > /etc/timezone

# Set cron 
RUN apt-get install -y cron

# Set rsync
RUN apt-get install -y rsync

# enable rewrite
RUN a2enmod rewrite

# custom php entrypoint
COPY custom-php-entrypoint "/usr/local/bin/"
RUN chmod +x "/usr/local/bin/custom-php-entrypoint"
ENTRYPOINT [ "/usr/local/bin/custom-php-entrypoint" ]
CMD ["apache2-foreground"]

WORKDIR /var/www/html

Docker勉強中なのでイケてないところがあるかもしれません。

githubのプライベートレポジトリにまとめていますが、GitHub Actions の勉強もかねて Docker Hubへ公開しています（https://hub.docker.com/r/komina77/onethirdcms）。使い方らしきものも書きました。

なぜ App Service の PHP8.1 を使わないか

App ServiceのPHP8.1で動かせばいいじゃないか、と思われるかもしれません。FTPSで公開用ディレクトリにオンラインインストーラ index.php を置くだけ済みそうです。

でもダメでした。

公開用のディレクトリ /home は Azure Files の CIFS/SMB をマウントして永続化していて、そのために POSIX のファイル操作の原子性や即時反映が期待通りに動作しなかったようです。（writableチェックとして、ファイルを複製して、元ファイルを削除、直後に再作成、でエラーになっている。ここまで念入りにチェックしていることにビックリした）

Webサーバも nginx を使っているようなので上記をクリアしてもおそらく mod_rewrite の問題で不可。

というわけで カスタムコンテナで PHP8.1 + Apache を動かす選択をするに至りました。コンテナ内のファイルシステムであればPOSIX準拠の動作になりますのでオンラインインストーラのチェックはクリアするかと。一方でファイルは一時ストレージに保持されることになるため、コンテナ停止時には /home へデータを退避は必要。

Azure App Serviceで動かす

Azure で リソースの作成＞Web アプリ でリソースを作成します。公開方法を「コンテナ」、OSはLinux、価格プランを「Free F1（共通インフラストラクチャ）」を選びます。

App Serviceの設定をする

設定＞環境変数

設定＞構成

• FTPを使えるようにする。
  • SCM基本認証の発行資格情報をON
  • FTP基本認証の発行資格情報をON
  • FTPの状態をFTPSのみ
• デプロイ＞デプロイセンター＞FTPS資格情報 に有効な値が表示されるのでFTPクライアントに登録する。

デプロイ＞デプロイセンター＞設定

準備作業

komina77/onethirdcms ではコンテナ起動時に ${BACKUP_DIR}/backup.sh 、コンテナ停止時に ${BACKUP_DIR}/restore.sh が実行されるようになっています。また、${BACKUP_CRON} が設定されていれば定期的に ${BACKUP_DIR}/restore.sh が実行されます。

komina77/onethirdcms では /var/www/html 配下がサイトとして公開されるようになっているので、${BACKUP_DIR}/data と /var/www/html の間でファイルを同期するようなスクリプトを用意しておくことで公開資材を永続化することができるという仕組みです。

そこで、FTPクライアントから以下のスクリプトを保存したファイルを /${BACKUP_DIR} から /home を除いたディレクトリにアップロードしておきます。（${BACKUP_DIR}=/home/backup であれば、/backup/backup.sh, /backup/restore.sh という感じです）

#!/bin/sh

# 環境変数チェック
if [ -z "$BACKUP_DIR" ]; then
    echo "Error: BACKUP_DIR environment variable is not set"
    exit 1
fi

# ソースディレクトリ確認
SRC_DIR="/var/www/html"
if [ ! -d "$SRC_DIR" ]; then
    echo "Error: Source directory $SRC_DIR does not exist"
    exit 1
fi

# バックアップ先ディレクトリ作成
DEST_DIR="$BACKUP_DIR/data"
mkdir -p "$DEST_DIR"
if [ $? -ne 0 ]; then
    echo "Error: Failed to create backup directory $DEST_DIR"
    exit 1
fi

# バックアップ実行
echo "$(date '+%Y-%m-%d %H:%M:%S') - Starting backup: $SRC_DIR → $DEST_DIR"
rsync -a --delete "$SRC_DIR/" "$DEST_DIR/"
if [ $? -eq 0 ]; then
    echo "$(date '+%Y-%m-%d %H:%M:%S') - Backup completed successfully"
    exit 0
else
    echo "$(date '+%Y-%m-%d %H:%M:%S') - Error occurred during backup"
    exit 1
fi

#!/bin/sh

# 環境変数チェック
if [ -z "$BACKUP_DIR" ]; then
    echo "Error: BACKUP_DIR environment variable is not set"
    exit 1
fi

# バックアップソースディレクトリ確認
SRC_DIR="$BACKUP_DIR/data"
if [ ! -d "$SRC_DIR" ]; then
    echo "Error: Backup directory $SRC_DIR does not exist"
    exit 1
fi

# 復元先ディレクトリ確認/作成
DEST_DIR="/var/www/html"
mkdir -p "$DEST_DIR"
if [ $? -ne 0 ]; then
    echo "Error: Failed to create restore destination directory $DEST_DIR"
    exit 1
fi

# 復元実行
echo "$(date '+%Y-%m-%d %H:%M:%S') - Starting restore: $SRC_DIR → $DEST_DIR"
rsync -a --delete "$SRC_DIR/" "$DEST_DIR/"
if [ $? -eq 0 ]; then
    echo "$(date '+%Y-%m-%d %H:%M:%S') - Restore completed successfully"
    exit 0
else
    echo "$(date '+%Y-%m-%d %H:%M:%S') - Error occurred during restore"
    exit 1
fi

OneThirdCMSのインストール作業

OneThirdCMSを動かす環境が準備できたらインストール作業を行います。

• OneThirdのダウンロードからオンラインインストーラをダウンロードし解凍する。
• FTPクライアントから解凍したファイル index.php を /${BACKUP_DIR}/data から /home を除いたディレクトリにアップロードする。
• App Service の 概要 へ
  • 開始されてなかったら開始をクリック。
  • 参照をクリックすると公開されているURLが別タブで開く。このURLへのアクセスがトリガになってコンテナ起動となる。初回はコンテナのプルから始まるので時間かかります。

[Start Download OneThird CMS] ボタンをクリックするとダウンロードが走ります。

[Install OneThird CMS] ボタンをクリックすると資材が解凍されてインストールが開始されます。1項目ずつチェックが入り、見た目もかっこいいです。

今回はSQLiteを使うので [インストール（SQLite）] をクリック。

Admin ID や Admin password を適当に入れて、jQuery はCDN参照を選んでインストール開始します。

順調にインストールは進み・・・

成功したように思いきやなんかエラーが出てしまった。

うむ。私はPHP5までの人なのだが、どうやら PHP8 で非推奨になった書き方についてのエラーのようだ。PHP8.1からさらにPHP7系に戻すのもセキュリティ的に問題ありですし（PHP8.1もセキュリティサポート切れてますが）、ソースを直してまで稼働するところまで持っていく義理もなく。。

残念だがここで中断することにした。おそらくこういった非推奨エラーになるところを一つ一つ潰していけば、この興味深いCMSは動くようになると思われる。

（よくよく見るとローカルPCで動かす版のPHPもバージョン7のようだ :-)）

中途半端になってしまったが、無駄にAzure App Serviceの知識が増えたところで今回はあきらめることにした。長々と読んでいただいた方、結果がパッとせず申し訳ない。

本来はPHPやNode.js、Java、Python、ASP.NETなどで作られたWebアプリケーションをデプロイする環境なのですが、アプリなしで静的資材の公開のために利用させてもらっています。便宜的にPHPを使用することにはなっていますが。

で、置いた資材がそのまま公開されていると思っていたのですが、最近なんとなしに昔のページを見ていると拡張子INCのファイルが404エラーになっていることに気付きました。

PICマイコン/テンプレート計画 (komina.info)
ここのページにPICマイコン用のアセンブラMPASMのためのインクルードファイルとして公開していたファイルです。

INCファイルはPHPではインクルードするファイルの拡張子として使われることが多いので、IISの設定で気を利かせて非公開にしてくれていたみたいです。

これだとせっかく公開しているファイルがDLできないので web.config に下記のようにmimeタイプを追記して公開されるようにしました。これで大丈夫だと思います。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
　:
    <staticContent>
      <mimeMap fileExtension=".inc" mimeType="text/plain" />
	  </staticContent>
  </system.webServer>
</configuration>

ところで蛇足ですが。
PICマイコンとは懐かしいです。業務でいくつかのプロジェクトで使用していました。ワンチップマイコンで秋月電子で安価に入手できたのでよく使っていました。数の出ない試作的な案件が多かったのです。