💾 Archived View for ebc.li › posts › server-migration.gmi captured on 2022-01-08 at 13:51:08. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
2020-10-21
I have messed around with my server again, so this post is now out of date. Might still be interesting to some people, though.
So, I finished re-deploying my server two hours or so ago, and it took ~7 hours.
The main motivation behind "this" was because I wanted a reproducible-ish config behind my server for MONTHS, and just a couple days ago started working on one.
First of all, I did the sensible thing of creating a VM and experimenting on that, which isn't usually what I do, but since I wanted this to be reproducible, testing on a VM and making it work "for real" with the same (or similar) configuration just felt like the best choice.
The VM was originally Debian bullseye, because that's what ISO I had lying around, but a couple days later I switched to Debian buster, because that's what I planned on running on the server. This switch also helped with me testing the configuration again from scratch, making sure it didn't depend on anything I installed by hand on the first VM. It also found a lot of compatibility issues I had to fix, so that's nice.
I scheduled¹ today² to the "migration" and stopped for the day.
It took ~3 hours for the initial configuration to apply, and for me to migrate the data over from the previous server³. With ~1 hour to fix "Mastodon being Mastodon" and some dumb things I did that didn't get tested beforehand⁴.
After getting Mastodon working, which was my "end goal" because the rest "just works" most of the time, I decided to try out something I didn't really try before, which was "Object Storage"
Object storage is basically "really cheap storage". It's actually a little more detailed than that but that's what you're getting from me at 4 AM (UTC+3)
I was mainly interested in trying it out because my server only has 20 GBs of storage, and the old server got to somewhere around 10-13 GBs full. I don't recall any specific "storage hog", but Mastodon's tendency to proxy remote media, it's system folder becoming ~2 GBs⁵, and it being the only service I have running that supports object storage made it the prime candidate to test it out on.
So I did. I enabled the "object storage" service from my VPS provider⁶ and messed around with my Nginx configuration until it worked⁷, and set up Mastodon via the following guide that's still not merged into Mastodon's documentation:
Migrate assets to S3 (tootsuite/documentation#809)
It was running on my Mastodon instance at toot.ebc.li, and hopefully it won't blow up any time soon.
1: Well, I didn't have anything important anyway.
2: 20th of October, which might be considered "yesterday" depending on how you interpret time, also relative to this post's release
3: I didn't keep track of the timeline any more detailed than a now deleted thread, and the migration did happen while I was waiting for other parts of the playbook to run.
4: My testing environment doesn't allow connection from the "outside world", so I couldn't generate SSL certs for it without more hassle than I cared about. This also prevented me from testing Mastodon, because it kept wanting to be served over SSL.
5: I am not entirely sure, but I might have skipped setting up some cron jobs that could have kept it lower than it was. I wish I could check but that server's gone now.
6: It's Linode. I probably could find a cheaper service specifically for that, but I already have all my payment stuff set-up to pay them monthly, so why not?
7: `proxy_pass` does not work properly with a trailing slash and that was probably an hour down the drain.
🐺 · CC BY-SA 4.0 · me@ecmelberk.com