カテゴリー: インフラ

技術が生まれては消えていく、諸行無常のITの世界において、本質を記すための「場所」を構築してきた。

node01（公開基盤）の構築から始まり、バックアップ戦略と外部監視の完備。これらを経て、IT-MUJOは単なるログの集積体から、一つの完結した「システム」へと昇華した。

本稿では、場所や環境に縛られない運用を支えている、執筆・公開環境の全容を総括する。

---

1. 現場を支える最小限の装備

特定のオフィスを持たず、あらゆる場所を執筆の現場とするために、私が手元に置いている装備は極めて限定的だ。

ASUS Chromebook C523NA

余計な装飾を排し、検証と記録に没頭するための母艦。ChromeOSを消し去り、SeaBIOSを経由してDebian 13をクリーンインストールした実録は第2記事に記している。また、標準の極致たるホスト名を与え、最小構成を選定したプロセスは第3記事の通りである。さらに、Chromebook特有のキーボード配列という制約に対し、Wayland環境下でkeydを用いてキーマップを最適化したログは第4記事に詳述している。Debian 13を核としたこの機体こそが、IT-MUJOの起点である。第1記事から今日に至るまで、すべてのログはこのキーボードから紡がれた。

Google Pixel 8a（USBテザリング）

不特定の公衆Wi-Fiに依存せず、自立した通信路を確保するための選択。第7記事で検証したVPN運用の基盤でもあり、ネットワークエンジニアとして通信の主権を握るための要（かなめ）だ。

Transcend JetFlash 710

第2記事においてDebianのインストールを完遂させた原点。現在は、緊急時のブートメディアとして常に携行している。極小の金属ボディに、環境再構築の可能性を封じ込めている。

これらに加え、拠点における物理バックアップを担う Samsung T7 や、インフラの源泉たる Anker Nano II 65W。これらはこれまでの検証を経て、IT-MUJOを支える「標準装備」として定義済みだ。

---

2. node01を支える三層の守り

公開基盤である node01（Vultr / Docker Compose）は、以下の三層によってその静寂を守られている。

1. 要塞化（NordVPN / Cloudflare WAF）:
   第7記事で構築したNordVPNによる暗号化に加え、第5記事で設定したCloudflareのファイアウォール機能であるWAF（Web Application Firewall）を活用したアクセス制限を適用。管理者以外の侵入を拒絶し、公開基盤の静寂を保っている。
2. データのポータビリティ（Docker Backup）:
   第8記事で実装した自動スクリプトにより、論理データは毎日アーカイブされ、物理メディアへの退避準備が整っている。拠点にある Samsung T7 への同期までを含めた、三重の備えだ。
3. 生存の観測（Uptime Kuma）:
   第9記事で導入した監視塔。異常を察知すれば、即座にDiscordへと通知が届く。主観的な「稼働しているはず」を排し、客観的なデータでサイトの生存を観測し続けている。

---

3. 結び：記録を積み重ねるということ

環境の構築は目的ではない。それは、技術の激しい流れの中に身を置きながら、ふと浮かび上がってきた「本質」を逃さず書き留めるための準備に過ぎない。

システムは完成した。あとは、実直に記録を積み重ねるだけだ。

---

執筆環境: host (Chromebook / Debian 13)
公開基盤: node01 (Vultr / Debian 13 / Docker)
接続環境: NordVPN (NordLynx)

「動いているはず」という運営者の主観は、技術の世界では無力だ。サーバーが起動していても、Nginxがハングアップしているかもしれない。SSL証明書が期限切れを起こしているかもしれない。

無常なインターネットの海において、node01の生存を客観的に証明するためには、外部からの継続的な観測が必要だ。本稿では、自前で構築できる監視ツール「Uptime Kuma」の導入と、その通信の保護について記す。

---

1. 外部監視の必要性とセキュリティの担保

node01の内部でプロセスを監視するだけでは、Cloudflareのプロキシ設定や証明書の不備を検知できない。ユーザーと同じ「外側」のネットワークから定期的にリクエストを送り続けることで、初めてサイトの生存が証明される。

監視環境の構築にあたっては、node01とは別のインスタンスが理想だが、まずはnode01上で独立したコンテナとして稼働させる手順を記す。

また、Uptime Kumaの管理画面にはログイン情報や通知トークンが含まれる。これらを平文のHTTPで流すのは、実直な運用とは言えない。既存のNginxをリバースプロキシとして機能させ、Cloudflare Origin CA証明書を用いたHTTPS環境下で運用する。

---

2. DockerとNginxによるリバースプロキシ

既存の docker-compose.yml に Uptime Kuma を追加し、Nginx経由でサブドメイン（monitor.it-mujo.com）を割り当てる。

docker-compose.yml への追記

  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: always
    volumes:
      - ./uptime-kuma:/app/data
    # 外部にポートは晒さず、Nginx経由でのみアクセスを許可する

Nginx リバースプロキシ設定

サブドメイン用の設定ファイル（monitor.conf）を作成。WebSocket通信（Upgradeヘッダ）を許可し、リアルタイムな監視状況の反映を確保する。

---

3. 監視設定と通知の自動化

HTTPS化された管理画面にアクセスし、監視対象と通知先を設定する。

• HTTP(S)ステータス: https://it-mujo.com を定期的に監視。
• SSL証明書の有効期限: 期限切れを事前に察知し、警告を発する。
• 通知連携: DiscordのWebhook APIを使用。異常を察知した瞬間、host（Chromebook）へ即座に通知が届く体制を整える。

もし特定のメッセージサービスに依存したくない場合は、Cloudflare Email Routingを活用したEmail通知も一つの選択肢となるだろう。

こうした監視設定のバックアップ（JSON）には、機密情報が含まれる。取り扱いには細心の注意を払う。こうした微細な配慮の積み重ねこそが、実直なサーバー運用を形作る。

---

結び

監視を始めると、自分のサイトがいかに多くの「波」に晒されているかが可視化される。
安定稼働を支えるのは、高度な技術だけではない。日々の微かな変化に気づき、静かに対応し続ける実直さである。

---

執筆環境: host (Chromebook / Debian 13)
公開基盤: node01 (Vultr / Debian 13 / Docker)
接続環境: NordVPN (NordLynx)

技術が生まれては消えていく「諸行無常」のITにおいて、唯一の資産は積み上げた「記録」である。
Vultrが提供するスナップショット機能は強力だが、それはプラットフォームという外部要素への依存を意味する。
万が一、クラウド事業者のリージョン障害やアカウント閉鎖が起きた際、手元に「本質的なデータ」が残っていなければ、その記録は霧散する。

本稿では、node01上のDocker Compose環境におけるバックアップ戦略と、物理メディアへの退避手順について記す。

---

1. バックアップ対象の特定

現在のLEMPスタックにおいて、バックアップすべき対象は以下の3点に集約される。

1. MariaDBデータ（論理ダンプ）: バインドマウントされたバイナリデータ（./mariadb）を直接コピーするのは整合性のリスクがあるため、mariadb-dumpによる論理バックアップを行う。
2. WordPressコンテンツ: アップロードした画像やテーマファイル（./wordpress）。
3. 設定ファイル一式: 再構築の設計図である docker-compose.yml および、証明書等を含む nginx ディレクトリ全体。

これらをhost（Chromebook）を介し、最終的に外部ストレージへと物理的に退避させる。

---

2. バックアップスクリプトの実装

手作業によるバックアップは継続性を欠く。シェルスクリプトとcronによる自動化を実装する。

スクリプトの作成

/home/user/scripts/it-mujo-backup.sh として以下を作成。

#!/bin/bash
# IT-MUJO Backup Script

BACKUP_DIR="/home/user/backups/daily"
DATE=$(date +%Y%m%d)
FILE_DATE=$(date +%Y%m%d)
WP_STACK_DIR="/home/user/it-mujo"

echo "--- Backup Start: $DATE ---"

# ディレクトリ準備
mkdir -p $BACKUP_DIR

# 1. データベースの論理バックアップ
sudo docker exec mujo-db mariadb-dump -u root -p'your_root_password' wordpress > $BACKUP_DIR/db_backup_$DATE.sql

# 2. 設計図と静的ファイルのアーカイブ
sudo tar -czf $BACKUP_DIR/files_backup_$DATE.tar.gz -C $WP_STACK_DIR docker-compose.yml wordpress nginx


# 3. 権限の調整（生成されたバックアップファイルをuserが扱えるようにする）
sudo chown user:user $BACKUP_DIR/*.sql $BACKUP_DIR/*.tar.gz

# 4. 30日を経過した古いデータの削除 
echo "Cleaning up old backups..."
find $BACKUP_DIR -type f -mtime +30 -delete

echo "--- Backup Completed: $(date "+%Y-%m-%d %H:%M:%S") ---"

cronによる定期実行

深夜3時に実行されるよう設定。静寂の中でバックアップを完結させる。

0 3 * * * /home/user/scripts/it-mujo-backup.sh > /home/user/scripts/backup.log 2>&1

---

3. 物理メディアへの退避：Samsung T7

サーバー内部に保存したバックアップファイルを、定期的にhostへ引き出し、物理メディアへと書き出す。
ここで使用するのが、NVMeの速度と堅牢性を備えた Samsung T7 である。

選定理由：

• 信頼性: NVMeベースの高速転送は、バックアップという「面倒な作業」の心理的ハードルを下げる。
• 堅牢性: 移動先での執筆が多いエンジニアにとって、衝撃に強いアルミボディは必須だ。
• 本質的価値: クラウドという虚空にあるデータを、確かな重みを持つ物理メディアに書き出した瞬間、記録は「自分のもの」になる。

rsync を用い、host側のマウントポイント（T7）へデータを同期する。

# node01からhostへ引き出し、そのままT7へ同期
rsync -avz node01:/home/user/backups/daily/ /mnt/chromeos/removable/T7/it-mujo-backup/

---

結び

Vultrのスナップショットに甘んじず、自らスクリプトを書き、信頼できる物理メディアにデータを刻む。。

流行が去り、インフラが変わっても、このデータさえあれば「IT-MUJO」はどこでも再建できる。その確信こそが、次の一歩を実直なものにする。

---

執筆環境: host (Chromebook / Debian 13)
公開基盤: node01 (Vultr / Debian 13 / Docker)
接続環境: NordVPN (NordLynx)

独自ドメインを取得した際、エンジニアが直面する「メールサーバーをどうするか」という問い。かつてはPostfixやDovecotを自前でビルドし、SPF、DKIM、DMARCの設定に心血を注ぐことが技術者の嗜みであった。

しかし、現代において個人の技術ログを運用する上で、メールサーバーの維持管理、特にスパム対策やIPレピュテーションの監視にリソースを割くのは、本質的ではない。

今回は、IT-MUJOの公開基盤であるCloudflareの「Email Routing」を活用し、サーバーレスで信頼性の高いメール受信環境を構築した記録を記す。

1. 自前サーバーを「立てない」という選択

ネットワークエンジニアとして、インフラを自前で構築する喜びは理解している。しかし、メールサーバーの運用は「負の資産」になりやすい。

• 管理コスト: 絶え間ないセキュリティパッチの適用とスパムフィルタの調整。
• リソースの最適化: 公開基盤 node01 (Vultr) のリソースは、検証やコンテンツ配信にこそ割くべきである。
• 信頼性の担保: 大手プロバイダへの到達性を個人で維持し続けるのは困難を極める。

「無常に漂い、本質を記す」本ブログにおいて、メール基盤は「堅牢かつ透明」であればそれで良い。Cloudflare Email Routingは、その最適解であった。

2. Cloudflare Email Routing の構築

構築は極めてシンプルである。Cloudflareのダッシュボード上で数回の操作を行うだけで完了する。

設定プロセス

1. Email Routingの有効化: Cloudflareのメニューから「メール」を選択し、機能を有効にする。
2. ルートの作成: 「Get started with Email Routing」画面でカスタムアドレス [email protected] と、普段利用している転送先アドレスを入力する。
3. DNSレコードの自動設定: Cloudflareが生成するMXレコードおよびTXT（SPF）レコードを確認し、ボタン一つでDNSへ適用する。

技術的なポイント

このプロセスで最も本質的なのは、Cloudflareがプロキシとして機能し、私たちのサーバー（node01）を介さずにメールを処理する点にある。サーバー側には一切のプロセスが発生しない。

3. 疎通確認と運用の開始

設定完了後、外部のアドレスから [email protected] 宛にテストメールを送信した。

結果、わずか数秒で転送先の受信トレイに着信を確認。メールヘッダーを確認すると、Cloudflareのネットワークを経由して正しく処理されていることが証明された。

この受信基盤が整ったことを受け、サイト内にお問い合わせページを新設した。

4. 結び：エンジニアの引き算

技術とは、足すことだけが進化ではない。不要な複雑さを削ぎ落とし、既存の堅牢なインフラを賢く利用することもまた、エンジニアリングの本質である。

メールサーバーという重厚な装置を「メール転送」という軽量なサービスに置き換えたことで、私は再び、技術ログの執筆という本来のタスクに集中することができる。

---

執筆環境: host (Chromebook / Debian 13)
公開基盤: node01 (Vultr / Debian 13 / Docker)
接続環境: NordVPN (NordLynx)

1. はじめに：発信基盤としての node01

手元の host で技術を研ぎ澄ます一方で、その本質を外の世界へ提示するための安定した拠点が必要になる。

私は Vultr（東京リージョン）上に、本ブログの基盤となるサーバー node01 を構築した。特定の場所に縛られず、かつ実直な独立性を保つための「器」としての構築記録である。

2. 構造：Docker Compose による LEMP スタック

ホストOS（node01側のDebian 13）の環境を汚さず、移植性と再現性を確保するために、Docker Compose を採用した。これは現代のインフラ管理において合理的な選択である。

• 構成: Nginx / MariaDB / WordPress (PHP-FPM)
• 本質: ホストOSへの直接インストールを避け、コンテナとしてカプセル化（mujo-stack）することで、環境の「無」を維持しつつ、保守性を高めている。

3. 防御：Cloudflare による多層防御

ネットワークを外部に公開する以上、セキュリティを担保するのは管理上の「常識」である。過剰な装飾ではなく、実利に基づいた多層的な防御を敷いている。

• 通信の保護: Cloudflare Origin CA 証明書を適用。Cloudflareと node01 間は Full (strict) モードで暗号化を完結させている。
• WAFによるアクセス制御: 管理画面（/wp-admin 等）へのパスは Cloudflare WAF で常時遮断。執筆時のみ自身の特定IPを許可する「開門・封印」の運用を徹底している。
• 境界防御: Vultr側のファイアウォールにて、HTTP/HTTPSポートのソースIPを Cloudflare のレンジのみに限定。直接の攻撃を物理的に遮断している。

4. 結び：漂い続けるための静寂

複雑に見える構成も、その目的は執筆に集中するための「静寂」を得ることに集約される。

揺るぎない基盤が整い、ようやく「IT-MUJO」としての発信が本格的に始まる。

---

執筆環境: host (Chromebook / Debian 13)
公開基盤: node01 (Vultr / Debian 13 / Docker)
接続環境: NordVPN (NordLynx)