低スペックPCでも止まらない！32GB環境でWordPressを安定稼働させる4つの運用設計

こんにちは、てつです！

今回は、前回構築したブログサーバーの運用について書いていこうと思います！

ブログサーバーを構築しても、正しく運用できなければ意味がありません！

動き続ける仕組みを一緒に構築していきましょう！

ストレージ32GBの絶望を突破！ChromebookをDocker＋WordPressサーバーに変える「要塞化」構築術

こんにちは、てつです！今回は、新たにブログの構築をやっていこうと思います！このブログはAWS上のサーバで運用しているのですが、せっかく自宅にサーバー環境を作ったのでこの環境で別のブログを立ち上げてみようと思います！関連記事＃記事のポイント＃…

【はじめに】これだけは知っておきたい用語とツール
「建てる」のはスタート、「守る」のが本番
資産を守るための「整理整頓」：ディレクトリ構造
監視とメンテナンスツールの導入、通知設定
1. 構築中に直面したエラーとその突破法
運用の「二段構え」：検証とゼロデイ対応
定期再起動による「リフレッシュ」
セキュリティの現場経験者としてのアドバイス
まとめ

【はじめに】これだけは知っておきたい用語とツール

今回の記事における前提の知識となる用語とツールの解説文となります。ご参考になれば幸いです。

Docker（ドッカー）: パソコンの中に作る「仮想の小部屋」です。ブログをこの小部屋に入れることで、他の場所に影響を与えず安全に管理できます。
脆弱性（ぜいじゃくせい）: システムに見つかった「セキュリティ上の弱点」です。これを放置すると、悪い人にブログを乗っ取られるリスクがあります。
ゼロデイ（Zero-day）: 弱点が見つかってから、修正プログラム（パッチ）が出るまでの「無防備な期間」を指します。
Uptime Kuma: ブログが「今、動いているか」を監視し、グラフで見せてくれるツールです。
Watchtower: ブログの更新データ（パッチ）が出たことを自動で見張り、教えてくれるツールです。

「建てる」のはスタート、「守る」のが本番

せっかく構築した自宅サーバーも、放置してしまえば脆弱性の温床となり、いつかは物理的な限界（ストレージ不足やメモリリーク）で沈黙します。

今回の記事では、32GBという極限の環境で「手放しでも安全に稼働し続ける資産」に変えるための、具体的な運用設計を解説します。

今回やること：4つのレイヤーによる「要塞化」

いきなりツールを入れるのではなく、以下の論理的な手順で運用基盤を整えます。

物理層の保護: 書き込み回数に上限がある「SDカード」の寿命を延ばす設計。
監視の導入: 24時間365日、ブログが生きているかを確認する「目」を作る。
情報の自動収集: セキュリティパッチ（修正プログラム）の配布をスマホで検知する仕組み。
自動メンテナンス: 週に一度、データの整合性を守りながらシステムをリフレッシュする統合バッチの作成。

そもそも「運用（Operation）」とは何か？

IT業界における「運用」とは、単にシステムを動かし続けることではありません。プロの視点では、運用を以下のように定義します。

運用の定義：システムの「衛生管理」と「不確実性への準備」である

衛生管理: 人間が健康診断を受けるように、サーバーもメモリのゴミを掃除し、最新のワクチン（パッチ）を打つ必要があります。
不確実性への準備: 「いつか壊れる」「いつか攻撃される」という前提に立ち、その被害を最小限に抑えるためのバックアップや検証環境を整えておくことです。

多くの技術ブログが「作り方」で終わる中、この記事では「ビジネスを止めないためのプロの思考法」を自宅環境に落とし込んでいきます。

資産を守るための「整理整頓」：ディレクトリ構造

データがバラバラだと、トラブル時に復旧できません。今回は内蔵ストレージ（32GB）を守るため、すべての設定をSDカード側に集約します。

以下の表が今回使うディレクトリ構成となります。

同じような階層構造にすることをお勧めしますが、sdcardの部分に限っては私がサーバーとして稼働させているPCのストレージに起因するものなので個人のプロジェクトの配下にフォルダをつくればいいと思います。

フォルダ・ファイル名	役割
`/mnt/sdcard/＜プロジェクト名＞/`	ベースキャンプ: すべてのファイルをここに置きます。
`├── docker-compose.yml`	ブログの設計図: WordPress本体とDBの構成案です。
`├── maintenance.yml`	監視の設計図: 監視・通知ツールの構成案です。
`├── scripts/`	道具箱: 定期再起動などの自動命令書（スクリプト）を入れます。
`└── db/ , html/`	倉庫: ブログの実データや画像が保存されます。

自前ブログサーバーのメリットと注意点

なぜ、便利なクラウドサービス（AWSなど）を使わず、あえて自宅のパソコンをサーバーにするのでしょうか？

項目	メリット	注意点（リスク）
コスト	月々の固定費が実質「電気代のみ」になり大幅な節約になる	停電や物理的な故障リスクは自分で背負う必要がある
スキル	LinuxやDockerの深い運用知識が身につき、自身の「実績・資産」になる	セキュリティ対策やパッチ適用の責任は100%自分にある
データ	自分のデータが物理的にどこにあるかを完全にコントロールできる	SDカードなどを利用する場合、書き込み回数による寿命に注意が必要

監視とメンテナンスツールの導入、通知設定

低スペック環境でも重くならないよう、監視（Uptime Kuma）と通知（Watchtower）の基盤を構築します。

また、「Watchtower」と「Discord（またはSlack）」を連携させ、パッチ配布をスマホで即座に検知させます。

Bash
# 監視用とメンテナンス用のツールをまとめた設定を作成します
code maintenance.yml

YAML
# 監視用と通知用の設定ファイル（maintenance.yml）を作成します
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    restart: always
    ports:
      - "3001:3001"
    volumes:
      - /mnt/sdcard/<プロジェクト名>/kuma:/app/data
    deploy:
      resources:
        limits:
          memory: 128M # 監視ツール自身のメモリ消費を最小限に抑えます

watchtower:
  image: containrrr/watchtower
  volumes: 
   - /run/docker.sock:/var/run/docker.sock
  environment:
    # 通知を有効にします
    - WATCHTOWER_NOTIFICATIONS=shoutrrr
    # あなたのスマホに届けるための「住所（Webhook）」を設定します
    - WATCHTOWER_NOTIFICATION_URL=discord://token@channel_id 
　　- DOCKER_API_VERSION=1.40
  command: --monitor-only --interval 86400

ここまで書けたら、下記コマンドを実行し立ち上げてみましょう。

Bash
# 監視・通知コンテナを起動します
docker compose -f maintenance.yml up -d

# ログを確認し、WatchtowerがSlackへ接続できているかチェックします
docker compose -f maintenance.yml logs -f watchtower

構築中に直面したエラーとその突破法

設計図（YAML）を書き、コマンドを打つ。その過程で必ずと言っていいほど直面する「壁」があります。ここでは、プロの現場でも頻発する4つのエラーとその対処法を整理します。

1. YAMLの文法エラー（インデントとタイポ）

症状：additional properties not allowed や mapping values are not allowed in this context と表示される。

ロジック（処理の手順）:
1. エラーメッセージに表示された「行番号」を特定する。
2. 最上段が複数形の services: になっているか確認する。
3. 各コンテナの設定が、親要素から半角スペース2つ分右にズレているか（インデント）を確認する。
解決策: Docker Composeは「字下げ」で親子関係を判断します。すべての設定項目が正しい階層に並んでいるか、定規で測るように縦のラインを揃えるのが鉄則です。

2. Dockerデーモンへの接続拒否（心臓部へのアクセス権）

症状：Cannot connect to the Docker daemon というエラーが出る。

ロジック（処理の手順）:
1. コンテナ（Watchtower）が「外の世界」を監視するための窓口（docker.sock）を探す。
2. その窓口がホスト側のどこにあるか（/var/run/docker.sock 等）を特定する。
3. コンテナの中にその窓口を「共有（マウント）」する設定を加える。
解決策: コンテナは本来、隔離された小部屋です。他のコンテナを見張るには、ホストOSの「心臓部」へアクセスする特別な許可（Volumes設定）が必要です。

3. パーミッション（権限）の壁

症状：パスは合っているのに「アクセス権がない」と弾かれる。

ロジック（処理の手順）:
1. 現在の操作ユーザー（一般ユーザー）が、Dockerを触る権限を持っているか確認する。
2. 管理者権限（sudo）を使って、ユーザーを docker グループに所属させる。
3. グループ変更をシステムに即座に認識させる（newgrp）。
解決策: セキュリティリーダーの視点では、誰でもシステムを操作できる状態は危険です。特定の信頼されたユーザー（自分）にだけ「鍵（グループ権限）」を渡す処置を施します。

4. APIバージョンの不一致

症状：client version 1.25 is too old. Minimum supported API version is 1.40 と出る。

ロジック（処理の手順）:
1. 道具（Watchtower）が話す「古い方言」と、本体（Dockerエンジン）が話す「新しい言葉」のズレを認識する。
2. 環境変数 DOCKER_API_VERSION を使い、道具側に「新しい言葉で話しなさい」と命令を出す。
解決策: 最新のツールを安定したOS環境（MX Linux等）で動かす際、共通言語のバージョンが合わないことがあります。環境変数で明示的に指定することで、新旧のギャップを埋めることができます。

運用の「二段構え」：検証とゼロデイ対応

アップデートが来たら「自動で全て適用する」のは一見便利ですが、現場では推奨されません。

理由としては、パッチの影響でサイトが真っ白になる（壊れる）リスクがあるからです。安全を担保するため、以下の「2つのレーン」を使い分けます。

通常レーン（Stable Track）:
- 通知: Watchtowerで新バージョンの案内を受け取る。
- 検証: 本番とは別の「テスト環境」に適用し、1週間稼働させる。
- 適用: Uptime Kumaで異常がないことを確認後、本番へ適用。
特急レーン（Fast Track / ゼロデイ対応）:
- 判断: ニュースなどで極めて危険な脆弱性（ゼロデイなど）が発表された場合。
- 即時適用: 1週間のテストを省略し、データをバックアップした直後に即時適用してサイトへの攻撃を防ぐ。

定期再起動による「リフレッシュ」

サーバーを24時間365日動かし続けると、不要なデータが蓄積し（メモリリーク）、最終的にシステムがフリーズするリスクが高まります。

また、データベース稼働中のバックアップはデータ破損の恐れがあるため、慎重な手順が求められます。

そこで、「システムの停止」→「安全な圧縮バックアップ」→「リフレッシュ起動」の一連の流れを、わずか1分で全自動遂行する仕組みを構築します。

ダウンタイム1分。「統合バッチ」と「Cron」による手放し運用の完成

再起動バッチの処理ロジック（手順）

いきなり再起動するのではなく、以下の5つのステップを自動で踏むように設計しています。

ディレクトリ移動: プロジェクトのルート（SDカード側）へ移動します。
安全な停止: docker compose down でコンテナを一度止めます。これにより、データベースへの書き込みを安全に停止し、メモリをリフレッシュする準備を整えます。
圧縮バックアップ: 止まっているわずかな時間に、現在のデータを固めて本体ストレージへ退避させます。
クリーン起動: docker compose up -d で、真っさらな状態でシステムを再起動します。
世代管理と記録: 古いバックアップを消して容量を確保し、結果をログに記します。

まずは、作ってなかったら/scripts/のファルダを作り、maintenance.shファイルを作り編集画面を開きましょう。

下記コマンドを順次実行してください。

mkdir -p /mnt/sdcard/tech-shortcut-lab/scripts

nano /mnt/sdcard/tech-shortcut-lab/scripts/maintenance.sh

ここまで実行出来たら、コードエディタが開かれてると思います。その中に下記のスクリプトを入れましょう。

# メンテナンス用のスクリプトファイルを作成します
# 保存先: /mnt/sdcard/<プロジェクト名>/scripts/maintenance.sh

#!/bin/bash

# --- 1. 設定セクション ---
SOURCE_DIR="/mnt/sdcard/<プロジェクト名>"               # ブログデータの大元です
BACKUP_DIR="/home/$USER/backups"                         # バックアップ保存先（本体側）です
TIMESTAMP=$(date +%Y%m%d_%H%M%S)                         # 日時スタンプを作成します
RETENTION_DAYS=7                                         # 過去7日分のデータを残します
LOG_FILE="$SOURCE_DIR/scripts/maintenance.log"           # 処理結果を記録するログです

# --- 2. 実行セクション ---
mkdir -p $BACKUP_DIR                                     # 保存フォルダがなければ作成します

# 安全な停止（メモリのリフレッシュ 兼 バックアップ準備）
cd $SOURCE_DIR && docker compose down                    # システムを一時停止します

# データの整合性を保った状態での圧縮保存
tar -czf $BACKUP_DIR/backup_$TIMESTAMP.tar.gz .          # 全データを高圧縮して保存先へ送ります

# クリーンな状態での再起動
docker compose up -d                                     # 速やかにブログをオンラインに戻します

# 容量確保のための世代管理
find $BACKUP_DIR -type f -mtime +$RETENTION_DAYS -delete # 7日以上前の古いデータを削除します

# 実行結果の記録
echo "[$(date)] Maintenance Success: backup_$TIMESTAMP.tar.gz & System Rebooted" >> $LOG_FILE

スクリプトファイルの編集が終わったら、Ctrl+O（保存）、Ctrl+X(閉じる)で抜けましょう。

下記コマンドを実行し手動でスクリプトの実行ができるが確認します。

# 1. スクリプトに「実行する権限」を与えます
chmod +x /mnt/sdcard/<プロジェクト名>/scripts/maintenance.sh

# 2. スクリプトを実行します。
sudo /mnt/sdcard/<プロジェクト名>/scripts/maintenance.sh

ここまでエラーなく実行出来たらBackupファイルが出力されているはずなので確認しましょう。

ls -lh /home/$USER/backups

問題なく出力されていたら、完全に自動実行するステップへ移りましょう。

Cronによる「完全自動実行」の設定

作成したスクリプトを、アクセスの最も少ない「毎週日曜日の深夜3時」に自動実行されるよう設定します。

Bash

# 1. 自動実行のスケジュール帳（cron）を開きます
sudo crontab -e

# 2. ファイルの一番下に以下の1行を追記して保存します（毎週日曜の深夜3時に実行）
0 3 * * 0 /mnt/sdcard/<プロジェクト名>/scripts/maintenance.sh

【解説】

0 3 * * 0 は、左から「分・時・日・月・曜日」を指定しています。

末尾の 0 は日曜日を指し、毎週日曜日の午前3時にメンテナンスが自動遂行されます。

運用開始後の確認

設定が正しいことを「確信」に変えるために、来週の月曜日の朝に以下の3点を確認してください。

ログファイルの確認: cat /mnt/sdcard/＜プロジェクト名＞/scripts/maintenance.log を実行し、日曜日の日付で「Success」の文字があるか見ます。
バックアップファイルの存在確認: ls -lh /home/$USER$/backups で、新しい日付の .tar.gz ファイルが増えているか確認します。
Discord,Slack通知のチェック: Watchtowerから「監視を再開した」旨の通知が届いているかスマホで確認します。