icon

aries

ITインフラエンジニア
My central page.

aries

経緯

前回 https://blog.asterism.xyz/posts/2019-08-01/

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

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

構成とか設定ファイルだとか

https://github.com/orlea/pl.asterism.xyz

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

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

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

https://gist.github.com/orlea/1151b27245f89cfff4dce95f4a75fbbd

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と比べてPleroma特有のこととか

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

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

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

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

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

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

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

comments powered by Disqus

Recent posts

See more

Categories

About

都内某所で自社の情シスとかやってます。
Server, Network, Security, Windows, Linux, vSphere, AWS, ConoHa