Conoha VPSのバージョンを2.0から3.0へ移行しました。KUSANAGIでWordPressサイトを運用する用途です。公式の手順が無いし、ブログ記事も少なかったので、迷ったり問題にぶつかったりしたので、解決した方法などを解説していきます。
もくじ
最初はPHPのバージョンアップをしたいだけだった
今回の作業に至る経緯は以下の記事に詳しく記載しています。
上記の記事は本記事内で度々言及するので、以降は【KUSANAGIアップデート記事】と呼びますね。
最初はPHPのバージョンが古くて（7.3）、WordPressのプラグインも対応しなくなってきたものもあり、作業当時最新の8.3に上げたいという状況でした。
その中で、KUSANAGIのバージョンも8から9に上げる必要があることがわかりました。その手順を調べると、なんと yum update などのコマンドでできるものではなくVPSの構築からやるものだということがわかりました。
そうであるなら、Conoha VPSのバージョン3.0も登場してしばらく経っていたので、この際移行することが頭に浮かびました。
ただ、2.0から3.0に移行することで、使い方が変わって学習コストが発生するぐらいなら、そのまま2.0で新しいVPSを構築すればいいかな、という気もしていました。
料金については、3.0にすると長期で利用する場合の金銭的コスパが若干向上するように見えますが、料金の仕組みが違うので実質は状況によるということがわかりました。
2.0の料金
3.0の料金
私が利用している1GBプランは12ヶ月の場合、月88円安くなります。
ただ、長期の割引の仕組みが、2.0の仕組みの方が柔軟性があって、無駄なく使えるようです。2.0では割引をVPS間で付け替えることができます。しかし、3.0だと当該VPSへ単体への割引になるので、割引期間中にそのVPSを削除する場合、残った期間に対して払ったお金が無駄になってしまいます。
なので、今回のようにVPSを新規構築して移行しなければならないような状況が発生した場合（数年に一度はありそう）、無駄な支払いになってしまうので、一概に3.0の方がコスパが良いとは言えないと思いました。
以下の記事が参考になりました。
ConoHa VPSの長期割引サービス「まとめトク」の特徴・長所・短所・契約のコツ
しかし、今後2.0のサポートは薄くなるだろうし、情報も減ってくると思われるので、3.0に移行するのが無難かなと考え、移行することにしました。
ということで、
- PHPを7.4⇒8.3
- KUSANAGIを8⇒9
- Conoha VPSを2.0⇒3.0
への移行を同時に行うことになってしまいました。
また、KUSANAGIのアップデートに伴い、MariaDBも10.1⇒10.5へアップデートしたりと、付随するいくつかのソフトウェアもアップデートされたと思われます。
かなり大掛かりな作業です。。。
ではご説明していきます。ただ、KUSANAGIのデータ周りは、【KUSANAGIアップデート記事】に譲りますので、本記事ではConoha VPSのバージョン移行に関わるもののみ説明しています。
ちなみに、Conoha VPSのみバージョンアップしたい方は、2.0でのイメージをまるっと取得して、3.0でそのイメージでVPSを構築すればいいんじゃない？って思う方もいらっしゃると思います。しかし、残念なことに、２.0で取得したイメージは3.0では使うことができません。なので、そういった方にも本記事は参考になると思います。
ちなみに、まだConoha VPSを使っている方は今は特に安くなっているので、試しに使ってみてもいいかもしれません。時間ごとの課金なので、立ち上げてすぐに削除すればほとんどコストはかかりませんし。
移行データ作成用VPSを作る
【KUSANAGIアップデート記事】にも書きましたが、KUSANAGIの移行データを作るために、KUSANAGI8の中でマイナーアップデートをしたり、MariaDBのアップデートをする必要がありました。
そのためには、 yum update をする必要があります。これを本番環境でやるにはリスクがあるので、本番環境のコピー環境を作って行うことにしました。
本番環境のイメージ作成
本番環境のイメージを作ります。Conoha VPSの場合、手動でイメージを作成する場合、対象のVPSをシャットダウンしなければなりません。有料の自動バックアップ機能を使えば、シャットダウンは不要なようです。
私はそんなオプションはつけていないので、シャットダウンが必要になります。シャットダウンしているときは、もちろんサイトは表示されません。これが長くなったら嫌だなーと思っていたのですが、 9分程度で完了しました。ちなみに当該VPSはSSDが50GBのプランでした（今は50GBのプランは無いのですが、構築当時はありました）が、保存したイメージは47GBでした。
私がもっと怖かったのは、イメージ作成後に、起動した際に、きちんとサイトが動いてくれるかどうかです。いろんなプロセスを立ち上げ直さないとなるとかなり厄介です。
とはいえ、その必要がなく、起動後は何もせずにサイトが動きました。これはKUSANAGIの特性なのかConoha VPSの特性なのかはわかりません。ちなみに、シャットダウンする前に、各サービスのプロセスを一つずつ落とすなどはせずにコンソールからブチっとシャットダウンしました。
ちなみに、Conoha VPSの場合、50GBまでなら無料枠のストレージに入ります。前述したように、私の場合47GBでしたので、ギリギリ入りました。ただ、無料枠に入れているイメージは、どうやら利用されずに90日経過すると削除されるようなので注意が必要です。90日おきに利用するなどすれば、ずっと残せるのかな？ちょっとわかりません。
作成したイメージでVPSを新規構築
残念なことに、 バージョン２.0で作成したイメージは、バージョン3.0で使うことはできません。試しに、バージョン3.0に切り替えてイメージの一覧をご覧になってください。当該イメージは表示されないはずです。
もしかしたら以下のCLIツールを使えば、柔軟にイメージを移行できるかもしれませんが、ちょっと情報が無さすぎて怖かったので使いませんでした。
ご利用ガイド CLIツールで簡単にISOイメージをマウントする
なので、バージョン２.0にて、作成したイメージを使ってVPSを新規構築します。これで移行データ作成用VPSができます。
移行データ作成
作成した移行データ作成用VPSにて、移行データを作成します。これについては【KUSANAGIアップデート記事】をご覧ください。
バージョン3.0で移行先VPSを新規構築
Conoha VPSの管理画面にてバージョン3.0に切り替えます。VPSの新規構築の方法についてはほとんどバージョン2.0と変わりません。以下で説明しているのでご覧ください。
この記事は、以降でも言及するので【Conoha VPSレビュー記事】と呼びます。
ちなみに、選択するイメージタイプについてですが、KUSANAGI関連だと「かんたんKUSANAGI」と「WordPress(KUSANAGI)」の二つがあります。
バージョン2.0の時は前者を選んでいました。こちらにはKUSANAGI ManagerというConohaが作ったツールがついています。後述するつもりですが、このツールが非常に厄介なツールなので、なるべく使いたくありません。とはいえ、後者の中身かどういうものかよくわからないですし、KUSANAGI Managerはデフォルトで自動バックアップを設定してくれるという唯一のメリットがあるので、前者を使うことにしました。自動バックアップ以外のKUSANAGIの機能は使わなければいいだけです。
ただ、一つ違う点は、3.0になり「セキュリティグループ」という概念が導入されました。どんな通信を許可するかを設定できるというような機能です。
私の場合は、以下を入れています。
- IPv4v6-KUSANAGI manager
- IPv4v6-SSH
- IPv4v6-Web
基本的に何も選ばないとdefaultというものがつき、これだと外部との通信ができません。セキュリティグループはデフォルトだと基本的に通信できず、そこからどんな種類の通信を許可するかという観点でセキュリティグループを選びます。
１はKUSANAGI ManagerのWEB画面を見るためのものです。先ほどKUSANAGI Managerは使いたくないと言いましたが、WEBツールなので設定を見るだけなら見やすいので、一応見られる状態にはしておきます。KUSANAGIの設定変更などはコマンドラインで行った方がいいです。
2はコマンドラインで作業するためにSSHでログインするためのものです。
3は当然WEB画面を表示するためのものです。
これらは順番は関係ないようです。どれを上にしても結局同じ順番に並びます。これだけつけておけばとりあえず作業と運用はできます。
ちなみに、作業時以外は1と2は解除して3だけにしたらより安全です。
補足：KUSANAGI Managerがダメな理由
「かんたんKUSANAGI」というイメージによって作ったVPSにはKUSANAGI Managerというツールが付いています。これはKUSANAGI公式のものではなく、Conoha側が作ったツールで、WEB画面で簡単にKUSANAGIの管理ができるというものです。【Conoha VPSレビュー記事】で簡単に使い方に触れています。
今になって分かったのですが、このツールは使わない方がいいです。同じことがコマンドラインでできますし、KUSANAGI Managerを使うと厄介な事態を招く可能性があります。
それが、プロファイル名がランダムな文字列になってしまうという問題です。
KUSANAGI Managerは自動的にバージョンアップします。（これも困った仕様ですが）
しかも、この通知画面以外にバージョンを確認する画面が無いのがひどい作りです。（しかも、いまだにバージョン1.0に達してないのはやる気を疑ってしまいます。。。）
自動的にアップデートされるのは致命的な問題ではないですが、いつからかプロファイル名を以下のようなランダムな文字列にしてしまうようになったのです。
|
1 2 3 4 5 |
# kusanagi status Profile: 6723218321be1ac8243d1bf7 FQDN: proggy.info Type: WordPress KUSANAGI Version 8.7.13-1 |
プロファイル名がランダムの文字列だと、ディレクトリ名や設定ファイルの名前にもそれが入ってきます。コマンドラインの作業をしているとこれが可読性が非常に悪いです。なので、どうにかプロファイル名をFQDNに合わせて変更できないか調べたところ、それがかなり難しいのです。
私のVPSは複数のサイト（プロファイル）を運営しています。最初の頃はFQDNとProfileの文字列を同じでした。その頃に作ったプロファイルは kusanagi migrate というKUSANAGI公式のコマンドで移行しました。
kusanagi migrate を使うとランダムなプロファイル名もそのまま持っていってしまいます。なので、この移行のタイミングで、ランダムなプロファイル名になっているサイトは、コマンドラインでプロファイルを作り直して、データは別の方法で移行することにしました。詳しくは【KUSANAGIアップデート記事】をご覧ください。
まぁ、KUSANAGI Managerは非エンジニアの方でもKUSANAGIのサイトをWEB画面のインターフェースで立ち上げられるようにするのが目的だと思うので、そもそもコマンドラインで可読性など考えないのも仕方ないとは思います。でも、Conoha VPSのバージョンアップのための移行やKUSANAGIのバージョンアップのための移行など、ある程度長期で運営すると絶対に避けられない状況があります。なので、KUSANAGI ManagerもWEB画面でデータエクスポートやインポートできる機能を付けないのは筋が通らないのではないでしょうか？非エンジニアの方は短期間で運営をやめるだろうという考えなのでしょうか？
移行データの取り込み
移行データの取り込み、PHPのアップデート、動作確認、などのもろもはKUSANAGIアップデート記事をご覧ください。
ドメイン切替え。DNSが両Verにあって大混乱
動作確認も完了したら、ようやくドメインを切り替えます。
Conoha VPSは独自に「DNS」という機能を持っています。この機能で当該VPSのIPとドメインを紐づけます。ドメインを購入したレジストラでは、IPアドレスを指定するのではなく、サーバー業者側のネームサーバーを指定する、というケースが多いと思います。
しかし、今回この「DNS」が厄介な仕様になっていることがわかりました。
この「DNS」ですが、2.0、3.0それぞれにあります。なので、通常3.0に移行することを考えると思います。
2.0と3.0の大きな違いとしては、ネームサーバーが違います。
2.0だと上の画像のように
- ns-a1.conoha.io
- ns-a2.conoha.io
- ns-a3.conoha.io
というネームサーバーです。
3.0は以下です。
- a.conoha-dns.com
- b.conoha-dns.org
これを知って、最初は喜びました。というのは、先ほど紹介した以前にConoha VPSでKUSANAGIのサイトを構築したという記事にて詳しく書いたのですが、ioというトップレベルドメインに不安がありました。なので、comやorgというメジャーなトップレベルドメインになることは、安定性を上げるためにはとても良い改善です。
さて、あなたはどのようにドメインを切り替えるのが良いと思いますか？ユーザーから見てダウンタイムがないように切り替えたいですよね。
まず、前提として、通常、ドメインを購入したレジストラ側のDNSとConoha VPS側の「DNS」の役割分担は以下になります。
| レジストラ側DNS | ドメインとネームサーバーの紐付け |
| Conoha VPS側DNS | ネームサーバーとIPアドレスの紐付け |
私が考えたのは、2.0の「DNS」の設定を残しつつ、3.0の「DNS」の設定を登録します。その後に、ドメインを購入したレジストラ側のDNSで指定できるネームサーバーを、上述した2.0のものから3.0のものに変更します。こうすれば、レジストラ側の変更が浸透した時点で、ダウンタイム無くシームレスに切り替わります。切り替わりを確認した後、2.0の「DNS」の設定を削除します。
これでダウンタイム無く切り替えできる！って思ってさっそく3.0の「DNS」に当該ドメインを登録しようとしました。すると、以下のようなエラーが発生しました。
失敗しました。
ドメイン追加
サポートに問い合わせた結果、2.0の「DNS」と3.0の「DNS」に重複したドメインが併存でいないということです。理由は教えてくれませんでした。
これは個人的には設計ミスだと考えます。2.0と3.0がそれぞれDNS機能を持つということは、バージョンアップに見えて、実質それぞれ独立した別サービスということになります。別サービスであれば、ドメインの重複チェックなど走るはずもないし必要もありません。それなのに重複チェックを入れているのは思想として矛盾しています。
こうなると、切り替え時は、レジストラ側DNS、Conoha VPS側のDNSの二つの紐付けが同時になくなってしまうわけですから、一旦、ユーザーは当該VPSにアクセスできなくなります。両方の紐付けが浸透されたらようやくアクセスできるようになります。アクセスできなくなる時間がどれくらいの長さなのか読めません。おそらく、新規にドメインを購入し最初にサーバーに紐付けた時と同じような状況かと思います。だとすると、2、3日という情報を目にしました。これは困ります。
ムームーＤＮＳの設定してもサイトが表示されないので対応方法を知りたい
Conoha VPSの運営は、2.0から3.0への移行をさせたくないのでしょうか？2.0の「DNS」と3.0の「DNS」に重複したドメインが併存が、どうしてもシステム的に難しいのなら、何かシームレスに移行できる手段や手順を案内する記事などを公式から出すのが筋ではないでしょうか？
ちなみに、次の記事によると、VPSを3.0のものを使っていても、「DNS」は2.0のものを使い続けても動くようです。
conoha VPS V3（その2:移行したけど不具合多発）
つまり、2.0の「DNS」の既存の設定にてIPアドレスのみ新しいものに変えるということです。
しかし、個人的には、2.0はいつサービス終了するかわからないので、どうせいつかは「DNS」も移行する必要があると考えています。なので、ダウンタイムは発生しますが、今やってしまおうことにしました。
素直に2.0のDNSから3.0のDNSに変更しダウンタイム6時間
ということで、まず、2.0の「DNS」の設定を削除します。この時点でサイトは表示できなくなります。次に3.0の「DNS」に当該ドメインと新しいIPアドレスを紐付けた設定を登録します。当然まだサイトは表示されません。次に、レジストラ側のDNSでネームサーバーを3.0のものに変更します。
ここから変更が浸透するのを待ちます。ブラウザの更新ボタンを定期的に押して確認するけど、なかなか表示されるようになりません。待つことおよそ６時間後、ようやく表示されました。
レジストラ側DNSで完結すればよくない？
後で気がついたのですが、Conoha VPS側のDNSは一切使わず、レジストラ側のDNSで、ドメインとネームサーバーを紐付けるのではなく、直接IPアドレスと紐づけてしまえばいいのでは？というアイディアが浮かびました。切替わりを確認した後に、Conoha VPS側DNSの設定を削除すれば、シームレスに移行できると思います。つまり以下のような役割分担となります。
| レジストラ側DNS | ドメインとIPアドレスの紐付け |
| Conoha VPS側DNS | 使用しない |
実際これをお勧めしているサイトもありました。
ムームードメインでVPSのネームサーバーにムームーDNSを使用する方法
解決策が簡単過ぎて、少し不安だったので、そもそもなぜレジストラ側とサーバー側が両方ともDNSを持っているのか不思議になりました。
上の記事によると、サーバー業者側がDNSサービスを持つかどうかは、固定的なIPアドレスをユーザーに付与するかどうかによるようです。
ロリポップのような共用サーバーは一つのIPアドレスを複数ユーザーで共用していますし、IPアドレスが固定されているわけでもないようです。このようなサーバー業者はDNSサービスを持つ必要があります。
それに対し、さくらVPSなどは固定のIPアドレスをユーザーに付与しているのでDNSサービスを持たないそうです。
ただ、Conoha VPSは固定IPアドレスをVPSごとに付与してくれますが、DNSサービスも提供してくれています。これは混乱しやすい状況です。（良かれと思って提供していると思いますが）
実は私は複数サイトを1つのVPSで運営していたので、２つ目のサイトのドメインの切替をこのやり方でやってみることにしました。
レジストラ側DNSでIPアドレスを指定したことがなかったので、少し怖かったのですが、やってみることにしました。私はムームードメインを使っていたので、やり方は上記で紹介した記事「ムームードメインでVPSのネームサーバーにムームーDNSを使用する方法」とほとんど同じです。ただ、DNSに登録するレコードはTXTレコードとwwwのAレコードは無しにして、www無しドメインのAレコードの一つのみにしました。
ちなみに、最初はwwwのAレコードも入れました。するとKUSANAGIのSSL化のコマンド実行時に厄介な事態になりました。詳しくは【KUSANAGIアップデート記事】をご覧ください。
切替わりにどのくらい時間かかるのかなー、と思っていました。シームレスなのでユーザーには全く迷惑をかけませんが、自分が次の作業に早く移りたいので早ければいいなと思っていました。最初のサイトの事例から６時間はかかってもおかしくないと覚悟していましたが、なんと数分で切り替わりました。もしかしたら、最初の事例の方法だと6時間かかっていた理由は、レジストラ側のDNSの変更は反映が早いが、サーバー業者側のDNSサービスの浸透には時間がかかるからということかもしれませんね。切り替えの確認後、Conoha VPS側DNSの設定を削除します。
Conoha VPSはバージョン２.0と3.0の良バージョンに「DNS」という機能を作ってしまい、このようにシームレスに移行が難しいという事態になりました。想像すると、バージョン4.0や5.0が出た時も同じような事態になりかねません。なので、早めにここで説明した方法に移行してしまうのがおすすめです。つまり、Conoha VPSの「DNS」は一切使わずに、レジストラ側のDNSでドメインとIPアドレスを紐付けるということです。
SSLの設定＆旧本番環境のお掃除と削除
ドメインが切り替わったのでLet's Encryptの自動更新を有効化できます。そして不要になった旧本番環境をお掃除していきます。詳しくは【KUSANAGIアップデート記事】をご覧ください。
あれ？アップデートしたのにサイト表示速度が落ちた
旧環境を削除する前に、サイト表示速度がどれだけ速くなったか比べてみることにしました。Conoha VPSだけでなく、たくさんのものをバージョンアップしたので当然速くなってるだろうなワクワクしていました。
KUSANAGIのキャッシュの設定なども同じにして、同一のページをChromeの「検証」の「ネットワーク」でアクセスしました。
しかし。。。
バージョン2.0
バージョン3.0
あれ、遅くなってるじゃん。
今回、Conoha VPSの他に、KUSANAGI、MariaDB、PHP、WordPress、CentOSなどがアップデートされています。アップデートされたら通常は速度は向上するはずなのですが。Conoha VPSも2.0と3.0で同じプランを選んでいます。
ソフトウェアのアップデートで遅くなるとは考えにくいので、Conoha VPSのアップデートに遅くなる原因があるのでは？と勘繰ってしまいます。（断言していません）
もしかしたら、Conoha VPS側のネットワークの構成なども変わっているのかもしれません。その辺りが影響しているのでしょうか。もしくは、プランに割り当てるリソースを薄めていたりするのかな？とか勘繰ってしまいます。（断言していません）
時間ができたら検証してみたいと思います。
さいごに
まだConoha VPSを使うか迷っている方にお伝えします。KUSANAGI Managerの出来が酷いということと、Conoha VPSのバージョンアップ時の移行が全く想定されていない仕様というのは問題だと思います。とはいえ、共用サーバーのサービスに比べると圧倒的にコスパが良いし、期間限定割引キャンペーン中なので、試しに一度WordPress環境を作ってみてもいいかもしれません。
