NGINX Plus R25 발표
NGINX Plus 릴리스 25(R25)가 출시되어 기쁩니다. NGINX 오픈 소스를 기반으로 하는 NGINX Plus는 유일한 올인원 소프트웨어 웹 서버, 로드 밸런서, 역방향 프록시, 콘텐츠 캐시 및 API 게이트웨이입니다.
NGINX Plus R25 의 새로운 기능은 다음과 같습니다.
- 추가적이고 더욱 고급 JSON 웹 토큰 사용 사례 – NGINX Plus R25는 NGINX Plus R24 에 도입된 암호화된 JSON 웹 토큰(JWE) 지원을 기반으로 구축됩니다.
- HTTP 응답 코드에 대한 보다 세부적인 보고 – NGINX Plus API는 이제 HTTP 응답 코드를 클래스별로 집계하는 것뿐 아니라 개별적으로도 계산합니다. 메모리 할당을 늘려야 할 수도 있습니다 . 시작 실패를 방지하기 위해 충분한 메모리 할당을 참조하세요.
- 프록시 연결을 위한 동적 SSL/TLS 클라이언트 인증서 로딩 – 변수를 사용하여 NGINX Plus와 백엔드 서버 간 mTLS 연결을 위한 인증서를 동적으로 선택할 수 있습니다.
- HTTP 요청 처리를 위한 강화된 보안 – NGINX Plus는 HTTP 요청에 대해 여러 가지 추가 검사를 수행하여 잠재적인 공격으로부터 애플리케이션을 보호합니다.
- TCP/UDP 애플리케이션에 대한 다시 로드 시에도 상태 검사 상태 지속성 - TCP/UDP 서버에 대한 필수 상태 검사 결과는 이제 구성 다시 로드 시에도 지속될 수 있습니다.
- NGINX JavaScript 모듈 개선 – JavaScript ES6와의 호환성이 강화되었습니다.
행동의 중요한 변화
업스트림 존에 대한 메모리 요구 사항 증가
HTTP 응답 코드에 대한 보다 세부적인 보고 에서 자세히 설명한 대로 NGINX Plus R25는 개별 상태 코드 수와 클래스별 집계 수를 제공합니다. NGINX Plus가 역방향 프록시 또는 부하 분산 장치로 구성된 경우 20개가 넘는 피어가 있는 경우 업스트림 "피어"(백엔드 서버)를 모니터링하는 데 사용되는 공유 메모리 영역의 크기를 늘려야 할 수도 있습니다.
공유 메모리 영역이 충분히 프로비저닝되지 않은 경우 NGINX Plus R25가 시작되지 않아 업그레이드가 실패합니다. 업그레이드하기 전에 각 업스트림 영역의 메모리 사용률을 확인하는 것이 중요합니다. 메모리 할당을 확인하고 조정하는 방법에 대한 자세한 내용은 시작 실패를 방지하기 위한 충분한 메모리 할당을 참조하세요.
NGINX Plus Repo 구성 및 설치 절차 변경
NGINX Plus R24 가 출시되면서 모든 NGINX 소프트웨어의 패키지 저장소가 재구성되어 NGINX Plus 설치 절차가 변경되었습니다.
NGINX Plus를 설치하거나 업그레이드하면 운영 체제의 패키지 관리자( apt , yum 또는 이와 동등한 패키지)가 NGINX Plus용 소프트웨어 저장소로 구성됩니다. 이전 저장소를 사용하도록 구성된 기존 시스템( NGINX Plus R23 또는 이전 버전을 실행하는 경우)에서는 새 저장소를 참조하도록 패키지 관리자를 업데이트해야 합니다. F5 지식 기반 의 지침을 참조하세요.
NGINX Plus R25 의 초기 설치를 수행하는 경우 NGINX Plus 관리자 가이드 의 NGINX Plus 설치를 참조하세요.
메모: 새로운 소프트웨어 저장소를 사용해야 합니다. 이전 리포는 더 이상 업데이트되지 않으며 향후 설치 및 업그레이드 시 오류가 발생할 수 있습니다.
더 이상 사용되지 않는 쿠키 플래그 모듈
NGINX Plus R23 출시 당시 발표된 대로 타사 Cookie‑Flag 모듈은 더 이상 사용되지 않으며 NGINX Plus R26 의 동적 모듈 리포에서 제거됩니다. 해당 모듈에 정의된 set_cookie_flag 지시문은 내장된 proxy_cookie_flags 지시문으로 대체됩니다. 가능한 한 빨리 구성에서 set_cookie_flag 지시문을 proxy_cookie_flags 지시문으로 바꾸는 것이 좋습니다.
플랫폼 지원 변경
- 지원되는 새로운 운영 체제:
- 데비안 11(x86_64, aarch64)
- Alpine Linux 3.14(x86_64, aarch64)
- 제거된 이전 운영 체제:
- Alpine Linux 3.10; 지원되는 가장 오래된 버전은 3.11입니다.
- Amazon Linux 1(2018.03+); Amazon Linux 2 LTS로 전환
- FreeBSD 11.4+; 지원되는 가장 오래된 버전은 12.1+입니다.
- Ubuntu 16.04 LTS; 지원되는 가장 오래된 버전은 18.04 LTS입니다.
- NGINX Plus R26 에서 더 이상 지원되지 않는 이전 운영 체제:
- 알파인 리눅스 3.11
새로운 기능에 대한 자세한 정보
추가 JSON 웹 토큰 사용 사례 및 기능
NGINX Plus R24는 암호화된 JSON 웹 토큰(JWE)에 대한 최초 지원을 도입하여 데이터 기밀성을 유지하면서도 가장 널리 사용되는 클라이언트 인증 방법 중 하나를 확장했습니다. NGINX Plus R25는 해당 기능을 기반으로 하여 서명된(JWS) 및 암호화된(JWE) 사용 사례 모두에 대한 JWT 기반 인증의 보안을 개선하는 데 도움이 되는 추가적이고 보다 고급 인증 사용 사례에 대한 지원을 도입합니다. 이러한 개선 사항은 개인 식별 정보(PII) 유출 위험을 줄이는 동시에 더 많은 유연성을 제공합니다. NGINX Plus의 새로운 JWT 기능과 향상된 기능은 다음과 같습니다.
복호화된 JWE 암호문에 대한 변수
JWT는 HTTP 요청의 상태 비저장 인증(즉, 토큰 기반 인증)에 널리 사용되고 신뢰받는 방법입니다. JWT는 토큰 페이로드에서 최종 사용자 속성을 전송하여 요청의 보안을 강화하는 데 도움이 됩니다. 그러나 보안 연구원과 DevSecOps 실무자는 암호화되지 않은 PII를 웹 클라이언트에 저장함으로써 발생하는 위험이 시급한 문제라는 데 동의합니다. 따라서 암호화된 토큰을 구현하기 위한 지침을 제공하는 JSON 웹 암호화 표준(RFC 7516) 이 개발되었습니다.
NGINX Plus R24는 JWE에 대한 지원을 도입하여 전체 클레임 세트에 대한 데이터 무결성과 기밀성을 제공합니다. 암호화된 토큰 내에 PII를 인코딩하면 JWT를 사용할 때 데이터 유출 위험을 크게 줄일 수 있습니다.
NGINX Plus R25는 초기 JWE 지원을 기반으로 새로운 변수인 $jwt_payload를 추가했습니다. 이 변수를 통해 NGINX Plus는 JWE와 암호문을 복호화하고 HTTP 요청을 처리하는 동안 일반 텍스트에 액세스할 수 있습니다. 이 새로운 기능은 고급 액세스 제어 정책과 요청 라우팅 결정을 구현하는 데 사용할 수 있으며, 사용자가 NGINX Plus를 백엔드 애플리케이션의 JWE 복호화 계층으로 배포할 수 있도록 합니다.
중첩된 JWT 지원
JWE 토큰은 PII를 보호하는 데 효과적이며 암호문은 CDN 및 기타 TLS 종료 프록시에서도 기밀성을 유지하는 데 도움이 됩니다. 하지만 JWE는 애플리케이션 환경을 복잡하게 만들 수 있으므로 암호화는 양날의 검입니다. 이 문제를 해결하는 방법은 중첩된 JWT를 사용하는 것입니다.
중첩된 JWT는 JWE의 암호문으로 JWS를 내장합니다. NGINX Plus R25는 JWS와 JWE를 동시에 지원하여 HTTP 요청을 인증하는 방법으로 중첩된 JWT를 사용할 수 있습니다. 이제 NGINX Plus는 한 번의 작업으로 JWE의 암호문을 해독하고, 생성된 평문을 JWS로 검증하고, 포함된 토큰의 exp (만료 시간) 및 nbf (이전 아님) 클레임을 사용하여 유효한지 확인할 수 있습니다. 이를 통해 기존 JWS 환경을 JWE로 래핑하여 페이로드 암호화로 업그레이드할 수 있습니다.
다음 구성 스니펫은 해당 프로세스를 보여줍니다. auth_jwt_type 지시문의 새로운 중첩 매개변수는 NGINX Plus에게 JWE 복호화와 JWS 유효성 검사를 모두 수행하라고 지시합니다. 또한 JWT 헤더와 JWT 클레임에 대한 변수가 평가되는 방식에도 영향을 미칩니다.
auth_jwt_header_set지시어는 외부 JWE 헤더에서 작동합니다.auth_jwt_claim_set지시어는 중첩된 JWS 클레임에 적용됩니다.$jwt_header_ 이름변수에는 외부 JWE 헤더 속성이 포함되어 있습니다.$jwt_claim_ 이름변수에는 중첩된 JWS 클레임이 포함되어 있습니다.
다음 구성을 사용하면 NGINX Plus는 추가 HTTP 요청 헤더를 구성하여 백엔드 애플리케이션으로 전송합니다. JWE 헤더의 암호화 알고리즘( $jwt_header_enc 변수)과 JWS 페이로드의 JWT 주제 클레임( $jwt_claim_sub 변수)은 원래 요청과 함께 프록시됩니다. 즉, 애플리케이션은 암호화 코드나 라이브러리를 구현할 필요 없이 HTTP 헤더를 사용하기만 하면 JWE 기반 인증을 활용할 수 있습니다.
제로 트러스트 아키텍처에서 운영하는 사용자의 경우 다음 구성을 통해 백엔드 애플리케이션이 $jwt_payload 변수에 캡처된 JWS 토큰의 유효성을 검사할 수 있습니다. 변수에는 JWE 암호문의 복호화된 평문 버전이 포함되어 있습니다. 중첩된 JWT가 있는 경우 JWS는 전달 토큰으로 백엔드 애플리케이션에 전달될 수 있습니다.
본질적으로 중첩된 JWT는 NGINX Plus가 보안 토큰을 동시에 복호화하고 검증할 수 있도록 하여 운영을 간소화하고 애플리케이션 보안을 개선하며, 백엔드 애플리케이션에 대한 "일반 JWT" 서명 토큰을 구문 분석하거나 프록시할 수 있습니다.
JWE를 위한 비대칭 암호화
NGINX Plus R24는 AES 표준을 사용하여 토큰의 대칭 암호화를 지원합니다. NGINX Plus R25는 RSA 키 쌍을 사용할 때 비대칭 암호화를 지원합니다. 비대칭 암호화는 암호화와 복호화에 서로 다른 키(공개 키와 개인 키)를 사용하며, 이 키는 RSA(Rivest–Shamir–Adleman) 알고리즘을 통해 수학적으로 연결됩니다. 이는 클라이언트와 서버 간 HTTPS 트래픽의 SSL/TLS 암호화에 사용되는 메커니즘과 동일합니다.
NGINX Plus R25는 NGINX Plus 측에서 명시적 구성이 필요하지 않고 키 관리 알고리즘으로 OEAP(Optimal Asymmetric Encryption Padding)를 갖춘 RSA를 지원합니다. JWS alg (알고리즘) 헤더에 지원되는 값은 RSA-OAEP , RSA-OAEP-256 , RSA-OAEP-384 및 RSA-OAEP-512 입니다.
다음 구성은 JWE에 대한 비대칭 암호화를 구현하는 데 필요한 모든 것이 RSA 개인(언래핑) 키가 포함된 JSON 웹 키(JWK) 파일을 auth_jwt_key_file 지시문의 매개변수로 지정하는 것뿐임을 보여줍니다( auth_jwt_key_request 지시문도 사용할 수 있음).
다중 소스 JWK 지원
중첩된 JWT를 활용한다는 것은 연관된 JWK가 두 개 이상의 소스에서 나올 가능성이 높다는 것을 의미합니다. NGINX Plus R25는 동일한 컨텍스트에서 여러 개의 auth_jwt_key_file 및 auth_jwt_key_request 지시어를 지원합니다. NGINX Plus는 지정된 모든 소스에서 키를 로드하고 결합된 키 세트 중에서 일치하는 검증 키를 찾습니다. 이는 외부 ID 공급자가 발급하고 별도의 프로세스로 암호화가 수행된 JWE 내부에 중첩된 JWS로 작업할 때 매우 유용합니다.
이 기능은 API 게이트웨이로 배포된 NGINX Plus에 더 많은 유연성, 보안 및 성능을 추가합니다.
사용자 정의 JWT 검증 규칙
NGINX Plus를 API 게이트웨이로 배포하는 경우 세분화된 액세스 제어를 구현하기 위해 JWT 클레임을 검사하는 것이 일반적입니다. 이로 인해 복잡한 구성이 생길 수 있습니다. 이전 NGINX Plus 릴리스에서는 구성 블록을 사용 하여 JWT 클레임을 평가할 수 있었지만 이 방법은 다소 제한적이었고 암호화된 토큰에는 작동하지 않았습니다.
NGINX Plus R25는 JWT 검증 프로세스 중에 토큰에 대한 추가 검사를 수행하는 기본 방식을 제공함으로써 이러한 제한을 해결합니다. auth_jwt_require 지시어는 JWT 검증 프로세스에 선택적이고 사용자 정의 가능한 단계를 추가합니다. 공백으로 구분된 문자열 목록을 허용하며, 모든 문자열은 비어 있지 않아야 하며 다음과 같지 않아야 합니다.0 JWT 검증이 성공하려면 (0)이 필요합니다. 이를 통해 JWT 검증 프로세스에 큰 유연성이 추가됩니다.
JWT 표준은 어떤 클레임이 필수인지 규정하지 않으므로, auth_jwt_require를 사용하여 각 환경에 적합한 클레임을 나열할 수 있습니다.
다음 구성은 exp 및 sub 클레임이 모든 토큰에 모두 존재하도록 보장합니다.
맵 블록이나 NGINX Plus 키‑값 저장소를 사용하여 auth_jwt_require 지시문에 부울 값을 전달하면 더 복잡한 사용 사례를 구성할 수 있습니다. 또한 NGINX JavaScript 모듈을 사용하여 RFC 8705 에 정의된 상호 TLS(mTLS) 클라이언트 인증서 바인딩 액세스 토큰과 같은 풍부한 인증 솔루션을 구현할 수 있습니다.
다음 구성은 클라이언트 인증서 인증(mTLS)과 JWT 검증을 모두 수행합니다. 14번째 줄의 auth_jwt_require 지시문은 $thumbprint_match 변수의 평가를 요구하며, JWT 검증은 0이 아닌 값을 갖는 경우에만 성공합니다. 이 변수는 2번째 줄에서 호출된 JavaScript 함수를 실행하여 평가됩니다.
이전 스니펫의 2번째 줄에서 호출된 validate 함수의 코드는 다음과 같습니다.
HTTP 응답 코드에 대한 보다 세부적인 보고
모니터링과 가시성은 애플리케이션 성능, 가용성 및 보안의 초석입니다. HTTP 응답 코드는 애플리케이션 상태를 파악할 수 있는 가장 중요한 소스 중 하나입니다. NGINX Plus API는 NGINX와 클라이언트 간 상호작용, NGINX와 업스트림 서버 간 상호작용에 대한 HTTP 응답 코드를 추적합니다. 해당 횟수는 NGINX Plus 라이브 활동 모니터링 대시보드 의 해당 탭에 보고됩니다.
이전 버전의 NGINX Plus API 는 클래스( 2xx , 4xx 등)별로 HTTP 응답 코드 수를 집계했습니다. 이제 코드는 개별적으로도 계산됩니다. 200,404 ,503 , 등.). 이를 통해 실패한 인증의 급증과 같이 매우 다른 원인을 가진 오류를 구별하여 애플리케이션에서 정확히 무슨 일이 일어나고 있는지에 대한 더 깊은 통찰력을 얻을 수 있습니다.403 ) 및 누락된 콘텐츠(404 ). 메트릭 수집 구성에 대한 자세한 내용은 NGINX Plus 관리자 가이드를 참조하세요.
NGINX Plus R25 와 함께 출시된 NGINX Plus API 의 최신 버전( 버전 7 )에는 responses 객체 내에 codes 객체가 포함되어 개별 HTTP 응답 코드를 계산할 수 있습니다. 집계된 응답은 여전히 사용할 수 있으며, 코드 개체가 포함되지 않은 이전 버전의 NGINX Plus API도 NGINX Plus R25 와 함께 계속 사용할 수 있습니다. 새로운 측정 항목 세트의 예는 다음과 같습니다.
$ curl -s http://localhost:8080/api/7/http/server_zones/www.example.com | jq { "처리 중": 31, "요청": 63192, "응답": { "1xx": 0, "2xx": 54368, "3xx": 8454, "4xx": 330, "5xx": 9, "코드": { "200": 54368, "302": 8454, "401": 30, "404": 200, "429": 100, "503": 9 }, "총": 63161 }, "폐기됨": 0, "수신됨": 693436, "보냄": 13843478 }
시작 실패를 방지하기 위해 충분한 메모리 할당
중요 참고 사항: NGINX Plus가 역방향 프록시 또는 로드 밸런서로 구성된 경우 개별 코드를 계산하면 각 업스트림 그룹의 공유 메모리 영역에서 메모리 사용률이 늘어납니다. 업스트림 그룹에 20개가 넘는 피어가 있는 경우 zone 지시문으로 구성된 대로 메모리 크기를 늘려야 할 수도 있습니다.
업스트림 영역에 충분한 프로비저닝이 없으면 NGINX Plus R25가 시작되지 않아 업그레이드가 실패합니다.
다음은 상류 그룹의 공유 메모리 영역에 대한 일반적인 구성입니다.
NGINX Plus R25 로 업그레이드하기 전에 기존 업스트림 영역의 메모리 사용률을 확인하는 것이 중요합니다. 이렇게 하려면 다음 방법 중 하나를 사용하기 전에 NGINX Plus API가 활성화되어 있는지 확인하세요.
이 demo.nginx.com 의 예와 같이 사용률이 54%인 라이브 활동 모니터링 대시보드의 HTTP 업스트림 탭을 확인하세요.
다음 명령을 실행하여 호스트에서 직접 NGINX Plus API를 사용합니다. 첫 번째:
$ API=http://localhost:8080/api; `curl -s $API/1/http/upstreams | jq -r '.[].zone | @uri'에 대해 i를 ``사용합니다.[].zone | @uri''를 ``반올림 ...
현재 사용률이 40%를 넘는 경우(스크린샷 참조), zone 명령어의 두 번째(크기) 매개변수를 최소 2.5배 이상 늘립니다. 예를 들어, 위의 구성 스니펫에서 64k를 160k 로 늘리는 것이 좋습니다.
프록시를 위한 동적 SSL/TLS 클라이언트 인증서 로딩
상호 TLS(mTLS)는 클라이언트와 서버 모두의 신원을 확인하는 일반적인 인증 관행입니다. NGINX Plus를 사용하면 업스트림 그룹의 서버를 동적으로 정의하고 변수를 사용할 수 있습니다. 즉, NGINX Plus가 업스트림 서버에서 자체를 검증하는 데 사용하는 TLS 인증서를 동적으로 선택할 수 있어야 할 수도 있음을 의미합니다.
NGINX Plus R25는 mTLS에 사용되는 구성 지침을 백엔드 서버로 확장하여 인증서를 나타내는 변수를 허용합니다. 변수는 다음 중 하나를 참조할 수 있습니다.
- 디스크에 있는 파일
- PEM 형식의 원시 데이터,
데이터 접두사:
이를 통해 NGINX Plus는 인증서와 개인 키를 동적으로 선택할 수 있습니다. 이는 지속적으로 변화하는 최신 애플리케이션 환경에 유용합니다. NGINX Plus 키‑값 저장소 에 인증서와 개인 키를 저장할 수 있습니다. 이렇게 하면 개인 키가 디스크가 아닌 메모리에 저장되므로 보안이 강화됩니다. 또 다른 사용 사례는 API 호출을 사용하여 키‑값 저장소의 인증서를 업데이트하는 자동 인증서 순환입니다.
다음 구성에서 NGINX Plus는 호스트 이름을 기반으로 다양한 업스트림 그룹으로 요청을 라우팅합니다. 프록시 연결은 mTLS를 사용하여 만들어지며, 각 업스트림에 대한 적절한 클라이언트 인증서가 동적으로 선택됩니다.
다음 지침은 업스트림 서버를 사용한 mTLS에 대한 동적 인증서 로딩을 지원합니다.
HTTP 요청 처리를 위한 강화된 보안
NGINX 철학의 핵심 원칙 중 하나는 지속적인 개선이며, 특히 보안과 관련된 것입니다. 보안 연구원과의 협업, F5의 업계 최고 보안 기술을 당사 제품에 통합, 내부 개발 노력을 포함하여 사용 가능한 모든 리소스를 활용합니다.
마지막의 예로, NGINX Plus R25는 요청 밀수 등의 잠재적인 공격으로부터 애플리케이션을 보호하기 위해 HTTP 요청에 대해 여러 가지 추가 검사를 수행합니다. 다음 조건에는 오류가 반환됩니다.
- HTTP/1.0 요청에는
Transfer-Encoding헤더가 포함됩니다. Transfer-Encoding및Content-Length헤더가 모두 존재합니다.- 요청 줄이나 헤더 이름에 공백이나 제어 문자가 있습니다.
호스트헤더에 공백이나 제어 문자가 있습니다.CONNECT방식을 사용합니다
또한, 다음 문자는 이제 프록시 URI에서 항상 이스케이프됩니다: " , < , > , \ , ^ , ` , { , | , } .
이러한 변경 사항은 사전 예방적 보안 강화 조치이며 알려진 취약점에 대응하여 이루어진 것이 아닙니다.
TCP/UDP 애플리케이션에 대한 재로드 시 필수 상태 검사 상태의 지속성
NGINX Plus는 필수 상태 검사를 사용하여 클라이언트 요청이 해당 서버로 프록시되기 전에 업스트림 그룹에 추가된 새 서버가 테스트되고 정상인지 확인합니다. NGINX Plus R23 및 이전 버전에서는 구성이 다시 로드된 후에는 다시 로드 전 상태에 관계 없이 업스트림 서버가 비정상인 것으로 간주되었습니다. 결과적으로 NGINX Plus는 첫 번째 필수 검사를 통과할 때까지 서버로 요청을 보내지 않았습니다.
NGINX Plus R24는 HTTP 애플리케이션에 대해 다시 로드하는 동안 필수 상태 검사 상태를 선택적으로 지속시키는 기능을 도입했습니다. 다시 로드하기 전 마지막 필수 상태 검사가 성공적이었다면 NGINX Plus는 다시 로드 후 필수 상태 검사가 성공할 때까지 기다릴 필요 없이 즉시 서버에 요청을 보낼 수 있습니다.
NGINX Plus R25는 이 기능을 TCP/UDP 애플리케이션( 스트림 컨텍스트 내)으로 확장합니다. HTTP의 경우 필수 매개변수와 함께 health_check 지시문에 지속성 매개변수를 추가합니다.
NGINX JavaScript 모듈의 향상
NGINX JavaScript 모듈(njs)이 여러 버그 수정과 JavaScript ES6 와의 호환성을 강화하는 몇 가지 기능 향상을 통해 버전 0.6.2로 업데이트되었습니다.
let 및 const 키워드를 사용한 변수 선언
NGINX JavaScript는 이제 let 및 const 키워드를 사용하여 범위가 지정된 변수의 선언을 지원합니다. 이전 버전의 NGINX Plus와 njs는 변수를 선언하고 할당하기 위해 var 키워드만 지원했습니다. 이는 서로 다른 프로젝트, 프로그래밍 언어 및 엔지니어링 팀이 공유 코드베이스나 라이브러리에서 협업할 때 종종 발생하는 복잡성을 처리하는 데 필요한 특정 블록 명령문의 범위로 제한되는 변수를 제공하지 않았습니다.
JavaScript ES6는 범위 변수를 정의하기 위한 let 및 const 키워드를 제공합니다.
let변수는블록명령문이나 변수가 사용되는 표현식의 범위로 제한됩니다. 이와 대조적으로var키워드는 블록 범위에 관계없이 전역적으로, 또는 전체 함수에 대해 지역적으로 변수를 선언합니다.const변수는let키워드를 사용하여 선언된 변수와 마찬가지로 블록 범위입니다. 상수의 값은 재할당을 통해 변경될 수 없으며, 다시 선언할 수 없습니다.
모든 Promise 생성자 메서드 지원
Promise.all() , Promise.allSettled() , Promise.any() , Promise.race() 생성자 메서드가 추가되어 이제 njs는 JavaScript ES6 표준에 정의된 전체 생성자 메서드 세트를 지원합니다.
업그레이드 또는 NGINX Plus를 사용해 보세요
NGINX Plus를 사용하고 계시다면 가능한 한 빨리 NGINX Plus R25 로 업그레이드하실 것을 적극 권장합니다. 또한 몇 가지 추가적인 수정 사항과 개선 사항을 얻을 수 있으며, 지원 티켓을 제출해야 할 때 NGINX에서 도움을 주는 데 도움이 됩니다.
NGINX Plus를 사용해보지 않으셨다면 보안, 부하 분산, API 게이트웨이로 사용하거나 향상된 모니터링 및 관리 API를 갖춘 완벽히 지원되는 웹 서버로 사용해보시기 바랍니다. 오늘 무료 30일 체험판을 통해 시작해 보세요.
"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."