CentOS8のサポート終了は2021年12月31日。2025年元旦に再構築・移行を決意し、途中発熱で中断したものの1月12日に対応が完了したため思い出を残す。
１．移行先の選定
サービスは、過去困っていなかったので同じさくらのVPS(v5) 1G IK01のプランを選んだ。
OSはCentOS8の後継としてはAlmaLinuxとRockyLinuxが有力だったが、結果的に選んだのはRockyLinuxである。どちらも甲乙つけがたい素晴らしいOSなため、RockyLinuxが優れていたから選んだということではない。ただ、趣味のサーバーであり、直前にAlmaLinuxを使っていたから今回はRockyLinuxにしようという程度の選定理由である。
AlmaLinux と RockyLinuxの比較参考： https://blog.apar.jp/linux/15640/
２．ホストネットワーキング
ホストネットワーキングとは、Dockerの仮想ネットワークと違うという意味でホストを付けている。特別難しいことはせず、さくらVPSの機能で一部プロトコルのポート開放を行い、公開鍵認証方式のみ許可するようありがちな設定を適用した。
特筆すべき点で言えば、鍵への拘り。さすがに今の時代RSAはなぁということで、ecdsa_nistp521の鍵を使うことにした。
更にiPadで『https://it.sifr.me/study/operate-your-ssh-server-with-buffer-editor/』の設定を適用した。これで、出先でサーバーを操作したいと思った場合はiPadから操作する環境が整った。
２．Docker CEのインストール
CentOSよりひと手間入るという程度で、上のリンク先に従えばすんなり入る。簡単だった。
問題は、過去インストール版との違いで、3点Dockerの違いに悩まされた。
２．１．docker compose
昔は docker 本体とは分けて docker-compose コマンドを使っていたが、最近は統合されたらしい。
docker-compose と書いていた部分を全て docker compose （ハイフン→半スぺ）に変更する。
２．２．docker-compose.yml の services:
docker-compose.yml の最初に services: から始めないと動作しない。具体例としては以下が一目瞭然なのだが、全部のdocker-compose.ymlにこれを足していくのは大変手間だったぞ。
[user@hostname web-hoge]$ cat docker-compose.yml
services:
web-hoge:
image: nginx:alpine
container_name: web-hoge
restart: always
environment:２．３．docker-compose.yml の networks:
docker は初期とネットワークのコンセプトが変わっている。多分セキュリティ確保のため『デフォルトでは他のコンテナ同士で連携させない』ようにしていて、コンテナ間で通信をするにはネットワークを明示してドメイン名解決＆通信させるのが◎である。
この違いを考慮していないと『host not found in upstream “$server_name”…』のエラーが出力されることとなる。
※2025年1月時点、Dockerのネットワークの仕様については『Dockerネットワークを理解したい #docker-compose – Qiita』が詳しい
実際の対策としては以下のようにネットワーク設定を設けておき、
docker network create mainnetwork以下のように docker-compose.yml にネットワーク情報を載せると管理し易い。
[user@hostname web-hoge]$ cat docker-compose.yml
services:
web-hoge:
image: nginx:alpine
container_name: web-hoge
restart: always
environment:
#～中略～
networks:
mainnetwork:
networks:
mainnetwork:
name: mainnetwork
driver: bridge
external: true３．コンテナの最新化
ここからは個別のコンテナ移行を取り扱う。権限を維持したままデータをコピーしておくのは前提として、引っかかった部分を説明する。
３．１．openldapの延命措置
別記事にまとめた『https://it.sifr.me/study/extending-the-life-of-osixia-openldap-container/』の通り。
osixia/openldapを使い続けるには調査と工夫が必要だった。
３．２．php-fpm
一気に最新版にするぞと PHP8.4にするつもりで php:8.4-fpm-alpine で構築を進めたが、結果的に8.2に落ち着いた。理由は２つある。
一つはpecl imagemagick が8.4で破棄された関数を使っているためコンパイルに失敗するから（参考：https://github.com/Imagick/imagick/issues/689）。
もう一つはNextCloud Version30が8.4に対応しておらず、31から8.4対応となっているから（参考：https://github.com/nextcloud/server/wiki/Releases-and-PHP-versions）である。
３．２．１．Alpine Linuxでの標準ライブラリの変化
昔は phar, iconv をインストールする場合は明示していたが、これらはAlpine Linuxでは標準で入るようになった（外したい場合にコマンドで明示するようになった）。Dockerfileのインストールコマンドからこれらを外す必要がある。
なお、インストール可能な項目を調べたところ以下項目が有効だった。
bcmath, bz2, calendar, ctype, curl, dba, dl_test, dom, enchant, exif, ffi, fileinfo, filter, ftp, gd, gettext, gmp, hash, iconv, intl, json, ldap, mbstring, mysqli, odbc, opcache, pcntl, pdo, pdo_dblib, pdo_firebird, pdo_mysql, pdo_odbc, pdo_pgsql, pdo_sqlite, pgsql, phar, posix, random, readline, reflection, session, shmop, simplexml, snmp, soap, sockets, sodium, spl, standard, sysvmsg, sysvsem, sysvshm, tidy, tokenizer, xml, xmlreader, xmlwriter, xsl, zend_test, zip３．２．２．メモリ不足
opcache, redis のようにコンパイルに時間のかかるインストールはいつも途中で止まる。原因は見出しの通りメモリ不足。昔は同じプランのさくらVPSでフリーズすることなく一発で出来ていたから、Docker CEのビルドはメモリ使用量が昔より増えてると思った方が良さそうだ。
SWAPで解決できるのでさくらVPSのプランを上げる必要はない。
# /swap をスワップファイルとする
sudo dd if=/dev/zero of=/swap bs=1M count=4096
sudo chmod 600 /swap
sudo mkswap /swap
sudo swapon /swap
# 再起動後も永続化する場合以下も実行
echo '/swap none swap sw 0 0' | sudo tee -a /etc/fstab３．２．３．CLIでの処理の取り扱い変化
昔はPHP-FPMでCLIが使えた。例えばNextCloudでコマンドラインでのアップグレードがしたいのであれば『php occ upgrade』のコマンド実行で済んでいたのだが、現在は『php –define memory_limit=1024M –define apc.enable_cli=1 occ upgrade』とメモリ不足対策やAPCuの設定を入力しないと動作しない。実際に昔のアップグレードコマンドを実行すると以下の通りエラーとなる。
An unhandled exception has been thrown:
OC\HintException: [0]: Memcache \OC\Memcache\APCu not available for local cache (Is the matching PHP module installed and enabled?)Copilot先生に聞いたところでは、PHPは通常のPHP処理とCLIで設定を分けるようになった。そしてPHP-FPMはCLIで使うタイプのものではないようで、PHP-FPMにapc.enable_cli=1の設定を入れると起動が出来ない。なのでCLIで実行したい時は都度パラメータを渡してほしいということだった。
Copilotが嘘を言っているんじゃないかとか、ちょっと違和感感じてしまうところだけれど動けば良い派だからよしとする。
３．３．nginx proxy <-> letsencrypt の仕様変更
皆大好きな nginx proxy とLet’s Encryptで自動的に連携出来るミドルウェア構築の強い味方コンボだが、BASIC認証を含むサイトを設置すると、nginx proxy が立ち上がらないことに気づいた。
https://github.com/jwilder/docker-letsencrypt-nginx-proxy-companion
どうやら、BASIC認証がかかっている場合は直接アクセスが出来ないため『自分が所有者です本物です』という証が要るようで、ログを見ると『/.well-known/acme-challenge/』配下のURLへアクセスが来るのが分かる。
以下のように当該URL配下へのアクセスをBASIC認証対象外にしておけばnginx proxy が落ちるのは回避出来た。
location /.well-known/acme-challenge/ {
try_files $uri $uri;
}３．４．NextCloud
地味に困ったのが、『NextCloudアップグレード途中、工程５の間にメモリ不足エラーになってしまい止まってしまった』件である。メモリ不足エラーは『php –define memory_limit=1024M –define apc.enable_cli=1 occ upgrade』の1024Mのようにメモリ指定をして実行すれば解決できるのだが、途中まで進めてしまった状況は再度アップグレードコマンドを実行しても『Step 5 is currently in process. Please call this command later.』と応答が来るだけで解決出来ない。
３．４．１．Step 5の途中扱いをリセットして再試行
ステップを中断した場合は、前のステップが終わったところまで戻せば進められる。
具体的には <NEXTCLOUD_ROOT>/updater-ocflfrurabky/.step を編集し、{“state”:“start”,“step”:5} の記載を {“state”:“end”,“step”:4} に書き換えてから『php –define memory_limit=1024M –define apc.enable_cli=1 occ upgrade』を再実行すれば良い。以下URLが参考となる。
３．４．２．既に最新版と言われる
明らかに最新版でないのに、『php –define memory_limit=1024M –define apc.enable_cli=1 occ upgrade』を実行すると既に最新版と言われる可能性がある。
これは何をしたくてこの表現にしたのか理解に苦しむが、実態としては『アップグレード準備が完了しましたわ』な状態で、アップグレードの適用まで至っていない状態。
以下コマンドで適用すると、次のメジャーバージョンアップグレードの処理を進められる。
php -d memory_limit=1024M --define apc.enable_cli=1 updater/updater.phar↓ 調査に役立ったURL
https://help.nextcloud.com/t/nextcloud-is-already-the-latest-version/156063
結果的にアップグレードに使うと◎なコマンドを載せておく。
# user #82(www-data) としてPHP-FPMサーバーでシェルを起動
sudo docker exec -u82 -it php-fpm /bin/sh
cd /path/to/the/nextcloud/root
# アップデート準備
php --define memory_limit=1024M --define apc.enable_cli=1 occ upgrade
# アップデートの適用
php --define memory_limit=1024M --define apc.enable_cli=1 updater/updater.phar
# アップデートの適用時にメンテナンスモードで残していた場合は、事後以下コマンドで復帰
php --define memory_limit=1024M --define apc.enable_cli=1 occ maintenance:mode --off