之前由于总是在纠结如何有效存储喵窝的数据,虽然每一张图片并不大,但是当数量累积起来的时候就会形成一种相当恐怖的灾难情形。默认自然是存储在运行主站的服务器上,但是由于那边还要存储数据库(和莫名其妙快速增大的log表),为了防止用户图片数据的丢失、降低主站的数据开销,考虑到Misskey支持配置外部存储,于是就给之前的接入了IPv6的BuyVM配了一个512G的存储盘,并使用docker启动了一个minio实例。但是这一次我上传一些将近1G的文件的时候,后端出现了非常频繁的报错,为了解决相关的问题,我找了不少资料,修正了之前nginx上配置不够详尽导致的意外情况。现将我的一些记录整理如下,以方便各位读者(包括未来的我自己)的参考,与之后可能会有的后续维护工作。
首先是docker的启动脚本,由于方便后续更新与维护,我使用了 docker compose 进行配置。
docker-compose.yml1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
| version: "3" services: minio: image: minio/minio container_name: restart: unless-stopped environment: MINIO_ACCESS_KEY: MINIO_SECRET_KEY: command: server /data volumes: - /storage/minio/data:/data - /storage/minio/config:/root/.minio ports: - "127.0.0.1:9000:9000" restart: always healthcheck: test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"] interval: 30s timeout: 20s retries: 3
|
之后就是最重要的内容:设置nginx反向代理。
由于原来是走Cloudflare的,而Cloudflare有限制上传请求的文件最大大小(免费版为100MB),过大的文件会直接报 413 错误拒绝上传,所以只剩下直连上传这一条路了。但同时也需要修改nginx中相关的超时、限制选项,以避免在网关层出现莫名的限制导致错误。
附上一份整理完成的nginx配置,其中关闭了上传文件的体积限制,并将超时时间均设置为了3600秒,以避免因为文件过大、上传缓慢导致的连接关闭。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
| upstream minio { server 127.0.0.1:9000; }
server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name # 您的服务器名(域名) ## SSL ssl_certificate # 您的证书公钥 ssl_certificate_key # 您的证书密钥
client_max_body_size 0;
## reverse proxy location / { proxy_pass http://minio; proxy_send_timeout 3600; proxy_read_timeout 3600; send_timeout 3600; include conf.d/shared/revproxy.conf; }
}
|
然后一切就绪,docker-compose up -d
启动minio,nginx -s reload
重载nginx的配置即可。minio基本兼容AWS S3的API,因而可以直接用于替代。
顺带整理路上发现了一个价格实惠的存储服务商Wasabi(山葵),当之后数据量累积到一定的时候,就选择这些专业的存储机构吧。