Movable Type を AWS で使ういろいろな方法

この記事は Movable Type Advent Calendar 2019 22日目の記事です。

Movable Type を AWS 環境で利用する方法として、「Movable Type for AWS」を利用する。という方法がありますが、$0.07/h の費用が EC2 の利用料金以外に掛かってきます。(t2.micro / t2.nano を除く)これは、月額で5,000円ちょいくらいですね。法人利用する場合にはお安いですね。

とはいえ、自身でライセンスをもっていたり、ほかのアプリやサービスなども絡めた運用をされている場合は、独自に環境を構築したほうがいいこともあります。

ということで、Movable Type for AWS を利用せずに AWS で Movable Type の環境を構築する方法。について書いていきま・・・

すいません、ここ数日ダウンしていて準備が間に合いませんでした・・・。

ということで、ここまでやったらできるよ。ということについての妄想と解説。そして、おまけでお届けします。

ということで、まずは完成予定図がこちら。

oregram-aws.png

ポイントとしては、Amazon ECS の利用と、Code4兄弟を利用した Docker Image のビルドとデプロイの自動化。

CodeCommit に Movable Type のパッケージを解凍したものを含め導入環境の状態で Push します。こうすることで、Movable Type のアップデートや、プラグインの導入などをすべてログに残すことができるので、操作ログになります。まあ、GitHub でもいんですけど、敢えて公開するものでもないのでこちらで。

Docker Image の作成は、CodeBuild で行ないます。この段階で一度 CodeBuild 上での動作を確認しておきましょう。動かないと以降のプロセスがまるっと動かないですからね・・・。

さて、CodeBuild では、Docker Image を ECR にイメージ登録するところまでやってしまいます。ここで登録した Docker Image を CodeDeploy を利用して ECS にデプロイします。

この一覧の流れを CodePipeline で行うことで自動化します。

コンテナ内の Movable Type から利用する永続化ボリュームとしてホストのボリュームを利用することもできますが、EFS が利用できるようになったのでこちらが正解でしょう。とはいえ、最終的にファイル一式は S3 に上げて CloudFront のオリジンにしたいとことです。個々の連携をどうやったらいいものかなあ。と考えているうちに時間が足りなくなったわけですが・・・。

プラグインを使って直接 S3 にアップデートがラクなんですけど、ローカルにファイルがないと画像のサムネイル作るときにおかしくなったりもするのでやっぱり EFS でファイルは保持しておいたほうがいいのではないかと思っているところ。

再構築がおわったタイミングで S3 にアップロードする仕組みのほうがいいかなあ。

(S3 使わないでウェブサイトもコンテナにしちゃえばいいじゃないか)

もうちょっと時間作って全体について改めて記事にまとめることとして、今日の内容はおしまいになりますが、まとめると。

プラグインやテーマのコード管理だけではなく、運用環境のファイルも Git で管理することで運用環境の更新をトラッキング可能にすること。そして、Docker Image のビルドを自動化することで手間を省く。

MTonCodeCommit.png

と、これで終わるのもなんか物足りないので・・・。

ローカルの開発環境も Docker で構築するというのが最近は流行っております。案件単位で環境作ることができるし毎度面倒なことをしないで済むのでラクですね。

ということで、ボクも公開してたりします。

https://github.com/yuji/docker-movabletype-dev

実運用環境に近づけることができる CentOS 8 ベースで構成してるので、コンテナじゃなく環境を作るときにも Dockerfile を参考にすれば環境作りにも役立ちますかね。

Apache + Starman + PHP + MariaDB + Mailcatcher な環境です。百花繚乱してるのでお好きなものを利用すれば良いと思います。

では、メリークリスマス&良いお年を。