Youtubeの動画作成リクエストをもらったので作成しました。 Microsoftが公開しているチュートリアルに沿ってアプリケーションを動かしながらどのようにWebアプリケーションからデータベースに接続をしているのかという点を説明しています。 https://youtu.be/kqx2ds1NBhA 一番単純に接続する方法としては接続文字列をアプリケーションのコードに生で書いてしまうことでしょうが、さすがにそれは筋が悪すぎるので、チュートリアルでは接続文字列内にIDとパスワードを記載しそれを利用して接続する形態になっています。 次のステップとしてはKeyvaultの利用、あるいはマネージドIDの利用ということになります。 https://www.youtube.com/watch?v=tAfwj_HH02E
個人で管理しているブログをAzureのPaaSに移行しました。合計で6個ほどのブログを移行してみました。 いろいろとハマってしまって、結局丸一日かかってしまったので、事の顛末を記録しておきたいと思います。 動画でも同じ内容を喋っているので、動画でご覧になりたい方は下記からご覧ください。 環境 移行元と移行先は下記です。 移行元Azure VM(Wordpress on Apache2 + MySQL)- 移行先Azure App Service(Linux)- WebApp- Azure Database for MySQL- Azure Blob Storage Wordpress on AppService Wordpress自体はAppService上でコンテナとして動作させました。このコンテナ自体は以前からこのブログ含めて複数ブログで利用していたもので、それを再利用しました。 https://github.com/ebibibi/wordpress-cocoon Wordpressの公式のイメージをもとにそこに自分が利用するテーマやプラグインを追加しているだけのシンプルなものです。 レポジトリにコードをコミットすれば自動的にGitHub Actionsでイメージがビルドされたうえで、Azure Container Registryに格納され、AppServiceにPushされるところまで全自動で動きます。 画像データのAzure Blobストレージへのオフロード 移行先の環境はコンテナなので、画像データをコンテナ内に持っておくわけにはいきません。そこでWordpressプラグインでAzure Blobストレージにあらかじめ画像を逃がすようにしました。 つかったプラグインはこちらです。 https://wordpress.org/plugins/wp-azure-offload/ 少し古いプラグインなのですが、以前から使ってますし、今回もきちんとうまく動いてくれました。このプラグインを使って、あらかじめAzureのブログに画像をオフロードさせます。その際にこのプラグインはブログのエントリーの中に埋め込まれているURLも書き換えるところまで自動的にやってくれます。 MySQL間のデータ移行 MySQL間のデータ移行に関しては、当初Azure Database Migration Servicesを使おうと考えたのですが、スキーマ移行には別途MySQL Workbenchが必要でしたし、それならMySQL Workbenchでそのままデータ移行してしまえばよさそうな感じでした。もちろんこれは私がサイトを簡単に停めても大丈夫だし、データ量も少ないからです。何度もデータ移行を継続的に繰り返さなければいけない時にはAzure Database Migration Sericesが役に立つと思います。 ですが、この方法はうまくいかず文字化けしてしまいました。原因はそもそも私が以前作っていたデータベースの文字コード設定が間違っていたからです。下記の状況でした。 Latin1に設定されたDBにUTF8のデータが入っていた- データ移行をそのまま行うと文字化け…。 いろいろ悩みましたが、結局下記の方法で回避しました。 先に移行先DBをUTF8で作成- Mysqldumpでダンプしたデータ内のcharset関連の部分を置換してから取り込み 具体的には下記のように行いました。 # c # m s s # m D r D y e e D y B e B s d d B s 作 a ダ q 取 q 成 t ン l - - り l e プ d e e 込 u み d m s s - a p / / h t l l o a - a a s b u t t t a i i = s u n n n e s 1 1 e e / _ w w r u g m p t e y _ - f n s d p 8 e q b / r l n a d a - w l b m d p _ . e e _ c m f d s y c a b / s h u n u q a l a t l r t m f . a - e 8 d c c . _ a t h d g t e a u e a r r m n b a p e a s c r s e t > a e t e l . r w _ a U - p c z T s _ i u F e d / r 8 t b e = n w . c l a p c o a m _ o l t e d m l i _ b a n u n t 1 t a - e f m u w 8 e s u p . _ e t _ d u r f d u t = 8 b m f u _ n p 8 s g a . e e m d r n e u e m - r > p p a l w > w _ p p c _ w _ i d p d ; b _ b n d n a b a m n m e a e . m d e u _ m u p t f 8 _ g e n e r a l _ c i . d u m p その他のはまった点 その他にもあれこれはまりました…。 ...
今日は久しぶりにのんびりと自分が管理するサーバーの作業を行いました。今皆さんが見ているこのサイト(cloud.ebisuda.net)をAzureサブスクリプションをまたいでお引越しをしました。 もともとは、MVP特典でもらっていた月額2万弱の枠の中でやりくりしていたのですが、Azureの使える枠が広がったので別のAzureサブスクリプションに移動したうえでスケールアップさせようと思っていたのですが、なかなか時間が取れずにいました。それをやっとやることができました。 以下、躓いたところや気が付いたところを記録しておきます。 移行元環境がどこにあったか忘れてしまって探すのにかなり手間取ってしまった。Azure管理ポータルでAzureADを切り替えたあとには必ずフィルタを確認しないといけない…。やってたつもりでできてなかった…。- PaaSのMySQL同士のデータ移行にはAzure Database Migration Servicesが使えるが、スキーマの移行には(現在は)MySQL Workbenchが必要。- MySQL Workbenchでスキーマ移行時に規定値の部分でエラーが複数発生。「サーバーパラメーター」のsql_modeにて「NO_ZERO_DATE」「No_ZERO_IN_DATE」あたりを無効化したらスクリプト修正なしで大丈夫になった。(※細かく見ていないので適切な対応だったかどうかは不明)- MySQL Workbenchでそのままデータ移行を実行したところ結構失敗した。しかし、Azure Database Migration Servicesではうまくデータ移行できた。裏で色々と良しなにしてくれている模様。 もともと環境は、VMではなくPaaSのMySQLとAppService上で動いているコンテナ環境だったので、サーバーの構成をちまちまいじる必要なくデータ移行さえできてしまえばサクッと移行可能でした。 App Service上でドメインを取得したり、証明書を作成したりとかなりAzureに依存した構成だったので移行できないことを心配してましたが、それは杞憂でした。ドメインやDNS自体はまだ元のサブスクリプションに残したままですが、そのあたりは課金額少ないので当面はこのままにしておきます。 というわけで、ひとつやり方わかったので、同じ要領であといくつかブログをお引越し予定です。