⑥Dockerコンテナのメンテナンスとトラブルシューティング

はじめに

　このブログの⑤で解説したDockerコンテナのメンテナンスとトラブルシューティングについてまとめました。compose.yamlの内容はこのブログの⑤を確認ください。

wordpressのデータのバックアップ

　バックアップする必要のあるフォルダはwordpressフォルダの中のhtmlとmysql、https-portalの３フォルダです。htmlフォルダはwordpressのインストールフォルダ。mysqlフォルダはmaria.dbのデータフォルダ。https-portalフォルダはSSL証明書が保管されています。これらをバックアップして戻せばバックアップ時の状態にWordPressを回復できます。ただし、バックアップすると、持ち主が自分に変わってしまいます。もともとの持ち主はrootだったりするので、コンテナからファイルの変更や保管ができなくなってしまいます。ここで紹介している事例では持ち主はrootに戻してます。

wordpressのバージョンアップ

　WordPressに備わっているアップデート機構によりアップデートできます。compose.yamlを書き直して最初からインストールする方法もあるかもしれませんが、面倒なのでやってません。

Google Search Console

　サーバのメンテナンスとは関係ないですが、サーバのWEBページがどこからどれだけアクセスされているか情報を得ることができます。googleの承認が必要ですが、htmlファイルをWEBサイトにアップロードしろと言われます。これはwordpressフォルダの中のhtmlフォルダに保管しで申請ボタンを押すだけで承認されました。

トラブルシューティング

• 携帯でサーバのWordPressのサイトが閲覧できない。
  ・携帯のAPNの設定を確認のこと。IPｖ６も併用するよう変更。
• docker compose up -dコマンドでエラーが発生する。
  ・compose.yamlの記入ミスを確認のこと。全角スペースの混在に注意。
• WordPressのサイトが表示されない。
  以下を確認しましょう。
  ・https-portalのDOMAINS:で指定しているURLはWordPressで設定したURLと一致しているか。
  ・DNSで設定したURLのIPv6アドレスとサーバのIPv6アドレスを一致しているか。
  ・https-portalの証明書の期限が切れていないか。無効になっていないか。
  ・https-portalフォルダの持ち主がrootになっているか。rootでないと更新した証明書を保存できなくなる場合があります。
• WordPressのアップデートや画像のアップロードなどができない。
  ・DockerのWordPressのhtmlフォルダの持ち主が自分になっていると更新できない場合があります。持ち主をrootに戻します。
• SSL証明書が取り込めているか確認したい。
  ・Dockerのhttps-portalコンテナのログを調べることで証明書が取り込めているか確認できます。Let’s EncryptにSSL証明書申請は、1時間に５回までの制限を超えると次の月曜まで証明書を申請できないので注意が必要です。これを避けるためhttps-portalフォルダをvolumes:に設定して置くことをおすすめします。詳細は⑤Dockerの設定を参照ください。
• 急にサイトが表示されなくなった。ERR_CONNECTION_REFUSEDが表示される。
  ・SSL証明書が更新できているか確認する。（https-portalコンテナのログを調べる）
• WordPressの各投稿のタイトルとプラウザのタブの表示内容が一致しない。
  ・投稿の編集画面の一番下のメタボックスにプラウザのタブの内容を記載するテキストボックスがある。ここにテキストを入力すると内容がプラウザのタブに表示されてしまうので、表示内容が一致しなくなる。テキストボックスの内容を削除する。

コンテナのログのとり方

• https-portalコンテナのログを取りたい場合

１）　docker container lsコマンドを実行
２）　IMAGE列がsteveltn/https-portal:1である行のNAMES列にあるコンテナ名を確認する。
３）　docker logs -f コンテナ名　コマンドを実行するとログが表示される。

修正の履歴

• UBUNTU24.04.2に更新（クリーンインストール、20250409）
• Domainをgororon.spaceからgororon.mydns.jpに変更(20250622)
• インターネット回線をNTT光からeo光に変更。(20260630)
• IPv4に対応。（20260706）

おわりに

　これまでに発生したトラブルをまとめてみました。けっこう原因究明に悩まされます。引き続きこのサーバの運営を継続します。