Dies ist die erste Veröffentlichung in einer Reihe von Materialien, die sich mit den Änderungen, Verbesserungen und Ergänzungen im bevorstehenden Update der Red Hat OpenShift-Plattform auf 4.0 befassen, die helfen werden, sich auf den Übergang zur neuen Version vorzubereiten.
Von dem Moment an, als die Vertreter der gerade erst entstehenden Kubernetes-Community im Herbst 2014 zum ersten Mal im Google-Büro in Seattle zusammentrafen, war schon abzusehen, dass das Kubernetes-Projekt die modernen Ansätze zur Softwareentwicklung und -bereitstellung grundlegend verändern würde. Gleichzeitig setzten öffentliche Cloud-Anbieter weiterhin kräftig auf den Ausbau der Infrastruktur und die Entwicklung von Dienstleistungen, was die Arbeit mit IT und die Softwareerstellung erheblich erleichterte und zugänglicher machte, was sich zu Beginn des Jahrzehnts kaum jemand hätte vorstellen können.
Es versteht sich von selbst, dass die Ankündigung jedes neuen Cloud-Dienstes von zahlreichen Experten-Diskussionen auf Twitter begleitet wurde, wobei die Debatten über die unterschiedlichsten Themen geführt wurden – unter anderem über das Ende des Zeitalters des Open Source, den Niedergang der On-Premises-IT, die Unvermeidlichkeit einer neuen Softwaremonopolstellung in der Cloud und darüber, wie das neue Paradigma X alle anderen Paradigmen ablösen wird.
Es ist überflüssig zu sagen, dass all diese Diskussionen ziemlich töricht waren.
Die Realität ist, dass nichts einfach verschwinden wird, und heute kann man ein exponentielles Wachstum von Endprodukten und deren Entwicklungsmethoden beobachten, was mit dem ständigen Erscheinen neuer Software in unserem Leben zusammenhängt. Und trotz aller Veränderungen wird im Wesentlichen alles gleich bleiben. Softwareentwickler werden weiterhin fehlerhaften Code schreiben, Operations- und Reliability-Ingenieure werden weiterhin mit Paging-Systemen arbeiten und automatische Benachrichtigungen in Slack erhalten, Manager werden nach wie vor mit den Begriffen OpEx und CapEx hantieren, und jedes Mal, wenn ein Fehler auftritt, wird der leitende Entwickler traurig seufzen und sagen: „Ich habe es doch gesagt…“
Was wirklich diskutiert werden sollte, so ist das, welche Werkzeuge wir erhalten können, um qualitativ hochwertigere Softwareprodukte zu erstellen, und wie sie die Sicherheit erhöhen und die Entwicklung einfacher und zuverlässiger gestalten. Mit zunehmender Komplexität der Projekte entstehen auch neue Risiken, und heute hängen die Lebensweisen der Menschen so stark von der Software ab, dass Entwickler einfach verpflichtet sind, ihre Arbeiten zu verbessern.
Kubernetes ist eines dieser Werkzeuge. Es wird daran gearbeitet, es im Rahmen von Red Hat OpenShift mit anderen Tools und Dienstleistungen in einer einzigen Plattform zu vereinen, die es ermöglichen würde, Software zuverlässiger, benutzerfreundlicher und sicherer für die Anwender zu machen.
Vor diesem Hintergrund stellt sich das OpenShift-Team eine einfache Frage:
Wie kann die Arbeit mit Kubernetes einfacher und benutzerfreundlicher gestaltet werden?
Die Antwort ist überraschend offensichtlich:
- komplizierte Punkte im Cloud- oder On-Premise-Deployment zu automatisieren;
- den Fokus auf Zuverlässigkeit zu legen und dabei die Komplexität zu verbergen;
- konstante Anstrengungen zu unternehmen, um einfache und sichere Updates zu veröffentlichen;
- Kontrollierbarkeit und Auditierbarkeit zu gewährleisten;
- von Anfang an hohe Sicherheit zu bieten, jedoch nicht auf Kosten der Benutzerfreundlichkeit.
Die nächste Version von OpenShift sollte sowohl die Erfahrungen von Entwicklern als auch die der anderen Entwickler berücksichtigen, die in großem Maßstab Software in den größten Unternehmen der Welt implementieren. Außerdem muss sie alle gesammelten Erfahrungen von offenen Ökosystemen berücksichtigen, die heute die Grundlage der modernen Welt bilden. Dabei ist es notwendig, sich von der alten Mentalität des Amateurentwicklers zu lösen und zu einer neuen Philosophie der automatisierten Zukunft überzugehen. Es muss eine ‚Brücke‘ zwischen den alten und neuen Methoden der Softwarebereitstellung geschlagen werden und die gesamte verfügbare Infrastruktur vollständig genutzt werden – unabhängig davon, ob sie von einem großen Cloud-Anbieter verwaltet wird oder auf winzigen Systemen am Rande läuft.
Wie erreicht man ein solches Ergebnis?
Bei Red Hat ist es üblich, lange geduldige und undankbare Arbeit zu leisten, um die gewachsene Gemeinschaft zu erhalten und die Schließung von Projekten, an denen das Unternehmen beteiligt ist, zu verhindern. In der Open-Source-Community gibt es eine riesige Menge talentierter Entwickler, die die außergewöhnlichsten Dinge schaffen – unterhaltsame, lehrreiche, neue Möglichkeiten eröffnende und einfach schöne Sachen. Niemand erwartet jedoch, dass alle Beteiligten in die gleiche Richtung gehen oder gemeinsame Ziele verfolgen. Es ist manchmal notwendig, diese Energie zu nutzen und sie in die richtigen Bahnen zu lenken, um Entwicklungen voranzutreiben, die unseren Nutzern nützlich wären, während wir gleichzeitig die Entwicklung unserer Gemeinschaften im Auge behalten und von ihnen lernen sollten.
Anfang 2018 erwarb Red Hat das Projekt CoreOS, das ähnliche Ansichten über die Zukunft hatte – sicherer und zuverlässiger, basierend auf Open-Source-Prinzipien. Das Unternehmen arbeitete an der Weiterentwicklung dieser Ideen und deren Umsetzung, um unsere Philosophie in die Tat umzusetzen – den sicheren Betrieb aller Software zu erreichen. Diese ganze Arbeit basiert auf Kubernetes, Linux, öffentlichen Clouds, privaten Clouds und Tausenden anderen Projekten, die das Fundament unseres modernen digitalen Ökosystems bilden.
Die neue Version von OpenShift 4 wird verständlich, automatisiert und natürlicher sein.
Die OpenShift-Plattform wird mit den besten und zuverlässigsten Linux-Betriebssystemen, mit Bare-Metal-Hardwareunterstützung, benutzerfreundlicher Virtualisierung, automatisierter Infrastrukturprogrammierung und selbstverständlich mit Containern (die im Grunde genommen nur Linux-Images sind) arbeiten.
Die Plattform muss von Anfang an sicher sein, dabei jedoch Entwicklern bequeme Iterationen ermöglichen – das heißt, sie muss ausreichend Flexibilität und Zuverlässigkeit bieten und gleichzeitig Administratoren erlauben, Audits durchzuführen und die Verwaltung zu erleichtern.
Sie muss es ermöglichen, Software als Dienst auszuführen, ohne dass die Infrastruktur für Betreiber unkontrollierbar wächst.
Es ermöglicht Entwicklern, sich auf die Erstellung echter Produkte für Benutzer und Kunden zu konzentrieren. Sie müssen sich nicht durch das Dickicht der Hardware- und Softwareeinstellungen kämpfen, und alle zufälligen Komplikationen gehören der Vergangenheit an.
OpenShift 4: NoOps-Plattform, die keine Unterstützung benötigt
Im wurden die Aufgaben beschrieben, die dazu beigetragen haben, die Vision des Unternehmens in Bezug auf OpenShift 4 zu formen. Das Team hat die Aufgabe, tägliche Betriebs- und Wartungsaufgaben so weit wie möglich zu vereinfachen und diese Prozesse sowohl für Implementierungsspezialisten als auch für Entwickler leicht und mühelos zu gestalten. Aber wie kann man diesem Ziel näher kommen? Wie schafft man eine Software-Plattform, die minimalen Eingriff erfordert? Was bedeutet NoOps in diesem Kontext überhaupt?
Wenn man versucht, abstrahiert zu denken, bedeuten die Begriffe „serverless“ oder „NoOps“ für Entwickler Werkzeuge und Dienste, die es ermöglichen, die „Betriebs“-Komponente zu verbergen oder diese Last für den Entwickler zu minimieren.
- Arbeiten Sie nicht mit Systemen, sondern mit Anwendungsschnittstellen (API).
- Kümmern Sie sich nicht um die Implementierung von Software – lassen Sie stattdessen den Anbieter dies übernehmen.
- Es sollte nicht sofort ein großes Framework entwickelt werden – beginnen Sie mit dem Schreiben kleiner Fragmente, die als „Bausteine“ fungieren, und achten Sie darauf, dass dieser Code mit Daten und Ereignissen und nicht mit Festplatten und Datenbanken arbeitet.
Die Aufgabe besteht nach wie vor darin, die Iterationen bei der Entwicklung von Software zu beschleunigen, die Möglichkeit zur Erstellung qualitativ besserer Produkte zu gewährleisten und dabei sicherzustellen, dass der Entwickler sich keine Sorgen über die Systeme machen muss, auf denen seine Software läuft. Ein erfahrener Entwickler weiß genau, dass sich die Situation schnell ändern kann, wenn man sich auf die Benutzer konzentriert. Daher sollte nicht zu viel Mühe in die Softwareentwicklung investiert werden, wenn man sich nicht absolut sicher ist, dass sie notwendig ist.
Für Fachleute, die mit der Wartung und dem Betrieb beschäftigt sind, kann das Wort „NoOps“ etwas beängstigend klingen. Doch beim Austausch mit Betriebstechnikern wird offensichtlich, dass die von ihnen verwendeten Muster und Methoden zur Gewährleistung der Zuverlässigkeit (Site Reliability Engineering, SRE) in vielerlei Hinsicht mit den oben beschriebenen Mustern übereinstimmen:
- Verwalten Sie keine Systeme – automatisieren Sie die Verwaltung ihrer Prozesse.
- Kümmern Sie sich nicht um die Implementierung von Software – erstellen Sie eine Pipeline für deren Bereitstellung.
- Versuchen Sie, Ihre Dienste nicht zu bündeln und zu vermeiden, dass der Ausfall eines von ihnen den Ausfall des gesamten Systems verursacht – verteilen Sie sie über die gesamte Infrastruktur hinweg mithilfe von Automatisierungstools und verbinden Sie sie unter Berücksichtigung von Kontroll- und Überwachungsmöglichkeiten.
SRE-Experten wissen, dass etwas schiefgehen kann, und sie müssen das Problem überwachen und beheben – deshalb automatisieren sie Routinearbeiten und legen im Voraus fest, welche Abweichungen akzeptabel sind (Error Budgets), um auf Priorisierungen und Entscheidungen bei Problemen vorbereitet zu sein.
Kubernetes in OpenShift ist eine Plattform, die zwei Hauptziele verfolgt: Anstatt Sie zu zwingen, sich mit virtuellen Maschinen oder APIs von Lastenausgleichssystemen auseinanderzusetzen, arbeitet sie mit Abstraktionen höherer Ordnung – mit Bereitstellungsprozessen und Diensten. Statt Software-Agenten zu installieren, können Container gestartet werden, und anstelle eines eigenen Überwachungsstapels können vorhandene Werkzeuge der Plattform verwendet werden. So ist die geheime Zutat von OpenShift 4 eigentlich kein Geheimnis – es gilt lediglich, die Prinzipien von SRE und serverlose Konzepte zu übernehmen und sie bis zum Ende zu bringen, um Entwicklern und Betriebstechnikern zu helfen:
- Automatisieren und Standardisieren der Infrastruktur, die von Anwendungen verwendet wird.
- Die Prozesse der Bereitstellung und Entwicklung miteinander verbinden, ohne die Entwickler einzuschränken.
- Dafür sorgen, dass der Start, die Überprüfung und die Sicherheit des hundertsten Dienstes, der Funktion, der Anwendung oder des gesamten Stacks nicht schwieriger sind als die des ersten.
Aber was unterscheidet die Plattform OpenShift 4 von ihren Vorgängern und dem "Standard"-Ansatz zur Lösung solcher Probleme? Wie wird die Skalierung für Teams, die implementieren und betreiben, erreicht? Wichtig in dieser Situation ist der Cluster. Also,
- Lassen Sie uns dafür sorgen, dass der Zweck der Cluster klar ist (Teures Cloud, ich habe diesen Cluster erstellt, weil ich es konnte)
- Maschinen und Betriebssysteme existieren, um den Cluster zu bedienen (Eure Majestät)
- Verwalten Sie den Zustand der Hosts vom Cluster aus und minimieren Sie deren Drift.
- Für jedes wichtige Element des Systems ist eine Aufsicht nötig (mechanismus), der Probleme überwacht und behebt
- Ein Ausfall *jedes* Aspekts oder Elements des Systems erfordert entsprechende Wiederherstellungsmechanismen – das ist ein ganz normaler Teil des Lebens
- Die gesamte Infrastruktur sollte über APIs konfiguriert werden.
- Verwenden Sie Kubernetes, um Kubernetes zu betreiben. (Ja, das ist kein Tippfehler)
- Updates sollten einfach und unkompliziert installiert werden. Wenn die Installation eines Updates mehr als einen Mausklick erfordert, machen wir offensichtlich etwas falsch.
- Das Überwachen und Debuggen jeder Komponente sollte keine Probleme bereiten, und damit sollte auch das Nachverfolgen und Berichten über die gesamte Infrastruktur einfach und benutzerfreundlich sein.
Möchten Sie die Möglichkeiten der Plattform in der Praxis sehen?
Die Vorabversion von OpenShift 4 ist für Entwickler verfügbar. Mit einem einfach zu bedienenden Installer kann ein Cluster auf AWS über Red Hat CoreOS gestartet werden. Um die Vorabversion nutzen zu können, benötigen Sie lediglich ein AWS-Konto zur Bereitstellung der Infrastruktur und eine Reihe von Konten für den Zugriff auf die Vorabversion-Images.
- Um zu beginnen, gehen Sie zu und klicken Sie auf „Loslegen“.
- Melden Sie sich bei Ihrem Red Hat-Konto an (oder erstellen Sie ein neues) und folgen Sie den Anweisungen, um Ihren ersten Cluster einzurichten.
Nach einer erfolgreichen Installation werfen Sie einen Blick auf unsere Schulungsmaterialien , um einen detaillierteren Einblick in die Systeme und Konzepte zu erhalten, die die Plattform OpenShift 4 zu einem so einfachen und benutzerfreundlichen Werkzeug zur Ausführung von Kubernetes machen.
Probieren Sie die neue Version von OpenShift aus und teilen Sie uns Ihre Meinung mit. Wir streben an, die Arbeit mit Kubernetes so zugänglich und mühelos wie möglich zu gestalten – die Zukunft von NoOps beginnt schon heute.
Jetzt aufgepasst!
Auf der Konferenz Am 20. April wird einer der Entwickler von OpenShift, Vadim Rutkovski, einen Workshop leiten – dabei werden zehn Cluster durch die Decke gehen und wieder repariert werden. Die Konferenz ist kostenpflichtig, aber mit dem Promo-Code #RedHat erhalten Sie 37 % Rabatt.
Der Workshop findet von 17:15 bis 18:15 Uhr statt, und der Stand ist den ganzen Tag geöffnet. T-Shirts, Hüte, Aufkleber – wie gewohnt!
Saale #2
„Hier muss das gesamte System geändert werden: Wir reparieren defekte k8s-Cluster zusammen mit zertifizierten Fachleuten.“
Quelle: habr.com
