Choisir une image Ubuntu pour votre VPS

Écrire les critères avant de commander

Listez versions d’Ubuntu, langages, bases de données et architectures acceptées par l’application. Incluez extensions natives, agents de supervision et outils de restauration. Distinguez le support officiel de vos propres essais.

1. Recensez les versions et architectures de tous les composants.
2. Écartez les images sans durée de maintenance adaptée.
3. Confirmez l’image et l’architecture dans la région du fournisseur.
4. Vérifiez la machine livrée avec les commandes ci-dessous.
5. Testez les fonctions réelles avant tout transfert de données ou de trafic.

Ubuntu 24.04 a introduit Python 3.12 par défaut, PHP 8.3 et PostgreSQL 16. Les versions correctives évoluent. Une application compatible avec des versions majeures précédentes ne l’est pas automatiquement avec celles-ci. Consultez les durées de maintenance LTS.

Identifier le système reçu

Dans la session distante, ces commandes en lecture seule indiquent distribution, noyau, architecture des paquets et architecture machine :

cat /etc/os-release
uname -r
dpkg --print-architecture
uname -m

Faites défiler le tableau pour voir toutes les colonnes →

Le noyau ne suffit pas à identifier le support du système entier. N’attendez pas qu’un binaire amd64 fonctionne nativement sur arm64 sans version adaptée ou alternative prise en charge.

Comprendre l’initialisation de l’image

De nombreuses images utilisent cloud-init pour créer utilisateurs, clés et réseau. Vérifiez d’abord sa présence ; son absence ne prouve pas une panne si le fournisseur utilise une autre méthode.

if command -v cloud-init >/dev/null 2>&1; then
    cloud-init status --long
else
    printf '%s\n' 'cloud-init est absent ; vérifiez la méthode de préparation de cette image.'
fi

Un état running signifie que la préparation continue. Un état dégradé ou en erreur doit être compris même si SSH fonctionne. Lorsque cloud-init est installé, examinez les journaux :

sudo tail -n 50 /var/log/cloud-init.log
sudo tail -n 50 /var/log/cloud-init-output.log

Masquez les secrets avant de partager ces fichiers. Ne lancez pas cloud-init clean et ne remplacez pas le réseau uniquement pour faire disparaître une erreur. Une initialisation terminée ne valide pas la santé de l’application.

Examiner les versions candidates et leurs dépôts

Actualisez les index puis regardez les paquets nécessaires. apt update ne réalise pas ici leur installation. Les paquets avec numéro de version complètent la lecture des métapaquets.

sudo apt update
apt-cache policy python3 php postgresql
apt-cache policy python3.12 php8.3 postgresql-16

Installed: (none) indique l’absence du paquet ; Candidate: (none) indique qu’aucune version n’est proposée par les sources configurées. Vérifiez nom, architecture et composants Ubuntu avant d’ajouter un dépôt quelconque.

Pour un logiciel installé, contrôlez aussi le binaire ou le service réellement utilisé : python3 --version et php --version renseignent les exécutables correspondants. La version du client d’une base de données peut différer de celle du serveur.

Exemple : deux incompatibilités indépendantes

Supposons une application limitée à Python 3.10 avec une extension native uniquement amd64. Une image Ubuntu 24.04 arm64 échoue sur deux points : Python par défaut est 3.12 et l’extension cible une autre architecture.

Passer à amd64 résout l’architecture, pas la version de Python. Un environnement virtuel isole des paquets avec l’interpréteur qui l’a créé ; il ne transforme pas Python 3.12 en 3.10. Ne remplacez pas le Python système d’Ubuntu.

Envisagez une évolution de l’application ou un environnement maintenu séparément, avec un plan de support. Une ancienne version d’Ubuntu n’est pas une correction automatique : son horizon de maintenance compte aussi.

Dans un environnement de test, utilisez réellement l’extension, une opération de base de données, une tâche de fond et une restauration. Une page d’accueil qui répond n’exerce qu’une petite partie du système.

Inclure conteneurs et maintenance des composants

Un conteneur isole des dépendances mais repose sur le noyau, le réseau et le stockage de l’hôte. Vérifiez la disponibilité d’une image native. L’émulation change les performances et les conditions de support.

Gardez les données persistantes dans des volumes identifiés ou un stockage externe. Fixez versions ou empreintes d’images pour reproduire le déploiement tout en planifiant leurs mises à jour. Une image figée vulnérable reste vulnérable.

La maintenance standard Ubuntu, Ubuntu Pro, les dépôts tiers et les images de conteneurs n’ont pas tous le même périmètre. Notez qui met à jour chaque couche.

Séparer mises à jour et changement de version Ubuntu

Après actualisation des index, listez les mises à jour, les services en échec et un éventuel besoin de redémarrage. Ces commandes ne lancent pas une migration de distribution.

apt list --upgradable
systemctl --failed
if [ -f /var/run/reboot-required ]; then cat /var/run/reboot-required; fi

Appliquez les mises à jour pendant une période adaptée puis refaites les tests. Un service peut redémarrer ; l’absence du marqueur reboot-required ne prouve pas que chaque composant est à jour.

Testez une montée de version Ubuntu sur une copie ou une nouvelle machine. Vérifiez dépôts, extensions et migration des bases. Prévoyez une synchronisation finale et un retour arrière tenant compte des nouvelles écritures : un snapshot ancien ne contient pas les commandes clients arrivées depuis.

Conserver une fiche reproductible

Faites défiler le tableau pour voir toutes les colonnes →

Versionnez la configuration non secrète. Pour une image adaptée, poursuivez avec le déploiement HTTPS. Pour un essai public éligible, consultez la création d’une VM Ubuntu Oracle.

Questions et réponses