Dealing with servers running out-of-LTS versions of Ubuntu

Overview

If one or more of the servers in your application are running older versions of Ubuntu that are no longer covered by long term support (LTS) and have thus reached end-of-life (EOL), you will receive periodic warnings from Cloud 66 about this. This guide explains why you’re getting these warnings, and what you can do to remedy the cause.

Understanding LTS and EOL

Free versions of Ubuntu are supported by Canonical for 5 years after their initial release - hence the label “long term support”. This means that a version released in 2018 (i.e. 18.04) is no longer eligible for support as of April 2023 and effectively becomes EOL.

At this point Canonical stops actively releasing updates and patches to that version of Ubuntu. Some package maintainers will patch older versions of their software, but many will drop support as the respective versions of Ubuntu reach EOL.

This means that your server and its packages are no longer able to be patched with any degree of certainty, including urgent security patches.

How Cloud 66 handles EOL versions of Ubuntu

Our first priority is to keep your application running and not to make any changes that might cause downtime. As such we will stop making any passive updates to your version of Ubuntu once it is out of LTS, including package upgrades or patches.

We will begin warning you as soon as one or more of your servers running a version of Ubuntu reaches EOL. We strongly urge you to upgrade to a later LTS release (ideally the latest) at this point, since we can’t guarantee the security of your server if it remains unpatched.

How to fix this issue

There are two ways to approach upgrading Ubuntu, each with different pros and cons:

Scaling up new servers in your existing application (running the new versions of Ubuntu and any version-dependent components) and then scaling down old servers.
Cloning your existing application to a new set of servers and switching your DNS once you have tested this new version thoroughly

Method	Pros	Cons
Scaling up new servers in your existing application, and then scaling down outdated ones	- Quicker, with less configuration changes required	- Ideal if only a few components need to be upgraded
Cloning your entire application and then upgrading all the components	- Lower risk, with all the configuration changes and testing happening in a “sandbox” until you’re ready to cut over	- More time consuming

Upgrade one layer at a time

Whenever possible we suggest upgrading your stack one layer at a time - for example focus on upgrading all your databases and then move on to your application servers.

Before you start the process

Check the Manifest for your application to ensure you haven’t specified a version of Ubuntu in any of your component configurations. Either remove any mention of operating system version, or update to a version of Ubuntu that is still in LTS.
Check both your Manifest and your other configuration or package dependency files (e.g. Gemfile or package.json) and confirm that the package versions are compatible with the latest version of Ubuntu. Where they are not, update the versions to achieve compatibility.
Replication is generally not possible between different (minor and major) versions of database engines. If your new servers will need to use a significantly different version of the engine, you will need to upgrade manually - see our section below.
We strongly advise you to test a version of your application locally on the same version of Ubuntu that will be deployed.

How to upgrade Ubuntu using the app cloning method

Once you are ready, you can upgrade your version of Ubuntu as follows:

Log into your Dashboard
(Optional but recommended) Set up a Failover Group for the application you’re planning to upgrade
Click through to the application
Click on Settings in the left-hand nav
Scroll down to Application Actions and click the Clone button
Give the new version of your application a name and click Clone Application
Follow the build process to analyze and configure your application for deployment
Deploy the clone to the cloud of your choice - the servers will automatically be provisioned with the latest LTS version of Ubuntu (or the version specified in your Manifest)
Set up database replication between your existing application and your clone
Test your cloned application thoroughly
Once you are satisfied, switch your Failover Group to point at the cloned application
Deactivate database replication and promote your replica database on the clone to master

You now have a fully upgraded version of your application, and you can delete your old version of your application and the servers it relied on.

How to upgrade databases between versions

Replication is generally not possible between different (minor and major) versions of database engines. In order to upgrade between versions you will need to:

Dump or export the data from your existing database
Add a new database group that uses the new version of your database engine
Manually import the database dump (or snapshot) to the new database group
Examine the database (using command line or a database client) to check the data has been imported successfully
Switch your application servers to use the new database group

Depending on the size of your database you may need to import an initial large dump and then import the latest records just before you cut over.