Im Gegensatz zum vorherigen und ebenso revolutionären Übergang von Bare-Metal- zu virtuellen Maschinen reduzieren Container die Redundanz des Software-Stacks erheblich und verändern die Art der Betriebssystemverwaltung im Unternehmen.
Viele entscheiden sich dafür, ihre Migration auf Container mit der Red Hat OpenShift Container Platform, der branchenführenden Kubernetes-Plattform für den Unternehmenssektor, zu beschleunigen. Diese Lösung übernimmt automatisch viele Aufgaben des ersten Tages und bietet das beste Kubernetes-Ökosystem auf der Grundlage einer einzigen, gründlich getesteten und hochsicheren Plattform. Dies ist die umfassendste und funktionalste Lösung für Unternehmen, die alles enthält, was Sie für den Einstieg benötigen, und viele technische Hindernisse und Komplexitäten beim Aufbau einer Kubernetes-Plattform beseitigt.
OpenShift ist jedoch kein Zauberstab, der alle Probleme selbst löst. Ja, dank ihrer Fähigkeiten kann diese Plattform ihren Kunden viele Vorteile bringen und zahlt sich schnell aus, vorausgesetzt, Sie haben zum Zeitpunkt ihrer Einführung einen gut durchdachten Plan. Um erfolgreich zu sein, müssen sieben Bereiche sorgfältig geprüft werden, bevor Workloads auf OpenShift verschoben werden.
1. Standardisierung von Namensregeln und Metadaten
In der Informatik gibt es nur zwei schwierige Dinge: Ungültigmachen des Caches und Benennen von Entitäten.
- Phil Karlton
Jede Entität in OpenShift und Kubernetes hat ihren eigenen Namen. Und jeder Dienst muss seinen eigenen DNS- Namen haben. Die einzige Einschränkung hierbei sind die DNS-Namensregeln. Stellen Sie sich nun vor, dass eine monolithische Anwendung in 100.500 separate Mikrodienste mit jeweils einer eigenen Datenbank zerlegt wurde. Und ja, in OpenShift ist alles entweder hierarchisch, verwandt oder muss einem Muster folgen. Also muss die Masse und Masse von allem benannt werden. Und wenn Sie Standards nicht im Voraus vorbereiten, wird sich herausstellen, dass es sich um einen echten Wilden Westen handelt.
Haben Sie das Service-Implementierungsschema bereits geplant? Angenommen, es handelt sich um einen großen Namespace, z. B. "Datenbanken", in dem jeder seine Datenbanken hostet. OK, und nehmen wir sogar an, dass dies jeder tut, aber dann beginnen sie, ihre Kafka-Cluster in ihren eigenen Namespaces zu hosten. Ja, aber müssen Sie einen Namespace "Middleware" erstellen? Oder ist es besser, es "Messaging" zu nennen? Und wie immer gibt es irgendwann Leute, die immer ihren eigenen Weg gehen und sich als etwas Besonderes betrachten und sagen, sie brauchen ihre eigenen Namespaces. Und hören Sie, wir haben 17 Abteilungen in der Organisation. Vielleicht müssen wir unsere Standardabteilungspräfixe an alle Namespaces anhängen.
Berücksichtigen Sie Namens- und Sortierstandards, bevor Sie etwas in die Produktion aufnehmen. Sie können viel Zeit und Mühe sparen, wenn Sie dies im Voraus tun. Setzen Sie Maßstäbe für alles. Darüber hinaus ist hier nicht so sehr ihre Qualität wichtig, sondern ihre Verfügbarkeit, Integrität und Umsetzung.
Eine weitere äußerst nützliche Sache sind Metadaten . Standardisieren Sie, welche Assets Sie verfolgen möchten, und stellen Sie sicher, dass die richtigen Metadaten auf den richtigen Ressourcen geschrieben sind. Beginnen Sie mit den empfohlenen Etiketten... Wenn Sie beispielsweise "support_email" in den Namespace-Metadaten mit Anmerkungen versehen, können Sie wertvolle Zeit sparen, wenn Sie sich bei einem schwerwiegenden Fehler an den Tier 2-Support wenden. Darüber hinaus können Metadaten verwendet werden, um Ressourcennamen auf eine sinnvolle Länge zu kürzen, anstatt alle erforderlichen Informationen dort zu trennen. Binden Sie alle, von Anwendungsarchitekten bis hin zu IT-Betreibern, ein Brainstorming ein und finden Sie heraus, was erforderlich sein kann, um beim Start von OpenShift solide Standards zu haben.
2. Standardisierung von Unternehmensbasisbildern
Eines der Hauptmerkmale von Containern ist die Fähigkeit, alle Teile des Software-Stacks zu mischen und anzupassen. Sie können natürlich Ihr Lieblingsbetriebssystem verwenden und alles darauf aufbauen, aber wenn Sie sich so verhalten, verpasst die Organisation große Chancen. Was ist eigentlich cool an Container-Bildern? Schichtung. Sie können viele wichtige Aufgaben von Entwicklern entfernen und lösen, indem Sie Bilder standardisieren.
Nehmen Sie zum Beispiel eine einfache Java-Anwendung. Es ist unwahrscheinlich, dass Ihre Entwickler mit OpenJDK etwas falsch machen Aber mit dem Management von Schwachstellen, der Aktualisierung von Bibliotheken und anderen Fragen der IT-Hygiene können sie. Wir alle wissen, dass geschäftliche Probleme häufig auf Kosten technischer Kompromisse gelöst werden, beispielsweise durch die gezielte Verwendung älterer Java-Versionen. Glücklicherweise lassen sich diese Aufgaben leicht automatisieren und auf Unternehmensebene verwalten. Sie können weiterhin die Basis-Images des Anbieters verwenden , aber gleichzeitig Ihre Aktualisierungszyklen festlegen und steuern, indem Sie Ihre eigenen Basis-Images erstellen.
Zurück zum obigen Beispiel: Nehmen wir an, Entwickler möchten Java 11 und möchten, dass sie immer die neueste Version von Java 11 verwenden. Anschließend erstellen Sie ein Unternehmens-Basisimage (registry.yourcompany.io/java11) als Ausgangspunkt Basisimage des Betriebssystemherstellers (registry.redhat.io/ubi8/openjdk-11). Wenn dieses Basisimage aktualisiert wird, helfen Sie Entwicklern automatisch bei der Implementierung der neuesten Updates. Darüber hinaus bietet dies eine Abstraktionsschicht, mit der Sie das Standardimage nahtlos mit den erforderlichen Bibliotheken oder Linux-Paketen erweitern können.
3. Standardisierung von Gesundheits- und Bereitschaftsprüfungen
Die Überwachung der Wartungsfreundlichkeit wird fast überall benötigt. Es wird angenommen, dass eine jährliche ärztliche Untersuchung für eine Person ausreichend ist. Der Zustand von Anwendungen sollte natürlich viel häufiger überprüft und zwei wichtige Dinge überwacht werden:
- Gibt an, ob die Anwendung ausgeführt wird (Integritätsprüfung).
- Ob die Anwendung bereit ist (Bereitschaftsprüfung).
Es gibt unzählige andere Metriken, die die Überwachung von Anwendungen vereinfachen. Diese beiden Metriken bilden jedoch nicht nur die Grundlage für die Überwachung, sondern auch für die Skalierung. Der Zustand wird normalerweise durch die Netzwerkkonnektivität und die Fähigkeit des Hosts bestimmt, auf dem die Anwendung ausgeführt wird, auf eine Anfrage zu antworten. In Bezug auf die Bereitschaft muss hier bereits jede Anwendung auf Anfragen nach ihren eigenen Standards reagieren. Das Starten einer Anwendung mit sehr geringer Latenz kann beispielsweise zu einer längeren Cache-Aktualisierung oder zum Aufwärmen der JVM führen . Dementsprechend kann die Pause zwischen den Antworten "Gestartet" und "Bereit" mehrere Minuten betragen. Bei einer zustandslosen REST-API mit einer relationalen Datenbank werden diese Antworten jedoch gleichzeitig angezeigt.
Das Wichtigste bei diesen Prüfungen ist, nicht von der rein binären Logik abzuweichen. Gestartet bedeutet gestartet, ohne dass dort irgendeine "Art von gestartet" wird. Fertig bedeutet bereit, und es gibt keine Abstufungen wie "bereit, solche Anfragen zu beantworten, aber keine solchen Anfragen". Das Prinzip ist einfach: alles oder nichts.
Der zweite Aspekt dieser Prüfungen ist die Standardisierung. Wie überprüfe ich die Bereitschaft? Wenn Sie keine Standards haben, kann selbst eine so einfache Frage ein wahrer Überwachungsalptraum sein. Vergleichen Sie einfach, wie die Quarkus- Standards und die Spring Boot- Standards voneinander abweichen . Aber das wollte niemand, aber Standards sind immer der Fall. Der einzige Unterschied besteht darin, dass Ihr Unternehmen jetzt die Möglichkeit hat, Standards festzulegen und durchzusetzen.
Beachten Sie am Rand. Erfinde keine eigenen Standards. Finden und verwenden Sie einfach eine fertige .
4. Standardisierung von Protokollen
Wir setzen das Thema Überwachung fort und stellen fest, dass die Kombination aus kostengünstigen Speichern und Big-Data-Lösungen ein neues Monster in Unternehmen hervorgebracht hat - die vollständige Protokollierung. Bisher waren dies unstrukturierte und archaische Konsolenprotokolle, die nicht lange lebten und von Zeit zu Zeit erstellt wurden. Jetzt bemühen sie sich, alles zu protokollieren und Data Science mit maschinellem Lernen aufzubauen, um den Betrieb und die Überwachung auf revolutionärste Weise zu optimieren. Leider müssen wir das Offensichtliche zugeben: Jeder Versuch, Protokolle von Hunderten von Anwendungen zu sammeln, ohne absolut irgendwelche Standards zu haben und ohne darüber nachzudenken, führt ausnahmslos zu sinnlosen und exorbitanten Ausgaben für Tools zur Verwaltung von Protokollen und zur Datentransformation, um loszulegen Arbeit. Das heißt, noch bevor Sie verstehendass die Meldungen "Übergang abgeschlossen" oder "Dieser Block ausgelöst" wahrscheinlich nichts mit Ihren Vorgängen zu tun haben.
Die Struktur muss standardisiert werden. Auch hier ist die Integrität der Standards wichtiger als ihre Richtigkeit. Sie sollten in der Lage sein, für jede Anwendung im Unternehmen einen separaten Protokollparser zu schreiben. Ja, dies sind reine, nicht replizierte Dinge. Ja, es gibt eine Reihe von Ausnahmen, die nicht kontrolliert werden können, insbesondere für Box-Anwendungen. Aber werfen Sie das Baby nicht mit dem Wasser hinaus, achten Sie auf die Details: Zum Beispiel muss der Zeitstempel in jedem Protokoll dem entsprechenden ISO-Standard entsprechen . Die Ausgabe selbst muss in UTC mit einer Genauigkeit der 5. Dezimalstelle in Mikrosekunden erfolgen (2018-11-07T00: 25: 00.07387Z). Die Protokollebenen sollten mit CAPS ausgegeben werden und es sollten Elemente TRACE, DEBUG, INFO, WARN, ERROR vorhanden sein. Legen Sie im Allgemeinen die Struktur fest und beschäftigen Sie sich erst dann mit den Details.
Die strukturelle Standardisierung zwingt alle dazu, sich an dieselben Regeln zu halten und dieselben Architekturmuster zu verwenden. Dies gilt sowohl für Anwendungs- als auch für Plattformprotokolle. Und weichen Sie nicht von einer vorgefertigten Lösung ab, es sei denn, dies ist unbedingt erforderlich. Der EFK-Stack (Elasticsearch, Fluentd und Kibana) der OpenShift-Plattform sollte in der Lage sein, alle Ihre Skripte zu verarbeiten. Immerhin hat er die Plattform aus einem bestimmten Grund betreten, und wenn sie aktualisiert wird, ist dies eine weitere Sache, über die Sie sich keine Sorgen machen müssen.
5. Wechseln zu GitOps
Eines der großartigen Dinge an OpenShift ist, dass alles hier - wörtlich: alles - letztendlich entweder Konfiguration oder Code ist, was bedeutet, dass es über ein Versionskontrollsystem gesteuert werden kann. Auf diese Weise können Sie die Liefermethoden revolutionieren und Bürokratie beim Start in die Produktion abbauen.
Insbesondere kann das traditionelle Ticket-basierte Schema vollständig durch ein Modell mit Git-Pull-Anforderungen ersetzt werden.... Angenommen, der Anwendungseigentümer möchte die der Anwendung zugewiesenen Ressourcen anpassen, nachdem er neue Funktionen implementiert hat, z. B. indem der Speicher von 8 GB auf 16 GB erhöht wird. Im herkömmlichen Schema muss ein Entwickler ein Ticket erstellen und warten, bis eine andere Person die entsprechende Aufgabe erledigt hat. Diese andere Person ist meistens ein IT-Betreiber, der nur eine spürbare Verzögerung in den Prozess der Implementierung von Änderungen einführt, ohne den Wert dieses Prozesses zu erhöhen oder schlimmer noch, unnötige zusätzliche Zyklen zu diesem Prozess hinzuzufügen. In der Tat hat der Bediener zwei Möglichkeiten. Zunächst überprüft er die Anwendung und beschließt, sie auszuführen, für die er in die Produktionsumgebung eintritt, die angeforderten Änderungen manuell vornimmt und die Anwendung neu startet.
Zusätzlich zu der Zeit, um die Arbeit selbst auszuführen, gibt es hier eine zusätzliche Verzögerung, da der Bediener in der Regel immer eine ganze Warteschlange von Ausführungsanforderungen hat. Darüber hinaus besteht das Risiko menschlicher Fehler, z. B. 160 GB anstelle von 16 GB. Die zweite Option: Der Betreiber bezweifelt die Anwendung und löst damit eine Kettenreaktion aus, um die Gründe und Folgen der angeforderten Änderungen herauszufinden, so dass die Behörden manchmal eingreifen müssen.
Nun wollen wir sehen, wie das in GitOps gemacht wird. Die Änderungsanforderung geht an das Git-Repository und wird zu einer Pull-Anforderung. Danach kann der Entwickler diese Pull-Anfrage (insbesondere wenn es sich um Änderungen in der Produktionsumgebung handelt) zur Genehmigung durch die beteiligten Parteien einreichen. Auf diese Weise können Sicherheitsexperten frühzeitig einbezogen werden, und es ist immer möglich, die Reihenfolge der Änderungen zu verfolgen. Standards in diesem Bereich können mithilfe geeigneter Tools in der CI / CD-Toolkette programmgesteuert implementiert werden. Nach der Genehmigung wird die Pull-Anforderung versioniert und einfach überprüft. Darüber hinaus kann es als Teil eines Standardprozesses in einer Vorproduktionsumgebung getestet werden , wodurch das Risiko menschlicher Fehler vollständig ausgeschlossen wird.
Wie Sie sehen können, sind die Änderungen radikal. Sie werden jedoch weniger für Entwickler neu sein, die an Versionskontrollsysteme gewöhnt sind, als vielmehr für Systemadministratoren und Sicherheitsspezialisten. Sobald sie sich jedoch mit dem neuen Paradigma befassen und dessen Stärke und Einfachheit schätzen, wird die Idee mit einem Knall losgehen.
6. Blaupausen
Der Übergang von monolithischen Anwendungen zu Mikrodiensten verbessert die Rolle von Anwendungsdesignmustern (Mustern). In der Tat ist die typische monolithische Anwendung nicht sehr klassifizierbar. In der Regel gibt es REST-APIs, Stapelverarbeitung und ereignisgesteuert. HTTP, FTP, Kafka, JMS und Infinispan ? Ja, bitte, und es funktioniert auch mit drei verschiedenen Datenbanken gleichzeitig. Und wie bestellen Sie ein Schema, wenn hier eine ganze Reihe von Integrationsmustern für Unternehmensanwendungen gemischt werden? Auf keinen Fall.
Wenn Sie jedoch eine solche monolithische Anwendung in separate Teile zerlegen, werden Vorlagen immer einfacher unterschieden. Angenommen, es gibt jetzt vier separate Anwendungen, die die folgenden Vorlagen verwenden:
- REST-API zum Verwalten von Daten in einem DBMS.
- Stapelverarbeitung, die den FTP-Server auf Datenaktualisierungen überprüft und an das Kafka-Thema sendet.
- Camel ist ein Adapter, der Daten aus diesem Kafka-Thema an die REST-API sendet
- REST-APIs, die aggregierte Informationen verfügbar machen, die aus dem Datenraster gesammelt wurden und sich wie eine Zustandsmaschine verhalten.
Jetzt haben wir also Schaltpläne, und Schemata können standardisiert werden. REST-APIs müssen den Open API-Standards entsprechen . Stapeljobs werden als OpenShift-Stapeljobs verwaltet . Integrationen verwenden Camel... Sie können Schemas für APIs, für Stapeljobs, für AI / ML, für Multicast-Anwendungen oder was auch immer erstellen. Anschließend können Sie festlegen, wie diese Schemata bereitgestellt, konfiguriert und welche Vorlagen verwendet werden sollen. Mit diesen Standards müssen Sie das Rad nicht jedes Mal neu erfinden, und Sie können sich besser auf die wirklich wichtigen Aufgaben konzentrieren, z. B. das Erstellen neuer Geschäftsfunktionen. Die Ausarbeitung der Programme mag als Zeitverschwendung erscheinen, aber der Aufwand wird sich in Zukunft hundertfach auszahlen.
7. Bereiten Sie sich auf die API vor
APIs werden mit einer Microservice-Architektur geliefert. Sie müssen auch im Voraus verwaltet und besser darauf vorbereitet werden.
Erstens werden hier wieder Standards benötigt. Sie können die Open API-Standards als Ausgangspunkt nehmen , müssen jedoch tiefer in den Dschungel eintauchen. Obwohl es wichtig ist, hier ein Gleichgewicht zu finden und nicht mit einer Reihe von Einschränkungen in eine übermäßige Überregulierung zu geraten. Schauen Sie sich diese Fragen an: Wenn eine neue Entität mit POST erstellt wird, sollten wir 201 oder 200 zurückgeben? Darf Entitäten mit POST und nicht mit PUT aktualisiert werden? Was ist der Unterschied zwischen 400 und 500 Antworten? - ungefähr den gleichen Detaillierungsgrad, den Sie benötigen.
Zweitens benötigen Sie ein Service-Mesh... Dies ist eine wirklich starke Sache und wird im Laufe der Zeit ein wesentlicher Bestandteil von Kubernetes werden. Warum? Weil der Verkehr früher oder später zu einem Problem wird und Sie ihn sowohl innerhalb des Rechenzentrums (sogenannter Ost-West-Verkehr) als auch zwischen dem Rechenzentrum und der Außenwelt ( Süd"). Sie möchten die Authentifizierung und Autorisierung aus Anwendungen ziehen und sie auf die Plattformebene bringen. Sie benötigen die Funktionen von Kiali , um den Datenverkehr innerhalb des Servicenetzes zu visualisieren, sowie Bereitstellungsschemata für blaugrüne und kanarische Anwendungen oder beispielsweise die dynamische Verkehrssteuerung. Im Allgemeinen fällt das Servicenetz ohne Frage in die Kategorie der Aufgaben des ersten Tages.
Drittens benötigen Sie eine zentralisierte API-Verwaltungslösung... Sie möchten ein "Ein Fenster" zum Suchen und Wiederverwenden von APIs haben. Entwickler müssen in der Lage sein, in den API Store zu gehen, die gewünschte API zu finden und Dokumentation zur Verwendung zu erhalten. Sie möchten Versionen und Abwertungen konsistent verwalten. Wenn Sie eine API für externe Verbraucher erstellen, kann dies ein Nord-Süd-Endpunkt für Sicherheit und Lastmanagement sein. 3Scale kann sogar bei der API-Monetarisierung helfen. Früher oder später möchte Ihr Management einen Bericht erhalten, in dem die Frage "Welche API haben wir?" Beantwortet wird.
Zusammenfassend stellen wir fest, dass die Identifizierung von Bereichen für die Standardisierung und die Dokumentation von Unternehmensstandards an sich schon entmutigend sein kann, der Löwenanteil der Anstrengungen jedoch nicht dafür aufgewendet wird, sondern für die Überwachung und Durchsetzung der Einhaltung der Standards. Leistungsstarke Mischung aus organisatorischer Entropieund eine ganz natürliche Abneigung, von Anfang an mit Kollegen in Konflikt zu geraten, gegen Standards zu arbeiten. Der Kampf gliedert sich in unzählige winzige und manchmal unsichtbare Schlachten: Hier fehlt das erforderliche Etikett, und dieser Name entspricht, obwohl nicht vollständig, dem Standard immer noch ausreichend. Standards sterben normalerweise an tausend Kürzungen, und nur wenige, wenn überhaupt, in der Organisation wissen davon. In gewissem Sinne sind Standards wie Bewegung: Niemand möchte schwitzen und sich anstrengen, aber jeder weiß, dass ein langes und gesundes Leben ohne sie nicht möglich ist.
Es gibt jedoch Hoffnung und sie liegt in der Automatisierung. Jeder der oben genannten Standards kann mithilfe der Automatisierung implementiert werden. Der GitOps-Prozess kann überprüfen, ob alle erforderlichen Beschriftungen und Anmerkungen in allen relevanten Yaml-Dateien vorhanden sind. Der CI / CD-Prozess kann Standards für Unternehmensimages durchsetzen. Alles kann kodifiziert, getestet und harmonisiert werden. Darüber hinaus kann die Automatisierung verbessert werden, wenn Sie neue Standards einführen oder bestehende ändern. Der zweifelsfreie Vorteil der Standardisierung durch Automatisierung besteht darin, dass der Computer Konflikte nicht vermeidet, sondern lediglich die Fakten angibt. Mit genügend Raffinesse und Investitionen in die Automatisierung ist die Plattform, in die Sie heute so viel investierenkann in Zukunft eine viel höhere Kapitalrendite in Form einer verbesserten Leistung und Stabilität bringen.