Infrabbitのこのサイトが動いているシステム構成は、以下のような感じになっています。
コンテナはいろいろ動いていたりはしますが、サイト自体は単純なWordpressになっています。
メディアファイルはS3にストアし、S3をオリジンとしたCFとの接続になっており、原則としてコンテナ内には可変要素を持ちません。
なので、Fargateが来たら速攻でFargateに置き換えるつもりでいますが、その前にApplication Scalingを入れておかないといけないかな、と思っています。
さて、半分テストみたいな感じで作っているのでいろいろと変えたいところもあるのですが。
おなかの中にデータを抱えていないので、当然Scalingはできるわけですが、問題となるのはWordpressの場合テーマファイルとプラグインです。
テーマファイルはほとんどの場合CSSとHTMLなので最悪S3にストアという選択肢が取れます（テーマのphp化とかされていると無理ですね）が、プラグインは抱えざるを得ません。s3fsやgoofysでs3を見せる、というのも些かためらわれます。
Scalingしたコンテナでいちいちテーマとプラグインのインストールを都度走らせる、というのも起動が遅くなるので避けたい、となると、結局コンテナにプラグインとテーマを組み込んでしまうしかない。そうすると困ったことにwp-adminからのアップデートは実行しちゃいけない（あるいはコンテナを同時にリリースしないといけない）。
めんどくせぇ。
そしてWPのプラグインやテーマはご存知の通りやたら頻繁にアップデートされますし、そもそもOSSのCMSなんてほとんどの場合プラグインはつっこんでナンボ、の世界でしょう。
ちょっと困りますね。まもなくEFSが来るのでEFSにストアすればよいのでしょうが、これもこれでそこまで速度が出なさそうなのと、そもそもWP本体のアップデートをどうするのだ、という話になります。
結論として、
・プラグインはEFS
・テーマもEFSかS3
・メディアはS3
・コアファイルはコンテナ内臓でアップデートOFF
あたりが現実解なのかな、という感じがいたします。テーマは結局EFSがベストかなぁという気もするんですが。
このあたり、EFSとFargateがそろった段階で一度整理する予定です。
この辺が固まれば、あとはCodePipelineでCodeCommitにDockerfileぶち込んだらデプロイされるとこまでカバーしてしまえば、多少は楽になるのかな。
手で作れば一瞬なわけですが、Infrabbitでは原則としてAWSの構築にはTerraformを利用してコード化を行っています。あちこちで言われていることですが、TerraformにしろCloudFormationにしろ、「全部コード化するとつらいぞ」という教訓を一切合切無視して、すべてをコード化しています。
ECSインスタンス自体もPackerとAnsibleでの固定イメージによる起動ですし、Terraformでデプロイされる可変項目はUserData行きです。
全体的に本気でつらいので全くおすすめはしません。そもそも一部はどう頑張ってもコード化できないので。
原則は部分コード化なのでしょうねぇ。
ほかに誰もいないおひとりさま開発なのに何でそこまで、という気もしないでもないんですが、手で作るとそのときは覚えていても半年もしたら詳細設計書の内容と実体が合致しているのか、自分でも自信がなくなりますし、設計書が更新されているかどうか、こちらも自信が失われます。
コード化されていればとりあえずplanだけでも投げればtfstateとの差分があるかどうかだけでもわかりますし、JSONさえパースできればHumanReadableに成形することも（一応）可能ですしね。
ここしばらくjqばっかり使っている気がします。
この差はとんでもなく大きいです。特にインフラ設計は一度作ると長期運用が前提ですから、数年後にベリファイできるのか、というのは本当に大事です。設計書としては可読性のあるエクセルでちまちまやるくらいならtfstateを保存しておくべきですし。
以前Rancherでやっていたのですが、GCPのインスタンスとAWSのインスタンスでRancherクラスタを組んで、というのもKubernetesに書き換えてテストしないといけないですね。EKSがどこまで面倒見れるのか、少し楽しみでもあります。マルチクラウドでこういうことしようとすると、CloudFormationだけだとどうしてもできないことなので、InfrabbitではTerraformを利用しています。
YAMLで書けるようになったCloudFormationがちょっとうらやましいのは内緒ですが。HCLももうちっと可読性がよくなるといいんですが…。
