Docker on 或る阿呆の記

AIによるサイバー攻撃時代の個人サイト・個人ブログのセキュリティ

Sat, 24 Oct 2026 00:00:00 +0900

定期的にくる全裸待機イベントがPHPに襲来。

PHPに「緊急」レベルの脆弱性2件修正版を日本時間21日深夜に公開へ、事前準備を呼び掛け - ITmedia NEWS

全裸で待て！

とにかく地球がヤバい

技術的な詳細が不明なのは仕方無いですが、「とにかくやべぇからPHPユーザは全員23時全裸な！」ということで、こういうことがあると、WordPressユーザとしては限界みを感じます。特に昨今はAIのせいでサイバー攻撃が激化していることもあり、それは自動ですから、場末の当サイトも常にアタックを受けていることを思うと、対策しないわけにもいきません。

そんでまぁ、当日こられた方は珍しくサイトに赤帯出ているのを見たかもしれません。

で、23時前からしばらく落としました。

それでまぁしばらくは、X上でも様々な人が話題にしていて、少し本当にお祭りのような気分になりテンションも上がりました。

著名ITサービス相次いで緊急メンテへコドモン、シャドバ、BASE、さくらのレンタルサーバなど「PHP」脆弱性に起因か（1/2 ページ） - ITmedia NEWS

当サイトはDocker版のため、大元のPHPの更新から降ってくるまでけっこう時間がかかりました。一人ポチポチと下記コマンドでDocker版の更新はまだかなぁと確認していました。

curl -s "https://hub.docker.com/v2/repositories/library/wordpress/tags/latest" | grep -o '"last_updated":"[^"]*"'

これの結果が2026-10-21T14:00より後になったらOKなのですが、結局"last_updated":"2026-10-21T17:50:57.852281Z"を確認できたのは夜中の3時くらいだったかな。お、と思ってイメージ更新して、バージョンを確認します。

$ docker run --rm wordpress:latest php -v
PHP 8.3.36 (cli) (built: Oct 21 2026 15:57:18) (NTS)

OK、ということでサイト復活。この頃になると大方みんな対策が終わっており、Docker版を話題にしている人はほとんどおらず、なにしてるんだろうなぁという気分になっていました。

せっかく頑張ったので青帯で頑張りましたの告知を誰に向けたわけでもなくしています。複数サイトやってるので対策は複数やったのですが、このサイトでしか帯は出していません。所詮個人サイト、告知というより祭り参加表明だったので…。場末でも一応今も技術系のサイトのつもりだしね。

実際の所脅威はどれくらいだったの？

終わってみると、かねてより考えてはやめていた脱WordPress計画も現実味を帯びてきます。今回のようなことが今後もけっこうありそうだな、とまず思えました。地味にNode.jsも騒がれていましたしね（「「Node.js」にセキュリティ更新～10件の脆弱性を修正、「eMudhra」の侵害にも対応 - 窓の杜」）。

しかし実際のところ、今回の脅威（後にphp2shellとされる）が本当にどれほどの被害をもたらすものだったのかは謎です。真の影響力について実はちょっと疑っています。CVSSスコア9.2とか数字ばかり独り歩きし、対策しなければサービスにあらずみたいな空気が醸成されても、本当のところどうだったのかはわからないわけでしょう。試みがあったということ自体は既に「PHP「緊急」脆弱性悪用の試み、数百万件に CloudflareのCEOが報告 - ITmedia NEWS」のようにニュースになっていますけれど、ではそれでどうかなったのか…。

この手のものは、何か起きていた時にはもう遅いのだとか、未来の危機を予言した預言者が迫害されるとか、まぁそんな話になるわけですが、しかし今回については、PHPサイトの有名どころとしてアンサイクロペディアがノーガード戦法だったらしいので、今後このサイトがどうなるのかでわかるかもしれません。

UnNews:PHPに史上最悪級の穴、世界が予防停止する中アンサイクロペディアだけ止められる人がおらず平常運転。 - アンサイクロペディア

サイト内でもネタにされています。しかしまだやってたんですね。元気そうでなにより。

ま、だからといって事前に脅威を告知されればやらないわけにはいかないんですが…今回の脅威はOpenAIが検知したとのことでしたけれど、世界中が一斉に全裸待機するほどのものだったのかな…とは少し思います。個人的には見えている脅威はそりゃ対応すべきだと思うんですが、祭り状態になるのも何か違和があります。

今後こんな感じでAIにより新たな脆弱性発見！深刻度9.3…9.4…100だーーーー！全裸で待て！とか毎日のように言われることになったら、みんなどこまでついていくんだろう。どうせ侵入されても詫びメール一本で済ます癖に…（余計なこと）。今回総理大臣までツイートしていましたが、総理のツイートは脆弱性の報告で埋まるんでしょうか。

怪しいもんです。対応した中の人はこれが技術的に必要なことだという思いで対応されたかもしれませんが、組織の観点では、やるべきことはやりましたというポージング、免責の観点でコストを払っているように思われます。でなければ、事前対応は熱心なのに、いざ本当にインシデントが起きたら詫びメール1本で済ませようとする態度は説明がつきません…。ま、情報漏洩のエース・タイムズカーはPHPではなかったようですが（永遠に言い続ける）。

クラウドなら安心伝説

まぁそうはいっても、現実上のセキュリティリスクは確かに上がっているのでしょう。求められるセキュリティパッチの適用であるとか、対策なんかは、これから目に見えて高まっていくのかなぁ、という感じはしています。

これについて、中小まして個人が防ぎ切るのはもう無理だ、クラウドに任せよう！みたいな論調も最近はちらほら見かけるのですが、大手クラウドなら信用できるのか？と思います。実際、最近俺たちのGMOがやられました。

「お名前.com デスクトップクラウド」不正プログラム設置で全プラン停止 FX用VPS、2万6739サーバに影響か - ITmedia NEWS

これは記事だと実際どこまで基盤に侵入されたのかわからないんですが、不正にプログラム設置されてるんですよね。少なくともそこにおいては実行権限まで取られている中で、本当にGMOの言う通り情報閲覧があるかも程度の被害なのかな…僕がユーザだったらちょっと信じられないですけどね。まぁ実際被害者は滅茶苦茶可哀想ですよ、FX自動取引の基盤でしょう。つらすぎる（実感）。

……とか書いて予約投稿していたんですが、Xを見ていたら次の展開が。

https://x.com/yutoriineet/status/2113264833307267254?s=20

口座破綻させられているのあまりにも悲惨で可哀想過ぎる。ご愁傷さまです……。これマジで洒落にならない金額の被害が出ているのでは。やっぱり情報閲覧程度じゃなかったのか。攻撃されたといえば企業は被害者だが、本当の被害者は企業を信じて情報を預けたのに漏洩されたユーザで、企業はその被害を隠蔽と過小申告するモチベがあるから信じられない。報道する側も企業側の言うことをそのまんま垂れ流すだけじゃダメだし、見る側ももっと疑う必要がある。……と言い始めるとちょっと話が完全に逸れるので、本件滅茶苦茶興味深いけどここまでにしておいて…。

まぁこういう投資にかかるサービスで、クラウドを銘打ったサービスで、GMOがやられた、というのはこれは重たいんじゃないでしょうか（GMOだけど）。いや、ここでいうクラウドとはAWS/GCP/Azure/OCIとかそのへんのことを言うのだ、AWSにあらずんばクラウドにあらずみたいなことは言えるかもしれないし、実際信用レベルでいえばまだかなり差があるのはそうなんですけれど、しかしAWSだから大丈夫だ、は原理原則の話をするならやはりあり得ず、それは技術的判断というより信仰というべきではないでしょうか。

一方でAWSがやられたらもう仕方ない、は現実的な妥協点として言えるかもしれません。もしかしたらそういう気持ちは業界としてあるのかなぁという気もするし、正直私も組織のエンジニアの立場ならそう言ってしまう気はします。ただ一人の場末の管理者として考えた時、それはすごく納得できません。

まぁこれは信条なので並行線なんですけれど、ただ個々人がそれぞれ自分の城で守るのは合理の観点でも無謀とは言えません。まず分散されることによって、攻撃側は攻撃成功時の報酬が下がるため、モチベーションが著しく低下します。多くの小規模サービス・サイトで標的型攻撃の的になる可能性はかなり下がるでしょう。また、自分ところでの対策はネットワーク層、物理層などあらゆるところで対策が打てるため、本当に必要な保護を必要なだけやることができます。極端なことを言えば最終奥義物理遮断も可能です。

一方で大手サービスは高い壁があるものの、その壁を超えられると全員巻き添えでとんでもない被害になりますし、またその時出来ることは非常に限られています。

まぁイメージとしては高い壁に囲まれたデカくて整った街にレンタルオフィスを構えるか、孤島に手作りの拠点を構えるのかという違いになるわけですけれど、AIがあろうがなかろうが、リスクのトレードオフの本質が変わらない以上、どちらが間違っているとも言えないんじゃないでしょうか。少なくとも私は討ち死にするならせめて自分の居場所で死にたい。

まぁそうは言っても、自動攻撃も今後激しくなっていくことは予想され、無駄にアタックサーフェスが多いことから、WordPressはちょっと限界を感じています。そろそろ10年ぶりくらいのサイト大改造に着手する時がきたのだろうか…。

<関連記事>

/timescar/

あわせて読みたい

タイムズカーと焼肉きんぐの個人情報漏洩における深刻さのベクトルの違い

/timescar-yakinikuking/

あわせて読みたい

セキュリティリスク再考 KADOKAWAの情報漏洩レベルでも特損36億円らしい

/securityrisk/

WordPress が Web サーバーにアクセスする必要があります。次に進むには FTP の認証情報を入力してください（大嘘）

Sun, 04 Oct 2026 00:00:00 +0900

早くWordPressを更新しろ！間に合わなくなっても知らんぞーーー！！って脅してくるから更新しようとしたら

要求されたアクションを実行するには、WordPress が Web サーバーにアクセスする必要があります。次に進むには FTP の認証情報を入力してください。認証情報が思い出せない場合は、ホスティング担当者に問い合わせてください。

などと意味不明な供述をしてきたときの対応。多分DockerでWordPress使っている時によく出てくる、と思われる。大昔ネイティブで運用していた頃には見たことなかった気がする。

次に進むには FTP の認証情報を入力してください。（大嘘）だし、そもそもホスティング担当者（私）なので、例によって全然違う対応をする必要があります。

環境

Docker版だよ。

Linux Mint Xfce 22.3
Docker version 29.8.1, build 4a63305
- WordPress 7.1 -> 7.12

原因

Webサーバドキュメントルートの/var/www/htmlの権限問題が発生していると思われます。なんで発生しているのかは知らん。なぜなの？

コンテナ内でのパーミッション修復手順

docker-compose.ymlのあるところに移動して、とりあえずコンテナに入ります。

docker compose exec wordpress bash

違ったらdocker compose psでSERVICE列を確認します。

/var/www/htmlにいる状態から始まります。で、ls -ldすると所有権がrootになっていました。

以下のコマンドを実行してWebサーバーの実行ユーザーに所有権を戻します。

chown -R www-data:www-data /var/www/html

実行後、Web画面から再度更新を実行して、通ればOK。

エラーメッセージは永遠に

どうでもいいんですけど、IT関係のエラーメッセージの不親切さは永遠なんでしょうかね。あまりにも意味不明過ぎて逆に検索適応性が高いという謎の事象も発生。AI革命だのAIでもう知識労働は不要だのAIで人類絶滅だのなんかセンセーショナルな記事ばかり出てきますが、結局わからないのはAIツールの吐き出す謎のエラーメッセージ、そして何よりエラーの原因であったりします。

GoogleのAIコーディングツール、Antigravityでよく見るエラーメッセージ

あの日見たエラーメッセージがなんだったのか僕たちは永遠に知らない…。

セルフホストしたUmamiでWordPressサイトのアクセス解析

Fri, 21 Aug 2026 00:00:00 +0900

Google Analytics代替として候補にあがる、セルフホストのアクセス解析ソフトUmamiを使っていく。

GitHub - umami-software/umami: Umami is a privacy-first analytics platform. Traffic, campaigns, behavior, conversions, and revenue in one place — no cookies, no tracking, self-hosted or in the cloud. · GitHub

なお公式サイトはisドメインなんだけれど、なぜか弾かれる。Cloudflare経由で接続するといけるのでおまかんっぽいんだがアイスランドに嫌われるようなことしたっけ？

まぁそれはいいとして、今回インストールでは「How to Install Umami Analytics on Docker (2026 Guide)」の記事を参考にさせていただきました、っていうか正直うちの記事よりこの記事のほうが詳しいからこっち見たほうがいいよｗ

じゃあなんで書くのかというと、記事は消えるから……。10年以上もブログやっていると「この記事が詳しいです！」で雑に案内だけ貼ったリンクが消える消える。まぁ微妙に情報補足と雑なWordPress案内も追加したので…。

環境

Umami@3.2.0
自宅サーバ
- ThinkPad L390, Core i5-8265U, 32GB RAM
Linux Mint Xfce 22.3
- docker 29.7.2
Cloudflare Tunnel

インストールと最初の設定

`docker-compose.yml`

以下でランダムな文字列を作る

openssl rand -hex 32

文字列はコピーしておく。

.envを作成する。以下のAPP_SECRETにさっきのランダム文字列を入れる。パスワードは適当に入れる。

POSTGRES_USER=umami
POSTGRES_PASSWORD=your-secure-password
POSTGRES_DB=umami
APP_SECRET=run-openssl-rand-hex-32-to-generate
DISABLE_TELEMETRY=1

docker-compose.ymlを編集。元記事からimageのURLだけ差し替えた（エラー出たので）。ポート番号は変えたかったら変える。バージョン固定したかったらする。ちなみにvつかないらしい（v3.2.0ではなく3.2.0）。

services:
 umami:
 image: umamisoftware/umami:postgresql-latest
 ports:
 - "3000:3000"
 environment:
 DATABASE_URL: postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@umami-db:5432/${POSTGRES_DB}
 APP_SECRET: ${APP_SECRET}
 DISABLE_TELEMETRY: ${DISABLE_TELEMETRY:-1}
 depends_on:
 umami-db:
 condition: service_healthy
 init: true
 restart: always
 healthcheck:
 test: ["CMD-SHELL", "curl http://localhost:3000/api/heartbeat"]
 interval: 5s
 timeout: 5s
 retries: 5

 umami-db:
 image: postgres:15-alpine
 environment:
 POSTGRES_DB: ${POSTGRES_DB}
 POSTGRES_USER: ${POSTGRES_USER}
 POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
 TZ: UTC
 volumes:
 - ./umami-db-data:/var/lib/postgresql/data
 restart: always
 healthcheck:
 test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
 interval: 5s
 timeout: 5s
 retries: 5

ここで、参考記事によると、Cloudflare Tunnelを使っている場合、Umamiから見ると全部CloudflareのIPを取ってしまうので、docker-compose.ymlのenvironmentに以下を追記せよとのことであった。

CLIENT_IP_HEADER: cf-connecting-ip

VPSとかで直接公開してCaddyをリバースプロキシにしている場合はヘッダの付与よしなにしているから不要なはず。

準備が出来たら、docker compose upでエラーが出ないことを確認する。いけたらdocker compose up -dでバックグラウンド起動。

最初の設定

http://<IPアドレス>:<ポート>にアクセスして、ユーザ名adminとパスワードumamiでログイン。

当然危ないので、管理者設定からパスワードを変更する。ユーザ名も変更できる。

言語設定も日本語あり。

ネットワーク設定

トラッキングデータの送信はクライアントマシンから行うため、グローバルに公開する必要あり。

全体の流れは以下 by AI。

sequenceDiagram
autonumber
actor Client as クライアント
participant WP as WPサーバー(ブログサイト)
participant Umami as Umamiサーバー(セルフホスト)
Note over Client, Umami: 1. ブログページの読み込み
Client->>WP: ① ページリクエスト (アクセス)
WP-->>Client: ② HTML返却 (Umamiのscriptタグを含む)
Note over Client, Umami: 2. アクセス解析データの送信 (クライアント直接)
Client->>Umami: ③ script.jsの読み込みリクエスト
Umami-->>Client: ④ script.jsの返却
Client->>Umami: ⑤ 閲覧データ(PV等)を直接送信 [要グローバル公開]

うちの場合は例によってCloudflare Tunnelで開通している。

ここでサブドメインだが、参考記事によるとanalyticsとか使うと広告ブロッカーに遮断される率が上がるらしい。参考記事ではstatsやmetricsやtrackなどにせよと言われている。

WordPressサイトの解析

別にWordPressサイトじゃなくてもやることは同じ。

トラッキングコードの取得

サイドバーの「Webサイト」より、管理したいドメインを追加する。

追加したら、Editを開くと以下のようなトラッキングコードが取得できる。

<script 
 defer 
 src="https://your-umami-domain.com/script.js" 
 data-website-id="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx">
</script>

基本はこれを<head>タグに貼り付けること。

タグの貼り付け

プラグイン「Integrate Umami」があるが、<head>タグに貼り付けるだけなのでプラグイン使う必要はないかなと思う。

うちはテーマとしてSwellを使っているので、「外観」「カスタマイズ」「高度な設定」から「headタグ終了直前に出力するコード」にコードを貼り付け。

自分だけ除外とかするなら functions.phpでログインユーザにはトラッキングコードを出さないとかしないといけないかなと思う。

実測で確認

しばらくダッシュボードを見てきちんと動いているか確認する。

まぁなんか動いてそう。使い方についてはおいおい見ていこうと思う。

以上。ちなみに最初AIに聞いて作業していたんだが、古いバージョンの情報に惑わされて完全に無能だった。

セルフホストしたWebアプリになぜかうまくアクセスできない時のチェック

Mon, 10 Aug 2026 00:00:59 +0900

私的メモ。そりゃそうだ集。症状は様々なので症状から逆引きというより流し読みして心当たりあるやつを思い出す集。構成が複雑になるほど、「端末Aでは症状A’になるが端末Bでは症状B’になる」など発生する。がんばれ。

環境

Linuxが基本。メインはLinux Mint Xfce。

一般

localhost以外からのアクセスを許可してない

症状: ローカル端末からはアクセスできるし正常に起動しているが、他端末からアクセスできない。

アプリ側でそういう設定になってるので、変更できるか否かという感じ。

ファイアウォールで許可していない

症状: ローカル端末からはアクセスできるし正常に起動しているが、他端末からアクセスできない。

間抜けなことにこれは本当によくある。

ファイアウォールの設定確認する。ufwの場合のコマンド。

sudo ufw status

空いてなかったら追加。

sudo ufw allow <ポート番号>

セキュリティグループ的なので許可していない

AWSをはじめとするクラウドとかVPSで、そもそもネットワークインタフェースに到達していないケース。許可しよう。

ポートの競合

症状: なんかうまくいったりいかなかったりする

複数のアプリケーション、なんなら同一のアプリケーションでポートが競合している。調べるときのコマンドはこれ。

sudo lsof -i :8080

AdGuardHome(AGH)とかLAN内DNSを使っている場合

LAN内DNSに向いてない

症状: LAN内ドメインだけ名前解決できない

そもそも論としてLAN内DNSに向いてない。ルータでDNSをLAN内のやつ指定するか、あるいは各クライアントでそれぞれ設定するか。

AGH側でDNS書き換え設定を忘れている

症状: LAN内ドメインだけ名前解決できない

稀によくある。設定しよう。

サブドメインの法則決めてワイルドカード使うのが楽ではある（ワイルドカードを使えばサブドメインの証明書発行を知られないというのもある。まぁサブドメイン知られたところで別にLAN内限定公開なら問題ないかもしれないが気持ち悪いので…）。

IPv6が優先されている

症状: 名前解決できない。端末によってはできることもある。

AdGuardHomeで頑張ってIPv6対応するか、ルータで切れるならIPv6切るか、あるいはクライアントでIPv6を切るか。クライアントで切る場合は対応はOSによって異なる。Macは基本的にDNSサーバをIPv4で設定すればいけると思うのだが、Windows/Linuxは明示的にやる必要あり。Androidはアプリ使う必要がある。自分はRethinkDNSを使っている。iOSは持ってないから知らない。

このとおり、OSによって状況が異なるため「端末AではいけるけどBではいけない」ということが起きうる。さらに同じOSでも設定してたりしてなかったりすると、それでも異なる症状になったりする。めんどくさい。

あわせて読みたい

LAN内DNSでIPv6は使わないのでWindowsでIPv6を無効化する

/landnsipv6windowsipv6/

/android-lan-agh-dns/

Caddyを使っている時

AGH + Caddyまで持っていくとだいぶ捗るけど構築は面倒くさい。DNS-01チャレンジを利用しているとエラーパターンが増える。

Caddyfileの設定を忘れている、間違えている

稀によくある。設定しよう。ドメインの前にスペース空いてないとかよくある examp.com{。caddy validateとcaddy fmt --overwriteしよう。Docker版ならサービス名caddyの時

docker compose exec caddy caddy validate --config /etc/caddy/Caddyfile

フォーマットは

docker compose exec caddy caddy fmt --overwrite /etc/caddy/Caddyfile

Caddyfileの設定を読み込むのを忘れている

ファイル書き換えただけで。リロードしよう。

caddy reload

Docker版

docker compose exec caddy caddy reload --config /etc/caddy/Caddyfile

証明書の発行に失敗している

症状: 証明書エラー

自己証明書以外のとき。ログを見て判断。利用しているレジストラに対応したCaddyを使っているか確認。あとAPIの権限を確認。

証明書を発行していない

症状: 証明書エラー

Docker版で docker compose up -dリロード代わりにした場合、証明書が発行されないまま。docker compose downしてから起動し直す。

(Docker利用時) バインドマウントを忘れている

症状: 404エラーがでる

Docker版Caddyを使っている時。ホストマシンのディレクトリをそのまんまfile_serverとか使ってホスティングする場合、バインドマウントしないと当然見えない。

Tailscaleを使っている場合

最近使ってないけど、使っていたときはややこしかった。特にAGH、Caddyと併用するとカオス。

MagicDNSがうまく機能しない

Tailscaleから付与されるIPアドレスを直打ちするほうが無難。

AGHと一緒に使う

TailscaleのDNSをAGHに向けること。

個人的にはこの構成はそもそも管理がとても複雑なのでやめたほうがいいように思う。

<参考>

/splitdns/

Cloudflare Tunnelとか使っている場合

トンネルが落ちている、接続されていない、間違えている

当たり前の見落としをよくする。

トンネルが競合している

症状: 繋がったり繋がらなかったりする

Docker版とネイティブ版両方動かしていたりとか、よくわからないことをすると起きる。

WordPress(Docker)をコンテナとボリュームごと別マシンに移行するスクリプト

Sun, 14 Jun 2026 15:37:33 +0900

以下の記事の自動化スクリプト。

あわせて読みたい

コンテナ構築のWordPressサイトを別マシンに移行する

/container-wp/

やることとやらないこと

やること
- 移行元からボリュームをバックアップして、移行先で復元する
やらないこと
- 移行後のルーティング

スクリプトでやっていることについて図示する。バックアップ中はダウンタイムとなるので注意。

flowchart TD
subgraph Local["ローカルマシン (移行元)"]
direction TB
A[YAMLからボリューム一覧を取得] --> B[移行対象のボリュームを選択]
B --> C[元マシンのコンテナ停止]
C --> D[選択ボリュームのバックアップvackup export]
D --> E[元マシンのコンテナ再開ダウンタイム短縮]
E --> F[設定ファイル一式とバックアップを転送rsync]
end
subgraph Remote["リモートマシン (移行先) SSH経由で自動実行"]
direction TB
G[作業ディレクトリに移動]
H[ボリュームのリストアvackup import]
I[ネスト構造の解消vackup-volumeを直下へ移動]
J[移行先コンテナ起動docker compose up -d]
K[リモートの一時バックアップ削除]
end
F -->|ネットワーク転送| G
G --> H
H -.各ボリュームごとにループ.-> I
I --> J
J --> K
subgraph Local_Cleanup["ローカルマシン (完了後)"]
L[ローカルの一時バックアップ削除]
end
K -->|処理完了| L

準備

移行元から移行先に、sshで転送できるようにしておく。
- 移行元はLAN内のマシンで、移行先はVPSとする。
移行元と移行先にdockerとdocker composeとvackupを入れる。

vackupについては以下。

あわせて読みたい

DockerのボリュームをCLIでバックアップ・復元する

/docker-volume-cli-backup/

また、移行元のディレクトリ構成を以下のようにする。

.
├── site1
│   ├── custom-php.ini
│   └── docker-compose.yml
├── site2
│   ├── ads.txt
│   ├── custom-php.ini
│   └── docker-compose.yml
└── migrate-wp.sh

上記のディレクトリ構成で、migrate-wp.shを実行すると、転送先のマシンにコンテナの設定とボリュームごともってく。ディレクトリごともっていくので、見えていないが.envも含む。

スクリプトと実行

スクリプトは以下。AIが書いた。

#!/bin/bash

# エラー発生時にスクリプトを終了
set -e

# 引数のチェック
if [ "$#" -ne 3 ]; then
 echo "Usage: $0 <dir_name> <user@ip> <remote_base_path>"
 echo "Example: $0 site1 user@192.168.1.50 /home/user/wordpress"
 exit 1
fi

DIR_NAME=$1
REMOTE_TARGET=$2
REMOTE_BASE_PATH=$3

LOCAL_DIR="./$DIR_NAME"
REMOTE_DIR="$REMOTE_BASE_PATH/$DIR_NAME"

# ローカルディレクトリの存在確認
if [ ! -d "$LOCAL_DIR" ]; then
 echo "Error: Local directory '$LOCAL_DIR' does not exist."
 exit 1
fi

echo "=== 1. ボリューム名の取得 ==="
cd "$LOCAL_DIR"

# docker compose config を使ってボリューム名一覧を取得
VOLUMES=$(docker compose config --volumes)

if [ -z "$VOLUMES" ]; then
 echo "Error: No volumes found in docker compose config for $DIR_NAME."
 exit 1
fi

echo "対象ボリューム:"
echo "$VOLUMES"

echo "=== 2. 元マシンのコンテナ停止 ==="
docker compose stop

echo "=== 3. ボリュームのバックアップ (vackup) ==="
mkdir -p volume-backups
for vol in $VOLUMES; do
 echo "Exporting volume: $vol"
 vackup export "$vol" "volume-backups/$vol.tar.gz"
done

echo "=== 4. 元マシンのコンテナ再開 (ダウンタイム短縮) ==="
docker compose up -d

echo "=== 5. 移行先へのファイル転送 (設定ファイル一式 + バックアップ) ==="
cd ..

# 移行先にターゲットディレクトリを作成
ssh -o ServerAliveInterval=60 "${REMOTE_TARGET}" "mkdir -p ${REMOTE_DIR}"

# フォルダごとリモートへ同期
rsync -avz --progress -e "ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=10" \
 "$DIR_NAME/" "${REMOTE_TARGET}:${REMOTE_DIR}/"

echo "=== 6. 移行先でのボリュームリストアと起動 ==="

# 変数内の改行をスペースに変換する
VOLUMES_ONELINE=$(echo "${VOLUMES}" | tr '\n' ' ')

REMOTE_SCRIPT=$(cat << EOF
cd "${REMOTE_DIR}"

for vol in ${VOLUMES_ONELINE}; do
 echo "----------------------------------------"
 echo "Processing volume on remote: \$vol"
 
 # リストアを実行
 vackup import "volume-backups/\$vol.tar.gz" "\$vol"
 
 # vackup-volume のネスト構造を修正
 echo "Fixing nested directory structure for \$vol..."
 docker run --rm -v "\$vol":/volume alpine sh -c "
 if [ -d /volume/vackup-volume ]; then
 mv /volume/vackup-volume/* /volume/ 2>/dev/null || true
 mv /volume/vackup-volume/.[!.]* /volume/ 2>/dev/null || true
 rmdir /volume/vackup-volume 2>/dev/null || true
 fi
 "
done

echo "----------------------------------------"
echo "Starting containers on remote host..."
docker compose up -d
EOF
)

# 移行先マシンでリストア処理を実行
ssh -o ServerAliveInterval=60 "${REMOTE_TARGET}" "${REMOTE_SCRIPT}"

echo "=== 7. ローカルの一時バックアップを削除 ==="
rm -rf "$DIR_NAME/volume-backups"

echo "=== 移行プロセスが完了しました ==="

使い方は以下。

./migrate-wp.sh site1 VPSのユーザ@VPSのIPアドレス /home/VPSのユーザ/wordpress

これを実行すると、移行先に~/wordpress/site1ができる。すでにコンテナの実行までされている。

なので、あとはDNSなどを操作して移行元から移行先に向けるとか、ルーティングで必要なことをやれば移行完了。

以上。

Growi (Docker) をコンテナごと別マシンに引っ越す

Sat, 13 Jun 2026 13:10:29 +0900

環境

移行元
- Intel Mac mini 2018
- Docker Desktop
- Growi 7.x
移行先
- Linux Mint Xfce 22.3
- Docker 29.2.1
- Growi 7.x

基本的な手順

手順はWordPressのコンテナ移行とほぼ一緒なので、下記記事を参考にすること（雑）

あわせて読みたい

コンテナ構築のWordPressサイトを別マシンに移行する

/container-wp/

全体の流れと微妙な差分を下記にメモ。

移行元でコンテナを停止してボリュームをバックアップし、移行先にアーカイブを送信
移行先でボリュームを復元

ここでElasticsearchの書き込み権限がなかったりするので修正する

移行先のdocker-compose.ymlでボリューム名を指定する
docker compose upしてブラウザで動作確認

の流れ。ボリューム名の定義と、権限の修正あたりが若干の追加要素となる。

ボリューム名は通常はフォルダ名にデフォ名つくような感じだろう。たとえばgrowiフォルダでは以下のようになっているだろう。

local growi_es_data
local growi_growi_data
local growi_mongo_configdb
local growi_mongo_db

これらについて、docker-compose.ymlでes_dataやgrowi_dataとなっているところをそれぞれ修正する。そしてexternalをtrueにする。ここらへんは上記WordPress記事のymlを見て参考に。

docker compose upで様子を見るが、もしかするとElasticsearchでエラーが出てしまうかもしれない。これはElasticsearchコンテナの権限問題であるため、以下のコマンドで修正する。

docker run --rm -v <ボリューム名、たとえばgrowi_es_data>:/mnt alpine chown -R 1000:1000 /mnt

雑だが、以上。

Docker版WordPressの更新でFTPの認証情報を求められた時

Thu, 11 Jun 2026 10:19:31 +0900

環境

Linux Mint Xfce 22.3
Docker 29.5.3
WordPress 6.9.4 -> 7.0

症状

WebブラウザでWordPressを更新しようとしたら、以下のようにFTPの接続情報を求められた。

原因と対応

Webサーバのユーザがwww-dataになっていないと考えられる。確認する。

docker compose excc <wordpress> /bin/bash

ターミナルに入って、/var/www/htmlのパーミッションを見てみる。

root@:/var/www# ls -l
total 4
drwxr-xr-x 5 root root 4096 May 18 03:05 html

oh…。

ログアウトして修正する。

docker compose exec <wordpress> chown -R www-data:www-data /var/www/html

この後、WebブラウザよりWordPressで更新を実行すると、更新できるようになる。

以上。

Trilium Notes (Docker) のマシンを移行する

Sun, 07 Jun 2026 21:21:36 +0900

現在運用しているTrilium Notesについて、Intel Mac mini 2018 + Docker Desktop から Linux Mint Xfce 22.3のサーバマシンに移行する。

環境

Trilium Notesのlatest
移行元
- Intel Mac mini 2018
  - macOS Sonoma 14.6.1
  - Docker Desktop for mac v4.76.0
移行先
- ThinkPad L390
- Linux Mint Xfce 22.3
  - Docker 29.5.2

手順

移行元のマシンで停止する。

docker compose down

docker-compose.ymlでデータディレクトリを確認する。TRILIUM_DATA_DIRがどうなっているか見る。

# Running `docker-compose up` will create/use the "trilium-data" directory in the user home
# Run `TRILIUM_DATA_DIR=/path/of/your/choice docker-compose up` to set a different directory
# To run in the background, use `docker-compose up -d`
services:
 trilium:
 # Optionally, replace `latest` with a version tag like `v0.90.3`
 # Using `latest` may cause unintended updates to the container
 image: triliumnext/trilium:latest
 # Restart the container unless it was stopped by the user
 restart: unless-stopped
 environment:
 - TRILIUM_DATA_DIR=/home/node/trilium-data
 - TZ=Asia/Tokyo
 ports:
 # By default, Trilium will be available at http://localhost:8080
 # It will also be accessible at http://<host-ip>:8080
 # You might want to limit this with something like Docker Networks, reverse proxies, or firewall rules,
 # however be aware that using UFW is known to not work with default Docker installations, see:
 # https://docs.docker.com/engine/network/packet-filtering-firewalls/#docker-and-ufw
 - '8080:8080'
 volumes:
 # Unless TRILIUM_DATA_DIR is set, the data will be stored in the "trilium-data" directory in the home directory.
 # This can also be changed with by replacing the line below with `- /path/of/your/choice:/home/node/trilium-data
 - ${TRILIUM_DATA_DIR:-~/trilium-data}:/home/node/trilium-data
 # - /etc/timezone:/etc/timezone:ro
 - /etc/localtime:/etc/localtime:ro

ここでは~/trilium-dataとなっている。ついでにMacで/etc/timezoneがなかったのでコメントアウトされているね。

とりあえずアーカイブ化しよう。

tar -czvf trilium-data-backup.tar.gz ~/trilium-data

こいつを新しいマシンに転送してやる。

scp trilium-data-backup.tar.gz ユーザ@IPアドレス:移行先のパス

新しいマシンで、これを保存先ディレクトリ上に展開する。今回はtrilium-dataにしている。

tar -xzvf trilium-data-backup.tar.gz

保存先ディレクトリに入って、もしデータベースの一時ファイルが存在したら削除する。

rm -f document.db-shm document.db-wal

準備ができたらコンテナの起動。とりあえずフロントで。

docker compose up

エラーなく起動したら、http://IPアドレス:ポートにアクセスする。以前使っていたパスワードでログインできることを確認する。

問題なければOK。Ctrl-cで停止して、改めてバックグラウンドで起動する。

docker compose up -d

これでOK。しばらく動かして、安定していることを確認したら元のコンテナは削除してよい。

<関連記事>

/evernote-notion-trilium-notes/

コンテナ構築のWordPressサイトを別マシンに移行する

Sun, 24 May 2026 00:00:00 +0900

現在常時稼働サーバがMac・Linuxと無意味に分かれている。Linuxマシンに統一してIntel Mac mini 2018には予備役となってもらうように、少しずつ機能を移行している。今回は自宅サーバのWebサイト。つまりこのサイト。

環境

Mac上で展開していたDocker + WordPressのサイトを、別マシンに移行する。前回の移行時はプラグインを使って復元したのだが、せっかくコンテナでやってるのにそれではかいがないと思い、今回はCLIで実施。

元マシン: Intel Mac mini 2018
- Docker Desktop 4.73.0
移行先マシン: Linux Mint Xfce 22.3
- Docker 29.5.0
GitHub - BretFisher/docker-vackup: Script to easily backup and restore docker volumes · GitHub

vackupコマンドの中身については以下の記事を参照。

あわせて読みたい

DockerのボリュームをCLIでバックアップ・復元する

/docker-volume-cli-backup/

手順

全体は以下。

元マシン：コンテナを停止する
元マシン：ボリュームのエクスポート
元マシン：コンテナを再開する
元マシンからコンテナにボリュームをコピー
移行先：ボリュームをリストア
移行先：コンテナを起動
移行先：localhostにアクセスして復元されていることを確認する
リバースプロキシなどで向け先を移行先に。元サイトは落とす

元マシン：ボリュームのバックアップ

コンテナは持ち運べるとして、問題は永続化ボリュームをコピーすること。ここでは、docker-compose.ymlは以下のようなものとする。変数は.envで定義しているとする。内容は、WordPressとDBそれぞれコンテナたててるよ、それぞれボリュームを指定して使うよ、というもの。

services:
 hp_wordpress:
 image: wordpress:latest
 ports:
 - "ポート番号:80"
 environment:
 WORDPRESS_DB_HOST: データベースコンテナ
 WORDPRESS_DB_USER: ${DB_USER}
 WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}
 WORDPRESS_DB_NAME: ${_DB_NAME}
 volumes:
 - hp_wordpress_data:/var/www/html
 - ./custom-php.ini:/usr/local/etc/php/conf.d/custom-php.ini
 restart: always
 depends_on:
 - db

 db:
 image: mariadb:latest
 environment:
 MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
 MYSQL_DATABASE: ${DB_NAME}
 MYSQL_USER: ${DB_USER}
 MYSQL_PASSWORD: ${DB_PASSWORD}
 volumes:
 - db_data:/var/lib/mysql
 restart: always

volumes:
 hp_wordpress_data:
 external: true
 db_data:
 external: true

volumeとして、hp_wordpress_dataとdb_dataを外部で作成したものを使うような設定になっている。

現在のボリュームを確認する。

docker volume ls

ターゲットとなるボリューム名と存在することを確認しておく。

コンテナを停止する。

docker compose stop

以下のコマンドでバックアップ。

mkdir volume-backups
vackup export WPボリューム名 volume-bakcups/WPボリューム名.tar.gz
vackup export DBボリューム名 volume-bakcups/DBボリューム名.tar.gz

ダウンタイムを小さくしたいなら、この時点で元マシンをdocker compose up -dで復帰させる。

転送する。

rsync -avz --progress volume-backups ユーザ@移行先:移行先のパス/

容量大きくて途中でdisconnectされるときは

rsync -avz --progress -e "ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=10" volume-backups ユーザ@移行先:移行先のパス/

移行先マシン：ボリュームのリストア

作業ディレクトリに移動し、ボリュームを復元する。

vackup import WPボリューム.tar.gz WPボリューム名
vackup import DBボリューム.tar.gz DBボリューム名

これで問題ないはずだが、なぜか自分の環境でよくわからんことになっていたので、ボリュームの中身を確認しておく。以下のように直下にされておらずvakcup-volumeがあるかもしれない。

$ docker run --rm -v ボリューム:/volume alpine ls -lh /volume
total 4K 
drwxr-xr-x 6 999 ping 4.0K May 18 02:53 vackup-volume

vackup-volumeなる親ディレクトリが出来ていて、その下にディレクトリがあるようだ。

この場合は以下のコマンドによりvackup-volume以下を展開する。

docker run --rm -v WPボリューム名:/volume alpine sh -c "mv /volume/vackup-volume/* /volume/ 2>/dev/null || true; mv /volume/vackup-volume/.[!.]* /volume/ 2>/dev/null || true; rmdir /volume/vackup-volume"

もう一度ボリュームを確認したら直下に展開されていることがわかる。DBのほうのボリュームも同様に。

これでいけるが、なんかよくわからんことをしている。

後日実行したときは再現しなかったので、なんだかよくわからない。

起動と疎通確認

最後にもう一度docker-compose.ymlを確認し、コンテナを起動する。

docker compose up

エラーとか出ないかを確認するため、最初はフォアグラウンドで。http://localhost:ポートにアクセスし、いつもの画面が表示されることを確認する。インストール画面が出たら初期化されちゃってます。なにか間違えているので最初からやりなおし。やりなおした🥺

問題なければ正式にバックグラウンドで動かす。

docker compose up -d

移行元から移行先に向ける

準備が整ったので、DNSやらリバースプロキシやらいじって、移行元から移行先に向ける。

この時点で移行元を落としていいが、いつ落とすかは考え方による。ダウンタイムを小さくするなら移行元をしばらく残しておいてもいい。しかし、変に残しておいてナイスタイミングでコメントついてしまい、消えてしまうみたいな事故が起きる可能性もあるので、何がいいとも言えない。僕はいらなくなったら落とす。

インフラはAI無能

最初これくらいAIがすぐできるだろうと思ったけど何か色々ハマってしまって、結局手作業で心を込めてやりました。インフラ周りは固有の環境や設定が多すぎるので、汎用的な一般解を出し続けるAIは無能になりがち。

それにしてもこの手の作業をするとき、昔書いた記事を参考にすることがよくあるのだけれど、このサイト自身が対象のとき、失敗するとサイト自体が落ちてしまって閲覧することができないっていう。まぁそれを考えると、ニッチな記事でもnoteに転載していくのは保険としての意味もあるか。釈然としないけど。

今後Linuxマシンは色々なハードウェアを検証していくため、移行作業はスクリプト化してスムーズに検証できる体制を整えたい。

追記：自動化した

けっこう何度も引越ししているので、スクリプトで自動化した。

/wordpressdocker-script/

Docker on 或る阿呆の記

AIによるサイバー攻撃時代の個人サイト・個人ブログのセキュリティ

とにかく地球がヤバい

実際の所脅威はどれくらいだったの？

クラウドなら安心伝説

WordPress が Web サーバーにアクセスする必要があります。 次に進むには FTP の認証情報を入力してください（大嘘）

環境

原因

コンテナ内でのパーミッション修復手順

エラーメッセージは永遠に

セルフホストしたUmamiでWordPressサイトのアクセス解析

環境

インストールと最初の設定

docker-compose.yml

最初の設定

ネットワーク設定

WordPressサイトの解析

トラッキングコードの取得

タグの貼り付け

実測で確認

セルフホストしたWebアプリになぜかうまくアクセスできない時のチェック

環境

一般

localhost以外からのアクセスを許可してない

ファイアウォールで許可していない

セキュリティグループ的なので許可していない

ポートの競合

AdGuardHome(AGH)とかLAN内DNSを使っている場合

LAN内DNSに向いてない

AGH側でDNS書き換え設定を忘れている

IPv6が優先されている

Caddyを使っている時

Caddyfileの設定を忘れている、間違えている

Caddyfileの設定を読み込むのを忘れている

証明書の発行に失敗している

証明書を発行していない

(Docker利用時) バインドマウントを忘れている

Tailscaleを使っている場合

MagicDNSがうまく機能しない

AGHと一緒に使う

Cloudflare Tunnelとか使っている場合

トンネルが落ちている、接続されていない、間違えている

トンネルが競合している

WordPress(Docker)をコンテナとボリュームごと別マシンに移行するスクリプト

やることとやらないこと

準備

スクリプトと実行

Growi (Docker) をコンテナごと別マシンに引っ越す

環境

基本的な手順

Docker版WordPressの更新でFTPの認証情報を求められた時

環境

症状

原因と対応

Trilium Notes (Docker) のマシンを移行する

環境

手順

コンテナ構築のWordPressサイトを別マシンに移行する

環境

手順

元マシン：ボリュームのバックアップ

移行先マシン：ボリュームのリストア

起動と疎通確認

移行元から移行先に向ける

インフラはAI無能

追記：自動化した

WordPress が Web サーバーにアクセスする必要があります。次に進むには FTP の認証情報を入力してください（大嘘）

`docker-compose.yml`