Seit dem 1. Juli 2019 partnert die profi.com AG mit Red Hat und bekennt sich damit auch offiziell zu Enterprise Open Source Software und einer
Open Source Kultur.
Zusammen haben wir es auch in kürzester Zeit geschafft, den Status des Advanced Partners zu erreichen. Wir haben mittlerweile Beratung, Architektur, Konzeption und Implementierung für diverse Red Hat- und Open Source-Produkte in unser Portfolio aufgenommen.
Für mich als Open Source-Contributor sind das erstmal gute Nachrichten, gebunden an ein wenig Skepsis. Was bedeutet das für mich? Muss ich nun propritäre Software benutzen, die es nur bei Red Hat gibt? Ist mein Fedora- und CentOS-Wissen für Red Hat Enterprise Linux anwendbar? In diesem Artikel möchte ich auf diese Fragen und meine Erfahrungen mit der Red Hat-Partnerschaft eingehen.
Red Hat und Open Source
Für mich als Techniker hat sich natürlich die Frage gestellt, ob ich jetzt mit Red Hat nur noch „spezielles“ Open Source nutzen darf. Gibt es überhaupt Open Source-Alternativen zu den Red Hat-Produkten? Sehr positiv empfand ich daher Red Hats Open Source Kultur und Mindset. Wirklich zu jedem Enterprise-Produkt gibt es eine adäquate Alternative / ein entsprechendes Upstream-Produkt. Ein paar Beispiele mit den jeweiligen Open Source-Equivalenten möchte ich hier kurz vorstellen. Red Hat selbst beschreibt dies auch nochmal in seinem Development Model.
Red Hat Enterprise Linux = Linux für Unternehmen
Red Hat Enterprise Linux (RHEL) war mein erster Berührungspunkt mit Red Hat. Da ich schon seit vielen Jahren selbst Fedora auf dem Desktop und CentOS auf Servern einsetze war der Umstieg recht einfach. Im Grunde fühlte sich alles an wie auf CentOS. „Yum“ managed die Pakete, „NetworkManager“ kümmert sich um das Netzwerk und selbst die Paketversionen waren sehr dicht beieinander. Lediglich an den SubscriptionManager musste ich mich gewöhnen.
Die Philosophie bei Red Hat ist, dass Fedora als Upstream Plattform dient und immer die neuesten Softwarestände und Updates inkludiert. Red Hat erstellt dann an einem Punkt eine „Kopie“ um daraus das neue RHEL zu generieren. Dieser Ansatz wird auch bei den anderen Software Produkten von Red Hat verfolgt. Kein Wunder also, dass mir alles bekannt vorkommt.
Und warum sollte ich nun Red Hat Enterprise Linux nutzen? Neben den wirklich sehr schnellen Updates und einer der umfangreichsten Dokumentationen hat mich auch der sehr gute Support beeindruckt. Meine Tickets wurden in Windeseile bearbeitet und gelöst. Darüber hinaus werden Red Hat-Produkte sehr ausgiebig getestet und es wird viel Wert auf Qualität gelegt. Dass ich Red Hat Enterprise Linux mit dem Developer Programm sogar privat kostenlos nutzen kann beeindruckt mich um so mehr.
Für das Management der Server kann ich klassisch „SSH“ oder das Webinterface Cockpit oder Red Hat Satellite / Foreman nutzen. Cockpit hat unter RHEL 8 nochmal deutlich zugelegt und ich möchte behaupten, selbst Linux-Neulinge werden hier nicht überfordert. Zusammen mit den Tools tuned und performance co-pilot steht einem eine solide Management-Lösung für kleine Netze zur Verfügung. Wer größere Flotten zu bewältigen hat, kommt an Red Hat Satellite nicht vorbei. Wenn das noch nicht genügt, gibt es Red Hat Insights. Das ist ein Cloud-Werkzeug von Red Hat für RHEL 8, welches neben Vulnerabilities und Compliance Tips auch weitere Advisories bereit hält.
Red Hat Ansible = Automation – the simple way
Ansible nutze ich mittlerweile seit fünf Jahren und war gespannt was Red Hat mir zusätzlich anbietet. Zugegeben, nicht sooo viel auf den ersten Blick. Ansible auf der Kommandozeile fühlte sich genauso an wie unter Fedora und der Ansible Tower wird beinahe pragmatisch aus dem Upstream Produkt Ansible AWX heraus entwickelt. Die Installation von Ansible und Ansible Tower konnte ich entweder anhand der Dokumentation direkt vornehmen und ausprobieren oder mir vorher das ein oder andere Training und E-Lab anschauen und alles ausgiebig testen.
Selbstverständlich steht mir das gesamte Open Source Repertoir zur Verfügung und darüber hinaus zertifizierte Inhalte aus dem Ansible Automation Hub. Hier findet man für jeden Geschmack etwas. Tickets in JIRA anlegen, eine Palo Alto Firewall konfigurieren oder einfach nur User unter Windows und Linux anlegen.
Red Hat OpenShift = Kubernetes für den Unternehmenseinsatz
Eines der vielleicht beeindruckensten Produkte ist Red Hat OpenShift. Die passende Open Source Variante ist OKD. Was ich mit OpenShift 4 geboten bekomme ist nicht nur einfach ein Kubernetes + X. Das gesamte System ist gut durchdacht und bietet viel mehr als die Summe seiner Teile.
Die Installation unter VMWare, AWS oder Azure ist geradezu beispielhaft einfach. Konfigdatei erstellen, Installer anstoßen und fertig. Anschließendes Konfigurieren von LDAP/Active Directory oder SSL-Zertifikaten habe ich auch schnell erledigt bekommen. Die Interaktion erfolgt wahlweise via CLI mit kubectl, den eigenen OpenShift CLI-Tools oder über die Weboberfläche. Irgendwie erschlägt einen auch alles. Prometheus ist vorkonfiguriert, ein Katalog mit einigen Templates ist dabei, Quotas, Limits, Access… Alles ist schon da und muss „nur“ noch konfiguriert werden.
Glücklicherweise gibt es auch hier neben der Dokumentation noch zusätzliche Lerninhalte und E-Labs, die viele Dinge sehr gut erklären und an die vielen zusätzlichen Tools heranführen.
Als letztes kleines Goodie hat Red Hat OpenShift dann mit etwas überrascht, was ich in der Welt von Kubernetes gar nicht erwartet habe. Automatische Updates für Images, Container und den Cluster OHNE Downtime, auf Knopfdruck!
Fazit
Neben all den neuen Tools fühlte sich sonst alles sehr vertraut an. Meine Ansible Rollen liefen wie gewohnt, etliche Container konnten wir bereits testen und RHEL macht eine so gute Figur, dass ich mich sogar privat damit weiter beschäftige. Irgendwie weckte die sehr einfache Zugänglichkeit, die Tonnen an Dokumentation und Schulungsinhalten und die vielen Möglichkeiten mal wieder den Spieltrieb und ich freue mich darauf euch in einem der nächsten Blogbeiträge das ein oder andere Werkzeug genauer zu erläutern.
