Serveurs dédiés Ubuntu

Un serveur dédié Ubuntu est une machine physique mono-locataire qui exécute Ubuntu Server directement sur le matériel — aucune couche de virtualisation entre votre charge de travail et le CPU, la mémoire et le NVMe. Vous disposez d’un accès root complet, de tous les cœurs et de performances prévisibles, plutôt que d’une simple fraction d’un hôte partagé.

Ubuntu est le Linux serveur le plus largement déployé, ce qui en fait précisément le choix par défaut le plus sûr : la plus grande base de paquets, une automatisation cloud-init de premier ordre et le plus vaste réservoir de tutoriels, d’images et de support amont pour Docker, Kubernetes et pratiquement tout runtime que vous pourriez déployer.

Vous comparez les distributions ? Consultez notre guide des serveurs dédiés Linux.

Les versions LTS et la cadence de publication

Ubuntu publie une version Long Term Support (LTS) tous les deux ans, en avril des années paires, avec des versions intermédiaires tous les six mois entre-temps. Pour un serveur, vous voulez presque toujours une LTS : cinq ans de maintenance de sécurité standard, étendus à dix ans avec Ubuntu Pro, et jusqu’à douze ans avec l’add-on payant Legacy Support superposé à Pro.

Nous provisionnons par défaut la LTS actuelle et la précédente, afin que vous puissiez standardiser un parc sur une version et vous y tenir tout au long de sa fenêtre de support, plutôt que d’être poussé vers une cible mouvante. Si vous avez besoin d’une version intermédiaire pour un noyau ou un userland plus récent, elle est disponible sur demande.

Lorsque vous êtes prêt à passer d’une LTS à une autre, do-release-upgrade gère le saut sur place ; comme vous disposez d’un accès root complet et d’une console KVM, c’est vous qui pilotez la mise à niveau — ou une réinstallation propre sur la nouvelle LTS — selon votre propre calendrier, sans verrouillage de version et sans rien d’imposé de notre côté.

Ubuntu Pro, ESM et Livepatch

Ubuntu Pro étend la couverture de sécurité au-delà du dépôt « main » vers l’ensemble bien plus vaste « universe », et ajoute Livepatch pour appliquer les CVE critiques du noyau sans redémarrer — utile lorsque la disponibilité d’un hôte bare metal compte. Canonical propose Pro gratuitement pour un usage personnel et à petite échelle ; les parcs commerciaux y attachent un abonnement.

Parce que vous disposez d’un accès root complet sur une machine Serverside, vous êtes libre d’attacher votre propre token Ubuntu Pro, d’utiliser Landscape ou de gérer entièrement le patching vous-même — nous ne verrouillons pas l’OS.

Démarrez votre propre Ubuntu avec un iPXE personnalisé

Vous n’êtes pas limité à nos images de série. Les configurations iPXE personnalisées vous permettent de chaîner le démarrage de votre propre build Ubuntu ou d’un noyau personnalisé directement sur le métal, de sorte que la machine démarre exactement l’image que vous avez validée.

Le même chemin peut faire tourner Ubuntu entièrement en mémoire — un root sans disque, uniquement en RAM, qui laisse le NVMe local libre pour les données ou effacé à chaque démarrage. C’est l’expression la plus forte du même principe : nous vous remettons le matériel et restons en dehors de la chaîne de démarrage.

apt et snap : ce que vous exécutez réellement

Ubuntu repose sur dpkg/apt, et c’est là que vit la grande majorité des logiciels serveur. Ubuntu embarque aussi snap, le format de packaging confiné de Canonical, que certains opérateurs serveur préfèrent pour les daemons auto-mis à jour et que d’autres désactivent pour garder une base minimale.

Sur un serveur dédié, le choix vous revient entièrement : conservez snapd, retirez-le, ou épinglez tout sur apt. Rien dans notre provisioning n’en dépend.

Ce que les équipes font tourner sur Ubuntu bare metal

L’ubiquité d’Ubuntu en fait la voie de moindre résistance, en particulier pour les charges de travail conteneurisées et orchestrées — les images Docker et Kubernetes officielles, les runtimes et les runners CI le ciblent tous en premier.

• Hôtes de conteneurs et nœuds Kubernetes (kubeadm, k3s, RKE2) qui veulent du CPU et du NVMe bruts sans la taxe d’un hyperviseur
• Couches web et API à haut débit où l’uplink complet et la mitigation DDoS incluse comptent
• Bases de données et caches auto-hébergés (PostgreSQL, MySQL, Redis) sur NVMe local
• Runners CI/CD et fermes de build qui consomment des cœurs en continu
• Serveurs de jeu et vocaux — nos profils DDoS sont réglés par titre pour les jeux hébergés sur notre réseau

Sécuriser un serveur Ubuntu

La couche de contrôle d’accès obligatoire par défaut d’Ubuntu est AppArmor (et non SELinux), livrée activée avec des profils pour les daemons courants et généralement plus simple à appréhender.

Avant même que le trafic n’atteigne la pile de l’hôte, notre mitigation DDoS en self-service et la gestion des règles de pare-feu le filtrent à la périphérie du réseau. Cela vous donne une défense en couches : un filtrage au niveau réseau que vous contrôlez en amont, avec ufw et AppArmor qui appliquent la politique sur la machine elle-même. Le réseau privé virtuel entre vos serveurs maintient le trafic est-ouest — réplication de base de données, communication de nœud à nœud Kubernetes — entièrement hors de l’interface publique.

Une base de départ raisonnable sur une machine Serverside neuve :

• Activez unattended-upgrades pour que les correctifs de sécurité s’appliquent automatiquement
• Verrouillez SSH : authentification par clé uniquement, pas de connexion root par mot de passe, et notre filtrage au niveau réseau en amont
• Activez ufw et n’exposez que les ports dont votre charge de travail a besoin
• Gardez AppArmor en mode enforce ; ajoutez des profils pour tout élément personnalisé
• Ajoutez Ubuntu Pro + Livepatch si vous avez besoin d’une couverture des CVE noyau sans redémarrage