Openstack Queens wurde veröffentlicht und es ist „Container-Tastic“

2018-04-10

Machine-translated — the English original is authoritative.

Die Anzahl der Openstack-Projekte, die sich auf Container-Technologien beziehen, wächst schnell, ebenso wie die Verwirrung bezüglich ihrer unterschiedlichen Anwendungsfälle. Hoffentlich hilft dieser Beitrag dabei zu klären, wann und warum diese Projekte verwendet werden sollten.

Zunächst jedoch, warum Container? Was ist das große Ding? Sind das nicht nur wieder eine andere, von Entwicklern getriebene „Modeerscheinung“? Wenn Sie noch nichts über Container gelesen oder sie in der Entwicklung/Produktion verwendet haben, ist es sehr wahrscheinlich, dass Sie für ein Unternehmen arbeiten, das immer noch traditionelle, monolithische Anwendungen und Bereitstellungsmechanismen verwendet, die sich entweder in privaten Rechenzentren oder in einer öffentlichen Cloud befinden können.

Hintergrund

In den letzten 5 Jahren hat ein Container-Unternehmen, Docker, Software und Toolsets unter dem gleichen Namen veröffentlicht (obwohl das Open-Source-Projekt kürzlich verwirrenderweise in Moby umbenannt wurde), die die Nutzung des Mechanismus zur Isolierung von Prozessen und ihren Ressourcen innerhalb eines Betriebssystems von anderen Prozessen erheblich vereinfacht haben. Diese Mechanismen (Netzwerk-Namensräume, cgroups usw.) gibt es seit vielen Jahren, aber man musste ein Raketenwissenschaftler sein (kein Wortspiel beabsichtigt), um die Systemaufrufe zu verstehen, die für die Aufrufung der Isolierung notwendig sind. Docker hat diese Systemaufrufe in eine sehr einfach zu verwendende API eingebettet, was die Massenadoption von Container ermöglichte – Menschen wie ich wurden plötzlich befähigt.

Anfangs war Linux das einzige unterstützte Host-Betriebssystem, aber in den letzten zwei Jahren hat Microsoft alles daran gesetzt, das Container-Erlebnis auf Windows zu „imitieren“ – es ist immer noch etwas rau an den Rändern, verbessert sich aber schnell. Es kann auch auf einigen Mainframes ausgeführt werden.

Doch Docker hat es nicht dabei bewenden lassen; sie haben sehr clever ein kostenloses globales Repository eingerichtet, das zur Speicherung von Container-Images (yaml-Dateien) verwendet werden kann. Die Softwareindustrie hat diese neue Technologie rasch übernommen, zusammen mit dem https://hub.docker.com-Repository, das schnell mit Distributionen ihrer Softwareangebote gefüllt wurde, die als fertige Container verpackt waren.
So haben wir nun einen Container-Engine mit einer fantastischen Bibliothek von Anwendungen, die einfach und, was noch wichtiger ist, konsistent mit einer Standardmenge von Befehlen bereitgestellt werden können.

Infolge dieses Repositorys und einer großartigen API ist Docker nun zum „De-facto“-Standard für Container-Engines geworden – zum Glück haben wir jedoch die Open Container Initiative [OCI], der Docker folgt und die sicherstellen sollte, dass wir bei Bedarf Container-Engines mit minimalem Aufwand wechseln können.
Diese Revolution, und ich sehe sie als Revolution und nicht als Evolution, hat die Entwicklergemeinschaft sowohl befähigt als auch frustriert. Die Frustration der Entwickler entsteht, wenn sie versuchen, ihre containerbasierten Anwendungen in nicht-containerbasierte Produktionsumgebungen zu deployen. Sie stehen wieder vor langen Vorlaufzeiten für den Aufbau der Umgebung, was zu langen Anwendungszykluszeiten führt. Die folgenden Openstack-Containerprojekte werden hoffentlich helfen, viele dieser Herausforderungen zu lösen.

Warum also Container verwenden?

• Verbesserte Serverauslastung, was zu reduzierten OS-Lizenzkosten führt. Dies ist ähnlich wie die VM-Revolution im letzten Jahrzehnt, in der wir viele physische Server zu virtuellen Servern P2V’ed haben, wodurch die Anzahl der erforderlichen physischen Server reduziert wurde. Jede virtuelle Maschine erforderte jedoch immer noch ihr eigenes Betriebssystem (OS), während Container ein einzelnes Host-Betriebssystem teilen können und dies auch tun.
  Es ist möglich, viele Container innerhalb eines einzelnen Host-Betriebssystems zu starten – dadurch gewinnen wir erneut eine Größenordnung an Verbesserung sowohl bei der Ressourcenauslastung als auch bei den OS-Lizenzanforderungen.

• Modernisierung traditioneller Anwendungen. Bitte verwechseln Sie dies nicht mit Anwendungstransformationen. Dabei bauen Sie Ihre monolithische (meist zustandsbehaftete) Anwendung innerhalb von Containern.
  Sie leiden immer noch unter den gleichen Einschränkungen traditioneller Anwendungen – typischerweise erfordern sie kostspielige Drittanbieterdienste/-lösungen, um ihren Zustand aus Sicht der hohen Verfügbarkeit zu verwalten.
  Allerdings gewinnen Sie die Vorteile der IaaS-Abstraktion (gleiche Erfahrung, ob in private oder öffentliche Cloud bereitgestellt) und konsistente, codifizierte Bereitstellungen. Sie spielen effektiv im Bereich Containers as a Service (CaaS) mit traditionellen Anwendungen.
• Cloud-Native-Anwendungsentwicklung. Diese Anwendungen nutzen heute tendenziell stark Microservice-Muster, und Microservices, die in Container verpackt sind, sind eine sehr leistungsstarke und ergänzende Kombination.
• DevOps-Pipeline-Bereitstellungen. Denken Sie an Continuous Integration und Continuous Deployment. Indem Sie sich auf Container als bewährte Praxis für die Anwendungsbereitstellung festlegen, abstrahieren Sie effektiv die unnötigen Komplexitäten der zugrunde liegenden Infrastruktur. Entwickler können sicherstellen, dass sie das gleiche Bereitstellungs-Erlebnis haben, ob sie ihr eigenes Laptop, einen Entwicklungsserver oder sogar Fujitsus K5, Amazons AWS oder Microsofts Azure-öffentliche Clouds anvisieren. Diese letzten drei öffentlichen Clouds basieren alle auf sehr unterschiedlichen Infrastrukturentechnologien und APIs, aber das ist uns egal! Alle diese Umgebungen benötigen lediglich die Fähigkeit, denselben Container-Engine auszuführen.

Was hat Openstack mit Containern zu tun?

Die verschiedenen Container-Initiativen von Openstack sind hier, um die Bereitstellung und Verwaltung von Containern in der Produktion auf Bare-Metal- und virtuellen Maschinen zu lösen, die mit der Openstack-Software-Suite erstellt wurden. Die Projekte richten sich sowohl an Infrastrukturbetreiber, die die Vorteile von Containern für ihre eigenen Openstack-Bereitstellungen nutzen können, als auch an Entwickler, um deren Probleme bei der Pipeline-Bereitstellung zu lindern und sicherzustellen, dass sie einen konsistenten, schnellen und agilen Prozess haben, um ihre Anwendungen schnell in die Produktion zu überführen.

Magnum
Dies ist die Container-Orchestrierungs-Engine-API. Nehmen wir an, Sie möchten einen Kubernetes-Cluster UND/ODER einen Docker-Swarm-Cluster UND/ODER einen Apache Mesos-Cluster bereitstellen und verwalten, dann wird Openstack Magnum eine konsistente API bereitstellen, die diese verschiedenen Technologien umschließen und eine konsistente Schnittstelle für Infrastrukturbetreiber bieten kann. Das bedeutet, dass Betreiber in der Lage sein sollten, denselben Prozess und dieselben vertrauten API-Aufrufe zu nutzen, um diese sehr unterschiedlichen Produkte bereitzustellen.

Zun
Von der Projektwebseite: „Zun (ehem. Higgins) ist der OpenStack-Container-Dienst. Er zielt darauf ab, einen API-Dienst zum Ausführen von Anwendungscontainern bereitzustellen, ohne dass Server oder Cluster verwaltet werden müssen.“ Im Grunde ist Zun für Container das, was Nova für virtuelle Maschinen ist, und Ironic für Bare-Metal-Server. Der Nova-Docker-Dienst war ein früher Versuch, Container über die Nova-Compute-API zu verwalten. Zun ist nicht an die Nova-API gebunden.

Kuryr
Auch hier bietet die Projektwebseite eine gute Zusammenfassung – „Die Idee hinter Kuryr ist es, die Abstraktion und die ganze harte Arbeit, die in Neutron und seine Plugins und Dienste investiert wurde, zu nutzen und dies zu verwenden, um Produktions-Grade-Netzwerkfunktionen für Container-Anwendungsfälle bereitzustellen. Anstatt jedes unabhängige Neutron-Plugin oder jede Lösung zu versuchen, die Lücken zu finden und zu schließen, können wir die Bemühungen konzentrieren und uns auf einen Punkt konzentrieren – Kuryr. Kuryr zielt darauf ab, die „Integrationsbrücke“ zwischen den beiden Gemeinschaften, Docker (oder einem anderen Container-Engine) und Neutron, zu sein und Änderungen vorzuschlagen und voranzutreiben, die in Neutron (oder in Docker) notwendig sind, um die speziell für Container-Netzwerke benötigten Anwendungsfälle zu erfüllen. Es ist wichtig zu beachten, dass Kuryr keine Netzwerk-Lösung an sich ist und auch nicht versucht, eine zu werden. Die Kuryr-Bemühungen konzentrieren sich darauf, der Kurier zu sein, der Neutron-Netzwerkfunktionen und -Dienste an Docker liefert.“

Kolla
Dies sind OpenStack-Dienste in Produktionsqualität, die als fertige Container geliefert werden. Jeder Entwickler, der dies liest, wird sofort verstehen, wie befähigend das ist – OpenStack als Container bereitgestellt! Für alle, die wie ich die Schmerzen großer Bash-Installationen von OpenStack in Kundendatencentern durchgemacht haben, gilt, wie das D:ream-Song sagt „Things can only get better“… und sie haben sich verbessert. Container sind tatsächlich die Zukunft der Anwendungsbereitstellung. Sie bieten einen konsistenten, codifizierten und damit kontrollierbaren Mechanismus für schnelle Bereitstellungen (oder Rollbacks, falls erforderlich). Diese Kolla-Container-Images werden in Kombination mit dem LOCI-Projekt/-Modul verwendet.

LOCI
„Das Ziel von LOCI ist es, CI/CD-freundliche, leichte OCI-konforme Images und Tooling für OpenStack-Dienste bereitzustellen. Sie können LOCI-Images in einer luftgetrennten Umgebung ohne Modifikation erstellen (unter der Annahme, dass Sie einen Git-, Paket- und PyPI-Spiegel haben).“ Der Telekommunikationssektor, ein großer Adopteur von OpenStack, sieht LOCI als eine wesentliche Komponente an, die die Zukunft von Openstack im Edge-Computing-Bereich vorantreiben wird. Stellen Sie sich Ihren BT-, Virgin Media- oder AT&T-Heimrouter oder Set-Top-Box vor, die einen Container ausführen. Dies würde diesen Unternehmen UND Heimanwendern viel größere Agilität und Flexibilität geben. Sie könnten potenziell Anbieter in Sekunden wechseln, ohne dass neue Hardware erforderlich ist – Win-Win für alle. Für kleine Unternehmen und Edge-Rechenzentren kann dies auch die Notwendigkeit von dedizierten Hardwaregeräten für einzelne Aufgaben beseitigen – IoT, Big Data und staatliche Vorschriften werden das Wachstum im Edge-Compute-Bereich in den kommenden Jahren rasch vorantreiben.

Es gab in diesem Release viele weitere bedeutende Verbesserungen an Openstack, die sich insbesondere auf die GPU-Virtualisierung konzentrierten. Für die vollständigen Details lesen Sie bitte https://www.openstack.org/software/queens/

Happy Stacking!

Graham

Originally published on allthingscloud.eu (2018-04-10).