もうタイトルのまんまです。
一昨日のAMまでは、設定なり投稿の下書きなり、スパムコメントを削除したりとできてたのですが、その日の夜から更新できなくなっちゃいました。
パッと見でいつもと違うのは、スパムコメントの数で1桁多い感じだったのと、お酒の勢いでDBを直接いじって、コメントをDeleteしたのを最後に、WordPress のダッシュボードも見れなくなりました。。
その前に、WordPress のエクスポートはしてよかった。
で、色々試してみたのですが、WordPress ってあんま知らないのでどうにもならなくて、データもあるので再デプロイしちゃえばいいんじゃないってことにしました。Azure の Web Apps 使ってるのですぐに復活しますしね。
予定ではダウンタイム5分くらいで、あとはちょこちょこ直すくらいのイメージだったのですが。。。
30分くらいダウンタイム発生しちゃいました。。。
なんで再デプロイだったのか
URL を引き継ぎたかったんです。
独自ドメインで運用していたら、WordPressをデプロイして、データをインポートして、DNS の向き先変える流れで済むので、ダウンタイムは無しですね。
だけど、独自ドメインで運用してなかったんです。
そうなると、今あるWeb Apps をそのまま使うか、一度削除して、再デプロイしてデータ入れて再設定しての2択で後者を選びました。
スロット作って、そこにWordPress ぶち込んでスワップするとかも考えたけど、面倒くさそうだし。。。
WordPress のデプロイはデモでも何度もやってるから、失敗も少ないだろうって思い込みもあったし。
ダウンタイムが延びた理由
Web Apps の WordPress のデプロイに失敗したからです。
手順は、ClearDB を 先に作成し、その後Web Apps より WrodPress をインストールする時に、既存DBを選んでデプロイしました。
ClearDB を先にインストールしたのは、直前に実験した時に、WordPress のインストールの中でClearDBを新規作成したら、応答が遅いことが何度かあったり無応答になったので、だったら先に作ってしまい、既存Web App の削除タイミングを後ろにずらすことでダウンタイムは短縮できると思ったからです。
そんで、ClearDB を作成したのですが、リソースグループは米国西部(だったと思う)になって、ClearDBはJapan East になってたみたいで、それに気づかずにWeb Apps を米国西部のリソースグループに紐付けて、東日本に作成したらWordPressのデプロイにこけるし。。。
※ だけど、他のClearDBではリソースグループと同じ場所になってるから、何かのタイミングで偶然出たのかも。
しゃーないから、Web Apps を削除しようとしたら東日本にあなたの指定したリソースグループはないですよ的なメッセージで削除してくれないし。。。
で、リソースグループごと抹殺してやるって思ったら、東日本じゃなかった。。。。
(まぁー、抹殺したので、何もエビデンスないんですけど。。。)
で、リソースグループから自分で作成して、今に至るという感じです。
まとめ
PaaS を使っていても、アプリケーションやDB の不具合でシステムは止まることはありますが、それはユーザ側で管理しなければいけません。
なので、障害復旧プランは持ちましょう!!
あと、再デプロイする時も、捨ててから作り直すシナリオは怖いので、作り直してから捨てるシナリオを考えましょう。。。
ということで、長くなったけど、テスト投稿終了!!
コメント