Serveurs dédiés RHEL

Un serveur dédié RHEL est une machine physique mono-locataire qui exécute Red Hat Enterprise Linux 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 la plateforme certifiée et adossée à un support contre laquelle sont écrits les logiciels d’entreprise et les régimes de conformité.

RHEL est licencié par abonnement plutôt que vendu au forfait, si bien que le modèle sur bare metal est le bring-your-own : vous attachez votre entitlement Red Hat existant à la machine. Si vous voulez la plateforme RHEL sans abonnement, AlmaLinux et Rocky Linux sont des rebuilds libres et compatibles RHEL que nous provisionnons sans frais — les mêmes binaires, sans la relation de support avec l’éditeur.

Vous pesez RHEL face aux rebuilds gratuits ? Consultez notre guide des serveurs dédiés Linux.

Comment un abonnement RHEL s’attache à un serveur physique

RHEL n’est pas un achat unique — le logiciel est habilité par un abonnement Red Hat, et c’est cet abonnement qui vous procure des errata certifiés, un SLA de support et l’accès au cycle de vie supporté. Sur une machine Serverside, vous apportez le vôtre : nous déployons l’OS et vous remettons le root, puis vous enregistrez la machine auprès de votre organisation Red Hat et elle commence à tirer les mises à jour depuis le CDN de Red Hat.

L’enregistrement tient en une seule commande — subscription-manager register avec votre organisation ID et une activation key — après quoi le système est habilité. Le modèle actuel de Red Hat est le Simple Content Access (SCA), aujourd’hui le défaut pour les comptes : une fois qu’un système est enregistré, il a accès au contenu sans étape d’attachement explicite, si bien que l’ancienne manœuvre subscription-manager attach est désormais sans effet. Notez qu’activer le SCA sur une organisation est un changement à sens unique.

Vous n’êtes pas limité à nos images : montez votre propre ISO d’installation RHEL et pilotez l’installation vous-même depuis la console KVM, en regardant l’installateur graphique ou texte démarrer exactement comme sur une machine devant vous. C’est la voie propre lorsque vous voulez agencer la machine selon votre propre kickstart ou votre standard de partitionnement avant d’attacher votre abonnement Red Hat — apportez votre propre installateur, apportez votre propre entitlement.

Chaque entitlement est lié à un système, si bien qu’un hôte bare metal consomme un abonnement pour la machine physique quel que soit son nombre de cœurs — une machine EPYC dense ne coûte pas plus à habiliter qu’une petite. Comme vous disposez d’un accès root complet et que le serveur est non infogéré par défaut, la manière dont vous l’enregistrez, les dépôts que vous activez et la façon dont vous patchez sont entièrement de votre ressort.

Versions actuelles et cycle de vie de dix ans

RHEL 10 est la version majeure actuelle, disponible depuis mai 2025 et bâtie sur un noyau et une chaîne d’outils modernes. RHEL 9 reste en Full Support jusqu’en 2027 avec une maintenance jusqu’en 2032, et RHEL 8 est dans sa phase de Maintenance jusqu’en 2029 — les trois sont donc des cibles viables selon ce contre quoi votre stack applicative est certifiée.

Chaque majeure de RHEL bénéficie d’un cycle de vie de dix ans : environ cinq ans de Full Support (nouvelles fonctionnalités et prise en charge du matériel), puis cinq ans de Maintenance Support (correctifs de sécurité et de bugs urgents sur la dernière mineure), suivis d’une phase optionnelle d’Extended Life. Cette fenêtre décennale et prévisible est l’une des raisons pour lesquelles les charges de travail réglementées et durables se standardisent sur RHEL plutôt que sur une distribution qui évolue plus vite.

Si vous devez vous figer sur une version mineure précise — parce qu’un ISV certifie uniquement contre, disons, RHEL 9.4 — l’Extended Update Support (EUS) maintient une mineure donnée patchée pendant 24 mois, et le flux E4S orienté SAP porte cela à quatre ans. Ces options s’appuient sur votre abonnement ; le matériel en dessous est la même machine que nous déployons en moins d’une minute.

RHEL, AlmaLinux et Rocky après le changement de sources de 2023

À la mi-2023, Red Hat a fait de CentOS Stream le seul dépôt public pour le code source lié à RHEL, mettant fin à la pratique antérieure de publication des sources par version sur git.centos.org. Les clients payants de Red Hat reçoivent toujours l’intégralité des sources RHEL via le Customer Portal ; le changement a spécifiquement touché les rebuilds downstream qui s’appuyaient sur ces sources publiques pour produire des copies binaires 1:1.

Les deux grands rebuilds communautaires ont réagi différemment. AlmaLinux a déplacé son objectif du « 1:1 bug-for-bug » vers la compatibilité d’interface binaire applicative (ABI) — les logiciels certifiés pour RHEL continuent de tourner, mais Alma ne promet plus des paquets identiques au byte près. Rocky Linux, dont les soutiens ont contribué à former l’Open Enterprise Linux Association (OpenELA) avec Oracle et SUSE, continue de viser une compatibilité RHEL bug-for-bug, via des sources obtenues par OpenELA. Les deux sont gratuits, et nous provisionnons l’un ou l’autre sans frais.

Pour la plupart des charges de travail auto-supportées, un rebuild est le choix pragmatique : vous obtenez la plateforme et l’écosystème RHEL sans abonnement. Vous vous tournez vers le vrai RHEL lorsque la relation de support, les errata certifiés ou l’aval de l’éditeur sont l’objectif même — ce qui fait précisément l’objet de la section suivante.

Quand le RHEL payant l’emporte sur un rebuild gratuit — et quand non

Les rebuilds sont compatibles binairement, si bien que le facteur décisif est rarement le logiciel lui-même — c’est la paperasse et la relation avec l’éditeur qui l’entoure. Le vrai RHEL justifie son abonnement lorsqu’un tiers est engagé :

• Certification ISV : SAP, Oracle Database et une grande partie du middleware commercial sont certifiés et supportés uniquement sur RHEL (ou ses variantes SAP/E4S), et les éditeurs peuvent refuser de faire du dépannage sur un rebuild
• Régimes de conformité qui imposent un OS supporté, adossé à un éditeur, avec un SLA et des errata traçables
• Certification matérielle et plateforme, où un serveur ou un accélérateur précis est validé contre RHEL
• Gestion de parc via Red Hat Lightspeed (anciennement Insights) et Satellite pour la visibilité sur les vulnérabilités, le patching et la dérive à grande échelle
• À l’inverse : pour une couche web auto-hébergée, des hôtes de conteneurs, des runners CI ou de l’outillage interne, AlmaLinux ou Rocky vous donnent la même plateforme gratuitement — aucun abonnement à suivre, un renouvellement de moins

SELinux en mode enforcing par défaut

RHEL est livré avec SELinux en mode enforcing d’emblée — un contrôle d’accès obligatoire qui confine les processus à une politique étiquetée, si bien qu’un daemon compromis est enfermé dans ce que son type est autorisé à toucher plutôt que d’hériter des droits de l’appelant. Sur Debian et Ubuntu, la couche équivalente est AppArmor ; sur RHEL, SELinux est la posture native et par défaut, et les politiques de l’écosystème supposent qu’il est activé.

Sur un serveur dédié, cela signifie opérationnellement qu’il faut consacrer du temps au réglage des contextes et des booléens plutôt que de le passer par réflexe en permissive : étiquetez correctement vos répertoires de données (restorecon, semanage fcontext), activez les sebooleans pertinents pour des services comme httpd ou les conteneurs, et lisez le journal d’audit (ausearch, sealert) quand quelque chose est refusé. Laisser SELinux en enforcing explique en grande partie pourquoi RHEL est de confiance dans les environnements réglementés, il vaut donc la peine de le garder activé.

Segmentez le réseau comme un audit l’attend

SELinux confine les processus sur l’hôte ; la couche réseau confine ce qui peut les atteindre, et les entreprises sous RHEL ont généralement besoin des deux. Vous pouvez placer vos serveurs sur un réseau privé entre les machines et exploiter un véritable déploiement multi-tier — la couche applicative dialoguant avec la couche base de données sur l’interface privée, avec une interface publique uniquement sur le front-end qui doit faire face aux utilisateurs. La base de données n’a jamais besoin de porter d’adresse publique.

Pour une segmentation dictée par la conformité, vous pouvez définir votre propre DMZ réseau : n’exposez que la couche qui doit être joignable et gardez les systèmes internes isolés derrière elle, ce qui est précisément la topologie qu’un auditeur s’attend à voir documentée lorsque votre charge de travail porte des obligations PCI, HIPAA ou similaires. Comme vous définissez vous-même la segmentation, la frontière suit vos contrôles plutôt qu’un réglage par défaut partagé du fournisseur.

Outillage natif RHEL

La surface de gestion au quotidien est la stack Red Hat que vous attendez, et tout cela fonctionne de la même façon sur le vrai RHEL ou un rebuild :

• dnf et RPM pour la gestion des paquets et des transactions, avec la modularité et les application streams
• kpatch, le live kernel patching pour appliquer les CVE critiques du noyau sans redémarrer — supporté depuis RHEL 8.1 — qui va bien avec un hôte bare metal à longue disponibilité
• Image Builder (osbuild) pour produire des images d’OS personnalisées reproductibles à redéployer sur tout un parc
• Red Hat Lightspeed et Satellite (fonctionnalités d’abonnement) pour les advisories, l’orchestration du patching et le déploiement de kpatch à grande échelle
• System roles et contenu Ansible pour une configuration reproductible sur une machine qui est à vous de bout en bout