📓 👩🏿‍🔬 🐴 DEVOXX UK. Kubernetes in der Produktion: Blau / Grün-Bereitstellung, automatische Skalierung und Bereitstellungsautomatisierung. Teil 2 ❄️ 🎨 🤑

Kubernetes ist ein großartiges Tool zum Ausführen von Docker-Containern in einer Cluster-Produktionsumgebung. Es gibt jedoch Aufgaben, die Kubernetes nicht lösen kann. Bei häufigen Bereitstellungen in einer Produktionsumgebung benötigen wir eine vollautomatische Blue / Green-Bereitstellung, um Ausfallzeiten in diesem Prozess zu vermeiden, für die auch externe HTTP-Anforderungen und SSL-Uploads erforderlich sind. Dies erfordert die Integration mit einem Load Balancer wie ha-proxy. Eine weitere Aufgabe ist die halbautomatische Skalierung des Kubernetes-Clusters selbst bei der Arbeit in der Cloud, beispielsweise die teilweise Reduzierung der Cluster-Skalierung bei Nacht.

Obwohl Kubernetes diese Funktionen nicht standardmäßig bietet, bietet es eine API, mit der solche Probleme gelöst werden können. Kubernetes Cluster-Tools für die automatisierte Bereitstellung und Skalierung von Blau / Grün wurden im Rahmen des Open-Source-Projekts Cloud RTI entwickelt.

In diesem Video-Transkript wird beschrieben, wie Sie Kubernetes zusammen mit anderen Open Source-Komponenten konfigurieren, um eine produktionsbereite Umgebung zu erhalten, die Code aus dem Commit für die Festschreibung von Git Commits ohne Ausfallzeiten in der Produktion akzeptiert.

DEVOXX UK. Kubernetes in der Produktion: Blau / Grün-Bereitstellung, automatische Skalierung und Bereitstellungsautomatisierung. Teil 1

Nachdem Sie von außen auf Ihre Anwendungen zugegriffen haben, können Sie mit der vollständigen Konfiguration der Automatisierung beginnen, dh sie auf die Stufe bringen, auf der Sie das Git-Commit ausführen und sicherstellen können, dass dieses Git-Commit in der Produktion endet. Natürlich möchten wir bei der Implementierung dieser Schritte und bei der Implementierung der Bereitstellung keine Ausfallzeiten haben. Jede Automatisierung in Kubernetes beginnt also mit einer API.

Kubernetes ist kein Tool, das produktiv „out of the box“ eingesetzt werden kann. Natürlich können Sie dies tun, Kubectl verwenden und so weiter, aber dennoch ist die API das Interessanteste und Nützlichste an dieser Plattform. Mit der API als Funktionsumfang können Sie auf fast alles zugreifen, was Sie in Kubernetes tun möchten. Kubectl selbst verwendet auch die REST-API.

Dies ist REST, sodass Sie alle Sprachen und Tools verwenden können, um mit dieser API zu arbeiten. Benutzerbibliotheken erleichtern Ihnen jedoch das Leben erheblich. Mein Team hat zwei solcher Bibliotheken geschrieben: eine für Java / OSGi und eine für Go. Die zweite wird nicht oft verwendet, aber auf jeden Fall stehen Ihnen diese nützlichen Dinge zur Verfügung. Sie sind ein teilweise lizenziertes Open-Source-Projekt. Es gibt viele solcher Bibliotheken für verschiedene Sprachen, sodass Sie die am besten geeignete auswählen können.

Bevor Sie mit der Automatisierung der Bereitstellung beginnen, müssen Sie sicherstellen, dass für diesen Prozess keine Ausfallzeiten auftreten. Zum Beispiel führt unser Team die Produktionsbereitstellung mitten am Tag durch, wenn die Mitarbeiter ihre Anwendungen optimal nutzen. Daher ist es sehr wichtig, Verzögerungen in diesem Prozess zu vermeiden. Um Ausfallzeiten zu vermeiden, werden zwei Methoden verwendet: Blau / Grün-Bereitstellung oder fortlaufendes Update. Im letzteren Fall werden 5 Replikate der Anwendung nacheinander aktualisiert. Diese Methode funktioniert hervorragend, funktioniert jedoch nicht, wenn Sie während des Bereitstellungsprozesses verschiedene Versionen der Anwendung gleichzeitig ausführen. In diesem Fall können Sie die Benutzeroberfläche aktualisieren, während das Backend mit der alten Version funktioniert und die Anwendung nicht mehr funktioniert.Unter dem Gesichtspunkt der Programmierung ist es daher ziemlich schwierig, unter solchen Bedingungen zu arbeiten.

Dies ist einer der Gründe, warum wir die blau / grüne Bereitstellung bevorzugen, um die Bereitstellung unserer Anwendungen zu automatisieren. Bei dieser Methode müssen Sie sicherstellen, dass zu einem bestimmten Zeitpunkt nur eine Version der Anwendung aktiv ist.

Der blau / grüne Bereitstellungsmechanismus ist wie folgt. Wir erhalten Datenverkehr für unsere Anwendungen über ha-proxy, wodurch die Ausführung von Anwendungsreplikaten derselben Version geleitet wird.

Wenn eine neue Bereitstellung ausgeführt wird, verwenden wir Deployer, der mit neuen Komponenten bereitgestellt wird, und stellen die neue Version bereit. Das Bereitstellen einer neuen Version einer Anwendung bedeutet, dass ein neuer Satz von Replikaten "aufsteigt". Danach werden diese Replikate der neuen Version in einem separaten, neuen Pod gestartet. Ha-proxy weiß jedoch nichts über sie und hat ihnen bisher keine Arbeitslast gesendet.

Daher ist es zunächst erforderlich, den Zustand neuer Versionen von Health Cheeking zu überprüfen, um sicherzustellen, dass die Replikate bereit sind, die Last zu bedienen.

Alle Bereitstellungskomponenten müssen irgendeine Form von Health Cheek unterstützen. Dies kann eine sehr einfache HTTP-Prüfung mit einem Anruf sein, wenn Sie einen Code mit dem Status 200 erhalten, oder eine eingehendere Prüfung, bei der Sie die Verbindung von Replikaten mit der Datenbank und anderen Diensten, die Stabilität der Verbindungen der dynamischen Umgebung, ob alles startet und ordnungsgemäß funktioniert, überprüfen. Dieser Vorgang kann sehr kompliziert sein.

Nachdem das System überprüft hat, ob alle aktualisierten Replikate betriebsbereit sind, aktualisiert Deployer die Konfiguration und übergibt die korrekte Konfiguration, wodurch ha-proxy neu konfiguriert wird.

Erst danach wird der Datenverkehr mit Repliken der neuen Version nach unten geleitet, und die alte Version verschwindet.

Dieser Mechanismus ist kein Merkmal von Kubernetes. Das blau / grüne Bereitstellungskonzept gibt es schon seit geraumer Zeit und es wurde immer ein Load Balancer verwendet. Zunächst leiten Sie den gesamten Datenverkehr auf die alte Version der Anwendung und übertragen ihn nach dem Upgrade vollständig auf die neue Version. Dieses Prinzip wird nicht nur in Kubernetes angewendet.

Jetzt werde ich Ihnen eine neue Bereitstellungskomponente vorstellen - Deployer, die eine Integritätsprüfung durchführt, Proxys neu konfiguriert usw. Dies ist ein Konzept, das nicht für die Außenwelt gilt und innerhalb von Kubernetes existiert. Ich werde zeigen, wie Sie mit Open-Source-Tools Ihr eigenes Deployer-Konzept erstellen können.

Als erstes erstellt Deployer einen RC-Replikationscontroller mithilfe der Kubernetes-API. Diese API erstellt Pods und Services für die weitere Bereitstellung, dh sie erstellt einen völlig neuen Cluster für unsere Anwendungen. Sobald der RC überprüft, ob die Replikate gestartet wurden, überprüft er ihre Integritätsprüfung. Zu diesem Zweck verwendet Deployer den Befehl GET / health. Es startet die entsprechenden Überprüfungskomponenten und überprüft alle Elemente, die den Betrieb des Clusters sicherstellen.

Nachdem alle Pods ihren "Zustand" gemeldet haben, erstellt Deployer ein neues Konfigurationselement - den verteilten Speicher usw., der in Kubernetes verwendet wird, einschließlich zum Speichern der Load Balancer-Konfiguration. Wir schreiben Daten in etcd und ein kleines Tool, confd, überwacht etcd auf neue Daten.

Wenn er Änderungen an der Erstkonfiguration feststellt, generiert er eine neue Einstellungsdatei und übergibt sie an ha-proxy. In diesem Fall wird ha-proxy neu gestartet, ohne dass Verbindungen verloren gehen, und die Last wird mit neuen Diensten behoben, die die neue Version unserer Anwendungen bereitstellen.

Wie Sie sehen, gibt es trotz der Fülle an Komponenten nichts Kompliziertes. Sie müssen nur mehr auf die API und etcd achten. Ich möchte Ihnen etwas über den Open-Source-Deployer erzählen, den wir selbst verwenden - dies ist Amdatu Kubernetes Deployer.

Dies ist ein Kubernetes Deployment Orchestration-Tool mit den folgenden Funktionen:

Blau / Grün-Bereitstellung
Einrichten eines externen Load Balancers;
Deployment Descriptor Management
Tatsächliches Bereitstellungsmanagement
Integritätsprüfungen während der Bereitstellung
Implementierung von Umgebungsvariablen in Pods.

Dieser Deployer wurde über der Kubernetes-API erstellt und bietet eine REST-API zum Verwalten von Deskriptoren und Bereitstellungen sowie eine Websocket-API für Stream-Protokolle während der Bereitstellung.

Die Load Balancer-Konfigurationsdaten werden in etcd abgelegt, sodass Sie ha-proxy nicht mit "out of the box" -Unterstützung verwenden können. Es ist jedoch einfach, Ihre eigene Balancer-Konfigurationsdatei zu verwenden. Amdatu Deployer ist wie Kubernetes selbst in Go geschrieben und von Apache lizenziert.

Bevor ich diese Version des Deployers verwendet habe, habe ich den folgenden Deployment-Deskriptor verwendet, der die benötigten Parameter angibt.

Einer der wichtigen Parameter dieses Codes ist die Aktivierung des Flags "useHealthCheck". Wir müssen angeben, dass während des Bereitstellungsprozesses eine Integritätsprüfung erforderlich ist. Diese Option kann deaktiviert werden, wenn für die Bereitstellung Container von Drittanbietern verwendet werden, die nicht überprüft werden müssen. Dieser Deskriptor gibt auch die Anzahl der Replikate und die Frontend-URL an, die ha-proxy benötigt. Am Ende befindet sich das Spezifikationsflag für den Podspec-Pod, der Kubernetes aufruft, um Informationen zur Portkonfiguration, zum Image usw. zu erhalten. Dies ist ein ziemlich einfacher Deskriptor im JSON-Format.

Ein weiteres Tool, das Teil des Amdatu Open Source-Projekts ist, ist Deploymentctl. Es verfügt über eine Benutzeroberfläche zur Konfiguration der Bereitstellung, speichert den Bereitstellungsverlauf und enthält Webhooks für Rückrufe durch Benutzer und Entwickler von Drittanbietern. Sie können die Benutzeroberfläche nicht verwenden, da Amdatu Deployer selbst eine REST-API ist. Diese Schnittstelle erleichtert Ihnen jedoch die Bereitstellung ohne API. Deploymentctl wurde in OSGi / Vertx mit Angular 2 geschrieben.

Jetzt werde ich das Obige auf dem Bildschirm anhand einer vorgefertigten Aufzeichnung demonstrieren, damit Sie nicht warten müssen. Wir werden eine einfache Anwendung auf Go bereitstellen. Keine Sorge, wenn Sie Go noch nicht kennengelernt haben, ist dies eine sehr einfache Anwendung. Sie sollten also alles verstehen.

Hier erstellen wir einen HTTP-Server, der nur auf / health reagiert, sodass diese Anwendung nur die Integritätsprüfung und sonst nichts überprüft. Wenn die Prüfung bestanden ist, wird die unten gezeigte JSON-Struktur aufgerufen. Es enthält die Version der Anwendung, die vom Bereitsteller bereitgestellt wird, die Meldung, die oben in der Datei angezeigt wird, und den booleschen logischen Datentyp - unabhängig davon, ob unsere Anwendung funktioniert oder nicht.

Ich habe mit der letzten Zeile ein wenig geschummelt, weil ich einen festen booleschen Wert oben in die Datei eingefügt habe, was mir in Zukunft helfen wird, selbst eine "ungesunde" Anwendung bereitzustellen. Wir werden uns später darum kümmern.

Also lasst uns anfangen. Zuerst überprüfen wir mit dem Befehl ~ kubectl get pods, ob Pods ausgeführt werden. Wenn die Frontend-URL keine Antwort gibt, stellen wir sicher, dass derzeit keine Bereitstellungen ausgeführt werden.

Als Nächstes sehen Sie auf dem Bildschirm die von mir erwähnte Deploymentctl-Oberfläche, in der die Bereitstellungsparameter festgelegt sind: Namespace, Anwendungsname, Bereitstellungsversion, Anzahl der Replikate, Frontend-URL, Containername, Image, Ressourcenlimits, Portnummer zur Überprüfung der Integritätsprüfung usw. . Ressourcenlimits sind sehr wichtig, da Sie so die maximal mögliche Menge an "Eisen" verwenden können. Hier können Sie auch das Bereitstellungsprotokoll des Bereitstellungsprotokolls anzeigen.

Wenn Sie den Befehl ~ kubectl get pods jetzt wiederholen, können Sie sehen, dass das System 20 Sekunden lang „einfriert“, währenddessen die Neukonfiguration des ha-Proxys erfolgt. Danach beginnt es unter und unser Replikat wird im Bereitstellungsprotokoll angezeigt.

Ich habe eine Wartezeit von 20 Sekunden aus dem Video herausgeschnitten, und jetzt sehen Sie auf dem Bildschirm, dass die erste Version der Anwendung bereitgestellt wird. All dies wurde nur mit Hilfe der Benutzeroberfläche durchgeführt.

Versuchen wir jetzt die zweite Version. Dazu ändere ich die Meldung der Anwendung mit "Hallo, Kubernetes!" Bei „Hallo, Deployer!“ erstellt das System dieses Image und platziert es in der Docker-Registrierung. Anschließend klicken Sie einfach erneut auf die Schaltfläche „Deploy“ im Deploymentctl-Fenster. In diesem Fall wird das Bereitstellungsprotokoll automatisch auf dieselbe Weise gestartet wie bei der Bereitstellung der ersten Version der Anwendung.

Der Befehl ~ kubectl get pods zeigt an, dass derzeit 2 Versionen der Anwendung ausgeführt werden. Das Front-End zeigt jedoch an, dass noch Version 1 ausgeführt wird. Der

Load Balancer wartet, bis die Integritätsprüfung ausgeführt wird, und leitet den Datenverkehr dann zur neuen Version um. Nach 20 Sekunden wechseln wir zu Curl und stellen fest, dass wir jetzt Version 2 der Anwendung bereitgestellt haben und die erste entfernt wird.

Es war die Bereitstellung einer "gesunden" - gesunden - Anwendung. Mal sehen, was passiert, wenn ich für die neue Version der Anwendung den Wert des Parameters "Healthy" von "true" in "false" ändere. Das heißt, ich werde versuchen, eine fehlerhafte Anwendung bereitzustellen, die die Integritätsprüfung nicht bestanden hat. Dies kann passieren, wenn in der Entwicklungsphase einige Konfigurationsfehler in der Anwendung gemacht wurden und diese in dieser Form in Produktion ging.

Wie Sie sehen können, durchläuft die Bereitstellung alle oben genannten Schritte, und ~ kubectl get pods zeigt an, dass beide Pods ausgeführt werden. Im Gegensatz zur vorherigen Bereitstellung zeigt das Protokoll jedoch den Status des Zeitlimits an. Das heißt, aufgrund der Tatsache, dass die Integritätsprüfung nicht bestanden wurde, kann die neue Version der Anwendung nicht bereitgestellt werden. Als Ergebnis sehen Sie, dass das System wieder die alte Version der Anwendung verwendet hat und die neue Version einfach gelöscht wurde.

Das Gute daran ist, dass selbst wenn eine große Anzahl von Anforderungen gleichzeitig in die Anwendung eingehen, diese während der Implementierung des Bereitstellungsverfahrens keine Ausfallzeiten bemerken. Wenn Sie diese Anwendung mit dem Gatling-Framework testen, das die maximal mögliche Anzahl von Anforderungen sendet, wird keine dieser Anforderungen gelöscht. Dies bedeutet, dass unsere Benutzer nicht einmal Versionsaktualisierungen in Echtzeit bemerken. Wenn dies fehlschlägt, wird die Arbeit an der alten Version fortgesetzt. Wenn dies erfolgreich ist, wechseln Benutzer zur neuen Version.

Es gibt nur eine Sache, die zu einem Fehler führen kann: Wenn die Integritätsprüfung erfolgreich war und die Anwendung abstürzte, sobald sie die Arbeitslast erhalten hat, tritt der Zusammenbruch erst nach Abschluss der Bereitstellung auf. In diesem Fall müssen Sie manuell auf die alte Version zurücksetzen. Wir haben uns also angesehen, wie man Kubernetes mit seinen Open-Source-Tools verwendet. Der Bereitstellungsprozess wird viel einfacher, wenn Sie diese Tools in die Pipelines zum Erstellen / Bereitstellen von Pipelines einbetten / bereitstellen. Gleichzeitig können Sie zum Starten der Bereitstellung sowohl die Benutzeroberfläche verwenden als auch diesen Prozess vollständig automatisieren, indem Sie beispielsweise Commit to Master anwenden.

Unser Build Server Build Server erstellt ein Docker-Image, fügt es in den Docker Hub oder eine andere von Ihnen verwendete Registrierung ein. Der Docker-Hub unterstützt Webhook, sodass wir die Remote-Bereitstellung über Deployer wie oben gezeigt starten können. Auf diese Weise können Sie die Bereitstellung der Anwendung in der potenziellen Produktion vollständig automatisieren.

Fahren wir mit dem nächsten Thema fort - der Skalierung des Kubernetes-Clusters. Beachten Sie, dass der Befehl kubectl ein Skalierungsbefehl ist. Mit Hilfe eines anderen können Sie die Anzahl der Replikate in unserem Cluster problemlos erhöhen. In der Praxis möchten wir jedoch normalerweise die Anzahl der Knoten erhöhen, nicht die Anzahl der Knoten.

Gleichzeitig müssen Sie möglicherweise während der Arbeitszeit die Anzahl der ausgeführten Instanzen der Anwendung erhöhen und nachts, um die Kosten für Amazon-Dienste zu senken, verringern. Dies bedeutet nicht, dass nur die Anzahl der Pods für die Skalierung ausreicht, denn selbst wenn einer der Knoten nicht ausgelastet ist, müssen Sie Amazon dafür bezahlen. Das heißt, zusammen mit der Skalierung der Herde müssen Sie die Anzahl der verwendeten Maschinen skalieren.

Dies kann schwierig sein, da Kubernetes unabhängig davon, ob wir Amazon oder einen anderen Cloud-Dienst verwenden, nichts über die Anzahl der verwendeten Computer weiß. Es fehlt ein Tool, mit dem Sie das System auf Knotenebene skalieren können.

Wir müssen uns also um die Knoten und die Pods kümmern. Wir können den Start neuer Knoten mithilfe der AWS-API und der Skalierungsgruppencomputer einfach skalieren, um die Anzahl der Kubernetes-Arbeitsknoten zu konfigurieren. Sie können auch Cloud-Init oder ein ähnliches Skript verwenden, um Knoten in einem Kubernetes-Cluster zu registrieren.

Der neue Computer startet in der Scaling-Gruppe, initiiert sich als Knoten, registriert sich in der Registrierung des Assistenten und beginnt mit der Arbeit. Danach können Sie die Anzahl der Replikate erhöhen, die auf den resultierenden Knoten verwendet werden sollen. Das Reduzieren des Maßstabs erfordert mehr Aufwand, da Sie sicherstellen müssen, dass ein solcher Schritt nicht zur Zerstörung bereits laufender Anwendungen führt, nachdem "unnötige" Maschinen ausgeschaltet wurden. Um dieses Szenario zu verhindern, müssen Sie die Knoten in den Status "nicht planbar" versetzen. Dies bedeutet, dass der Standardplaner beim Planen von DaemonSet-Pods diese Knoten ignoriert. Der Scheduler löscht nichts von diesen Servern, startet dort aber auch keine neuen Container. Der nächste Schritt besteht darin, den Abflussknoten zu verschieben, dh die Arbeitsherde von dieser auf eine andere Maschine oder andere Knoten zu übertragen, die über eine ausreichende Kapazität dafür verfügen.Nachdem Sie überprüft haben, dass sich auf diesen Knoten keine Container mehr befinden, können Sie sie aus Kubernetes entfernen. Danach hören sie für Kubernetes einfach auf zu existieren. Als Nächstes müssen Sie die AWS-API verwenden, um unnötige Knoten oder Computer zu deaktivieren.
Sie können Amdatu Scalerd verwenden, ein weiteres Open-Source-Skalierungswerkzeug, das der AWS-API ähnelt. Es bietet eine CLI zum Hinzufügen oder Entfernen von Knoten in einem Cluster. Die interessante Funktion ist die Möglichkeit, den Scheduler mithilfe der folgenden JSON-Datei zu konfigurieren.

Der angezeigte Code halbiert die Kapazität des Clusters nachts. Es wird als Anzahl der verfügbaren Replikate und als gewünschte Kapazität des Amazon-Clusters konfiguriert. Durch die Verwendung dieses Schedulers wird die Anzahl der Knoten nachts automatisch reduziert und morgens erhöht, wodurch die Kosten für die Verwendung von Knoten eines Cloud-Dienstes wie Amazon gespart werden. Diese Funktion ist nicht in Kubernetes integriert. Mit Scalerd können Sie diese Plattform jedoch nach Ihren Wünschen skalieren.

Ich möchte Ihre Aufmerksamkeit auf die Tatsache lenken, dass mir viele Leute sagen: "Das ist alles gut, aber was ist mit meiner Datenbank, die sich normalerweise in einem statischen Zustand befindet?" Wie kann ich so etwas in einer dynamischen Umgebung wie Kubernetes ausführen? Meiner Meinung nach sollten Sie dies nicht tun, sollten nicht versuchen, den Betrieb des Data Warehouse in Kubernetes zu organisieren. Technisch ist dies möglich, und es gibt Handbücher im Internet zu diesem Thema, aber es wird Ihr Leben ernsthaft verkomplizieren.

Ja, das Konzept des persistenten Speichers existiert in Kubernetes, und Sie können versuchen, Data Warehouses wie Mongo oder MySQL auszuführen, aber dies ist eine ziemlich zeitaufwändige Aufgabe. Dies liegt an der Tatsache, dass Data Warehouses die Interaktion mit einer dynamischen Umgebung nicht vollständig unterstützen. Die meisten Datenbanken erfordern eine erhebliche Optimierung, einschließlich der manuellen Konfiguration des Clusters. Sie mögen keine automatische Skalierung und ähnliche Dinge.
Erschweren Sie daher nicht Ihr Leben, wenn Sie versuchen, ein Data Warehouse in Kubernetes zu starten. Organisieren Sie ihre Arbeit auf traditionelle Weise mit vertrauten Diensten und geben Sie Kubernetes die Möglichkeit, sie zu nutzen.

Am Ende des Themas möchte ich Ihnen die Cloud RTI-Plattform vorstellen, die auf Kubernetes basiert und an der mein Team arbeitet. Es bietet zentralisierte Protokollierung, Überwachung von Anwendungen und Clustern sowie viele andere nützliche Funktionen, die für Sie nützlich sind. Es verwendet verschiedene Open-Source-Tools wie Grafana, um die Überwachung anzuzeigen.

Es wurde die Frage aufgeworfen, warum der ha-proxy Load Balancer mit Kubernetes verwendet wird. Gute Frage, denn derzeit gibt es zwei Stufen des Lastausgleichs. Kubernetes-Dienste befinden sich weiterhin auf virtuellen IP-Adressen. Sie können sie nicht für externe Host-Ports verwenden, da sich die Adresse ändert, wenn Amazon seinen Cloud-Host neu startet. Aus diesem Grund stellen wir Ha-Proxy-Dienste vor Dienste, um eine statischere Struktur für eine nahtlose Verkehrsinteraktion mit Kubernetes zu schaffen.

Eine weitere gute Frage ist, wie ich das Datenbankschema während der blau / grünen Bereitstellung ändern kann. Tatsache ist, dass das Ändern des Datenbankschemas unabhängig von der Verwendung von Kubernetes eine komplexe Aufgabe ist. Sie müssen die Kompatibilität des alten und des neuen Schemas sicherstellen. Anschließend können Sie die Datenbank aktualisieren und anschließend die Anwendungen selbst aktualisieren. Sie können die Datenbank im laufenden Betrieb austauschen und anschließend die Anwendungen aktualisieren. Ich kenne Leute, die einen völlig neuen Datenbankcluster mit einem neuen Schema heruntergeladen haben. Dies ist eine Option, wenn Sie eine schemenlose Datenbank wie Mongo haben, aber auf jeden Fall ist dies keine leichte Aufgabe. Wenn Sie keine Fragen mehr haben, vielen Dank für Ihre Aufmerksamkeit!

Ein bisschen Werbung :)

Vielen Dank für Ihren Aufenthalt bei uns. Gefällt dir unser Artikel? Möchten Sie weitere interessante Materialien sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder Ihren Freunden Cloud-basiertes VPS für Entwickler ab 4,99 US-Dollar empfehlen , ein einzigartiges Analogon von Einstiegsservern, das von uns für Sie erfunden wurde: Die ganze Wahrheit über VPS (KVM) E5-2697 v3 (6 Kerne) 10 GB DDR4 480 GB SSD 1 Gbit / s ab 19 $ oder wie teilt man den Server? (Optionen sind mit RAID1 und RAID10, bis zu 24 Kernen und bis zu 40 GB DDR4 verfügbar).

Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur wir haben 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2,6 GHz 14C 64 GB DDR4 4 x 960 GB SSD 1 Gbit / s 100 TV von 199 US-Dollar in den Niederlanden!Dell R420 - 2x E5-2430 2,2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbit / s 100 TB - ab 99 US-Dollar! Lesen Sie mehr über den Aufbau eines Infrastrukturgebäudes. Klasse C mit Dell R730xd E5-2650 v4-Servern für 9.000 Euro für einen Cent?

DEVOXX UK. Kubernetes in der Produktion: Blau / Grün-Bereitstellung, automatische Skalierung und Bereitstellungsautomatisierung. Teil 2

Ein bisschen Werbung :)

More articles: