見にきてくれてありがとうございます。石川さんです。
このブログ、実はGoogle Cloud（GCP）のCompute Engine上のWordPressで動いています。WordPressのサイトヘルスステータスから「PHPのバージョンが古いよ～」、と言われているのに気づいたので、そろそろPHPのバージョンを上げなきゃなぁ、とずっと思っていたのですが、気づいて調べたときに「OSのバージョンアップから必要です」ということが分かって、そっと先送りにしていました。。。
ところが、つい先日、大々的にPHPの脆弱性が発表されてしまいました。詳細を確認している時間もなかったので、取り急ぎサイトは停止。と、いうことで、ついに本格的に対応することにしました！そのときの調査と移行作業の記録です。同じように古いVMを放置している方のお役に立てばうれしいです。
現状調査：想像以上に古かった！
まずは、サーバーの中身を確認しました。結果は、、、OSもPHPもDBも、全部サポート切れでした。なんてこったい。
| 項目 | 移行前 | 状態 |
|---|---|---|
| OS | Debian 9（stretch） | 2022年にサポート終了 |
| PHP | 7.4.4 | サポート終了 |
| DB | MySQL 5.7.29 | サポート終了 |
| Webサーバー | Apache＋php-fpm | ― |
| VM | e2-micro（us-west1） | 無料枠の範囲 |
確認には、以下の読み取り専用のコマンドを使いました。何も変更しないので、安心して実行できます。
cat /etc/os-release | head -4 php -v mysql --version ps -eo comm | sort -u | grep -Ei 'apache|httpd|nginx|mysql|php' sudo find / -name wp-config.php -not -path '/proc/*' 2>/dev/null
Debian 9に標準で入っているPHPは7.0だそうです。この環境でPHPだけ上げようとしても、OSが古すぎてPHPの最新までは上げられないのですよね。そのため、まずは「OSから」バージョンアップする必要があったのでした。
ドメインまわりも確認しました。GCPで管理しているつもりだったのですが、ドメインの登録はいつの間にかGoogleからGoDaddyに移管されていました。。。ただ、DNSは今もCloud DNSで管理されていたので、サーバーを入れ替えてもDNSは触らなくて大丈夫そうです。ほっ。
方針：OSは上げずに、お引っ越しします！
今のVMのOSを上げるのはやめて、Debian 13の新しいVMを作ってWordPressをお引っ越しすることにしました。比べてみると、こんな感じです。
| 新VMへお引っ越し（採用） | 今のVMでOSアップグレード | |
|---|---|---|
| OSの上げ方 | Debian 13を新規インストール（1回） | 9→10→11→12→13の4段階 |
| 失敗したとき | 旧VMがそのまま残る | スナップショットから復元 |
| 切り替え | 静的IPの付け替えだけ | 作業中ずっと停止 |
Debian 9から13まで4段階も上げるのは、さすがに気が遠くなりますよねぇ。OSのバージョンアップでもうまくいくと思いますが、不要なモジュールが残ったり、不具合が発生することもあるかも知れないので、やはり、新VMへお引越しの方が、スッキリしますね！移行後の構成は、Debian 13＋PHP 8.4＋MariaDB＋Apacheです。PHP 8.4は2028年末までセキュリティサポートが続くので、しばらくは安心です。マシンタイプは、移行前と同じe2-microのままにしました。
作業の流れ
作業は、6つのフェーズに分けて進めました。
- スナップショットと公開停止：旧VMのディスクを保存して、Web用のネットワークタグを外します。こうしておけば、旧VMを起動してもサイトは外から見えません。ずっと停止しておけば関係ないのですけど、旧データを引っ越す関係で起動する必要があったので、公開停止方法も調べました。
- バックアップ：旧VMで
mysqldumpとtarを実行して、DBとWordPressのファイルをまとめます - 新VMの作成と転送：Debian 13のVMを作って、Cloud Shellを中継してファイルを運びます
- 新VMの構築：Apache、PHP 8.4（php-fpm）、MariaDBを入れて、DBとファイルを戻します
- 静的IPの付け替え：旧VMの静的IPを新VMに付け替えて、Web用のタグを付けます
- SSLと動作確認：certbotで証明書を取って、管理画面からプラグインなどを更新し、メールが送れるか確認します
新VMの作成と、PHPまわりのインストールは、こんな感じのコマンドで行いました。
gcloud compute instances create <新VM名> --zone=us-west1-a \ --machine-type=e2-micro --image-family=debian-13 --image-project=debian-cloud \ --boot-disk-size=30GB --boot-disk-type=pd-standard sudo apt -y install apache2 mariadb-server php-fpm php-mysql php-curl php-gd php-intl \ php-mbstring php-xml php-zip php-imagick certbot python3-certbot-apache sudo a2enmod proxy_fcgi setenvif rewrite ssl sudo a2enconf php8.4-fpm
e2-microはメモリが1GBしかないので、念のため1GBのスワップも追加しておきました。
つまずいたポイント
ネットワークタグの名前が違う！？
GCPでWebを公開するタグといえば http-server と https-server だと思っていたのですが、このVMは wordpress-…-tcp-80 のような独自の名前になっていました。Click to Deployで作ったVMだったからのようです。外すタグを間違えると、公開を止めたつもりで止まっていない、なんてことになってしまうので、要注意です！
タグを外したのに、一覧から消えない！？
remove-tags を実行して、さあ外れたかな、とファイアウォールルールの一覧を見たら、、、対象タグがそのまま残っています。あれ？
実は、ファイアウォールルールは「このタグが付いたVMに許可する」という定義で、VMとはタグ名で結びついているだけなのですね。外れたのはVM側のタグなので、確認もVM側でしなきゃいけませんでした。データベースで言えば、結合相手の行がなくなっただけで、ルールの行は残っている状態です。そう考えるとスッキリしますね。
VM作成時の警告にドキリ
新しいVMを作ったら、「200GB未満だとI/O性能が出ないかも」「イメージより大きいので手動で拡張が必要かも」という警告が2つ出て（英語で！）、ドキリとしました。どちらも一般的な注意だそうで、小規模なサイトなら問題なさそうです。ディスクの拡張も、初回起動時に自動でやってくれていましたよ。
certbotのメールアドレスって、どれ？
certbotを実行したら「Enter email address」と聞かれて、はて、どのアドレス？と手が止まりました。普段見ているアドレスを入れておけばよいようです。Let’s Encryptの期限切れ通知メールはすでに廃止されていて、証明書の更新は自動なので、通知がなくても困りません。
パスワードがメタデータに書いてあった。。。
旧VMには、Click to Deployが作ったパスワードが、VMのカスタムメタデータに書かれていました。新しいVMにも同じように書いておこうかな、と思ったのですが、メタデータはVM内のどのプログラムからも読めてしまうそうです。脆弱性対応で引っ越すのに、それでは本末転倒ですよね。と、いうことで、別の場所で保管することにしました。
まとめ
- OSが古すぎるときは、段階的にアップグレードするより、新しいVMへお引っ越ししたほうが手間もリスクも小さいです
- 静的IPを使っていれば、付け替えるだけで切り替わるので、DNSの変更は不要です
- 旧VMとスナップショットを残しておけば、いつでも元に戻せます
- Click to Deployで作った環境は、タグ名やパスワードの保管場所など、独自の作りに注意しましょう
ずっと先送りにしていた作業でしたが、構成をちゃんと把握してしまえば、手順自体は素直なものでした。土曜日の午前中に作業完了しました♪
こんなに簡単なら、もっと早くやっておけばよかったですねぇ。。。皆さんも、放置しているサーバーがあったら、早めに確認しましょうね！