One place for hosting & domains

      richten

      So richten Sie eine Passwort-Authentifizierung mit Apache unter Ubuntu 18.04 ein [Schnellstart]


      Einführung

      Dieses Tutorial führt Sie durch den Passwortschutz von Assets auf einem Apache-Webserver, der unter Ubuntu 18.04. ausgeführt wird. Durch die Ausführung dieser Schritte wird Ihrem Server zusätzliche Sicherheit bereitgestellt, damit unbefugte Benutzer auf bestimmte Teile Ihrer Seite nicht zugreifen können.

      Eine ausführlichere Version dieses Tutorials mit detaillierteren Erklärungen zu den einzelnen Schritten finden Sie unter So richten Sie die Passwort-Authentifizierung mit Apache unter Ubuntu 18.04 ein.

      Voraussetzungen

      Um diesem Tutorial zu folgen, benötigen Sie auf einem Ubuntu 18.04-Server Zugriff auf Folgendes:

      • Einen sudo-Benutzer auf Ihrem Server

      • Einen Apache2-Webserver

      • Eine Site, die mit SSL gesichert ist

      Schritt 1 – Installation des Apache-Dienstprogramm-Pakets

      Wir installieren ein Dienstprogramm namens htpasswd, das Teil des apache2-utils-Pakets ist, um Benutzernamen und Passwörter mit Zugriff auf beschränkte Inhalte zu verwalten.

      • sudo apt update
      • sudo apt install apache2-utils

      Schritt 2 – Erstellen der Passwort-Datei

      Wir erstellen den ersten Benutzer wie folgt (ersetzen Sie `first_username durch einen Benutzernamen Ihrer Wahl):

      • sudo htpasswd -c /etc/apache2/.htpasswd first_username

      Sie werden aufgefordert, ein Passwort für den Benutzer anzugeben und zu bestätigen.

      Geben Sie nicht das Argument -c für zusätzliche Benutzer an, die Sie hinzufügen möchten, um die Datei nicht zu überschreiben:

      • sudo htpasswd /etc/apache2/.htpasswd another_user

      Schritt 3 – Einrichten der Apache Passwort-Authentifizierung

      In diesem Schritt müssen wir Apache konfigurieren, um diese Datei zu überprüfen, bevor wir unseren geschützten Inhalt bereitstellen. Dazu verwenden wir die virtuelle Host-Datei der Site, aber es gibt eine weitere Option, die im längeren Tutorial ausführlich beschrieben wird, wenn Sie keinen Zugriff haben oder lieber .htaccess-Dateien verwenden.

      Öffnen Sie die virtuelle Host-Datei, zu der Sie mit einem Textbearbeitungsprogramm wie nano eine Einschränkung hinzufügen möchten:

      • sudo nano /etc/apache2/sites-enabled/default-ssl.conf

      Die Authentifizierung wird pro Verzeichnis durchgeführt. In unserem Beispiel beschränken wir den gesamten Dokumentenstamm, aber Sie können diese Liste ändern, um nur auf ein bestimmtes Verzeichnis im Web-Raum abzuzielen.

      In diesem Schritt fügen Sie die folgenden hervorgehobenen Zeilen zu Ihrer Datei hinzu:

      /etc/apache2/sites-enabled/default-ssl.conf

      <VirtualHost *:80>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
      
        <Directory "/var/www/html">
            AuthType Basic
            AuthName "Restricted Content"
            AuthUserFile /etc/apache2/.htpasswd
            Require valid-user
        </Directory>
      </VirtualHost>
      

      Überprüfen Sie die Konfiguration mit dem folgenden Befehl:

      Sie können den Server neu starten, um Ihre Passwort-Richtlinien umzusetzen, und dann den Status Ihres Servers überprüfen.

      • sudo systemctl restart apache2
      • sudo systemctl status apache2

      Schritt 4 – Bestätigung der Passwort-Authentifizierung

      Um zu bestätigen, dass Ihr Inhalt geschützt ist, versuchen Sie, auf Ihren beschränkten Inhalt in einem Webbrowser zuzugreifen. Sie sollten eine Benutzernamen- und Passwort-Eingabeaufforderung sehen:

      Eingabeaufforderung für ein Apache2-Passwort

      Relevante Tutorials

      Hier sehen Sie Links zu detaillierteren Leitfäden, die in Verbindung mit diesem Tutorial stehen:



      Source link

      So richten Sie eine Passwort-Authentifizierung mit Apache unter Ubuntu 18.04 ein


      Einführung

      Für Sie als Web-Administrator könnte es eventuell sinnvoll sein, einige Teile einer Website vorübergehend oder dauerhaft für Besucher einzuschränken. Obwohl Webanwendungen möglicherweise ihre eigenen Authentifizierungs- und Autorisierungsmethoden anbieten, können Sie sich auch auf den Webserver selbst stützen, um den Zugriff einzuschränken, wenn diese unzureichend oder nicht verfügbar sind.

      Dieses Tutorial bietet Ihnen eine Vorgehensweise, um Assets auf einem Apache-Webserver, auf dem Ubuntu 18.04 ausgeführt wird, mit einem Passwort zu schützen, um Ihren Server mit zusätzlicher Sicherheit zu versehen.

      Voraussetzungen

      Um dieses Tutorial fertigzustellen, benötigen Sie Zugriff auf einen Ubuntu 18.04 Server.

      Zusätzlich benötigen Sie die folgende Einrichtung, bevor Sie beginnen können:

      • Einen sudo-Benutzer auf Ihrem Server: Sie können einen Benutzer mit sudo-Berechtigungen erstellen, indem Sie der Anleitung für die Ersteinrichtung eines Servers unter Ubuntu 18.04 folgen.

      • Einen Apache2-Webserver: Sollten Sie noch keinen eingerichtet haben, können Sie eine Hilfestellung in dem Tutorial So installieren Sie den Apache-Webserver unter Ubuntu 18.04 finden.

      • Eine mit SSL gesicherte Website: Wie Sie diese einrichten, hängt davon ab, ob Sie einen Domänenamen für Ihre Website haben.

        • Wenn Sie einen Domänennamen haben, können Sie Ihre Site mit Let’s Encrypt sichern, das kostenlose, vertrauenswürdige Zertifikate bereitstellt. Folgen Sie dem Leitfaden Let’s Encrypt für Apache, um diese Einrichtung vorzunehmen.
        • Wenn Sie keine Domäne haben und diese Konfiguration nur zu Testzwecken oder für den persönlichen Gebrauch verwenden, können Sie stattdessen ein selbstsigniertes Zertifikat verwenden. Damit wird die gleiche Art der Verschlüsselung bereitgestellt, aber ohne Domänenvalidierung. Folgen Sie dem Leitfaden für selbstsignierte SSL für Apache, um diese Einrichtung vorzunehmen.

      Wenn alle diese Voraussetzungen erfüllt sind, melden Sie sich als sudo-Benutzer an Ihrem Server an und fahren weiter unten fort.

      Schritt 1 – Installieren des Apache-Dienstprogrammpakets

      Beginnen wir, indem wir unseren Server aktualisieren und ein Paket installieren, das wir benötigen. Um diesem Tutorial zu folgen, verwenden wir ein Dienstprogramm namens htpasswd, das Teil des Pakets apache2-utils ist, um die Datei zu erstellen und den Benutzernamen und die Passwörter zu verwalten, die für den Zugriff auf eingeschränkte Inhalte benötigt werden.

      • sudo apt update
      • sudo apt install apache2-utils

      Wenn dies installiert ist, haben wir Zugriff auf den Befehl htpasswd.

      Schritt 2 – Erstellen der Passwort-Datei

      Mit dem Befehl htpasswd können wir eine Passwortdatei erstellen, die Apache zur Authentifizierung von Benutzern verwenden kann. Wir werden zu diesem Zweck eine versteckte Datei namens .htpasswd in unserem Konfigurationsverzeichnis /etc/apache2 erstellen.

      Wenn wir dieses Dienstprogramm zum ersten Mal verwenden, müssen wir die Option -c hinzufügen, um die spezifizierte passwdfile zu erstellen. Wir geben am Ende des Befehls einen Benutzernamen (in diesem Beispiel sammy) an, um einen neuen Eintrag in der Datei zu erstellen:

      • sudo htpasswd -c /etc/apache2/.htpasswd sammy

      Sie werden aufgefordert, ein Passwort für den Benutzer anzugeben und zu bestätigen.

      Geben Sie für zusätzliche Benutzer, die Sie hinzufügen möchten, nicht das Argument -c ein, um die Datei nicht zu überschreiben:

      • sudo htpasswd /etc/apache2/.htpasswd another_user

      Wenn wir den Inhalt der Datei ansehen, können wir für jeden Datensatz den Benutzernamen und das verschlüsselte Passwort sehen:

      • cat /etc/apache2/.htpasswd

      Output

      sammy:$apr1$.0CAabqX$rb8lueIORA/p8UzGPYtGs/ another_user:$apr1$fqH7UG8a$SrUxurp/Atfq6j7GL/VEC1

      Unsere Benutzer und Passwörter liegen jetzt in einem Format vor, das Apache lesen kann.

      Schritt 3 – Konfigurieren der Apache Passwort-Authentifizierung

      In diesem Schritt müssen wir Apache so konfigurieren, dass diese Datei überprüft wird, bevor unser geschützter Inhalt bereitgestellt wird. Wir können dies auf eine von zwei Arten tun: entweder direkt in der virtuellen Host-Datei einer Website oder indem wir .htaccess-Dateien in die Verzeichnisse übertragen, die eine Einschränkung benötigen. In der Regel empfiehlt sich die Verwendung der virtuellen Host-Datei. Wenn Sie jedoch Benutzern ohne Rootberechtigung die Verwaltung ihrer eigenen Zugriffsbeschränkungen ermöglichen müssen, die Einschränkungen in die Versionskontrolle der Website integrieren müssen oder eine Webanwendung haben, die .htaccess-Dateien bereits für andere Zwecke verwendet, sollten Sie die zweite Option ausprobieren.

      Wählen Sie die Option, die am besten für Ihre Bedürfnisse geeignet ist.

      Option 1: Konfigurieren der Zugriffskontrolle innerhalb der virtuellen Host-Definition (bevorzugt)

      Die erste Option besteht darin, die Apache-Konfiguration zu bearbeiten und den Passwortschutz zu der virtuellen Host-Datei hinzuzufügen. Dadurch wird im Allgemeinen eine bessere Leistung erzielt, da die Kosten für das Lesen von verteilten Konfigurationsdateien vermieden werden. Diese Option erfordert Zugriff auf die Konfiguration, der nicht immer verfügbar ist. Wenn Sie jedoch Zugriff haben, wird dies empfohlen.

      Beginnen Sie, indem Sie die virtuelle Host-Datei öffnen, der Sie eine Einschränkung hinzufügen möchten. Wir werden für unser Beispiel die Datei default-ssl.conf verwenden, die den virtuellen Standard-Host enthält, der über das Apache-Paket von Ubuntu installiert wurde. Öffnen Sie die Datei mit einem Befehlszeilen-Texteditor wie nano:

      • sudo nano /etc/apache2/sites-enabled/default-ssl.conf

      Ohne die Kommentare sollte die Datei in etwa wie folgt aussehen:

      /etc/apache2/sites-enabled/default-ssl.conf

      <VirtualHost *:80>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
      </VirtualHost>
      

      Die Authentifizierung wird pro Verzeichnis durchgeführt. Um die Authentifizierung einzurichten, müssen Sie das Verzeichnis, das Sie einschränken möchten, mit einem <Directory ___>-Block als Ziel angeben. In unserem Beispiel schränken wir den gesamte Dokumentenstamm ein. Sie können diese Auflistung jedoch so ändern, dass sie nur auf ein bestimmtes Verzeichnis innerhalb des Webspace abzielt:

      /etc/apache2/sites-enabled/default-ssl.conf

      <VirtualHost *:80>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
      
        <Directory "/var/www/html">
        </Directory>
      </VirtualHost>
      

      Innerhalb dieses Verzeichnisblocks legen wir fest, dass die Basic-Authentifizierung eingerichtet wird. Wählen Sie für den AuthName einen Bereichsnamen, der dem Benutzer bei der Aufforderung zur Eingabe der Anmeldedaten angezeigt wird. Verwenden Sie die Anweisung AuthUserFile, um Apache auf die von uns erstellte Passwort-Datei zu verweisen. Machen Sie es zum Schluss zur Bedingung, dass nur ein valid-user auf diese Ressource zugreifen kann, was bedeutet, dass jede Person, die ihre Identität mit einem Passwort verifizieren kann, Zugriff erhält.

      /etc/apache2/sites-enabled/default-ssl.conf

      <VirtualHost *:80>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
      
        <Directory "/var/www/html">
            AuthType Basic
            AuthName "Restricted Content"
            AuthUserFile /etc/apache2/.htpasswd
            Require valid-user
        </Directory>
      </VirtualHost>
      

      Wenn Sie fertig sind, speichern und schließen Sie die Datei. Wenn Sie nano verwenden, drücken Sie hierfür STRG+X, gefolgt von Y und dann der EINGABETASTE.

      Bevor Sie den Webserver neu starten, können Sie die Konfiguration mit dem folgenden Befehl überprüfen:

      • sudo apache2ctl configtest

      Wenn alles in Ordnung ist und Sie als Ausgabe Syntax OK erhalten, können Sie den Server neu starten, um Ihre Passwort-Richtlinie zu implementieren. Da systemctl nicht das Ergebnis aller Dienstverwaltungsbefehle anzeigt, verwenden wir status, um sicherzustellen, dass der Server ausgeführt wird:

      • sudo systemctl restart apache2
      • sudo systemctl status apache2

      Nun sollte das von Ihnen angegebene Verzeichnis passwortgeschützt sein.

      Option 2: Konfigurieren der Zugriffskontrolle mit .htaccess-Dateien

      Apache kann .htaccess-Dateien verwenden, um die Einstellung bestimmter Konfigurationselemente innerhalb eines Inhaltsverzeichnisses zu ermöglichen. Da Apache diese Dateien bei jeder das Verzeichnis betreffenden Anfrage erneut lesen muss, was sich negativ auf die Leistung auswirken kann, wird Option 1 bevorzugt. Wenn Sie jedoch bereits die Datei .htaccess verwenden oder Benutzern ohne Rootberechtigung die Verwaltung von Einschränkungen ermöglichen müssen, sind .htaccess-Dateien sinnvoll.

      Um den Passwortschutz unter Verwendung von .htaccess-Dateien zu aktivieren, öffnen Sie die Apache-Konfigurationsdatei mit einem Befehlszeilen-Texteditor wie nano:

      • sudo nano /etc/apache2/apache2.conf

      Suchen Sie den Block <Directory> für das Verzeichnis /var/www, in dem sich der Dokumentenstamm befindet. Aktivieren Sie die Verarbeitung von .htaccess, indem Sie die Anweisung AllowOverride innerhalb dieses Blocks von None zu All ändern:

      /etc/apache2/apache2.conf

      . . .
      
      <Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
      </Directory>
      
      . . .
      

      Wenn Sie fertig sind, speichern und schließen Sie die Datei. Wenn Sie nano verwenden, drücken Sie hierfür STRG+X, gefolgt von Y und dann der EINGABETASTE.

      Als Nächstes müssen wir dem Verzeichnis, das wir einschränken möchten, eine .htaccess-Datei hinzufügen. In unserer Demonstration beschränken wir den gesamten Dokumentenstamm (die gesamte Website), der auf /var/www/html basiert. Sie können diese Datei jedoch in jedem Verzeichnis ablegen, in dem Sie den Zugriff einschränken möchten:

      • sudo nano /var/www/html/.htaccess

      Innerhalb dieser Datei geben wir an, dass wir die Basic-Authentifizierung einrichten möchten. Wählen Sie für den AuthName einen Bereichsnamen, der dem Benutzer bei der Aufforderung zur Eingabe der Anmeldedaten angezeigt wird. Verwenden Sie die Anweisung AuthUserFile, um Apache auf die von uns erstellte Passwort-Datei zu verweisen. Abschließend erfordern wir den Zugriff auf diese Ressource durch einen valid-user, d. h. jede Person, die ihre Identität mit einem Passwort verifizieren kann, erhält Zugriff:

      /var/www/html/.htaccess

      AuthType Basic
      AuthName "Restricted Content"
      AuthUserFile /etc/apache2/.htpasswd
      Require valid-user
      

      Speichern und schließen Sie die Datei. Starten Sie den Webserver neu, um alle Inhalte in oder unterhalb des Verzeichnisses mit der .htaccess-Datei mit einem Passwort zu schützen, und verwenden Sie systemctl status, um den Erfolg des Neustarts zu überprüfen:

      • sudo systemctl restart apache2
      • sudo systemctl status apache2

      Das von Ihnen angegebene Verzeichnis sollte nun passwortgeschützt sein.

      Schritt 4 – Bestätigen der Passwort-Authentifizierung

      Um zu bestätigen, dass Ihr Inhalt geschützt ist, versuchen Sie, in einem Webbrowser auf Ihren eingeschränkten Inhalt zuzugreifen. Sie sollten eine Aufforderung zur Eingabe von Benutzername und Passwort erhalten, die wie folgt aussieht:

      Eingabeaufforderung für ein Apache2-Passwort

      Wenn Sie die richtigen Anmeldedaten eingeben, können Sie auf den Inhalt zugreifen. Wenn Sie die falschen Anmeldedaten eingeben oder auf „Cancel“ klicken, wird die Fehlerseite „Unauthorized“ angezeigt:

      Apache2 Fehler „unauthorized“

      Zusammenfassung

      Herzlichen Glückwunsch! Wenn Sie diesem Tutorial gefolgt sind, haben Sie nun die standardmäßige Authentifizierung für Ihre Website eingerichtet.

      Sie können mit der Apache-Konfiguration und .htaccess noch wesentlich mehr tun. Um mehr über die Flexibilität und Leistungsfähigkeit der Apache-Konfiguration zu erfahren, probieren Sie eines dieser Tutorials aus:



      Source link

      So richten Sie ReadWriteMany (RWX) Persistent Volumes mit NFS unter DigitalOcean Kubernetes ein


      Einführung

      Aufgrund der verteilten und dynamischen Natur von Containern ist die statische Verwaltung und Konfiguration von Speicher in Kubernetes zu einem schwierigen Problem geworden, da Arbeitslasten jetzt in der Lage sind, innerhalb von Sekunden von einer virtuellen Maschine (VM) auf eine andere zu wechseln. Um dieses Problem zu lösen, verwaltet Kubernetes Volumes mit einem System aus Persistent Volumes (PV), API-Objekten, die eine Speicherkonfiguration/ein Volume darstellen, und PersistentVolumeClaims (PVC), einer Speicheranforderung, die von einem Persistent Volume erfüllt werden soll. Darüber hinaus können Container Storage Interface (CSI)-Treiber dazu beitragen, die Handhabung und Bereitstellung von Speicher für containerisierte Workloads zu automatisieren und zu verwalten. Diese Treiber sind für die Bereitstellung, das Einbinden, das Aufheben der Einbindung, das Entfernen und das Erstellen von Snapshots von Volumes verantwortlich.

      Das digitalocean-csi integriert einen Kubernetes-Cluster mit dem Produkt DigitalOcean Block Storage. Damit kann ein Entwickler Blockspeicher-Volumes für containerisierte Anwendungen in Kubernetes dynamisch bereitstellen. Anwendungen können jedoch manchmal erfordern, dass Daten über mehrere Droplets hinweg persistent gespeichert und gemeinsam genutzt werden. Die Blockspeicher-CSI-Standardlösung von DigitalOcean ist nicht in der Lage, das gleichzeitige Einbinden eines Blockspeicher-Volumes in mehrere Droplets zu unterstützen. Dies bedeutet, dass es sich um eine ReadWriteOnce (RWO)-Lösung handelt, da das Volume auf einen Knoten beschränkt ist. Das Protokoll Network File System (NFS) hingegen unterstützt das Exportieren derselben Freigabe an viele Consumer. Dies wird ReadWriteMany (RWX) genannt, da viele Knoten das Volume als Read-Write einbinden können. Wir können daher einen NFS-Server innerhalb unseres Clusters verwenden, um Speicher bereitzustellen, der die zuverlässige Unterstützung von DigitalOcean Block Storage mit der Flexibilität von NFS-Freigaben nutzen kann.

      In diesem Tutorial werden Sie die dynamische Bereitstellung für NFS-Volumes innerhalb eines DigitalOcean Kubernetes (DOKS)-Clusters, in dem die Exporte auf DigitalOcean Block-Speichervolumes gespeichert werden, konfigurieren. Anschließend werden Sie mehrere Instanzen einer Nginx-Demoanwendung bereitstellen und die gemeinsame Nutzung von Daten zwischen den einzelnen Instanzen testen.

      Voraussetzungen

      Bevor Sie mit diesem Leitfaden beginnen, benötigen Sie Folgendes:

      • Die auf Ihrem lokalen Rechner installierte Befehlszeilenschnittstelle kubectl. Mehr über die Installation und Konfiguration von kubectl können Sie der offiziellen Dokumentation entnehmen.

      • Einen DigitalOcean Kubernetes-Cluster, bei dem Ihre Verbindung standardmäßig als kubectl konfiguriert ist. Um einen Kubernetes-Cluster auf DigitalOcean zu erstellen, lesen Sie unseren Kubernetes-Schnellstart. Eine Anleitung zur Konfiguration von kubectl finden Sie unter dem Schritt Verbinden mit Ihrem Cluster, wenn Sie Ihren Cluster erstellen.

      • Den auf Ihrem lokalen Rechner installierten Helm-Paketmanager und das auf Ihrem Cluster installierte Tiller. Führen Sie dazu die Schritte 1 und 2 des Tutorials So installieren Sie Software auf Kubernetes Clustern mit dem Helm-Paketmanager aus.

      Hinweis: Ab Helm Version 3.0 muss Tiller nicht mehr installiert werden, damit Helm funktioniert. Wenn Sie die neueste Version von Helm verwenden, finden Sie die Anweisungen in der Helm-Installationsdokumentation.

      Schritt 1 – Bereitstellen des NFS-Servers mit Helm

      Für die Bereitstellung des NFS-Servers verwenden Sie ein Helm Chart. Die Bereitstellung eines Helm Charts ist eine automatisierte Lösung, die schneller und weniger fehleranfällig ist als die manuelle Erstellung der NFS-Serverbereitstellung.

      Stellen Sie zuerst sicher, dass das standardmäßige Chart-Repository stable verfügbar ist, indem Sie das Repo hinzufügen:

      • helm repo add stable https://kubernetes-charts.storage.googleapis.com/

      Als Nächstes rufen Sie die Metadaten für das Repository ab, das Sie gerade hinzugefügt haben. Dadurch wird sichergestellt, dass der Helm-Client aktualisiert wird:

      Um den Zugriff auf das Repo stable zu verifizieren, führen Sie eine Suche in den Charts aus:

      Dadurch erhalten Sie eine Liste der verfügbaren Charts, ähnlich der folgenden:

      Output

      NAME CHART VERSION APP VERSION DESCRIPTION stable/acs-engine-autoscaler 2.2.2 2.1.1 DEPRECATED Scales worker nodes within agent pools stable/aerospike 0.3.2 v4.5.0.5 A Helm chart for Aerospike in Kubernetes stable/airflow 5.2.4 1.10.4 Airflow is a platform to programmatically autho... stable/ambassador 5.3.0 0.86.1 A Helm chart for Datawire Ambassador ...

      Das Ergebnis bedeutet, dass Ihr Helm-Client ausgeführt wird und auf dem neuesten Stand ist.

      Nachdem Helm nun eingerichtet ist, installieren Sie das Helm Chart nfs-server-provisioner, um den NFS-Server einzurichten. Wenn Sie den Inhalt des Charts untersuchen möchten, werfen Sie einen Blick in seine Dokumentation auf GitHub.

      Wenn Sie das Helm-Chart bereitstellen, legen Sie einige Variablen für Ihren NFS-Server fest, um die Konfiguration für Ihre Anwendung weiter zu spezifizieren. Sie können auch andere Konfigurationsoptionen untersuchen und sie an die Bedürfnisse der Anwendung anpassen.

      Verwenden Sie den folgenden Befehl, um das Helm-Chart zu installieren:

      • helm install nfs-server stable/nfs-server-provisioner --set persistence.enabled=true,persistence.storageClass=do-block-storage,persistence.size=200Gi

      Dieser Befehl stellt einen NFS-Server mit den folgenden Konfigurationsoptionen bereit:

      • Fügt ein Persistent Volume für den NFS-Server mit dem Flag --set hinzu. Dadurch wird sichergestellt, dass alle gemeinsam genutzten NFS-Daten auch bei Pod-Neustarts persistent gespeichert sind.
      • Für die persistente Speicherung wird die Speicherklasse do-block-storage verwendet.
      • Stellt insgesamt 200Gi für den NFS-Server bereit, die in Exporte aufgeteilt werden können.

      Hinweis: Die Option persistence.size bestimmt die Gesamtkapazität aller NFS-Volumes, die Sie bereitstellen können. Zum Zeitpunkt dieser Veröffentlichung unterstützen nur die DOKS Version 1.16.2-do.3 und spätere Versionen die Erweiterung von Volumes, sodass die Größenänderung dieses Volumes eine manuelle Aufgabe ist, wenn Sie eine frühere Version verwenden. Stellen Sie in diesem Fall sicher, dass Sie diese Größe im Hinblick auf Ihre zukünftigen Bedürfnisse einstellen.

      Nachdem dieser Befehl abgeschlossen ist, erhalten Sie eine Ausgabe, die der folgenden ähnelt:

      Output

      NAME: nfs-server LAST DEPLOYED: Thu Feb 13 19:30:07 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: The NFS Provisioner service has now been installed. A storage class named 'nfs' has now been created and is available to provision dynamic volumes. You can use this storageclass by creating a PersistentVolumeClaim with the correct storageClassName attribute. For example: --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: test-dynamic-volume-claim spec: storageClassName: "nfs" accessModes: - ReadWriteOnce resources: requests: storage: 100Mi

      Um den von Ihnen bereitgestellten NFS-Server zu sehen, führen Sie den folgenden Befehl aus:

      Dadurch wird Folgendes angezeigt:

      Output

      NAME READY STATUS RESTARTS AGE nfs-server-nfs-server-provisioner-0 1/1 Running 0 11m

      Prüfen Sie als Nächstes die von Ihnen erstellte storageclass:

      Sie erhalten eine Ausgabe, die der folgenden ähnelt:

      Output

      NAME PROVISIONER AGE do-block-storage (default) dobs.csi.digitalocean.com 90m nfs cluster.local/nfs-server-nfs-server-provisioner 3m

      Sie haben nun einen NFS-Server sowie einen storageclass, die Sie für die dynamische Bereitstellung von Volumes verwenden können. Als Nächstes können Sie eine Bereitstellung erstellen, die diesen Speicher verwendet, und ihn über mehrere Instanzen hinweg gemeinsam nutzen.

      Schritt 2 – Bereitstellen einer Anwendung unter Verwendung eines gemeinsam genutzten PersistentVolumeClaim

      In diesem Schritt erstellen Sie eine beispielhafte Bereitstellung auf Ihrem DOKS-Cluster, um Ihre Speichereinrichtung zu testen. Dies wird eine Nginx Webserver-Anwendung namens web sein.

      Um diese Anwendung bereitzustellen, schreiben Sie zunächst die YAML-Datei, um die Bereitstellung zu spezifizieren. Öffnen Sie eine Datei nginx-test.yaml mit Ihrem Texteditor; dieses Tutorial verwendet nano:

      Fügen Sie in diese Datei die folgenden Zeilen ein, um die Bereitstellung mit einem PersistentVolumeClaim namens nfs-data zu definieren:

      nginx-test.yaml

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        labels:
          app: web
        name: web
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: web
        strategy: {}
        template:
          metadata:
            creationTimestamp: null
            labels:
              app: web
          spec:
            containers:
            - image: nginx:latest
              name: nginx
              resources: {}
              volumeMounts:
              - mountPath: /data
                name: data
            volumes:
            - name: data
              persistentVolumeClaim:
                claimName: nfs-data
      ---
      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: nfs-data
      spec:
        accessModes:
        - ReadWriteMany
        resources:
          requests:
            storage: 2Gi
        storageClassName: nfs
      

      Speichern Sie die Datei und beenden Sie den Texteditor.

      Diese Bereitstellung ist so konfiguriert, dass sie die zugehörigen PersistentVolumeClaim nfs-data verwendet und sie unter /data einbindet.

      In der PVC-Definition werden Sie feststellen, dass der storageClassName auf nfs gesetzt ist. Damit wird dem Cluster mitgeteilt, dass er diese Speicherung nach den Regeln der nfs storageClass, die Sie im vorherigen Schritt erstellt haben, erfüllen muss. Der neue PersistentVolumeClaim wird verarbeitet und dann wird eine NFS-Freigabe bereitgestellt, um den Anspruch in Form eines Persistent Volumes zu erfüllen. Der Pod wird versuchen, dieses PVC einzubinden, sobald es bereitgestellt wurde. Nach dem Einbinden verifizieren Sie die Funktionalität ReadWriteMany (RWX).

      Führen Sie die Bereitstellung mit dem folgenden Befehl aus:

      • kubectl apply -f nginx-test.yaml

      Dadurch erhalten Sie folgende Ausgabe:

      Output

      deployment.apps/web created persistentvolumeclaim/nfs-data created

      Als Nächstes prüfen Sie, ob der Pod web anläuft:

      Dadurch wird Folgendes ausgegeben:

      Output

      NAME READY STATUS RESTARTS AGE nfs-server-nfs-server-provisioner-0 1/1 Running 0 23m web-64965fc79f-b5v7w 1/1 Running 0 4m

      Nachdem nun die Beispielbereitstellung läuft, können Sie sie mit dem Befehl kubectl scale auf drei Instanzen skalieren:

      • kubectl scale deployment web --replicas=3

      Dadurch erhalten Sie folgende Ausgabe:

      Output

      deployment.extensions/web scaled

      Führen Sie nun den Befehl kubectl get erneut aus:

      Sie finden die skalierten Instanzen der Bereitstellung:

      Output

      NAME READY STATUS RESTARTS AGE nfs-server-nfs-server-provisioner-0 1/1 Running 0 24m web-64965fc79f-q9626 1/1 Running 0 5m web-64965fc79f-qgd2w 1/1 Running 0 17s web-64965fc79f-wcjxv 1/1 Running 0 17s

      Sie haben nun drei Instanzen Ihrer Nginx-Bereitstellung, die mit demselben Persistent Volume verbunden sind. Im nächsten Schritt stellen Sie sicher, dass sie Daten untereinander gemeinsam nutzen können.

      Schritt 3 – Validieren der gemeinsamen Nutzung von NFS-Daten

      Im letzten Schritt überprüfen Sie, ob die Daten von allen Instanzen, die in die NFS-Freigabe eingebunden sind, gemeinsam genutzt werden. Dazu erstellen Sie eine Datei im Verzeichnis /data in einem der Pods und verifizieren dann, ob die Datei in dem Verzeichnis /data eines anderen Pods vorhanden ist.

      Um dies zu validieren, verwenden Sie den Befehl kubectl exec. Mit diesem Befehl können Sie einen Pod angeben und einen Befehl innerhalb dieses Pods ausführen. Um mehr über die Überprüfung von Ressourcen unter Verwendung von kubectl zu erfahren, werfen Sie einen Blick auf unseren kubectl-Spickzettel.

      Um innerhalb eines Ihrer Pods web eine Datei namens hello_world zu erstellen, verwenden Sie den Befehl kubectl exec, um den Befehl touch weiterzugeben. Beachten Sie, dass die Zahl nach web im Pod-Namen für Sie unterschiedlich sein wird. Achten Sie also darauf, den hervorgehobenen Pod-Namen durch einen Ihrer eigenen Pods zu ersetzen, die Sie im letzten Schritt als Ausgabe von kubectl get pods gefunden haben.

      • kubectl exec web-64965fc79f-q9626 -- touch /data/hello_world

      Ändern Sie dann den Namen des Pod und verwenden Sie den Befehl ls, um die Dateien im Verzeichnis /data eines anderen Pods aufzulisten:

      • kubectl exec web-64965fc79f-qgd2w -- ls /data

      Ihre Ausgabe zeigt die Datei an, die Sie im ersten Pod erstellt haben:

      Output

      hello_world

      Dies zeigt, dass alle Pods Daten über NFS gemeinsam nutzen und dass Ihre Einrichtung korrekt funktioniert.

      Zusammenfassung

      In diesem Tutorial haben Sie einen NFS-Server erstellt, der durch DigitalOcean Block Storage unterstützt wurde. Der NFS-Server verwendete dann diesen Blockspeicher zur Bereitstellung und zum Export von NFS-Freigaben für Workloads in einem RWX-kompatiblen Protokoll. Auf diese Weise konnten Sie eine technische Beschränkung der Blockspeicherung von DigitalOcean umgehen und dieselben PVC-Daten über viele Pods hinweg gemeinsam nutzen. Durch dieses Tutorial ist Ihr DOKS-Cluster nun so eingerichtet, dass er eine wesentlich größere Anzahl von Anwendungsfällen für die Bereitstellung unterstützt.

      Wenn Sie mehr über Kubernetes erfahren möchten, sehen Sie sich unser Curriculum für Full-Stack-Entwickler oder die Produktdokumentation für DigitalOcean Kubernetes an.



      Source link