Kubernetes ist ein großartiges Tool zum Ausführen von Docker-Containern in einer Cluster-Produktionsumgebung. Allerdings gibt es Probleme, die Kubernetes nicht lösen kann. Für häufige Produktionsbereitstellungen benötigen wir eine vollständig automatisierte Blau/Grün-Bereitstellung, um Ausfallzeiten im Prozess zu vermeiden, der auch externe HTTP-Anfragen verarbeiten und SSL-Offloads durchführen muss. Dies erfordert die Integration mit einem Load Balancer wie Ha-Proxy. Eine weitere Herausforderung ist die halbautomatische Skalierung des Kubernetes-Clusters selbst beim Betrieb in einer Cloud-Umgebung, beispielsweise eine teilweise Verkleinerung des Clusters nachts.
Kubernetes verfügt zwar nicht standardmäßig über diese Funktionen, bietet jedoch eine API, mit der Sie ähnliche Probleme lösen können. Im Rahmen des auf Open-Source-Basis erstellten Cloud-RTI-Projekts wurden Tools zur automatisierten Blue/Green-Bereitstellung und Skalierung eines Kubernetes-Clusters entwickelt.
Dieser Artikel, ein Videotranskript, zeigt Ihnen, wie Sie Kubernetes zusammen mit anderen Open-Source-Komponenten einrichten, um eine produktionsbereite Umgebung zu erstellen, die Code von einem Git-Commit ohne Ausfallzeiten in der Produktion akzeptiert.
Sobald Sie also von außen Zugriff auf Ihre Anwendungen haben, können Sie mit der vollständigen Einrichtung der Automatisierung beginnen, das heißt, sie so weit bringen, dass Sie einen Git-Commit durchführen und sicherstellen können, dass dieser Git-Commit in der Produktion endet. Natürlich möchten wir bei der Implementierung dieser Schritte und bei der Implementierung der Bereitstellung nicht auf Ausfallzeiten stoßen. Jede Automatisierung in Kubernetes beginnt also mit der API.
Kubernetes ist kein Tool, das sofort produktiv eingesetzt werden kann. Natürlich können Sie das tun, kubectl usw. verwenden, aber dennoch ist die API das Interessanteste und Nützlichste an dieser Plattform. Durch die Verwendung der API als Funktionssatz können Sie auf fast alles zugreifen, was Sie in Kubernetes tun möchten. Auch kubectl selbst nutzt die REST-API.
Dies ist REST, Sie können also jede beliebige Sprache oder jedes Tool verwenden, um mit dieser API zu arbeiten, aber benutzerdefinierte Bibliotheken werden Ihnen das Leben erheblich erleichtern. Mein Team hat zwei solcher Bibliotheken geschrieben: eine für Java/OSGi und eine für Go. Der zweite wird nicht oft verwendet, aber auf jeden Fall stehen Ihnen diese nützlichen Dinge zur Verfügung. Es handelt sich um ein teilweise lizenziertes Open-Source-Projekt. Es gibt viele solcher Bibliotheken für verschiedene Sprachen, sodass Sie diejenigen auswählen können, die am besten zu Ihnen passen.
Bevor Sie also mit der Automatisierung Ihrer Bereitstellung beginnen, müssen Sie sicherstellen, dass der Prozess keinen Ausfallzeiten unterliegt. Beispielsweise führt unser Team Produktionsbereitstellungen mitten am Tag durch, wenn die Anwendungen am häufigsten genutzt werden. Daher ist es wichtig, Verzögerungen in diesem Prozess zu vermeiden. Um Ausfallzeiten zu vermeiden, werden zwei Methoden verwendet: Blue/Green-Deployment oder Rolling Update. Wenn im letzteren Fall fünf Replikate der Anwendung ausgeführt werden, werden diese sequentiell nacheinander aktualisiert. Diese Methode funktioniert hervorragend, ist jedoch nicht geeignet, wenn während des Bereitstellungsprozesses verschiedene Versionen der Anwendung gleichzeitig ausgeführt werden. In diesem Fall können Sie die Benutzeroberfläche aktualisieren, während im Backend die alte Version ausgeführt wird, und die Anwendung funktioniert dann nicht mehr. Daher ist es aus programmtechnischer Sicht ziemlich schwierig, unter solchen Bedingungen zu arbeiten.
Dies ist einer der Gründe, warum wir die Blau/Grün-Bereitstellung bevorzugen, um die Bereitstellung unserer Anwendungen zu automatisieren. Bei dieser Methode müssen Sie sicherstellen, dass jeweils nur eine Version der Anwendung aktiv ist.
Der Blau/Grün-Bereitstellungsmechanismus sieht folgendermaßen aus. Wir empfangen Datenverkehr für unsere Anwendungen über ha-proxy, der ihn an laufende Replikate der Anwendung derselben Version weiterleitet.
Wenn eine neue Bereitstellung durchgeführt wird, verwenden wir den Deployer, der die neuen Komponenten erhält und die neue Version bereitstellt. Die Bereitstellung einer neuen Version einer Anwendung bedeutet, dass ein neuer Satz von Replikaten „erstellt“ wird. Anschließend werden diese Replikate der neuen Version in einem separaten, neuen Pod gestartet. Allerdings weiß ha-proxy nichts über sie und leitet noch keine Arbeitslast an sie weiter.
Daher ist es zunächst erforderlich, eine Leistungsprüfung neuer Versionen der Gesundheitsprüfung durchzuführen, um sicherzustellen, dass die Replikate für die Bewältigung der Last bereit sind.
Alle Bereitstellungskomponenten müssen eine Art Gesundheitsprüfung unterstützen. Dies kann eine sehr einfache HTTP-Aufrufprüfung sein, wenn Sie einen Code mit dem Status 200 erhalten, oder eine detailliertere Prüfung, bei der Sie die Verbindung der Replikate mit der Datenbank und anderen Diensten sowie die Stabilität der dynamischen Umgebungsverbindungen überprüfen , und ob alles richtig startet und funktioniert. Dieser Prozess kann recht komplex sein.
Nachdem das System überprüft hat, dass alle aktualisierten Replikate funktionieren, aktualisiert der Deployer die Konfiguration und übergibt den richtigen Confd, der den Ha-Proxy neu konfiguriert.
Erst danach wird der Datenverkehr an den Pod mit Replikaten der neuen Version weitergeleitet und der alte Pod verschwindet.
Dieser Mechanismus ist kein Feature von Kubernetes. Das Konzept der Blau/Grün-Bereitstellung gibt es schon seit geraumer Zeit und es wurde immer ein Load Balancer verwendet. Zunächst leiten Sie den gesamten Datenverkehr an die alte Version der Anwendung weiter und übertragen ihn nach dem Update vollständig auf die neue Version. Dieses Prinzip wird nicht nur in Kubernetes verwendet.
Jetzt stelle ich Ihnen eine neue Bereitstellungskomponente vor – Deployer, die Gesundheitsprüfungen durchführt, Proxys neu konfiguriert und so weiter. Dies ist ein Konzept, das nicht auf die Außenwelt anwendbar ist und innerhalb von Kubernetes existiert. Ich zeige Ihnen, wie Sie mit Open-Source-Tools Ihr eigenes Deployer-Konzept erstellen können.
Der Deployer erstellt also zunächst einen RC-Replikationscontroller mithilfe der Kubernetes-API. Diese API erstellt Pods und Dienste für die weitere Bereitstellung, d. h. sie erstellt einen völlig neuen Cluster für unsere Anwendungen. Sobald RC davon überzeugt ist, dass die Replikate gestartet sind, führt es einen Health Check ihrer Funktionalität durch. Hierzu verwendet der Deployer den Befehl GET /health. Es führt die entsprechenden Scan-Komponenten aus und überprüft alle Elemente, die den Betrieb des Clusters unterstützen.
Nachdem alle Pods ihren Zustand gemeldet haben, erstellt der Deployer ein neues Konfigurationselement – den verteilten etcd-Speicher, der intern von Kubernetes verwendet wird, einschließlich der Speicherung der Load-Balancer-Konfiguration. Wir schreiben Daten in etcd, und ein kleines Tool namens confd überwacht etcd auf neue Daten.
Wenn Änderungen an der Anfangskonfiguration festgestellt werden, wird eine neue Einstellungsdatei erstellt und an ha-proxy übertragen. In diesem Fall startet ha-proxy ohne Verbindungsverlust neu und verteilt die Last auf neue Dienste, die das Funktionieren der neuen Version unserer Anwendungen ermöglichen.
Wie Sie sehen, gibt es hier trotz der Fülle an Komponenten nichts Kompliziertes. Sie müssen nur der API und etcd mehr Aufmerksamkeit schenken. Ich möchte Ihnen etwas über den Open-Source-Deployer erzählen, den wir selbst verwenden – Amdatu Kubernetes Deployer.
Es ist ein Tool zur Orchestrierung von Kubernetes-Bereitstellungen und verfügt über die folgenden Funktionen:
- Blau/Grün-Bereitstellung;
- Einrichten eines externen Load Balancers;
- Verwaltung von Bereitstellungsdeskriptoren;
- Verwaltung des tatsächlichen Einsatzes;
- Überprüfung der Funktionalität von Gesundheitsprüfungen während der Bereitstellung;
- Implementierung von Umgebungsvariablen in Pods.
Dieser Deployer basiert auf der Kubernetes-API und bietet eine REST-API zum Verwalten von Handles und Bereitstellungen sowie eine Websocket-API zum Streamen von Protokollen während des Bereitstellungsprozesses.
Dadurch werden die Load-Balancer-Konfigurationsdaten in etcd abgelegt, sodass Sie nicht den Ha-Proxy mit sofort einsatzbereiter Unterstützung verwenden müssen, sondern ganz einfach Ihre eigene Load-Balancer-Konfigurationsdatei verwenden können. Amdatu Deployer ist wie Kubernetes selbst in Go geschrieben und wird von Apache lizenziert.
Bevor ich mit der Verwendung dieser Version des Deployers begann, habe ich den folgenden Bereitstellungsdeskriptor verwendet, der die von mir 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 Plausibilitätsprüfung durchgeführt werden muss. Diese Einstellung kann deaktiviert werden, wenn die Bereitstellung Drittanbietercontainer verwendet, 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 Pod-Spezifikationsflag „podspec“, das Kubernetes aufruft, um Informationen zur Portkonfiguration, zum Image usw. anzufordern. Dies ist ein ziemlich einfacher JSON-Deskriptor.
Ein weiteres Tool, das Teil des Open-Source-Projekts Amdatu ist, ist Deploymentctl. Es verfügt über eine Benutzeroberfläche zum Konfigurieren von Bereitstellungen, speichert den Bereitstellungsverlauf und enthält Webhooks für Rückrufe von Drittbenutzern und Entwicklern. Sie dürfen die Benutzeroberfläche nicht verwenden, da Amdatu Deployer selbst eine REST-API ist, aber diese Schnittstelle kann Ihnen die Bereitstellung erheblich erleichtern, ohne dass eine API erforderlich ist. Deploymentctl ist in OSGi/Vertx unter Verwendung von Angular 2 geschrieben.
Ich werde das Obige jetzt anhand einer zuvor aufgezeichneten Aufnahme auf dem Bildschirm demonstrieren, damit Sie nicht warten müssen. Wir werden eine einfache Go-Anwendung bereitstellen. Machen Sie sich keine Sorgen, wenn Sie Go noch nicht ausprobiert haben. Es handelt sich um eine sehr einfache Anwendung, sodass Sie sie verstehen sollten.
Hier erstellen wir einen HTTP-Server, der nur auf /health antwortet, sodass diese Anwendung nur die Gesundheitsprüfung und nichts anderes testet. Wenn die Prüfung erfolgreich ist, wird die unten gezeigte JSON-Struktur verwendet. Es enthält die Version der Anwendung, die vom Deployer bereitgestellt wird, die Meldung, die Sie oben in der Datei sehen, und den booleschen Datentyp – unabhängig davon, ob unsere Anwendung funktioniert oder nicht.
Bei der letzten Zeile habe ich ein wenig geschummelt, weil ich oben in der Datei einen festen booleschen Wert platziert habe, der mir in Zukunft sogar bei der Bereitstellung einer „ungesunden“ Anwendung helfen wird. Wir werden uns später damit befassen.
Also lasst uns anfangen. Zuerst prüfen wir mithilfe des Befehls ~ kubectl get pods, ob laufende Pods vorhanden sind. Basierend auf dem Fehlen einer Antwort von der Frontend-URL stellen wir sicher, dass derzeit keine Bereitstellungen durchgeführt werden.
Als nächstes sehen Sie auf dem Bildschirm die von mir erwähnte Deploymentctl-Schnittstelle, in der Bereitstellungsparameter festgelegt werden: Namespace, Anwendungsname, Bereitstellungsversion, Anzahl der Replikate, Front-End-URL, Containername, Bild, Ressourcenlimits, Portnummer für Gesundheitsprüfung, usw. . Ressourcenlimits sind sehr wichtig, da Sie damit die größtmögliche Menge an Hardware nutzen können. Hier können Sie auch das Bereitstellungsprotokoll anzeigen.
Wenn Sie nun den Befehl ~ kubectl get pods wiederholen, können Sie sehen, dass das System für 20 Sekunden „einfriert“, währenddessen ha-proxy neu konfiguriert wird. Danach startet der Pod und unser Replikat ist im Bereitstellungsprotokoll zu sehen.
Ich habe die Wartezeit von 20 Sekunden aus dem Video herausgeschnitten, und jetzt können Sie auf dem Bildschirm sehen, dass die erste Version der Anwendung bereitgestellt wurde. All dies wurde nur über die Benutzeroberfläche durchgeführt.
Probieren wir nun die zweite Version aus. Dazu ändere ich die Nachricht der Anwendung von „Hallo, Kubernetes!“ Auf „Hallo, Deployer!“ erstellt das System dieses Image und platziert es in der Docker-Registrierung. Anschließend klicken wir einfach erneut auf die Schaltfläche „Deploy“ im Deploymentctl-Fenster. In diesem Fall wird das Bereitstellungsprotokoll automatisch auf die gleiche Weise gestartet wie bei der Bereitstellung der ersten Version der Anwendung.
Der Befehl ~ kubectl get pods zeigt an, dass derzeit zwei Versionen der Anwendung ausgeführt werden, das Frontend zeigt jedoch an, dass wir immer noch Version 2 ausführen.
Der Load Balancer wartet auf den Abschluss der Integritätsprüfung, bevor er den Datenverkehr auf die neue Version umleitet. Nach 20 Sekunden wechseln wir zu Curl und sehen, dass wir jetzt Version 2 der Anwendung bereitgestellt haben und die erste gelöscht wurde.
Dies war die Bereitstellung einer „gesunden“ Anwendung. Sehen wir uns an, was passiert, wenn ich für eine neue Version der Anwendung den Parameter „Healthy“ von „true“ auf „false“ ändere, d. h. ich versuche, 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 die Produktion gesendet wurde.
Wie Sie sehen, durchläuft die Bereitstellung alle oben genannten Schritte und ~kubectl get pods zeigt an, dass beide Pods ausgeführt werden. Aber anders als bei der vorherigen Bereitstellung zeigt das Protokoll den Timeout-Status an. Das heißt, dass die neue Version der Anwendung nicht bereitgestellt werden kann, da die Integritätsprüfung fehlgeschlagen ist. Als Ergebnis sehen Sie, dass das System wieder die alte Version der Anwendung verwendet und die neue Version einfach deinstalliert wurde.
Das Gute daran ist, dass selbst wenn eine große Anzahl gleichzeitiger Anfragen in die Anwendung eingehen, diese die Ausfallzeit während der Implementierung des Bereitstellungsverfahrens nicht einmal bemerken. Wenn Sie diese Anwendung mit dem Gatling-Framework testen, das ihr so viele Anfragen wie möglich sendet, wird keine dieser Anfragen verworfen. Dies bedeutet, dass unsere Benutzer Versionsaktualisierungen nicht einmal in Echtzeit bemerken. Schlägt dies fehl, wird an der alten Version weitergearbeitet, bei Erfolg wechseln Nutzer auf die neue Version.
Es gibt nur eine Sache, die fehlschlagen kann: Wenn die Integritätsprüfung erfolgreich ist, die Anwendung jedoch fehlschlägt, sobald die Arbeitslast auf sie angewendet wird, erfolgt der Zusammenbruch erst, nachdem die Bereitstellung abgeschlossen ist. In diesem Fall müssen Sie manuell auf die alte Version zurücksetzen. Deshalb haben wir uns angeschaut, wie man Kubernetes mit den dafür entwickelten Open-Source-Tools nutzen kann. Der Bereitstellungsprozess wird viel einfacher, wenn Sie diese Tools in Ihre Build/Deploy-Pipelines integrieren. Gleichzeitig können Sie zum Starten der Bereitstellung entweder die Benutzeroberfläche verwenden oder diesen Prozess vollständig automatisieren, indem Sie beispielsweise „Commit to Master“ verwenden.
Unser Build-Server erstellt ein Docker-Image und überträgt es in den Docker Hub oder in die von Ihnen verwendete Registrierung. Docker Hub unterstützt Webhook, sodass wir die Remote-Bereitstellung über Deployer auf die oben gezeigte Weise auslösen können. Auf diese Weise können Sie die Bereitstellung Ihrer Anwendung für die potenzielle 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 mehr Hilfe können wir die Anzahl der Replikate in unserem bestehenden Cluster problemlos erhöhen. In der Praxis möchten wir jedoch normalerweise die Anzahl der Knoten statt der Pods erhöhen.
Gleichzeitig müssen Sie möglicherweise während der Arbeitszeit die Anzahl der ausgeführten Anwendungsinstanzen erhöhen und nachts möglicherweise die Anzahl der ausgeführten Anwendungsinstanzen reduzieren, um die Kosten für Amazon-Dienste zu senken, um die Kosten für Amazon-Dienste zu senken. Das bedeutet nicht, dass es ausreicht, nur die Anzahl der Pods zu skalieren, denn selbst wenn einer der Knoten inaktiv ist, müssen Sie Amazon dafür bezahlen. Das heißt, dass Sie neben der Skalierung der Pods auch die Anzahl der verwendeten Maschinen skalieren müssen.
Dies kann eine Herausforderung sein, denn egal ob wir Amazon oder einen anderen Cloud-Dienst nutzen, Kubernetes weiß nichts über die Anzahl der verwendeten Maschinen. Es fehlt ein Tool, mit dem Sie das System auf Knotenebene skalieren können.
Wir müssen uns also sowohl um Knoten als auch um Pods kümmern. Wir können den Start neuer Knoten problemlos skalieren, indem wir die AWS-API und Scaling-Gruppenmaschinen verwenden, um die Anzahl der Kubernetes-Worker-Knoten zu konfigurieren. Sie können auch cloud-init oder ein ähnliches Skript verwenden, um Knoten im Kubernetes-Cluster zu registrieren.
Die neue Maschine startet in der Scaling-Gruppe, initiiert sich selbst als Knoten, registriert sich in der Master-Registrierung und beginnt zu arbeiten. Anschließend können Sie die Anzahl der Replikate zur Verwendung auf den resultierenden Knoten erhöhen. Das Herunterskalieren erfordert mehr Aufwand, da Sie sicherstellen müssen, dass ein solcher Schritt nicht zur Zerstörung bereits laufender Anwendungen nach dem Abschalten „unnötiger“ Maschinen führt. Um ein solches Szenario zu verhindern, müssen Sie die Knoten auf den Status „unplanbar“ setzen. Dies bedeutet, dass der Standardplaner diese Knoten ignoriert, wenn er DaemonSet-Pods plant. Der Scheduler löscht nichts von diesen Servern, startet dort aber auch keine neuen Container. Der nächste Schritt besteht darin, den Drain-Knoten zu verdrängen, d. h. laufende Pods von ihm auf eine andere Maschine oder andere Knoten zu übertragen, die über ausreichende Kapazität dafür verfügen. Sobald Sie sichergestellt haben, dass sich auf diesen Knoten keine Container mehr befinden, können Sie sie aus Kubernetes entfernen. Danach werden sie für Kubernetes einfach nicht mehr existieren. Als Nächstes müssen Sie die AWS-API verwenden, um unnötige Knoten oder Maschinen zu deaktivieren.
Sie können Amdatu Scalerd verwenden, ein weiteres Open-Source-Skalierungstool, das der AWS-API ähnelt. Es bietet eine CLI zum Hinzufügen oder Entfernen von Knoten in einem Cluster. Seine interessante Funktion ist die Möglichkeit, den Scheduler mithilfe der folgenden JSON-Datei zu konfigurieren.
Der angezeigte Code reduziert die Clusterkapazität während der Nachtzeit um die Hälfte. Es konfiguriert sowohl die Anzahl der verfügbaren Replikate als auch die gewünschte Kapazität des Amazon-Clusters. Durch die Verwendung dieses Planers 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 eingespart werden. Diese Funktion ist nicht in Kubernetes integriert, aber mit Scalerd können Sie diese Plattform nach Ihren Wünschen skalieren.
Ich möchte darauf hinweisen, dass mir viele Leute sagen: „Das ist alles schön und gut, aber was ist mit meiner Datenbank, die normalerweise statisch ist?“ Wie kann man so etwas in einer dynamischen Umgebung wie Kubernetes ausführen? Meiner Meinung nach sollten Sie dies nicht tun und nicht versuchen, ein Data Warehouse in Kubernetes zu betreiben. Das ist zwar technisch möglich und im Internet gibt es Tutorials zu diesem Thema, aber es wird Ihr Leben erheblich verkomplizieren.
Ja, es gibt ein Konzept für persistente Speicher in Kubernetes, und Sie können versuchen, Datenspeicher wie Mongo oder MySQL auszuführen, aber das ist eine ziemlich arbeitsintensive Aufgabe. Dies liegt daran, dass Data Warehouses die Interaktion mit einer dynamischen Umgebung nicht vollständig unterstützen. Die meisten Datenbanken erfordern eine umfangreiche Konfiguration, einschließlich der manuellen Konfiguration des Clusters, und mögen keine automatische Skalierung und ähnliche Dinge.
Daher sollten Sie Ihr Leben nicht dadurch verkomplizieren, dass Sie versuchen, ein Data Warehouse in Kubernetes zu betreiben. Organisieren Sie ihre Arbeit auf herkömmliche Weise mit bekannten Diensten und geben Sie Kubernetes einfach die Möglichkeit, diese zu nutzen.
Zum Abschluss des Themas möchte ich Ihnen die auf Kubernetes basierende Cloud RTI-Plattform vorstellen, an der mein Team arbeitet. Es bietet zentralisierte Protokollierung, Anwendungs- und Clusterüberwachung und viele andere nützliche Funktionen, die sich als nützlich erweisen werden. Es verwendet verschiedene Open-Source-Tools wie Grafana, um die Überwachung anzuzeigen.
Es stellte sich die Frage, warum der Ha-Proxy-Load-Balancer mit Kubernetes verwendet werden sollte. Gute Frage, denn derzeit gibt es zwei Ebenen des Lastausgleichs. Kubernetes-Dienste befinden sich weiterhin auf virtuellen IP-Adressen. Sie können sie nicht für Ports auf externen Host-Rechnern verwenden, da sich die Adresse ändert, wenn Amazon seinen Cloud-Host überlastet. Aus diesem Grund platzieren wir Ha-Proxy vor den Diensten, um eine statischere Struktur für die nahtlose Kommunikation des Datenverkehrs mit Kubernetes zu schaffen.
Eine weitere gute Frage ist, wie Sie Datenbankschemaänderungen bei der Blau/Grün-Bereitstellung berücksichtigen können. Tatsache ist, dass die Änderung des Datenbankschemas unabhängig von der Verwendung von Kubernetes eine schwierige Aufgabe ist. Sie müssen sicherstellen, dass das alte und das neue Schema kompatibel sind. Anschließend können Sie die Datenbank aktualisieren und dann die Anwendungen selbst aktualisieren. Sie können die Datenbank im laufenden Betrieb austauschen und dann die Anwendungen aktualisieren. Ich kenne Leute, die einen völlig neuen Datenbankcluster mit einem neuen Schema gestartet haben. Dies ist eine Option, wenn Sie eine schemalose Datenbank wie Mongo haben, aber es ist ohnehin keine leichte Aufgabe. Wenn Sie keine weiteren Fragen haben, vielen Dank für Ihre Aufmerksamkeit!
Einige Anzeigen 🙂
Vielen Dank, dass Sie bei uns geblieben sind. Gefallen Ihnen unsere Artikel? Möchten Sie weitere interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder an Freunde weiterempfehlen. , ein einzigartiges Analogon von Einstiegsservern, das von uns für Sie erfunden wurde: (verfügbar mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40 GB DDR4).
Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur hier in den Niederlanden! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbit/s 100 TB – ab 99 $! Lesen über
Source: habr.com