초보자 가이드

이 가이드는 nginx에 대한 기본적인 소개와 이를 활용할 수 있는 간단한 작업을 안내합니다. nginx가 이미 컴퓨터에 설치되어 있어야하며, 아직 설치되지 않은 경우, nginx 설치 페이지를 참조하세요. 이 가이드에서는 nginx를 시작하고 중단하는 방법, 구성을 다시 로드하는 방법, 구성 파일의 구조 설명, nginx가 정적 콘텐츠를 제공하도록 설정하는 방법, nginx를 프록시 서버로 구성하는 방법, FastCGI 애플리케이션과 연결하는 방법에 대해 설명합니다.

nginx는 마스터 프로세스 1개와 여러 개의 작업자 프로세스로 구성됩니다. 마스터 프로세스의 주 목적은 구성을 읽고 평가하고, 작업자 프로세스를 관리하는 것입니다. 요청을 실제로 처리하는 것은 작업자 프로세스입니다. nginx는 이벤트 기반 모델과 OS 종속적 메커니즘을 사용하여 작업자 프로세스에 요청을 효율적으로 분배합니다. 작업자 프로세스 수는 구성 파일에서 정의되고, 구성에 따라 수정되거나 사용 가능한 CPU 코어에 맞게 자동으로 조정됩니다(worker_processes 참조).

nginx 및 모듈이 작동하는 방식은 구성 파일에서 정의됩니다. 기본적으로 구성 파일 이름은 nginx.conf로 지정되고, /usr/local/nginx/conf, /etc/nginx 또는 /usr/local/etc/nginx 디렉터리에 저장됩니다.

구성 시작, 중단 및 리로드

nginx를 시작하려면 실행 파일을 실행합니다. nginx가 시작되면 -s 매개변수로 실행 파일을 호출하여 제어할 수 있습니다. 다음의 구문을 사용하세요.

nginx -s signal

signal은 다음 중 하나일 수 있습니다.

• stop — 빠른 종료
• quit — 점진적 종료
• reload — 구성 파일 다시 로드하기
• reopen — 로그 파일 다시 열기

예를 들어 작업자 프로세스가 현재 요청을 서비스하는 것을 종료하기를 기다렸다가 nginx 프로세스를 종료하려면 다음의 명령을 사용할 수 있습니다.

nginx -s quit

이 명령은 nginx를 시작한 사용자로 실행해야 합니다.

구성 파일의 변경 사항은 구성 파일을 다시 로드하는 명령을 nginx에 보내거나 다시 시작해야 적용됩니다. 구성 파일을 다시 로드하려면 다음을 실행합니다.

nginx -s reload

마스터 프로세스에서 구성을 다시 로드하라는 신호를 받으면 새로운 구성 파일의 구문 유효성을 검사하여 구성에 적용하려고 시도합니다. 구성에 성공적으로 적용되면 마스터 프로세스가 새 작업자 프로세스를 시작하고, 이전 작업자 프로세스에 종료를 요청하는 메시지를 보냅니다. 실패할 경우, 마스터 프로세스가 변경 사항을 롤백하고 기존 구성을 계속 사용합니다. 이전 작업자 프로세스는 종료 명령을 받으면 새로운 연결 수신을 중단하고, 모든 요청의 서비스가 완료될 때까지 기존 요청을 서비스합니다. 그 이후에 기존 작업자 프로세스가 종료됩니다.

Unix 도구(예: kill 유틸리티)를 사용하면 nginx 프로세스로 신호를 보낼 수 있습니다. 이 경우, 신호는 특정 프로세스 ID를 가진 프로세스로 직접 전송됩니다. nginx 마스터 프로세스의 프로세스 ID는 기본적으로 /usr/local/nginx/logs 또는 /var/run 디렉터리의 nginx.pid에 작성됩니다. 예를 들어 마스터 프로세스 ID가 1628일 경우, QUIT 신호를 보내서 nginx를 서서히 종료하려면 다음을 실행하세요.

kill -s QUIT 1628

실행 중인 모든 nginx 프로세스 목록을 가져오려면 다음과 같이 ps 유틸리티를 사용할 수 있습니다.

ps -ax | grep nginx

nginx에 신호를 보내기 위한 자세한 정보는 nginx 제어를 참조하세요.

구성 파일의 구조

nginx는 구성 파일에 지정된 명령으로 제어되는 모듈로 구성됩니다. 명령은 단순 명령과 블록 명령으로 나뉩니다. 단순 명령은 공백으로 구분된 이름과 매개변수로 구성되어 있으며, 세미콜론(;)으로 끝납니다. 블록 명령은 단순 명령과 구조는 동일하지만 세미콜론이 아니라 중괄호({ 및 })로 감싼 추가적 명령 세트로 종료됩니다. 블록 명령의 괄호 안에 다른 명령이 들어갈 경우, 이를 컨텍스트라 합니다(예: events, http, server, location).

구성 파일에서 컨텍스트 외부에 존재하는 명령은 main 컨텍스트로 간주합니다. events 및 http 명령은 main 컨텍스트에 있고, server는 http에 있으며, location은 server에 있습니다.

# 기호 이후의 나머지 행은 주석으로 간주됩니다.

정적 콘텐츠 제공

중요한 웹 서버 작업은 파일(예: 이미지,정적 HTML 페이지)을 서비스합니다. 요청에 따라 각 로컬 디렉터리에서 파일을 서비스하는 /data/www(HTML 파일 포함)와 /data/images(이미지 포함)의 예시를 구현해보겠습니다. 그러려면 구성 파일을 편집하고, http 블록 내의 server 블록을 두 개의 location 블록으로 설정해야 합니다.

먼저 /data/www 디렉터리를 만들고 index.html 파일에 아무 텍스트를 넣은 다음, /data/images 디렉터리를 만들어 몇 개의 이미지를 넣습니다.

그런 다음 구성 파일을 엽니다. 기본 구성 파일에는 이미 server 블록의 여러 예시가 포함되어 있으며, 대부분은 주석 처리되어 있습니다. 이제 모든 해당 블록을 주석처리하고 새 server 블록을 시작합니다.

http {
    server {
    }
}

일반적으로 구성 파일에는 여러 server 블록이 포함되고, 수신하는 포트와 서버 이름을 기준으로 구분합니다. nginx에서 어떤 server가 요청을 처리할지 결정하고 나면, 요청 헤더에서 지정된 URI를 server 블록 안에 정의된 location 명령 매개변수에 대해 테스트합니다.

다음의 location 블록을 server 블록에 추가합니다.

location / {
    root /data/www;
}

이 location 블록은 요청의 URI와 비교하여 “/” 접두사를 지정합니다. 요청이 일치할 경우, URI는 root 디렉터리에 지정된 경로(즉, /data/www)에 추가되어 로컬 파일 시스템에서 요청한 파일의 경로를 구성합니다. 일치하는 location 블록이 여러 개일 경우, nginx에서 접두사가 가장 긴 블록을 선택합니다. 위의 location 블록은 가장 짧은 접두사를 제공하므로, 다른 모든 location 블록이 일치하지 않아야 이 블록을 사용합니다.

다음으로 두 번째 location 블록을 추가합니다.

location /images/ {
    root /data;
}

/images/로 시작하는 요청에 대한 매칭이 됩니다(location /도 이러한 요청에 매칭되지만 접두사가 더 짧습니다).

이 결과로 얻는 server 블록의 구성은 다음과 같습니다.

server {
    location / {
         root /data/www;
    }
    
    location /images/ {
         root /data;
    }
}

이는 표준 포트 80을 수신하는 서버에서 이미 작동하는 구성이며, http://localhost/에서 로컬 컴퓨터에 액세스할 수 있습니다. /images/로 시작하는 URI를 포함하는 요청을 받으면 서버는 /data/images 디렉터리에서 파일을 전송합니다. 예를 들어 nginx는 http://localhost/images/example.png 요청에 응답하여 /data/images/example.png 파일을 전송합니다. 이러한 파일이 존재하지 않을 경우, nginx가 404 오류를 나타내는 응답을 보냅니다. /images/로 시작하지 않는 URI를 포함한 요청은 /data/www 디렉터리에 매핑됩니다. 예를 들어 nginx는 http://localhost/some/example.html 요청에 응답하여 /data/www/some/example.html 파일을 전송합니다.

새 구성을 적용하려면 nginx를 시작하세요. 아직 시작하지 않았다면 다음을 실행하여 reload 신호를 nginx의 마스터 프로세스로 보내세요.

nginx -s reload

예상과 다르게 작동하는 경우, /usr/local/nginx/logs 또는 /var/log/nginx 디렉터리의 access.log 및 error.log 파일에서 이유를 찾아보세요.

단순 프록시 서버 설정

ngnix는 주로 프록시 서버를 설정하는 데 사용합니다. 즉, 프록시 서버란 요청을 받아서 프록시된 서버로 전달하고, 여기에서 응답을 조회해 클라이언트로 보내는 서버를 의미합니다.

이제 기본 프록시 서버를 구성하겠습니다. 로컬 디렉터리에 있는 파일을 포함한 이미지에 대한 요청을 서비스하고, 그 외에 다른 요청은 프록시된 서버로 전송합니다. 이 예시에서는 두 서버를 하나의 nginx 인스턴스에서 정의할 것입니다.

먼저 server 블록을 하나 더 nginx 구성 파일에 추가하여 다음과 같은 내용으로 프록시된 서버를 정의합니다.

server {
    listen 8080;
    root /data/up1;

    location / {
    }
}

이 서버는 포트 8080을 수신하고(전에는 표준 포트 80을 사용했기 때문에 listen 명령이 지정되지 않음) 로컬 파일 시스템에 /data/up1 디렉터리로 모든 요청을 매핑하는 단순 서버가 됩니다. 이 디렉터리를 생성하고 index.html 파일을 넣습니다. root 명령은 server 컨텍스트에 배치됩니다. 이런 root 명령은 요청을 서비스하도록 선택한 location 블록에 root 명령을 포함하지 않을 때 사용합니다.

이제 앞의 섹션에서 나온 서버 구성을 사용하여 프록시 서버 구성으로 수정합니다. 첫 번째 location 블록에서 매개 변수에 지정된 프록시 서버의 프로토콜, 이름 및 포트를 가진 proxy_pass 지시문을 넣습니다. (이 예시에서는 http://localhost:8080).

server {
    location / {
        proxy_pass http://localhost:8080;
    }
    localtion /images/ {
        root /data;
    }
}

두 번째 location 블록을 수정하겠습니다. 이 블록은 현재 /images/ 접두사가 있는 요청을 /data/images 디렉터리의 파일에 매핑하여 일반적 파일 확장자를 사용하는 이미지로 구성된 요청과 매칭합니다. 수정된 location 블록은 다음과 같습니다.

location ~ \.(gif/jpg/png)$ {
    root /data/images;
}

이 매개변수는 .gif, .jpg 또는 .png로 인코딩되는 모든 URI를 매칭하는 정규식입니다. 정규식에는 ~을 붙여야 합니다. 해당 요청은 /data/images 디렉터리에 매핑됩니다.

nginx에서 요청을 서비스할 location 블록을 선택하면 먼저 접두사를 지정하는 location 명령을 검사한 후, 가장 접두사가 긴 location을 기억하고 정규식을 검사합니다. 정규식과 매치가 있을 경우, nginx가 이 location을 선택합니다. 그렇지 않을 경우 앞서 기억한 위치를 선택합니다.

이 결과로 얻는 프록시 서버 구성은 다음과 같습니다.

server {
    location / {
        proxy_pass http://localhost:8080/;
    }

    location ~ \.(gif/jpg/png)$ {
        root /data/images;
    }
}

이 서버는 .gif, .jpg 또는 .png로 끝나는 요청을 필터링하고 (URI를 root 명령의 매개변수에 추가하여) /data/images 디렉터리에 매핑합니다. 그 외에 다른 요청은 위에서 구성한 프록시된 서버로 보냅니다.

새 구성을 적용하려면 reload 신호를 앞의 섹션에서 설명한 nginx로 전송합니다.

프록시 연결을 추가로 구성하는 데 사용할 수 있는 명령은 여러 가지가 있습니다.

FastCGI 프록시 설정

nginx를 사용하여 FastCGI 서버로 요청을 라우팅할 수 있습니다. 이 서버는 여러 가지 프레임워크와 프로그래밍 언어(예: PHP)로 구축한 애플리케이션을 실행합니다.

FastCGI에서 사용하는 가장 기본적인 nginx 구성에서는 proxy_pass 명령 대신 fastcgi_pass 명령을 사용하고, fastcgi_param 명령을 사용하여 FastCGI 서버에 전달된 매개변수를 설정합니다. FastCGI 서버를 localhost:9000에서 액세스할 수 있다고 가정해보겠습니다. 앞의 섹션에서 사용한 프록시 구성을 기본으로 삼아 proxy_pass 명령을 fastcgi_pass 명령으로 교체하고 이 매개변수를 localhost:9000으로 변경합니다. PHP에서 SCRIPT_FILENAME 매개변수는 스크립트 이름을 확인하는 데 사용합니다. QUERY_STRING 매개변수는 요청 매개변수를 전달하는 데 사용합니다. 그 결과로 얻는 구성은 다음과 같습니다.

server {
    location / {
        fastcgi_pass localhost:9000;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param QUERY_STRING $query_string;
    }

    location ~ \.(gif|jpg|png)$ {
        root /data/images;
    }
}

이 구성은 모든 요청을 라우팅하는 서버를 설정합니다. 단, FastCGI 프로토콜을 통해 localhost:9000에서 작동하는 프록시된 서버로 정적 이미지를 보내는 요청은 예외입니다.