I should probably upgrade my website hosting Ubuntu version. It's a small VM at Hetzner.

First thing that occurs to me for continuity of service is:

1. set up new VM with up to date OS
2. port everything over and test
3. repoint DNS
4. delete old box

But how did you approach this?

@davidgerard basically the same way? I wouldn't bother with an inline upgrade, tear down and move site by site?

@davidgerard I'm not sure, but I believe Hetzner potentially allows you to clone a VPS. If they do that seems like the easiest way.

@davidgerard

If it’s just static website files (html, image, JavaScript) I’d stick it in an s3 bucket, and let cloudfront serve it. Very cheap, simple, low hassle

Otherwise, I’d probably snapshot the box, run all the apt updates and then test -> rather than starting over

Engine that we get into a very deep infrastructure as code rabbit hole and overengineer

@davidgerard For a relatively simple site that can tolerate a short period of downtime, I would usually just do a dist-upgrade (in-place Debian upgrade). IDK how reliable those are on Ubuntu servers but on Debian they work very well.

If you're in the habit of "reinstall the OS" style upgrades, you would ideally be using some infrastructure-as-code approach so that the "install new system" part is "run the automated installation and then check all is working". I have a few systems that I manage that way.

And, finally: not an answer to your question, but folks in this thread who haven't seen it might like to read about the skip-skip-cross-up-grade I did to chiark a couple of years ago.

@davidgerard how did I approach it? Generally by using rolling release systems, or faking it by using nixos-unstable and openbsd-current

@davidgerard Re testing, I suggest you make a list (bookmark folder? page-o-links?) of URLs that you can quickly click through. Include things that maybe work differently or that you don't look at as frequently (dunno, maybe signup page? reports?) Then verify that they all work on the existing site first (you'd be surprised).

@davidgerard

1. Set up new VM with up to date OS
2. Port half of everything over
3. Oh look, a squirrel!
4. Pay for 2 VPSs for the next several years…

@davidgerard Did this recently to move from AWS to OVH. Docker was pretty useful for this. My websites are docker-composed using the nginx-proxy and let’s encrypt images, and built using Makefiles. So copy the files across, run “make”, docker compose and that part is pretty much done.

I altered my local DNS config and put some fake entries for the new IPs for testing purposes. I dropped my DNS TTL as low as feasible (say, 1 minute). When happy, I updated DNS to the new IPs and waited a bit.

@davidgerard Yes, I've used that approach frequently. It's a good step up from YOLO in prod without getting into real devops / IaC shit

One thing you may run into is stuff in your application / config that refers to real domain, e.g. wordpress database references pivot-to-ai.com, so it's broken when your testing on the new vm, or you end up pulling images from the old site without noticing. Tracking those when you set it up will help avoid surprises when you switch the domain over

@Diziet lol i remember this post at the time 😄

skip-upgrades are a bad idea on ubuntu, but a chain of lts->lts->lts *probably* will work