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

Lösung 1:

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

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

Ich begann 2000-2002 professionell mit Linux zu arbeiten. Dies geschah während der breiten Einführung von Red Hat und den Red Hat Professional Editions (6.x, 7.x, 8.0). Diese waren zum kostenlosen Download sowie als verpackte Sets erhältlich. Sie könnten leicht in Computer-Einzelhandelsgeschäften gefunden werden.

Für mich hatte dies den Vorteil, Hobby- und Heimanwender mit demselben zu beschäftigen Produkt, das sich im Unternehmen zu entwickeln begann. Zu dieser Zeit bestand meine Arbeit darin, Kundenserversysteme von kommerziellen Unices (HP-UX, AIX und SCO) auf die Red Hat-Plattform zu verschieben.

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

Also, warum Red Hat?

Red Hat war das erste Unternehmen auf diesem Markt und erhielt wichtige Unterstützung für Unternehmen, Anbieter und Hardware. Zu sehen, wie große Anwendungsanbieter Red Hat als Zielplattform verwenden, besiegelte den Deal. Hobbyanwender wie ich konnten die zu Hause erlernten Fähigkeiten problemlos auf unsere Arbeitsumgebung übertragen. Die Gemeinschaft wuchs. Slashdot-, Freshmeat- und LAMP-Stacks regiert! 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 probierte ich eine andere Distribution (Mandrake, SuSE, Debian, Gentoo) aus, fand aber Probleme mit Paketierung, Hardwareunterstützung (Server oder Peripherie), der (Größe der) Community oder ein anderer Deal-Breaker.

Ein Beispiel:Ich habe Compaq/HP ProLiant-Hardware verwendet, die mit Digi Serial-PCI-X-Erweiterungskarten und Esker VSIfax-Produktionsfaxsoftware ausgestattet war. 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 eine einfache Verwendung auf anderen Linux-Varianten ausschließt.

Momentum zählt in der Welt der Informationstechnologie
Niemand möchte jemand sein, der das Verlieren empfiehlt Lösung oder Projekt, das schließlich verwaist, also bleibst du bei sicheren Entscheidungen. Ich verwaltete einen Technologie-Stack, der zuverlässig funktionieren und mehrere Support-Ebenen bieten musste. An diesem Punkt eine andere Distribution zu wählen, wäre gerechtfertigt gewesen. gewesen. unverantwortlich.

Die Flitterwochen von Red Hat 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 sich... Kosten (teures abonnementbasiertes Modell), Zugänglichkeit (Schrumpfung der Benutzerbasis und Community) und allgemeine Verwirrung über die Zukunft...

Ich begann nach Alternativen zu suchen und bewertete Gentoo, Debian und SuSE neu. Ich konnte nicht die richtige Unterstützung für alle Komponenten unseres Technologie-Stacks erhalten. Ich war gezwungen, beim Red Hat-Ökosystem zu bleiben ... Aufgrund der wilden Kostenverschiebungen im Zusammenhang mit Red Hat Enterprise Linux führte ich letztendlich Jahre ein stark modifiziertes Red Hat 8.0 aus über sein Lebensende hinaus. 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 Binärkompatibilität mit den kostenpflichtigen RHEL-Versionen. Es ist sogar möglich, direkte Konvertierungen zwischen RHEL und CentOS und umgekehrt durchzuführen. Ich habe weiter mit RHEL-ähnlichen Systemen gearbeitet, bis ich den nächsten Karriereschritt gemacht habe...

Später fand ich mich in der Hochfrequenz-Finanzhandelsbranche wieder, wo ich für F&E und Linux-Engineering für kritische automatisierte Handelssysteme verantwortlich war. Die Betonung in dieser Welt lag auf Geschwindigkeit , durch sorgfältiges Testen und Einstellen. Auch hier war die Hardwareunterstützung der Schlüssel. Ich hatte spezielle Netzwerkkarten, spezialisierte Hardware, Serverhardware oder Anwendungsbibliotheken, die nur für RHEL oder RHEL-ähnliche Systeme zertifiziert waren. Auch dort, wo Dinge für andere Linux-Varianten kompiliert werden konnten, kam der Community-Faktor auf. Wenn ich an dem Punkt war, an dem ich ein Problem recherchieren musste, war es oft ein Problem, das auf Notizen oder Kommentare in Red Hat Bugzilla-Berichten zurückgeführt werden konnte, oder manchmal reichte ich einfach einen Patch ein oder forderte die nächste Version an .

Als ich anfing, mich mit Low-Latency-Networking und Kernel-Tuning zu befassen, begann ich, die Stock-RHEL-Kernel und RHEL MRG Realtime-Kernel zu sezieren. Mir ist aufgefallen, wie viel Arbeit in den Veröffentlichungen steckt ... über 200 Patches für einen Vanilla-Kernel.org-Kernel. Lesen Sie die Kommentare und Commit-Notizen. Möglicherweise haben Sie kleine Dinge wie sysctl Parameter ausgesetzt oder vernünftigere Standardwerte angewendet. Red Hat bezahlt Leute dafür, diese Probleme zu patchen, zu testen und zu beheben. Ich habe bei anderen Linux-Distributionen nicht das gleiche Engagement gesehen ... Fügen Sie die Tatsache hinzu, dass die Unternehmensplattform für Jahre garantiert echte Sicherheit, Fehlerbehebung und Backport-Unterstützung bietet .

Also wechselte ich schließlich zu einer anderen Finanzfirma, die auf dem Server und fast ausschließlich aus Gentoo bestand Desktop... Es war eine Katastrophe für mich. Da ich aus der Welt von Red Hat und CentOS komme, bin ich auf zahlreiche Stabilitäts- und Verwaltungsprobleme mit dem Gentoo-Setup gestoßen. Die Versionskontrolle war das größte Problem, aber auch die schwindende Unterstützung der Community und der Mangel an echten Tests waren Bedenken. Ich fing an, RHEL in die Umgebung einzuführen, weil einige unserer Drittanbieter-Software es 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 darauf einstellen, die festen Hauptversionen zu haben, auf denen Red Hat Enterprise Linux standardisiert ist. Der Entwicklungs- und Veröffentlichungsprozess wurde von Fragen geplagt, warum GLIBC 2.7 nicht auf RHEL 5.x aufgepfropft 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.

An diesem Punkt wurde mir klar, dass Red Hat sich viel zu langsam für Entwickler bewegte, die auf dem neuesten Stand sein wollten. RHEL 6.x war ein dringend benötigtes und willkommenes Upgrade, aber dieses Thema wurde deutlicher, als ich anfing, Interviews mit Startups und Firmen zu führen, die sich den DevOps-Prinzipien verschrieben hatten.

Heute...
Eine wachsende Zahl von Entwicklern und Linux-Benutzern kommt aus Nicht-Red Hat-, Nicht-SuSE- und Nicht-Enterprise-Linux-Umgebungen.

• Sie verwenden Ubuntu oder Debian...
• Sie mussten sich nicht mit Hardware der alten Schule oder dem Support großer Anbieter auseinandersetzen.
• Sie schreiben ihre eigenen Anwendungen von Grund auf (selbsttragend).
• Virtualisierung und Cloud-Computing abstrahieren die Hardwareebene, sodass Sorgen über unkonventionelle RAID-Controller-Treiber, PCI-X-Peripheriegeräte oder binär verteilte Management-Agenten nicht einmal auf dem Radar sind.
• Diese Benutzer möchten die Tools und das Userland, an das sie gewöhnt sind.

Es gibt also einen Konflikt ... Diese Benutzer verstehen nicht, warum sie auf Anwendungs- oder Bibliotheksversionen beschränkt sind. Administratoren der alten Schule passen sich immer noch an das neue Paradigma an. Argumente, die scheinen in der Religion verwurzelt zu sein, sind wirklich nur Funktionen davon, 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 in Debian-basierten Linux-Distributionen kompetent bis Experte sein (Ubuntu und Varianten okay. Red Hat passabel , aber nicht bevorzugt)

Ich denke also, es funktioniert in beide Richtungen ... Ich habe mich von Stellenangeboten abgewandt, 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 wäre, wie ich sein könnte ... Ich habe mit Debian-Installationen herumgefummelt und mir gewünscht, dass eine RPM-basierte Distribution verwendet würde. Ich hatte hitzige Diskussionen über die Vorzüge verschiedener Plattformen (wobei Gentoo normalerweise ganz unten auf der Liste steht).

Was ist also das Richtige für IHRE Umgebung? Es hängt davon ab, ob. Ich war in Unternehmen, in denen Systemingenieure Entscheidungen treffen, sowie in Organisationen, in denen die Entwickler König sind. Ich denke, die beste Vereinbarung ist, wenn sich Entwickler und die Leute, die die Systeme unterstützen, auf eine Plattform einigen. Aber denken Sie darüber hinaus an langfristigen Support, Benutzerfreundlichkeit, Community und daran, was Ihren Anwendungsstapel am besten unterstützt.

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

Lösung 2:

Ich arbeite derzeit in einer Umgebung, in der Linux seit mehr als einem Jahrzehnt verwendet wird. Jeder im Büro verwendet verschiedene Distributionen auf seinen Desktops sowie auf den Servern. Daher dreht sich die Wahl der Verteilung in der Regel um eine Reihe von Dingen in keiner bestimmten 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. Upgrades werden einfacher, wenn die Software von einer Distribution gut unterstützt wird.
2. Vertrautheit - Ähnlich wie Geschichte, aber wir haben alle unsere Favoriten. Ich habe mich bei Debian durchgebissen und bin zu Ubuntu migriert (damals eine schwierige Entscheidung, weil ich dazu neige, mich einer Community anzuschließen). Umgekehrt ist es mühsam, sich merken zu müssen, wie man Dinge auf einem Dutzend verschiedener Distributionen macht (ganz zu schweigen von den Scratch-Built-Distributionen).
3. Unterstützung - Ich bin hauptsächlich zu Ubuntu migriert, weil ich zu schätzen wusste, was sie in Bezug auf das Angebot von kostenpflichtigem Support tun. Das war ein Verkaufsargument, wenn ein Kunde jemals Bedenken hatte, ein System langfristig zu betreiben. Ähnlich dem Ansatz von RedHat (aber zu der Zeit war die RPM-Hölle im Gange). Aus diesem Grund haben wir auch eine Reihe von RedHat-Servern.
4. Abhängigkeiten - Manche Software ist auf manchen Distributionen einfacher zu verwenden, weil die abhängigen Pakete leichter erhältlich oder baubar sind. Als Beispiel hierfür wäre oVirt auf RedHat zu nennen. Es gibt keine Pakete für einige Software auf einigen Distributionen. Und Sie könnten es kompilieren, aber warum sollten Sie es tun, wenn das Paket in einer anderen Distribution vorhanden wäre?
5. Granularität - Distributionen wie Gentoo bieten eine feinere Kontrolle über Versionierung und Software-Switch-Granularität. Andere Distributionen haben "Pinning" in verschiedenen Formen, aber das ist immer noch nicht so kontrollierbar oder zuverlässig.
6. Verbindlich - Während es bei den meisten Distributionen möglich ist, aus dem Quellcode zu kompilieren, sind einige Distributionen besser darin als andere. Dies kann sich beispielsweise auswirken, wenn Ihr Projekt vorhandene Bibliotheken für erweiterte Funktionalität patcht.
7. Schönheit - Einige Distributionen sehen einfach besser aus. Jeder Geek weiß, dass es nur eine Floskel ist (und Sie könnten heutzutage wahrscheinlich davonkommen, es als Web-App zu machen), aber einige Kunden sind von diesem Zeug begeistert, und wir alle wissen es.
8. Stabilität - Einige Distributionen streamen "stabile" Softwareversionen im Gegensatz zu "testen", "experimentell" usw. Dies kann viel bedeuten, wenn Sie wissen, dass die Version, auf der Sie aufbauen, schließlich einen Konsens über die Stabilität erreichen wird. Sie können sich auf „experimentell“ entwickeln, in dem Wissen, dass Ihr Projekt am Ende „stabil“ ist und Sie sich darauf verlassen können.
9. Paketverwaltung - Wenn Sie täglich etwas entwickeln und es mit einem Schlag an Tausende von Computern senden soll, möchten Sie wahrscheinlich etwas, das es einfach macht, Pakete über diese Systeme hinweg zu erstellen, zu warten und zu verfolgen.
10. Konsistenz - Dies ist eher ein Argument für dasselbe Distribution. Es werden weniger Fehler gemacht (und weniger Sicherheitsfehler), wenn sich die Leute auf eine Distribution konzentrieren können, anstatt auf mehrere.
11. Vorhersehbarer Veröffentlichungszeitplan - Wenn Sie sicher sein möchten, dass Ihre Software weiterhin unterstützt wird, bieten geplante Upgrades eine gewisse Stabilität.
12. Sicherheit - Einige Distributionen haben aktive Sicherheitsteams, deren Aufgabe es ist, sofort auf echte Sicherheitsrisiken in jedem genehmigten Paket zu reagieren.

Das sind nur ein paar Dinge, die mir in Bezug auf die Gründe, warum jedes System ausgewählt wurde, spontan einfallen. Ich sehe in dieser Entscheidung kein Leitbild oder keine Präferenz 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 in Gang zu bringen, aber es ist auch die Schlinge, an der Sie hängen bleiben können. Stellen Sie sicher, dass Sie im Voraus darüber nachdenken, was Sie brauchen werden. Planen Sie, was die Anforderungen des Systems sind und wann das System aktualisiert oder ausgemustert wird. Gehen Sie nicht davon aus, dass Sie es immer pflegen werden.