Azure App Service / WordPress on Linux (preview) を探る - 2
2018/4/12現在、Azure App Service / WordPress on Linux (preview)はpreviewではなく正式リリースされているようです
前置き
前回に引き続きAzure App Service / WordPress on Linux、今回は開発環境 / 運用とデプロイフローについて見ていきます。
2. 開発環境 / 運用とデプロイフロー
Dockerと参照先のWordPressリポジトリでリモート環境を再現する
前回解説した通り、Azure App Service自体のOS/ミドルウェア構成は、Dockerのimageをベースに作成されています。
また、アプリケーションリソースはgithubで管理されています。
local環境でも同様なimageを参照して、アプリケーションリソースをクローンすれば、リモートと同じ環境を用意することができますね。
前回調べた通り、Azure App Service / WordPress on Linuxで参照されているDocker imageとアプリケーションリソースは以下の通りです。
- Docker image: appsvc/apps:apache-php-mysql-0.2
- アプリケーションリソース: https://github.com/azureappserviceoss/wordpress-azure
docker-compose.yml
appsvc/apps:apache-php-mysql-0.2では、データサーバをbuilt-inのローカルもしくはリモートを選択できます。*1
開発環境では、簡易に制作を開始できるbuilt-inのローカルを利用してみます。
これは、環境変数DATABASE_TYPEにlocalを指定することで実現できます。
また、Docker Containerにその他必要な環境変数をあらかじめ設定しておきます。
version: '2' services: webapp: image: appsvc/apps:apache-php-mysql-0.2 volumes: - ./:/var/www/wwwroot ports: - 80:80 environment: DATABASE_TYPE: local PHPMYADMIN_USERNAME: phpmyadmin PHPMYADMIN_PASSWORD: MS173m_QN
PHPMYADMIN_USERNAME及びPHPMYADMIN_PASSWORDはサービスのデフォルトを利用しています。
wp-config.php
次に、wp-config.phpの作成です。
ここでは、前回説明したデフォルトで紐づけられているWordPressのリポジトリに乗っ取ってwp-config.phpを編集します。
L23〜L26
$connectstr_dbhost = 'local'; $connectstr_dbname = 'wpapp'; $connectstr_dbusername = 'phpmyadmin'; $connectstr_dbpassword = 'MS173m_QN';
DBの作成
docker-compose.ymlとwp-config.phpの準備が整ったら、docker-compose up -dでコンテナを立ち上げます。
これだけだと、まだDBが作成されていないため"Error establishing a database connection"と表示されてしまいます。
立ち上がったコンテナ内に入り、直接DBをcreateしていきます。
このあたりはDockerfileを利用する等して作業の単純化をおすすめしますが、一旦流れをシンプルに説明するためにここでは直接作成しにいきます。
docker exec -it wordpressazuremaster_webapp_1 bash
コンテナに入ったら、build-inのDBに対して新規作成していきます。
$ mysql -u root $ CREATE DATABASE wpapp; $ exit
これで全ての手順が整ったので、改めてdocker-machineのホスト先へアクセスしてみると
無事に成功しました。
ここまでの成果物をアップして、次にリモートと連携をとります。
注意点として、wp-config.phpは環境ごとに設定が違うため.gitignoreで除外してあります。
補足
今回の構成では、毎回DB作成しないといけない、データが永続化されない、といった点がありますが、もちろんDockerの構成次第でその辺りはクリアできます。
また、プロジェクトによってはドキュメントルートを変更したいといったミドルウェアの設定にも影響するものもありますが、Azure App ServiceではDocker Hubを参照することもできるので、自分でカスタマイズしたDocker imageを参照させることでいくらでも設定できます。
あまり突っ込んでカスタマイズしていくと、PaaSではなくなってくるような気もしますが、、publicに晒したくないファイルの管理のためにも、ドキュメントルートの変更くらいはしたほうが運用都合よさそうですね。
また、wp-config.phpといったgit管理したくない設定ファイル系はFTPでアップすることもできます。
リモートのアプリケーションリソース設定を変更する
先ほど作成したgitリポジトリを開発リポジトリと仮定して、次にAzure App Service内で環境を紐づけます。
リポジトリの設定
デプロイオプションから現在紐づいているgitリポジトリを切断します。
新しく、先ほど設定したリポジトリを紐づけます。
以上で、上記リポジトリmasterをwebhookされた状態になっているので、なにかしら変更があれば自動的に取り込まれるようになりました。
簡単すぎる、、、
wp-config.phpのアップ
先ほど編集した箇所と同様の箇所を、リモート環境の環境変数に合わせたwp-config.phpをFTPを利用してアップします。
反映するべき環境変数は、"設定 -> アプリケーション設定"に記述されています。
FTPのアイパスは、"デプロイメント -> デプロイ資格情報"からAzure全体にひもづくユーザアカウント設定をした後、"設定 -> プロパティ"から確認できます。
こちらの情報で接続して、/site/wwwroot/配下にwp-config.phpをアップして正しく設定されていると
無事に接続されます。
運用とデプロイフロー
デプロイメントスロット
Azure触ったっことある方には全然新鮮味のない話になってしまいそうですが、 今回最も感動したのがこのデプロイメントスロットの存在です。
基本ここまで何度か説明している通り、Azure App Serviceはコンテナベースで動いています。
デプロイメントスロットは、コンテナの作成というイメージに近いです。
そして、作成されたコンテナに対してスワップという機能を用いてプロダクションとステージングの切り替えといったことがコンテナ単位で行われます。
Azure App Service内のみでGUIベースでの簡易オーケストレーションツールが付帯されているような感じです。
これがめちゃくちゃ便利で、PaaS環境のことから遠ざかっていた私としては新鮮に感じました。
スロット作成して
もう一度押せば、本番環境がスワップ前の元に戻ります。
コンテナ自体は維持したまま、参照先のみ変更するようなイメージなので、デプロイ自体も全く時間かかりません。
さらに、スワップさせない環境変数といったものも設定できます。
まだ実運用している案件はないのですが、これを利用して相当スムーズなデプロイフローを構築できるのではないかと思います。
本来このようなデプロイフローは、k8sで構築したり、ちゃんとコードを書いて運用に回したりするものですが、プラットフォーム自体がこのようなサービスを提供していてくれれば、ものすごい効率いいですね、保守管理付きです。
振り返り
改めて振り返って、Azure App Service非常に使えるなという印象でした。
しっかり調べたら他2大サービスも近いことできそうですが、UI UXに関して言うと個人的にはダントツで一番使いやすくてわかりやすかったです。
また、コンテナのホットデプロイといった本来シンプルなものをシンプルに機能提供できている点についても、とてもフレンドリーに扱いやすかったです。
なにより触っているだけでサービスが理解できてきてワクワクしてくる、これがサービスの本質だなぁと肌で感じることができました。
これを機に、自社案件受託案件問わず積極的にAure App Serviceの提案をしていってみようと思っています。
また比較として他のPaaSも気になりますが、それはまた別の機会に調べていきたいと思います。
