docker swarmでEC2スポットフリートにPleromaを載せる

Overview

各種リソースを共有させて節約しよう、という発想。

図だとかは前回記事とほぼ同じなので省略。

リバースプロキシ, DB, Dockerホストは共有して、volumeはAWS EFSを使っています。

Pleromaのポートフォワードを4000じゃなくて4040とか4050にしてあるのはMastodonと相乗りしているからです。

またDockerホストにはこんな感じのuserdataを設定しています。

volumeについてですが、Pleromaの場合はMastodonとは違い、オブジェクトストレージを設定していてもカスタム絵文字はローカルのストレージを見ます。

その為に今回はAWS EFS(マネージドNFS)を使い、各EC2にマウントしています。

SDSとしてglusterfsも試しましたがあれは既にプールに所属している側でコマンドを打つ必要がありまして。

私はスポットインスタンスに対してはEC2のuserdataだけで操作を完了したいのでglusterfsはやめてEFSにしました。楽。

以前の記事で書いたように、私はPleromaは自動アップデートを実施しています。(バックアップについてはGoogleではなくS3に投げるように変えましたが)

元々はネイティブに動かしていたので、git pullしてcompileしてecto.migrateして……という形でしたが今回はそうはいきません。

適当に手元でdocker build, pushしてもいいですが面倒なのでCIに手を出すことに。

Pleroma公式のDockerfileを使おうとするとリポジトリをforkしてCI仕掛ければいいそれはそうですがリポジトリ追従の手間があるため断念。

その代わりとして、公式ではない以前から存在していた(また私がpl.asterism.xyzを本稼働させるまえに使ったことがある)Dockerfileをお借りしました。

また、これはDockerfileの中でpleromaをgit cloneしているのでcommitを検知してCIというやり方も通りません。

これが中々の曲者で、初めはCIツールとしてdrone.ioを使おうとしていましたがcloud.drone.ioだとcronが無効化されている為こちらも断念。

ですので今回はCircleCIを使っています。

CircleCIでdocker build, pushを自動化して、swarm managerに仕掛けたcronでecto.migrateとstack deployを自動化しています。

Mastodonはsidekiqはredisにデータを置いて処理させているが、Pleromaの場合redis的なものはローカルに持っている。

またワーカーとサーバ本体とで分割されていない為、ただ単純にPleromaのコンテナを増やせばスケールアップできるわけではない。

スケールとか冗長性とかその辺のissueもちらちら見かけますがうーん……。

まぁお一人様なのでどうでもいいっちゃどうでもいいんですが。

swarmマネージャ(兼リバースプロキシ)とDBが死ななきゃ回復できるというのもある。

あと今回は独自のDockerfileを使いましたが、最近Pleroma公式でDockerサポートをしようという動きがあります。

今の所まだDockerfileが作られたところですが、gitlabのレジストリに最新のdocekr imageを置いてくれるようになるといいですね。