WordPressサイトを引っ越したものの、なかなか苦労しましたという話の後編。
前編は
サイト引っ越し、そして、再引っ越し（Part1）
WordPressサイトの引っ越し方法
色々あると思いますが、毎回検討するのは、こちらのプラグイン。
All-in-One WP Migration – WordPress
そして、毎回容量オーバーに引っかかっている気が・・・
あまり、検索で引っかからないのですが、その後の作業の中で、以下のような方法もあるのではないか、と思っています。試してませんが、これをまとめておくと次回に役立ちそうな気はしますね。
Jetpack、UpdraftPlus、あと忘れた・・・
phpmyadminのイメージ追加
今回は結局、力業で、DBもダンプ取ってリストア、ファイルは丸ごとwp-content/uploadsを持ってくる。
そのために、是非新サイトのDBもphpmyadminで参照したいということで、イメージを追加します。
これ自体は比較的すんなりいきました。下記を参考にさせていただきました。
https://qiita.com/furu8ma/items/50718efebee20fd24517
/home/wordpress/mariadb/docker-compose.yml
に下記を追加します。
phpmyadmin:
image: phpmyadmin/phpmyadmin
environment:
– PMA_ARBITRARY=1
– PMA_HOST=db-data
– MYSQL_USER=●●●
– MYSQL_PASSWORD=●●●
– MYSQL_ROOT_PASSWORD=●●●
links:
– mariadb
ports:
– 8080:80
volumes:
– /sessions
networks:
– common_link
PMA_HOSTのdb-dataは、この直前で定義しているデータベースデータのコンテナ名です。
また、8080で公開されるので、ファイアウォールのルールで8080を解放する必要があります。
ファイルの移行
DB移行後、最初はそのままデータをINSERTしてしまったら、最初のページから旧サイトに飛ばされるという事態になり、文字列を変換してからINSERTするように修正。
次にファイルの移行ですが、こちらについては、まずファイル20MB制限があったので（何の話か忘れてしまいましたが）、分割してzipでアップしました。
そして、GCE初期状態ではzipが入っていなかったためインストール。
sudo apt install unzip
なぜだか、ずいぶん画像リンク切れが多発していますが、とりあえずは良しとします。
サーバ停止
とりあえず良しとして、アナリティクスの設定をしていたら、数日後、サイトの検索が利いていないことに気づきました。
おかしいと思い、Dockerのダウン・アップをすると利くようになるので、はて？と思っていたら、しばらくするとまた同じ現象。そして、だんだん間隔が短くなっていき、最後は、SSHが接続できなくなってしまいました。
Webコンソールだからかなと、ここでgloudコマンドツールをインストールすることにします。
しかし、gloudコマンドツールは使えるようになっても、そのSSHはやはり使えません。
Google公式トラブルシューティングということで、
https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-ssh?hl=ja
を試していきます。
「インスタンスをシャットダウンせずに検査する」あたりは、今回の件とは関係なくためになる、GCEの色々な機能の勉強になる手順でしたが、結局デバッグインスタンスにも接続できません。
こんなエラーです。
ssh: connect to host 10.138.0.2 port 22: Connection refused
ERROR: (gcloud.beta.compute.ssh) [/usr/bin/ssh] exited with return code [255].
しかし、「起動スクリプトを使用する」によりログが見られるようになり、原因はディスクの空きがなくなったということが分かりました。
GCEは30GBまでAlwaysFree対象なのですが、初期値が10GBなので、10GBで作っていました。
そこで、20GB（なぜかもう10GBは遠慮しておく・・・ではなく、またこんなことがあった時にもう一度拡張できるように）に変更します。
ディスクサイズ関係の基本的な内容はこちらを参考にさせていただきました。
https://www.apps-gcp.com/gcedisk-online-extension/
df -h
・・・ /dev/sda1 20G 12G 8.3G 58% / ・・・
現在はこんな感じですが、これが10GBで100%になっていたわけです。勉強サイトでなければ冷や汗どころではありません。
そして、GCEとして20GBに増やすのは簡単にできてもOSでそれを認識されるのは次の手順が必要なのですが、それについては、こちらを参考にさせていただきました。
http://thr3a.hatenablog.com/entry/20150120/1421724127
これにより、SSH接続は復活です。
ドメインの復活
しかし、復活劇はまだ終わりません。
途中色々いじっていたのが原因だと思いますが、WordPress設定は初期化されてしまいました。docker-compose.ymlの内容が初期状態になってしまっていたためです。
そしてさらに悩ましいことに、再度立ち上げなおしても、接続ができません。Cloudflareの表示ではこのサイトが「move」という表示になっています。そして、IPアドレスでも接続できません。
これも相当悩みましたが、解きほぐすとこのような状態です。
まず、freenomからは「Your domain name has been cancelled」というメールが来ていました。
サイトが死んでいる時間が続くとキャンセルされるという仕組みとのことでした。
そして、
https://gakumon.tech/nginx/nginx_directory.html
でにわか勉強をすると、/etc/nginx/conf.d/ の記述により、ドメイン名でのみリクエストを受け付ける設定になっているということのようです。
そこで、再度freenomで同じドメイン名を登録し、Cloudflareでは、これも再読み込み・再チェック等ではmoveが変わらなかったので、いったん登録を削除して、再度登録し、これでようやく、https://www.programmers-office.ml/wp-admin/install.php にリダイレクトはされるようになりました。installかよ、と思いながら・・・
しかも、リダイレクトはされるものの、HTTP ERROR 500の表示です。
この辺はメモも取り切れておらず、復活方法はあいまいになってしまいました。基本的には、
GCPの無料枠でdev.toなみの爆速WordPress環境を構築する
を改めて漏れがないか確認していくことで復活するはずです。
その意味で、この手順は本当に神かと思いました。
その後、WordPressテーマもいったん浮気して戻したりしていますが、それはまた別途書くことができたらよいなと思います。