Comment un service informatique doit-il choisir une distribution Linux standard?

Il existe de nombreux points de vue de la communauté sur les distributions Linux appropriées pour les environnements de serveurs de production et qui ne le sont pas. Cependant, une grande partie de ce sentiment semble être basée sur la religion et rarement présentée avec des preuves à l'appui.

En supposant que nous essayions de sélectionner une distribution Linux à normaliser (parce que nous souhaitons garder nos environnements aussi homogènes que possible), quels critères sont importants et comment déterminez-vous si différentes distributions répondent à ces critères?

Je travaille actuellement dans un environnement qui utilise Linux depuis plus de dix ans. Tout le monde au bureau utilise différentes distributions sur leurs ordinateurs de bureau ainsi que sur les serveurs. En tant que tels, les choix de distribution tendent à tourner autour d’un certain nombre de choses sans ordre particulier:

1. Historique - Il est évident que des systèmes tels que RedHat et Debian existent depuis longtemps. En tant que tel, l'adage "si ce n'est pas cassé, ne le corrige pas" peut être utilisé pour ceux-ci. La mise à niveau devient plus facile si le logiciel est bien pris en charge sur une distribution.
2. Familiarité - Semblable à l’Histoire, nous avons cependant tous nos favoris. Je me suis mordu à Debian et j'ai migré vers Ubuntu (une décision difficile à prendre à l'époque car j'ai tendance à m'engager dans une communauté). Inversement, il est pénible de devoir se rappeler comment faire les choses sur une douzaine de distributions différentes (sans compter celles qui ont été construites à partir de zéro).
3. Support - J'ai migré vers Ubuntu principalement parce que j'appréciais leur travail en termes d'assistance technique payante. C’était un argument de vente si jamais un client s’inquiétait de la gestion à long terme d’un système. Similaire à l'approche de RedHat (mais l'enfer se déroulait à l'époque). Nous avons également un certain nombre de serveurs RedHat.
4. Dépendances - Certains logiciels sont plus faciles à utiliser sur certaines distributions simplement parce que les paquetages dépendants sont plus faciles à obtenir ou à construire. Comme exemple de ceci serait Ovirt sur RedHat. Il n'y a pas de paquets pour certains logiciels sur certaines distributions. Et vous pourriez le compiler, mais pourquoi le feriez-vous si le paquet était là sur une autre distribution?
5. Granularité - Les Distros comme Gentoo offrent un contrôle plus fin sur la gestion des versions et des commutateurs logiciels. D'autres distributions ont «épinglé» sous différentes formes, mais ce n'est toujours pas aussi contrôlable ou fiable.
6. Liaison - Bien qu'il soit possible de compiler à partir de la source sur la plupart des distributions, certaines sont meilleures que d'autres. Cela peut avoir un effet, par exemple, si votre projet corrige des bibliothèques existantes pour une fonctionnalité étendue.
7. Jolie - Certaines distributions sont simplement plus jolies. Chaque geek sait que ce n'est que du fluff (et vous pourriez probablement vous en tirer comme une application web de nos jours), mais certains clients sont impressionnés par ce truc, et nous le savons tous.
8. Stabilité - Certaines distributions diffusent des versions "stables" du logiciel par opposition à "tester", "expérimental", etc. Cela peut vouloir dire beaucoup si vous savez que la version sur laquelle vous construisez finira par atteindre un consensus sur la stabilité. Vous pouvez développer "expérimental" en sachant que lorsque votre projet sera terminé, il sera "stable" et il sera bon de s'y fier.
9. Gestion des packages - Si vous développez quelque chose tous les jours et que plusieurs milliers de machines y sont associées en un coup, vous voulez probablement quelque chose qui facilite la création, la maintenance et le suivi des packages sur ces systèmes.
10. Cohérence - C'est plus un argument pour la même distribution. Moins d'erreurs sont commises (et moins d'erreurs de sécurité) lorsque les utilisateurs peuvent se concentrer sur une distribution au lieu de plusieurs.
11. Calendrier de publication prévisible - Si vous voulez être sûr que votre logiciel reste pris en charge, les mises à niveau planifiées offrent un certain type de stabilité.
12. Sécurité - Certaines distributions ont des équipes de sécurité actives dont le rôle est de réagir immédiatement aux risques de sécurité réels dans les packages approuvés.

Ce ne sont là que quelques-unes des choses qui me viennent à l’esprit en ce qui concerne les raisons pour lesquelles chaque système a été choisi. Je ne vois aucune direction ou préférence d'une distribution par rapport à une autre dans cette décision. La diversité et le choix peuvent être formidables et vous offrir de très bonnes options pour démarrer rapidement un projet, mais c’est aussi le nœud coulant qui peut vous pendre. Assurez-vous de penser à ce dont vous aurez besoin. Planifiez quels sont les besoins du système ainsi que le moment où le système va être mis à niveau ou mis à jour. Ne présumez pas que vous serez toujours celui qui le maintient.

Je partagerai mes expériences en tant que technologue dans différents domaines ...

(Attention: ceci est une histoire à propos de Red Hat et de la manière dont j'ai grandi professionnellement avec.)

J'ai commencé à travailler avec Linux de manière professionnelle en 2000-2002. C'était lors de l'adoption à grande échelle de Red Hat et des éditions professionnelles Red Hat (6.x, 7.x, 8.0) . Ceux-ci étaient disponibles en téléchargement gratuit ainsi que des ensembles emballés dans une boîte. Ils pourraient facilement être trouvés dans les magasins d'informatique.

Pour moi, cela a eu l'avantage d'engager les amateurs et les utilisateurs à domicile avec le même produit qui commençait à émerger dans l'entreprise. Mon travail à ce moment-là consistait à déplacer les systèmes de serveur client des Unices commerciaux (HP-UX, AIX et SCO) vers la plate-forme Red Hat.

Les économies de coûts étaient substantielles! Remplacer des serveurs PA-RISC à plus de 100 000 dollars par HP9000 par des serveurs Intel Compaq ProLiant à 40 000 dollars représentait un gain absolu en termes de coût et de performances.

Alors, pourquoi Red Hat?

Red Hat a été le premier sur ce marché, obtenant un support matériel, commercial et commercial crucial. Voir de grands fournisseurs d’applications utiliser Red Hat comme plate-forme cible a scellé l’accord. Les utilisateurs amateurs comme moi ont pu transférer facilement les compétences acquises à la maison dans notre environnement de travail. La communauté grandissait. Slashdot , Freshmeat et LAMP empilées ! C'était un bon moment pour Linux.

À ce stade, j'étais responsable du développement et de l'évaluation des distributions Linux en tant que plate-forme pour une solution logicielle ERP propriétaire. J'ai collé avec Red Hat. De temps en temps, j'essayais une autre distribution ( Mandrake , SuSE , Debian , Gentoo ), mais je trouvais des problèmes avec le packaging, le support matériel (serveurs ou périphériques), la communauté (taille de la) ou un autre deal-breaker.

Un exemple: j'utilisais du matériel Compaq / HP ProLiant équipé de cartes PCI-X d'extension Digi Serial et du logiciel de télécopie de production Esker VSIfax . Ces deux derniers ne prenaient en charge les pilotes que pour les systèmes d'exploitation Red Hat. Dans certains cas, les logiciels n'étaient livrés que sous forme binaire ou sous forme de RPM, ce qui excluait une utilisation facile sur d'autres variantes de Linux.

Le momentum compte dans le monde des technologies de l'information
Personne ne veut être quelqu'un qui recommande la solution ou le projet perdant qui finit par devenir orphelin, vous devez donc choisir des solutions sûres. Je gérais une pile de technologies qui devait fonctionner de manière fiable et bénéficier de plusieurs niveaux de support. Choisir une distribution différente à ce stade aurait tout simplement. été. irresponsable.

La lune de miel Red Hat s’est terminée pour moi en 2003 avec l’ arrêt des éditions professionnelles du logiciel. Red Hat Enterprise Linux était le remplaçant et est venu avec pas mal de bagages ... Coût (modèle basé sur un abonnement coûteux), accessibilité (réduction de la base d'utilisateurs et de la communauté) et confusion générale pour l'avenir ...

J'ai commencé à chercher des alternatives, en réévaluant Gentoo, Debian et SuSE. Je ne pouvais pas obtenir le support adéquat sur tous les composants de notre pile technologique. J'étais obligé de rester dans l'écosystème Red Hat ... En raison du coût extrêmement élevé associé à Red Hat Enterprise Linux, j'ai finalement utilisé une version hautement modifiée de Red Hat 8.0 pendant des années après sa fin de vie. Ce n’est que lorsque les clones RHEL ont mûri ( Whitebox Linux et plus tard CentOS ) que j’ai préparé un véritable abandon de mon standard.

Le principal avantage des produits dérivés Red Hat était et reste la compatibilité binaire avec les versions payantes de RHEL. Il est même possible d'effectuer des conversions sur place entre RHEL et CentOS, et inversement. J'ai continué à travailler avec des systèmes RHEL-comme jusqu'à ce que je fasse le prochain changement de carrière ...

Je me suis ensuite retrouvé dans le secteur du trading financier à haute fréquence , où j'étais responsable de la R & D et de l'ingénierie Linux pour les systèmes de trading automatisés critiques. Dans ce monde, l’accent était mis sur la rapidité , au moyen de tests et de réglages minutieux. Encore une fois, le support matériel était la clé. J'aurais des cartes réseau spécifiques , du matériel spécialisé, du matériel de serveur ou des bibliothèques d’applications certifiées uniquement pour les systèmes RHEL ou similaires. Même dans les cas où des choses pourraient être compilées pour d’autres variantes de Linux, le facteur communauté s’est manifesté. Au moment où j’étais sur le point de rechercher un problème, c’était souvent un problème qui pouvait être attribué à des notes ou des commentaires dans les rapports Red Hat Bugzilla, ou parfois, je soumettais simplement un correctif ou une demande pour la version suivante. .

Alors que je commençais à explorer les réseaux et le réglage du noyau à faible latence, j'ai commencé à disséquer les noyaux RHEL et les noyaux RHEL MRG Realtime . J'ai remarqué combien de travail avait lieu dans les versions ... plus de 200 correctifs pour un noyau vanilla kernel.org. Lisez les commentaires et validez les notes. Vous pouvez avoir de petites choses comme des sysctlparamètres exposés ou des valeurs par défaut plus saines appliquées. Red Hat paie les utilisateurs pour corriger, tester et résoudre ces problèmes. Je ne voyais pas le même engagement de la part des autres distributions Linux ... Ajoutez à cela que la plate-forme de l'entreprise est assurée d'avoir une réelle prise en charge de la sécurité, des corrections de bogues et des backports pendant des années .

Alors, j'ai finalement déménagé dans une autre société financière qui était presque entièrement Gentoo sur le serveur et le bureau ... C'était un désastre pour moi. Venant du monde Red Hat et CentOS, j'ai rencontré de nombreux problèmes de stabilité et de gestion avec l'installation de Gentoo. Le contrôle des versions était le principal problème, mais la diminution du soutien de la communauté et le manque de tests réels étaient également des préoccupations. J'ai commencé à introduire RHEL dans l'environnement car certains de nos logiciels tiers en avaient besoin ...

Mais il y avait un problème ... Mes développeurs étaient habitués à Gentoo et disposaient de chemins de mises à niveau relativement faciles pour les bibliothèques principales et les versions d'application. Ils ne pouvaient pas s'adapter aux versions majeures corrigées sur lesquelles Red Hat Enterprise Linux est normalisé. Le processus de développement et de publication comportait de nombreuses questions sur les raisons pour lesquelles GLIBC 2.7 ne pouvait pas être greffé sur RHEL 5.x ou sur la raison pour laquelle un certain compilateur ou une version de la bibliothèque n’était pas disponible. Lorsqu'elles ont appris que les mises à niveau entre les versions principales de RHEL / CentOS nécessitaient essentiellement une reconstruction complète , elles ont perdu beaucoup de confiance en la solution.

À ce stade, je me suis rendu compte que Red Hat progressait beaucoup trop lentement pour les développeurs qui souhaitaient être à la pointe du progrès. RHEL 6.x était une mise à niveau indispensable et bienvenue, mais ce thème est devenu plus évident lorsque j'ai commencé à interviewer des startups et des entreprises souscrivant aux principes de DevOps .

Aujourd'hui ...
Un nombre croissant de développeurs et d'utilisateurs Linux proviennent d'environnements Linux non Red Hat, non SuSE et non professionnels.

• Ils utilisent Ubuntu ou Debian ...
• Ils n'avaient pas à faire face à du matériel de la vieille école ou à un support important.
• Ils écrivent leurs propres applications à partir de la base (auto-soutenu).
• La virtualisation et l'informatique en nuage font l'abstraction de la couche matérielle, de sorte que les inquiétudes concernant les pilotes de contrôleur RAID géniaux, les périphériques PCI-X ou les agents de gestion distribués binaires ne sont même pas sur le radar.
• Ces utilisateurs veulent les outils et le pays utilisateur auxquels ils sont habitués.

Il y a donc un conflit ... Ces utilisateurs ne comprennent pas pourquoi ils seraient limités aux versions d'applications ou de bibliothèques. Les administrateurs de la vieille école sont encore en train de s’adapter au nouveau paradigme . Les arguments qui semblent être enracinés dans la religion ne sont en réalité que des fonctions de la façon dont les gens ont développé leurs compétences respectives.

J'ai vu aujourd'hui une offre d'emploi pour un très haut poste d'ingénieur DevOps Linux qui se lisait comme suit:

Doit être compétent en expert sur les distributions Linux basées sur Debian (Ubuntu et ses variantes, d'accord. Red Hat est passable , mais non préféré).

Donc, je suppose que cela fonctionne dans les deux sens ... Je me suis éloigné des possibilités d'emploi car les serveurs 800 CentOS que je gérerais devaient être convertis à Ubuntu. Bien sûr, Linux, c’est Linux ... mais je ne pensais pas être aussi efficace que possible. J’ai fouillé avec les installations de Debian et souhaité qu’une distribution basée sur RPM soit utilisée. J'ai eu de vives discussions sur les mérites de différentes plateformes (plaçant généralement Gentoo au bas de la liste).

Alors, qu'est-ce qui convient à VOTRE environnement? Ça dépend. J'ai été dans des entreprises où les ingénieurs systèmes prennent les décisions, ainsi que dans des organisations où les développeurs sont les maîtres mots. Je pense que le meilleur arrangement est quand les développeurs et les personnes supportant les systèmes s'accordent sur la plateforme. Mais en dehors de cela, pensez au support à long terme, à la convivialité, à la communauté et aux solutions adaptées à votre pile d'applications de la manière la plus appropriée.

Un développeur talentueux devrait être capable de travailler dans un environnement semblable à RHEL ou à Debian. Et bien, les plates-formes de développement devraient refléter l'environnement de production. Vous partez de là ...