njs 0.7.7을 사용하여 NGINX 구성을 더욱 모듈화하고 재사용 가능하게 만드십시오.
NGINX JavaScript 모듈(njs)을 도입한 이후2015 (원래 이름인 nginScript로) 2017년에 일반적으로 출시한 이후<.htmla> 수십 번의 버전 업데이트를 통해 꾸준히 새로운 기능을 추가하고 구현을 개선해 왔습니다 . 보통 우리는 새로운 NGINX JavaScript 버전의 기능에 대해 논의하기 위해 NGINX Plus 릴리스를 기다리지만, 이번에는 0.7.7 버전이 너무나 기대돼서 기다릴 수가 없습니다!
njs 0.7.7의 중요한 개선 사항은 NGINX 구성을 더욱 모듈화하고 체계화하며 재사용 가능하게 만드는 데 도움이 됩니다.
- 이제 전역적으로 선언하는 대신 적용되는 컨텍스트에서 njs 코드를 선언하여 사용자 지정 코드를 사용 지점에 더 가깝게 가져올 수 있습니다.
- njs 코드 자체의 후크를 사용하면 실행 컨텍스트에 따라 동작을 수정할 수 있습니다.
- 새로운
fs.FileHandle객체는 파일 작업의 효율성을 더욱 높여줍니다 .
njs에 대해 자세히 알아보고 샘플 코드가 제공되는 사용 사례 목록을 검토하려면 블로그의 NGINX JavaScript 모듈을 사용하여 각 요청에 JavaScript의 강력함과 편의성 활용을 읽어보세요.
njs 0.7.7의 모든 새로운 기능과 버그 수정의 전체 목록을 보려면 변경 사항 문서를 참조하세요.
로컬 컨텍스트에서 JavaScript 코드 및 변수 선언
이전 njs 버전에서는 JavaScript 코드를 가져와서 js_import , js_path , js_set , js_var 지시문을 사용하여 최상위 http 또는 스트림 컨텍스트에서 관련 변수를 선언해야 했습니다. 이는 기본 파일 맨 위에 전역 변수를 선언하는 것과 같습니다. 하지만 실제로 JavaScript 함수와 변수를 호출하는 지시문은 자식 컨텍스트에 나타납니다. 예를 들어, HTTP location{} 블록의 js_content 지시문과 Stream server{} 블록의 js_access 지시문이 있습니다. 이로 인해 두 가지 문제가 발생합니다.
- 구성 내용을 읽는 사람에게는
http및스트림컨텍스트의 선언은 사실상 노이즈일 뿐입니다. 연관된 코드와 변수가 실제로 어디에서 사용되는지 표시되어 있지 않기 때문입니다. - 자식 컨텍스트에서는 코드와 변수가 어디로 가져와서 선언되었는지 명확하게 알 수 없습니다. nginx.conf 라는 기본 구성 파일에만
http{}및stream{}블록을 포함하고include지시문을 사용하여 /etc/nginx/conf.d 및 /etc/nginx/stream.d 디렉터리에서 더 작은 함수별 구성 파일을 읽는 것을 권장하지만, NGINX 구성은 유연하여 여러 파일에http{}및stream{}블록을 포함할 수 있습니다. 특히 여러 사람이 NGINX 구성에 대해 작업하고 항상 확립된 규칙을 따르지 않는 환경에서는 이러한 문제가 심각해질 수 있습니다.
njs 0.7.7 이상에서는 코드를 가져오고 사용된 컨텍스트에서 변수를 선언할 수 있습니다.
HTTP –
특정 사용 사례에 대한 모든 njs 구성을 하나의 파일에 저장하면 코드가 더 모듈화되고 이식성이 좋아집니다.
예를 들어, 이전 njs 버전에서 새 스크립트를 추가할 때 nginx.conf ( js_import 와 가능한 경우 js_path , js_set , js_var 추가)와 JavaScript 함수가 호출되는 파일(여기서는 jscode_local.conf )을 모두 변경해야 했습니다.
njs 0.7.7 이상에서는 util 함수와 관련된 모든 구성이 jscode_integrated.conf라는 하나의 파일에 들어 있습니다.
실행 컨텍스트에 따라 동작 수정
njs 0.7.7의 여러 가지 새로운 기능을 사용하면 실행되는 컨텍스트(처리 단계)에 따라 JavaScript 코드의 동작을 수정할 수 있습니다.
HTTP r.internal 속성
HTTP r.internal 속성은 내부 요청( internal 지시문을 포함하는 location{} 블록에서 처리됨)에 대해 "true"로 설정된 부울 플래그입니다. 스크립트가 내부 및 비내부 컨텍스트에서 모두 호출될 수 있는 일반 이벤트 핸들러를 사용하는 경우 r.internal 플래그를 사용하여 논리를 포크할 수 있습니다.
다음은 내부 요청으로 분류됩니다.
error_page,index,random_index및try_files지시문에 의해 리디렉션된 요청- 업스트림 서버에서
X-Accel-Redirect응답 헤더에 의해 리디렉션된 요청 auth_request및mirror지시문, ngx_http_addition_module 모듈의 지시문 또는 SSI(Server Side Include)포함가상명령( ngx_http_ssi_module 모듈에서 지원)에 의해 호출되는 하위 요청다시 쓰기지시문에 의해 변경된 요청
개선된 s.send() 스트림 메서드
이전 njs 버전에서는 Stream s.send() 메서드는 컨텍스트에 따라 달라졌습니다. 즉, 데이터를 보내는 방향은 메서드가 호출되는 콜백의 위치(업스트림 또는 다운스트림)에 따라 결정되기 때문입니다. 이것은 동기 콜백에는 잘 작동합니다. s.send() 는 원래 동기 콜백을 위해 설계되었습니다. 하지만 ngx.fetch() 와 같은 비동기 함수에서는 작동하지 않습니다.
njs 0.7.7 이상에서는 방향이 별도의 내부 플래그에 저장되어 s.send() 가 사용할 수 있습니다.
새로운 fs.FileHandle() 객체를 사용한 보다 효율적인 파일 작업
파일 시스템 모듈( fs )은 파일에 대한 작업을 구현합니다. fs 모듈의 새로운 FileHandle 객체는 숫자형 파일 설명자에 대한 객체 래퍼입니다. FileHandle 객체의 인스턴스는 fs.promises.open() 메서드에 의해 생성됩니다.
FileHandle 객체를 사용하여 파일 설명자를 가져오며, 이는 다음 용도로 사용할 수 있습니다.
- 파일에서
read()및write()와 같은 기능을 수행합니다. - 전체 파일을 읽지 않고도 파일을 열고 지정된 위치에서 읽기 및 쓰기를 수행합니다.
FileHandle 의 다음 속성이 구현되었습니다(각 속성에 대한 필수 인수와 선택 인수에 대한 자세한 내용은 설명서를 참조하세요):
파일핸들.fd파일 핸들.read()파일 핸들.stat()파일 핸들.write()파일 핸들.write()파일 핸들.닫기()
다음 메서드는 FileHandle을 지원하도록 업데이트되었습니다(각 메서드의 인수에 대한 정보는 링크된 설명서를 참조하세요).
njs를 사용하여 구성을 향상시키세요
njs 0.7.7을 통해 여러분의 팀이 njs 코드를 작업하고 공유하는 것이 더 쉬워졌습니다. njs 지시문에 대한 확장된 컨텍스트를 사용하면 사용자 정의 JavaScript 코드로 NGINX 구성을 더욱 간편하게 향상시킬 수 있습니다. API 게이트웨이, 역방향 프록시 또는 웹 서버를 향한 첫 걸음을 내딛을 수 있으며, 이는 단순한 미들웨어나 에지 구성 요소가 아닙니다. 스택에 다른 구성 요소를 추가하지 않고도 JavaScript, TypeScript 또는 타사 노드 모듈을 통해 이를 애플리케이션의 일부로 만들 수 있습니다. 필요한 것은 NGINX뿐입니다!
질문이 있으신가요? NGINX 커뮤니티 Slack 에 가입하고 #njs-code-review 채널을 확인하여 njs 코드에 대한 자세한 정보를 알아보고, 질문하고, 피드백을 받아보세요.
"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."