Original link: https://blog.fivest.one/archives/6429
This guide applies to——
- Self-built mastodon (non-big station)
- use docker compose
- Save media files directly on the server without using s3 external storage
Although this combination is rare, it is actually quite cool to use. The s3 service used by many people is to squeeze wool, and the perverted mastodon caches other people’s media files to its own architecture. Easily exceeded. On the contrary, the traffic limit of vps itself is very high. For personal website building, the total amount of media files is usually <50GB, and some VPSs come with a 200GB hard disk, which is enough.
The disadvantage is that, in addition to regular database backups, off-site backups of media files must also be considered. But in fact, only the media_attachments that store local attachments need to be backed up, and the cache does not need to be backed up, so the workload is not too big.
When I transferred the media files to the local two years ago, I referred to the settings of antisocial science . But because I use docker, the official default setting, the internal and external permissions of docker are inconsistent, and media files cannot be written locally. So I hastily built a minio s3 locally to transfer… This is actually a waste of resources, and the overhead of minio is not small. So recently, while moving, I tried again, and finally managed to run docker + local storage.
1. In docker-compose.yml,
In the web and sidekiq containers, volume mapping for media files has been preset
volumes:
- ./public/system:/mastodon/public/system
Don’t move this one. (It can also be changed to other paths, but it must be consistent with the subsequent settings.
2. Modify .env.production
S3_ENABLED=false
PAPERCLIP_ROOT_PATH=/mastodon/public/system
PAPERCLIP_ROOT_URL=/fivestone-mastodon-media
The default value of PAPERCLIP_ROOT_URL is /system; but it is recommended to change it to a unique name, and it is recommended to be consistent with S3_BUCKET. Save yourself a little headache later when you need to switch between local storage and s3. (So be unique, to prevent you from colliding with others on s3)
3. Modify the domain name configuration file of nginx
Referring to the official configuration , change the proxy_pass in the domain name folder directly to the local alias
server { server_name mastodon.fivest.one; # ...... location /fivestone-mastodon-media/ { alias /path-to...docker-compose-folder/public/system/ ; proxy_cache CACHE; proxy_cache_valid 200 48h; proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504; proxy_cache_lock on; expires 1y; add_header Cache-Control public; add_header 'Access-Control-Allow-Origin' '*'; add_header X-Cache-Status $upstream_cache_status; add_header X-Content-Type-Options nosniff; add_header Content-Security-Policy "default-src 'none'; form-action 'none'"; } }
Then restart nginx
sudo systemctl reload nginx.service
4. Set the permissions of the media folder through docker
Inside docker, the program is run as mastodon user, so change the owner of the media folder to mastodon (inside docker):
sudo docker-compose run --user=root --rm web chown -R mastodon /mastodon/public/system
If you are migrating from s3 to local, after moving the media files into this local folder (/path-to…docker-compose-folder/public/system/), execute the above command again.
This article is transferred from: https://blog.fivest.one/archives/6429
This site is only for collection, and the copyright belongs to the original author.