API-einheitliches Registrierungsmodul

Das Open-Source-Community-Team China machte seine erste Live-Übertragung und erzählte im Namen des Teilens die Geschichte hinter der Open-Source-Community China.“

NGINX entwickelt sich zu Cloud Native weiter, alles in OpenNJet

1.Nachfrage

Konfiguration der Steuerungsebene Mit der Zunahme dynamischer Module stellte jedes dynamische Modul (deklarative API verwendet /config) ursprünglich eine Standortkonfigurationsmethode bereit. Bei immer mehr Konfigurationselementen ist es notwendig, einen einheitlichen API-Moduleingang bereitzustellen, der von jedem gesteuert wird Dynamisches Modul registriert sich beim API-Modul und ruft zur Laufzeit den registrierten Handler zur Verarbeitung entsprechend der tatsächlichen Funktionsanforderung auf.

2. Vorhandenes dynamisches API-Modul

2.1 Bestehende API-separate Module

njet-config-api-module
njet-http-sendmsg-module
njet-http-cache-quick-module
njet-health-check-helper
njet-http-dyn-server-api-module
njet-http-location-api-module
njet-http-range-api-module
njet-http-ssl-api-module
njet-http-upstream-api-module

2.2 Vorhandene dynamische Modulkonfiguration (deklarative API und imperative API):

server {
        listen       8081;
        
         //声明式api入口
        location /config {
            config_api;
        }       

        location /hc {
            health_check_api;
        }

        //upstream api
        location /api {
             api write=on;
        }

        location /kv {
            dyn_sendmsg_kv;
        }

        location /ssl {
            dyn_ssl_api;
        }

        location /range {
            dyn_range_api;
        }

        location /cache {
            cache_quick_api;
        }

        location /dyn_loc {
           dyn_location_api;
        }

        location /dyn_srv {
           dyn_server_api;
        }
  }

3. Einheitliche Registrierungsmodullösung

3.1 Einheitlicher Konfigurationseingang (mit /api)


    server {
        listen       8081;
        
         #api 统一入口
        location /api {
            dyn_module_api;         #用于解析设置clcf->handler为统一入口handler
            
            #权限校验
            api_limit_except  /v1/dyn_loc {method};
            api_limit_except  /v1/range {method};
        }
        
        location /doc {
            doc_api;
        }
    }

3.2 Das API-Modul bietet eine Registrierungsschnittstelle

•Das API-Modul wird mit statischen Modulen kompiliert und im Strg-Hilfsprozess initialisiert

•api_module stellt eine Registrierungsschnittstelle ähnlich dem kv-Modul bereit und speichert den Schlüssel und Handler jedes Moduls.

• Jedes Modul registriert den Handler jedes Moduls gemäß /v{version}/{module_name} als Schlüssel. Die erste Version ist Version 1. Der Registrierungsschlüssel jedes API-Moduls lautet wie folgt:

njet-config-api-module
    /v1/config

njet-http-sendmsg-module
    /v1/kv

njet-http-cache-quick-module
    /v1/cache

njet-health-check-helper
    /v1/hc

njet-http-dyn-server-api-module
    /v1/dyn_srv

njet-http-location-api-module
    /v1/dyn_loc

njet-http-range-api-module
   /v1/range

njet-http-ssl-api-module
   /v1/ssl

njet-http-upstream-api-module
   /v1/upstream_api

3.3 Prozess der Inhaltsverarbeitungsphase des API-Moduls

• Wenn die http-Anfrage eintrifft, wird der Schlüssel (/v{version}/{module_name}) gemäß der URL analysiert: /api/v{version}/{module_name}/{other}

•Überprüfen Sie anhand des Schlüssels, ob ein registrierter Handler vorhanden ist, ohne 404 direkt zurückzugeben. Wenn er gefunden wird, rufen Sie den Handler zur Verarbeitung auf

4. api_limit_exclusive-Schema

4.1 Einführung in die limit_exclusive-Direktive


Syntax:	limit_exclusive-Methode…{…}
Standard	-
Kontext:	Standort

Beschränkt zulässige HTTP-Methoden innerhalb eines Standorts. Der Methodenparameter kann einer der folgenden sein: GET, HEAD, POST, PUT, DELETE, MKCOL, COPY, MOVE, OPTIONS, PROPFIND, PROPPATCH, LOCK, UNLOCK oder PATCH. Durch das Zulassen der GET-Methode wird auch die HEAD-Methode zugelassen. Der Zugriff auf andere Methoden kann mithilfe der Moduldirektiven ngx_http_access_module, ngx_http_auth_basic_module und ngx_http_auth_jwt_module (1.13.10) eingeschränkt werden:

limit_except GET {
    allow 192.168.1.0/32;
    deny  all;
}

Bitte beachten Sie, dass dadurch der Zugriff auf alle Methoden außer GET und HEAD eingeschränkt wird.

4.2 api_limit_exclusive-Anweisungsschema

4.2.1 Anforderungen

Ziel:

•Fügen Sie für das API-Modul die Direktive api_limit_exclusive hinzu (mehrere können konfiguriert werden, um Einschränkungen für verschiedene API-Module festzulegen).

limit_exclusive-Funktionen:

•Die limit_exclusive-Direktive kann Berechtigungen für den konfigurierten Standort steuern. Jede Standortfunktion wird mit einer limit_exclusive-Anweisung konfiguriert. Erst nachdem die Überprüfung bestanden wurde, kann die nachfolgende Inhaltsverarbeitungsphase durchgeführt werden .

•Die limit_exclusive-Direktive generiert auch eine Noname-Speicherortstruktur im Speicher

Daher muss eine neue api_limit_exclusive-Direktive implementiert werden, um zwei Ziele zu erreichen:

•Es können mehrere Elemente konfiguriert werden, und eine limit_exclusive kann für Modul-URLs mit unterschiedlichen Konfigurationen konfiguriert werden

•Der API-Standort muss in der Lage sein, Standortstrukturen zu generieren, die mehrere Nonames gleichzeitig im Speicher unterstützen, und in der Lage sein, die korrekte limit_exclusive konfigurierte Berechtigungszugriffskontrolle basierend auf der tatsächlichen URL aufzurufen, wenn eine http-Anfrage vorliegt.

ANMERKUNGEN:

Wenn limit_exclusive konfiguriert ist, wird eine zweischichtige Überprüfung durchgeführt. Die Regeln lauten wie folgt:

•limit_exclusive-Überprüfung hat Vorrang

•limit_exclusive Wenn eine Authentifizierung erforderlich ist, verwenden Sie die Passwortauthentifizierung mit limit_exclusive

•limit_exclusive Wenn zulässig, wird die Berechtigungsüberprüfung der api_limit_exclusive-Konfiguration eingegeben

4.2.2 Einführung in die api_limit_exclusive-Direktive


Syntax:	api_limit_exclusive module_key-Methode…{…}
Standard	-
Kontext:	Standort

Fügen Sie einen module_key-Parameter für limit_exclusive hinzu. Dieser Parameter ist das URL-Präfixformat jedes API-Moduls: beginnend mit /api/v{version}/{module_name}

声明式api 模块前缀： /api/v1/config

kv模块： /api/v1/kv

cache加速：/api/v1/cache

健康检查： /api/v1/hc

动态VS: /api/v1/dyn_srv

动态location: /api/v1/dyn_loc

动态range: /api/v1/range

动态ssl: /api/v1/ssl

动态upstream： /api/v1/upstream_api

4.2.3 Konfigurationsbeispiel

•So verwenden Sie den Befehl htpasswd:

centos：
yum install -y httpd

ubuntu:
apt install -y apache2-utils

密码文件/root/bug/njet1.0/htpasswd 新增用户test 密码是123456
htpasswd -bc /root/bug/njet1.0/htpasswd test 123456

密码文件/root/bug/njet1.0/htpasswd_ssl 新增用户test2 密码是test2
htpasswd -bc /root/bug/njet1.0/htpasswd_ssl test2 test2

 server {
       listen       8081;
       
        #api 统一入口
       location /api {
           dyn_module_api;
           
           #dyn_loc 权限校验， 非GET请求需要校验
           api_limit_except  /v1/ssl GET {
              auth_basic "OpenNJet SSL API";
              auth_basic_user_file /root/bug/njet1.0/htpasswd_ssl;
           }
           
           #range 权限校验， 非PUT请求需要校验
           api_limit_except  /v1/range PUT {
              auth_basic "OpenNJet RANGE API";
              auth_basic_user_file /root/bug/njet1.0/htpasswd;
           }
           
           #其他url请求，不做权限校验
       }
       
       location /doc {
           doc_api;
       }

       location /metrics {
           vhost_traffic_status_display;
           vhost_traffic_status_display_format html;
       }

       location /adc {
           #return 200 "ok";
           content_by_lua_file scripts/http_register.lua;
       }
   }

5. Testen

Die Schnittstellenpräfixe aller deklarativen APIs und imperativen APIs sind vereinheitlicht

5.1 Strg-Konfigurationsdatei

server {
    listen       8081;
    #api 统一入口
    location /api {
        dyn_module_api;
    }
    
    location /doc {
        doc_api;
    }
}

5.2 Modultest (die Funktion bleibt unverändert, die einzige Änderung ist die URL-Änderung aller API-Module)

Das Schnittstellenpräfix aller deklarativen APIs und imperativen APIs wird geändert und beginnt mit /api/v{version}/{module_name}.

声明式api 模块前缀： /api/v1/config
kv模块： /api/v1/kv
cache加速：/api/v1/cache
健康检查： /api/v1/hc
动态VS: /api/v1/dyn_srv
动态location: /api/v1/dyn_loc
动态range: /api/v1/range
动态ssl: /api/v1/ssl
动态upstream|： /api/v1/upstream_api

5.2.1 Dynamisches SSL-Zertifikat:/api/v1/ssl

Bild

5.2.2 Gesundheitscheck: /api/v1/hc

Bild

5.2.3 Dynamikbereich: /api/v1/range

Bild

5.2.4 Cache-Beschleunigung: /api/v1/cache

Bild

5,2,5 sq: /api/v1/sq

Bild

5.2.6 Konfigurations-API: /api/v1/config

5.3 api_limit_exclusive Berechtigungsüberprüfungstest

5.3.1 Beispiel für die Generierung einer Verifizierungspasswortdatei:

centos：
yum install -y httpd

ubuntu:
apt install -y apache2-utils

密码文件/root/bug/njet1.0/htpasswd 新增用户test 密码是123456
htpasswd -bc /root/bug/njet1.0/htpasswd test 123456

密码文件/root/bug/njet1.0/htpasswd_ssl 新增用户test2 密码是test2
htpasswd -bc /root/bug/njet1.0/htpasswd_ssl test2 test2

5.3.2 Konfiguration (am Beispiel des Testens von SSL und Range):

server {
        listen       8081;

        location /api {
            dyn_module_api;

            #针对 ssl 添加校验，用户名密码使用test2/test2
            api_limit_except  /v1/ssl GET {
               auth_basic "OpenNJet API";
               auth_basic_user_file /root/bug/njet1.0/htpasswd_ssl;
            }

            #针对 range 添加校验，用户名密码使用test/123456
            api_limit_except  /v1/range PUT {
               auth_basic "OpenNJet API";
               auth_basic_user_file /root/bug/njet1.0/htpasswd;
            }
            
            #如果同时配置了limit_except, 则优先判断limit_except权限配置，
            #如果limit_except 不检查，则会进入到api_limit_except 权限配置检查
            #limit_except GET{
            #   auth_basic "OpenNJet API";
            #   auth_basic_user_file /root/bug/njet1.0/htpasswd;
            #}
        }
   }

5.3.3 Test:

5.3.3.1 SSL-Verifizierungstest

Bei SSL führt die GET-Methode keine Überprüfung durch, andere Methoden überprüfen dies, sodass Sie beim Aufrufen der get-Schnittstelle das Kennwort nicht eingeben können. Beim Aufrufen der put-Schnittstelle können Sie nur test2/test2 mit dem richtigen Kennwort eingeben .

5.3.3.1.1 Test abrufen: Das Ergebnis direkt zurückgeben

Bild

5.3.3.1.2 PUT-Test: Sie müssen ein Passwort eingeben. Das Ergebnis wird zurückgegeben, nachdem das Passwort korrekt ist.

Geben Sie das richtige Passwort ein und gelangen Sie zur Inhaltsverarbeitungsphase.

5.3.3.2 Bereichsüberprüfungstest

Für den Bereich führt die PUT-Methode keine Überprüfung durch, andere Methoden überprüfen dies, sodass beim Aufruf der Put-Schnittstelle die Eingabe des Kennworts nicht möglich ist. Beim Aufruf der Get-Schnittstelle ist die Eingabe des Kennworts erforderlich. Nur test/123456 mit dem richtigen Kennwort wird bestanden .

5.3.3.2.1 GET-Test: Passwort erforderlich

GET erfordert das Passwort test/123456

Bild

Geben Sie das richtige Passwort ein und geben Sie das Ergebnis zurück

Bild

5.3.3.2.2 PUT-Test: Sie müssen kein Passwort eingeben, sondern gelangen direkt zur Inhaltsverarbeitungsphase

Bild

Die NJet -Anwendungs-Engine erreicht durch Kernel-Rekonstruktion einzigartige Funktionen zum dynamischen Laden von Konfigurationen zur Laufzeit und ist eine neue Generation leistungsstarker Web-Anwendungs-Engines . NJet verfügt über leistungsstarke Datenebenenverarbeitungsfunktionen und plant mehrere Hilfsfunktionen wie Clustering, Hochverfügbarkeit, aktive Zustandsprüfungen und deklarative APIs über das einzigartige Co-Pilot-Service-Framework von NJet, um Funktionserweiterungen zu erleichtern und fällige Verwaltungs-/Kontrollfunktionspaare zu isolieren Aufgrund der Auswirkungen auf die Datenebene ist die Leistung der NJet-Anwendungs-Engine dreimal so hoch wie die der von CNCF empfohlenen Envoy-Anwendungs-Engine. Offizielle Website der Mail-Gruppe