Module d'enregistrement unifié API

L'équipe de la communauté open source chinoise a réalisé sa première diffusion en direct, racontant l'histoire de la communauté open source chinoise au nom du partage.

NGINX évolue vers le cloud natif, tout dans OpenNJet

1.Demande

Configuration du plan de contrôle Avec l'augmentation des modules dynamiques, chaque module dynamique (l'API déclarative utilise /config) fournissait à l'origine une méthode de configuration d'emplacement. Avec de plus en plus d'éléments de configuration, il est nécessaire de fournir une entrée de module API unifiée, qui est contrôlée par chacun. module dynamique. Le module s'enregistre auprès du module API et, au moment de l'exécution, appelle le gestionnaire enregistré pour le traitement en fonction de la demande de fonction réelle.

2. Module API dynamique existant

2.1 Modules séparés API existants

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 Configuration du module dynamique existant (API déclarative et API impérative) :

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. Solution de module d'inscription unifiée

3.1 Entrée de configuration unifiée (en utilisant /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 Le module API fournit une interface d'enregistrement

•Le module API est compilé à l'aide de modules statiques et initialisé dans le processus d'assistance ctrl.

•api_module fournit une interface d'enregistrement similaire au module kv et enregistre la clé et le gestionnaire de chaque module.

• Chaque module enregistre le gestionnaire de chaque module selon /v{version}/{module_name} comme clé. La première version est la version 1. La clé d'enregistrement de chaque module API est la suivante :

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 Processus de l'étape de traitement du contenu du module API

• Lorsque la requête http arrive, la clé (/v{version}/{module_name}) est analysée en fonction de l'url : /api/v{version}/{module_name}/{other}

•Vérifiez s'il existe un gestionnaire enregistré basé sur la clé, sans renvoyer directement 404 s'il est trouvé, appelez le gestionnaire pour le traitement ;

4. Schéma api_limit_sauf

4.1 Introduction à la directive limit_sauf


Syntaxe:	Méthode limit_sauf…{…}
Défaut	-
Contexte:	emplacement

Limite les méthodes HTTP autorisées à l’intérieur d’un emplacement. Le paramètre de méthode peut être l'un des suivants : GET, HEAD, POST, PUT, DELETE, MKCOL, COPY, MOVE, OPTIONS, PROPFIND, PROPPATCH, LOCK, UNLOCK ou PATCH. Autoriser la méthode GET rend la méthode HEAD également autorisée. L'accès à d'autres méthodes peut être limité à l'aide des directives des modules ngx_http_access_module, ngx_http_auth_basic_module et ngx_http_auth_jwt_module (1.13.10) :

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

Veuillez noter que cela limitera l'accès à toutes les méthodes sauf GET et HEAD.

4.2 Schéma d'instructions api_limit_sauf

4.2.1 Exigences

Cible:

•Pour le module API, ajoutez la directive api_limit_sauf (plusieurs peuvent être configurées pour définir des restrictions pour différents modules API)

fonctionnalités limit_sauf :

•La directive limit_sauf peut contrôler les autorisations pour l'emplacement configuré. Chaque fonction d'emplacement est configurée avec un limit_sauf. Cette directive enregistrera un gestionnaire pour la vérification des autorisations dans la phase d'accès. Ce n'est qu'une fois la vérification réussie que la phase de traitement du contenu suivante peut être effectuée. .

•La directive limit_sauf générera également une structure d'emplacement noname en mémoire

Par conséquent, une nouvelle directive api_limit_sauf doit être implémentée pour atteindre deux objectifs :

• Plusieurs éléments peuvent être configurés, et un limit_sauf peut être configuré pour les URL de module avec différentes configurations.

• L'emplacement de l'API doit être capable de générer des structures d'emplacement prenant en charge plusieurs non-noms en mémoire en même temps, et être capable d'appeler le contrôle d'accès aux autorisations configuré limit_sauf correct en fonction de l'URL réelle lorsqu'il y a une requête http.

REMARQUES:

Si limit_sauf est configuré, une vérification double couche sera effectuée. Les règles sont les suivantes :

• La vérification limit_sauf est prioritaire

•limit_sauf Si une authentification est requise, utilisez l'authentification par mot de passe avec limit_sauf

•limit_sauf Si autorisé, il entrera dans la vérification des autorisations de la configuration api_limit_sauf

4.2.2 Introduction à la directive api_limit_sauf


Syntaxe:	Méthode api_limit_sauf module_key…{…}
Défaut	-
Contexte:	emplacement

Ajoutez un paramètre module_key pour limit_sauf. Ce paramètre est le format de préfixe d'URL de chaque module API : commençant par /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 Exemple de configuration

•Comment utiliser la commande 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. Testez

Les préfixes d'interface de toutes les API déclaratives et impératives sont unifiés

5.1 fichier de configuration ctrl

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

5.2 Test du module (la fonction reste inchangée, le seul changement est le changement d'URL de tous les modules api)

Le préfixe d'interface de toutes les API déclaratives et impératives est modifié pour commencer par /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 Certificat SSL dynamique :/api/v1/ssl

5.2.2 Bilan de santé : /api/v1/hc

5.2.3 Plage dynamique : /api/v1/range

5.2.4 Accélération du cache : /api/v1/cache

5.2.5 carré : /api/v1/sq

5.2.6 API de configuration : /api/v1/config

5.3 Test de vérification des autorisations api_limit_sauf

5.3.1 Exemple de génération d'un fichier de mot de passe de vérification :

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 Configuration (en prenant comme exemple les tests SSL et 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 Essai :

5.3.3.1 Test de vérification SSL

Pour SSL, la méthode GET ne vérifie pas, d'autres méthodes vérifient, donc appeler l'interface get ne vous permettra pas de saisir le mot de passe, appeler l'interface put vous permettra de saisir le mot de passe. Seul test2/test2 avec le mot de passe correct passera. .

5.3.3.1.1 Obtenir le test : renvoyer le résultat directement

5.3.3.1.2 Test PUT : vous devez saisir un mot de passe. Le résultat sera renvoyé une fois le mot de passe correct.

Entrez le mot de passe correct et entrez dans l'étape de traitement du contenu.

5.3.3.2 essai de vérification de la portée

Pour range, la méthode PUT ne vérifie pas, d'autres méthodes vérifient, donc l'appel de l'interface put ne permettra pas de saisir le mot de passe, l'appel de l'interface get nécessitera la saisie du mot de passe. Seul test/123456 avec le mot de passe correct réussira. .

5.3.3.2.1 Test GET : mot de passe requis

GET nécessite le mot de passe test/123456

Entrez le mot de passe correct et renvoyez le résultat

5.3.3.2.2 Test PUT : Pas besoin de saisir de mot de passe, passez directement à l'étape de traitement du contenu

Le moteur d'application NJet offre des capacités uniques de chargement de configuration dynamique d'exécution grâce à la reconstruction du noyau et constitue une nouvelle génération de moteur d'application Web hautes performances . NJet dispose de capacités de traitement de plan de données hautes performances et planifie plusieurs fonctions auxiliaires telles que le clustering, la haute disponibilité, les contrôles de santé actifs et les API déclaratives via le cadre de service copilote unique CoPilot de NJet pour faciliter l'expansion des fonctions et isoler les paires de fonctions de gestion/contrôle dues. Compte tenu de l'impact sur le plan des données, les performances du moteur d'application NJet dépassent trois fois celles du moteur d'application Envoy recommandé par la CNCF. Site officiel du groupe de messagerie