NGINX Unit, 새로운 기능(통계 엔진!)과 흥미로운 계획으로 2022년 가을을 맞이합니다.

가장 먼저 말씀드릴 것은 NGINX Unit 팀의 소식을 공유한 지 꽤 오랜 시간이 지났다는 것입니다. 이 격동의 시기는 모든 사람에게 영향을 미쳤고, 우리도 예외는 아닙니다. 올해 3월, Unit 팀의 창립 멤버인 Valentin Bartenev와 Maxim Romanov는 수년간의 노력과 엄청난 창의성을 NGINX Unit 에 쏟은 후 다른 기회를 찾기로 결정했습니다. 공로는 누구에게 돌려야 할까요. 그들이 없었다면 NGINX Unit은 지금의 위치에 있을 수 없었을 것입니다. 축하해요, 여러분.

그럼에도 불구하고, 우리의 결의는 굳건하며, NGINX 공동 창립자 이고르 시소예프의 NGINX 사업부에 대한 원래 열망을 실현하려는 우리의 헌신도 마찬가지입니다. Alejandro Colomar와 Andrew Clayton이라는 두 명의 새로운 팀 멤버가 합류하면서 개발 작업이 더욱 활기를 띠게 되었고, 이제 NGINX Unit 버전 1.25 부터 1.28까지에서 주목할 만한 몇 가지 항목을 여러분과 공유하고자 합니다.

관찰 가능성은 이제 중요한 것입니다

Unit의 주요 열망 중 하나는 항상 관찰성이었으며, 버전 1.28.0에는 가장 간절히 기다려온 기능 중 하나인 통계 엔진의 첫 번째 반복이 포함되었습니다. 해당 출력은 새로운 /status API 엔드포인트에 노출됩니다.

$ curl --unix-socket /var/run/control.unit.sock http://localhost/status

{
"연결": {
"수락됨": 1067,
"활성": 13,
"유휴": 4,
"닫힘": 1050
},

"요청": {
"총": 1307
},

"applications": {
"wp": {
"processes": {
"running": 14,
"시작": 0,
"유휴": 4
},

"요청": {
"활성": 10
            }
        }
    }
}

여기의 대부분 필드는 자체 설명적입니다. 연결 (2번째 줄)과 요청 (9번째 줄)은 인스턴스 전체 데이터를 제공하는 반면, 애플리케이션 개체(13번째 줄)는 /config/applications를 미러링하여 애플리케이션과 특별히 관련된 프로세스와 요청을 다룹니다.

3~6행은 NGINX Unit에서 추적하는 네 가지 연결 범주( 허용 , 활성 , 유휴 , 닫힘) 를 보여줍니다. 프로세스에 대한 범주는 실행 중 , 시작 중 , 유휴 상태 입니다(16~18행). 이러한 카테고리는 연결과 프로세스의 내부 표현을 반영하므로 이제 서버만큼 이에 대해 많이 알 수 있습니다.

간결한 것 같나요? 지금으로선 알 수 있는 게 전부입니다. 물론, 우리는 더 유용한 지표를 공개하기 위해 노력하고 있습니다. 하지만 여러분은 이미 명령줄에서 이 API를 쿼리하여 서버에서 무슨 일이 일어나고 있는지 확인할 수 있고, 심지어 출력을 대시보드에 꽂거나 더 기발한 접근 방식을 선택할 수도 있습니다. 대시보드가 없는 게 아닐까요? 글쎄요, 저희의 일부 계획에는 내장형 기능을 제공하는 것도 포함되어 있으니, 이것이 어떻게 전개되는지 지켜보시려면 저희를 팔로우해 주세요.

자세한 내용은 NGINX 단위 설명서의 사용 통계를 참조하세요.

변수가 많을수록 사용할 수 있는 곳도 많아집니다

버전 1.24부터 도입된 변수 목록은 매우 광범위하며 $body_bytes_sent , $header_referer , $header_user_agent , $remote_addr , $ request_line , $request_uri , $status , $time_local 이 포함됩니다.

이들 중 대부분은 다소 간단하지만, 특히 주목할 만한 몇 가지를 소개합니다.

• $request_uri에는 브라우저 인코딩이 유지된 요청된 URI의 경로와 쿼리가 포함됩니다.
• 이름이 비슷한 $request_line은 GET /docs/help.html HTTP/1.1 과 같은 전체 요청을 저장하며 로깅을 목적으로 합니다.
• HTTP 응답 상태 코드를 포함하는 $status 와 같습니다.

알아차리셨나요? 우리는 응답을 언급했습니다. 그렇습니다. 저희도 그 영역으로 이동하고 있습니다. 이전 Unit 버전의 변수는 들어오는 요청에 초점을 맞췄지만, 이제는 $status 및 $body_bytes_sent 와 같이 응답 속성도 캡처하는 변수가 있습니다.

변수를 사용할 수 있는 새로운 장소와 관련하여 가장 먼저 언급할 것은 사용자 정의가 가능한 새로운 액세스 로그 형식입니다. NGINX 단위 로그 항목에서 JSON을 사용하고 싶으신가요? 간단한 경로 문자열을 지정하는 것 외에도 access_log 옵션은 로그 항목의 형식을 설정하는 객체가 될 수도 있습니다.

{ 
"액세스_로그": {
"경로": "/var/log/unit/access.log", 
"형식": "{ \"원격_주소\":\"$원격_주소\", "시간\":\"$시간_로컬\", \"요청\":\"$요청_라인\", \"응답\":\"$상태\", \"헤더_참조자\":\"$헤더_참조자\", \"헤더_사용자_에이전트\":\"$헤더_사용자_에이전트\" }" 
} 
}

따라서 일반적인 로그 형식을 벗어나 원하는 대로 사용할 수 있습니다.

변수에 대한 두 번째 주목할 만한 사용 사례는 경로 작업 의 위치 값입니다.

{ 
"action": { 
"return": 301, 
"위치": "https://$host$request_uri" 
} 
}

여기서는 $request_uri를 사용하여 HTTPS를 통해 쿼리 부분을 포함한 요청을 동일한 웹사이트로 전달합니다.

chroot 옵션은 이제 공유 옵션과 마찬가지로 변수를 지원하는데 이는 논리적입니다.

{ 
"action": { 
"share": "/www$uri",
"chroot": "/www/data/$host/" 
} 
} 

NGINX Unit은 이제 동적 변수도 지원합니다. 요청 인수, 쿠키 및 헤더는 변수로 노출됩니다. 예를 들어, 쿼리 문자열 Type=car&Color=red는 $arg_Type 및 $arg_Color 라는 두 개의 인수 변수를 생성합니다. 런타임에 이러한 변수는 동적 값으로 확장됩니다. 존재하지 않는 변수를 참조하는 경우 비어 있는 것으로 간주됩니다.

자세한 내용은 NGINX 단위 설명서의 변수를 참조하세요.

X-Forwarded-* 헤더에 대한 광범위한 지원

여러분이 요청하셨고, 우리는 그 결과를 제공해 드렸습니다. 버전 1.25.0부터 NGINX Unit은 리스너에 대한 일부 TLS 구성 기능을 제공했으며 여기에는 X-Forwarded-* 인식 수준이 포함됩니다. 이제 리스너에 대한 구성에서 클라이언트 IP 주소와 프로토콜 대체를 구성할 수 있습니다.

{
"listeners": {
"*:80": {
"pass": "routes/my-app",
"forwarded": {
"client_ip": "X-Forwarded-For",
"프로토콜": "X-Forwarded-Proto",
"재귀적": 거짓,
"소스": [
"198.51.100.1-198.51.100.254",
"!198.51.100.128/26",
"203.0.113.195"
]
}
}
},
...
}

메모: 이 새로운 구문은 이전 client_ip 구문을 더 이상 사용하지 않으며, 해당 구문은 향후 릴리스에서 제거될 예정입니다.

자세한 내용은 NGINX 단위 설명서의 IP, 프로토콜 전달을 참조하세요.

개편된 주식 옵션

NGINX Unit 버전 1.11.0에서는 정적 콘텐츠를 제공하기 위한 공유 라우팅 옵션이 도입되었습니다. 이는 NGINX의 root 지시문과 비슷합니다.

{
"공유": "/경로/디렉토리/"
}

처음에는 공유 옵션이 문서 루트 디렉토리를 지정했습니다. 어떤 파일을 제공할지 결정하기 위해 Unit은 요청의 URI를 이 공유 경로에 추가하기만 했습니다. 예를 들어, /some/file.html 에 대한 간단한 GET 요청에 대한 응답으로 Unit은 /path/to/dir/some/file.html을 제공했습니다. 그래도 우리는 파일 경로를 보다 정교하게 제어해야 하는 문제에 계속 부딪혔고, 결국 발전하기로 결정했습니다. 1.26.0 버전부터 공유 옵션은 문서 루트만이 아니라 공유 파일의 전체 경로를 지정합니다.

특정 파일을 제공하고 싶으신가요? 괜찮은:

{
"공유": "/path/to/a/file.html"
}

경로 내에서 변수를 사용하시겠습니까? 좋아요, 문제없어요:

{
"공유": "/www/data/$host/app.html"
}

하지만 NGINX와 이전 Unit 버전에서 이미 익숙해진 동작을 어떻게 모방할 수 있을까요? 몇 문단 전에 우리가 더 이상 필요 없다고 판단했던 문서 루트를 아시죠? 우리는 해결책을 가지고 있습니다.

이제 다음과 같이 구성을 다시 작성할 수 있습니다.

{
"공유": "/www/data/"
}

다음과 같이 요청된 URI를 경로에 명시적으로 추가합니다!

{
"공유": "/www/data/$uri"
}

마지막으로, 공유 지시문은 이제 경로 배열을 허용하여 파일을 찾을 때까지 하나씩 시도할 수 있습니다.

{
"공유": [
"/www/$host$uri",
"/www/static$uri",
"/www/app.html"
]
}

파일이 발견되지 않으면 라우팅은 다음으로 전달됩니다. 폴백 행동; 만약 없다면 폴백, 그 404 (아니다 설립하다) 상태 코드가 반환됩니다.

자세한 내용은 NGINX 단위 설명서의 정적 파일을 참조하세요.

계획: njs, URI Rewrite, Action Chaining, OpenAPI

이 글을 읽는 동안, 우리는 이미 다음 릴리스를 위해 작업 중입니다. 우리가 준비한 것을 살짝 보여드리겠습니다.

첫째, NGINX Unit을 NGINX JavaScript 모듈( njs )과 통합합니다. NGINX에서 활발히 개발 중인 또 다른 워크호스 프로젝트입니다. 간단히 말해서, 이는 NGINX Unit이 JavaScript 모듈 호출을 지원한다는 것을 의미합니다. 다음 사항을 고려하세요.

var hellonjs = {}

hellonjs.hello = 함수(vars) {
    if (vars의 'unitvar') {
        vars.unitvar를 반환합니다;

    } 또 다른 {
        '기본값'을 반환합니다.
    }
}

기본 hellonjs 내보내기

NGINX Unit에서 모듈을 가져온 후에는 구성을 통해 멋진 작업을 할 수 있습니다.

{ "match": { "uri": "~(?.*)" }, "action": { "share": "`/www/html${hellonjs.hello(vars)} `" } }

또한, 우리는 늘 인기 있는 NGINX 재작성 지시어와 유사한 것을 도입하는 것을 목표로 하고 있습니다.

{
"match": {
"uri": "/app/old_path"
},

"action": {
"rewrite": "/app/new_path",
"pass": "routes"
}
}

하지만 우리의 계획은 거기서 끝나지 않습니다. NGINX 단위의 라우팅을 앱 자체의 출력에 연결하는 것(일명 액션 체이닝)은 어떨까요?

{
"action": [
{
"pass": "applications/auth_check"
},
{
"pass": "applications/my_app"
}
]
}

여기서 아이디어는 auth_check 앱이 들어오는 요청을 인증하고 결과를 나타내는 상태 코드를 반환한다는 것입니다. 인증이 성공하면,200 OK 가 반환되고 요청은 my_app 으로 전달됩니다.

한편, 우리는 NGINX Unit의 API와 정확한 기능을 한꺼번에 정의하기 위한 OpenAPI 사양을 작업하고 있습니다. 우리에게 행운을 빌어주세요. 이건 엄청난 사업이거든요.

그래도 호기심이 충족되지 않는다면, 저희의 계획을 세부적으로 분석한 로드맵을 참조하세요. 대화형이어서 독자 여러분의 의견을 환영합니다.