New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Yes
I usually install the latest Ubuntu LTS version when setting up a new server. Then, once it gets close to end-of-life (about 5 years later), I set up a new server, install the latest new LTS release, and migrate the project over.
In my experience, doing a clean install is much simpler and more predictable than trying to upgrade an old system through several OS versions. You can also take your time and make sure everything works properly before switching over.
Over those 5 years, hardware usually improves too. You’ll probably be able to find better specs for the same price, so it's a good opportunity to refresh both the software and the hardware at the same time.
I do the same with my home Linux machines - clean reinstall every 5 years. Keeps things tidy and manageable.
migrate and rebuild ftw
i redeploy
This is solid, I just need to do stuff once in 5 years
It's not a question that can be answered simply because it totally depends on what you are upgrading.
For myself, with a dozen or so reverse proxies, when things need an update I use ansible. The playbook talks to my control panel API for the DNS, takes them out of rotation, waits, upgrades server 1, brings it back in, and so on. But that is a relatively stateless application and a separate service manages resyncing their database if it gets updated while one of the servers is rebooting. And there are different processes for upgrading control panel, orchestration infrastructure, etc.
For something with a database, you could setup a new instance of your app with its database as a replica, then switch the DNS and eventually turn off the old instance. But upgrades of applications have even more nuances, how to deal with schema changes with multiple version of the app running simultaneously (as they do a rolling release). There's a reason people go to school to learn this kind of stuff.
This only scratches the surface.
That's why I use containers inside K8s
We have a strict ‘if it ain’t broke, don’t fix it’ policy
Please understand that this is a joke.
Ansible seems good. Can practice on some nodes before rolling out to all
Sound promising
If you're going the route of containers and K8s then K3s, (aka Lightweight Kubernetes), is well worth a look because it's K8s compatible and runs on lowend hardware like Raspberry Pis and oversold LET nodes: https://k3s.io
As others have suggested, it would be easiest to redeploy. Starting fresh would allow you to not need to play catch-up and just get back to operations.
For future reason, if your on Debian, I have had perfect luck with
unattended-upgrades, which by default will only auto-upgrade security packages (but can be configured for more).Regarding Docker, depending on your setup it might work perfect; I have my blog running with Docker (on Crun) and watchtower auto-upgrades every update smoothly.
I'm just putting K8s inside AWS lightsail instances (can be single node if required), this way we can pull out worker nodes from cluster and upgrade them and reattach them back to cluster.
Don't update the current server. At EOL, get a new server, install the latest LTS and updates, and migrate your project over. Then, decommission the old server.
Repeat every time EOL comes around.