API 통합 등록 모듈

NGINX, 클라우드 네이티브로 진화, All in  OpenNJet 


1.수요

제어 평면 구성 동적 모듈이 증가함에 따라 각 동적 모듈(선언적 API는 /config를 사용함)은 원래 위치 구성 방법을 제공했습니다. 구성 항목이 점점 더 많아지면서 각 동적 모듈에서 제어되는 통합 API 모듈 입구를 제공해야 합니다. 동적 모듈. 모듈은 api 모듈에 등록하고 런타임에 실제 함수 요청에 따라 처리하기 위해 등록된 핸들러를 호출합니다.

2. 기존 동적 API 모듈

2.1 기존 API 별도 모듈

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 기존 동적 모듈 구성(선언적 API 및 명령형 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. 통합 등록 모듈 솔루션

3.1 통합 구성 입구(/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 api 모듈은 등록 인터페이스를 제공합니다

•API 모듈은 정적 모듈을 사용하여 컴파일되고 ctrl 도우미 프로세스에서 초기화됩니다.

•api_module은 kv 모듈과 유사한 등록 인터페이스를 제공하며 각 모듈의 키와 핸들러를 저장합니다.

• 각 모듈은 /v{version}/{module_name}에 따라 각 모듈의 핸들러를 키로 등록합니다. 첫 번째 버전은 버전 1입니다. 각 API 모듈의 등록 키는 다음과 같습니다.

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 API 모듈 콘텐츠 처리 단계 프로세스

• http 요청이 오면 URL: /api/v{version}/{module_name}/{other}에 따라 키(/v{version}/{module_name})가 구문 분석됩니다.

• 키를 기반으로 등록된 핸들러가 있는지 확인하고, 발견되면 직접 404를 반환하지 않고 핸들러를 호출하여 처리합니다.

4. api_limit_Exception 구성표

4.1 한계_제외 지시어 소개

   
통사론: 한계_제외 방법…{…}
기본 -
문맥: 위치

위치 내에서 허용되는 HTTP 메서드를 제한합니다. 메소드 매개변수는 GET, HEAD, POST, PUT, DELETE, MKCOL, COPY, MOVE, OPTIONS, PROPFIND, PROPPATCH, LOCK, UNLOCK 또는 PATCH 중 하나일 수 있습니다. GET 메소드를 허용하면 HEAD 메소드도 허용됩니다. 다른 메소드에 대한 액세스는 ngx_http_access_module, ngx_http_auth_basic_module 및 ngx_http_auth_jwt_module(1.13.10) 모듈 지시문을 사용하여 제한할 수 있습니다.

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

이렇게 하면 GET 및 HEAD를 제외한 모든 메소드에 대한 액세스가 제한됩니다.

4.2 api_limit_Exception 명령어 체계

4.2.1 요구사항

표적:

•API 모듈의 경우 api_limit_Exception 지시문을 추가합니다(다양한 API 모듈에 대한 제한을 설정하도록 여러 개 구성 가능).

제한_제외 기능:

•limit_Exception 지시어는 구성된 위치에 대한 권한을 제어할 수 있습니다. 이 지시어는 액세스 단계에서 권한 확인을 위한 핸들러를 등록합니다. 이후의 콘텐츠 처리 단계를 수행할 수 있습니다. .

•limit_Exception 지시문은 메모리에 noname 위치 구조도 생성합니다.

따라서 두 가지 목표를 달성하려면 새로운 api_limit_Exception 지시문을 구현해야 합니다.

•여러 항목을 구성할 수 있으며, 구성이 다른 모듈 URL에 대해 제한_제외를 구성할 수 있습니다.

• api 위치는 메모리에서 동시에 여러 개의 noname을 지원하는 위치 구조를 생성할 수 있어야 하며, http 요청이 있을 때 실제 URL을 기반으로 구성된 올바른 제한 제외 권한 액세스 제어를 호출할 수 있어야 합니다.

노트:

Limit_Exception이 구성되면 이중 계층 검증이 수행됩니다. 규칙은 다음과 같습니다.

•limit_out 확인이 우선 적용됩니다.

•limit_Exception 인증이 필요한 경우에는 Limit_Exception을 사용하여 비밀번호 인증을 사용합니다.

•limit_ex 허용되면 api_limit_just 구성의 권한 확인에 들어갑니다.

4.2.2 api_limit_Exception 지시어 소개

   
통사론: api_limit_book module_key 메소드…{…}
기본 -
문맥: 위치

제한_제외에 대한 module_key 매개변수를 추가합니다. 이 매개변수는 각 API 모듈의 URL 접두사 형식입니다. /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 구성 예

•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. 테스트

모든 선언적 API와 명령형 API의 인터페이스 접두사가 통합되었습니다.

5.1 Ctrl 구성 파일

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

5.2 모듈 테스트(기능은 변경되지 않고 유지되며 유일한 변경 사항은 모든 API 모듈의 URL 변경입니다.)

모든 선언적 API 및 명령형 API의 인터페이스 접두사가 /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 동적 SSL 인증서:/api/v1/ssl

img

5.2.2 상태 확인: /api/v1/hc

img

5.2.3 동적 범위: /api/v1/range

img

5.2.4 캐시 가속: /api/v1/cache

img

5.2.5 평방: /api/v1/sq

img

5.2.6 구성 API: /api/v1/config

5.3 api_limit_book 권한 확인 테스트

5.3.1 검증 비밀번호 파일 생성 예:

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 구성(SSL 및 범위 테스트를 예로 들어):

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 테스트:

5.3.3.1 SSL 검증 테스트

SSL의 경우 GET 메소드는 확인하지 않고 다른 메소드는 확인하므로 get 인터페이스를 호출하면 비밀번호를 입력할 수 없으며, put 인터페이스를 호출하면 올바른 비밀번호가 있는 test2/test2만 비밀번호를 입력할 수 있습니다. .

5.3.3.1.1 Get test: 결과를 직접 반환

img

5.3.3.1.2 PUT 테스트: 비밀번호를 입력해야 합니다. 비밀번호가 정확하면 결과가 반환됩니다.

올바른 비밀번호를 입력하고 콘텐츠 처리 단계로 진입하세요.

5.3.3.2 범위 검증 시험

범위의 경우 PUT 메소드는 확인하지 않고 다른 메소드는 확인하므로 put 인터페이스를 호출하면 비밀번호 입력이 허용되지 않으며 get 인터페이스를 호출하면 올바른 비밀번호를 사용하여 test/123456만 입력해야 합니다. .

5.3.3.2.1 GET 테스트: 비밀번호 필요

GET에는 비밀번호 test/123456이 필요합니다.

img

올바른 비밀번호를 입력하고 결과를 반환하세요.

img

5.3.3.2.2 PUT 테스트: 비밀번호를 입력할 필요 없이 바로 콘텐츠 처리 단계로 이동합니다.

img

NJet 애플리케이션 엔진은 커널 재구성을 통해  고유한 런타임 동적 구성 로딩 기능을 달성하며 차세대 고성능 웹 애플리케이션 엔진 입니다 . NJet은 고성능 데이터 플레인 처리 기능을 갖추고 있으며 NJet의 고유한 부조종사 CoPilot 서비스 프레임워크를 통해 클러스터링, 고가용성, 활성 상태 확인 및 선언적 API와 같은 여러 보조 기능을 예약하여 기능 확장을 촉진하고 관리/제어 기능 쌍을 분리합니다. 데이터 플레인에 미치는 영향까지 NJet 애플리케이션 엔진의 성능은 CNCF에서 권장하는 Envoy 애플리케이션 엔진의 3배를 초과합니다. 메일 그룹 공식 홈페이지   

알려지지 않은 오픈 소스 프로젝트가 얼마나 많은 수익을 가져올 수 있습니까? Microsoft의 중국 AI 팀은 수백 명의 사람들을 모아 미국으로갔습니다. Huawei는 Yu Chengdong의 직업 변경이 15년 동안 "FFmpeg Pillar of Shame"에 못 박혔다 고 공식 발표했습니다. 이전에는 그랬지만 오늘은 우리에게 감사해야 합니다.— Tencent QQ Video가 과거의 굴욕을 복수한다고요? Huazhong University of Science and Technology의 오픈 소스 미러 사이트가 외부 액세스 보고를 위해 공식적으로 공개되었습니다 . Django는 여전히 74%의 개발자가 선택한 제품입니다. Zed 편집자는 유명한 오픈 소스 회사의 전직 직원이었습니다 . 소식을 전했습니다: 기술 리더는 부하 직원의 도전을 받은 후 격노하고 무례하게 행동하여 해고되었으며 임신했습니다. 여직원 Alibaba Cloud가 공식적으로 Tongyi Qianwen 2.5를 출시했습니다. Microsoft는 Rust Foundation에 100만 달러를 기부했습니다.
{{o.이름}}
{{이름}}

추천

출처my.oschina.net/u/6606114/blog/11104034