復習7日目_20251129

IT

🎉 Day7：最終調整（UI & セキュリティ総点検）
🌈 今日のゴール

  • サイト全体の見た目を整える
  • セキュリティ設定を再点検して、安全に運用できる状態にする
  • AIアプリ / WordPress の最終統合チェック

具体的には、

  1. WordPress UI 最終調整

  2. 絵画分類アプリ（/kaiga/）の最終確認

  3. Nginx のセキュリティヘッダ確認

  4. AWS セキュリティグループの最終点検

  5. Docker ボリュームとバックアップ

 

これらと、ゴールの対応関係は？

ゴール 対応する具体作業 説明
サイト全体の見た目を整える 1. WordPress UI 最終調整 文字サイズ、余白、見出しデザイン、全体レイアウトを整え、読みやすいデザインに仕上げる
2. 絵画分類アプリ（/kaiga/）の最終確認 アップロード画面や結果表示の見た目・スマホ表示を確認し、統一感を出す
セキュリティ設定を再点検して、安全に運用できる状態にする 3. Nginx のセキュリティヘッダ確認 HTTPS強制、HSTS、X-Frame-Optionsなどの基本ヘッダでWeb脆弱性を最小化
4. AWS セキュリティグループの最終点検 不要ポート閉鎖、SSHアクセス制限、IPv6チェックなど外部からの攻撃リスクを削減
AIアプリ / WordPress の最終統合チェック 2. 絵画分類アプリ（/kaiga/）の最終確認 WordPress → /kaiga/ の動線、Google認証後の遷移確認
5. Docker ボリュームとバックアップ WPデータ・DBデータの保全、バックアップルール確立で長期運用に備える

 

さあ、作業に入ります。

1. WordPress UI 最終調整

①トップページの記事一覧の画像が小さすぎる → 中サイズに

方法

【手順①】管理画面にログイン

【手順②】左メニューの「外観」をクリック

項目の中から 「カスタマイズ」 を選ぶ。

【手順③】カスタマイズ画面で追加CSSを選ぶ

【手順④】そこでCSSのコードを貼るだけ！

感想、簡単だが、アイキャッチ画像の場合、クラス名が違うために、変わらないケースであった。

そこで、どのクラスが使われていてもヒットする ようにした。

.blog img.attachment-post-thumbnail,
.archive img.attachment-post-thumbnail,
.blog img.wp-post-image,
.archive img.wp-post-image,
.blog .entry-thumbnail img,
.archive .entry-thumbnail img {
display: block !important;
margin-left: auto !important;
margin-right: auto !important;
}

さらに具体的にやったこと、

  1. display: block にする

画像は本来は inline なので中央寄せできないが、block + margin-left/right: auto で中央に位置できる要素になります。

  1. margin-left: auto
  2. margin-right: auto

この「auto」が左右の余白を均等にする → 結果として中央になる。

  1. !important

テーマ側のCSS（強い指定）に負けないようにしている。

変わったので成功だ！

2. 絵画分類アプリ（/kaiga/）の最終確認

見てくれの改善の余地はあるが、動作確認をすすめる。

よし、動いた！！！

異なるファイル形式では識別されない。

もっとテストするケースがあるのでテストケースを洗い出すことが重要だ。

 

3. Nginx のセキュリティヘッダ確認

① Nginx コンテナに入る

docker ps

でコンテナを探してから、入った。

docker exec -it wordpress-nginx-1 /bin/sh

② 設定ファイルの場所を確認

ls /etc/nginx/conf.d

どのファイルが k-stone.click を担当しているか確認する。

コンテナ内で：

grep -n 'server_name' /etc/nginx/conf.d/*.conf

# cat /etc/nginx/conf.d/wp-https.conf
server {
listen 443 ssl;
http2 on;
server_name k-stone.click www.k-stone.click;

ssl_certificate /etc/letsencrypt/live/k-stone.click/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/k-stone.click/privkey.pem;

# === Security Headers ===
add_header X-Content-Type-Options “nosniff”;
add_header X-Frame-Options “SAMEORIGIN”;
add_header Referrer-Policy “strict-origin-when-cross-origin”;
add_header Permissions-Policy “camera=(), microphone=(), geolocation=()”;
add_header Strict-Transport-Security “max-age=31536000; includeSubDomains” always;

# — ACME on HTTPS (renew follows redirects) —
location ^~ /.well-known/acme-challenge/ {
root /var/www/certbot;
default_type “text/plain”;
try_files $uri =404;
}

root /var/www/html;
index index.php index.html;

# Flask /kaiga/ reverse proxy
location /kaiga/ {
proxy_pass http://kaiga:8000/;
proxy_http_version 1.1;

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}

location / {
try_files $uri $uri/ /index.php?$args;

}

location ~ \.php$ {
try_files $uri =404;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param HTTP_X_FORWARDED_PROTO $scheme;
fastcgi_pass wordpress:9000;
}

}

すでに入っているのは：

  • ✅ X-Content-Type-Options

  • ✅ X-Frame-Options

  • ✅ Referrer-Policy

  • ✅ Permissions-Policy

  • ✅ HSTS（Strict-Transport-Security）

2️⃣ ちょい足し＆微修正するとベストとのことより
(1) X-XSS-Protection を追加

古いブラウザ向けだけど、一応入れておくとよく見る定番セットになる。

add_header X-XSS-Protection “1; mode=block”;

(2) always を付けておくと安心

add_header は「デフォルトだと 200レスポンス以外で付かない」ことがあるので、全部に always を付けておくのがすすめられるとのこと。

そこで、修正版のブロックを以下にした。
# === Security Headers ===
add_header X-Content-Type-Options “nosniff” always;
add_header X-Frame-Options “SAMEORIGIN” always;
add_header Referrer-Policy “strict-origin-when-cross-origin” always;
add_header Permissions-Policy “camera=(), microphone=(), geolocation=()” always;
add_header X-XSS-Protection “1; mode=block” always;
add_header Strict-Transport-Security “max-age=31536000; includeSubDomains” always;

そして、

nginx -t → nginx -s reload を実行した。

Nginx セキュリティヘッダも入った！！！。

4. AWS セキュリティグループの最終点検

AWS コンソールから：EC2 → 対象インスタンス → セキュリティ → セキュリティグループ
をクリックして確認した。

✔️ 1. インバウンドルール
① HTTP(80) と HTTPS(443) だけ全世界から許可

② SSH(22) は“自分のIPアドレスだけ”に制限

③ それ以外のポートが開いていたら削除

✔️ 2. アウトバウンドルール
デフォルトの「すべて許可」のままでOK

WordPress・yum・apt・Let’s Encrypt 更新すべて必要だから、
特殊な理由がなければ制限しない。

なぜ？

Webサーバ（EC2）は、“外向きの通信” が必要不可欠だから、アウトバウンドを締めすぎると動かなくなる

つまり：WordPress を運用、nginx を運用、Certbot(SSL更新)、apt/yum 更新、Docker イメージを pull するなど、ぜんぶ EC2 から外部へアクセスする機能に依存しているためである。

👉 アウトバウンド通信を制限するとサイトが動かなくなる危険がある

では、アウトバウンドを制限するのは、どういうとき？

サーバの種類 アウトバウンド制限すべき？ 理由
公共のWebサーバ（WordPress等） ❌ しない 証明書更新・パッチ更新が必要
内部アプリケーションサーバ ✔ 制限する 外部通信の必要なし
DBサーバ ✔ 制限する 外部通信不要、漏えい防止
基幹系（人事、会計） ✔ 制限する 情報漏えい防止
PCI DSS環境 ✔ 必須 ルールで義務
医療・金融・官公庁（閉域） ✔ 必須 組織ポリシー

5. Docker ボリュームとバックアップ

1. ボリュームの確認（必須）

cd ~/wordpress
docker compose ps
docker volume ls

Docker サービス一覧（稼働コンテナ）

サービス名 コンテナ名 役割 ポート バックアップ必要？
kaiga kaiga 絵画分類アプリ（Flask） 8000/tcp 任意（必要なら app.py, model など手動）
wordpress wordpress WordPress PHP-FPM 9000/tcp ファイルは wp_data ボリュームで管理
db wordpress-db-1 MySQL 5.7（WordPress DB） 3306/tcp 必須：DBバックアップが最重要
nginx wordpress-nginx-1 Webサーバ（HTTP/HTTPS） 80/443 設定のバックアップは任意

Docker ボリューム一覧とバックアップ必要性

ボ

 

 

 

リューム名

 役割 バックアップ必要性 理由
wordpress_db_data MySQL の全データ（WordPress の本体データ） ◎ 必須（最重要） 投稿・固定ページ・ユーザ等すべてのDBデータ
wordpress_wp_data WordPress の HTML・テーマ・プラグイン・画像・wp-config.php ◎ 必須 WordPress ファイル全てが入っている
wordpress_certbot-etc certbot 設定 ✖ 不要 certbot は再生成可能
wordpress_certbot-www ACME challenge 用ファイル ✖ 不要 毎回使い捨ての領域
297d9c8… Nginx または kaiga の作業キャッシュ（用途不明） ✖ 不要 永続データでない（名前からして匿名ボリューム）
ef5c9c… 同上（匿名ボリューム） ✖ 不要 ※データ保持目的では使われていない可能性が高い

↓バックアップ用フォルダを作る（1回だけでOK）

mkdir -p ~/wp_backups

↓DBバックアップスクリプト

nano ~/backup_db.sh

内容：

#!/bin/bash
set -e

DATE=$(date +”%Y%m%d_%H%M%S”)
BACKUP_DIR=”$HOME/wp_backups”
mkdir -p “$BACKUP_DIR”

DB_CONTAINER=”wordpress-db-1″
DB_NAME=”wordpress” # MYSQL_DATABASE
DB_USER=”wpuser” # MYSQL_USER
DB_PASSWORD=”wppass” # MYSQL_PASSWORD

docker exec “$DB_CONTAINER” \
mysqldump -u”$DB_USER” -p”$DB_PASSWORD” “$DB_NAME” \
> “$BACKUP_DIR/db_${DATE}.sql”

echo “[OK] DB backup saved: $BACKUP_DIR/db_${DATE}.sql”

↓権限付与

chmod +x ~/backup_db.sh

↓試しに実行：

↓実行手順
ホームへ移動する
cd ~

ファイルがあるか確認
ls -l backup_db.sh

↓実行する
./backup_db.sh

./backup_db.sh↓成功したら

✅ DBバックアップは成功

WPファイルのバックアップも作る。

↓スクリプトをつくる。

nano ~/backup_wp_files.sh

↓中身は？

#!/bin/bash
set -e

DATE=$(date +”%Y%m%d_%H%M%S”)
BACKUP_DIR=”$HOME/wp_backups/wp_${DATE}”
mkdir -p “$BACKUP_DIR”

docker cp wordpress-nginx-1:/var/www/html “$BACKUP_DIR”

echo “[OK] WP files saved: $BACKUP_DIR”

↓以下のコマンドをうつ。

chmod +x ~/backup_wp_files.sh
./backup_wp_files.sh
ls -lh ~/wp_backups

できた!!!

これで「EC2 が壊れても復旧できる状態」になった。

DB復元OK

ファイル復元OK

Docker構成は残る、conf.d（nginx）もバックアップしておけば完璧

以下は復元の手順と手順書

EC2 障害時の復旧ガイド（あなたの環境専用）

このドキュメントは、WordPress（Nginx + PHP-FPM）・MySQL・Flask（/kaiga）を Docker で運用しているあなたの EC2 が、万が一障害で停止・破損した場合に 確実に復旧できる状態 をまとめたものです。

✔️ 復旧に必要なバックアップ

1. MySQL データ（最重要）

  • バックアップファイル例：db_YYYYMMDD_HHMMSS.sql
  • 内容：WordPress の 投稿・固定ページ・メディア情報・ユーザ情報・設定 など、全データベース内容。
  • 保存場所：~/wp_backups/
  • 取得コマンド：./backup_db.sh

2. WordPress ファイル一式

  • ディレクトリ例：wp_YYYYMMDD_HHMMSS/
  • 内容：
    • wp-content（画像・テーマ・プラグイン）
    • wp-config.php
    • WordPress コアファイル
  • 取得コマンド：./backup_wp_files.sh

3. Docker 構成（docker-compose）

  • あなたの EC2 の /home/ubuntu/wordpress/ に保持
  • GitHub 等にコピーしておけばさらに安全
  • これが残っていれば 同じコンテナ構成を再構築可能

4. Nginx 設定（/etc/nginx/conf.d/）

  • セキュリティヘッダなど、あなたが手動で修正した部分を含む
  • バックアップ推奨
    • docker cp wordpress-nginx-1:/etc/nginx/conf.d ~/wp_backups/nginx_conf_YYYYMMDD

✔️ 障害発生後の復旧手順

Step 1：新しい EC2 を起動する

  • OS：Ubuntu（元と同じ）
  • 既存の Elastic IP を割り当てる（推奨）

Step 2：Docker / docker-compose をインストール

sudo apt update
sudo apt install docker.io docker-compose -y

Step 3：wordpress ディレクトリを復元

  • GitHub またはバックアップから docker-compose.yml を設置
  • /home/ubuntu/wordpress/ に配置

Step 4：Docker を再構築

cd ~/wordpress
docker compose up -d

Step 5：MySQL データベースをリストア

cat ~/wp_backups/db_YYYYMMDD.sql | docker exec -i wordpress-db-1 mysql -u<DB_USER> -p<DB_PASSWORD> <DB_NAME>

Step 6：WordPress ファイルをリストア

docker cp ~/wp_backups/wp_YYYYMMDD/html wordpress-nginx-1:/var/www/

Step 7：Nginx 設定をリストア（必要な場合）

docker cp ~/wp_backups/nginx_conf_YYYYMMDD/conf.d wordpress-nginx-1:/etc/nginx/
docker exec wordpress-nginx-1 nginx -s reload

✔️ 最終チェック

  • WordPress が表示されるか
  • /kaiga/ が動作するか
  • 管理画面（/wp-admin）がログインできるか
  • 記事・画像が正しく読み込まれるか

これらがすべて問題なく動けば、EC2 障害からの完全復旧が完了です。

✔️ このドキュメントの目的

  • EC2 が破損または削除されても 5〜10分以内に復旧できる状態 を作る
  • Docker 構成（コンテナ）は再構築できる
  • データ（DB + ファイル）があれば、完全に元通りになる

今後の方針は以下

目的 内容 チェック項目 使用コマンド / 作業
① コスト分析しながら運用する（最適化） AWSの月額コストを適正化しつつ監視 – EC2 の時間課金- EBSの容量- データ転送費- Route53（¥150/月）- SSL更新（無料）- CloudWatch 異常検知（CPU/ディスク） – AWS Cost Explorer- CloudWatch アラーム設定- 料金試算（必要なら作成）
② 運用ログを取る（健全性確認） システム負荷・動作・攻撃をチェックして健全性を保つ 1. Nginx ログアクセス傾向 / 攻撃パターン2. Dockerログ個別コンテナの状態3. ディスク容量監視 Nginx/var/log/nginx/access.log/var/log/nginx/error.log（必要なら fail2ban）Dockerdocker logs wordpressdocker logs wordpress-nginx-1docker logs wordpress-db-1Diskdf -hdocker system df
③ 2ヶ月後：別サーバへ移行（ゼロダウン計画） コンテナごと別サーバに移動 – 新サーバを準備（Ubuntu 20.04/22.04）- Dockerインストール- docker-compose.ymlコピー- DB復元- WPファイル復元- DNS切替（TTL=300） 移行手順1. 新EC2準備2. 構成ファイルコピー3. docker compose up -d4. `cat db.sql
次の選択肢（あなたの次のアクション） 方向性を決めて進める – コスト監視ダッシュボード作成- 週次運用チェック表の作成- 移行計画書の作成- Day8へ進む A. コスト分析ダッシュボードB. 運用チェックシートC. 移行計画書D. Day8（使い方の戦略）