このサイトはWordpressで構築されています。Azure上のサービスであるWeb App for ContainersにDocker Hub上の「wordpress」コンテナイメージを元にカスタマイズしたコンテナイメージを展開して動作させています。

Web App for Containersは本記事執筆時点の2018年3月現在では相対的に新しいサービスであり、これを使ったWordpressサイトの構築手法に関してはまだあまり情報がなかったため、備忘録も兼ねて構造を書き残しておきます。

全体像

下図がシステムの全体像です。

 

実行環境は全てAzure上にあり、1つのリソースグループに格納されています。

 

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で必要な編集を行い、コミット、プッシュするのみであとは全自動のため非常に快適です。

コンテナ更新時に失われてしまうものへの対処

コンテナを更新すると、コンテナイメージビルド後に保存したものが全て失われてしまいますのでそこに対しての考慮、対処が必要です。例えば以下のものは失われます。

- Web管理画面からインストールしたプラグイン、テーマ等
- Web管理画面からアップロードした画像等のメディア

他にも色々とありますが、要はコンテナイメージにはじめから入っているものやMySQLに格納している以外のサーバー上に配置されているものは全て更新時に失われてしまうことになります。

「失われてしまう」と書くとネガティブに聞こえますが、だからこそ、この状況を考慮した設計にしておくことでインスタンス数を増やして負荷分散しても大丈夫ですし、イメージを頻繁に更新しても大丈夫ということでもあります。いわゆるImmutableな運用を行えます。

プラグイン、テーマへの対処

プラグイン及びテーマに関しては、Dockerfile上で明示的にダウンロード、展開、配置をするように記載する方式にしています。具体例はGitHub上で確認することができます。

####RR#W#RR#RR--UUOUUUU-I-NNRNNNN-n-K-s-aaDwwuc-t-ppIggnh-a-使ttReezo-l---ttiw-l-`gg/Wpn--weethho-w-gttmttr--o-epttdR-r-tu-/ppP-d-`pywssrw-p-dp::ew-r-`a-//sw-e-ut-p//s--s-nefldd.d-s-zouooza--irgwwit-p-pcinnpa-l-`enll':-u--soow-g-yaa-w-i-edddw-n-sss--s-../dwwuaoostrrraDdd/ppps/krrrugeecs:ss/r:ssw/O..ospoorrtrrdciggp/o//rwnppeosllsr:uusd:gg/p=iiwr"nnpe-//-s-abcsfkbo/oipnwrsrtpcmee-eesnc-tstoc../no42ptn..lef05und..gte31if.4n"z.sizipinpstallwgetunzip

画像への対処

画像は消えてしまっては困るものですので、サーバー以外の場所に配置する必要があります。今回は下記のプラグインを用いてAzure上のストレージアカウントに配置するようにしました。

https://wordpress.org/plugins/wp-azure-offload/

さらに、Azure CDNと連携してCDN上からの配信をするように構成しました。CDNにしたのは単に自分が個人サイトで使ったことがなく、使ってみたかったからという理由だけです。

この構成はうまく動いていますが、Open Live Writerから画像を含む投稿をした時にうまく動かない部分があります。こちらは今後の研究課題としたいと思います。(今は一度下書きで投稿後に、下書き上で画像を直してから投稿しています。)

構築してみて

今回このサイトを新規に構築するまで、自分自身ではContainer関連はちょっとテストで触ってみる程度のことしかやったことがありませんでした。実際に今回の環境を構築してみて、きちんと中核部分がコードに落ちていることと、コードを更新することで更新できることの快適さを改めて感じました。

また、これまで自分で管理しているLinuxサーバー上で各種モジュールのインストールに苦労して、調査して、解決して…ということをずっと繰り返していたので、DockerHub上の公式イメージを元にできることの大変な楽さ、コンテナのモビリティの高さ等を強く感じました。

仮想マシンを大事に何年もメンテナンスし続けるようなやり方にはもう戻りたくないなという印象があります。が、そういう環境を前提として全て作成されているわけでもないので、細かい所で苦労することに今後もなりそうです。

実際にこのサイトを運用する中で経験を積んでいければと思います。