こんにちは。
去年に引き続き今年もこのサイトのサブスク移行をしました。
ちなみに、去年やったのはこんな感じ。今年は楽できると思ってたんだけどなー。
ちなみに、去年と比べてこのサイトの構成は
- カスタムドメインを入れている
- Azure FrontDoor Service を入れている
という部分が違います。
さっくり構成はこんな感じ。
進め方としては、こんなくらいラフな感じ。
- 去年のことを踏まえて、サブスクリプション変更をする
- 変更できないやつは作りなおす
サブスクリプション変更
変更前に調べておくとよさそうなこと
サブスク変更の前提条件には、同じテナントにサブスクリプションが紐づいているなどの前提条件があります。
その辺は以下のドキュメントを読んでおきましょう。
(自分は読まずにやってるけどｗ)
サブスク変更できるリソースについては、以下のドキュメントに載っています。
ちなみに、日本語ドキュメントの方がサブスク移行をサポートしているリソースを見るだけならわかりやすいかも。(ちょっと更新のラグがあるけど)
ちなみに、テナントとサブスクの関係については、こんな記事書いてるのでご参考にしてください。
サブスク変更でのトラブルシュートのドキュメントは以下に用意されてます。
(読んでないけどｗ)
事前に見ておくといいと書いたけど、自分は何も見ずにどんどんマイグレーションしていきました。今見ると、ちゃんと調べておけば回避できたこともいくつかあったかな。
実際にやったこと
今回は、
- ひとまず、サブスクリプション変更をやってみる
- エラーが出たら、その場で一番時間がかからずに解決できそうなことをやる
という作戦です。
最近、ちょっとお仕事忙しいのでこれをやる気持ちの余裕がなかったので。。。
サブスクリプション変更(DB+Storage)
去年の移行のときは、Azure Database for MySQL がサブスクリプション変更をサポートしてなかったんです。でも、今年は違います。
去年の10月にサポートされたんですね。
そんで、Azure 接続はサブスクリプションまたぎができるので、ポータルからあっさりサブスクリプションの変更ができます。
Storage も同様です。
サブスクリプション変更(Web Apps)
Web Apps もサブスクリプション変更ができます。
App Service のドキュメントの通り、App Service Plan で相乗りしている Web Apps を1つのリソースグループにまとめて移動しようとしたのですが、なんかエラーが出て移動できない。。。。
しょうがないので、App Service Plan を付け替えて最小単位の構成を作って移動しようとしてもエラーが出て移動ができない。
なので、今回はデータはもうすでにサブスクリプション移行が出来ているので、新しく Web Apps + WordPress を作っちゃいました。
カスタムドメインでの運用をしているので、Web Apps が同じじゃなきゃいけない理由もなかったので。
移行自体は、
- 新しいサブスクリプションの Web Apps + WordPress の環境を作る
- 移行前の環境で使っていた、WordPress の プラグインを全部インストールする。
- DB 接続を切り替える
で、すんなり終わりました。
ただ、これがちょっとこの後のめんどくささを産む要因になっていった気がします。
サブスクリプション変更(FrontDoor Service)
FrontDoor Service もサブスクリプション変更をサポートしています。(というか、今ドキュメントを見てサポートされていたんだと知るｗ)
変更をしてみたところエラーとなったので、FrontDoor マネージドな証明書を組み込んでいるので多分その辺が原因だったんじゃないかなって、今となっては思います。
でも、証明書組み込むからサポートされていないリソースだと思い込んでいたので、新しいサブスクリプションで FrontDoor を作成しました。
作成後、お名前.com で、CNAME の向き先を新しい FrontDoor Service に振り向けました。
この辺までは、何も問題なく、nslookup で向き先が変わったのを確認して、FrontDoor Service のカスタムドメインの設定もして特に問題ありませんでした。
接続テストも特に問題なかったので、順調に向いているのかなーって思ったのですが、なんとなく、サブスクリプション変更前の FrontDoor がルーティングしている Web Apps を停止してから接続テストをしたら、App Service が停止しているエラーがでるようになったんですよね。
つまり、nslookup では、意図した通り新しい FrontDoor で名前解決できているけど、実際に閲覧しに行くときは古い FrontDoor にアクセスしているといった感じ。
よくわかんなかったので、ひとまず前からやろうって思ってた、Azure DNS を使ってレコードの管理に切り替えてみました。
この時点では、CNAME の向き先を新しい FrontDoor に向けたけど、どっかでキャッシュでも効いちゃって、古い方に向いているときがあるのかなって思ってたのでその切り分けがしたかったからです。
ちなみにレコードの追加はこんな感じで、Azureのリソースを選んで設定する感じになります。
でも、結果が変わらなかったので、古い FrontDoor Service を削除して接続できるようになりました。
この移行方法で FrontDoor で困ったこと
この移行方法で、最も困ったのは、FrontDoor のカスタムドメインに対する証明書です。
この証明書は、FrontDoor のマネージドな証明書を使っていて新規に設定する場合はとても便利なものです。
で、今回は FrontDoor のサービスが変わってる(証明書が変わる)のに、CNAME が変わらないからなのですが、このケースで証明書を再発行するには、前の証明書が Clean up されるのを待つ必要があります。
これが、8時間かかるんですよ。。。
8時間経過後、新規と同じく証明書の設定をしていったのですが、今度は設定途中のプロセスで2時間くらい処理に時間がかかり、その間なんもできない時間がありました。
ひとまず、https を http にリダイレクトしてごまかしてましたけどｗ
ということで、カスタムドメインの設定だけで約半日。。。orz
結果的に
結果的にこんな構成になりました。
って、構成はほとんど変わってないですけどねｗ
一応このサイトの課題としては、こんなんを抱えてるので今年の中で改善していきたいなー。
- 元々、Web Apps にカスタムドメインを付けないで運用していて、いまだに azurewebsites.net でのアクセスがある
- 記事毎の目次ができないので、そろそろテンプレを見直したい
- 1サイトだけど、P1V2で CPU がギリギリでスローダウン気味
まとめ
ということで、まぜ全部の移行が終わってなくて若干課金がかかっちゃってるけど、一番のメインのサイトが新しいサブスクリプションに移行できたので一安心です。
で、やっぱり移行は事前にドキュメントをちゃんと読んでおいた方が、作戦ミスも少なくていいのかなーって思います。
来年もまたサブスク移行しているのかな。。。（そだったらやだなー)
コメント