こんにちは。
今回は、自分がこのサイトのサブスクリプションの移行を行った際に色々とはまったので、その忘備録を残します。
ちなみに、このブログですが、2018/6/30～7/6 まで、403のエラーとなっていました。
というのは、6/30 まで使っていたサブスクリプションが有効期限付きのものであり、事前に有効期限が切れる前に従量課金に変更するようにアナウンスをもらっていたのですが、そのメールを見逃していて期間終了したために止まっていたのです。
その結果、サポートに連絡して一度従量課金プランで復旧させたのち、別のサブスクリプションに変更をしたというシナリオになります。
移行シナリオは
- 移行元/移行先のサブスクリプションが異なるテナントのため、移行元の従量課金プランのサブスクリプションを移行先のディレクトリに変更する
- 移行元のリソースを選んで、移行先のサブスクリプションに変更する。
なお、構成は、こんな感じ
1つの AppService Plan に、２つの Web Apps が載っていて、DB は、それぞれ Azure Database for MySQL で、それぞれが Storage を持っています。
サブスクリプションのディレクトリ変更
これは簡単ですよね。
- まずは、移行元のサブスクリプションのIAMで、オーナーとして移行先のサービスアカウントを追加します。
- で、移行先のサービスアカウントでサインインして、サブスクリプションのディレクトリを変更します。
たったこんだけ。
ということでやってみました。
ただ、処理は正常に終了したのですが、移行先のサービスアカウントで紐づけたディレクトリのサブスクリプションを見ても表示されない。。。
しょうがないので、移行元のサービスアカウントでサインインしたら、今度はサブスクリプションがない状態。。
移行先のディレクトリに、移行元のサービスアカウントを所有者として追加しようと思ったら、なぜかメールが届かない。。。
正直、またサポートに連絡？？って思いました。
が、ただの反映が遅いだけで、結局大丈夫でした。
昼ごはん食べにいってそのあとのんびりしてから確認したので、2～3時間後にみたらうまくいってたって感じですかね。
ひとまずこんな感じになりました。
リソースのサブスクリプション変更
ディレクトリが変更できたので、ひとまずサブスクリプションの移行をやっていこうと思います。
AppService Planの変更
まずは、2つの Web Apps を同時ではなくて順次移行を考えていました。
そうするとネックになってくるのが、1つの AppService Plan の上に2つの Web Apps が載っているので、これを分離したいと思います。
ということで、
- AppService Plan を作成する
- Web Apps の AppService Plan を変更する
という手順で作業を進めたのですが、結果はNGでした。
というのも、Web Apps で AppService Plan の変更を選択しても、作成した AppService Plan が表示されない。
Azure ポータルでやっても同じ結果
ドキュメントを調べたところ、AppService Plan を変更するためには以下の条件がありました。
- 同じリソース グループに存在する
- 同じ地理的リージョンに存在する
- 同じ Web スペースに存在する
今回は、リソースグループもリージョンも同じにしてたので、Web スペースってやつなのかな？？
って、Web スペースって何？？って感じです。
ちなみに、今は AppService Plan にPv2が選択できるのとできないのがあるんですねー。
この辺が原因？？
ということで、これは Clone App で、複製作って別のApp Service Plan に紐づける作戦ですましちゃいました。
っていうか、Clone App って初めて使ったｗ
ちなみに、Clone App にするには、AppService Plan を Premium プランに変更する必要があります。
※ スケールアップのプラン変更は割とすぐに終わった。
リソースグループ丸ごとのサブスクリプション移行
Web サイトをわけることができたので、丸っとサブスクリプションをマイグレーションしようと思ったのですが、まぁー、うまくいかなかったです。
Azure Database for MySQL のサブスクリプション移行
Azure Database for MySQL は、現時点ではリソースグループもサブスクリプションも変更がサポートされていません。
移動ができないので、MySQL Workbench を使ってマイグレーションで逃げました。
この辺っすね。
これをやるためには、新しいサブスクで、Azure Database for MySQL を一個つくって、
クライアントアクセスできるようにしてってのは、必要っすね。
その他のサブスクリプション移行
このあとは、なんも問題なくできました。
ただ、リソースグループで移動しないで、サービスごとに移動しました。
(もう、移動でエラーが出ることにつかれてきたので。。。)
- ストレージ
- Web Apps / AppService Plan
やっていて気づいたこと
色々やりながらも、試してみたらうまくできちゃったってことをいくつか発見しました。
思い込みっていけないですね。
あと、今時点でできただけなので、将来的に保障される動作ではありあせん。
サブスクリプションが異なっていても、Azure サービス接続はできる
今回の移行をしてる途中で、Web Apps と Azure Database for MySQL が別サブスクリプションになったときに、つながないんじゃないかなーって試しに動作確認したら、ちゃんと接続できちゃいました。
サブスクリプションまたぎでも、Azure サービスで接続できるんですねー。
Web Apps のバックアップは意外と利用できる
色々試している中で、元の設定に戻したつもりだったのですが、うまく動作しない状況になったんですよね。
それで、ダメもとで、Web Apps のバックアップからリストアしたら、ちゃんと元通りに戻りました。
Web Apps のバックアップって使うシーンってそんなにないかなーってなんとなく思ってたのですが、今回のように設定をぐりぐりいじったりするときには、いざというときに使えるんだなって思いました。
※ 去年の夏にWeb Apps のバックアップ周りは、色々試してサポートに問い合わせしてたので、機能的に改善されてるのを知ってたから普通に試せたんですよねｗ
移行元で Application Insight を利用している場合
Clone App で Web Apps をクローンするときに、Application Insights を一緒につくることができます。
今回はこれで新規作成していたので、前のデータがなくなっちゃうのはもったいないなーって思いつつ、Application Insights は新しく構築することにしました。
んで、しばらくしてからサーバサイドのメトリックスのデータがないことに気づいたんですねｗ
Web Apps の Application Settings の中で、Application Insights のキーを持っているので、ここが影響しているのかと思ってみてみたら、クローンする前の設定がひき継がれてました。。。
裏を返すと、Application Insights も、サブスクリプション移行をしてしまえば、何も気にせずデータがとり続けられたんだと思います。
そうすれば、クライアントサイドのモニタリングもキーを変える必要もないですし、ちょっと失敗したな。
でも、消してから気づいたので、これは後の祭り。。。。
まとめ
長々と書いてきましたが、Azure Web Apps を別サブスクリプションに移行するときの手順をまとめると、次の通りです。
ただし、今回の環境は、AppService Plan に複数の Web Apps を載せているということと、
App Service Plan をPv2が利用できない環境からできる環境へのマイグレーションであったという部分があるので、
多少冗長なところはあると思います。
[手順]
- 移行前後のサブスクリプションを同じディレクトリに紐づける。
- Azure Database for MySQL を、移行先のサブスクリプションにも作り、MySQL Workbench をつかってマイグレーションする。
マイグレーション後、Web Apps の App Settings より、接続文字列を変え移行先のMySQL での接続テストをする - メディア用の Storage をサブスクリプション変更で、移行先のサブスクリプションに移す
- サイト別にマイグレーションするために、Web Apps を Clone して、App Service Planeを Web Apps 別に振り分ける
※ この時点では移行元のWeb Apps で運用するために、Cloneは、ほげほげ2とかそんな名前 - 4で Clone した Web Apps と App Service Planeを、移行先のサブスクリプションに移動する。
- 運用中の Web Apps を削除する(ここで一度サービス停止)
- 5で移した Web Apps をもう一度 Clone して、6で削除した Web Apps 名をつける(URL を引きつぐため)
※ カスタムドメインを利用している場合は、6と7は不要で5で移動したものを利用するはず
※ DNS のリフレッシュの時間によっては、正常に移行できても、403のエラーとなる場合がある。 - 移行元に残っているリソースを削除する
サブスクリプションの移行はあまりやったことがなかったので、実際に自分のブログで試してみて色々と勉強になりました。
ついでに、前からやろうと思っていた、Azure Dtabase for MySQL の統合もできちゃったのでよかったなって思っています。
あと、今回は事前に何も調べてない状態で、いきなり移行をやってみたのですが(そうせざるを得なかったのはあるけど)、それで色々つまりながらも最初の Web Apps の移行で4時間くらいでできちゃったので、PaaS の環境で運用するのは楽だなーって思いました。
これをオンプレで運用していて、別サーバに移行するってやってたら何時間かかってたんだろ。。。
でも、Try & Error で試した方法ですので、もっといい手順があると思います。
もっといい手順をご存知で教えてもいいよって方がいましたら、アドバイス頂けるとうれしいです。
コメント