こないだ Web Apps の Sandbox について調べている時に、名前付きパイプを使えば MySQL を自前インストール出来るのではないかと思ったので試しました。あくまでも実験なので、プロダクションで動かしてトラブったり、動かなくなったりしても私は知りません。
結論を先に書くと、ちょっと工夫するだけで TCP でも MySQL を動かすことが出来ました。まずは zip 版の MySQL 5.7.9 をダウンロードしてきて、Web Apps のディレクトリに展開します。
設定ファイルの my.ini を殆どデフォルトのまま適当に作成しました。とりあえず data ディレクトリは、MySQL のインストールディレクトリ以下に置くようにしました。
[mysqld] basedir="." datadir="data" sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
この時点で MySQL は Web Apps 上で実行可能になっているので、データベースの初期化を行ってスタンドアロンモードで mysqld を実行してみました。
"bin/mysqld" --initialize-insecure --user=mysql --log_syslog=0 "bin/mysqld" --standalone --log_syslog=0
スタンドアロンモードだと実行が終わらないので、別の Debug Console を立ち上げてシャットダウンのコマンドを実行すると、無事に mysqld が終了します。
"bin/mysqladmin" shutdown -u root
これで問題ないかと思いきや、Web Apps の Sandbox 内で作成されたパイプやソケットは、同じ Sandbox 内からしかアクセス出来ないようになっています。
なので、アプリケーション設定から SCM のワーカープロセスをフロントと同じプロセスで動かすようにします。ちゃんと Kudu にリファレンスがある機能なので大丈夫です。
Use the same process for the user site and the scm site
WEBSITE_DISABLE_SCM_SEPARATION=trueConfigurable settings · projectkudu/kudu Wiki · GitHub
ポータルから WEBSITE_DISABLE_SCM_SEPARATION を追加すると w3wp.exe が 1 つになります。
当然ながら mysqld は Web App が起動中は常に立ち上がっている必要があるので、WebJob として mysqld を起動するスクリプトを作成しておきます。
同時に Always On を有効にしておくことで、常時起動が簡単に実現出来ました。起動用のスクリプトは PowerShell で書いたので powershell.exe の下に mysqld がぶら下がっていることが確認出来ます。
mysqld が 200MB ぐらいメモリを食うので、占有インスタンスじゃないと辛いと思います。
MySQL を TCP で起動できているので WordPress を使う場合にも、DB の設定はホスト名を 127.0.0.1 に変更するぐらいで動かすことが出来ます。必要な DB は事前に phpMyAdmin で作りました。
データベース情報が 127.0.0.1 になっているので、ClearDB ではなくローカルの MySQL で動作していることが確認できます。実際に WordPress 用の DB を作成したのでインストールしてみます。
WordPress のインストールは Kudu から curl と unzip を使って、直接展開する方法を選びました。DB の設定を変更して、インストールを行うと特に問題なく WordPress が起動しました。
最初はちょっと重かったですが、起動しっぱなしにしているとマシになってきました。DB の保存場所が SMB でマウントしているディレクトリなので、限界は普通にあります。
今回の勝因は WEBSITE_DISABLE_SCM_SEPARATION でした。裏技っぽいですが同一プロセスで動かすことで、Sandbox の影響を受けることなくソケットを利用出来ました。