Mettre à niveau son serveur Ubuntu 14.04 LTS vers une version supérieure

Les cycles de sorties d’Ubuntu

La fin du support des mises à jour pour la version 14.04 LTS a été annoncé par Canonical, éditeur de la distribution Ubuntu, à partir du 30 avril 2019. Les versions LTS (Long Term Support) de la distribution Ubuntu sont particulièrement adaptées aux serveurs de productions, celles-ci sont stables et disposent de mises à jour sur le long terme (5 ans). Ces versions estampillées LTS sortent tous les deux ans, la dernière en date est la 18.04, publiée le 26 avril 2018 et dont la fin de vie est annoncée en avril 2023.

Il est important d’effectuer ces mises à jour, un serveur ne doit pas se trouver sans support de mises à jour, principalement pour des raisons de sécurité. Ainsi, si votre serveur est aujourd’hui en version 14.04, ou en version inférieure, il est conseillé de faire la mise à jour sur une version supérieure, encore supportée par Canonical. Il faudra à minima effectuer la mise à jour vers la version 16.04 dont la date de fin de vie est annoncée en avril 2021, voire une version plus récente comme la 18.04.

Vous pouvez retrouver toutes les informations concernant les cycles des distributions estampillées LTS à l’adresse (EN) https://wiki.ubuntu.com/LTS ou (FR) https://doc.ubuntu-fr.org/lts.

Avant de mettre à niveau

Les manipulations de mise à niveau ne sont pas complexes en tant que telles, le réel danger lors d’une telle opération est de casser le bon fonctionnement des logiciels et bibliothèques utilisés par vos applicatifs. Lors de la mise à jour de la distribution vers une version supérieure, il y a toujours un risque d’incompatibilité d’un fichier de configuration ou d’un langage.

Par exemple, la version Ubuntu 18.04 ne propose plus le paquet php5.6 dans les dépôts officiels mais le paquet php7.x, or il est possible que votre applicatif codé en PHP ne supporte que la version PHP 5.6. Dans ce cas, il faudra s’assurer de mettre à jour le code de l’applicatif pour supporter la nouvelle version (solution conseillée), ou bien de réinstaller le paquet php5.6 depuis un dépôt tiers (fonctionnel, mais déconseillé). Les risques sont multiples et nous verrons dans ce tutoriel comment procéder pour les limiter au maximum lors de la migration.

La virtualisation offerte par l’offre Cloud nous permettra notamment de procéder étape par étape, en validant systématiquement le bon fonctionnement des applicatifs. Ce tutoriel couvrira un cas général car il est impossible de détailler la migration de tous les services et configurations possibles. Nous vous donnerons les bonnes pratiques à suivre pour une migration maîtrisée, en utilisant les fonctionnalités offertes par l’offre Cloud.

Vérifier la version actuelle de son serveur

Pour vérifier la version actuelle utilisée par votre serveur, il suffira d’exécuter la commande suivante :

root@serveur:# lsb_release -a

Si la version retournée est inférieure ou égale à la 14.04, alors il est vivement conseillé de migrer, mais globalement, vous devriez faire la migration si la version est inférieure à la 16.04.

Notez que la migration d’un serveur avec plusieurs services installés dessus n’est pas nécessairement la meilleure solution, il peut parfois être préférable de créer un nouveau serveur dans une distribution récente et de reconfigurer les différents services directement sur cette nouvelle version. Le fait de pouvoir attacher et détacher un disque vous facilitera grandement la migration des données de l’ancien serveur vers le nouveau.

Les prérequis

Avant de vous lancer dans la migration du ou des serveurs, nous vous conseillons de bien la préparer en listant les différents programmes qui fonctionnent sur le serveur et les dépendances que vous utilisez. Cela peut être une version de langage, d’un logiciel …

Avant de procéder à la mise à jour, vous pourrez alors vérifier la version de certains paquets fournis par la distribution en vous rendant à l’adresse suivante https://packages.ubuntu.com/fr/

Pour effectuer la migration, nous vous conseillons d’utiliser les snapshots afin de faire une image du disque système avant tout changement sur la distribution. Le snapshot permettra également de créer un nouveau serveur à partir de celui-ci. Cela permettra de procéder à la migration sur un serveur identique à celui qui doit être mis à niveau, sans affecter le serveur en production. Notez que ce serveur aura une nouvelle adresse IP, et qu’il faudra potentiellement dupliquer les autres disques pour les attacher au nouveau serveur. Une fois la migration terminée, il sera alors nécessaire de détacher l’adresse IP de l’ancien serveur pour la rattacher au nouveau serveur et d’effectuer une manipulation pour que l’adresse IP soit prises en compte. Il sera nécessaire de créer le nouveau serveur sur le même centre de donnée que l’ancien afin d’utiliser le snapshot crée depuis l’ancien serveur.

La mise à jour

Une fois le nouveau serveur crée à partir du snapshot, connectez-vous dessus en tant que root, afin d’effectuer des actions d’administration. Canonical préconise l’utilisation de la commande do-release-upgrade pour effectuer la migration. En exécutant cette commande, le système ira chercher la prochaine version LTS d’Ubuntu par rapport à celle actuellement utilisée. Ainsi, si la version utilisée est la 14.04, alors la mise à jour sera effectuée vers la 16.O4.

Vous pouvez vérifier vers quelle version sera effectuée la mise à jour avec la commande do-release-upgrade -c. Puis, pour lancer la mise à jour exécutez la commande do-release-upgrade :

root@serveur:#do-release-upgrade

Une fois la mise à jour terminée, vous pouvez vérifier le bon fonctionnement des services dans la plupart des cas. Vous pouvez modifier le fichier hosts de votre poste client afin de faire pointer le ou les domaines habituellement utilisés vers l’adresse IP du nouveau serveur. Cela permettra de tester localement la réponse du serveur sans avoir à modifier les enregistrements DNS des domaines utilisés en production, très utile à des fins de tests (n’oubliez pas de supprimer les lignes ajoutées dans le fichier `hosts` par la suite).

Une fois testé et vérifié, vous pourrez recommencer la même procédure pour passer en version 18.04.

Mise en production

Si la mise à jour s’est passée sans erreurs et que tous vos services sont fonctionnels, vous pouvez passer ce serveur en production. Il suffira de réaffecter l’interface réseau de l’ancien serveur vers le nouveau et de démarrer dessus. Avant de procéder au détachement et rattachement de l’interface, vous devrez modifier les fichiers :

• /etc/default/gandi : supprimez la valeur eth0 de la directive NO_DHCP, tel que

NO_DHCP=""

• /etc/network/interfaces remplacez la configuration réseau de l’interface eth0 par :

auto eth0

iface eth0 inet dhcp

Ces modifications sont nécessaires afin que l’adresse IP que nous allons rattacher soit prise en compte lors du démarrage du serveur. Vous pouvez maintenant arrêter l’ancien et le nouveau serveur, puis détacher les interfaces réseaux de chacun d’eux. Enfin, rattacher l’interface réseau alloué à l’ancien serveur au nouveau, puis démarrez-le. Tous vos services devraient être fonctionnels sur le nouveau serveur.

Dépannage

Dans le cas où le serveur ne répond plus après le démarrage, vous pouvez activer la console d’urgence afin de vous connecter en SSH et vérifier l’origine du problème.

Si le serveur ne démarre plus, vous avez également la possibilité de définir le kernel “ramdisk-rescue” qui aura pour effet de démarrer un système Linux en chargé en RAM. Une fois démarré, vous pourrez monter le disque système et effectuer un chroot sur le disque système :

• On monte le disque système sur un répertoire

# mkdir /mnt/chroot

# mount /dev/xvda1 /mnt/chroot

• On monte les pseudos systèmes de fichiers :

# mount -t sysfs /sys /mnt/chroot/sys

# mount --bind /dev /mnt/chroot/dev

# mount -t proc /proc /mnt/chroot/proc

Puis on passe en chroot via la commande chroot /mnt/chroot. Les commandes exécutées dans le chroot s’appliqueront au système comme si vous aviez démarré le serveur normalement.