Red Hat Satellite Server 6

Andreas Grünenfelder

Mit dem Release 6 des Satellite Server, der im September 2014 GA Status erreichte, hat Red Hat einiges überarbeitet. Die Änderungen sind nicht allesamt technologischer Natur. Während Red Hat beim Satellite 5 noch auf Entitlements via Red Hat Network Classic setzte, werden für den Satellite 6 Subscriptions mittels Red Hat Subscription Management vorausgesetzt. Für den Kunden bedeutet dies eine Umstellung der Red Hat Produkte auf das Subscription Model.

Welche technischen Änderungen gibt es?

Vom technischen Standpunkt aus gesehen sind die Satellite Versionen 5 und 6 fundamental unterschiedlich. Während Satellite 5 auf dem Open Source Projekt Spacewalk basiert, vereint Satellite 6 die Projekte Foreman, Puppet und Katello mit den Komponenten Pulp und Candlepin.

Satellite6

Abbildung: Red Hat

Puppet ersetzt Configuration Channels

Konfigurationsdateien wurden im Satellite 5 mittels Configuration Channels verwaltet. Mit der Verwendung von Macros konnten nebst statischen auch dynamische Dateien gehandhabt werden. Im Satellite 6 setzt Red Hat auf die bewährte Open Source Configuration Management Software Puppet. Diese erlaubt es, mit einer deklarativen Syntax Zustände für die gemanagten Ressourcen zu definieren. Die Liste der von Puppet supporteten Ressourcen geht von Files über Pakete zu Services und vielem mehr. Mit der Verwendung von Metaparametern innerhalb von Puppet lassen sich einfach Abhängigkeiten verschiedener Ressourcen modellieren und so deren Reihenfolge festlegen. Bei jedem Durchlauf des Puppet Agents auf einem Client versucht dieser folglich, den festgelegten Zustand herzustellen.

Durchgängiges Lifecycle Management

Wollten Administratoren im Satellite 5 fixe Softwarestände und aktuelle Security Updates für ihre Serversysteme einsetzen, war dies sehr aufwändig. Auch der anschliessende Deploy der Software-Releases in die verschiedenen Environments wie Development, Integration und Production war meist umständlich. Genau dieses Problem löst Satellite 6 mit sogenannten Content Views und Lifecycle Environments. Sie erlauben es, verschiedene Sichten auf die zugrunde liegenden Software- und Puppet-Repositories zu definieren und diese anschliessend in die verschiedenen Environments zu promoten. Da bei jeder Veränderung einer Content View eine neue Version erstellt wird, kann einfach sichergestellt werden, dass die Änderung zuerst ein Integration-System durchläuft, bevor sie auf ein Production-System kommt.

Capsules lösen Satellite Proxy ab

Satellite 5 Anwender werden schnell feststellen, dass der Satellite Proxy im neuen Release nicht mehr existiert. Dieser wurde im Satellite 6 durch Capsules abgelöst. Während der Satellite Proxy dazu da war, Software-Pakete zu cachen, kann man sich die Capsule als Mirror des Software- und Configuration-Content vorstellen. Dies erlaubt es, Content lokal zu halten und Umgebungen einfacher zu skalieren. Zusätzlich können Capsules mittels Smart Proxies weitere APIs zu Diensten wie DHCP, TFTP, etc. bereitstellen, die wiederum von Satellite 6 angesprochen werden können.

Wann migrieren?

Den richtigen Zeitpunkt für die Migration einer so zentralen Komponente wie dem Satellite Server zu finden, ist nie einfach. Deshalb sollten die Anforderungen an das neue Management System sorgfältig ausgearbeitet werden. Während zum einen Satellite 6 keine Unterstützung für Clients älterer Red Hat Enterprise Linux (RHEL) Versionen mehr bietet, sind zum anderen Satellite Server der Version 5.5 und älter nicht in der Lage, RHEL 7 Systeme zu managen.

Sprechen alle Anforderungen für eine Migration auf Satellite 6, sollte man im Hinterkopf halten, dass Red Hat den Release 6.1 für Anfang 2015 angekündigt hat. Selbst wenn die aufgelisteten Features des nächsten Releases nicht benötigt werden, sollte man sich überlegen, auf diesen zu warten. Wie bei anderen Software-Produkten, die einem grundlegenden Re-Design unterzogen wurden, haben sich auch im Satellite Release 6.0 einige Kinderkrankheiten eingeschlichen. Es ist daher anzunehmen, dass die Version 6.1 nebst Erweiterungen vor allem auch eine höhere Stabilität bringen wird.

Abschliessend gilt es zu beachten, dass mit den Lifecycle Environments und dem Configuration Management mittels Puppet für viele Anwender neue Konzepte hinzu gekommen sind. So ist es durchaus möglich, dass nach der Migration des Management Systems die Umstellung der Client Systeme erst beginnt.

Fazit

Mit dem Satellite 6 bringt Red Hat mit Sicherheit einige gute Veränderungen. Lange vermisste Features wie das Management unterschiedlicher Software-Stände für verschiedene Umgebungen stellen nun einen Eckpfeiler des neuen Satellites dar. Auch die Integration eines Configuration Management Werkzeugs wie Puppet ist lobenswert. So unterstützt dies Administratoren sowohl in der Standardisierung ihrer Serverumgebungen als auch in der Automatisierung des Deployments. Eine Umstellung auf Satellite lohnt sich auf alle Fälle. Wann die Migration geschehen soll und welcher Release verwendet wird, sollte im Einzelfall individuell entschieden werden. Puzzle unterstützt Sie dabei gerne.

Kommentare sind geschlossen.