Verwenden von Docker zum Einrichten von Nginx Reverse Proxy mit automatischer SSL-Generierung

Was ist ein Reverse-Proxy? Was sind seine Vorteile?

Was ist ein Reverse-Proxy? Reverse Proxy ist eine Art Server, der vor vielen anderen Servern sitzt und die Client-Anfragen an die entsprechenden Server weiterleitet. Die Antwort des Servers wird dann ebenfalls vom Proxy-Server entgegengenommen und an den Client weitergeleitet.

Warum sollten Sie eine solche Konfiguration verwenden? Dafür gibt es mehrere gute Gründe. Dieses Setup kann zum Einrichten eines Load Balancers, Caching oder zum Schutz vor Angriffen verwendet werden.

Ich gehe hier nicht in die Details. Stattdessen zeige ich Ihnen, wie Sie das Konzept des Reverse-Proxys nutzen können, um mehrere Dienste auf demselben Server einzurichten.

Nehmen Sie das gleiche Bild wie das, das Sie oben gesehen haben. Was Sie tun können, ist, einen Ngnix-Server in einem Docker-Container im Reverse-Proxy-Modus auszuführen. Andere Webdienste können auch in ihren eigenen jeweiligen Containern ausgeführt werden.

Der Nginx-Container wird so konfiguriert, dass er weiß, welcher Webdienst in welchem ​​Container ausgeführt wird.

Dies ist eine gute Möglichkeit, Kosten für das Hosten jedes Dienstes auf einem anderen Server zu sparen. Dank des Reverse-Proxy-Servers können Sie mehrere Dienste auf demselben Linux-Server ausführen.

Einrichten von Nginx als Reverse-Proxy, um mehrere Dienste auf dem bereitzustellen gleichen Server mit Docker

Lassen Sie mich Ihnen zeigen, wie Sie das oben erwähnte Setup konfigurieren.

Mit diesen Schritten können Sie mehrere webbasierte Anwendungscontainer installieren, die unter Nginx ausgeführt werden, wobei jeder eigenständige Container seiner eigenen jeweiligen Domain oder Subdomain entspricht.

Lassen Sie uns zuerst sehen, was Sie brauchen, um diesem Tutorial zu folgen.

Voraussetzungen

Sie benötigen die folgenden Kenntnisse, um problemlos mit diesem Tutorial beginnen zu können. Obwohl, du kannst auch ohne sie auskommen.

• Ein Linux-System/Server. Mit dem Linode-Cloud-Service können Sie ganz einfach einen Linux-Server in wenigen Minuten bereitstellen.
• Vertrautheit mit Linux-Befehlen und -Terminal.
• Grundkenntnisse von Docker.
• Sie sollten Docker und Docker Compose auf Ihrem Linux-Server installiert haben. Bitte lesen Sie unsere Anleitung zur Installation von Docker und Docker Compose auf CentOS.
• Sie sollten auch eine Domain besitzen (damit Sie Dienste auf Subdomains einrichten können).

Ich habe domain.com als Beispiel-Domainnamen im Tutorial verwendet. Bitte stellen Sie sicher, dass Sie es entsprechend Ihren eigenen Domains oder Subdomains ändern.

Abgesehen von den oben genannten Stellen Sie bitte auch die folgenden Dinge sicher:

DNS-Einträge Ihrer Domain ändern

Stellen Sie im A/AAAA- oder CNAME-Eintragsfeld Ihres Domainnamenanbieters sicher, dass sowohl die Domain als auch die Subdomains (einschließlich www) auf die IP-Adresse Ihres Servers verweisen.

Dies ist ein Beispiel für Ihre Referenz:

Hostname	IP-Adresse	TTL
domain.com	172.105.50.178	Standard
*	172.105.50.178	Standard
sub0.domain.com	172.105.50.178	Standard
sub1.domain.com	172.105.50.178	Standard

Leerzeichen tauschen

Um sicherzustellen, dass sich alle Ihre Container-Apps wohlfühlen und ihnen nach der Bereitstellung nie der Arbeitsspeicher ausgeht, müssen Sie über den erforderlichen Auslagerungsspeicher auf Ihrem System verfügen.

Sie können den Swap jederzeit entsprechend dem verfügbaren RAM auf Ihrem System anpassen. Sie können den Auslagerungsbereich basierend auf dem Bündel von App-Containern auf dem einzelnen Server festlegen und deren kumulierte RAM-Nutzung schätzen.

Schritt 1:Nginx-Reverse-Proxy-Container einrichten

Beginnen Sie mit der Einrichtung Ihres Nginx-Reverse-Proxys. Erstellen Sie ein Verzeichnis namens "reverse-proxy" und wechseln Sie dorthin:

mkdir reverse-proxy && cd reverse-proxy

Erstellen Sie eine Datei namens docker-compose.yml , öffnen Sie es in Ihrem bevorzugten terminalbasierten Texteditor wie Vim oder Nano.

Für den nginx-Reverse-Proxy verwende ich das jwilder/nginx-proxy-Image. Kopieren Sie Folgendes und fügen Sie es in die Datei docker-compose.yml ein:

version: "3.7"

services:

    reverse-proxy:
        image: "jwilder/nginx-proxy:latest"
        container_name: "reverse-proxy"
        volumes:
            - "html:/usr/share/nginx/html"
            - "dhparam:/etc/nginx/dhparam"
            - "vhost:/etc/nginx/vhost.d"
            - "certs:/etc/nginx/certs"
            - "/run/docker.sock:/tmp/docker.sock:ro"
        restart: "always"
        networks: 
            - "net"
        ports:
            - "80:80"
            - "443:443"

Lassen Sie uns nun die wichtigen Teile der Compose-Datei durchgehen:

• Sie haben vier Volumes deklariert, html, dhparam, vhost und certs. Es handelt sich um persistente Daten, die Sie auf jeden Fall auch nach dem Ausfall des Containers behalten möchten. Die html &vhost Volumes werden bei der nächsten Bereitstellung von Let's Encrypt-Containern sehr wichtig sein. Sie sind so konzipiert, dass sie zusammenarbeiten.
• Der Docker-Socker ist im Container schreibgeschützt gemountet. Dies ist für den Reverse-Proxy-Container erforderlich, um die Konfigurationsdateien von nginx zu generieren und andere Container mit einer bestimmten Umgebungsvariable zu erkennen.
Die
• Docker-Neustartrichtlinie ist auf always eingestellt . Weitere Optionen sind on-failure und unless-stopped . In diesem Fall schien immer angemessener.
• Die Ports 80 und 443 sind an den Host für http bzw. https gebunden.
• Schließlich verwendet es ein anderes Netzwerk, nicht das Standard-Bridge-Netzwerk.

Die Verwendung eines benutzerdefinierten Netzwerks ist sehr wichtig. Dies hilft beim Isolieren aller Container, die weitergeleitet werden sollen, zusammen mit dem Aktivieren des Reverse-Proxy-Containers, um die Clients an ihre gewünschten/beabsichtigten Container weiterzuleiten und die Container miteinander kommunizieren zu lassen (was mit dem Standard-Bridge-Netzwerk nicht möglich ist außer icc auf true gesetzt ist für den Dämon).

Denken Sie daran, dass YML in Bezug auf Tabulatoren und Einrückungen sehr wählerisch ist.

Schritt 2:Richten Sie einen Container für die automatische Generierung von SSL-Zertifikaten ein

Dazu können Sie das Container-Image jrcs/letsencrypt-nginx-proxy-companion verwenden.

Auf derselben docker-compose.yml Datei, die Sie zuvor verwendet haben, fügen Sie die folgenden Zeilen hinzu:

    letsencrypt:
        image: "jrcs/letsencrypt-nginx-proxy-companion:latest"
        container_name: "letsencrypt-helper"
        volumes:
            - "html:/usr/share/nginx/html"
            - "dhparam:/etc/nginx/dhparam"
            - "vhost:/etc/nginx/vhost.d"
            - "certs:/etc/nginx/certs"
            - "/run/docker.sock:/var/run/docker.sock:ro"
        environment:
            NGINX_PROXY_CONTAINER: "reverse-proxy"
            DEFAULT_EMAIL: "[email protected]"
        restart: "always"
        depends_on:
            - "reverse-proxy"
        networks: 
            - "net"

In dieser Dienstdefinition:

• Sie verwenden exakt die gleichen Volumes wie für den Reverse-Proxy-Container. Die html und vhost Die gemeinsame Nutzung von Volumes ist erforderlich, damit die ACME-Herausforderung von letsencrypt erfolgreich ist. Dieser Container generiert die Zertifikate in /etc/nginx/certs , im Behälter. Aus diesem Grund teilen Sie dieses Volume mit Ihrem Reverse-Proxy-Container. Der dhparam Volume enthält die dhparam-Datei. Der Socket wird gemountet, um andere Container mit einer bestimmten Umgebungsvariable zu erkennen.
• Hier haben Sie zwei Umgebungsvariablen definiert. Der NGINX_PROXY_CONTAINER Variable zeigt auf den Reverse-Proxy-Container. Setzen Sie ihn auf den Namen des Containers. Die DEFAULT_EMAIL ist die E-Mail-Adresse, die beim Generieren der Zertifikate für jede Domain/Subdomain verwendet wird.
• Der depends_on ab Die Option ist so eingestellt, dass dieser Dienst zuerst auf den Start des Reverse-Proxys wartet, dann und nur dann wird dieser gestartet.
• Schließlich nutzt dieser Container auch dasselbe Netzwerk. Dies ist notwendig, damit die beiden Container kommunizieren können.

Schritt 3:Finalisieren Sie die Docker-Compose-Datei

Sobald die Dienstdefinitionen abgeschlossen sind, vervollständigen Sie die docker-compose-Datei mit den folgenden Zeilen:

volumes:
  certs:
  html:
  vhost:
  dhparam:

networks:
  net:
    external: true

Das Netzwerk net auf extern gesetzt, da die Proxy-Container dieses Netzwerk ebenfalls verwenden müssen. Und wenn wir das Netzwerk verlassen, um von docker-comspose erstellt zu werden , hängt der Netzwerkname vom aktuellen Verzeichnis ab. Dadurch wird ein seltsam benanntes Netzwerk erstellt.

Abgesehen davon müssen andere Container dieses Netzwerk sowieso als extern festlegen, da sich diese Compose-Dateien sonst auch in demselben Verzeichnis befinden müssen, was nicht ideal ist.

Erstellen Sie daher das Netzwerk mit

 docker network create net

Das Folgende ist der gesamte Inhalt der docker-compose.yml Datei.

version: "3.7"

services:

    reverse-proxy:
        image: "jwilder/nginx-proxy:latest"
        container_name: "reverse-proxy"
        volumes:
            - "html:/usr/share/nginx/html"
            - "dhparam:/etc/nginx/dhparam"
            - "vhost:/etc/nginx/vhost.d"
            - "certs:/etc/nginx/certs"
            - "/run/docker.sock:/tmp/docker.sock:ro"
        restart: "always"
        networks: 
            - "net"
        ports:
            - "80:80"
            - "443:443"
    letsencrypt:
        image: "jrcs/letsencrypt-nginx-proxy-companion:latest"
        container_name: "letsencrypt-helper"
        volumes:
            - "html:/usr/share/nginx/html"
            - "dhparam:/etc/nginx/dhparam"
            - "vhost:/etc/nginx/vhost.d"
            - "certs:/etc/nginx/certs"
            - "/run/docker.sock:/var/run/docker.sock:ro"
        environment:
            NGINX_PROXY_CONTAINER: "reverse-proxy"
            DEFAULT_EMAIL: "[email protected]"
        restart: "always"
        depends_on:
            - "reverse-proxy"
        networks: 
            - "net"
volumes:
  certs:
  html:
  vhost:
  dhparam:

networks:
  net:
    external: true

Schließlich können Sie diese beiden Container (Ngnix und Let’s Encrypt) mit dem folgenden Befehl bereitstellen:

docker-compose up -d

Schritt 4:Überprüfen Sie, ob der Ngnix-Reverse-Proxy funktioniert

Der Container, der das Frontend bedient, muss zwei Umgebungsvariablen definieren.

VIRTUAL_HOST :zum Generieren der Reverse-Proxy-Konfiguration

LETSENCRYPT_HOST :zum Generieren der erforderlichen Zertifikate

Stellen Sie sicher, dass Sie die richtigen Werte für diese beiden Variablen haben. Sie können nginx-Dummy-Image mit Reverse-Proxy wie folgt ausführen:

docker run --rm --name nginx-dummy -e VIRTUAL_HOST=sub.domain.com -e LETSENCRYPT_HOST=sub.domain.com -e VIRTUAL_PORT=80 --network net -d nginx:latest

Wenn Sie nun zu Ihrer Subdomain gehen, die im vorherigen Befehl verwendet wurde, sollten Sie eine Nachricht vom Ngnix-Server sehen.

Wenn Sie es erfolgreich getestet haben, können Sie den laufenden Docker-Container stoppen:

docker stop nginx-dummy

Sie können den Ngnix-Reverse-Proxy auch stoppen, wenn Sie ihn nicht verwenden:

docker-compose down

Schritt 5:Andere Dienstcontainer mit Reverse-Proxy ausführen

Der Prozess, andere Container so einzurichten, dass sie als Proxys verwendet werden können, ist SEHR einfach.

Ich werde es gleich mit zwei Instanzen der Nextcloud-Bereitstellung zeigen. Lassen Sie mich Ihnen zuerst sagen, was Sie hier tun.

An keinen Port binden

Der Container kann den Port weglassen, der das Frontend bedient. Der Reverse-Proxy-Container erkennt das automatisch.

(OPTIONAL) VIRTUAL_PORT definieren

Wenn der Reverse-Proxy-Container den Port nicht erkennt, können Sie eine andere Umgebungsvariable mit dem Namen VIRTUAL_PORT definieren mit dem Port, der das Frontend bedient oder welchen Dienst Sie per Proxy erhalten möchten, wie "80" oder "7765".

Let's Encrypt-E-Mail spezifisch für einen Container festlegen

Sie können DEFAULT_EMAIL überschreiben -Variable und legen Sie eine bestimmte E-Mail-Adresse für die Domänen-/Unterdomänenzertifikate eines bestimmten Containers/Webdienstes fest, indem Sie die E-Mail-ID auf die Umgebungsvariable LETSENCRYPT_EMAIL festlegen . Dies funktioniert pro Container.

Jetzt, da Sie all diese Dinge kennen, möchte ich Ihnen den Befehl zeigen, der eine Nextcloud-Instanz bereitstellt, die über den nginx-Proxy-Container weitergeleitet wird und für die TLS (SSL/HTTPS) aktiviert ist.

Dies ist KEINE IDEALE Bereitstellung. Der folgende Befehl wird nur zu Demonstrationszwecken verwendet.

docker run --name nextcloud --network net -e VIRTUAL_HOST="sub0.domain.com" -e LETSENCRYPT_HOST="sub0.domain.com" -d nextcloud:19.0.2

Im Beispiel haben Sie dasselbe Netzwerk wie die Reverse-Proxy-Container verwendet und die beiden Umgebungsvariablen mit den entsprechenden Subdomains definiert (stellen Sie Ihre entsprechend ein). Nach ein paar Minuten sollte Nextcloud auf sub0.domain.com laufen. Öffnen Sie es zur Überprüfung in einem Browser.

Sie können eine weitere Nextcloud-Instanz wie diese auf einer anderen Subdomain bereitstellen, wie folgt:

docker run --name anothernextcloud --network net -e VIRTUAL_HOST="sub1.domain.com" -e LETSENCRYPT_HOST="sub1.domain.com" -d nextcloud:19.0.2

Jetzt sollten Sie eine andere Nextcloud-Instanz sehen, die auf einer anderen Subdomain auf demselben Server läuft.

Mit dieser Methode können Sie verschiedene Web-Apps auf demselben Server bereitstellen, der unter verschiedenen Subdomains bereitgestellt wird, was ziemlich praktisch ist.

Mitmachen

Nachdem Sie diese Einrichtung nun vorgenommen haben, können Sie fortfahren und dies in tatsächlichen Bereitstellungen mit den folgenden Beispielen verwenden:

• Matrix Synapse Homeserver mit Docker installieren
• Installieren Sie mehrere Discourse-Container auf demselben Server

Für weitere Artikel dieser Art abonnieren Sie unseren Newsletter oder werden Sie Mitglied. Zögern Sie nicht, bei Fragen unten einen Kommentar abzugeben.