Nginx Configuration (1/2)

Nginx Configuration 이해하기

 Nginx는 웹 서버 및 리버스 프록시로 사용되는 오픈소스 소프트웨어로, 그 구성 파일은 웹 서버 및 프록시 서버의 동작을 제어하는 중요한 부분이다. Nginx의 Configuration 파일은 일반적으로 nginx.cof라는 이름으로 저장되며, 여러 가지 구성 요소와 용어가 포함되어 있다.  Nginx의 Configuration 파일에서 Directive와 Context는 중요한 개념이다. 이 두 가지에 대해서 자세히 알아보자.

 

Directive

listen 80;
server_name mydomain.com;
root /var/www/html;
location /images/ {
    alias /var/www/images/;
}

Directive는 Nginx Configuration 파일에서 명령 또는 설정을 정의하는 요소이다. Directive는 directive_name directive_value 형식을 가지고 위의 listen, server_name, root, location. 등은 모든 다른 Directive를 나타낸다.

• listen: 웹 서버가 수신 대기할 포트를 설정한다.
• server_name: 가상 호스트를 식별하는데 사용된다.
• root: 웹 문서의 루트 디렉터리를 설정한다.
• location: 특정 URL 경로에 대한 지시자 그룹을 정의한다.
• upstream: server 설정에서 Nginx가 받아들인 요청을 어떤 서버로 흘려보낼 줄 것인지 결정할 때 사용된다. 이를 통해 로브 밸런싱을 구성하여 서버를 분산시킬 수 있다.

 

Context

Context는 Directive가 적용되는 범위를 나타낸다. Nginx Configuration 파일은 여러 수준의 컨텍스트를 포함하며, 주요 컨텍스트는 다음과 같다.

• http 컨텍스트: 전체 웹 서버의 설정을 나타낸다. 예를 들어, HTTP 리퀘스트 처리에 관한 전역 설정을 정의할 수 있다.
• server 컨텍스트: 가상 호스트에 대한 설정을 포함한다. 하나의 Nginx 인스턴스에서 여러 개의 가상 호스트를 호스팅할 때 사용된다.
• location 컨텍스트: 특정 URL 경로 또는 패턴에 대한 설정을 정의한다. 다양한 요청 경로에 대한 서버의 동작을 세부적으로 제어할 수 있다.

 

server {
    listen 80;
    server_name mydomain.com;
    location / {
    	root /var/www/html;
    }
}

각 컨텍스트는 중괄호({})로 둘러싸여 있으며, 그 안에서 Directive와 Directive 그룹이 포함된다. 위의 server 컨텍스트 내에 listen, server_name, location이 포함된 것을 확인할 수 있다. 컨텍스트는 계층적 구조를 가지며, 내부 컨텍스트는 외부 컨텍스트의 설정을 재정의하여 세밀하게 조정이 가능하다.

 

Virtual Host 만들기

Nginx에서 가상 호스트는 하나의 웹 서버 인스턴스에서 여러 독립적인 웹 사이트 또는 애플리케이션을 호스팅하기 위한 개념이다. 이를 통해 하나의 물리적 서버 또는 가상 머신에서 여러 개의 도메인 또는 서브도메인을 처리하고 관리할 수 있다. 각각의 가상 호스트는 고유한 도메인 또는 IP 주소와 연결되어 있다.

 

먼저, 해당 폴더 위치에 index.html 파일과 style.css 파일을 생성하자.

 

nginx.conf 수정

Nginx 웹 서버의 설정 파인인 nginx.conf 파일을 수정하자. HTTP 컨텍스트를 정의하고 80번 포트에서 들어오는 요청을 처리하도록 설정했다. 그리고 웹 서버가 어떤 도메인 이름 또는 호스트 이름을 인식하고 처리할지 가상 호스트를 설정하는데 사용하는 server_name과 웹 서버의 문서 루트 디렉터리를 설정하는 root Directive를 설정했다.

 

sudo nginx -t 명령어를 통해 Nginx 구성 파일에 대한 구문 오류 및 논리적 오류를 확인하고, 구성 파일이 올바르게 작성되었는지 확인할 수 있다. 유효성 검사를 통과하면 위처럼 메시지가 출력되는 것을 확인할 수 있다.

 

그리고 위처럼 sudo systemctl reload nginx로 다시 리로드 시키면 아까 만들었던 /sites/demo/index.html와 /sites/demo/style.css 파일을 응답하는 것을 확인할 수 있다. 

 

types Directive

 

curl -I url 명령은 HTTP 요청을 보내고 웹 서버의 응답 헤더를 확인할 수 있다. style.css 파일을 요청했을 때의 Content-Type에는 "text/plain"으로 값을 설정되어 있다. MIME 타입에서 "text/css"는 css 파일을 나타내는데 MIME 타입에 맞게 Content-Type을 응답하도록 설정 파일을 수정하자.

 

참고: MIME Type
웹 서버가 클라이언트에게 전송하는 파일의 형식을 정의하며, 이것은 클라이언트 브라우저가 적절한 방식으로 파일을 해석하고 표시하는데 중요한 역할을 한다.

 

vim /etc/nginx/mime.types 명령을 통해 해당 파일을 보면 types 블록이 있는 것을 확인할 수 있다. types 블록은 MIME 유형과 관련된 설정을 정의하는데 사용된다. types 블록을 구성 파일인 nginx.conf 파일에 포함시키기 위해서는 include 지시자를 사용하면 된다.

 

다시 curl -I 명령어를 통해 응답 헤더를 확인해보면 Content-Type 필드값으로 text/css로 설정된 것을 확인할 수 있다.

 

Location Blocks

location 블록을 통해 특정 URL 경로 또는 패턴에 대한 설정을 정의할 수 있다. 다양한 요청 경로에 대한 서버의 동작을 세부적으로 제어하여 특정 경로에 대한 정적 파일 제공, 프록시 설정, 리다이렉션, 인증 등 다양한 요청 처리 작업을 수행할 수 있다.

 

Prefix Match

Prefix Match는 가장 넓은 범위의 location 블록 유형이다. 요청된 URL 경로가 location 블록 내의 경로와 접두사로 일치하는 경우 해당 location 블록이 일치한다.

 

결과

 

Exact match

Exact Match는 요청된 URL 경로가 location 블록 내의 경로와 정확히 일치하는 경우 해당 locatino 블록과 일치한다.

 

결과

 

REGEX match(Tilde Prefix Match, Tilde and Asterisk Prefix Match)

정규 표현식을 사용하여 요청된 URL 경로를 패턴에 따라 매치시키는 데 사용된다. 정규 표현식을 사용하면 더 정교한 경로 일치 규칙을 젖의할 수 있으며, 동적 콘텐츠 또는 특정 경로 패턴에 대한 라우팅에 유용하다. 위 '~'만 사용하는 경우에는 대소문자를 구분하지만 ~*를 사용하는 경우에는 대소문자를 구분하지 않는다.

 

결과

 

Caret and Tilde Prefix Match

^~ 모드는 주어진 URL 경로가 지정된 접두사와 정확히 일치할 때 해당 location 블록이 선택된다. 이 모드에서는 정규표현식이 사용되지 않으며, 정확한 경로 기반의 일치를 검색한다.

 

결과

 

경로 일치 모드의 우선순위

1. Exact Math(=)
2. Caret and Tilde Prefix Match(^~)
3. Tilde Prefix Match(~)
4. Tilde and Asterisk Prefix Match(~*)
5. Prefix Match(기본)

우선순위는 상위에서 하위로 내려갈수록 낮아지며, 가장 구체적인 패턴이 먼저 일치하게 된다.

 

Variables

Nginx에서 변수는 동적 콘텐츠 생성, 로깅, 리다이렉션 및 조건부 구성과 같은 다양한 용도로 사용되는 중요한 요소이다. Nginx 변수는 $로 시작하며 서버 환경, 요청 정보 및 사용자 정의 데이터를 포함할 수 있다. 크게 Configuration Variables와 Nginx Module Variables로 나눌 수 있다.

 

Configuration Variables

set $var 'something';

Nginx의 set 모듈을 사용하여 사용자 정의 변수를 만들 수 있다. 이를 통해 중간 계산, 조건부 로깅 또는 요청 처리에 사용할 수 있는 임시 변수를 정의할 수 있다. 위 예시는 $var라는 사용자 정의 변수에 'something' 문자열이 할당된 것이다.

 

Nginx Module Variables

Nginx는 다양한 내장 변수를 제공한다. 이러한 내장 변수는 요청과 관련된 정보를 추출하거나 서버 환경에 관한 정보를 제공하는 데 사용된다. $http, $uri, $args 등이 있으며 https://nginx.org/en/docs/varindex.html 에서 확인할 수 있다.

 

Variables 사용해보기

if 지시문을 통해 요청의 쿼리 매개변수 중에서 apikey의 값이 1234가 아닌 경우 401 Unauthorized 응답을 반환하는 조건문이다. 이를 통해 API 키의 유효성을 확인할 수 있다. set을 통해서 $date_local 내장 변수에서 Saturday나 Sunday인 경우에는 'YES'를 아닌 경우에는 'No'를 할당하도록 작성할 수 있다. 그리고 $arg_를 통해서 쿼리 매개변수의 값을 가져올 수 있다.

 

결과

 

Rewrites & Redirects

Nginx에서 리다이렉트와 리라이트는 클라이언트의 요청을 수정하거나 다른 URL로 보내는 요청 경로의 수정, 도메인 이름 변경, HTTP와 HTTPS 간 전환 등에 사용되는 중요한 기능이다. 

 

Redirects

리다이렉트는 클라이언트의 요청을 새로운 URL로 보내는 프로세스를 나타낸다. 주로 다음과 같은 상황에서 사용된다.

• 도메인 이름 변경: 이전 도메인에서 새 도메인으로 요청을 보내는 경우에 이전 도메인에 대한 요청을 새 도메인으로 리다이렉트할 수 있다.
• HTTP와 HTTPS 간 전환: 암호화된 HTTPS 연결을 요청하지 않은 경우 HTTP에서 HTTPS로 리다이렉트할 수 있다.
• URL 경로 수정: 특정 경로의 요청을 다른 경로로 리다이렉트하는 경우에 사용할 수 있다.

리다이렉트를 수행하기 위해 Nginx에서 return 또는 rewrite 지시문을 사용할 수 있다. return 지시문은 단순한 리다이렉트를 수행하고 rwrite 지시문은 더 복잡한 패턴 일치 및 수정을 수행할 수 있다. 위 특징들을 보면 알 수 있듯이 리다이렉트의 경우에 URL이 변경된다.

 

Rewrite

리라이트는 클라이언트의 요청 URL을 변경하거나 다른 경로로 라우팅하는 프로세스를 나타낸다. 주로 다음과 같은 상황에서 사용된다.

• URL 경로 수정: 요청된 URL 경로를 변경하는 경우에 /old-path로 들어온 요청을 /new-path로 리라이트할 수 있다.
• 파라미터 재작성: 요청 URL의 쿼리 매개변수를 수정하거나 새로운 파라미터를 추가할 수 있다.

리라이트 작업을 위해 Nginx에서 rewrite 지시문을 사용할 수 있고, 이 지시문은 정규 표현식을 기반으로 일치하는 URL을 수정할 수 있다.

 

Rewrite와 Redirect 사용해보기

rewrite ^/user/(\w+) /greet/$1;는 /user/ 다음에 문자나 숫자가 있는 요청을 /greet/로 리라이트한다. $1은 이전 정규 표현식에서 캡처한 그룹을 의미한다. location은 우선순위에 따라 Exact Match가 먼저 그 뒤에 가장 우선순위가 낮은 Prefix Match로 요청을 처리한다.

 

 

결과

 

출처

NGINX Fundamentals: High Performance Servers from Scratch