TOC

So skalieren Sie eine Node.js-Anwendung mit MongoDB auf Kubernetes mithilfe von Helm

Einführung

Kubernetes ist ein System zum Ausführen moderner, containerisierter Anwendungen in großem Maßstab. Mit ihr können Entwickler Anwendungen über mehrere Maschinencluster hinweg bereitstellen und verwalten. Kubernetes kann zwar zur Verbesserung der Effizienz und Zuverlässigkeit bei der Einrichtung von Einzelinstanzanwendungen eingesetzt werden, kann jedoch mehrere Instanzen einer Anwendung auf mehreren Computergruppen ausführen.

Bei der Erstellung von Multi-Service-Bereitstellungen mit Kubernetes verwenden viele Entwickler den Paketmanager Helm. Helm optimiert den Prozess der Erstellung mehrerer Kubernetes-Ressourcen, indem Diagramme und Vorlagen angeboten werden, die die Interaktion dieser Objekte koordinieren. Es bietet auch vorgefertigte Diagramme für beliebte Open-Source-Projekte.

In diesem Lernprogramm stellen Sie eine Node.js -Anwendung mit einer MongoDB-Datenbank mithilfe von Helm-Diagrammen auf einem Kubernetes-Cluster bereit. Sie werden das offizielle Helm MongoDB-Replikatgruppendiagramm verwenden, um ein https://kubernetes.io/docs/concepts/workloads/ zu erstellen. controller / statefulset / [StatefulSet-Objekt] bestehend aus drei Pods, einem https://kubernetes.io/docs/concepts/services-networking/ service / # headless-services [Headless Service] und drei PersistentVolumeClaims. Sie erstellen auch ein Diagramm zum Bereitstellen einer Node.js-Anwendung mit mehreren Replikaten mithilfe eines benutzerdefinierten Anwendungsimages. Das Setup, das Sie in diesem Lernprogramm erstellen, spiegelt die Funktionalität des unter https://www.digitalocean.com/community/tutorials/containerizing-a-node-js-application-for-development-with-docker-compose beschriebenen Codes wider [Containerisieren einer Node.js-Anwendung mit Docker Compose] und ist ein guter Ausgangspunkt für die Erstellung einer ausfallsicheren Node.js-Anwendung mit einem MongoDB-Datenspeicher, der sich an Ihre Anforderungen anpassen lässt.

Voraussetzungen

Um dieses Tutorial abzuschließen, benötigen Sie:

  • Ein Kubernetes 1.10+ -Cluster mit aktivierter rollenbasierter Zugriffssteuerung (RBAC). Für dieses Setup wird ein DigitalOcean Kubernetes cluster verwendet. Sie können jedoch https://www.digitalocean.com/community/tutorials/how-to-create- a-kubernetes-1-11-cluster-using-kubeadm-on-ubuntu-18-04 [Cluster mit einer anderen Methode erstellen].

  • Das Befehlszeilentool "+ kubectl ", das auf Ihrem lokalen Computer oder Entwicklungsserver installiert und für die Verbindung mit Ihrem Cluster konfiguriert ist. Weitere Informationen zur Installation von " kubectl +" finden Sie in der offiziellen Dokumentation unter official documentation.

  • Helm auf Ihrem lokalen Computer oder Entwicklungsserver installiert und Tiller auf Ihrem Cluster installiert. Befolgen Sie dabei die Anweisungen in den Schritten 1 und 2 von https://www.digitalocean.com/community/tutorials/how-to-install-software-on- kubernetes-cluster-with-the-helm-package-manager [Installieren von Software auf Kubernetes-Clustern mit dem Helm Package Manager].

  • Docker auf Ihrem lokalen Computer oder Entwicklungsserver installiert. Wenn Sie mit Ubuntu 18.04 arbeiten, befolgen Sie die Schritte 1 und 2 unter How To Installieren und Verwenden von Docker unter Ubuntu 18.04; Andernfalls lesen Sie die official documentation, um Informationen zur Installation auf anderen Betriebssystemen zu erhalten. Stellen Sie sicher, dass Sie Ihren Nicht-Root-Benutzer zur Gruppe "+ docker +" hinzufügen, wie in Schritt 2 des verknüpften Lernprogramms beschrieben.

  • Ein Docker Hub Konto. Eine Übersicht über die Einrichtung finden Sie unter diese Einführung in Docker Hub.

Schritt 1 - Klonen und Packen der Anwendung

Um unsere Anwendung mit Kubernetes zu verwenden, müssen wir sie so packen, dass der https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ [+ kubelet + agent] das Image abrufen kann. Vor dem Packen der Anwendung müssen wir jedoch die MongoDB connection URI im Anwendungscode ändern, um sicherzustellen, dass unsere Anwendung eine Verbindung zu den Mitgliedern herstellen kann des Replikatsets, das wir mit dem Helm + mongodb-replicaset + Diagramm erstellen.

Unser erster Schritt ist das Klonen des Repositorys node-mongo-docker-dev von https://github.com/do -community [DigitalOcean Community GitHub-Konto]. Dieses Repository enthält den Code aus dem Setup, der unter Containerizing a Node.js Application beschrieben ist für die Entwicklung mit Docker Compose, in dem anhand einer Demo-Anwendung von Node.js mit einer MongoDB-Datenbank demonstriert wird, wie eine Entwicklungsumgebung mit Docker Compose eingerichtet wird. Weitere Informationen zur Anwendung selbst finden Sie in der Reihe From Containers to Kubernetes with Node.js.

Klonen Sie das Repository in ein Verzeichnis mit dem Namen "++":

git clone https://github.com/do-community/node-mongo-docker-dev.git

Navigiere zum ++ Verzeichnis:

cd

Das Verzeichnis "++" enthält Dateien und Verzeichnisse für eine Hai-Informationsanwendung, die mit Benutzereingaben arbeitet. Es wurde für die Arbeit mit Containern modernisiert: vertrauliche und spezifische Konfigurationsinformationen wurden aus dem Anwendungscode entfernt und für die Einfügung zur Laufzeit überarbeitet, und der Anwendungsstatus wurde in eine MongoDB-Datenbank ausgelagert.

Weitere Informationen zum Entwerfen moderner, containerisierter Anwendungen finden Sie unter Architecting Applications for Kubernetes und https://www.digitalocean.com/ community / tutorials / modernizing-applications-for-kubernetes [Anwendungen für Kubernetes modernisieren].

Wenn wir das Helm + mongodb-replicaset + Diagramm bereitstellen, wird Folgendes erstellt:

  • Ein StatefulSet-Objekt mit drei Pods - die Mitglieder des MongoDB-Sets replica. Jedem Pod ist ein PersistentVolumeClaim zugeordnet, und im Falle einer Umplanung wird eine feste Identität beibehalten.

  • Ein MongoDB-Replikatsatz, der aus den Pods im StatefulSet besteht. Das Set enthält eine primäre und zwei sekundäre. Die Daten werden von den primären auf die sekundären repliziert, um sicherzustellen, dass unsere Anwendungsdaten hoch verfügbar bleiben.

Damit unsere Anwendung mit den Datenbankreplikaten interagieren kann, muss der MongoDB-Verbindungs-URI in unserem Code sowohl die Hostnamen der Replikatgruppenmitglieder als auch den Namen der Replikatgruppe selbst enthalten. Wir müssen diese Werte daher in den URI aufnehmen.

Die Datei in unserem geklonten Repository, die Datenbankverbindungsinformationen angibt, heißt + db.js +. Öffne diese Datei jetzt mit + nano + oder deinem Lieblingseditor:

nano db.js

Derzeit enthält die Datei constants, auf die zur Laufzeit in der Datenbankverbindungs-URI verwiesen wird. Die Werte für diese Konstanten werden mithilfe der Eigenschaft https://nodejs.org/api/process.html#process_process_env [+ process.env +] von Node eingefügt, die zur Laufzeit ein Objekt mit Informationen zu Ihrer Benutzerumgebung zurückgibt. Durch das dynamische Festlegen von Werten in unserem Anwendungscode können wir den Code von der zugrunde liegenden Infrastruktur entkoppeln, was in einer dynamischen, statusfreien Umgebung erforderlich ist. Weitere Informationen zum Umgestalten von Anwendungscode auf diese Weise finden Sie unter https://www.digitalocean.com/community/tutorials/containerizing-a-node-js-application-for-development-with-docker-compose#step-2- % E2% 80% 94-Konfigurieren-Ihrer-Anwendung-zum-Arbeiten-mit-Containern [Schritt 2] von https://www.digitalocean.com/community/tutorials/containerizing-a-node-js-application-for -Development-with-Docker-Compose [Containerisieren einer Node.js-Anwendung für die Entwicklung mit Docker Compose] und die entsprechende Diskussion in The 12-Factor App.

Die Konstanten für den Verbindungs-URI und den URI-String selbst sehen derzeit folgendermaßen aus:

~ / node_project / db.js

...
const {
 MONGO_USERNAME,
 MONGO_PASSWORD,
 MONGO_HOSTNAME,
 MONGO_PORT,
 MONGO_DB
} = process.env;

...

const url = `mongodb://${MONGO_USERNAME}:${MONGO_PASSWORD}@${MONGO_HOSTNAME}:${MONGO_PORT}/${MONGO_DB}?authSource=admin`;
...

In Übereinstimmung mit einem 12FA-Ansatz möchten wir die Hostnamen unserer Replikatinstanzen oder unseren Replikatgruppennamen nicht fest in diese URI-Zeichenfolge codieren. Die vorhandene Konstante "+ MONGO_HOSTNAME " kann erweitert werden, um mehrere Hostnamen - die Mitglieder unseres Replikatsatzes - einzuschließen. Wir müssen jedoch eine Replikat-Set-Konstante zum Abschnitt https://docs.mongodb.com/manual/reference/connection-string/#components [` options +`] der URI-Zeichenfolge hinzufügen.

Fügen Sie dem URI-Konstantenobjekt und der Verbindungszeichenfolge "+ MONGO_REPLICASET +" hinzu:

~ / node_project / db.js

...
const {
 MONGO_USERNAME,
 MONGO_PASSWORD,
 MONGO_HOSTNAME,
 MONGO_PORT,
 MONGO_DB

} = process.env;

...
const url = `mongodb://${MONGO_USERNAME}:${MONGO_PASSWORD}@${MONGO_HOSTNAME}:${MONGO_PORT}/${MONGO_DB}?authSource=admin`;
...

Durch Verwendung der Option https://docs.mongodb.com/manual/reference/connection-string/#urioption.replicaSet [+ replicaSet +] im Abschnitt options des URI können wir den Namen des Replikatsatzes übergeben. Dies ermöglicht uns, zusammen mit den in der Konstante + MONGO_HOSTNAME + definierten Hostnamen, eine Verbindung zu den festgelegten Mitgliedern herzustellen.

Speichern und schließen Sie die Datei, wenn Sie mit der Bearbeitung fertig sind.

Wenn Ihre Datenbankverbindungsinformationen für die Arbeit mit Replikatsätzen geändert wurden, können Sie Ihre Anwendung jetzt paketieren und das Image mit dem Befehl `+docker build + ` erstellen und schieben Sie es zu Docker Hub.

Erstellen Sie das Bild mit "+ docker build " und der Markierung " -t ", mit der Sie das Bild mit einem einprägsamen Namen versehen können. In diesem Fall kennzeichnen Sie das Image mit Ihrem Docker Hub-Benutzernamen und nennen es "+" oder einen Namen Ihrer Wahl:

docker build -t / .

Das "+. +" Im Befehl gibt an, dass der Erstellungskontext das aktuelle Verzeichnis ist.

Es dauert ein oder zwei Minuten, um das Image zu erstellen. Überprüfen Sie anschließend Ihre Bilder:

docker images

Sie werden die folgende Ausgabe sehen:

OutputREPOSITORY                              TAG                 IMAGE ID            CREATED             SIZE
/   latest              56a69b4bc882        7 seconds ago       90.1MB
node                                    10-alpine           aa57b0242b33        6 days ago          71MB

Melden Sie sich als Nächstes bei dem Docker Hub-Konto an, das Sie unter den folgenden Voraussetzungen erstellt haben:

docker login -u

Wenn Sie dazu aufgefordert werden, geben Sie Ihr Docker Hub-Kontokennwort ein. Wenn Sie sich auf diese Weise anmelden, wird eine "+ ~ / .docker / config.json +" - Datei mit Ihren Docker Hub-Anmeldeinformationen im Stammverzeichnis Ihres Nicht-Root-Benutzers erstellt.

Senden Sie das Anwendungsimage mit dem Befehl https://docs.docker.com/engine/reference/commandline/push/[`docker push + `an Docker Hub. Denken Sie daran, "+" durch Ihren eigenen Docker Hub-Benutzernamen zu ersetzen:

docker push /

Sie haben jetzt ein Anwendungsimage, das Sie zum Ausführen Ihrer replizierten Anwendung mit Kubernetes herunterladen können. Der nächste Schritt besteht darin, bestimmte Parameter für die Verwendung mit dem MongoDB Helm-Diagramm zu konfigurieren.

Schritt 2 - Erstellen von Geheimnissen für das MongoDB-Replikatset

Das Diagramm "+ stable / mongodb-replicaset +" bietet verschiedene Optionen für die Verwendung von Secrets. Wir erstellen zwei Optionen für die Verwendung mit unserer Diagrammbereitstellung:

Mit diesen Geheimnissen können wir unsere bevorzugten Parameterwerte in einer dedizierten Wertedatei festlegen und das StatefulSet-Objekt und das MongoDB-Replikat erstellen, die mit dem Helm-Diagramm festgelegt wurden.

Zuerst erstellen wir die Schlüsseldatei. Wir werden den https://www.openssl.org/docs/man1.1.1/man1/openssl.html [+ openssl + Befehl] mit der Option + rand + verwenden, um eine 756-Byte-Zufallszeichenfolge für die Schlüsseldatei zu generieren:

openssl rand -base64 756 > key.txt

Die vom Befehl generierte Ausgabe wird base64 -codiert, um eine einheitliche Datenübertragung zu gewährleisten, und gemäß den Richtlinien in der Datei "+ key.txt " umgeleitet https://github.com/helm/charts/tree/master/stable/mongodb-replicaset#authentication [` mongodb-replicaset +` Dokumentation zur Kartenauthentifizierung]. Der key selbst muss zwischen 6 und 1024 Zeichen lang sein und nur aus Zeichen im base64-Satz bestehen.

Sie können jetzt ein Geheimnis namens "++" mit dieser Datei erstellen: `+kubectl create + ":

kubectl create secret generic  --from-file=key.txt

Dadurch wird ein geheimes Objekt im + default + namespace erstellt, da wir keinen bestimmten Namespace für unser Setup erstellt haben.

Sie sehen die folgende Ausgabe, die angibt, dass Ihr Secret erstellt wurde:

Outputsecret/keyfilesecret created

Entfernen Sie + key.txt +:

rm key.txt

Wenn Sie die Datei alternativ speichern möchten, stellen Sie sicher, dass https://docs.mongodb.com/manual/tutorial/enforce-keyfile-access-control-in-existing-replica-set/#create-a-keyfile [ beschränken Sie seine Berechtigungen] und fügen Sie es Ihrer https://git-scm.com/docs/gitignore [+ .gitignore + Datei] hinzu, um die Versionskontrolle zu umgehen.

Erstellen Sie als Nächstes das Geheimnis für Ihren MongoDB-Administrator. Der erste Schritt besteht darin, Ihren gewünschten Benutzernamen und Ihr Kennwort in base64 umzuwandeln.

Konvertieren Sie Ihren Datenbank-Benutzernamen:

echo -n '' | base64

Notieren Sie den Wert, den Sie in der Ausgabe sehen.

Als nächstes konvertieren Sie Ihr Passwort:

echo -n '' | base64

Beachten Sie auch hier den Wert in der Ausgabe.

Öffne eine Datei für das Geheimnis:

nano secret.yaml

Fügen Sie der Datei den folgenden Code hinzu, um ein Secret zu erstellen, das einen Benutzer und ein Kennwort mit den soeben erstellten codierten Werten definiert. Achten Sie darauf, die Dummy-Werte hier durch Ihren eigenen * verschlüsselten * Benutzernamen und Ihr Passwort zu ersetzen:

~ / node_project / secret.yaml

apiVersion: v1
kind: Secret
metadata:
 name:
data:
 user:
 password:

Hier verwenden wir die Schlüsselnamen, die das Diagramm "+ mongodb-replicaset " erwartet: " user " und " password ". Wir haben das geheime Objekt "+" genannt, aber Sie können es beliebig benennen.

Speichern und schließen Sie die Datei, wenn Sie mit der Bearbeitung fertig sind.

Erstellen Sie das geheime Objekt mit dem folgenden Befehl:

kubectl create -f secret.yaml

Sie werden die folgende Ausgabe sehen:

Outputsecret/mongo-secret created

Auch hier können Sie entweder "+ secret.yaml " entfernen oder seine Berechtigungen einschränken und zu Ihrer " .gitignore +" - Datei hinzufügen.

Nachdem Sie Ihre geheimen Objekte erstellt haben, können Sie die Parameterwerte angeben, die Sie mit dem Diagramm "+ mongodb-replicaset +" verwenden und die MongoDB-Bereitstellung erstellen.

Schritt 3 - Konfigurieren des MongoDB-Helmdiagramms und Erstellen einer Bereitstellung

Helm wird mit einem aktiv gepflegten Repository namens * stable * ausgeliefert, das das Diagramm enthält, das wir verwenden werden: + mongodb-replicaset +. Um dieses Diagramm mit den soeben erstellten Secrets zu verwenden, erstellen wir eine Datei mit Konfigurationsparameterwerten mit dem Namen "+ mongodb-values.yaml +" und installieren das Diagramm mithilfe dieser Datei.

Unsere + mongodb-values.yaml + Datei wird weitgehend die Standard-https://github.com/helm/charts/blob/master/stable/mongodb-replicaset/values.yaml [+ values.yaml + Datei] in spiegeln das Diagramm-Repository + mongodb-replicaset +. Wir werden jedoch die folgenden Änderungen an unserer Datei vornehmen:

  • Wir setzen den Parameter "+ auth " auf " true +", um sicherzustellen, dass unsere Datenbankinstanzen mit "https://docs.mongodb.com/manual/reference/program/mongod/#cmdoption-mongod-auth[authorization enabled" beginnen.] . Dies bedeutet, dass sich alle Clients für den Zugriff auf Datenbankressourcen und -vorgänge authentifizieren müssen.

  • Wir werden Informationen zu den Geheimnissen hinzufügen, die wir im vorherigen Schritt erstellt haben, damit das Diagramm diese Werte verwenden kann, um die Schlüsseldatei des Replikatsatzes und den Administratorbenutzer zu erstellen.

  • Wir verringern die Größe der mit jedem Pod im StatefulSet verknüpften PersistentVolumes, um die minimum viable DigitalOcean Block Storage unit (1 GB) zu verwenden Passen Sie dies an Ihre Speicheranforderungen an.

Bevor Sie die Datei + mongodb-values.yaml + schreiben, sollten Sie jedoch zunächst überprüfen, ob Sie eine StorageClass erstellt und für die Bereitstellung von Speicher konfiguriert haben Ressourcen. Jeder der Pods in Ihrer Datenbank StatefulSet verfügt über eine Sticky-Identität und ein zugehöriges PersistentVolumeClaim, das dynamisch ein PersistentVolume für den Pod bereitstellt. Wenn ein Pod neu geplant wird, wird das PersistentVolume an den Knoten angehängt, auf dem der Pod geplant ist (jedes Volume muss jedoch manuell gelöscht werden, wenn der zugehörige Pod oder StatefulSet dauerhaft gelöscht wird).

Da wir mit DigitalOcean Kubernetes arbeiten, ist unsere standardmäßige StorageClass + provisioner + auf + dobs.csi.digitalocean.com + - https: // www eingestellt .digitalocean.com / products / block-storage / [DigitalOcean Block Storage] - das können wir überprüfen, indem wir Folgendes eingeben:

kubectl get storageclass

Wenn Sie mit einem DigitalOcean-Cluster arbeiten, wird die folgende Ausgabe angezeigt:

OutputNAME                         PROVISIONER                 AGE
do-block-storage (default)   dobs.csi.digitalocean.com   21m

Wenn Sie nicht mit einem DigitalOcean-Cluster arbeiten, müssen Sie eine StorageClass erstellen und einen Provisioner Ihrer Wahl konfigurieren. Einzelheiten dazu finden Sie in der offiziellen Dokumentation unter official documentation.

Nachdem Sie sichergestellt haben, dass Sie eine StorageClass konfiguriert haben, öffnen Sie "+ mongodb-values.yaml +" zum Bearbeiten:

nano mongodb-values.yaml

In dieser Datei legen Sie Werte fest, die Folgendes bewirken:

  • Autorisierung aktivieren.

  • Verweisen Sie auf Ihre ` und ` Objekte.

  • Geben Sie "++" für Ihre PersistentVolumes an.

  • Setzen Sie Ihren Replikatsatznamen auf "++".

  • Geben Sie "+ 3 +" - Replikate für das Set an.

  • Pin das + mongo + Bild auf die neueste Version zum Zeitpunkt des Schreibens: ++.

Fügen Sie den folgenden Code in die Datei ein:

~ / node_project / mongodb-values.yaml

replicas:
port: 27017
replicaSetName:
podDisruptionBudget: {}
auth:
 enabled:
 existingKeySecret:
 existingAdminSecret:
imagePullSecrets: []
installImage:
 repository: unguiculus/mongodb-install
 tag: 0.7
 pullPolicy: Always
copyConfigImage:
 repository: busybox
 tag: 1.29.3
 pullPolicy: Always
image:
 repository: mongo
 tag:
 pullPolicy: Always
extraVars: {}
metrics:
 enabled: false
 image:
   repository: ssalaues/mongodb-exporter
   tag: 0.6.1
   pullPolicy: IfNotPresent
 port: 9216
 path: /metrics
 socketTimeout: 3s
 syncTimeout: 1m
 prometheusServiceDiscovery: true
 resources: {}
podAnnotations: {}
securityContext:
 enabled: true
 runAsUser: 999
 fsGroup: 999
 runAsNonRoot: true
init:
 resources: {}
 timeout: 900
resources: {}
nodeSelector: {}
affinity: {}
tolerations: []
extraLabels: {}
persistentVolume:
 enabled: true
 #storageClass: "-"
 accessModes:
   - ReadWriteOnce
 size:
 annotations: {}
serviceAnnotations: {}
terminationGracePeriodSeconds: 30
tls:
 enabled: false
configmap: {}
readinessProbe:
 initialDelaySeconds: 5
 timeoutSeconds: 1
 failureThreshold: 3
 periodSeconds: 10
 successThreshold: 1
livenessProbe:
 initialDelaySeconds: 30
 timeoutSeconds: 5
 failureThreshold: 3
 periodSeconds: 10
 successThreshold: 1

Der Parameter "+ persistentVolume.storageClass " ist hier auskommentiert: Wenn Sie den Kommentar entfernen und seinen Wert auf "" - "" setzen, wird die dynamische Bereitstellung deaktiviert. In unserem Fall, da wir diesen Wert undefiniert lassen, wählt das Diagramm den Standardwert " provisioner " - in unserem Fall " dobs.csi.digitalocean.com +".

Beachten Sie auch das "+ accessMode ", das dem " persistentVolume " - Schlüssel zugeordnet ist: " ReadWriteOnce +" bedeutet, dass das bereitgestellte Volume nur von einem einzelnen Knoten gelesen und geschrieben wird. Weitere Informationen zu den verschiedenen Zugriffsmodi finden Sie unter documentation.

Weitere Informationen zu den anderen in der Datei enthaltenen Parametern finden Sie in der configuration table, die im Repo enthalten ist.

Speichern und schließen Sie die Datei, wenn Sie mit der Bearbeitung fertig sind.

Bevor Sie das Diagramm "+ mongodb-replicaset +" bereitstellen, müssen Sie das * stable * -repo mit dem Befehl `+helm repo update + `aktualisieren aktualisieren. :

helm repo update

Dadurch werden die neuesten Karteninformationen aus dem * stable * -Repository abgerufen.

Zum Schluss installieren Sie das Diagramm mit dem folgenden Befehl:

helm install --name  -f  stable/mongodb-replicaset

Beachten Sie, dass wir den Helm release ++ nennen. Dieser Name bezieht sich auf diese bestimmte Bereitstellung des Diagramms mit den von uns angegebenen Konfigurationsoptionen. Wir haben auf diese Optionen hingewiesen, indem wir das Flag "+ -f " und unsere Datei " mongodb-values.yaml +" eingeschlossen haben.

Beachten Sie außerdem, dass Ihre Diagrammobjekte im + Standard-Namespace + erstellt werden, da wir das Flag "+ - Namespace" mit "+ helm install in" nicht eingefügt haben.

Nachdem Sie das Release erstellt haben, werden Informationen zum Status sowie Informationen zu den erstellten Objekten und Anweisungen für die Interaktion mit diesen angezeigt:

OutputNAME:   mongo
LAST DEPLOYED: Tue Apr 16 21:51:05 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME                              DATA  AGE
mongo-mongodb-replicaset-init     1     1s
mongo-mongodb-replicaset-mongodb  1     1s
mongo-mongodb-replicaset-tests    1     0s
...

Sie können jetzt die Erstellung Ihrer Pods mit dem folgenden Befehl überprüfen:

kubectl get pods

Während die Pods erstellt werden, wird eine Ausgabe wie die folgende angezeigt:

OutputNAME                         READY   STATUS     RESTARTS   AGE
mongo-mongodb-replicaset-0   1/1     Running    0          67s
mongo-mongodb-replicaset-1   0/1     Init:0/3   0          8s

Die Ausgänge "+ READY " und " STATUS " hier zeigen an, dass die Pods in unserem StatefulSet nicht vollständig bereit sind: die zugehörigen https://kubernetes.io/docs/concepts/workloads/pods/init-containers/[Init Containers] mit dem Pod laufen die Container noch. Da StatefulSet-Mitglieder https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees[created in sequential order] sind, muss jeder Pod im StatefulSet " Running +" und "" sein + Bereit + `bevor der nächste Pod erstellt wird.

Sobald die Pods erstellt wurden und alle zugehörigen Container ausgeführt werden, wird die folgende Ausgabe angezeigt:

OutputNAME                         READY   STATUS    RESTARTS   AGE
mongo-mongodb-replicaset-0   1/1     Running   0          2m33s
mongo-mongodb-replicaset-1   1/1     Running   0          94s
mongo-mongodb-replicaset-2   1/1     Running   0          36s

Das "+ Running" "+ STATUS" zeigt an, dass Ihre Pods an Knoten gebunden sind und die diesen Pods zugeordneten Container ausgeführt werden. + READY + gibt an, wie viele Container in einem Pod ausgeführt werden. Weitere Informationen finden Sie in der documentation on Pod lifecycles.

Jeder der Pods in Ihrem StatefulSet hat einen Namen, der den Namen des StatefulSet mit dem ordinal index des Pods kombiniert. Da wir drei Replikate erstellt haben, sind unsere StatefulSet-Mitglieder mit 0-2 nummeriert und jeder hat einen stable DNS-Eintrag bestehend aus die folgenden Elemente: + $ () - $ (). $ (). $ (). svc.cluster.local +.

In unserem Fall haben das StatefulSet- und das Headless Service -Diagramm die gleichen Namen:

kubectl get statefulset
OutputNAME                       READY   AGE
  3/3     4m2s
kubectl get svc
OutputNAME                              TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)     AGE
kubernetes                        ClusterIP   10.245.0.1   <none>        443/TCP     42m
         ClusterIP   None         <none>        27017/TCP   4m35s
mongo-mongodb-replicaset-client   ClusterIP   None         <none>        27017/TCP   4m35s

Dies bedeutet, dass das erste Mitglied unseres StatefulSet den folgenden DNS-Eintrag hat:

mongo-mongodb-replicaset-.mongo-mongodb-replicaset.default.svc.cluster.local

Da unsere Anwendung eine Verbindung zu jeder MongoDB-Instanz herstellen muss, ist es wichtig, dass wir über diese Informationen verfügen, damit wir direkt mit den Pods und nicht mit dem Service kommunizieren können. Wenn wir unser benutzerdefiniertes Anwendungs-Helmdiagramm erstellen, übergeben wir die DNS-Einträge für jeden Pod mithilfe von Umgebungsvariablen an unsere Anwendung.

Wenn Ihre Datenbankinstanzen ausgeführt werden, können Sie das Diagramm für Ihre Knotenanwendung erstellen.

Schritt 4 - Erstellen eines benutzerdefinierten Anwendungsdiagramms und Konfigurieren von Parametern

Wir erstellen ein benutzerdefiniertes Helmdiagramm für unsere Knotenanwendung und ändern die Standarddateien im Standarddiagrammverzeichnis, sodass unsere Anwendung mit dem soeben erstellten Replikatsatz arbeiten kann. Wir werden auch Dateien erstellen, um ConfigMap- und Secret-Objekte für unsere Anwendung zu definieren.

Erstellen Sie zunächst mit dem folgenden Befehl ein neues Diagrammverzeichnis mit dem Namen "++":

helm create

Dadurch wird ein Verzeichnis mit dem Namen "+" in Ihrem Ordner " ~ / +" mit den folgenden Ressourcen erstellt:

  • Eine + Chart.yaml + Datei mit grundlegenden Informationen zu Ihrem Diagramm.

  • Eine + values.yaml + - Datei, mit der Sie bestimmte Parameterwerte festlegen können, wie Sie es bei Ihrer MongoDB-Bereitstellung getan haben.

  • Eine "+ .helmignore +" - Datei mit Datei- und Verzeichnismustern, die beim Packen von Diagrammen ignoriert werden.

  • Ein "+ templates / +" - Verzeichnis mit den Vorlagendateien, die Kubernetes-Manifeste erzeugen werden.

  • Ein + templates / tests / + Verzeichnis für Testdateien.

  • Ein + charts / + Verzeichnis für alle Diagramme, von denen dieses Diagramm abhängt.

Die erste Datei, die wir aus diesen Standarddateien heraus modifizieren, ist + values.yaml +. Öffne diese Datei jetzt:

nano /values.yaml

Folgende Werte werden hier festgelegt:

Wir werden keine Umgebungsvariablen in diese Datei eingeben. Stattdessen erstellen wir Vorlagen für ConfigMap- und Secret-Objekte und fügen diese Werte zu unserem Anwendungs-Deployment-Manifest hinzu, das sich unter + ~ / node_project // templates / deployment.yaml + befindet.

Konfigurieren Sie die folgenden Werte in der Datei + values.yaml +:

~ / node_project / nodeapp / values.yaml

# Default values for nodeapp.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount:

image:
 repository: /
 tag:
 pullPolicy: IfNotPresent

nameOverride: ""
fullnameOverride: ""

service:
 type:
 port: 80

...

Speichern und schließen Sie die Datei, wenn Sie mit der Bearbeitung fertig sind.

Öffnen Sie als nächstes eine "+ secret.yaml" -Datei im "+ / templates" -Verzeichnis:

nano /templates/secret.yaml

Fügen Sie in dieser Datei Werte für Ihre Anwendungskonstanten "+ MONGO_USERNAME " und " MONGO_PASSWORD " hinzu. Dies sind die Konstanten, auf die Ihre Anwendung zur Laufzeit Zugriff haben soll, wie in ` db.js `, Ihrer Datenbankverbindungsdatei, angegeben. Denken Sie beim Hinzufügen der Werte für diese Konstanten daran, die base64-codierten Werte zu verwenden, die Sie zuvor in https://www.digitalocean.com/community/tutorials/how-to-scale-a-node-js verwendet haben -anwendung-mit-mongodb-mit-helm # step-2-% E2% 80% 94-erstellen-von-geheimnissen-für-das-mongodb-replikat-set [Step 2] beim erstellen ihres `+` objekts. Wenn Sie diese Werte neu erstellen müssen, können Sie zu Schritt 2 zurückkehren und die entsprechenden Befehle erneut ausführen.

Fügen Sie der Datei den folgenden Code hinzu:

~ / node_project / nodeapp / templates / secret.yaml

apiVersion: v1
kind: Secret
metadata:
 name: {{ .Release.Name }}-auth
data:
 MONGO_USERNAME:
 MONGO_PASSWORD:

Der Name dieses geheimen Objekts hängt vom Namen Ihrer Helm-Version ab, die Sie beim Bereitstellen des Anwendungsdiagramms angeben.

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Öffnen Sie als Nächstes eine Datei, um eine ConfigMap für Ihre Anwendung zu erstellen:

nano /templates/configmap.yaml

In dieser Datei definieren wir die verbleibenden Variablen, die von unserer Anwendung erwartet werden: "+ MONGO_HOSTNAME ", " MONGO_PORT ", " MONGO_DB " und " MONGO_REPLICASET ". Unsere Variable " MONGO_HOSTNAME +" enthält den DNS-Eintrag für * jede * Instanz in unserem Replikatsatz, da dies für den MongoDB-Verbindungs-URI erforderlich ist. .

Laut Kubernetes documentation führt eine Anwendung bei der Implementierung von Verfügbarkeits- und Bereitschaftsprüfungen https: / /kubernetes.io/docs/concepts/services-networking/dns-pod-service/#srv-records[SRV records] sollte verwendet werden, wenn eine Verbindung zu den Pods hergestellt wird. Wie in https://www.digitalocean.com/community/tutorials/how-to-scale-a-node-js-application-with-mongodb-using-helm#step-3-%E2%80%94- beschrieben Beim Konfigurieren der Mongodb-Steuertafel und Erstellen einer Bereitstellung [Schritt 3] folgen unsere Pod-SRV-Datensätze diesem Muster: `+ $ () - $ (). $ (). $ (). svc. cluster.local + `. Da unser MongoDB StatefulSet Verfügbarkeits- und Bereitschaftsprüfungen implementiert, sollten wir diese stabilen Bezeichner verwenden, wenn wir die Werte der Variablen "+ MONGO_HOSTNAME +" definieren.

Fügen Sie der Datei den folgenden Code hinzu, um die Variablen "+ MONGO_HOSTNAME ", " MONGO_PORT ", " MONGO_DB " und " MONGO_REPLICASET " zu definieren. Es steht Ihnen frei, einen anderen Namen für Ihre Datenbank " MONGO_DB " zu verwenden, aber Ihre Werte " MONGO_HOSTNAME " und " MONGO_REPLICASET +" müssen so geschrieben werden, wie sie hier angezeigt werden:

~ / node_project / nodeapp / templates / configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
 name: {{ .Release.Name }}-config
data:
 MONGO_HOSTNAME: "mongo-mongodb-replicaset-0.mongo-mongodb-replicaset.default.svc.cluster.local,mongo-mongodb-replicaset-1.mongo-mongodb-replicaset.default.svc.cluster.local,mongo-mongodb-replicaset-2.mongo-mongodb-replicaset.default.svc.cluster.local"
 MONGO_PORT: "27017"
 MONGO_DB: ""
 MONGO_REPLICASET: "db"

Da wir das StatefulSet-Objekt und den Replikatsatz bereits erstellt haben, müssen die hier aufgelisteten Hostnamen in Ihrer Datei genau so aufgeführt sein, wie sie in diesem Beispiel angezeigt werden. Wenn Sie diese Objekte zerstören und Ihre MongoDB Helm-Version umbenennen, müssen Sie die in dieser ConfigMap enthaltenen Werte überarbeiten. Gleiches gilt für + MONGO_REPLICASET +, da wir den Namen des Replikatsets in unserer MongoDB-Version angegeben haben.

Beachten Sie auch, dass die hier aufgelisteten Werte in Anführungszeichen stehen. Dies ist https://github.com/helm/helm/blob/master/docs/charts_tips_and_tricks.md#quote-strings-dont-quote-integers Helm].

Speichern und schließen Sie die Datei, wenn Sie mit der Bearbeitung fertig sind.

Nachdem Sie die Diagrammparameterwerte definiert und die Manifeste Secret und ConfigMap erstellt haben, können Sie die Anwendungsbereitstellungsvorlage bearbeiten, um Ihre Umgebungsvariablen zu verwenden.

Schritt 5 - Integrieren von Umgebungsvariablen in Ihre Helmbereitstellung

Mit den Dateien für unsere Anwendung Secret und ConfigMap müssen wir sicherstellen, dass unsere Anwendung Deployment diese Werte verwenden kann. Wir werden auch die liveness- and Readiness-Tests anpassen, die bereits im Bereitstellungsmanifest definiert sind.

Öffnen Sie die Anwendungsbereitstellungsvorlage zum Bearbeiten:

nano /templates/deployment.yaml

Obwohl es sich um eine YAML-Datei handelt, verwenden Helm-Vorlagen eine andere Syntax als Standard-Kubernetes-YAML-Dateien, um Manifeste zu generieren. Weitere Informationen zu Vorlagen finden Sie in der Helm documentation.

Fügen Sie in der Datei zunächst einen "+ env " - Schlüssel zu Ihren Anwendungscontainerspezifikationen hinzu, und zwar unterhalb des Schlüssels " imagePullPolicy " und oberhalb des Schlüssels " ports +":

~ / node_project / nodeapp / templates / deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
...
 spec:
   containers:
     - name: {{ .Chart.Name }}
       image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
       imagePullPolicy: {{ .Values.image.pullPolicy }}

       ports:

Fügen Sie als Nächstes die folgenden Schlüssel zur Liste der Variablen + env + hinzu:

~ / node_project / nodeapp / templates / deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
...
 spec:
   containers:
     - name: {{ .Chart.Name }}
       image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
       imagePullPolicy: {{ .Values.image.pullPolicy }}
       env:

Jede Variable enthält einen Verweis auf ihren Wert, der in diesem Fall entweder durch einen https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables [+ secretKeyRef + key] definiert wird of Secret values ​​oder https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#define-container-environment-variables-using-configmap-data [+ configMapKeyRef +] für ConfigMap-Werte. Diese Schlüssel verweisen auf die Secret- und ConfigMap-Dateien, die wir im vorherigen Schritt erstellt haben.

Ändern Sie als Nächstes unter der Taste "+ ports " die Definition " containerPort +", um den Port für den Container anzugeben, für den unsere Anwendung verfügbar gemacht werden soll:

~ / node_project / nodeapp / templates / deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
...
 spec:
   containers:
   ...
     env:
   ...
     ports:
       - name: http
         containerPort:
         protocol: TCP
     ...

Als Nächstes ändern wir die Aktivitäts- und Bereitschaftsprüfungen, die standardmäßig in diesem Bereitstellungsmanifest enthalten sind. Diese Überprüfungen stellen sicher, dass unsere Anwendungs-Pods ausgeführt werden und für den Verkehr bereit sind:

  • Bereitschaftsprüfungen bewerten, ob ein Pod für den Datenverkehr bereit ist, und stoppen alle Anforderungen an den Pod, bis die Überprüfungen erfolgreich sind.

  • Liveness-Tests überprüfen das grundlegende Anwendungsverhalten, um festzustellen, ob die Anwendung im Container ausgeführt wird und sich wie erwartet verhält. Wenn eine Aktivitätsprüfung fehlschlägt, startet Kubernetes den Container neu.

Weitere Informationen zu beiden finden Sie unter relevant discussion in https://www.digitalocean .com / community / tutorials / architekturanwendungen für kubernetes [architekturanwendungen für kubernetes].

In unserem Fall bauen wir auf der https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-http-request [+ httpGet + auf request], den Helm standardmäßig bereitgestellt hat, und testen Sie, ob unsere Anwendung Anforderungen auf dem Endpunkt "+ / sharks " akzeptiert. Der Dienst https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ [` kubelet `] sendet eine GET-Anforderung an den Node-Server, der im Container und des Anwendungs-Pod ausgeführt wird lausche an port ` 8080 `. Wenn der Statuscode für die Antwort zwischen 200 und 400 liegt, schließt das " kubelet ", dass der Container fehlerfrei ist. Andernfalls stoppt " kubelet +" im Falle eines 400- oder 500-Status entweder den Verkehr zum Container im Falle des Readiness-Tests oder startet den Container im Falle des Liveness-Tests neu.

Fügen Sie dem angegebenen "+ path +" für die Aktivitäts- und Bereitschaftsprüfungen die folgende Änderung hinzu:

~ / node_project / nodeapp / templates / deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
...
 spec:
   containers:
   ...
     env:
   ...
     ports:
       - name: http
         containerPort: 8080
         protocol: TCP
     livenessProbe:
       httpGet:
         path: /
         port: http
     readinessProbe:
       httpGet:
         path: /
         port: http

Speichern und schließen Sie die Datei, wenn Sie mit der Bearbeitung fertig sind.

Sie können jetzt Ihre Anwendungsfreigabe mit Helm erstellen. Führen Sie den folgenden Befehl aus: `+helm install + `, der den Namen der Version und den Speicherort des Diagrammverzeichnisses enthält:

helm install --name  ./

Denken Sie daran, dass Sie "+ helm install " zuerst mit den Optionen " - dry-run " und " - debug +" ausführen können (siehe https://www.digitalocean.com/community/tutorials/how-to) -skalieren-Sie-eine-Knoten-js-Anwendung-mit-Mongodb-unter-Verwendung-des-Ruders # step-3-% E2% 80% 94-Konfigurieren-des-Mongodb-Ruder-Diagramms-und-Erstellen-einer-Bereitstellung [Schritt 3 ], um die generierten Manifeste für Ihre Freigabe zu überprüfen.

Auch hier werden Ihre Diagrammobjekte im Standard-Namespace "" erstellt, da das Flag " - Namespace" mit "+ helm install in" nicht enthalten ist.

Die folgende Ausgabe zeigt an, dass Ihre Version erstellt wurde:

OutputNAME:   nodejs
LAST DEPLOYED: Wed Apr 17 18:10:29 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME           DATA  AGE
nodejs-config  4     1s

==> v1/Deployment
NAME            READY  UP-TO-DATE  AVAILABLE  AGE
nodejs-nodeapp  0/3    3           0          1s

...

Auch hier zeigt die Ausgabe den Status der Freigabe zusammen mit Informationen zu den erstellten Objekten und wie Sie mit ihnen interagieren können.

Überprüfen Sie den Status Ihrer Pods:

kubectl get pods
OutputNAME                              READY   STATUS    RESTARTS   AGE
mongo-mongodb-replicaset-0        1/1     Running   0          57m
mongo-mongodb-replicaset-1        1/1     Running   0          56m
mongo-mongodb-replicaset-2        1/1     Running   0          55m
nodejs-nodeapp-577df49dcc-b5fq5   1/1     Running   0          117s
nodejs-nodeapp-577df49dcc-bkk66   1/1     Running   0          117s
nodejs-nodeapp-577df49dcc-lpmt2   1/1     Running   0          117s

Sobald Ihre Pods betriebsbereit sind, überprüfen Sie Ihre Dienste:

kubectl get svc
OutputNAME                              TYPE           CLUSTER-IP     EXTERNAL-IP       PORT(S)        AGE
kubernetes                        ClusterIP      10.245.0.1     <none>            443/TCP        96m
mongo-mongodb-replicaset          ClusterIP      None           <none>            27017/TCP      58m
mongo-mongodb-replicaset-client   ClusterIP      None           <none>            27017/TCP      58m
nodejs-nodeapp                    LoadBalancer   10.245.33.46           80:31518/TCP   3m22s

Das "+ EXTERNAL_IP ", das dem " nodejs-nodeapp " - Dienst zugeordnet ist, ist die IP-Adresse, unter der Sie von außerhalb des Clusters auf die Anwendung zugreifen können. Wenn in der Spalte " EXTERNAL_IP " der Status " <ausstehend> +" angezeigt wird, wird Ihr Load Balancer noch erstellt.

Wenn Sie eine IP in dieser Spalte sehen, navigieren Sie in Ihrem Browser zu dieser IP: + http: // +.

Sie sollten die folgende Zielseite sehen:

image: https://assets.digitalocean.com/articles/docker_node_image/landing_page.png [Landing Page der Anwendung]

Nachdem Ihre replizierte Anwendung funktioniert, fügen wir einige Testdaten hinzu, um sicherzustellen, dass die Replikation zwischen Mitgliedern des Replikatsets funktioniert.

Schritt 6 - Testen der MongoDB-Replikation

Während unsere Anwendung ausgeführt wird und über eine externe IP-Adresse erreichbar ist, können wir einige Testdaten hinzufügen und sicherstellen, dass diese zwischen den Mitgliedern unseres MongoDB-Replikatsets repliziert werden.

Stellen Sie zunächst sicher, dass Sie mit Ihrem Browser zur Zielseite der Anwendung navigiert haben:

image: https://assets.digitalocean.com/articles/docker_node_image/landing_page.png [Landing Page der Anwendung]

Klicken Sie auf die Schaltfläche * Get Shark Info *. Sie sehen eine Seite mit einem Anmeldeformular, auf der Sie einen Hai-Namen und eine Beschreibung des allgemeinen Charakters dieses Hais eingeben können:

image: https://assets.digitalocean.com/articles/node_mongo/shark_form.png [Hai-Info-Formular]

Fügen Sie in das Formular einen ersten Hai Ihrer Wahl ein. Zur Veranschaulichung fügen wir dem Feld * Shark Name * "" und dem Feld * Shark Character * "" hinzu:

image: https://assets.digitalocean.com/articles/node_mongo/shark_filled.png [Gefülltes Haifischformular]

Klicken Sie auf die Schaltfläche * Senden *. Sie sehen eine Seite mit diesen Hai-Informationen, die Ihnen wieder angezeigt werden:

image: https://assets.digitalocean.com/articles/node_mongo/shark_added.png [Ausgabe von Haien]

Gehen Sie nun zurück zum Hai-Informationsformular, indem Sie in der oberen Navigationsleiste auf * Sharks * klicken:

image: https://assets.digitalocean.com/articles/node_mongo/shark_form.png [Hai-Info-Formular]

Geben Sie einen neuen Hai Ihrer Wahl ein. Wir gehen mit ` und `:

image: https: //assets.digitalocean.com/articles/node_docker_dev/whale_shark.png [Enter New Shark]

Sobald Sie auf "Senden" klicken, sehen Sie, dass der neue Hai der Haisammlung in Ihrer Datenbank hinzugefügt wurde:

image: https://assets.digitalocean.com/articles/node_docker_dev/persisted_data.png [Vollständige Hai-Sammlung]

Überprüfen Sie, ob die von uns eingegebenen Daten zwischen dem primären und dem sekundären Mitglied unseres Replikatsatzes repliziert wurden.

Holen Sie sich eine Liste Ihrer Pods:

kubectl get pods
OutputNAME                              READY   STATUS    RESTARTS   AGE
mongo-mongodb-replicaset-0        1/1     Running   0          74m
mongo-mongodb-replicaset-1        1/1     Running   0          73m
mongo-mongodb-replicaset-2        1/1     Running   0          72m
nodejs-nodeapp-577df49dcc-b5fq5   1/1     Running   0          5m4s
nodejs-nodeapp-577df49dcc-bkk66   1/1     Running   0          5m4s
nodejs-nodeapp-577df49dcc-lpmt2   1/1     Running   0          5m4s

Um auf die https://docs.mongodb.com/manual/reference/program/mongo/#bin.mongo [+ mongo + shell] auf Ihren Pods zuzugreifen, können Sie die https://kubernetes.io/docs/ verwenden. reference / generated / kubectl / kubectl-commands # exec [+ kubectl exec + command] und der Benutzername, mit dem Sie Ihr ++ in https://www.digitalocean.com/community/tutorials/how-to- erstellt haben Scale-a-Node-Js-Anwendung-mit-Mongodb-unter-Verwendung-Helm # Schritt-2-% E2% 80% 94-Erstellen-von-Geheimnissen-für-das-Mongodb-Replikat-Set [Schritt 2]. Greifen Sie mit dem folgenden Befehl auf die + mongo + - Shell auf dem ersten Pod im StatefulSet zu:

kubectl exec -it mongo-mongodb-replicaset- -- mongo -u  -p --authenticationDatabase admin

Wenn Sie dazu aufgefordert werden, geben Sie das mit diesem Benutzernamen verknüpfte Passwort ein:

OutputMongoDB shell version v4.1.9
Enter password:

Sie werden in eine Verwaltungsshell versetzt:

OutputMongoDB server version: 4.1.9
Welcome to the MongoDB shell.
...

db:PRIMARY>

Obwohl die Eingabeaufforderung selbst diese Informationen enthält, können Sie mit `+rs manuell überprüfen, welches Replikatgruppenmitglied das primäre ist. isMaster () + `Methode:

rs.isMaster()

Sie sehen eine Ausgabe wie die folgende, die den Hostnamen des primären angibt:

Outputdb:PRIMARY> rs.isMaster()
{
       "hosts" : [
               "mongo-mongodb-replicaset-0.mongo-mongodb-replicaset.default.svc.cluster.local:27017",
               "mongo-mongodb-replicaset-1.mongo-mongodb-replicaset.default.svc.cluster.local:27017",
               "mongo-mongodb-replicaset-2.mongo-mongodb-replicaset.default.svc.cluster.local:27017"
       ],
       ...
       "primary" : "mongo-mongodb-replicaset-0.mongo-mongodb-replicaset.default.svc.cluster.local:27017",
       ...

Wechseln Sie als nächstes zu Ihrer ++ Datenbank:

use
Outputswitched to db sharkinfo

Listen Sie die Sammlungen in der Datenbank auf:

show collections
Outputsharks

Die Dokumente in der Sammlung ausgeben:

db.sharks.find()

Sie werden die folgende Ausgabe sehen:

Output{ "_id" : ObjectId("5cb7702c9111a5451c6dc8bb"), "name" : "Megalodon Shark", "character" : "Ancient", "__v" : 0 }
{ "_id" : ObjectId("5cb77054fcdbf563f3b47365"), "name" : "Whale Shark", "character" : "Large", "__v" : 0 }

Beenden Sie die MongoDB Shell:

exit

Nachdem wir die Daten auf unserer Primärdatenbank überprüft haben, überprüfen wir, ob sie auf eine Sekundärdatenbank repliziert werden. + kubectl exec in` + mongo-mongodb-replica set-1 + `mit folgendem Befehl:

kubectl exec -it mongo-mongodb-replicaset- -- mongo -u  -p --authenticationDatabase admin

In der administrativen Shell müssen wir die Methode + db.setSlaveOk () + verwenden, um Leseoperationen von der sekundären Instanz zuzulassen:

db.setSlaveOk(1)

Wechseln Sie in die ++ Datenbank:

use sharkinfo
Outputswitched to db sharkinfo

Erlaube den Lesevorgang der Dokumente in der + sharks + Sammlung:

db.setSlaveOk(1)

Die Dokumente in der Sammlung ausgeben:

db.sharks.find()

Sie sollten jetzt dieselben Informationen sehen, die Sie beim Ausführen dieser Methode auf Ihrer Primärinstanz gesehen haben:

Outputdb:SECONDARY> db.sharks.find()
{ "_id" : ObjectId("5cb7702c9111a5451c6dc8bb"), "name" : "Megalodon Shark", "character" : "Ancient", "__v" : 0 }
{ "_id" : ObjectId("5cb77054fcdbf563f3b47365"), "name" : "Whale Shark", "character" : "Large", "__v" : 0 }

Diese Ausgabe bestätigt, dass Ihre Anwendungsdaten zwischen den Mitgliedern Ihres Replikatsatzes repliziert werden.

Fazit

Sie haben jetzt eine replizierte, hochverfügbare Hai-Informationsanwendung in einem Kubernetes-Cluster mithilfe von Helm-Diagrammen bereitgestellt. Diese Demo-Anwendung und der in diesem Tutorial beschriebene Workflow können als Ausgangspunkt für die Erstellung benutzerdefinierter Diagramme für Ihre Anwendung dienen und das * stable * -Repository von Helm und https://github.com/bitnami/charts/tree/master/ nutzen. bitnami [andere Kartendepots].

Erwägen Sie, auf dem Weg zur Produktion Folgendes zu implementieren:

Weitere Informationen zu Helm finden Sie unter Eine Einführung in Helm, den Paketmanager für Kubernetes , Installation von Software auf Kubernetes-Clustern mit dem Helm-Paket Manager und die Helm-Dokumentation.

Related