Die Openshift Container Plattform Interview und Aufriss zur Container-Strategie von Red Hat

Dass sich die Container-Technologie hervorragend für Microservice-Architekturen nutzen lässt oder als Fundament für das Cloud-native App-Deployment, haben auch Unternehmen wie Red Hat früh erkannt. Wie sieht der Status Quo aus und wie genau lautet die Strategie?

Anbieter zum Thema

DataCore Software GmbH

Fujitsu Technology Solutions GmbH

Schwarz IT KG

Red Hat GmbH

Zwar hatte Red Hat bereits auf dem „Red Hat Summit 2015“ mit seiner „Red Hat Atomic Enterprise Platform“ eine integrierte Infrastrukturplattform für das Orchestrieren und Skalieren von Applikationen und Services angekündigt, allerdings wird es Atomic Enterprise Platform so nicht geben, denn Red Hat diese auf dem diesjährigen Summit in „Openshift Container Platform“ umbenannt und in „Openshift Enterprise“ beide Aspekte eine Container-Umgebung vereint, also Developement und Produktion.

Fundament der Plattform ist ein Managed-Scale-Out-Cluster auf Basis von „Red Hat Enterprise Linux“ (RHEL) 7 oder RHEL 7 Atomic Host. Zwar erfolgt auch hier das Bereitstellen von Linux-Containern auf Basis des Docker-Formats, einschließlich der Docker-eigenen Container-Runtime, für das Orchestrieren kommt, bei Red Hat, wie auch etwa bei Suse, aber „Google Kubernetes“ zum Einsatz.

Sicherer Container-Inhalt, sichere Container-Herkunft

So fußt die Sicherheitsstrategie von Red Hat im Umgang mit Linux-Containern auf einem eigenen Zertifizierungsservice. Dieser versteht sich als Angebot von Red Hat an ISVs, ihre Anwendungen auf Basis von RHEL für den Betrieb auf RHEL in Containern vorzubereiten und zu verpacken. Ihre Anwendungen werden damit dann auch über Red-Hat-Registry auffindbar und sind entsprechend leicht zu konsumieren.

Für wie grundlegend Red Hat Container-Technologie in Bezug auf die künftige App-Bereitstellung on premise und in Cloud-Umgebungen hält, zeigt sich beispielsweise daran, wie das Unternehmen mit „Atomic Host“ die fundamentale Architektur von Enterprise-Betriebssystemen auf Microservices bereitstellt.

Doch auch was die App-Entwicklung und Weitergabe als Cloud-Services angeht, setzt Red Hat spätestes seit Openshift 3 aus dem vergangenen Jahr ganz auf Docker. So bildet die Openshift-Container-Plattform heute Unterstützung für Entwicklung und Betrieb Cloud-basierter Anwendungen, welche auf Docker-Containern, Googles Container-Orchestrierung Kubernetes und RHEL 7 basieren.

Vom Container zum Microservice

Container-Technologie an sich macht Applikationen allerdings zunächst einmal „nur“ portabel, genügt allein aber nicht für das Verwalten einer auf komplexen Microservice-Architekturen basierenden Applikationslandschaft. Erst ein mächtiges Management-Werkzeug wie Google Kubernetes sorgt in der Praxis für echte Continuous Delivery oder DevOps-Konzepte mit oder ohne Container.

Allerdings kann die Openshift Container-Plattform DevOps Konzepte von der Tool-Seite aus unterstützen. Zudem kann Openshift Basis für den Betrieb von Microservices sein. Hierzu bedarf es wiederrum eines komplexen Ökosystem an Anwendungen, Services und Plattformen aus den Bereichen Sicherheit, Monitoring, Networking, Orchestration, Management, Container OS , Entwickler-Tools, Entwickler-Plattformen oder Hosting- und Service Providern, wie es der ehemalige Red-Hat-Mitarbeiter Krishnan Subramanian in Form seiner Mindmap „Open Container Ecosystem“ treffend illustriert.

Warum sich Container noch nicht durchsetzen

Soweit die Theorie. Container-Technologie findet aber wie o. e. vorrangig von unten oder „der Seite“ (initiiert durch Entwickler und Administratoren) Einzug ins Unternehmen. Bei CTOs herrscht oft noch eine Erwartungshaltung vor, die sich auf zum Teil auf Halbwissen stützt, was die praktische Einsetzbarkeit angeht. Container-Technologie ist daher bei vielen Unternehmen derzeit noch nicht als Deployment-Standard im Einsatz.

Dies liegt aber vorrangig daran, dass sich Cloud-basierte Apps noch lange nicht Status Quo sind. In der Realität herrscht was Bereitstellung und Nutzung von Apps in Unternehmen angeht ein Mix aus Legacy-Apps, mobilen Anwendungen, SaaS-Angeboten und gegebenenfalls Cloud-Apps vor, wobei Letztere wahlweise in der eigenen privaten Cloud bereitgestellt werden oder aus der Public-Cloud renommierter Anbieter stammen.

Ob sich Container-basierte Apps überhaupt sinnvoll in der Private- oder Public-Cloud bereitstellen lassen, wirft zunächst die Frage auf, ob sich statusbehaftete Applikationen containerisieren lassen? Allgemein herrscht nämlich oft noch die Ansicht vor, dass Container im Prinzip flüchtig seien und sich daher in Cloud-Szenarien nur sinnvoll für stateless Applications im Sinne von Microservices verwenden lassen.

Docker Container

Keiner kommt an Container-Technik, also Docker, vorbei

Container sind an sich nicht neu und es gibt sie in manigfachen Ausprägungen angefangen von Solaris Zones, über Parallel Virtuozzo, OpenVZ, LXC, Docker, CoreOS/Rocket und Co. Eine nennenswerte Bedeutung scheinen nur LXC und Docker zu haben. LXC deshalb, weil es zumindest einmal die Basis von Docker war, das ja inzwischen eine eigene Container-Engine hat.

Zugleich arbeitet das LXC-Team trotz des Docker-Erfolges unbeirrt weiter sowohl am LXC-Toolset, als auch an einem eigenen als „Lightervisor“ bezeichneten Container-Management. Der wesentliche Unterschied zu Docker besteht darin, statt nur eine einzige Anwendung ein vollwertiges System in den Container zu packen.

Interview mit Lutz Lange

Das wirft Fragen auf. Dazu und zur Durchsetzung von Container-Technologie stellt sich Lutz Lange einem Interview. Lange ist Solutions Archtitect und Cloud Spezialist bei Red Hat

Lutz Lange ist Solutions Archtitect und Cloud Spezialist bei Red Hat.

Docker ist in den Augen der LXC-Entwickler nur eine Lösung zum Ausliefern von Anwendungen. Sehen Sie das auch so? Hat sich Red Hat beim Container-Format auf Docker festgelegt, um einer weiteren Fragmentierung der Technologie entgegen zu wirken?

Lutz Lange: Es macht in unseren Augen wenig Sinn, mehrere konkurrierende Container-Formate zu haben. Docker selbst fehlten aber zu der Zeit, als Red Hat damit begann, das gesamte Potenzial der Technik von verschiedenen Seiten aus (OpenStack, Openshift, Atomic) auszuloten, maßgebliche Sicherheitskonzepte und außerdem war der Orchestrierungsgedanke bei Docker quasi noch nicht vorhanden. Insofern ist die Wahrnehmung der LXC-Entwickler nicht ganz falsch.

Was sind die nach Ihrer Ansicht wichtigsten Use Cases für Container? Immerhin scheinen vServer oder Zones, wie sie Hoster schon seit Jahren nutzen nicht so weltbewegend wichtig zu sein, dass dies allein den derzeitigen Container-Hype erklären könnte. Bleibt noch das komfortable Bereitstellen Cloud-nativer Apps und die Microsegmentierung? Noch vor 2 Jahren hieß es auf dem Red Hat Summit, dass Red Hat Atomic Host den Markt für Enterprise-Betriebssysteme revolutioniere.

Lutz Lange: Ja und Nein. Wir arbeiten zwar zusammen mit Google massiv an der Container-Orchestrierung und der Erweiterung der Skalierbarkeit, die meisten Unternehmen sind aber noch gar nicht do weit, sich dem Docker-Einsatz im ganz großen Maßstab zu widmen. Bei Vielen geht es zunächst erst einmal um die Integration in bestehende Umgebungen, damit Entwickler Container eben nicht im Stillen auf ihren Notebooks einsetzen, sondern per Self-Service in bestehenden Infrastrukuren anfordern.

Dazu arbeiten wir an Lösungen, Container in die bestehende Infrastruktur einzubetten und zwar MIT ihren Services, wie Security-, Authentisierungs- und Netzwerk-Dienste. Aber auch die Unternehmen selbst müssen sich mit der Frage befassen, wie sie Container-Technologie optimal mit bestehenden Workloads und Prozesse verknüpfen können, denn niemand startet ja mit Containern von der grünen Wiese.

Red Hat und Google haben mit Kubernetes einen Defakto-Standard für die Orchestrierung von Containern geschaffen. Wenn aber die meisten Unternehmen noch gar nicht in diesen Größenordnungen denken, ist die Orchestrierung dann nicht überbewertet?

Lutz Lange: Nein, die Orchestrierung steht über allem. Unternehmen müssen in der Lage sein, mehrere Container miteinander kombinieren zu können oder Container mit anderen Applikationen. Ferner müssen Container mit anderen IT-Ressourcen im Unternehmen kommunizieren können. Das klappt wiederum nur dann, wenn Container von vorne herein in einer Umgebung entwickelt werden, die die geschilderte Realität im Unternehmen auch abbildet.

Zudem ist die Skalierung ja auch nur ein Aspekt der Orchestrierung. Zunächst kombiniert die Orchestrierungs-Engine die unterschiedlichen Services und/oder deren Instanzen zu einer Anwendung. Die Orchestrierung sorgt aber auch dafür, das Apps in genau dem richtigen Kontext gebaut werden, also „wo“ die einzelnen Services ausgeführt werden und „wie“ Netzwerkkomponenten, Workloads, Storage-Ressourcen und Security-Profile einzubetten sind. Außerdem kümmert sich die Orchestrierungs-Engine um das Verwalten der Stati von Geräten und Apps.

Cloud und Container-Technologie ergänzen sich also, wenn die richtigen Orchestrierungswerkzeuge wie Kubernetes zum Einsatz kommen. Brauchen wir also langfristig keine virtuellen Maschinen mehr?

Lutz Lange: Amazon beispielsweise bietet ja inzwischen immer mehr Dienste an, mit denen sich das Betreiben eigener Instanzen ohnehin erübrigen würde. Wenn sich Amazons Lambda-Dienst fest etabliert, mit dem es möglich wird, Code zu hinterlegen der auf Events reagiert, müssen eigene Instanzen nicht mehr dauerhaft betrieben werden. Damit wird es sich auch erübrigen, dass Unternehmen sich bemühen, nach und nach Ihre VM-Workloads in Container zu verfrachten.

Ist das der falsche Weg?

Lutz Lange: Ja, das wäre die schöne ferne Zukunft, die dann auch IT-Abteilungen, Rechenzentren und Admins im Unternehmen überflüssig macht. Aber wie ich schon sagte, spiegelt das die Realität nicht im Entferntesten wieder. Unternehmen werden noch lange Legacy-Apss nutzen, gegebenenfalls parallel auf SaaS-Angebote zugreifen und vielleicht damit anfangen, erste eigene private Clouds zu bauen.

Legacy-Systeme werden sowohl auf Hardware- wie auch auf Software-Ebene auf lange Sicht nicht automatisch verschwinden und von Containern verdrängt werden. Daher liegt die Hauptherausforderung darin, Container sowohl mit neuesten Anwendungen, als auch mit Legacy-Systemen zu verheiraten.

Die IT in Unternehmen ist heute hoch dynamisch. Container-Lösungen müssen also mitwachsen und skalieren, insbesondere wenn wir von einer Tenant-fähigen Architektur reden. Wie wichtig ist aus ihrer Sicht die Skalierbarkeit?

Lutz Lange: Skalierbarkeit muss von Anfang an in der Planung angelegt sein. Daher preisen ja auch nahezu alle Container-Hersteller ihren Lösungen als hoch skalierbar an. Oft stimmt das aber nur bedingt, weil es das jeweilige Design gar nicht erlaubt. Skalierbarkeit ist die mit Abstand wichtigste Eigenschaft, wenn man auf eine verteilte, mandantenfähige IT-Architektur abzielt.

*Über den Autor

Thomas Drilling ist freie Journalist und Berater; auf DataDenter-Insider schreibt er seinen eigenen Blog: „Drillings Open Source-Eck“

(ID:44424780)