Wie sollte eine IT-Abteilung eine Standard-Linux-Distribution auswählen?

Es gibt viele Community-Meinungen darüber, welche Linux-Distributionen für Produktionsserver-Umgebungen geeignet sind und welche nicht. Viele dieser Meinungen scheinen jedoch religiös begründet zu sein und werden selten mit unterstützenden Beweisen präsentiert.

Angenommen, wir haben versucht, eine Linux-Distribution für die Standardisierung auszuwählen (weil wir daran interessiert sind, unsere Umgebungen so homogen wie möglich zu halten), welche Kriterien sind wichtig und wie bestimmen Sie, wie gut verschiedene Distributionen diese Kriterien erfüllen?

Ich arbeite derzeit in einer Umgebung, in der Linux seit mehr als einem Jahrzehnt verwendet wird. Jeder im Büro verwendet unterschiedliche Distributionen auf seinen Desktops sowie auf den Servern. Daher drehen sich die Verteilungsentscheidungen in der Regel um eine Reihe von Dingen ohne bestimmte Reihenfolge:

1. Geschichte - Offensichtlich gibt es Systeme wie RedHat und Debian schon lange. Als solches kann das Sprichwort "Wenn es nicht kaputt ist, repariere es nicht" für diese verwendet werden. Ein Upgrade wird einfacher, wenn die Software von einer Distribution gut unterstützt wird.
2. Vertrautheit - Ähnlich wie in der Geschichte, jedoch haben wir alle unsere Favoriten. Ich habe meine Zähne auf Debian geschnitten und bin zu Ubuntu gewechselt (eine schwere Entscheidung zu der Zeit, weil ich dazu neige, mich für eine Community zu engagieren). Umgekehrt ist es eine Qual, sich zu merken, wie man Dinge in einem Dutzend verschiedener Distributionen macht (ganz zu schweigen von den selbstgebauten).
3. Support - Ich bin zu Ubuntu gewechselt, hauptsächlich, weil ich ihre Arbeit als bezahlter Support sehr geschätzt habe. Das war ein Verkaufsargument, wenn jemals ein Kunde Bedenken hatte, ein System langfristig zu betreiben. Ähnlich wie bei RedHat (aber die RPM-Hölle war zu der Zeit los). Aus diesem Grund haben wir auch eine Reihe von RedHat-Servern.
4. Abhängigkeiten - Einige Softwareprogramme sind auf manchen Distributionen einfacher zu verwenden, da die abhängigen Pakete einfacher zu beziehen oder zu erstellen sind. Ein Beispiel dafür wäre oVirt on RedHat. Auf einigen Distributionen gibt es keine Pakete für einige Software. Und du könntest es kompilieren, aber warum würdest du es tun, wenn das Paket in einer anderen Distribution stünde?
5. Granularität - Distros wie Gentoo bieten eine genauere Kontrolle über die Versionierung und die Granularität von Software-Switches. Andere Distributionen "pinnen" in verschiedenen Formen, aber das ist immer noch nicht so kontrollierbar oder zuverlässig.
6. Bindung - Während es in den meisten Distributionen möglich ist, aus dem Quellcode zu kompilieren, sind einige Distributionen besser darin als andere. Dies kann sich beispielsweise auswirken, wenn in Ihrem Projekt vorhandene Bibliotheken für erweiterte Funktionen gepatcht werden.
7. Hübsch - Einige Distributionen sehen einfach besser aus. Jeder Geek weiß, dass es nur Flaum ist (und Sie könnten es heutzutage wahrscheinlich als Web-App durchstehen), aber einige Kunden sind von diesem Zeug begeistert, und wir alle wissen es.
8. Stabilität - Einige Distributionen streamen "stabile" Versionen von Software im Gegensatz zu "Testen", "Experimentieren" usw. Dies kann eine Menge bedeuten, wenn Sie wissen, dass die Version, auf der Sie aufbauen, irgendwann einen Konsens über die Stabilität erzielen wird. Sie können auf "experimentell" entwickeln, wenn Sie wissen, dass Ihr Projekt zum Zeitpunkt seines Abschlusses "stabil" ist und Sie sich darauf verlassen können.
9. Paketverwaltung - Wenn Sie täglich etwas entwickeln und es mit einem Schlag Tausende von Computern geben wird, dann möchten Sie wahrscheinlich etwas, das die Erstellung, Wartung und Nachverfolgung von Paketen auf diesen Systemen vereinfacht.
10. Konsistenz - Dies ist eher ein Argument für dieselbe Distribution. Es werden weniger Fehler gemacht (und weniger Fehler in der Sicherheit), wenn sich die Leute auf eine Distribution konzentrieren können, anstatt auf mehrere.
11. Vorhersehbarer Release-Zeitplan - Wenn Sie sicherstellen möchten, dass Ihre Software weiterhin unterstützt wird, bieten geplante Upgrades eine gewisse Stabilität.
12. Sicherheit - Einige Distributionen verfügen über aktive Sicherheitsteams, deren Aufgabe es ist, in genehmigten Paketen sofort auf echte Sicherheitsrisiken zu reagieren.

Dies sind nur ein paar Dinge, die mir im Hinblick auf die Gründe, warum jedes System ausgewählt wurde, auf den Kopf fallen. Ich sehe in dieser Entscheidung kein richtungsweisendes Licht oder keine Bevorzugung einer Distribution gegenüber einer anderen. Vielfalt und Auswahl können großartig sein und Ihnen einige wirklich gute Optionen bieten, um ein Projekt schnell zu starten, aber es ist auch die Schlinge, die Sie hängen kann. Stellen Sie sicher, dass Sie vorausdenken, was Sie brauchen werden. Planen Sie die Anforderungen des Systems sowie den Zeitpunkt, zu dem das System aktualisiert oder ausgemustert wird. Gehen Sie nicht davon aus, dass Sie immer derjenige sind, der es verwaltet.

Ich werde meine Erfahrungen als Technologe in verschiedenen Bereichen teilen ...

(Achtung: Dies ist eine Geschichte über Red Hat und wie ich beruflich damit aufgewachsen bin.)

Ich habe 2000-2002 angefangen, professionell mit Linux zu arbeiten. Dies geschah während der weiten Verbreitung von Red Hat und der Red Hat Professional Edition (6.x, 7.x, 8.0) . Diese standen zum kostenlosen Download zur Verfügung sowie verpackte Sets. Sie könnten leicht in Computer-Einzelhandelsgeschäften gefunden werden.

Für mich hatte dies den Vorteil, Hobby- und Privatanwender mit demselben Produkt zu begeistern, das sich im Unternehmen abzeichnete. Zu dieser Zeit bestand meine Aufgabe darin, Kundenserversysteme von kommerziellen Unices (HP-UX, AIX und SCO) auf die Red Hat-Plattform zu verlagern.

Die Kosteneinsparungen waren erheblich! Das Ersetzen von HP9000 PA-RISC-Servern im Wert von über 100.000 US-Dollar durch Compaq ProLiant Intel-Server im Wert von über 40.000 US-Dollar war ein absoluter Gewinn in Bezug auf Kosten und Leistung.

Warum also Red Hat?

Red Hat war der erste auf diesem Markt, der entscheidenden Support für Unternehmen, Anbieter und Hardware erhielt. Die Tatsache, dass große Anbieter von Anwendungen Red Hat als Zielplattform verwenden, besiegelte das Geschäft. Hobbyanwender wie ich konnten die zu Hause erarbeiteten Fähigkeiten problemlos auf unsere Arbeitsumgebung übertragen. Die Community wuchs. Slashdot , Freshmeat und LAMP Stacks entschieden! Es war eine gute Zeit für Linux.

Zu diesem Zeitpunkt war ich für die Entwicklung und Evaluierung von Linux-Distributionen als Plattform für eine proprietäre ERP-Softwarelösung verantwortlich. Ich bin bei Red Hat geblieben. Hin und wieder versuchte ich es mit einer anderen Distribution ( Mandrake , SuSE , Debian , Gentoo ), fand jedoch Probleme mit der Verpackung, dem Hardware-Support (Server oder Peripheriegeräte), der (Größe der) Community oder einem anderen Deal-Breaker.

Ein Beispiel: Ich habe Compaq / HP ProLiant-Hardware verwendet, die mit PCI-X-Erweiterungskarten von Digi Serial und der Esker VSIfax-Produktionsfaxsoftware ausgestattet ist . Die beiden letzteren hatten nur Treiberunterstützung für Red Hat-Betriebssysteme. In einigen Fällen wurde Software nur in Binär- oder RPM-Form geliefert, was die einfache Verwendung in anderen Linux-Varianten ausschließt.

Momentum zählt in der Welt der Informationstechnologie
Niemand möchte jemand sein, der die Lösung oder das Projekt empfiehlt, die bzw. das irgendwann verwaist wird, sodass Sie bei sicheren Entscheidungen bleiben. Ich verwaltete einen Technologie-Stack, der zuverlässig arbeiten und mehrere Unterstützungsebenen haben musste. Zu diesem Zeitpunkt eine andere Verteilung zu wählen, hätte genau das getan. gewesen. unverantwortlich.

Die Red Hat-Flitterwochen endeten für mich 2003 mit der Einstellung der Professional-Editionen der Software. Red Hat Enterprise Linux war der Ersatz und brachte einiges an Gepäck mit ... Kosten (teures abonnementbasiertes Modell), Zugänglichkeit (Verringerung der Benutzerbasis und der Community) und allgemeine Verwirrung über die Zukunft ...

Ich fing an, nach Alternativen zu suchen und Gentoo, Debian und SuSE neu zu bewerten. Ich konnte nicht für alle Komponenten unseres Technologie-Stacks den richtigen Support erhalten. Ich wurde mit dem Red Hat Ökosystem bleiben gezwungen ... Aufgrund der wilden Kostenverschiebung im Zusammenhang mit Red Hat Enterprise Linux, beenden ich eine sehr modifizierte Red Hat 8.0 für angerannt Jahre über seine End-of-life. Erst als die RHEL-Klone ausgereift waren ( Whitebox Linux und später CentOS ), bereitete ich eine echte Abkehr von meinem Standard vor.

Der Hauptvorteil von Red Hat-Derivaten war und ist die Binärkompatibilität mit den kostenpflichtigen RHEL-Versionen. Es ist sogar möglich, direkte Konvertierungen zwischen RHEL und CentOS durchzuführen und umgekehrt. Ich arbeitete weiter mit RHEL-ähnlichen Systemen, bis ich den nächsten Karriereschritt machte ...

Später war ich in der Hochfrequenz-Finanzhandelsbranche tätig, wo ich für die Entwicklung und das Linux-Engineering kritischer automatisierter Handelssysteme verantwortlich war. Der Schwerpunkt in dieser Welt lag auf der Geschwindigkeit durch sorgfältiges Testen und Einstellen. Auch hier war die Hardware-Unterstützung der Schlüssel. Ich hätte spezielle Netzwerkkarten , spezielle Hardware, Serverhardware oder Anwendungsbibliotheken, die nur für RHEL oder RHEL-ähnliche Systeme zertifiziert wurden. Sogar in Fällen, in denen Dinge für andere Linux-Varianten kompiliert werden konnten, trat der Community-Faktor auf. Wenn ich an dem Punkt angelangt war, an dem ich ein Problem untersuchen musste, war es häufig ein Problem, das auf Notizen oder Kommentare in Red Hat Bugzilla-Berichten zurückzuführen war, oder manchmal reichte ich einfach einen Patch oder eine Anforderung für die nächste Version ein .

Als ich anfing, mich mit Netzwerken mit geringer Latenz und der Optimierung des Kernels zu befassen, begann ich, die gängigen RHEL-Kernel und RHEL MRG Realtime- Kernel zu analysieren. Mir ist aufgefallen, wie viel Arbeit in den Releases steckt ... über 200 Patches für einen Vanillekernel.org-Kernel. Lesen Sie die Kommentare und machen Sie sich Notizen. Möglicherweise werden kleine Dinge wie sysctlParameter angezeigt oder vernünftigere Standardeinstellungen angewendet. Red Hat bezahlt die Leute für das Patchen, Testen und Beheben dieser Probleme. Ich habe nicht das gleiche Engagement von anderen Linux-Distributionen gesehen ... Füge die Tatsache hinzu, dass die Unternehmensplattform jahrelang echte Sicherheit, Bugfix und Backport-Unterstützung bietet .

Also bin ich irgendwann zu einer anderen Finanzfirma gewechselt, die auf dem Server und auf dem Desktop fast nur Gentoo anbietet ... Es war eine Katastrophe für mich. Aus der Red Hat- und CentOS-Welt kommend stieß ich beim Gentoo-Setup auf zahlreiche Stabilitäts- und Verwaltungsprobleme. Die Versionskontrolle war das größte Problem, aber auch die schwindende Unterstützung durch die Community und der Mangel an echten Tests waren bedenklich. Ich begann RHEL in die Umgebung einzuführen, weil einige unserer Software von Drittanbietern dies erforderten ...

Aber es gab ein Problem ... Meine Entwickler waren an Gentoo gewöhnt und hatten relativ einfache Upgrade-Pfade für Kernbibliotheken und Anwendungsversionen. Sie konnten sich nicht auf die festen Hauptversionen einstellen, auf denen Red Hat Enterprise Linux standardisiert ist. Der Entwicklungs- und Veröffentlichungsprozess war mit Fragen behaftet, warum GLIBC 2.7 nicht auf RHEL 5.x gepfropft werden konnte oder warum eine bestimmte Compiler- oder Bibliotheksversion nicht verfügbar war. Als ihnen mitgeteilt wurde, dass Upgrades zwischen Hauptversionen von RHEL / CentOS im Wesentlichen vollständige Neuerstellungen erforderten , verloren sie viel Vertrauen in die Lösung.

Zu diesem Zeitpunkt wurde mir klar, dass Red Hat für Entwickler, die am Puls der Zeit sein wollten, viel zu langsam war. RHEL 6.x war ein dringend benötigtes und willkommenes Upgrade, aber dieses Thema wurde offensichtlicher, als ich mit Startups und Firmen, die DevOps-Prinzipien abonniert hatten, begann, ein Interview zu führen .

Heute ...
Immer mehr Entwickler und Linux-Benutzer kommen aus Nicht-Red Hat-, Nicht-SuSE- und Nicht-Enterprise-Linux-Umgebungen.

• Sie benutzen Ubuntu oder Debian ...
• Sie mussten sich weder mit Hardware der alten Schule noch mit Support von großen Anbietern befassen.
• Sie schreiben ihre eigenen Anwendungen von Grund auf (selbst unterstützt).
• Virtualisierung und Cloud-Computing abstrahieren die Hardwareschicht, sodass die Sorge um flippige RAID-Controller-Treiber, PCI-X-Peripheriegeräte oder binär verteilte Verwaltungsagenten nicht einmal auf dem Radar steht.
• Diese Benutzer möchten die Tools und das Benutzerland, an die sie gewöhnt sind.

Es gibt also einen Konflikt ... Diese Benutzer verstehen nicht, warum sie auf Anwendungs- oder Bibliotheksversionen beschränkt sind. Die Administratoren der alten Schule stellen sich immer noch auf das neue Paradigma ein . Argumente, die in der Religion verwurzelt zu sein scheinen , sind eigentlich nur Funktionen, wie Menschen ihre jeweiligen Fähigkeiten entwickelt haben.

Ich habe heute eine Stellenanzeige für einen sehr erfahrenen DevOps Linux-Ingenieur gesehen, die lautete:

Muss sich mit Debian-basierten Linux-Distributionen auskennen (Ubuntu und Varianten in Ordnung. Red Hat passabel , aber nicht bevorzugt)

Ich schätze, es funktioniert in beide Richtungen. Ich habe mich von Stellenangeboten verabschiedet, weil die 800 CentOS-Server, die ich verwalten würde, auf Ubuntu umgestellt werden sollten. Sicher, Linux ist Linux ... aber ich hatte nicht das Gefühl, dass ich so effektiv sein könnte ... Ich habe mit Debian-Installationen herumgespielt und mir gewünscht, dass eine RPM-basierte Distribution verwendet wird. Ich hatte heftige Auseinandersetzungen über die Vorzüge verschiedener Plattformen (wobei Gentoo normalerweise ganz unten auf der Liste steht).

Was passt also zu IHRER Umgebung? Es hängt davon ab, ob. Ich war in Unternehmen tätig, in denen Systemingenieure Entscheidungen treffen, und in Organisationen, in denen die Entwickler König sind. Ich denke, das beste Arrangement ist, wenn Entwickler und die Leute, die die Systeme unterstützen, sich auf eine Plattform einigen. Aber denken Sie darüber hinaus an langfristigen Support, Benutzerfreundlichkeit, Community und an das, was Ihrem Anwendungsstapel am besten entspricht.

Ein talentierter Entwickler sollte in der Lage sein, in einer RHEL- oder Debian-ähnlichen Umgebung zu arbeiten. Und nun, Entwicklungsplattformen sollten die Produktionsumgebung widerspiegeln. Du gehst von dort ...