このblogをホストしているubuntuにloginしたら色々updateが溜まっていたようなので、気楽にupdateしてみた。するとここのwordpressが動かなくなった。どうも無理やりroutedで動かしていたのが動かなくなっていた。

今まではNATをしないためにiptablesをdisableにして、host側にrouting設定を入れておけばcontainerに対してもL3 routingしてくれてたのだが、どう設定してもそれがうまくいかなくなっていた。NATしない時はiptableやめちゃえって書いてあったはずの公式ドキュメントもない。いつの頃からかよく見るとiptablesのchain項目に’DOCKER xxx’というのが増えている。ここに設定している内容はiptables -Fとかでは全部消えないようで、iptables=falseとかしてもうまく動かない。chatgptが

どうやら新たに独自にrouted typeのbridge(network)を作ると、iptables他の設定はいじらずに通常のL3 networkはしてくれるっぽい。ただ、現在動いているコンテナのネットワーク設定は変えられないので、改めてcontainerを作るところから始めなきゃ行けないようだ。

とりあえず現在稼働中のやつのimageをとっておかねばというところで、mysql、wordpressのimageをcommitしておく

$ sudo docker commit momose-wordpress miscmemo-wordpress-latest:20240818
sha256:495adc56fa9dbd1cda8c969f7ab82d6f474d2871698e1d426f99523dd25efa04
$ sudo docker commit wp-mysql mysql:5.7.21-my20240818
sha256:4fb2a23c3b0016c3087e39be1453c01ce81a18df897a517a253d54a7f6f87bca

routedになるnetworkを作る。v6 prefixも指定し、gateway_mode_ipv4をroutedにし enable_ip_masqueradeをfalseにするのがポイント。

$ sudo docker network create --driver bridge --subnet 172.18.0.0/16 --ipv6 --subnet 2001:2c0:cc17:c302::/64  --opt com.docker.network.bridge.gateway_mode_ipv4=routed   --opt com.docker.network.bridge.enable_ip_masquerade=false   routed-net
e8df9d66c9e9b68d22eddd0464451b1e955f14df0d51fc14d24bfee383c1a30b

退避させた(というかcommitした)imageを使ってこのnetwork上にcontainerを作る。前のやつは止めたままにしておく。今までアドレスはhost起動直後に各コンテナを手動で起動させることでIP address固定にするという原始的とも言えないほど原始的なことをしていたが、今回からは専用bridgeを作ってそこでIPアドレスを固定にする。

$ sudo docker run -d --name miscmemo-wp-mysql --network routed-net --ip 172.18.0.2 -v /var/lib/mysql -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=mysql -e MYSQL_USER=wordpress -e MYSQL_PASSWORD=wordpress -p 3306:3306   mysql:5.7.21-my20240818
3abb3d2c34be91cbf8f0d48bee9491d84117713efaef12b371376e8502c02893
sudo docker run --network routed-net --ip 172.18.0.3 -v /var/www/html/:/var/www/html --name miscmemo-wordpress -d miscmemo-wordpress-latest:20240818
31ee2c1176cc7258b09fdf82b3c61d95e4762b6040c32b62c3c309ff743b4c17

ごちゃごちゃいじりすぎたので、docker本体をrestart。miscmemo-wordpress (wordpress本体; 172.18.0.3からmiscmemo-wp-mysql (wordpress用のmysql; 172.18.0.2)へのpingは通る。が、外(10.0.0.1とか)からは通らない。もちろん10.0.0.1には172.16.0.0/14宛のrouteはこのubuntu本体がnexthopになるようなrouteを設定してある。

これは例によってiptablesの設定が足りていなかろうということで、miscmemo-wordpress tcp:80宛は通るようにしておく。port限定しなくてもip全部通せばいいんじゃないかとも思うが、どうせ80以外は空いていないからとりあえずこれで。

$ sudo iptables -L
[sudo] momose のパスワード: 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy DROP)
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere            
DOCKER-FORWARD  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain DOCKER (2 references)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             172.18.0.2           tcp dpt:mysql
ACCEPT     icmp --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain DOCKER-BRIDGE (1 references)
target     prot opt source               destination         
DOCKER     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            

Chain DOCKER-CT (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED

Chain DOCKER-FORWARD (1 references)
target     prot opt source               destination         
DOCKER-CT  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere            
DOCKER-BRIDGE  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
RETURN     all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain DOCKER-USER (1 references)
target     prot opt source               destination         
momose@peso:~$ sudo iptables -I DOCKER 1 -d 172.18.0.3 -p tcp --dport 80 -j ACCEPT
momose@peso:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy DROP)
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere            
DOCKER-FORWARD  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain DOCKER (2 references)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             172.18.0.3           tcp dpt:http
ACCEPT     tcp  --  anywhere             172.18.0.2           tcp dpt:mysql
ACCEPT     icmp --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain DOCKER-BRIDGE (1 references)
target     prot opt source               destination         
DOCKER     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            

Chain DOCKER-CT (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED

Chain DOCKER-FORWARD (1 references)
target     prot opt source               destination         
DOCKER-CT  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere            
DOCKER-BRIDGE  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
RETURN     all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain DOCKER-USER (1 references)
target     prot opt source               destination         

この状態でもmiscmemo.momose.orgまたは172.18.0.3にwebで繋いでも’Error establishing database connection’になる。DBにloginできないということか?

db containerを作るときは-p 3306:3306してあるので、localhostに繋げばいけるはずだが、やはりいけない(これは謎)ので、172.18.0.2にmysql clientで繋いでみる。

docker runしたときにMYSQL_USERとかMYSQL_PASSWORD設定したせいか、それらのユーザは設定されているが、databaseとしてwordpressは定義されていない。

mysql> select User from mysql.user;
+---------------+
| User          |
+---------------+
| root          |
| wordpress     |
| mysql.session |
| mysql.sys     |
| root          |
+---------------+
5 rows in set (0.01 sec)
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
+--------------------+
2 rows in set (0.00 sec)

結論から言えば、これはvolumeの設定の仕方(-v option)の設定の仕方が悪い。上記例では ‘-v /var/lib/mysql’としてしか設定していないが、これはcontainer内部の/var/lib/mysqlをホスト側の匿名ボリュームを使え、ということしか指定していない。今回は新たに匿名ボリュームを作ってそれを内部で使おうとしているのに過ぎないので、今までのmysqlのデータは見れなくなっている。

今まで使っていたmysqlコンテナはdocker inspectすると

        "Mounts": [
            {
                "Type": "volume",
                "Name": "437162831f28b01734805001401217d94ae83d2c2ba91df5121bf27b1ec582c2",
                "Source": "/var/lib/docker/volumes/437162831f28b01734805001401217d94ae83d2c2ba91df5121bf27b1ec582c2/_data",
                 "Destination": "/var/lib/mysql",

で、hostの437…というvolumeを使っていたが、新しい方だと

        "Mounts": [
            {
                "Type": "volume",
                "Name": "ffbcf68f7e10fe79b6252f374094d4fd9ed61e0ac884ece61966cbdb7595b7cb",
                "Source": "/var/lib/docker/volumes/ffbcf68f7e10fe79b6252f374094d4fd9ed61e0ac884ece61966cbdb7595b7cb/_data",
                "Destination": "/var/lib/mysql",
 

となっていて、全く別のffbcという匿名ボリュームを指している。なので、旧データが復活できていない。

というわけで、mysqlデータが入っているはずの匿名ボリュームを指してコンテナを作り直す。

$ sudo docker run -d --name miscmemo-wp-mysql --network routed-net --ip 172.18.0.2 -v 437162831f28b01734805001401217d94ae83d2c2ba91df5121bf27b1ec582c2:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=mysql -e MYSQL_USER=wordpress -e MYSQL_PASSWORD=wordpress -p 3306:3306   mysql:5.7.21
434a61c30c7b967c440adbd8c3b518825da99e9b1be1b7e7463eb6f867a71c7f

一応これで旧mysqlデータも読み込めて、接続できるようになった。

が、なんかのはずみですぐこのmysqlコンテナが落ちる。通常の閲覧画面は見えるが、admin画面にアクセスしたら落ちる(画面的にはしばらく待たせられる状態になる。その後切れる)、loginしようとしたら落ちる、などなど。

原因はよくわからないので、この際旧データを吸い上げて新しいコンテナを設置の上、そのデータを読み込ませて復旧させることにした。

$ mysqldump -h 127.0.0.1 -u root --ssl-mode=DISABLED -p wordpress > miscmemo-wp.sql
Enter password: 
-- Warning: column statistics not supported by the server.

ここで読み込んだファイルの先頭に、CREATE DATABASE wordpress;USE wordpress;を入れる。

$ mysql -h 172.18.0.2 -P 3306 -u root -p < miscmemo-wp.sql
$ mysql -h 172.18.0.2 -P 3306 -u root -p 
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 19
Server version: 9.4.0 MySQL Community Server - GPL

Copyright (c) 2000, 2025, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show databases
    -> ;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| wordpress          |
+--------------------+
5 rows in set (0.01 sec)

mysql> use wordpress;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+-----------------------+
| Tables_in_wordpress   |
+-----------------------+
| wp_aal_products       |
| wp_aal_request_cache  |
| wp_aal_tasks          |
| wp_commentmeta        |
| wp_comments           |
| wp_links              |
| wp_options            |
| wp_postmeta           |
| wp_posts              |
| wp_pz_linkcard        |
| wp_term_relationships |
| wp_term_taxonomy      |
| wp_termmeta           |
| wp_terms              |
| wp_usermeta           |
| wp_users              |
+-----------------------+
16 rows in set (0.01 sec)

mysql> ^DBye

rootユーザでセットアップしてしまったためか、wordpress dbにアクセスできるのがwordpressユーザではなくrootユーザになってしまったので、wordpressコンテナの/var/www/wp-config.phpのUSERとPASSWORDをroot用のに変更、起動し直すと今度はうまくいった。adminアクセスとかも問題なさそう。

ただ、adminダッシュボード画面ではwordpress.orgにアクセスできないとか言っている。どうも外にうまく繋がっていないようだ。iptableで外向きもいけるように設定。

$ sudo iptables -I DOCKER 1 -s 172.18.0.3 -p tcp -j ACCEPT

実は外向けルータでnatのルールに172.18.0.3が入っていないことがわかったので、そっちも設定。FreeBSDの/etc/ipnat.rules、172.16.0.0/16だったのを172.16..0.0/14に。今までも172.17.x.xだったからいけなかったはずなんだがいけていたのはちょっと不思議ではある。

map ng0 172.16.0.0/14 -> 0.0.0.0/32 portmap tcp/udp 60000:65000
#map ng0 172.16.0.0/46 -> 0.0.0.0/32 icmpidmap icmp
map ng0 172.16.0.0/14 -> 0.0.0.0/32 proxy port ftp ftp/tcp
map ng0 172.16.0.0/14 -> 0.0.0.0/32
#

これで一通り復活はできた。途中作りまくった匿名ボリュームとか今後使わないだろうimageとかは決しておく。今のところこのエントリをかける程度までは安定して動いている。

iptablesを次のreboot前までには安定させないといけない。

ipv6を復活させよう。

結局ホスト機のマザーとかの不調というよりも、どうもmiscmemo blogを運用していた何でもubuntu VMの一部コンテナであるこのblogのコンテナのどれかが触られると固まるような気がしてきた。他のVM動かしても止まらないし。

そんなこんなでストレージも取り替え、ようやくこのblogをホストしているwordpress containerが復活したのでその顛末。

ESXi機不調

昨年(2024年)末ごろ、ESXi機に不調になり、突然反応がなくなる、突然リブートしてたり(ESXiコントロール画面で見ると、全VMが落ちている)といった事象が頻発していた。

熱暴走かな？と思ってある日本体を開けてみると、CPUファン近辺にホコリがみっしり。辛うじてファンは回っていたもののあまりの驚きに写真を撮るさえ忘れてしまった。これはエアダスターなどを駆使して除去し、一安心。

しかしその後も同じような不具合は頻発する。

• ACアダプタにはおそらく通電時には光るであろうLEDがついているが、全く光っていない。が、通常通り通電はしているように見える。もし不具合があるのだとしたら、出力が足りないのかもしれない
• ハードウェアの不具合だとすると、メモリが壊れている可能性もある。memtest86という世間でよく使われているらしいメモリテストソフトを使ってみた。これは特定のOSの上で動くアプリではなくこれごとbootしてメモリテストだけを行う。64GBに対して8時間ほどかかった。が、特に異常なし。
• 負荷がかかったに落ちるのかと、FreeBSD VMでyesをbackgroundで実行。このHWでこんなにファンが回るのかというくらいまで周り、消費電力も増えていることを確認したが、落ちなかった。

これらをやってもやはり数日で落ちる。

しばらくして分かったことは、しばらく落ちてなくても、どうやらubuntuを立ち上げて、この日記用コンテナをあげると、翌日くらいには落ちてるパターンが多かった、ということだ。

特定のVMがストレージの特定の場所(ここはきっとこの特定のVMに占有されているだろう)にアクセスするとハードウェア的に不安定になって落ちたりリセットがかかるのかもしれない。通常ストレージの一部が読めなくなったとしても、動いているVMにはエラーで読めなかったというステータスが返ってきてそのVMが不安定になるだけだが、今回の場合は何かハードウェア的な秘孔を突いた、ということなのかもしれぬ。

その傍証として、ホストハードウェアの交換も視野に入れてVMのイメージを別の場所にコピーしていた時、他のVMのイメージは時間はかかったとしても比較的リーズナブルな時間でコピーまたは移動は完了するのだが、ubuntu imageだけはなかなか終わらず、最後にはホストのUIも反応しなくなったということがあった。

このホスト機を導入した経緯はESXi機アップデートにあり。

Ununtuの必要データをサルベージ

ubuntuをはじめとするいくつかのVMは本体内のM.2 SSDに入っていたのだが、ubuntu以外は正常に外部のストレージに引越できた。

ubuntuはセッション繋ぎっぱなし用デスクトップとして使ったり、何も入っていないgitlabやkernel build専用のコンテナをホストしたりしていたが、これらはともかく、このブログは個人的に有用かもしれないメモとかあるので、何とかして救いたかった。救うべきものは三つ

• wordpress コンテナ
• wordpressコンテナが永続化ファイルとしてマウントしているwordpress用の各種ファイル
• mysqlコンテナ
• mysqlが持っている永続化されたデータ

コンテナ系はdocker saveで保存。復帰後にdocker loadでイメージを戻す。

永続ファイルとしてあるホストにあるファイルは、wordpressの方は単純にtarで固める。mysqlはデータファイルを復活できるかが自信なかったので、mysql dumpで全データをmysqlのコマンドとして吐き出す。

$ mysqldump -h localhost -u root --ssl-mode=DISABLE -p<password> wordpress > mysql-backup.sql

これらの過程でシステム不安定化させている秘孔をつかないとも限らないが、今回は何とか乗り切ったようだった。

VMホスト機再構築へ

ストレージ調達

とりあえずストレージが怪しいということで、新しいのを調達することとした。今使っているのはCrucialのやつだが、結構安めのものを選んでいた。もしかしてTBWの値も小さかったのかもしれない。

この反省を生かして、もっとよさそうなデータセンタークオリティということになっているWestern DigitalのWD Redにすることとした。(あれ、データセンタークオリティを謳っているのはWD Red Proだったかな)

買ったのはこれ。WDS100T1R0C [WD Red SN700 NVMe SSD（1TB M.2(2280) PCIe Gen3 x4 NVMe 2000TBW 5年保証）] [Amazon]

OS選定とインストール

何とか掬い上げたVM達を何とかそのまま使いたいということで、できればESXiを使いたいところだが、ESXiは去年のbroadcomの方針により無料バージョンがなくなった。

今使っていたESXi7のインストールメディアを探し出してそれを使うかと思っていたがそういえば一時期の不用品大パージのおりに使わないCD-ROMとか纏めて捨てたんだった。せめてイメージだけでも残っていないかとそれっぽいところも探したが、intel NIC対応インストールメディアを作る時の残骸があっただけだった。これでESXiの目はなくなった。Proxmoxにするかなあと思っていたところへESXi8.0u3が派手なアナウンスもなく、さらっと無料化復活へ、という情報が。

これはbroadcomで会員アカウントを作ればあとは無料でDLできるらしい。しかもIntel 226vドライバも対応。早速インストールしてみる。ちゃんとNICも認識した。webのデザインもだいぶフラット化というのかそんな感じだ。外部NASのiscsiも認識した。iscsiまたはNFSに置いたVMもあらかた復活できた。

ただ、今回も突然ホストごと固まるという事象が何回か散見された。ディスプレイが繋がっていないため、固まるとどうにもわからないので、ディスプレイは繋ぎっぱなしにしておく。

何回かはESXiの待機画面のまま固まっていた。後はいわゆるPSOD(Purple Screen Of Damage)の画面。

これをよくみると、PCPU 11: no heartbeatとある。何だかよくわからないが、PCPU(Performance CPU?)11が死んでるということのようにもみえる。もしかしたらC-StateとかでCPUが一旦寝てしまうと起きてこないのかもしれない。

BIOS設定画面でP-StateとかC-Stateっぽい設定があったので、それらをdisableしてみる。ただ同じ筐体のデフォルト設定でESXi7は何年も動いていたのに？

ただ、これらの設定で、とりあえずは今はまだ理不尽なリセットは起きていない。

最悪この理不尽リセットが続くようであれば、機種移行も検討しなければならない。今考えているのがhttps://amzn.to/4dF8tTO 8C16T AMD Ryzen 7 PRO 6850H。amazonでは度々セールをしていて5万円弱。AliExpressだとベアボーンでもっと安く売っている。

ubuntu復活

前述のように他のVMはvmx右クリックですぐ復活できたが、ubuntu imageはサルベージできなかったので、OSインストールからやり直す必要がある。

desktopの設定、dockerのインストールは通常通り。

その先の設定、実はこのblogの最初の記事に書いてあるので、このblogを復活させないと設定方法がわからないという実に缶切りは缶詰の中状態。サルベージしたsqlファイルの中身を見たり、何とか思い出して設定を行なった。

ここのdockerホストはcontainer networkに対してNATではなくL3 networkを提供するようにしているので、このdockerdに対してはiptablesを無効化し、提供するIPv6のprefixを指定する。

ExecStart=/usr/bin/dockerd --iptables=FALSE --ipv6 --fixed-cidr-v6="2001:2c0:cc17:c301::/64" -H fd://

各コンテナはまずバックアップしたファイルからimageをrestoreする。

sudo docker load < mysql5.7.21.tar.gz
sudo docker load < miscmemo-wordpress-latest.tar.gz

これでimageは入った。

$ sudo docker images
[sudo] momose のパスワード:
REPOSITORY                  TAG       IMAGE ID       CREATED        SIZE
miscmemo-wordpress-latest   latest    40af751e8d84   2 months ago   725MB
hello-world                 latest    74cc54e27dc4   4 months ago   10.1kB
mysql                       5.7.21    5195076672a7   7 years ago    371MB

mysql containerを作成、DBを復旧させる。

sudo docker run -d --name wp-mysql -v /var/lib/mysql -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=mysql -e MYSQL_USER=wordpress -e MYSQL_PASSWORD=wordpress -p 3306:3306 mysql:5.7.21
mysql -h 127.0.0.1 -P 3306 -u root -p --ssl-mode=DISABLED < miscmemo-wordpress.backup/mysql-backup.sql

WordPressの永続化部分を展開。いろいろわかってなくて変なところに展開する

cd /var/www/html
tar xfz <somewhere>/wordpress-data.tar.gz
cd wp-content/wp-uploads
tar xfz <somewhere>/wordpresss-uploads.tar.gv

しかたないので、そこ(/var/www/html)を永続化のvolumeとしてマウントすることにする。でもその前に、どうやらWordpressに登録してあるDBの接続情報が違っていたようなのでwp_config.php内のdefine( ‘DB_NAME’, ‘wordpress’ ), define( ‘DB_USER’, ‘root’ ), define( ‘DB_PASSWORD’, ‘root’ ); define( ‘DB_HOST’, ‘172.17.0.1’ ); を修正する。

で、wordpress containerを立ち上げる。

sudo docker run -v /var/www/html/:/var/www/html --name momose-wordpress -d miscmemo-wordpress-latest

ここにhttp://172.17.0.3/で繋げられればめでたしめでたし。

今後

• ここらへんのcontainerをdocker compose対応にする
• 定期的に止めて、中の埃を掃除する

最初のmomose.orgブログ開設-とその顛末_エントリにもあるように、 このblogのwordpressは公式のdocker imageを使っている。この公式のimageはphpのsourceをこのコンテナ内にDLしてきてそれをbuildしてインストールするようなことをしているので、コンテナ内でapt upgradeとかするわけにもいかない。したところでいろいろ公式イメージとは齟齬が生じそうだ。

ここはやはりdockerっぽく、imageをアップグレードしてコンテナを作り直すのが正しそうである。

ただ、wordpressは写真などのメディアファイルをアップロードすると、wordpressコンテナ内の/var/www/html/wp-content/uploads以下に置くので、コンテナを移行する前にこれをレスキューする必要がある。また、これらはblogのコンテンツ同様ずっと持っておくものなので、どこかホストのディレクトリにおいておいて、コンテナ起動時に-vでマッピングするのがよさそうである。

まずはメディアファイルディレクトリをレスキュー。momose-wordpressとすべきところがタイプミスで今日までmomose-worpressになっているのはご愛嬌。このおかげで新旧がくべつしやすくなって移行が少しやりやすくなった。次からどうしよう。

(host)$ docker cp momose-worpress:/var/www/html/wp-content/uploads wordpress-content-uploads

最新イメージの取得、旧コンテナの停止、新コンテナの起動

(host)$ docker pull wordpress
(host)$ docker stop momose-worpress
(host)$ sudo docker run --name momose-wordpress --link wp-mysql5:mysql -d -p 8080:80 -v /home/momose/wordpress-content-uploads:/var/www/html/wp-content/uploads wordpress

どうやらwp-config.phpはauthenticateのハッシュ値などが異なるようで、そのままでは使えなさそうな雰囲気。ここはブラウザから新しいコンテナに直接つないで設定し直したほうがよさそう。

あと使っていたプラグイン(Enlighter Inline CodeとPz-Link Card)を追加。こういうのも後で引き継げるような方策を考えたほうがいいかもしれない。

これで一応移行は出来たはず。本当はhttps化とかしておきたいところだが、どうにもうまくいかないので、これはまた後日。(ここに書き足すかもしれない)

追記(2023.06.15): https化成功

Apacheで、miscmemo用のSSL設定を書き、https://miscmemo. …の時は内部ネットワークのwordpressコンテナにreverse proxyするような設定をしていたのだが、今までうまく行っていなかった

• 本文はhttpsで通信しているっぽいが、呼び出している.js, .cssなどがhttpでリンクされているので、昨今のブラウザはそこら辺は読んでくれないっぽい。なので本文は表示されるが、cssとかが読まれないので表示が乱れまくる。
• URLに/loginを追加してログイン後に管理画面に入ろうとしても変なところに繋ごうとしてうまくログイン画面が出てこない
• とりあえずhttpでlogin画面に入り、「設定」→「一般」で”WordPressアドレス(URL)”をhttps://〜に変えて、httpでもhttpsでもloginしようとするとリダイレクトループが発生してにっちもさっちも行かなくなる。
  • この症状が最初に出た時は設定画面に二度と入れなくなるので、mysqlコンテナに入って、直接この設定が入っているレコードを修正。その手順については秘密のノートで。

「wordpress https リダイレクトループ」でググると、以下の設定をwp-config.phpに入れると良いみたいなことが書いてあってほんまかいなと思いながらやってみるとうまく行った。ログインはもちろん、ページ全体のhttps化も。

define('WP_HOME', 'https://miscmemo.momose.org');
define('WP_SITEURL', 'https://miscmemo.momose.org');
$_SERVER['HTTPS'] = 'on';

本ブログ創設以来4年ほど経ってようやく懸案事項解決。か?

追記の追記(2023.06.18)

新container上のwordpressはv6ではlistenしているようだが、sslではlistenしていないので、v6ではsslではつながらないことになる。実際、http://[v6 address]は繋がるが、https://[v6 address]ではつながらない。が、v6共存networkにいても繋がっているのはsafariのhappy eyeballのおかげなんだろうか。

追記の追記の追記(2023.07.03) – IPv6 SSL化の件

前記の通り、当初の「IPv6は直にWordPressコンテナへ、IPv4は仕方がないので入り口でReverse Proxy」というのが、SSL化した場合にうまくいっていない感があったのだが、とりあえずWordPressコンテナもSSL化してみた。

1. Let‘s Encryptでmiscmemo.momose.orgの証明書を取得
   • certbotはmomose.org本体で動かしているので、証明書本体は momose.org:/usr/local/etc/letsencrypt に格納される
2. WordPressコンテナからもこれを参照できるようにする
   • momose.orgからはNFS exportし、Wordpressコンテナはこれをマウントできるようにする。
   • が、これがどうやってもうまくいかない。ただでさえNFSは難しくて俺も苦手だというのを差し置いてもうまくいく気がしない。
   • もう仕方がないので今回は丸ごとletsencryptディレクトリを固めて持ってきた。
3. WordPressコンテナのSSL有効化
   • WordPressコンテナではWeb serverとしてApacheが使われているのだが、configの書き方がいつものFreeBSDでやっているのと相当勝手が違う。いつものserverではhttpd.confはSSLも何も一個のファイルにしてしまって、秘伝のタレ状態になっているのだが、WordpressコンテナのbaseであるDebianでは/etc/apach2/以下に整然と分けられていて、サイトでサポートされているconfigがsite-available/に、有効にされているものがsite-enable/にあって、コマンドで有効無効を切り分けたりする。SSLの場合はsite-available/default-ssl.confなんてものがあるのだが、そんなことは知らんので、default-ssl.confをsite-enable/にコピーしてきてしまった。
4. configの中のSSLCertificateFileは/etc/ssl/certs/ssl-cert-snakeoil.pem、SSLCertificateKeyfileが/etc/ssl/private/ssl-cert-snakeoil.keyを参照しているので、それぞれletsencryptのfullchain.pem, privkey.pemを指すようなシンボリックリンクを作る

あとはWordpressコンテナをrestart。再びコンテナのシェルでapt install iproute2をしてss -aで443をlistenしているかをチェック。

https://miscmemo.momose.org/ にアクセスして、コンテナのss -aでIPv6 SSLのセッションがあったかを確認する。

あとはconfigの設定を綺麗にしたり、ペンディングしているコンテナからFreeBSD NFS serverのマウント、接続した時にIPv6ならkameが踊る(でなくともなんかIPv6で繋がったよマーク)ような仕組みを作り込んでおきたい。

ところがどっこい、Let’s encrypt証明書のアップデートに失敗 (2023.09.09)

miscmemo.momose.orgの証明書がアップデートできないよ、あと一週間で切れちゃうよ、という警告メールが来た。certbotによる証明書の更新は、そのドメイン直下の.well-known/acme-challengeディレクトリにサインされたファイル名をtouchしておいて、Let’s encryptからそこのURL(この場合はhttps://miscmemo.momose.org/.well-known/acme-challenge/<signed file name>)にアクセスすることで確認するのだが、これはcertbotからfilesystem的に見えるところにないといけない。

今回https://miscmemo.momose.org/に来るときに、IPv6でまず来てしまうので、Containerの方に行ってしまうが、そこのDocumentRootのディレクトリはこのcertbotからは見えないので、結局認証に失敗してしまう。

なんとかアクセスをIPv4に強制できれば、momose.org内で完結するのだが、その方法はどうやらない。ので、一時的にDNS serverからmiscmemo.momose.orgのIPv6アドレスを外す。

momoseorg.dbの$TTLとSOAのMinimumと念のためにRefreshをそれぞれ3600から360(6分)にしてnamed再起動。1時間経った頃にmiscmemo.momose.orgからAAAAを外し、named再起動。6分後にcertbot renew。成功したら各パラメータを元に戻し、/usr/local/etc/letsencryptをtar.gzし、Dockerホストにscp、DockerホストからWordpress Containerの/tmpにdocker cp。/tmp/letsencrypt.tar.gzを/etcに展開、コンテナ再起動。古い/etc/letsencryptは消す。

これを3ヶ月ごとにやらなければいけないというのはなかなか辛い。

更に追記(2023.07.05) – 接続時にIPv4かIPv6かを表示

「ダッシュボード」→「外観」→「テーマファイルエディター」のfunctions.phpに以下を追加。add_shortcode()しておくと後で本文中で’[v4orv6]‘とか書いておくと、IPv4かIPv6かが表示できる。が、本文でそんなことする使いでがあるかどうかはわからない。

function v4orv6() {
  $ip = $_SERVER['REMOTE_ADDR'];
  if (filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_IPV4)) {
      // IPv4
      return "IPv4[" . $ip . "]";
  } else {
      // IPv6
      return "IPv6[" . $ip . "]";
  }
}
add_shortcode('v4orv6', 'v4orv6');

template-parts → header → site-branding.php で、

			$description = get_bloginfo( 'description', 'display' );

を

			$description = get_bloginfo( 'description', 'display' ) . ' ' . v4orv6();

に変更。

これでblogのキャッチフレーズ欄のところにv4 or v6、および接続元アドレスが表示される。イマイチ格好はよくない。

こんなにテーマファイル弄り回ったら次バージョンアップがしにくいんじゃないか。

基本的にmomose.orgのあらゆるサービスはns.momose.orgで行なっているが、WordPressを入れるためだけにいつものサーバーを汚すのもなあ、ということで、ここでは世間で流行りのdockerを使ってcontainerで実装して見た。

ただ、メインサーバーはFreeBSDだが、dockerは奥まったところにあるESXi上で動いているUbuntuの上で動いており、IPv4的には世間から到達できない場所にある。が、幸いにもIPv6的にはcontainerに対してもGlobalアドレスをつけることができたので、とりあえずはIPv6による提供、ということにしたいと思う。

ここではとりあえずdockerでどうインストールしたかのメモだけ。

Linuxの用意

これはもうすでに用意してある。かねてより何かに使おうと思ってインストールしておいたUbuntuを今回は使う。

とりあえずパッケージ等を最新にしておく。

必要に応じてホストをリブート。

$ sudo apt update
$ sudo apt upgrade 

dockerをインストール&&セットアップ

dockerをインストール。dockerとdocker-ioを入れなければいけない感じ?

$ sudo apt install docker docker-io

ここで素直にsystemd(systemctl)でdockerdを立ち上げるとIPv6がenableされないので、IPv6がenableされるように設定する必要がある

systemdでdaemonを立ち上げる時の各種設定は/lib/systemd/system以下にあり、dockerの場合はそのディレクトリのdockerd.service。ただし、設定を変えるときはこのファイルを弄るのではなく/etc/systemd/system以下に同名のファイルを作る。起動時はこちらが優先される。これは差分だけおけばいいような気もするが、数回の試行ではうまくいかなかったので、結局 /lib/systemd/system/docker.service を丸ごとコピーして必要な部分を変更することにした。本当は差分だけでいいのかもしれない。diffはこんな感じ

$ locate docker.service | xargs diff -c
*** /etc/systemd/system/docker.service	2019-01-29 17:56:57.559635761 +0900
--- /lib/systemd/system/docker.service	2018-09-27 11:39:50.000000000 +0900
***************
*** 10,18 ****
  # the default is not to use systemd for cgroups because the delegate issues still
  # exists and systemd currently does not support the cgroup feature set required
  # for containers run by docker
! ExecStart=
! #ExecStart=/usr/bin/dockerd --ipv6 --fixed-cidr-v6="2001:2c0:cc17:c301::/64" --default-gateway-v6="2001:2c0:cc17:c301::1" -H fd:// 
! ExecStart=/usr/bin/dockerd --ipv6 --fixed-cidr-v6="2001:2c0:cc17:c301::/64" -H fd:// 
  ExecReload=/bin/kill -s HUP $MAINPID
  LimitNOFILE=1048576
  # Having non-zero Limit*s causes performance problems due to accounting overhead
--- 10,16 ----
  # the default is not to use systemd for cgroups because the delegate issues still
  # exists and systemd currently does not support the cgroup feature set required
  # for containers run by docker
! ExecStart=/usr/bin/dockerd -H fd://
  ExecReload=/bin/kill -s HUP $MAINPID
  LimitNOFILE=1048576
  # Having non-zero Limit*s causes performance problems due to accounting overhead

要するに、立ち上げ時のパラメータとして –ipv6 –fixed-cidr-v6= を入れるのが肝要。もののwebには–default-gateway-v6=がいる、と書いてあるのもあるが、これで<network address>::1を指定するとdocker側でもdocker0インタフェースに同じアドレスをつけようとするのか、’Address is already used’と言われてしまうので、::1である限りは不要のようだ。

このとき、dockerのホストであるUbuntuがルータになって、dockerコンテナが別サブネットにあることになる。なので、あとはこのUbuntuでIPv6パケットフォワーディングができるようにし、自宅IPv6ルータからこのサブネットへのルーティングを設定すれば良い。

ちなみに公式ドキュメントによれば、コンテナ用インタフェースであるdocker0をL2ブリッジにするという方法もあるようだ。

後は通常通り、docker serviceを立ち上げるだけ。

$ sudo systemctl start docker.service

WordPressコンテナのインストール?デプロイ?

既にdockerリポジトリにはWordPress及びWordPressに必要なmysqlのコンテナがあるので、それを使う。こういうのはdocker composerというのを使うのが通例だそうだが、今回は愚直にそれぞれのイメージをpullして、それぞれに立ち上げることにする。

$ sudo docker pull wordpress
$ sudo docker pull mysql:5.7.21

mysqlのコンテナをpullするときに上記のようなバージョンを指定しないと最新版(Ver8系列?)をpullしてしまうので、バージョン指定は必要。

WordPressはDBたるmysqlに依存しているので、Mysql→WordPressの順で起動。ここでコンテナ名を指定するときにバージョンを指定しないと、最新版をとってこようとするので、ここでもバージョン番号を明記する。

$ sudo docker run --name wp-mysql5 -e MYSQL_ROOT_PASSWORD=<password> -d mysql:5.7.21
$ sudo docker run --name momose-wordpress --link wp-mysql5:mysql -d -p 8080:80 wordpress

起動後、docker ps -aとかすれば各コンテナが上がっているのがわかる。STATUSがUPになっていればOK。

$ sudo docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS              PORTS                  NAMES
3592eb4aceb4        wordpress           "docker-entrypoint.s…"   5 seconds ago        Up 4 seconds        0.0.0.0:8080->80/tcp   momose-worpress
450c9adde11d        mysql:5.7.21        "docker-entrypoint.s…"   About a minute ago   Up About a minute   3306/tcp               wp-mysql5

mysqlコンテナはすでに永続化対応されているようで、これ以上の対応は必要ない。ただ同じイメージで別のインスタンスを立ち上げると永続化に使っているディレクトリを共有してしまいそうな気はするので、複数mysqlコンテナを立ち上げる時はそこは気にする必要があるかもしれない。

ネットワーク設定

このWordPressコンテナにはIPv6アドレスが付いているので、このアドレスを直接、あるいはDNSに登録してやれば、IPv6ならばグローバルからアクセスできる。IPv6アドレスの確認は確認はdockerホストからdocker inspectコマンドでいける。

$ sudo docker inspect 3592 | grep IP
            "LinkLocalIPv6Address": "",
            "LinkLocalIPv6PrefixLen": 0,
            "SecondaryIPAddresses": null,
            "SecondaryIPv6Addresses": null,
            "GlobalIPv6Address": "2001:2c0:cc17:c301:0:242:ac11:3",
            "GlobalIPv6PrefixLen": 64,
            "IPAddress": "172.17.0.3",
            "IPPrefixLen": 16,
            "IPv6Gateway": "2001:2c0:cc17:c301::1",
                    "IPAMConfig": null,
                    "IPAddress": "172.17.0.3",
                    "IPPrefixLen": 16,
                    "IPv6Gateway": "2001:2c0:cc17:c301::1",
                    "GlobalIPv6Address": "2001:2c0:cc17:c301:0:242:ac11:3",
                    "GlobalIPv6PrefixLen": 64,

結果を見るとわかるように、IPv6アドレスのホストID部はEUI64ではなく、このコンテナに割り振られたIPv4アドレスが埋め込まれている。このアドレスの永続性は保証されていないと思われるので本来ならば何か別の手法でWordPressのURLをコンテナに対して適宜ルーティングしてくれる仕組みを入れるべきだが、とりあえずこれは将来の課題ということにする。

IPv4からの接続

何しろ奥まったところにあるのでIPv6によるグローバルリーチャビリティがあればあとはいいや、というつもりでいたが、ちょっと簡単な仕組みでIPv4からの接続性も確保してみる。

今ここについているmiscmemo.momose.orgというホスト名はIPv6ではWordPressコンテナのアドレスに、IPv4はmomose.orgに向いている。IPv6の時は直接WordPressにアクセスできるが、IPv4の時はmomose.orgのVirtualHostで受けて、プライベートのIPv4アドレスがついているWordPressコンテナにreverse proxyするようにしている。

しかし実はこのような仕組みは世間のwebサービスとしてはごく一般的なもので、特筆するようなものでもない。違いは世間のはipv4だろうがipv6だろうが一箇所で受け止めてreverse proxyするのだが、ここではv6だけは何としても直に通そうとしている点。こんなことするとTLS化した時に参照する証明書が分散してしまって何もいいことはないのだが、まあ今回はそこはそれということで。

当初はreverse proxyする先はdockerホストの8080ポートあてだったが、何故だかいつ頃からか8080にアクセスしてもWordPressコンテナにポートフォワードしてくれなくなった(iptablesをdisableしてあるからか?)ので、今は直接WordPressコンテナに繋ぐようにしている。

通常dockerdを立ち上げるとコンテナ収容ネットワークとdockerホストの外部ネットワーク間はNATしているのだが、今回はこのNATを切り、IPv6同様自宅ルータにコンテナ収容ネットワーク宛ルートを作る。併せてうちの場合はルータがFreeBSDなので、ipnat.rulesに172.17.0.0/16もNATする旨の設定も付け足す必要がある。dockerdでNATをやめるのに一番簡単な方法なのは、iptablesを無効にするだけ(–iptables=Falseをdockerdの起動オプションに追加)。

ExecStart=/usr/bin/dockerd --iptables=False --ipv6 --fixed-cidr-v6="2001:2c0:cc17:c301::/64" -H fd:// 

しかし、’–fixed-cidr-v6’なんていうオプションがIPv6でCIDRとか言いますかねぇ、みたいな気分が、なんともいえぬイマイチ感を惹起させる。

終わりに

そんなこんなでWordPressで一発目の記事を書いてみた。本家日記と違ってこちらは一般的に書いてgoogle先生にも見えるようにして、世間の集合知に貢献しようかと思ったが、あまりそんな感じに書けなかったので、やはり世間からは隔絶しておくことにする。

それに飽きたらさっさと閉じそうな気もするし。