Bereitstellen von NGINX als API-Gateway, Teil 3: Veröffentlichen von gRPC-Diensten

Dies ist der dritte Blogbeitrag unserer Reihe zur Bereitstellung von NGINX Open Source und NGINX Plus als API-Gateway.

• Teil 1 bietet detaillierte Anweisungen für mehrere Anwendungsfälle von NGINX Open Source und NGINX Plus als API-Gateway für RESTful, HTTP-basierte APIs.
• Teil 2 erweitert diese Anwendungsfälle und befasst sich mit einer Reihe von Sicherheitsvorkehrungen, die zum Schutz und zur Sicherung von Back-End-API-Diensten in der Produktion angewendet werden können.
• In diesem Beitrag wird erklärt, wie NGINX Open Source und NGINX Plus als API-Gateway für gRPC-Dienste bereitgestellt werden. Der ursprünglich im Jahr 2018 veröffentlichte Beitrag wurde aktualisiert, um die in NGINX Plus Release 23 für das native gRPC-Integritätsprüfungsprotokoll. Siehe Implementieren von Integritätsprüfungen .

Notiz: Sofern nicht anders angegeben, gelten alle Informationen in diesem Beitrag sowohl für NGINX Plus als auch für NGINX Open Source. Der besseren Lesbarkeit halber wird im Rest des Blogs lediglich von „NGINX“ gesprochen, wenn die Diskussion beide Versionen betrifft.

Die Konzepte und Vorteile von Microservices-Anwendungsarchitekturen wurden in den letzten Jahren ausführlich dokumentiert, insbesondere im NGINX-Blog . Das Herzstück von Microservices-Anwendungen ist die HTTP-API, und die ersten beiden Blogbeiträge dieser Reihe verwenden eine hypothetische REST-API, um zu veranschaulichen, wie NGINX diesen Anwendungsstil angeht.

Trotz der Beliebtheit von REST-APIs mit JSON-Nachrichtenformaten für moderne Anwendungen handelt es sich nicht für jedes Szenario oder jede Organisation um einen idealen Ansatz. Die häufigsten Herausforderungen sind:

• Dokumentationsstandards – Ohne Disziplin der Entwickler oder vorgeschriebene Dokumentationsanforderungen kommt es allzu leicht vor, dass viele REST-APIs ohne genaue Definition dastehen. Die Open API Specification hat sich als generische Schnittstellenbeschreibungssprache für REST-APIs herauskristallisiert, ihre Verwendung ist jedoch optional und erfordert eine strenge Kontrolle innerhalb der Entwicklungsorganisation.
• Ereignisse und langlebige Verbindungen – REST-APIs und ihre Verwendung von HTTP als Transportmittel diktieren weitgehend ein Anforderungs-Antwort-Muster für alle API-Aufrufe. Wenn die Anwendung servergenerierte Ereignisse erfordert, kann die Verwendung von Lösungen wie HTTP Long Polling und WebSocket hilfreich sein. Der Einsatz solcher Lösungen erfordert jedoch letztendlich die Erstellung einer separaten, angrenzenden API.
• Komplexe Transaktionen – REST-APIs basieren auf dem Konzept eindeutiger Ressourcen, die jeweils durch eine URI dargestellt werden. Wenn ein Anwendungsereignis die Aktualisierung mehrerer Ressourcen erfordert, sind entweder mehrere API-Aufrufe erforderlich, was ineffizient ist, oder es muss eine komplexe Transaktion im Backend implementiert werden, was dem Kernprinzip von REST widerspricht.

In den letzten Jahren hat sich gRPC als alternativer Ansatz zum Erstellen verteilter Anwendungen und insbesondere von Microservices-Anwendungen herauskristallisiert. gRPC wurde ursprünglich bei Google entwickelt, wurde 2015 als Open Source freigegeben und ist jetzt ein Projekt der Cloud Native Computing Foundation. Bezeichnend ist, dass gRPC HTTP/2 als Transportmechanismus verwendet und dessen binäres Datenformat und Multiplex-Streaming-Funktionen nutzt.

Die wichtigsten Vorteile von gRPC sind:

• Eng gekoppelte Schnittstellendefinitionssprache ( Protokollpuffer )
• Native Unterstützung für Streamingdaten (in beide Richtungen)
• Effizientes binäres Datenformat
• Automatisierte Codegenerierung für viele Programmiersprachen, die eine wirklich polyglotte Entwicklungsumgebung ermöglicht, ohne Interoperabilitätsprobleme einzuführen

Definieren des gRPC-Gateways

In den ersten beiden Beiträgen dieser Reihe wurde beschrieben, wie mehrere APIs über einen einzigen Einstiegspunkt bereitgestellt werden können (z. B. https://api.example.com ). Das Standardverhalten und die Eigenschaften des gRPC-Verkehrs veranlassen uns, denselben Ansatz zu verfolgen, wenn NGINX als gRPC-Gateway bereitgestellt wird. Obwohl es möglich ist, sowohl HTTP- als auch gRPC-Verkehr über denselben Hostnamen und Port zu teilen, gibt es eine Reihe von Gründen, warum eine Trennung vorzuziehen ist:

• API-Clients für REST- und gRPC-Anwendungen erwarten Fehlerantworten in unterschiedlichen Formaten
• Die relevanten Felder für Zugriffsprotokolle variieren zwischen REST und gRPC
• Da gRPC nie mit älteren Webbrowsern arbeitet, kann es eine strengere TLS-Richtlinie haben

Um diese Trennung zu erreichen, platzieren wir die Konfiguration für unser gRPC-Gateway in einem eigenen Server{}- Block in der Hauptkonfigurationsdatei von gRPC, grpc_gateway.conf , die sich im Verzeichnis /etc/nginx/conf.d befindet.

Wir beginnen mit der Definition des Formats der Einträge im Zugriffsprotokoll für gRPC-Verkehr (Zeilen 1–4). In diesem Beispiel verwenden wir ein JSON-Format, um die relevantesten Daten aus jeder Anfrage zu erfassen. Beachten Sie beispielsweise, dass die HTTP-Methode nicht enthalten ist, da alle gRPC-Anfragen POST verwenden. Wir protokollieren außerdem den gRPC-Statuscode zusammen mit dem HTTP-Statuscode. Der gRPC-Statuscode kann jedoch auf unterschiedliche Weise generiert werden. Unter normalen Bedingungen wird grpc-status als HTTP/2-Trailer vom Backend zurückgegeben, unter bestimmten Fehlerbedingungen kann es jedoch als HTTP/2-Header zurückgegeben werden, entweder vom Backend oder von NGINX selbst. Um das Zugriffsprotokoll zu vereinfachen, verwenden wir einen Map- Block (Zeilen 6–9), um eine neue Variable $grpc_status auszuwerten und den gRPC-Status von seinem Ursprungsort abzurufen.

Diese Konfiguration enthält zwei Listen- Direktiven (Zeilen 12 und 13), sodass wir sowohl Klartext- (Port 50051) als auch TLS-geschützten (Port 443) Datenverkehr testen können. Der Parameter http2 konfiguriert NGINX so, dass HTTP/2-Verbindungen akzeptiert werden. Beachten Sie, dass dies unabhängig vom Parameter ssl ist. Beachten Sie auch, dass Port 50051 der herkömmliche Klartext-Port für gRPC ist, aber nicht für den Einsatz in der Produktion geeignet ist.

Die TLS-Konfiguration ist konventionell, mit Ausnahme der ssl_protocols -Direktive (Zeile 23), die TLS 1.2 als schwächstes akzeptables Protokoll angibt. Die HTTP/2-Spezifikation schreibt die Verwendung von TLS 1.2 (oder höher) vor . Dadurch wird garantiert, dass alle Clients die Server Name Indication (SNI)-Erweiterung für TLS unterstützen. Dies bedeutet, dass das gRPC-Gateway Port 443 mit virtuellen Servern teilen kann, die in anderen Server{}- Blöcken definiert sind.

Ausführen von Beispiel-gRPC-Diensten

Um die gRPC-Funktionen von NGINX zu erkunden, verwenden wir eine einfache Testumgebung, die die Schlüsselkomponenten eines gRPC-Gateways mit mehreren bereitgestellten gRPC-Diensten darstellt. Wir verwenden zwei Beispielanwendungen aus den offiziellen gRPC-Anleitungen : „Helloworld “ (geschrieben in Go) und „RouteGuide“ (geschrieben in Python). Die RouteGuide-Anwendung ist besonders nützlich, da sie jede der vier gRPC-Dienstmethoden enthält:

• Einfaches RPC (Einzelne Anfrage‑Antwort)
• Antwort‑Streaming‑RPC
• Anforderungsstreaming-RPC
• Bidirektionales Streaming RPC

Beide gRPC-Dienste sind als Docker-Container auf unserem NGINX-Host installiert. Vollständige Anweisungen zum Erstellen der Testumgebung finden Sie im Anhang .

Wir konfigurieren NGINX so, dass es die Dienste RouteGuide und HelloWorld sowie die Adressen der verfügbaren Container kennt.

Wir fügen für jeden der gRPC-Dienste einen Upstream- Block hinzu (Zeilen 40–45 und 47–51) und füllen sie mit den Adressen der einzelnen Container, die den gRPC-Servercode ausführen.

Weiterleiten von gRPC-Anfragen

Da NGINX auf dem herkömmlichen Klartext-Port für gRPC (50051) lauscht, fügen wir der Konfiguration Routing-Informationen hinzu, damit Client-Anfragen den richtigen Backend-Dienst erreichen. Aber zuerst müssen wir verstehen, wie gRPC-Methodenaufrufe als HTTP/2-Anfragen dargestellt werden. Das folgende Diagramm zeigt eine gekürzte Version der Datei route_guide.proto für den RouteGuide-Dienst und veranschaulicht, wie Paket, Dienst und RPC-Methode aus der Sicht von NGINX die URI bilden.

Die in der HTTP/2-Anfrage enthaltenen Informationen können daher für Routing-Zwecke verwendet werden, indem einfach der Paketname (hier „routeguide“ oder „helloworld “) abgeglichen wird.

Der erste Standortblock (Zeile 26) definiert ohne Modifikatoren eine Präfixübereinstimmung, sodass /routeguide mit allen Diensten und RPC-Methoden übereinstimmt, die in der entsprechenden .proto- Datei für dieses Paket definiert sind. Die Direktive grpc_pass (Zeile 27) übergibt daher alle Anfragen des RouteGuide-Clients an die Upstream-Gruppe routeguide_service . Diese Konfiguration (und die parallele Konfiguration für den „Hello World“-Dienst in den Zeilen 29 und 30) bietet eine einfache Zuordnung zwischen einem gRPC-Paket und seinen Backend-Diensten.

Beachten Sie, dass das Argument der grpc_pass- Direktiven mit dem Schema grpc:// beginnt, das Anforderungen über eine gRPC-Verbindung im Klartext weiterleitet. Wenn das Backend für TLS konfiguriert ist, können wir das Schema grpcs:// verwenden, um die gRPC-Verbindung mit Ende-zu-Ende-Verschlüsselung zu sichern.

Nachdem wir den RouteGuide-Client ausgeführt haben, können wir das Routing-Verhalten durch Überprüfung der Protokolldateieinträge bestätigen. Hier sehen wir, dass die RouteChat-RPC-Methode an den Container weitergeleitet wurde, der auf Port 10002 läuft.

$ python route_guide_client.py ... $ tail -1 /var/log/nginx/grpc_log.json | jq { "Zeitstempel": "2021-01-20T12:17:56+01:00", "Kunde": "127.0.0.1", "uri": "/routeguide.RouteGuide/RouteChat", "http-status": 200, „grpc-Status“: 0, "Upstream": "127.0.0.1:10002", "rx-bytes": 161, "tx-Bytes": 212 }

Präzises Routing

Wie oben gezeigt, ist das Routing mehrerer gRPC-Dienste zu verschiedenen Backends einfach, effizient und erfordert nur sehr wenige Konfigurationszeilen. Allerdings können die Routing-Anforderungen in einer Produktionsumgebung komplexer sein und ein Routing basierend auf anderen Elementen in der URI erfordern (dem gRPC-Dienst oder sogar einzelnen RPC-Methoden).

Der folgende Konfigurationsausschnitt erweitert das vorherige Beispiel so, dass die bidirektionale Streaming-RPC-Methode RouteChat an ein Backend und alle anderen RouteGuide- Methoden an ein anderes Backend weitergeleitet werden.

Die zweite Standortdirektive (Zeile 7) verwendet den Modifikator = (Gleichheitszeichen), um anzuzeigen, dass dies eine exakte Übereinstimmung mit der URI für die RouteChat- RPC-Methode ist. Genaue Übereinstimmungen werden vor Präfixübereinstimmungen verarbeitet. Dies bedeutet, dass für die RouteChat- URI keine anderen Standortblöcke berücksichtigt werden.

Auf Fehler reagieren

gRPC-Fehler unterscheiden sich etwas von denen für herkömmlichen HTTP-Verkehr. Clients erwarten, dass Fehlerbedingungen als gRPC-Antworten ausgedrückt werden, weshalb der Standardsatz an NGINX-Fehlerseiten (im HTML-Format) ungeeignet ist, wenn NGINX als gRPC-Gateway konfiguriert ist. Wir beheben dies, indem wir eine Reihe benutzerdefinierter Fehlerantworten für gRPC-Clients angeben.

Der vollständige Satz der gRPC-Fehlerantworten ist eine relativ lange und weitgehend statische Konfiguration. Daher speichern wir sie in einer separaten Datei, errors.grpc_conf , und verwenden die Include -Direktive (Zeile 34), um auf sie zu verweisen. Im Gegensatz zu HTTP/REST-Clients wird von gRPC-Clientanwendungen nicht erwartet, dass sie eine große Bandbreite an HTTP-Statuscodes verarbeiten. In der gRPC-Dokumentation ist festgelegt, wie ein zwischengeschalteter Proxy wie beispielsweise NGINX HTTP-Fehlercodes in gRPC-Statuscodes umwandeln muss, damit die Clients stets eine passende Antwort erhalten. Wir verwenden die Direktive error_page , um diese Zuordnung durchzuführen.

Jeder der Standard-HTTP-Statuscodes wird mit dem Präfix @ an einen benannten Ort übergeben, sodass eine gRPC-kompatible Antwort generiert werden kann. Beispielsweise das HTTP404 Die Antwort wird intern zum Speicherort @grpc_unimplemented umgeleitet, der später in der Datei definiert wird:

Der benannte Speicherort @grpc_unimplemented ist nur für die interne NGINX-Verarbeitung verfügbar – Clients können ihn nicht direkt anfordern, da keine routingfähige URI vorhanden ist. An dieser Stelle erstellen wir eine gRPC-Antwort, indem wir die obligatorischen gRPC-Header ausfüllen und sie ohne Antworttext unter Verwendung des HTTP-Statuscodes senden.204 ( Kein Inhalt ).

Wir können den Befehl curl(1) verwenden, um einen schlecht funktionierenden gRPC-Client zu simulieren, der eine nicht vorhandene gRPC-Methode anfordert. Beachten Sie jedoch, dass curl im Allgemeinen nicht als gRPC-Testclient geeignet ist, da Protokollpuffer ein binäres Datenformat verwenden. Um gRPC auf der Befehlszeile zu testen, sollten Sie grpc_cli verwenden.

$ curl -i --http2 -H "Inhaltstyp: application/grpc" -H "TE: Trailer" -X POST https://grpc.example.com/does.Not/Exist HTTP/2 204 Server: nginx/1.19.5 Datum: Mittwoch, 20. Januar 2021, 15:03:41 GMT grpc-status: 12 grpc-Meldung: nicht implementiert

Die oben referenzierte Datei grpc_errors.conf enthält auch HTTP‑zu‑gRPC‑Statuscodezuordnungen für andere Fehlerantworten, die NGINX generieren könnte, wie etwa Timeouts und Client‑Zertifikatfehler.

Authentifizieren von Clients mit gRPC-Metadaten

gRPC- Metadaten ermöglichen Clients, neben RPC-Methodenaufrufen zusätzliche Informationen zu senden, ohne dass diese Daten Teil der Protokollpufferspezifikation ( .proto- Datei) sein müssen. Metadaten sind eine einfache Liste von Schlüssel-Wert-Paaren, wobei jedes Paar als separater HTTP/2-Header übertragen wird. Daher sind Metadaten für NGINX leicht zugänglich.

Von den vielen Anwendungsfällen für Metadaten ist die Client-Authentifizierung für ein gRPC-API-Gateway der häufigste. Der folgende Konfigurationsausschnitt zeigt, wie NGINX Plus gRPC-Metadaten zur Durchführung der JWT-Authentifizierung verwenden kann (JWT-Authentifizierung ist exklusiv für NGINX Plus). In diesem Beispiel wird das JWT in den Authentifizierungstoken- Metadaten gesendet.

Jeder HTTP-Anforderungsheader steht NGINX Plus als Variable mit dem Namen $http_ header zur Verfügung. Bindestriche ( - ) im Header-Namen werden im Variablennamen in Unterstriche ( _ ) umgewandelt, sodass das JWT als $http_auth_token (Zeile 2) verfügbar ist.

Wenn API-Schlüssel zur Authentifizierung verwendet werden, beispielsweise mit vorhandenen HTTP/REST-APIs, können diese auch in gRPC-Metadaten übertragen und von NGINX validiert werden. Eine Konfiguration für die API-Schlüsselauthentifizierung<.htmla> finden Sie in Teil 1 dieser Blogserie.

Implementieren von Integritätsprüfungen

Beim Lastenausgleich des Datenverkehrs auf mehrere Backends ist es wichtig, das Senden von Anfragen an Backends zu vermeiden, die ausgefallen oder anderweitig nicht verfügbar sind. Mit NGINX Plus können wir aktive Integritätsprüfungen verwenden, um proaktiv Out-of-Band-Anfragen an Backends zu senden und sie aus der Lastausgleichsrotation zu entfernen, wenn sie nicht wie erwartet auf Integritätsprüfungen reagieren. Auf diese Weise stellen wir sicher, dass Clientanfragen niemals ausgefallene Backends erreichen.

Der folgende Konfigurationsausschnitt aktiviert aktive Integritätsprüfungen für die gRPC-Dienste RouteGuide und helloworld. Um die relevante Konfiguration hervorzuheben, werden einige Anweisungen weggelassen, die in der in den vorherigen Abschnitten verwendeten Datei grpc_gateway.conf enthalten sind.

Für jede Route geben wir nun auch die Direktive health_check an (Zeilen 17 und 21). Wie durch das Argument type=grpc angegeben, verwendet NGINX Plus das gRPC-Integritätsprüfungsprotokoll, um eine Integritätsprüfung an jeden Server in der Upstream-Gruppe zu senden. Unsere einfachen gRPC-Dienste implementieren das gRPC-Integritätsprüfungsprotokoll jedoch nicht und daher erwarten wir, dass sie mit dem Statuscode „nicht implementiert“ ( grpc_status=12 ) antworten. Wenn dies der Fall ist, reicht dies als Hinweis darauf aus, dass wir mit einem aktiven gRPC-Dienst kommunizieren.

Mit dieser Konfiguration können wir alle Backend-Container herunterfahren, ohne dass es bei gRPC-Clients zu Verzögerungen oder Timeouts kommt. Aktive Integritätsprüfungen sind exklusiv für NGINX Plus verfügbar. Weitere Informationen zu gRPC-Integritätsprüfungen finden Sie in unserem Blog.

Anwenden von Ratenbegrenzungen und anderen API-Gateway-Steuerelementen

Die Beispielkonfiguration in grpc_gateway.conf ist mit einigen geringfügigen Änderungen für TLS für den Produktionseinsatz geeignet. Die Möglichkeit, gRPC-Anfragen basierend auf Paket, Dienst oder RPC-Methode weiterzuleiten, bedeutet, dass die vorhandene NGINX-Funktionalität auf genau dieselbe Weise auf gRPC-Verkehr angewendet werden kann wie für HTTP/REST-APIs oder auch für regulären Web-Verkehr. Der jeweilige Standortblock kann jeweils durch weitere Konfigurationen, wie etwa Ratenbegrenzung oder Bandbreitenkontrolle, erweitert werden.

Zusammenfassung

In diesem dritten und letzten Blogbeitrag unserer Reihe über die Bereitstellung von NGINX Open Source und NGINX Plus als API-Gateway haben wir uns auf gRPC als Cloud-native Technologie zum Erstellen von Microservices-Anwendungen konzentriert. Wir haben gezeigt, wie NGINX gRPC-Anwendungen ebenso effektiv bereitstellen kann wie HTTP/REST-APIs und wie beide API-Arten über NGINX als Mehrzweck-API-Gateway veröffentlicht werden können.

Anweisungen zum Einrichten der in diesem Blogbeitrag verwendeten Testumgebung finden Sie im Anhang unten. Sie können alle Dateien aus unserem GitHub Gist-Repository herunterladen.

Schauen Sie sich die anderen Blogbeiträge dieser Reihe an:

• Teil 1 erläutert, wie NGINX in einigen wichtigen Anwendungsfällen eines HTTP-basierten API-Gateways konfiguriert wird.
• Teil 2 untersucht fortgeschrittenere Anwendungsfälle zum Schutz von Backend-Diensten vor böswilligen oder sich schlecht verhaltenden Clients.

Um NGINX Plus als API-Gateway auszuprobieren, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen . Verwenden Sie während Ihrer Testphase den vollständigen Satz an Konfigurationsdateien aus unserem GitHub Gist-Repository .

Anhang: Einrichten der Testumgebung

Die folgenden Anweisungen installieren die Testumgebung auf einer virtuellen Maschine, sodass sie isoliert und wiederholbar ist. Es gibt jedoch keinen Grund, warum es nicht auf einem physischen „Bare-Metal“-Server installiert werden kann.

Um die Testumgebung zu vereinfachen, verwenden wir Docker-Container, um die gRPC-Dienste auszuführen. Dies bedeutet, dass wir für die Testumgebung nicht mehrere Hosts benötigen, sondern NGINX trotzdem mit einem Netzwerkaufruf Proxy-Verbindungen herstellen lassen können, wie in einer Produktionsumgebung.

Durch die Verwendung von Docker können wir außerdem mehrere Instanzen jedes gRPC-Dienstes auf einem anderen Port ausführen, ohne dass Codeänderungen erforderlich sind. Jeder gRPC-Dienst lauscht innerhalb des Containers auf Port 50051, der einem eindeutigen Localhost-Port auf der virtuellen Maschine zugeordnet ist. Dadurch wird wiederum Port 50051 freigegeben, sodass NGINX ihn als Abhörport verwenden kann. Wenn die Testclients daher über ihren vorkonfigurierten Port 50051 eine Verbindung herstellen, erreichen sie NGINX.

Installieren von NGINX Open Source oder NGINX Plus

1. Installieren Sie NGINX Open Source oder NGINX Plus gemäß den Anweisungen im NGINX Plus Admin Guide.

2. Kopieren Sie die folgenden Dateien aus dem GitHub Gist-Repository nach /etc/nginx/conf.d :

   • grpc_gateway.conf
   • Fehler.grpc_conf

   Notiz: Wenn Sie TLS nicht verwenden, kommentieren Sie die ssl_* -Direktiven in grpc_gateway.conf aus.

3. Starten Sie NGINX Open Source oder NGINX Plus.

   $ sudo nginx
   

Docker installieren

Führen Sie für Debian und Ubuntu Folgendes aus:

$ sudo apt-get installiere docker.io

Führen Sie für CentOS, RHEL und Oracle Linux Folgendes aus:

$ sudo yum installiere Docker

Installieren der RouteGuide-Servicecontainer

1. Erstellen Sie das Docker-Image für die RouteGuide-Container aus der folgenden Docker-Datei.

   Sie können das Dockerfile entweder vor dem Build in ein lokales Unterverzeichnis kopieren oder die URL des Gist für das Dockerfile als Argument für den Docker- Build -Befehl angeben:

   $ sudo docker build -t routeguide https://gist.githubusercontent.com/nginx-gists/87ed942d4ee9f7e7ebb2ccf757ed90be/raw/ce090f92f3bbcb5a94bbf8ded4d597cd47b43cbe/routeguide.Dockerfile
   

   Das Herunterladen und Erstellen des Images kann einige Minuten dauern. Das Erscheinen der Meldung „Erfolgreich erstellt“ und einer hexadezimalen Zeichenfolge (der Image-ID) signalisieren den Abschluss des Builds.

2. Bestätigen Sie, dass das Image erstellt wurde, indem Sie „Docker Images“ ausführen.

   $ sudo Docker-Bilder REPOSITORY-TAG BILD-ID ERSTELLT GRÖSSE Routeguide aktuell 63058a1cf8ca vor 1 Minute 1,31 GB Python aktuell 825141134528 vor 9 Tagen 923 MB
   

3. Starten Sie die RouteGuide-Container.

   $ sudo docker run --name rg1 -p 10001:50051 -d Routenführer $ sudo docker run --name rg2 -p 10002:50051 -d Routenführer $ sudo docker run --name rg3 -p 10003:50051 -d Routenführer
   

   Bei erfolgreicher Ausführung jedes Befehls wird eine lange hexadezimale Zeichenfolge angezeigt, die den laufenden Container darstellt.

4. Überprüfen Sie, ob alle drei Container aktiv sind, indem Sie docker ps ausführen. (Die Beispielausgabe ist zur leichteren Lesbarkeit auf mehrere Zeilen aufgeteilt.)

   $ sudo docker ps CONTAINER-ID BILD BEFEHL STATUS … d0cdaaeddf0f routeguide „python route_g …“  2 Sekunden lang … c04996ca3469 Routeguide „python route_g …“  9 Sekunden nach oben ...
   2170ddb62898 Routenführer „python route_g …“  Bis 1 Minute... ... HAFENNAMEN ... 0.0.0.0:10003->50051/tcp rg3 … 0.0.0.0:10002->50051/tcp rg2 ... 0.0.0.0:10001->50051/tcp rg1
   

   Die Spalte „PORTS“ in der Ausgabe zeigt, wie jeder der Container innerhalb des Containers dem Port 50051 einen anderen lokalen Port zugeordnet hat.

Installieren der HelloWorld-Servicecontainer

1. Erstellen Sie das Docker-Image für die HelloWorld-Container aus der folgenden Docker-Datei.

   Sie können das Dockerfile entweder vor dem Build in ein lokales Unterverzeichnis kopieren oder die URL des Gist für das Dockerfile als Argument für den Docker- Build -Befehl angeben:

   $ sudo docker build -t hallowelt https://gist.githubusercontent.com/nginx-gists/87ed942d4ee9f7e7ebb2ccf757ed90be/raw/ce090f92f3bbcb5a94bbf8ded4d597cd47b43cbe/hallowelt.Dockerfile
   

   Das Herunterladen und Erstellen des Images kann einige Minuten dauern. Das Erscheinen der Meldung „Erfolgreich erstellt“ und einer hexadezimalen Zeichenfolge (der Image-ID) signalisieren den Abschluss des Builds.

2. Bestätigen Sie, dass das Image erstellt wurde, indem Sie „Docker Images“ ausführen.

   $ sudo Docker-Bilder REPOSITORY-TAG BILD-ID ERSTELLT GRÖSSE Hallo Welt aktuell e5832dc0884a vor 10 Sekunden 926 MB Routeguide aktuell 170761fa3f03 vor 4 Minuten 1,31 GB Python aktuell 825141134528 vor 9 Tagen 923 MB Golang aktuell d0e7a411e3da vor 3 Wochen 794 MB
   

3. Starten Sie die HelloWorld-Container.

   $ sudo docker run --name hw1 -p 20001:50051 -d hallo Welt $ sudo docker run --name hw2 -p 20002:50051 -d hallo Welt
   

   Bei erfolgreicher Ausführung jedes Befehls wird eine lange hexadezimale Zeichenfolge angezeigt, die den laufenden Container darstellt.

4. Überprüfen Sie, ob die beiden „Hello World“-Container aktiv sind, indem Sie „docker ps“ ausführen.

   $ sudo docker ps CONTAINER-ID BILD BEFEHL STATUS ... e0d204ae860a hallo Welt „go run greeter …“  5 Sekunden nach oben ... 
   66f21d89be78 hallo Welt „geh und lauf, Begrüßer …“  9 Sekunden lang … d0cdaaeddf0f routeguide „python route_g …“  Bis 4 Minuten ... c04996ca3469 routeguide "python route_g ..."  Bis zu 4 Minuten... 
   2170ddb62898 Routenführer „python route_g …“  Bis zu 5 Minuten… … HAFENNAMEN ... 0.0.0.0:20002->50051/tcp hw2 ... 0.0.0.0:20001->50051/tcp hw1 ... 0.0.0.0:10003->50051/tcp rg3 … 0.0.0.0:10002->50051/tcp rg2 ... 0.0.0.0:10001->50051/tcp rg1
   

Installieren der gRPC-Clientanwendungen

1. Installieren Sie die erforderlichen Programmiersprachen. Einige davon sind möglicherweise bereits in der Testumgebung installiert.

   • Führen Sie für Ubuntu und Debian Folgendes aus:

     $ sudo apt-get installiere golang-go python3 python-pip git
     

   • Führen Sie für CentOS, RHEL und Oracle Linux Folgendes aus:

     $ sudo yum installiere Golang Python Python-Pip Git
     

   Beachten Sie, dass für Python-Pip das EPEL-Repository aktiviert sein muss (führen Sie bei Bedarf zuerst „sudo yum install epel-release“ aus).

2. Laden Sie die HelloWorld-Anwendung herunter:

   $ gehe zu google.golang.org/grpc
   

3. Laden Sie die RouteGuide-Anwendung herunter:

   $ git clone -b v1.14.1 https://github.com/grpc/grpc $ pip installiere grpcio-tools
   

Testen des Setups

1. Führen Sie den HelloWorld-Client aus:

   $ go run go/src/google.golang.org/grpc/examples/helloworld/greeter_client/main.go
   

2. Führen Sie den RouteGuide-Client aus:

   $ cd grpc/beispiele/python/route_guide $ python route_guide_client.py
   

3. Überprüfen Sie die NGINX-Protokolle, um zu bestätigen, dass die Testumgebung betriebsbereit ist:

   $ tail /var/log/nginx/grpc_log.json