Mysql

個人で管理しているブログを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 その他のはまった点 その他にもあれこれはまりました…。 ...

随分と更新しなくなってしまったこの日記ブログですが、ふと思い立ってVMからAzure PaaSへとお引越ししました。もうVMの管理をしなくて良いように、完全に個人サイト関連はVMを捨てます。 移行は簡単に終わる予定でしたが、MySQLで文字化けが発生…。どうやら前回VMを引っ越した際にDBのcharset設定をミスしていたようです。latin1の中にUTF8で文字が書かれているという謎な状態になってしまっていました。 ちょっと苦労したのですが結局下記の手順で移行しました。 character-setを変更せずにそのままmysqldumpでダンプする。 mysqldump -u user -p –default-character-set=latin1 wp_database > wp_database.dump 「latin1」という文字を「utf8」に置換する。 sed -e s/latin1/utf8/ wp_database.dump > wp_database_utf8.dump 「latin1_general_cs」という文字を「utf8_general_ci」に置換する。 sed -e s/latin1_general_cs/utf8_general_ci/ wp_database_utf8.dump > wp_database_utf8_general_ci.dump 新しいdatabaseに取り込む。 mysql –host=newmysqldbname.mysql.database.azure.com –user=user -p wp_database < wp_database_utf8_general_ci.dump というわけで、新しい環境にお引越しが一応うまく行った感じです。 もう日記サイトをわざわざ見に来るひともめったにいなくなったと思いますが、新しいWordpressならブログの内容をtwitterに自動連投できるようなのでそれを使おうと思います。まる。

今日は久しぶりにのんびりと自分が管理するサーバーの作業を行いました。今皆さんが見ているこのサイト(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自体はまだ元のサブスクリプションに残したままですが、そのあたりは課金額少ないので当面はこのままにしておきます。 というわけで、ひとつやり方わかったので、同じ要領であといくつかブログをお引越し予定です。

このサイトはWordpressで構築されています。Azure上のサービスであるWeb App for ContainersにDocker Hub上の「wordpress」コンテナイメージを元にカスタマイズしたコンテナイメージを展開して動作させています。 Web App for Containersは本記事執筆時点の2018年３月現在では相対的に新しいサービスであり、これを使ったWordpressサイトの構築手法に関してはまだあまり情報がなかったため、備忘録も兼ねて構造を書き残しておきます。 全体像 下図がシステムの全体像です。 実行環境は全てAzure上にあり、１つのリソースグループに格納されています。 App Service on Linuxにより環境が定義され、その上でWeb App for Containerが可動しています。 Wordpressはコンテナ上で実行されています。 データベースとしてはAzure Database for MySQLを利用しています。 App Serviceドメインにて独自のドメイン(ebisuda.net)を取得、割当しており、DNSもAzure DNSを利用しています。 Web App for Containersに展開するコンテナイメージはDocker Hub上のカスタムイメージとして公開されています。 https://hub.docker.com/r/ebibibi/appservice-wordpress/ Web App for Containerにてこのコンテナイメージを利用するように設定を行っています。 Docker Hub上のこのコンテナイメージは、Git Hub上のレポジトリがソースに指定されています。 具体的には下記のレポジトリがソースです。 https://github.com/ebibibi/appservice-wordpress このレポジトリ内にDockerfileが記載されており、このDockerfileの記載内容に従ってコンテナイメージがビルドされます。 このGitHub上のレポジトリを手元のPCにクローンしVSCodeにて編集している状況です。 コンテナイメージ更新の流れ なにか設定を変更したい場合には手元のVSCodeにてDockerfileを編集することであとは全自動でWeb App for Containerまで展開されるようにしています。流れは以下となります。 - VSCodeにてDockerfile編集 - VSCodeからGitHubレポジトリへgit push - GitHubレポジトリとDocker Hubの連携機能によりpushが検知される - Docker Hub上でコンテナイメージの自動ビルド - Docker Hub上でのビルド完了時にWeb App for ContainerのWeb Hook URLに対してPostが実行される - Web App for ContainerがDocker Hubからビルド完了済みの最新イメージを取得 - 更新された最新イメージが実行される 体験としては、手元のVSCodeで必要な編集を行い、コミット、プッシュするのみであとは全自動のため非常に快適です。 ...

今回はリクエストをいただいたので「Windows Serverで社内向けイントラネットをお金をかけずに構築したい」というときにどのような選択肢があるのかを考えてみることにします。 まずは目的を明確に 何かをしようと思ったら色々な事を明確にしなければいけません。アクセスするのは誰なのか、顧客なのか、社員なのか、プロジェクトメンバーなのか。そこでは何がなされるのか、情報提供なのか、商品を売りたいのか、共同の作業場所にしたいのか。アクセスはどの程度見込むのか、可用性はどの程度あればいいのか。 そして何よりも重要なのは、そのシステムによって「何を実現するのか、何ができれば成功なのか」という事を明確にすることです。 これによって何を選択するのかは全く変わってきますし、また、おのずと明確になっていくでしょう。 とはいえ選択肢を並べてみましょう とはいえ、今回ここで具体的に何かを作り出すわけではありませんから、具体的にどのような選択肢があるのかを見ていってみましょう。 手動管理 一番原始的な方法です。 Webサーバーを構築する 手動でコンテンツ(HTMLファイル等)を作成、配置する WebサーバーとしてはWindows ServerですからIISを使うもよし。Apacheを使うもよし。その他動けばなんでもかまいません。 そしてそのWebサーバーに対して自分で作成したコンテンツをおいていくわけです。更新する場合にはエディタで開いて中身を更新。静的なファイルですから読むだけ･･･ですね。 私が始めてWebページを作り出した1998年あたりのころは、みんなこうやってWebページを作っていたものでした。手間かかってました。 手動管理+動的ページ 静的なファイルが置かれているだけではあんまりですので、動的なページを使うということもできます。CGI等を用いてPerl、Ruby、Phyton、Java等で書かれたプログラムを動かす形になります。ちょっとひねるパターンとしてはFlaxを使うようなバージョンでしょうか。マイクロソフト的にはIIS+.NETという感じになります。 確かにやればもうこれだけで何でもできてしまいます。ちょっと大規模にやるならデータの保管場所にSQLデータベースでも使ってしまえばやってできないことは何も無い。という形でしょうか。 ただし、このような形で手動で管理するのは手間もかかりますし、間違いも起きます。大規模なWebサイトを作ろうと思ったらこのような手法だけでは限界があります。また、プログラミングスキルが要求されるなど、誰にでもできるようなものではありません。 コンテンツマネジメントシステム(CMS) そこで登場してきて一気に普及したのが、CMSです。昨今のWebシステムと言えばほとんどCMSにカテゴライズされてしまうのではないでしょうか。 CMSはWebシステムを構成する要素を統合的に管理し、HTMLやプログラミングを知らなくてもWeb上のインターフェース(だけとは限らないが)でWebサイトが構築できてしまうものです。 コンテンツマネージメントシステム – Wikipedia 上記のWikipediaを見てもわかりますが、非常に多くの種類があります。汎用的なものからブログなどある程度形の決まったものまであります。これらはインストールさえしてしまえばその後の運用が楽なものが多いです。 Webアプリケーションフレームワークを使った構築 自分で作る、あるいはCMS自体を作る、というときには昨今は強力なWebアプリケーションフレームワークを用いて作る、ということが多いようです。「手動管理+動的ページ」と書いたものをかなり発展させたものです。 Webアプリケーションフレームワーク - Wikipedia お勧め それでは、私のお勧めを書いてみます。 Windows SharePoint Services Windows SharePoint Services テクノロジ ホーム ページ - Microsoft Office Online 正直なところ、機能的にはあまりお勧めではないのですが以下の点でやはりお勧めせざるを得ないかなと思います。 Microsoft純正である 無料である 特に企業内で使うような場合に「上司が何のことやら理解していないOSSのプロダクト」よりも「Microsoftの製品で無料だけれども、それなりのことができるもの」の方が納得感が得られやすいのではないかと思います。 インストールが簡単なのも良い点です。ドキュメントライブラリなどは他の製品よりもはるかに出来がいい(そもそもこういうものを実装しているものがあまりない)ので、それも良い点です。 ただし、繰り返しますが、機能的な面ではお勧めしません。ですが、それも用途しだい。用途を明確にして、マッチするようであれば有力な選択肢の一つになるでしょう。 機能として何を持っているのか、と言う点については以下にまとまっていますので参照してみてください。(※ただし、何でもできるように書かれているので鵜呑みにしないように!) Windows SharePoint Services の概要 ｜ Microsoft TechNet ブログ - Wordpress WordPress | 日本語 目的が「ブログ」で達成できるのであればWordPressは良い選択肢です。あなたが今読んでいるこのブログもWordPressで構築されています。情報発信がメインであるのであればこれを選んでおけば間違いないでしょう。 ブログとしての次点にはMovableTypeをあげておきます。サポートありの商用バージョンもありますし、オープンソースバージョンもあります。 ...