Container-Strategie von Red Hat Was es mit der Openshift Container Plattform auf sich 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

PresseBox - unn | UNITED NEWS NETWORK GmbH

Confluent Germany GmbH

Windhoff Group

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.

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.

Das wirft Fragen auf. Dazu und zur Durchsetzung von Container-Technologie stellt sich Lutz Lange von Red Hat im Interview.

* Thomas Drilling ist freier Journalist und Berater; auf DataCenter-Insider schreibt er sein eigenes Blog: „Drillings Open Source-Eck“

(ID:44471927)