復習5日目_20251127

IT

Day5：Docker運用復習（安定化）

ゴール：更新や復元が安全に行える状態にする

今日のゴールは「Docker環境を壊さずにアップデート・復元できるようにする」

① docker-composeの基本操作（再確認）

~/に壊れたdocker-compose.ymlがあったので、

mv docker-compose.yml docker-compose.certbot.bak

で、名前を変えて退避させた。

私の環境の場合

~/wordpress フォルダが、本命の Docker 構成ディレクトリなので、

cd ~/wordpress
docker-compose ps

で、状況確認したところ、以下のように

Name Command State Ports
————————————————————————————————————————
kaiga python Kaigashikibetsu.py Up 8000/tcp
wordpress docker-entrypoint.sh php-fpm Up 9000/tcp
wordpress-certbot-1 /bin/sh -c echo ready Exit 0
wordpress-db-1 docker-entrypoint.sh mysqld Up 3306/tcp, 33060/tcp
wordpress-nginx-1 /docker-entrypoint.sh ngin … Up 0.0.0.0:443->443/tcp,:::443->443/tcp,
0.0.0.0:80->80/tcp,:::80->80/tcp

意味は、

kaiga ... Up 8000/tcp ← 絵画分類アプリ
wordpress ... php-fpm Up 9000/tcp ← WordPress 本体（PHP)
wordpress-certbot-1 /bin/sh -c echo ready Exit 0 ← 一瞬だけ動く certbot 用（正常終了）
wordpress-db-1 ... mysqld Up 3306/tcp ← MySQL（DB）
wordpress-nginx-1 ... nginx Up :80, :443 ← フロントの Nginx
certbot だけは「終わったら終了するタイプ」なので Exit 0 で正常

＝

操作 コマンド 説明
起動（バックグラウンド実行） docker-compose up -d コンテナをバックグラウンドで起動する
停止 docker-compose down コンテナを停止して削除（永続化データは残る）
再起動 docker-compose restart すべてのサービスを再起動する
状態確認 docker-compose ps 現在のコンテナ一覧と状態を表示
ログ確認 docker-compose logs -f 各コンテナのログをリアルタイムで確認
特定サービスのみ再起動 docker-compose restart nginx nginx だけ再起動などの部分運用が可能
イメージの再ビルド docker-compose up -d --build Dockerfile を変更した時に使用

練習、再起動

 

② logs（ログ確認）でトラブル時の原因をつかむ

項目 コマンド 説明
WordPress（php-fpm）ログ確認 docker logs wordpress WordPress（php-fpm）のエラー内容を確認する
Nginx ログ確認 docker logs nginx アクセスログ・エラーログを確認する
MySQL ログ確認 docker logs mysql MySQL の起動ログ・エラーログを確認する
リアルタイムでログを追う docker logs -f wordpress 500エラー・接続不可など、原因調査に必須

ログの見方

トラブル時にまず見るべきログ

cd ~/wordpress

nginx のログ（アクセス / エラー）

docker-compose logs –tail=20 nginx

WordPress(PHP-FPM) のログ

docker-compose logs –tail=20 wordpress

MySQL(DB) のログ

docker-compose logs –tail=20 db

ポイント：

  • サイトが 500 エラー → nginx と wordpress を見る

  • DB 接続エラー → db（MySQL）のログをチェック

 

WordPress(PHP-FPM) のログ部分

PHP Warning: Constant WP_SITEURL already defined in /var/www/html/wp-config.php on line 143
PHP Warning: Constant WP_HOME already defined in /var/www/html/wp-config.php on line 142
...
"POST /wp-admin/admin-ajax.php" 200
"GET /index.php" 200

なにが起きてるか

WP_HOME と WP_SITEURL という定数が、同じ名前で2回定義されてることへの Warning。しかも毎回 admin-ajax や index.php にアクセスするたびに出てる

よくある原因：wp-config.php の中で、同じ define(‘WP_HOME’, …) / define(‘WP_SITEURL’, …) を2回書いてしまっている

もしくは、プラグインや別ファイルでもう一度定義している

ただしログ見る限り、

“POST /wp-admin/admin-ajax.php” 200
“GET /index.php” 200なので、Warning は出ているけど、レスポンスは 200 でサイトは普通に動いてる状態。

対処方針

/var/www/html/wp-config.php の 142・143 行付近を後でチェックして、

同じ定数を2回書いていないか確認。直すなら下記。：

if (!defined(‘WP_HOME’)) {
define(‘WP_HOME’, ‘https://k-stone.click’);
}
if (!defined(‘WP_SITEURL’)) {
define(‘WP_SITEURL’, ‘https://k-stone.click’);
}

🎯 総合診断

  • nginx：
    → 起動正常、アクセスも200、Warningは一時ファイルへの退避メッセージだけで問題なし

  • WordPress(PHP)：
    → WP_HOME / WP_SITEURL の重複定義 Warning あり
    → 見た目や動作に大きな不具合がなければ、後で wp-config.php を整理すればOK

  • MySQL：
    → 起動正常、致命的なエラー/Warningなし、「ready for connections」状態

③ MySQL の dump（バックアップ）

↓ただしいDB名を確認する。

cd ~/wordpress
docker exec -it wordpress bash -c “grep DB_ /var/www/html/wp-config.php”

ubuntu@ip-172-31-32-242:~/wordpress$ cd ~/wordpress
docker exec -it wordpress bash -c “grep DB_ /var/www/html/wp-config.php”
define( ‘DB_NAME’, getenv_docker(‘WORDPRESS_DB_NAME’, ‘wordpress’) );
define( ‘DB_USER’, getenv_docker(‘WORDPRESS_DB_USER’, ‘example username’) );
define( ‘DB_PASSWORD’, getenv_docker(‘WORDPRESS_DB_PASSWORD’, ‘example password’) );
define( ‘DB_HOST’, getenv_docker(‘WORDPRESS_DB_HOST’, ‘mysql’) );
define( ‘DB_CHARSET’, getenv_docker(‘WORDPRESS_DB_CHARSET’, ‘utf8mb4’) );
define( ‘DB_COLLATE’, getenv_docker(‘WORDPRESS_DB_COLLATE’, ”) );

意味は

本当の値は Docker の環境変数（WORDPRESS_DB_NAME など）から読む

もし環境変数が無ければ、デフォルト値（wordpress, example username…）を使う

という仕組みです。

つまり、本物のユーザー名・パスワードは docker-compose 側の environment: に書いてあるはず。

そこで、docker-compose.yml から DB 情報を確認する。

cd ~/wordpress

docker-compose の中から WORDPRESS_DB_ を探す

grep -n “WORDPRESS_DB_” docker-compose.yml docker-compose.override.yml

✔ --no-tablespaces を付けてダンプ

cd ~/wordpress

BACKUP_NAME=”backup_$(date +%Y%m%d_%H%M%S).sql”

docker exec -i wordpress-db-1 mysqldump \
–no-tablespaces –single-transaction –quick –lock-tables=false \
-u wpuser -p’wppass’ wordpress > “$BACKUP_NAME”

オプションの意味：

  • --no-tablespaces
    → さっき怒られた「テーブルスペース情報」は捨てる（通常の WordPress 運用では問題なし

  • テーブルスペースとは、

    MySQL の内部では、

    • テーブルを保存するファイル

    • インデックスを保存するファイル

    • トランザクションログ

    • 一時データ

    など、いろんなデータが複数に分かれており、これらを まとめて管理する“箱” がテーブルスペース

  • テーブルスペースをすてたけど、一般ユーザーはまず使わない。。
    シチュエーション テーブルスペース必要？
    WordPress のバックアップ（普段） ❌ いらない
    mysqldump（普通の export） ❌ いらない
    サイト移転のための DB エクスポート ❌ いらない
    高度な物理バックアップ ⭕ 必要
    テーブルを高速に別サーバに移す ⭕ 必要
    InnoDB 内部解析や障害調査 ⭕ 必要（DBA案件）

参考までに物理バックアップとは？

巨大サイトや無停止システムのためのもの

種類 特徴 メリット デメリット
論理バックアップ（mysqldump） SQL（テキスト）で保存 どこでも復元可能／安全 遅い／巨大データには不向き
物理バックアップ（高度） データファイルそのものをコピー 超高速／巨大DBに強い／停止時間ゼロ 専門知識が必要／環境が同じでないと壊れる

  • --single-transaction
    → トランザクション中に一気に読む（InnoDB 向け。ロック少なめ）

  • --quick / --lock-tables=false
    → でかいサイトでもメモリ節約＆テーブルロックなしでダンプ

WordPress のバックアップとしては これで十分実用レベル

mysqldump: [Warning] Using a password on the command line interface can be insecure.
とでたが、出ているメッセージは「パスワードをコマンドラインに書くのは危ないかもね」という“お説教系の Warning”だけなので、処理自体は通っており、 毎回出るだけの注意喚起 で、エラーではない。

↓バックアップの確認

cd ~/wordpress
ls -lh backup_*.sql

④0バイト削除する

↓ls -lh

rw-rw-r– 1 ubuntu ubuntu 0 Nov 27 07:40 backup_20251127_074045.sql
-rw-rw-r– 1 ubuntu ubuntu 0 Nov 27 07:54 backup_20251127_075415.sql

↓ファイルの削除

rm backup_20251127_074045.sql

rm backup_20251127_075415.sql

⑤wp-content の容量見る

cd ~/wordpress
du -sh wp_data

ubuntu@ip-172-31-32-242:~/wordpress$ cd ~/wordpress
du -sh wp_data
4.0K wp_data

WordPress の wp-content がほぼ空 という意味

つまり：

  •  WordPress の本体やテーマ・画像などは
    すべて Docker ボリューム（mysql や wordpress など）側で管理されている

  • ~/wordpress/wp_data は ホスト側にマウントされていない（未使用）

  • 以上より、 4KB（ほぼ空）になっている

これで正しいが、

🔍 なぜ wp_data が空なの？

 docker-compose を見るとWordPress の /var/www/html や wp-content は
ホスト側ではなく Docker 内部の volume に保存される構造になってるから。つまり、ファイルの実体はここ👇にある：

docker volume の中

例：

  • wordpress_wp_data

  • wordpress_wp-content

  • wordpress_data
    など（compose の設定による）

🔧 本当の wp-content の容量を確認したいとき

コンテナの中に入って確認👇

docker exec -it wordpress bash
du -sh /var/www/html/wp-content
結果は、153M /var/www/html/wp-content

⑥docker-compose restart の練習

docker-compose restart nginx
docker-compose restart wordpress
docker-compose restart db

ブログ用まとめ作成に進む