KUSANAGIで動いているWordPressをAWSからConoHaへ移行したらめっちゃ大変だった話

KUSANAGIで動いているWordPressをAWSからConoHaへ移行したらめっちゃ大変だった話

先月から進めていたAWSからConoHaへのサーバー移行ようやく目処がつきました。
プロにおまかせすればチョチョイのチョイなんでしょうけど、自分でやってみたらどえらく大変だったので、その苦労を忘れないようにメモ…(苦笑)。

問題なく立ち上げできたものの、ドメインでひっかかる

ConoHaへの新規登録、サーバー立ち上げはめっちゃスムーズ。プロビジョニング(=WordPressの立ち上げ)もFQDNにConoHa側のIPアドレスを入れてかんたんにできたものの、SSLに必要なFQDNを独自ドメインに変更することができず、結局DNSサーバーの切り替えを行ってからやり直すことになりました。

データ移行でひっかかる

データの移行でもひっかかりました。

例によって「経験値」さんの記事を参考にさせていただいたんですけれども、

▶ConoHaでKUSANAGI8.0.0-3を設定して他のサーバから移行する方法|経験値

移行でおすすめされている(他のサイトでもおすすめされていることが多い)All-in-One WP Migrationがいつまで経っても「preparing to export」のまま動かない…。一昼夜置いても…(苦笑)。

そこでConoHa公式サイトにあった手動方式

▶WordPressサイトをConoHa VPSに移行しよう|ConoHa

でファイルをバックアップし移動。
これもtgzファイルが開かなかったり、どこのフォルダに入ったかがわからなかったりであたふた…(苦笑)。
それでもなんとかAWSからConoHa側にファイルを移すことができました。

パーマリンクに伴うconfファイルの修正

ConoHaのサイトには移行ができれば表示されると書いてありましたが、私のサイトは拡張子がhtmlではなくphpなのでconfファイルを修正する必要がありました。

▶HTTPS化しました|★ken.fm★

Autopitizmのエラー

一見ちゃんと表示された感じでしたが、画面上部にAutopitizmでキャッシュに書き込みができないとのエラーが…。
パーミッション変えたりしてみましたが消えず、困っていたのですが、所有者と所有グループがrootになっていることを発見し、これをhttpdとwwwにすることで正常に戻りました。

プラグインがアップデートできない

プラグインのアップデートがあったのでアップデートしようとしたところ、できず。
所有者と所有グループをそれぞれkusanagiに変更することでアップデートできるようになりました。

EWWW Image OptimizerとWordPress Popular Postsの画像に関するエラー

EWWW Image Optimizerは画像を圧縮してくれるプラグインですが、一括最適化をしても「画像が見つかりません」の表示。
本当に見つからないのかと画像ファイルのURLに直接アクセスするとちゃんと画像が表示される。なんでだ…。

WordPress Popular Postsはアクセス数の多い記事を自動で表示してくれるプラグインですが、こちらはサムネイルが全く表示されない…。

これらも所有者と所有グループの問題だったらしく、httpdとwwwに変更することでそれぞれのエラーが改善されました。

Jetpackとの連携ができない

管理画面ではJetpackと連携されたままの表示でしたがリンクが壊れており、一旦連携を外して再連携させようとするとできない。
Jetpackとの連携にはxmlrpc.phpが関わっているのですが、チェックしてみるとHTTP 405のエラーが…。

ググってみると、常時SSLの場合は一旦httpsからhttpに戻さないと再連携できないとか、SSLのオレオレ証明書(=KUSANAGIで使えるLet’s Encryptもそれだと言われている)では再連携できないとか載っていましたが、結果としてはLet’s EncryptのSSLでも再連携することができました。
(ちなみにHTTP 405エラーはxmlrpc.phpがダウンロードできるようになってしまっていたことが原因)

結果論なんでひょっとしたら違うかもしれないんですが、KUSANAGIは8.0.1のバージョンからSSL証明書の透明性(=CT:Certificate Transparency)に対応していて

▶SSL証明書の透明性ってなんですか?|KUSANAGI MAGAZINE

kusanagi ssl –ct onのコマンドを入れれば、不正なSSL証明書を早期に発見・検知するための仕組みが走るようになりました。
(PCやAndroid版Chromeのアドレスバー左の鍵マークをクリックすると透明性に関する情報が表示されていた:最新バージョンだと出なくなっている)

この仕組みができたことでLet’s Encryptはオレオレ証明書の域を出てきちんとした証明書として使えるようになったのではないかと。(違ってたらすみません)

ともあれ、Let’s Encryptを使った常時SSL環境でも、Jetpackの再連携はできるようになっています。

DNSが切り替わらない

最後はDNSが切り替わらない…。
ConoHa側にドメインを登録してAレコードを記載。
ドメインのレジストラでネームサーバーをConoHa側に変更するも変わらず…。
AWS側はRoute53で設定していたので、この設定消したらいけるやんと思って消したら、サイト自体全く表示されなくなってしまい、再度各項目を設定し直す羽目に…。

結局はRoute53でConoHa側のネームサーバーを指定することで切り替えることができました。

結局、1か月かかった…。

なんとか普通に動くようになったもののほぼ1月を費やしてしまい、その間記事も書けず…。
僕みたいな素人は素直にレンタルサーバー使ったほうが良いです。勉強にはなりますが、時間と労力がもったいない…。

でも、超快適!

AWSの時に困っていた502 bad gatewayも出ないし、EWWW Image Optimizerのjpegtranなどが読み込めないエラーもないし、超快適!
大変でしたが、頑張って切り替えてよかったです。

スポンサーリンク

LINEで送る
Pocket

Related Posts & ADs