NGINX Unit 1.31.0 릴리즈

NGINX Unit 1.31.0 버전을 발표하게 되어 기쁘게 생각합니다. NGINX Unit 을 위한 혁신적인 language 모듈을 개발하기 위해 열심히 노력했습니다. 이번 릴리즈의 일부로 Unit의 기능을 크게 향상시킬 수 있는 Unit WebAssembly(WASM) 기능을 소개하게 되어 기쁘게 생각합니다.

이번 릴리즈는 Unit의 WebAssembly 지원에 대한 기술 프리뷰이며, 커뮤니티에서 공유해 주실 사용 사례와 아이디어에 대해 더 많은 것을 배우게 되기를 기대합니다.

또한 이번 릴리즈에서는 response header를 전송하고 구성 내에서 response header 변수를 활용할 수 있는 기능도 새롭게 추가되었습니다. 이러한 개선 사항으로 인해 사용 가능한 유연성과 사용자 지정 옵션이 크게 늘어납니다.

이러한 주요 개선 사항과 더불어 다양한 사소한 버그 수정을 신중하게 처리하고 사용자 경험을 원활하게 개선하기 위해 추가적인 개선 사항을 도입했습니다:

• ASG lifespan_state에 Python 지원을 추가해준 최신 기여자 synodriver에게 감사드립니다.
• 이제 unitc CLI 툴에서 구성 URI의 대화형 편집 기능을 제공합니다.

목차

1. Server-Side WebAssembly: 기술 프리뷰
2. Response Header 작업
2-1. Response Header 설정
2-2. Response Header 변수 사용
3. NGINX Unit CLI 대화형 모드
4. NGINX Unit 전체 변경 로그

1. Server-Side WebAssembly: 기술 프리뷰

지난 2년 동안 WebAssembly 채택이 빠르게 증가했습니다. 이 새로운 바이너리 형식의 유연성은 놀라울 정도로 뛰어납니다. 특히 Server-Side WebAssembly는 애플리케이션 개발자에게 많은 이점을 제공합니다. Unit은 이미 다양한 프로그래밍 언어 런타임에 대한 기본 지원을 제공하고 있기 때문에 NGINX Unit에 Server-Side WebAssembly 지원을 추가하는 것은 자연스러운 과정이었습니다.

이제 Unit은 기본 애플리케이션 유형으로 WebAssembly 모듈을 실행할 수 있습니다. 블로그 포스트에서 자세히 알아보세요: NGINX Unit 의 Server-Side WebAssembly 기술 프리뷰 소개.

2. Response Header 작업

클라이언트로 다시 전송되는 HTTP response header를 완전히 제어할 수 있는 기능은 커뮤니티에서 오랫동안 기다려온 기능입니다. 1.31 에서는 Unit 라우터를 사용하여 HTTP response header를 추가, 제거 또는 재정의하고 전용 response header 변수의 값을 사용할 수 있는 기능이 추가됩니다. 1.31과 응답 헤더로 무엇을 할 수 있는지 살펴보겠습니다.

2-1. Response Header 설정

위에서 언급했듯이 Unit의 라우터를 사용하여 response header를 추가, 제거 또는 재정의할 수 있습니다. 대부분의 경우 라우터가 이미 사용 중일 것입니다. listener가 이와 같은 라우터 객체를 가리키면 사용할 수 있습니다.

{
    "listeners": {
        "*:80": {
            "pass": "routes"
        }
    }
}

Unit Routes를 처음 사용하시는 분은 이 새로운 기능을 살펴보기 전에 NGINX Unit 공식 문서를 확인하시기를 바랍니다.

간단한 사용 사례부터 시작하겠습니다. 웹 API 와 함께 프론트엔드를 호스팅하기 위해 Unit을 사용하고 있습니다. 이 경우 언어나 Unit 애플리케이션 객체는 크게 중요하지 않습니다. 현재 구성은 다음과 같습니다:

{
    "listeners": {
        "*:8080": {
            "pass": "routes/app"
        }
    },

    "routes": {
        "app": [
            {
                "match": {
                    "uri": [
                        "/api/*"
                    ]
                },

                "action": {
                    "pass": "applications/api"
                }
            },
            {
                "action": {
                    "share": [
                        "/var/www/frontend$uri",
                        "/var/www/frontend/index.html"
                    ]
                }
            }
        ]
    }
}

새로 도입된 response_headers 객체는 모든 action 객체에 추가할 수 있습니다. response_headers 객체는 key/value 쌍의 목록이 포함되어 있으며, 각 key/value 쌍은 단일 헤더를 정의합니다. 헤더 이름이 응답에 이미 존재하는 response header와 일치하면 해당 값이 대체됩니다. 그렇지 않으면 새 response header가 생성됩니다. 값이 null 이면 응답에서 헤더가 생략됩니다. 빈 문자열을 그렇지 않습니다. 이 모든 것이 무엇을 의미하는지 보여주기 위해 구성을 변경해 보겠습니다. 먼저 API 애플리케이션에서 보낸 X-Version 헤더를 숨기겠습니다:

{
    "action": {
        "pass": "applications/api",
        "response_headers": {
            "X-Version": null
        }
    }
}

프론트엔드에서는 소스를 파헤치지 않고도 배포된 버전을 식별할 수 있도록 버전 해시를 추가하려고 합니다:

{
    "action": {
        "share": [
            "/var/www/frontend$uri",
            "/var/www/frontend/index.html"
        ],
        "response_headers": {
            "X-FE-Version": "abc1234def"
        }
    }
}

"Upper-Case": "`${host.toUpperCase()}`"

2-2. Response Header 변수 사용

1.31과 response header 제어 기능이 추가되어 새로운 변수 집합이 추가되었습니다. Unit에서 호스팅되는 애플리케이션으로부터 응답을 수신하고 애플리케이션이 공유한 값을 기반으로 기존 response header를 수정하려는 경우, Unit이 해당 특정 값을 유지해야 합니다. 이때 새로 도입된 response header 변수가 중요한 역할을 합니다.

새 변수의 형식은 Unit이 라우터에서 이미 지원하는 다른 변수를 기반으로 합니다. 특정 HTTP 헤더의 값을 검색하려면 response_header를 key 식별자로 사용하고, 그 뒤에 ${} 로 묶인 name_of_the_header를 사용하면 됩니다. 요청 처리 중에 단위와 함께 변수를 처음 사용하는 경우 이 문서를 참조하여 자세히 알아보세요. 사용 사례 예시를 통해 이를 살펴보겠습니다.

다음 구성에서는 애플리케이션에서 이미 설정한 Content-Type response header에 문자셋을 추가하려고 합니다.

[
    {
        "action": {
            "pass": "applications/calc",
            "response_headers": {
                "Content-Type": "${response_header_content_type};charset=iso-8859-1"
            }
        }
    }
]

Content-Type 헤더가 응답에 이미 존재하므로 단위가 해당 값을 변경합니다.

3. NGINX Unit CLI 대화형 모드

1.29 에서는 Unit API와의 상호작용을 간소화하기 위해 curl용 래퍼 스크립트를 도입했습니다. 1.31에서는 이 스크립트에 대화형 편집 모드를 추가했습니다:

$ unitc EDIT /config

그러면 현재 $EDITOR에 정의된 에디터에서 지정된 엔드포인트의 JSON 구성이 열립니다. 대부분의 경우 기본값은 nano입니다. 다른 것을 사용하려면 vim과 같은 다른 것을 사용하세요:

$ EDITOR=vim unitc EDIT /config

4. NGINX Unit 전체 변경 로그

Changes with Unit 1.31.0                                         31 Aug 2023

    *) Change: if building with njs, version 0.8.0 or later is now required.

    *) Feature: technology preview of WebAssembly application module.

    *) Feature: "response_headers" option to manage headers in the action
       and fallback.

    *) Feature: HTTP response header variables.

    *) Feature: ASGI lifespan state support. Thanks to synodriver.

    *) Bugfix: ensure that $uri variable is not cached.

    *) Bugfix: deprecated options were unavailable.

    *) Bugfix: ASGI applications inaccessible over IPv6.

NGINX Unit 외에 NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 문의하십시오.

NGINX에 대한 최신 정보들을 빠르게 전달받고 싶으시다면, 아래의 뉴스레터를 구독하세요.