在Misskey中使用Vultr的对象存储
环境
我们通过多台服务器来运行Misskey应用程序。
我认为通常只需要一台服务器,所以我将为那台服务器编写内容。
如果您要在多台服务器上进行运营,请尝试一些小技巧。
操作系统:Fedora 36,Debian bullseye,Ubuntu 22.04
软件:支持以下版本,之前的版本可能无法运行
(特别是Areionskey,除非使用我的派生版本,否则可能会有一些错误)
Misskey v10系列→めいすきー 10.102.586-m544
https://github.com/mei23/misskey/releases/tag/10.102.586-m544
Misskey v11系列→Areionskey 1.4.0-atsuchan-b2
https://github.com/atsu1125/misskey-v11/releases/tag/1.4.0-atsuchan-b2
Misskey v12系列→Misskey 12.117.1
https://github.com/misskey-dev/misskey/releases/tag/12.117.1
オブジェクトストレージのURLをそのまま公開することはせず、
MisskeyをホストしているNginxでリバースプロキシを行います。
そうしないとリージョンが遠くて単純に不利だし、転送量課金なのでなるべくキャッシュして帯域利用量を減らすべきなのです。
Misskeyの設定でオブジェクトストレージを使用するようにすると、オブジェクトストレージ移行前にアップロードされたファイルはhttps://misskeyのドメイン/filesを読み、移行後にアップロードされたファイルはhttps://baseUrl/prefixで設定されたURIを読むようになります。
そのためオブジェクトストレージを将来的に廃止した場合や移転した場合は、その画像を投稿した時点のURLを参照し続けるので、そのURLが消滅した時点で404になってしまいます。
しかしリバースプロキシしておけば、URLを変えずにオブジェクトストレージを変更できますし、最悪廃止した場合でも、そのURLでローカルのファイルを読み出すように設定すれば404になることを回避可能です。
Misskeyはファイルシステムに保存している設定からオブジェクトストレージを利用する設定への移行をサポートしていません。
そのためオブジェクトストレージ移行後に/filesに保存されたファイルを消すとドライブから参照できなくなります。
すでに/filesにあるファイルをオブジェクトストレージに上げても見れるようにはなりません。
DB操作してURIを書き換えてもその変更を連合先に反映する手段がないのでよくありません。
通过Vultr网站创建对象存储。
Vultrのアカウントにログインしてオブジェクトストレージを追加する。
今はアメリカのニュージャージー州かシンガポールのどちらかを選択できる。
アメリカとシンガポールって、サーバーのリージョンによってすごい差がありそうですねw
私は両方使ってます。たぶん日本にMisskeyサーバーあるならシンガポールの方が読み込み速度が速いです。
Labelは適当に。
ReadyになったらCreate Bucketsでバケット作成する。
このバケット名は同一リージョン内で他のユーザのものを含めユニークである(重複しない)必要があるので、
オリジナル性の高い名前(インスタンス名)とかにするといいんじゃないかしら。
バケット作成できたらそのタブは開きっぱなしにして次に。
设置对象存储策略
Vultr的对象存储默认为私有,需要通过以下命令将其设为公开:
首先连接到对象存储,请参考https://www.vultr.com/ja/docs/how-to-use-s3cmd-with-vultr-object-storage,了解s3cmd的用法。
sudo (apt|dnf) install s3cmd
s3cmd --configure
请在之前保持打开的页面上输入Access Key。
请在该页面上输入Secret Key。
输入默认区域为Enter。
输入S3终端是ewr1.vultrobjects.com或sgp1.vultrobjects.com。
输入DNS样式为%(bucket)s.ewr1.vultrobjects.com或%(bucket)s.sgp1.vultrobjects.com。
然后按Enter键、Enter键、Enter键、y+Enter键、y+Enter键来继续。
如果可以的话,创建一个名为misskey-media_policy的文本文件。请将yourbacketname替换为每个人自己设置的桶名称。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AddPerm",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::yourbacketname/*"
}
]
}
执行以下操作将文件保存,并设置S3cmd misskey-media_policy策略至s3://yourbacketname。
创建用于对象存储引用的代理
有三种主要的设置方法,需要谨慎考虑,因为无法后退。
一番多い新しいサブドメイン等で配信するケース
例:misskey.io:https://s3.arkjp.net/misskey
misskey.dev:https://s3.arkjp.jp/dev
misskey.m544.net:https://misskey-drive2.m544.net/m544
meisskey.one:https://misskey-drive2.m544.net/one
优点:在规模较大的实例中,可以使用专门针对对象存储的Nginx等代理服务器,选择这种方式是很自然的。
缺点:必须获取子域名,Cloudflare等服务商不会为子域名生成证书,因此必须考虑好子域名以避免额外的麻烦。
虽然我没怎么看过(只有我吗???)但是新建一个目录并进行发布的情况。
Pleroma虽然是Pleroma,但是pr.shc.kanagawa.jp是https://pr.shc.kanagawa.jp/storage。
メリット:サブドメインを取得しなくてよい、Cloudflareとかはサブドメインのサブドメインに証明書を発行しないわけだし、オブジェクトストレージに移行した後のURIが新しいものとなるので設定は楽?
デメリット:オブジェクトストレージへのプロキシをmisskey Webと同じWebサーバーに置かないといけない、つまりアクセス増加した際に専用のオブジェクトストレージプロキシ用のNginxを用意するとかは不可能になる
替代目前最智能的现有内容分发目录的情况(不好)
原因:https://qiita.com/atsu1125/items/39fa725f6250ba8c7c13
步驟
オブジェクトストレージのメディアを参照するためのWebサーバーのアドレスをサブドメインとして登録する。
私はGoogle Domainsなのだけど、ここでmisskeyサーバーと同じアドレスで、s3っていうホスト名のサブドメインのAレコード, AAAAレコードを追加する。s3っていうのはawsで使われる名前ではあるけど、s3互換とか言うし短い名前だからいいんじゃないかしら。
ちなみに全然違うドメインにホストしても構わないからね。
misskey.ioだってs3.arkjp.netでメディア用プロキシをホストしてたりするし
メディア用プロキシのNginx設定ファイルを作成する
そしたらそのメディア用のプロキシのためのNginxの設定ファイルを書いてくよ
私は/etc/nginx/conf.d/s3.yourdomain.confに設定ファイル書いてるけど
各自の運用に合わせて作成してみて
yourdomainを各自のドメイン名で置き換えるのと
proxy_pass の後のURLはyourbacketnameがバケット名なのでさっき作成したバケット名に置き換える。
mkdir /var/cache/nginx/proxy_cache_images
chown -R nginx: /var/cache/nginx/proxy_cache_images
s3.yourdomain.conf
server {
listen 80;
listen [::]:80;
server_name s3.yourdomain;
location /.well-known/acme-challenge/ { allow all; }
location / { return 301 https://$host$request_uri; }
}
proxy_cache_path /var/cache/nginx/proxy_cache_images levels=1 keys_zone=images:2m max_size=20g inactive=90d;
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name s3.yourdomain;
ssl_session_cache shared:ssl_session_cache:10m;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers HIGH:!MEDIUM:!LOW:!aNULL:!NULL:!SHA;
location / {
try_files $uri $uri/ @proxy;
}
location @proxy {
proxy_ignore_headers set-cookie;
proxy_hide_header set-cookie;
proxy_set_header cookie “”;
proxy_hide_header etag;
resolver 1.1.1.1 valid=100s;
proxy_pass https://yourbacketname.ewr1.vultrobjects.com$request_uri; #シンガポールならewr1ではなくsgp1
expires max;
proxy_buffering on;
proxy_cache images;
proxy_cache_valid 200 302 90d;
proxy_cache_valid any 5m;
proxy_ignore_headers Cache-Control Expires;
proxy_cache_lock on;
add_header X-Cache $upstream_cache_status;
}
}
メディア用プロキシのサブドメインのSSL証明書を取得する
先ほどs3っていうホスト名のサブドメイン作ったのでSSL証明書が必要ですね。
今回はcertbotのnginxプラグインで一発で取得しちゃいます。
yourdomainは各自のドメインにしてね。
sudo certbot –nginx -d s3.yourdomain
それで成功したならば、sudo nginx -tで確認してsudo systemctl reload nginxで反映
新建一个目录并进行传递的情况;
这次将从https://实例的域名/storage目录进行传递;
不必使用名为storage的字符串,只要它尚未被misskey使用即可;
目前传递是从https://实例的域名/files进行的,现在将进行更改;
mkdir /var/cache/nginx/proxy_cache_images
chown -R nginx: /var/cache/nginx/proxy_cache_images在misskey的Nginx文件中进行以下追加:
首先是在server指令之外的部分
/etc/nginx/sites-available/misskey.conf
proxy_cache_path /var/cache/nginx/proxy_cache_images levels=1 keys_zone=images:2m max_size=20g inactive=90d;
其次是在server目录内部的部分
/etc/nginx/sites-available/misskey.conf
location /storage/ {
limit_except GET {
deny all;
}
try_files $uri $uri/ @proxy;
resolver 1.1.1.1 valid=100s;
proxy_pass https://bucket_name.ewr1.vultrobjects.com/; #如果是新加坡,则不是ewr1而是sgp1
proxy_buffering on;
proxy_redirect off;
proxy_http_version 1.1;
proxy_set_header Host bucket_name.ewr1.vultrobjects.com; #如果是新加坡,则不是ewr1而是sgp1
tcp_nodelay on;
expires max;
proxy_hide_header etag;
proxy_hide_header Set-Cookie;
proxy_ignore_headers Set-Cookie;
proxy_set_header cookie “”;
proxy_cache images;
proxy_cache_valid 200 302 90d;
proxy_cache_valid any 5m;
proxy_ignore_headers Cache-Control Expires;
proxy_cache_lock on;
add_header X-Cache $upstream_cache_status;
}
如果保存了这个文件,就可以使用 “sudo nginx -t” 来确认配置文件是否正确,如果正确的话,就可以使用 “sudo systemctl reload nginx” 来重新加载 Nginx。
编辑Nginx的systemd服务文件。
尝试在启动Nginx之前添加一个等待网络连接的步骤,确保可以正常连接到upstream。这样可以解决服务重启后Nginx启动失败的问题。
systemctl edit --full nginx.service
打开Nginx服务文件后,在[Service]中。
Restart=always
RestartSec=5
请追加以下内容:
如果可以的话,请确认使用”systemctl status nginx”命令时没有出现错误。
此设置在Nginx进程因某种原因而崩溃时,将等待5秒然后重新启动。
这样可以等待连接到互联网,从而在多次重新启动之后成功地启动。
编辑misskey的设置文件。
misskey v10的設定文件可以按以下步驟編輯,但從misskey v11開始,可以通過設定界面進行編輯。請根據以下設定值進行替換yourbacketname、youraccesskey和yoursecretkey為個別的值。如果prefix設置為/storage以作為對象存儲代理的傳送目錄,其他人則設置為misskey、dev或m544等。如果不想添加任何內容,您可以通過調整Nginx的配置來實現。如果您要從新的子域名發布,請將yourdomain設置為該域名;如果要創建新目錄進行發布,請將yourdomain設置為實例的域名。由於這裡設置的baseUrl會反映到聯盟伺服器上,所以在部署到正式環境之前,請仔細檢查。
#drive: #コメントアウト
# storage: 'fs' #コメントアウト
drive:
storage: 'minio'
bucket: yourbacketname
prefix: storage
baseUrl: https://yourdomain
config:
endPoint: sgp1.vultrobjects.com #ニュージャージーならewr1
useSSL: true
accessKey: youraccesskey
secretKey: yoursecretkey
setPublicRead: false
s3ForcePathStyle: true
如果没有问题,切换回sudo用户,使用sudo systemctl restart misskey重新启动并应用配置文件。如果出现错误,则可以使用sudo journalctl -u misskey -f等命令来确认错误内容。同时尝试在浏览器中打开misskey,并试着将一张图片上传到云端,如果可以看到该图片,则表示一切正常。如果无法显示,则可能存在某些错误,需要重新检查步骤并右键点击上传的图片的缩略图,在新标签页中打开并确认URL是否为https://s3.yourdomain/storage或https://yourdomain/storage。