Dies ist die erste Veröffentlichung in einer Serie von Materialien zu den Änderungen, Verbesserungen und Ergänzungen im bevorstehenden Update der Red Hat OpenShift-Plattform auf Version 4.0, die Ihnen helfen werden, sich auf den Übergang zu der neuen Version vorzubereiten.
Seit dem Moment, als die Vertreter der damals noch in der Entstehung begriffenen Kubernetes-Community im Herbst 2014 im Google-Büro in Seattle zusammenkamen, war bereits zu erkennen, dass Kubernetes das Potenzial hat, die modernen Ansätze zur Softwareentwicklung und -implementierung grundlegend zu verändern. Gleichzeitig investierten öffentliche Cloud-Anbieter weiterhin intensiv in die Entwicklung von Infrastruktur und Services, was die Arbeit im IT-Sektor sowie die Softwareerstellung erheblich erleichterte und vereinfachte. Dies machte Technologien so zugänglich, wie es sich zu Beginn des Jahrzehnts kaum jemand hätte vorstellen können.
Natürlich wurde die Einführung jeder neuen Cloud-Dienstleistung von zahlreichen Experten-Diskussionen auf Twitter begleitet. Die Debatten drehten sich um viele verschiedene Themen, darunter das Ende der Ära der Open-Source-Software, der Niedergang der IT auf der Client-Seite (On-Premises IT), die Unvermeidbarkeit einer neuen Softwaremonopolstellung in der Cloud und wie das neue Paradigma X alle anderen Paradigmen ablösen wird.
Es braucht wohl nicht gesagt zu werden, dass all diese Diskussionen ziemlich absurd waren.
Die Realität ist, dass nichts verloren geht und wir heute ein exponentielles Wachstum von Produktentwicklungen und -methoden beobachten können, was mit dem ständigen Aufkommen neuer Software in unserem Leben zusammenhängt. Und trotz aller Veränderungen bleibt das Wesen der Dinge unverändert. Softwareentwickler werden weiterhin fehlerhaften Code schreiben, Operationsingenieure und Reliability Engineers werden nach wie vor mit Pager unterwegs sein und automatische Benachrichtigungen über Slack erhalten, und Manager werden weiterhin mit den Begriffen OpEx und CapEx hantieren. Und jedes Mal, wenn ein Fehler auftritt, wird der Senior Developer schwer seufzen und sagen: „Ich habe es doch gesagt…“
Was wirklich diskutiert werden sollte, das sind die Werkzeuge, die uns zur Verfügung stehen, um qualitativ hochwertigere Softwareprodukte zu entwickeln und wie sie die Sicherheit erhöhen sowie die Entwicklung einfacher und zuverlässiger machen. Mit der zunehmenden Komplexität von Projekten entstehen auch neue Risiken, und heute sind die Lebensweisen der Menschen stark von Software abhängig, weshalb Entwickler bestrebt sein sollten, ihre Arbeit zu verbessern.
Kubernetes ist eines dieser Werkzeuge. Innerhalb von Red Hat OpenShift wird daran gearbeitet, es mit anderen Werkzeugen und Diensten zu einer integrierten Plattform zu vereinen, die es ermöglichen soll, Software zuverlässiger, leichter zu verwalten und sicherer für die Benutzer zu machen.
Vor diesem Hintergrund stellt sich das OpenShift-Team eine grundlegende Frage:
Wie kann die Arbeit mit Kubernetes einfacher und benutzerfreundlicher gestaltet werden?
Die Antwort ist überraschend offensichtlich:
- komplizierte Aspekte in der Bereitstellung, sowohl in der Cloud als auch vor Ort, zu automatisieren;
- sich auf Zuverlässigkeit zu konzentrieren und dabei die Komplexität zu verbergen;
- fortlaufend daran zu arbeiten, einfache und sichere Aktualisierungen zu veröffentlichen;
- Kontrolle und Auditierbarkeit anstreben;
- von Anfang an hohe Sicherheit gewährleisten, ohne die Benutzerfreundlichkeit zu beeinträchtigen.
Die nächste Version von OpenShift sollte sowohl die Erfahrungen der Entwickler als auch die anderer Entwickler berücksichtigen, die Software in großen Maßstäben in den größten Unternehmen der Welt implementieren. Darüber hinaus muss sie alle gesammelten Erfahrungen offener Ökosysteme einbeziehen, die heute die Grundlage der modernen Welt bilden. Es ist notwendig, sich von der bisherigen Mentalität des Hobby-Entwicklers zu lösen und zu einer neuen Philosophie der automatisierten Zukunft überzugehen. Dies sollte eine "Brücke" zwischen alten und neuen Methoden der Softwarebereitstellung sein und die gesamte verfügbare Infrastruktur vollständig nutzen – unabhängig davon, ob sie von einem großen Cloud-Anbieter bereitgestellt oder auf kleinen Systemen am Rande betrieben wird.
Wie lässt sich ein solches Ergebnis erreichen?
Bei Red Hat ist es üblich, lange und oft mühsame Arbeiten zu erledigen, um die bestehenden Gemeinschaften zu erhalten und die Projekte, an denen das Unternehmen beteiligt ist, nicht zu schließen. In der Open-Source-Community gibt es eine Vielzahl talentierter Entwickler, die die außergewöhnlichsten Dinge schaffen – unterhaltsame, lehrreiche, neue Möglichkeiten eröffnende und einfach schöne Projekte. Natürlich erwartet niemand, dass alle Teilnehmer in dieselbe Richtung gehen oder gemeinsame Ziele verfolgen. Es ist manchmal notwendig, diese Energie zu nutzen und umzuleiten, um Bereiche zu entwickeln, die für unsere Nutzer von Nutzen wären. Gleichzeitig müssen wir das Wachstum unserer Gemeinschaften im Auge behalten und von ihnen lernen.
Anfang 2018 erwarb Red Hat das CoreOS-Projekt, das ähnliche Visionen für die Zukunft hatte – mehr Sicherheit und Zuverlässigkeit, basierend auf Open-Source-Prinzipien. Das Unternehmen arbeitete an der Weiterentwicklung dieser Ideen und deren Umsetzung, um unsere Philosophie zu verwirklichen – die sichere Ausführung aller Software zu gewährleisten. All diese Arbeit basiert auf Kubernetes, Linux, öffentlichen und privaten Cloud-Lösungen sowie Tausenden von anderen Projekten, die die Grundlage unserer modernen digitalen Ekosysteme bilden.
Die neue Version von OpenShift 4 wird intuitiv, automatisiert und benutzerfreundlicher sein.
Die OpenShift-Plattform wird mit den besten und zuverlässigsten Linux-Betriebssystemen arbeiten, unterstützt von Bare-Metal-Hardware, effizienter Virtualisierung, automatisierter Infrastrukturprogrammierung und natürlich Containern (die letztlich einfach Linux-Images sind).
Die Plattform muss von Anfang an sicher sein und gleichzeitig bequeme Iterationen für Entwickler ermöglichen – das bedeutet, dass sie genügend Flexibilität und Zuverlässigkeit bieten sollte, während sie den Administratoren Auditmöglichkeiten und eine komfortable Verwaltung erlaubt.
Sie sollte die Ausführung von Software als Dienst ermöglichen, ohne dass die Infrastruktur für Betreiber unkontrolliert wächst.
So können sich Entwickler darauf konzentrieren, echte Produkte für Benutzer und Kunden zu schaffen. Es wird nicht nötig sein, sich durch ein Dickicht von Hardware- und Softwareeinstellungen zu kämpfen, und alle unerwarteten Komplikationen gehören der Vergangenheit an.
OpenShift 4: Eine NoOps-Plattform, die keine Wartung erfordert
In In diesem Abschnitt werden die Herausforderungen beschrieben, die dazu beigetragen haben, die Unternehmensvision in Bezug auf OpenShift 4 zu entwickeln. Das Team hat die Aufgabe, alltägliche Betriebs- und Wartungsaufgaben so weit wie möglich zu vereinfachen, um diese Prozesse für die Fachleute, die Implementierungen durchführen, sowie für die Entwickler angenehm und unkompliziert zu gestalten. Aber wie kann dieses Ziel erreicht werden? Wie kann eine Plattform geschaffen werden, die die Ausführung von Software mit minimalem Eingriff ermöglicht? Was bedeutet NoOps in diesem Zusammenhang überhaupt?
Wenn man versucht, abstrahierend zu denken, dann bedeuten die Begriffe „serverless“ oder „NoOps“ für Entwickler Werkzeuge und Dienstleistungen, die es ermöglichen, die „betriebliche“ Komponente zu verbergen oder die Last für den Entwickler zu minimieren.
- Arbeiten Sie nicht mit Systemen, sondern mit Anwendungsprogrammierschnittstellen (APIs).
- Kümmern Sie sich nicht um die Softwareimplementierung – lassen Sie dies von dem Anbieter übernehmen.
- Beginnen Sie nicht sofort mit der Entwicklung eines umfangreichen Frameworks – starten Sie mit kleinen Fragmenten, die als "Bausteine" fungieren. Achten Sie darauf, dass dieser Code mit Daten und Ereignissen arbeitet und nicht mit Festplatten oder Datenbanken.
Das Ziel bleibt wie zuvor, die Iterationen bei der Softwareentwicklung zu beschleunigen, um qualitativ hochwertigere Produkte zu schaffen, während die Entwickler sich keine Sorgen um die Systeme machen müssen, auf denen ihre Software läuft. Ein erfahrener Entwickler weiß, dass sich der Fokus auf die Nutzer schnell auf das Gesamtbild auswirken kann. Deshalb sollte man nicht zu viel Energie in die Softwareentwicklung investieren, wenn man nicht absolut sicher ist, dass sie notwendig ist.
Für Fachleute, die mit Wartung und Betrieb beschäftigt sind, kann der Begriff „NoOps“ etwas beängstigend klingen. Im Gespräch mit Betriebstechnikern wird jedoch schnell deutlich, 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:
- Managen Sie keine Systeme – automatisieren Sie die Verwaltung Ihrer Prozesse.
- Kümmern Sie sich nicht um die Softwareimplementierung – erstellen Sie einen Pipeline für deren Bereitstellung.
- Vermeiden Sie es, alle Ihre Dienste zu bündeln, und lassen Sie nicht zu, dass der Ausfall eines einzelnen Dienstes zum Ausfall des gesamten Systems führt – verteilen Sie sie in der Infrastruktur, nutzen Sie Automatisierungswerkzeuge und verbinden Sie sie mit der Möglichkeit der Überwachung und Kontrolle.
SRE-Experten wissen, dass etwas schiefgehen kann, und sie müssen Probleme überwachen und beheben – deshalb automatisieren sie Routineaufgaben und legen im Voraus akzeptable Abweichungen fest (Error Budgets), um auf Prioritäten und Entscheidungen im Falle von Problemen vorbereitet zu sein.
Kubernetes auf OpenShift ist eine Plattform, die zwei Hauptaufgaben löst: Anstatt sich mit virtuellen Maschinen oder APIs von Lastverteilern auseinanderzusetzen, arbeitet man mit höheren Abstraktionen – Deployment-Prozessen und Services. Anstelle von Software-Agents können Container gestartet werden, und statt einen eigenen Monitoring-Stack zu entwickeln, nutzt man die bereits in der Plattform verfügbaren Tools. Das geheime Erfolgsrezept von OpenShift 4 ist also kein Geheimnis – man muss einfach die Prinzipien des SRE und serverless Konzepte als Grundlage nehmen und sie zu Ende denken, um Entwicklern und Betriebsteams zu helfen:
- Automatisieren und Standardisieren der Infrastruktur, die von Anwendungen genutzt wird.
- Entwicklungs- und Bereitstellungsprozesse miteinander verbinden, ohne die Entwickler selbst einzuschränken.
- Sicherstellen, dass das Starten, Auditeren und Sichern des hundertsten Services, der Funktion, Anwendung oder des gesamten Stacks nicht schwieriger ist als beim ersten.
Was unterscheidet die Plattform OpenShift 4 von ihren Vorgängern und dem "Standard"-Ansatz zur Lösung ähnlicher Herausforderungen? Wie gelingt es, Teams, die mit Implementierung und Betrieb beschäftigt sind, zu skalieren? Indem der Cluster im Mittelpunkt steht. Also,
- Wir sorgen dafür, dass der Zweck von Clustern klar ist (Teure Cloud, ich habe diesen Cluster erstellt, weil ich es konnte)
- Maschinen und Betriebssysteme existieren, um den Cluster (Eure Majestät) zu unterstützen.
- Verwalten Sie den Zustand der Hosts aus dem Cluster und minimieren Sie deren Drift.
- Für jedes wichtige Element des Systems braucht es eine Aufsicht (einen Mechanismus), der Probleme überwacht und löst.
- Der Ausfall *jedes* Aspekts oder Elements des Systems und die entsprechenden Wiederherstellungsmechanismen sind ein normaler Teil des Lebens.
- Die gesamte Infrastruktur muss über APIs konfiguriert werden.
- Verwenden Sie Kubernetes zur Ausführung von Kubernetes. (Ja, das ist kein Tippfehler)
- Updates sollten einfach und mühelos installiert werden. Wenn zur Installation eines Updates mehr als ein Mausklick erforderlich ist, machen wir offensichtlich etwas falsch.
- Die Überwachung und Fehlersuche jeder Komponente sollte kein Problem darstellen, und daher sollte auch die Nachverfolgung und Berichterstattung über die gesamte Infrastruktur einfach und benutzerfreundlich sein.
Möchten Sie die Möglichkeiten der Plattform in Aktion sehen?
Die Vorabversion von OpenShift 4 ist jetzt für Entwickler verfügbar. Mit einem benutzerfreundlichen Installer können Sie einen Cluster auf AWS über Red Hat CoreOS starten. Um die Vorabversion zu nutzen, benötigen Sie lediglich ein AWS-Konto, um die Infrastruktur bereitzustellen, und eine Reihe von Konten für den Zugriff auf die Vorabversion-Bilder.
- Um zu beginnen, besuchen Sie und klicken Sie auf „Get Started“.
- Melden Sie sich bei Ihrem Red Hat-Konto an (oder erstellen Sie ein neues) und folgen Sie den Anweisungen, um Ihren ersten Cluster einzurichten.
Nachdem die Installation erfolgreich abgeschlossen ist, werfen Sie einen Blick in unsere Schulungsmaterialien , um einen detaillierteren Einblick in die Systeme und Konzepte zu erhalten, die OpenShift 4 zu einem so einfachen und benutzerfreundlichen Tool für den Betrieb von Kubernetes machen.
Testen Sie die neue Version von OpenShift und teilen Sie uns Ihre Meinung mit. Wir setzen alles daran, die Nutzung von Kubernetes so einfach und mühelos wie möglich zu gestalten – die Zukunft von NoOps beginnt bereits heute.
Achtung!
Auf der Konferenz Am 20. April wird einer der Entwickler von OpenShift, Vadim Rutkovsky, einen Workshop leiten – er wird zehn Cluster kaputt machen und wir werden sie reparieren. 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, während der Stand den ganzen Tag geöffnet ist. T-Shirts, Hüte, Aufkleber – wie gewohnt!
Saal #2
Hier muss das gesamte System überarbeitet werden: Wir reparieren kaputte k8s-Cluster gemeinsam mit zertifizierten Technikern.
Quelle: habr.com
