Erstellen eines Docker-Images von NGINX Plus mit NGINX Agent für Kubernetes

NGINX | 18. April 2023

F5 NGINX Management Suite ist eine Familie von Modulen zur zentralen Verwaltung der NGINX-Datenebene. Durch die vereinfachte Verwaltung von Instanzen von NGINX Open Source und NGINX Plus erleichtert NGINX Management Suite Ihre Prozesse zur Skalierung, Absicherung und Überwachung von Anwendungen und APIs.

Sie müssen den NGINX Agent auf jeder NGINX-Instanz installieren, die Sie über die NGINX Management Suite verwalten möchten, um die Kommunikation mit der Steuerungsebene und die Remote-Konfigurationsverwaltung zu ermöglichen.

Für NGINX-Instanzen, die auf Bare Metal oder einer virtuellen Maschine (VM) ausgeführt werden, stellen wir in unserer Dokumentation Installationsanweisungen bereit. In diesem Beitrag zeigen wir, wie Sie ein Docker-Image für NGINX Plus und NGINX Agent erstellen, um die Reichweite der NGINX Management Suite auf NGINX Plus-Instanzen auszuweiten, die in Kubernetes oder anderen Microservices-Infrastrukturen bereitgestellt werden.

Je nachdem, was Sie in das resultierende Docker-Image aufnehmen möchten, stehen drei Build-Optionen zur Verfügung:

[Redaktion – Dieser Beitrag wurde im April 2023 aktualisiert, um die Anweisungen zu präzisieren und ACM_DEVPORTAL als Feld in Schritt 1 unter „Ausführen des Docker-Images in Kubernetes“ hinzuzufügen.]

Voraussetzungen

Wir stellen ein GitHub-Repository mit den Ressourcen bereit, die Sie benötigen, um ein Docker-Image von NGINX Plus und NGINX Agent zu erstellen, das Version 2.8.0 und höher des Instance Manager-Moduls der NGINX Management Suite unterstützt.

Zum Erstellen des Docker-Images benötigen Sie:

  • Ein Linux-Host (Bare Metal oder VM)
  • Docker 20.10+
  • Eine private Registry, in die Sie das Ziel-Docker-Image pushen können
  • Eine aktive NGINX Management Suite-Instanz mit Instance Manager sowie API Connectivity Manager, wenn Sie die Unterstützung für das Entwicklerportal nutzen möchten
  • Ein Abonnement (oder eine kostenlose 30-Tage-Testversion) für NGINX Plus und optional NGINX App Protect

Zum Ausführen des Docker-Images benötigen Sie:

  • Ein laufender Kubernetes-Cluster
  • kubectl mit Zugriff auf den Kubernetes-Cluster

Erstellen des Docker-Images

Befolgen Sie diese Anweisungen, um das Docker-Image zu erstellen.

  1. Klonen Sie das GitHub-Repository:
$ git clone https://github.com/nginxinc/NGINX-Demos Cloning into 'NGINX-Demos'... 
remote: Enumerating objects: 126, done. 
remote: Counting objects: 100% (126/126), done. 
remote: Compressing objects: 100% (85/85), done. 
remote: Total 126 (delta 61), reused 102 (delta 37), pack-reused 0 
Receiving objects: 100% (126/126), 20.44 KiB | 1.02 MiB/s, done. 
Resolving deltas: 100% (61/61), done.
  1. Wechseln Sie in das Build-Verzeichnis:
$ cd NGINX-Demos/nginx-agent-docker/
  1. Führen Sie docker ps aus, um zu überprüfen, ob Docker ausgeführt wird. Führen Sie anschließend das Skript build.sh aus, um die gewünschte Software in das Docker-Image aufzunehmen. Die grundlegenden Optionen sind: Die zusätzlichen Optionen sind: Hier finden Sie die Befehle für die verschiedenen Softwarekombinationen: Hier sehen Sie eine Beispielausgabe des Build-Vorgangs für ein Basis-Image. Die Meldung Build complete am Ende zeigt an, dass der Build erfolgreich war.
$ ./scripts/build.sh -C nginx-repo.crt -K nginx-repo.key -t registry.ff.lan:31005/nginx-plus-with-agent:2.7.0 -n https://nim.f5.ff.lan => Target docker image is nginx-plus-with-agent:2.7.0 
[+] Building 415.1s (10/10) FINISHED 
=> [internal] load build definition from Dockerfile
=> transferring dockerfile: 38B
=> [internal] load .dockerignore 
=> transferring context: 2B 
=> [internal] load metadata for docker.io/library/centos:7
=> [auth] library/centos:pull token for registry-1.docker.io
=> CACHED [1/4] FROM docker.io/library /centos:7@sha256:be65f488b7764ad3638f236b7b515b3678369a5124c47b8d32916d6487418ea4
=> [internal] load build context 
=> transferring context: 69B 
=> [2/4] RUN yum -y update  && yum install -y wget ca-certificates epel-release curl  && mkdir -p /deployment /etc/ssl/nginx  && bash -c 'curl -k $NMS_URL/install/nginx-agent | sh' && echo "A  299.1s 
=> [3/4] COPY ./container/start.sh /deployment/
=> [4/4] RUN --mount=type=secret,id=nginx-crt,dst=/etc/ssl/nginx/nginx-repo.crt  --mount=type=secret,id=nginx-key,dst=/etc/ssl/nginx/nginx-repo.key  set -x  && chmod +x /deployment/start.sh &  102.4s  
=> exporting to image 
=> exporting layers 
=> writing image sha256:9246de4af659596a290b078e6443a19b8988ca77f36ab90af3b67c03d27068ff 
=> naming to registry.ff.lan:31005/nginx-plus-with-agent:2.7.0 
=> Build complete for registry.ff.lan:31005/nginx-plus-with-agent:2.7.0
  1. Docker-Image in Kubernetes ausführen Befolgen Sie diese Anweisungen, um das Deployment-Manifest vorzubereiten und NGINX Plus mit NGINX Agent auf Kubernetes zu starten. Erste Schritte Um die in diesem Beitrag vorgestellten NGINX-Lösungen auszuprobieren, starten Sie noch heute eine kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen: Laden Sie den NGINX Agent herunter – er ist kostenlos und Open Source.
    • ‑C – Name der NGINX Plus-Lizenzzertifikatsdatei (nginx-repo.crt in den folgenden Beispielbefehlen)
    • ‑K – Name der NGINX Plus-Lizenzschlüsseldatei (nginx-repo.key in den folgenden Beispielbefehlen)
    • ‑t – Die Registry und das Ziel-Image im Format <registry_name>/<image_name>:<tag> (registry.ff.lan:31005/nginx-plus-with-agent:2.7.0 in den folgenden Beispielbefehlen)
    • ‑n – Basis-URL Ihrer NGINX Management Suite-Instanz (https://nim.f5.ff.lan in den folgenden Beispielbefehlen)
    • ‑d – Unterstützung der Datenebene für das Entwicklerportal bei Verwendung von NGINX API Connectivity Manager hinzufügen
    • ‑w – NGINX App Protect WAF hinzufügen
    • NGINX Plus und NGINX Agent:
$ ./scripts/build.sh -C nginx-repo.crt -K nginx-repo.key \ -t registry.ff.lan:31005/nginx-plus-with-agent:2.7.0 \ -n https://nim.f5.ff.lan
  • NGINX Plus, NGINX Agent und NGINX App Protect WAF (fügen Sie die Option „‑w“ hinzu):
$ ./scripts/build.sh -C nginx-repo.crt -K nginx-repo.key \-t registry.ff.lan:31005/nginx-plus-with-agent:2.7.0 -w \ -n https://nim.f5.ff.lan
  • Unterstützung für NGINX Plus, NGINX Agent und das Entwicklerportal (fügen Sie die Option ‑d hinzu):
$ ./scripts/build.sh -C nginx-repo.crt -K nginx-repo.key \ -t registry.ff.lan:31005/nginx-plus-with-agent:2.7.0 -d \ -n https://nim.f5.ff.lan
  1. Öffnen Sie mit Ihrem bevorzugten Texteditor die Datei „manifests/1.nginx-with-agent.yaml“ und nehmen Sie die folgenden Änderungen vor (die Codeausschnitte zeigen die Standardwerte, die Sie ändern können oder müssen; sie sind orange hervorgehoben):
    • Ersetzen Sie im Abschnitt „spec.template.spec.containers“ den Standard-Image-Namen („your.registry.tld/nginx-with-nim2-agent:tag“) durch den Docker-Image-Namen, den Sie mit der Option „‑t“ in Schritt 3 unter „Erstellen des Docker-Images“ angegeben haben (in unserem Fall „registry.ff.lan:31005/nginx-plus-with-agent:2.7.0“):
spec:
  ...
  template:
    ...    
    spec:
      containers:
      - name: nginx-nim
        image: your.registry.tld/nginx-with-nim2-agent:tag
  • Nehmen Sie im Abschnitt spec.template.spec.containers.env für jeden angegebenen name die folgenden Ersetzungen im Feld value vor:
spec:
  ...
  template:
    ...    
  spec:
    containers:
      ...
      env:
        - name: NIM_HOST
        ...
          value: "nginx-nim2.nginx-nim2"
        - name: NIM_GRPC_PORT
          value: "443"
        - name: NIM_INSTANCEGROUP
          value: "lab"
        - name: NIM_TAGS
          value: "preprod,devops"
  • NIM_HOST – (Erforderlich) Ersetzen Sie den Standardwert (nginx-nim2.nginx-nim2) durch den FQDN oder die IP-Adresse Ihrer NGINX Management Suite-Instanz (in unserem Fall nim2.f5.ff.lan).
  • NIM_GRPC_PORT – (Optional) Ersetzen Sie den Standardport (443) durch eine andere Portnummer für den gRPC-Datenverkehr.
  • NIM_INSTANCEGROUP – (Optional) Ersetzen Sie den Standardwert (lab) durch die Instanzgruppe, zu der die NGINX Plus-Instanz gehört.
  • NIM_TAGS – (Optional) Ersetzen Sie den Standardwert (preprod,devops) durch eine kommagetrennte Liste von Tags für die NGINX Plus-Instanz.
  • Heben Sie außerdem im Abschnitt spec.template.spec.containers.env die Auskommentierung der folgenden name‑value-Feldpaare auf, wenn die angegebene Bedingung zutrifft:
spec:
  ...
  template:
    ...    
  spec:
    containers:
      ...
      env:
        - name: NIM_HOST
        ...
        #- name: NAP_WAF # value: "true" #- name: NAP_WAF_PRECOMPILED_POLICIES # value: "true"
        ...
        #- name: ACM_DEVPORTAL # value: "true"
  • NIM_WAF und NIM_WAF_PRECOMPILED_POLICIES – NGINX App Protect WAF ist im Image enthalten (Sie haben die Option -w in Schritt 3 unter „Erstellen des Docker-Images“ angegeben), daher lautet der Wert "true".
  • ACM_DEVPORTAL – Die Unterstützung für das Entwicklerportal von App Connectivity Manager ist im Image enthalten (Sie haben die Option -d in Schritt 3 unter „Erstellen des Docker-Images“ angegeben), daher lautet der Wert "true".
  1. Führen Sie das Skript nginxwithAgentStart.sh wie angegeben aus, um das Manifest anzuwenden und zwei Pods zu starten (wie durch die Anweisung replicas: 2 im Abschnitt spec des Manifests festgelegt), jeweils mit NGINX Plus und NGINX Agent:
$ ./scripts/nginxWithAgentStart.sh start$ ./scripts/nginxWithAgentStart.sh stop
  1. Überprüfen Sie, ob jetzt zwei Pods ausgeführt werden: Jeder Pod führt eine NGINX Plus-Instanz und einen NGINX Agent aus, um mit der Steuerungsebene der NGINX Management Suite zu kommunizieren.
$ kubectl get pods -n nim-test  NAME                        READY  STATUS   RESTARTS  AGE 
nginx-nim-7f77c8bdc9-hkkck  1/1    Running  0         1m 
nginx-nim-7f77c8bdc9-p2s94  1/1    Running  0         1m
  1. Rufen Sie die Benutzeroberfläche von NGINX Instance Manager in der NGINX Management Suite auf und überprüfen Sie, ob zwei NGINX Plus-Instanzen mit dem Status „Online“ ausgeführt werden. In diesem Beispiel ist NGINX App Protect WAF nicht aktiviert.
    Screenshot des Fensters „Instanzübersicht“ in NGINX Management Suite Instance Manager, Version 2.7.0


Teilen
Schlagwörter: F5 NGINX, Tech, 2023

Über den Autor

Ähnliche Blogbeiträge

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
NGINX | 23.08.2022

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln

Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
NGINX | 08.09.2021

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen

Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
NGINX | 16.08.2021

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet

Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
NGINX | 12.12.2018

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77

Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.

Ankündigung von NGINX Plus R16
NGINX | 05.09.2018

Ankündigung von NGINX Plus R16

NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
NGINX | 13.10.2016

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing

Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.