HAProxy

前回、記事中に「旧サーバについては、ファイル移行中のフォールバック目的です。ファイル移動が終わったら削除可能です。」と書いていました。しかし、「削除可能」なのは、以下のようなリモートのキャッシュに記載されている旧URLアクセスへの対策を実施済みの前提となります。（書きわすれてた。） すでにローカルストレージで運用しているMastodonサーバの場合、リモートのサーバにキャッシュされている投稿の内容は、古いメディアURLを参照しています。 ここは書き換わることがありません。どのぐらいの期間、投稿をキャッシュするのかもリモートサーバ次第です。 ※基本ずっと残るものと考えたほうが良いでしょう。。 そのため、本来であればローカルストレージ上にすでにアップロードされている画像などのデータを残したままにする必要があります。しかし、それではせっかく移行したのに面倒で取り回しが悪いです。 悪い設定が増えてしまいますが、下記のように当該の旧URLへアクセスが合った場合、内部でオブジェクトストレージを参照するようにします。 尚、投稿やアカウント自体の削除に伴う画像の消去は考慮していません。使い方によっては危険なので、留意すべきです。 バケット内にoldという名前をつけ、そこに旧URLで参照させたいファイルをコピーします。 Mastodonのnginx（通常のセットアップで作成するリバースプロキシ）の前段に、HAProxyを配置する設計です。 Mastodonのnginxだけでも似たようなことは簡単にできると思います。Mastodonと密なnginxか、疎なHAProxyか、どちらの設定がどの程度複雑になるかを想定してを選ぶと良いかもです。 （前段にMastodonと疎結合なリバースプロキシが存在すると、VMのマイグレやマシンの更改時などに非常に便利とおもいますので、趣味が合う（？）方は是非。） まずMastodonの通信を受けるFrontendを作成します。 frontend don-tls-fr http-request set-header X-Forwarded-Proto https http-request set-header X-Real-IP %[src] #本来のヘッダの使い方と違うのでここはお好みで http-request set-header X-Forwarded-For %[src] http-after-response add-header alt-svc 'h3=":443"; ma=31536000' #IP直打ちとかhostが違うときはこっち（設定例未記載） default_backend error-bk bind *:443 ssl crt pemファイルフルパス alpn h2,http/1.1 bind [::]:443 ssl crt pemファイルフルパス alpn h2,http/1.1 bind quic4@:443 ssl crt pemファイルフルパス alpn h3 bind quic6@[::]:443 ssl crt pemファイルフルパス alpn h3 #仮想的に旧Media URLでもアクセス可能とする措置 acl ismastodonlocalfile path -i -m beg /system/media_attachments/ acl ismastodonlocalfile path -i -m beg /system/accounts/ #カスタム絵文字はあまり使っておらず、移行時に全て削除してしまったので以下で正常に移行できるかは謎。コメントアウトしておきます。 #acl ismastodonlocalfile path -i -m beg /system/custom_emojis/ acl ismastodonlocalfile path -i -m beg /system/site_uploads/ #旧URL（/system/ 配下）のCache以外のアクセスをobj-bkへ転送 use_backend obj-bk if { req.hdr(host) 丼FQDN } ismastodonlocalfile #通常アクセス use_backend don-bk if { req.hdr(host) 丼FQDN } 次にオブジェクトストレージと、Mastodon自体へのアクセスを行うBackendです。 ...

Mastodonのオブジェクトストレージとして利用してみるやつ。 Wasabiは2023年春ごろからPublic accessが原則使えなくなっています。詳細は以下参照。 Wasabiのパブリックアクセスが使えなくなった件（対応の仕方） 上記の@noellaboさんの記事では、nginxとlua（openresty）を用いた対応例が示されていますが、今回は別のアプローチとして表題の通りHAProxyを用いたゲートウェイを作ります。 https://github.com/jouve/haproxy-s3-gateway/blob/main/haproxy/haproxy.cfg 上記の「s3v4」と「upstream」をほぼそのまま利用します。set-var-fmtがHAProxy 2.5以降の実装であるため、標準で新し目のバージョンが入らないOSをお使いの人は適宜対応してください。 万が一アクセスキーなどが漏れても参照しかできないように、必要最低限のキーをWasabiで作成してそちらを利用します。 また、WasabiのEndpointのIPが変わっても動作するよう、resolverの設定を追加します。HAProxyはresolver設定を行わないと、プロセス起動時に名前解決を行ったきりそれ以降DNSへの問い合わせを行わない、という挙動を示します。（2.0等といった昔の版は確実に。最近のはちゃんと調べていないです。） 今回、Proxyを動作させるOSは既存弊Mastodonサーバと合わせてUbuntuとしたので、以下を参考にppaを追加します。 https://haproxy.debian.net/ また、上記の設定例だとアットマークを含む画像（サーバのaboutページなどに使われている）がうまく表示されないため、以下のようなFrontendを追加し、そちらを443待ち受けで使用するように変更。 また、backendも追加し、redispatchオプション+retry-onオプションによりオブジェクトストレージ側で404やリトライ可能エラーが出た場合に旧サーバ（非オブジェクトストレージ）の参照やエラー画像を返すサーバを指定しています。（旧サーバについては、ファイル移行中のフォールバック目的です。ファイル移動が終わったら削除可能です。　※2024/2/16追記記事を公開したのでリンク） frontend fr-1 bind :::443 v4v6 ssl crt <pemファイルなど> alpn h2,http/1.1 http-request set-path %[path,regsub(@,%40,g)] http-request set-var(txn.path) path acl ismedia var(txn.path) -i -m end png acl ismedia var(txn.path) -i -m end jpg acl ismedia var(txn.path) -i -m end jpeg acl ismedia var(txn.path) -i -m end bmp acl ismedia var(txn.path) -i -m end gif acl ismedia var(txn.path) -i -m end jfif acl ismedia var(txn.path) -i -m end webp acl ismedia var(txn.path) -i -m end mp4 acl ismedia var(txn.path) -i -m end avi acl ismedia var(txn.path) -i -m end mpg acl ismedia var(txn.path) -i -m end mov acl ismedia var(txn.path) -i -m end mkv acl ismedia var(txn.path) -i -m end flv acl ismedia var(txn.path) -i -m end webm acl ismedia var(txn.path) -i -m end m4v http-response del-header X-Amz-Id-2 http-response del-header X-Amz-Request-Id http-response del-header X-Wasabi-Cm-Reference-Id http-response add-header Access-Control-Allow-Origin * if ismedia http-response add-header X-Nsd-IsMedia Yes if ismedia http-response add-header X-Nsd-IsMedia No if !ismedia default_backend bk-1 backend bk-1 balance first option redispatch retry-on 404 all-retryable-errors server listen-wasabi localhost:8081 check server listen-origin-cache localhost:8082 check server listen-error-bk localhost:8083 check Mastodon側では以下のように.env.production（など）へWasabiのEndpointや書き込み可能なAccessKey、参照用FQDNの指定などを行います。 ...

MaxMind社への登録他は適宜実施。 # mkdir -p /opt/geoip/vol # mkdir -p /root/geoip # cd /root/geoip # cat << EOT >.env GEOIPUPDATE_EDITION_IDS=GeoLite2-Country GEOIPUPDATE_ACCOUNT_ID=<MaxMind ID> GEOIPUPDATE_LICENSE_KEY=<MaxMind License key> GEOIPUPDATE_FREQUENCY=72 EOT # docker run --env-file /root/geoip/.env -v /opt/geoip/vol:/usr/share/GeoIP --name geoip_update --detach --restart always ghcr.io/maxmind/geoipupdate # git clone https://github.com/ntsklab/geoip2-haproxy-ranges # docker build -t geoip2-haproxy-ranges . # docker run -d --name geoip_convert_csv --restart always -v /opt/geoip/vol:/usr/local/var/GeoIP geoip2-haproxy-ranges:latest HAProxyへ以下のような設定を入れる ここは自由に。 frontend XXXX acl isjp src -f /opt/geoip/vol/output/JP.txt acl isadminpath path -i -m sub /wp-admin acl isadminpath path -i -m sub /wp-login.php acl isadminpath path -i -m sub /xmlrpc.php acl isadminpath path -i -m sub /wp-signup.php acl isadminpath path -i -m sub /wp-activate.php http-request reject if !isjp isadminpath 終わり ...

様子見。 in-deep.blue はTLSオフローダとしてHAProxyを利用しておりますが、Debian Backports上にある2.6系から自前ビルドの2.8系に更新してみました。 2.8になって何が嬉しいかというとQUICの本対応です。（他にも色々ある） 実は2.6系から一応使えはしたのですが、Backportsのものは非対応です。どうせビルドするなら新しいものを・・・というやつです。 一応動いているように見えていますが、どこかで不具合が起きたら無効化します。 Mastodonも（見かけ上）QUICで接続されます。なおBackendは・・・（手抜き。） 追記 ビルドめも cd wk/openssl git pull git checkout opensslばーじょん ./Configure --libdir=lib --prefix=/opt/quictls linux-x86_64 make -j2 make -j16 install cd ../haproxy-2.8 git pull make TARGET=linux-glibc \ USE_LUA=1 \ USE_PCRE=1 \ USE_ZLIB=1 \ USE_SYSTEMD=1 \ USE_PROMEX=1 \ USE_QUIC=1 \ USE_OPENSSL=1 \ SSL_INC=/opt/quictls/include \ SSL_LIB=/opt/quictls/lib \ LDFLAGS="-Wl,-rpath,/opt/quictls/lib" ./haproxy -vv make install-bin cd admin/systemd make haproxy.service cp ./haproxy.service /etc/systemd/system/ mkdir -p /etc/haproxy mkdir -p /run/haproxy 2023/12/07 HAProxyの設定例も追記。 ...