기본 기능(Basic Functionality)

NGINX STORE > Docs > NGINX Documentation > 기본 기능(Basic Functionality)

구성 파일 구문 및 런타임 제어를 포함하여 NGINX 및 NGINX Plus의 기본 기능을 설명하는 문서입니다.

런타임 시 NGINX 프로세스 제어

트래픽을 처리하는 NGINX 프로세스와 런타임에 이를 제어하는 ​​방법을 이해합니다.

이 섹션에서는 NGINX가 런타임에 시작하는 프로세스와 이를 제어하는 ​​방법에 대해 설명합니다.

Master 및 Worker 프로세스

NGINX에는 하나의 master 프로세스와 하나 이상의 worker 프로세스가 있습니다. 캐싱이 활성화된 경우 cache loader 및 cache manager 프로세스도 시작 시 실행됩니다.

master 프로세스의 주요 목적은 구성 파일을 읽고 평가하고 worker 프로세스를 유지 관리하는 것입니다.

worker 프로세스는 요청의 실제 처리를 수행합니다. NGINX는 OS 종속 메커니즘에 의존하여 worker 프로세스 간에 요청을 효율적으로 분산합니다. worker 프로세스의 수는 nginx.conf 구성 파일의 worker_processes 지시문에 의해 정의되며 고정된 수로 설정하거나 사용 가능한 CPU 코어 수에 자동으로 조정되도록 구성할 수 있습니다.

NGINX 제어

구성을 다시 로드하려면 NGINX를 중지 또는 다시 시작하거나 master 프로세스에 신호를 보낼 수 있습니다. -s 인수와 함께 nginx 명령(NGINX 실행 파일 호출)을 실행하여 신호를 보낼 수 있습니다.

nginx -s <SIGNAL>

여기서 <SIGNAL> 다음 중 하나가 될 수 있습니다.

  • quit – 정상적으로 종료( SIGQUIT신호)
  • reload – 구성 파일( SIGHUP시그널) 다시 로드
  • reopen – 로그 파일 다시 열기( SIGUSR1신호)
  • stop – 즉시 종료(또는 빠른 종료, SIGTERM신호)

kill 유틸리티를 사용하여 master 프로세스에 직접 신호를 보낼 수도 있습니다. master 프로세스의 프로세스 ID는 기본적으로 /usr/local/nginx/logs 또는 /var/run 디렉토리에 있는 nginx.pid 파일에 기록됩니다.

NGINX Plus 및 NGINX 구성 파일 생성

지시문 및 컨텍스트를 포함하여 NGINX 또는 NGINX Plus 구성 파일의 기본 요소를 이해합니다.

NGINX 및 NGINX Plus는 특정 형식으로 작성된 텍스트 기반 구성 파일을 사용한다는 점에서 다른 서비스와 유사합니다. 기본적으로 파일 이름은 nginx.conf이며 NGINX Plus의 경우 /etc/nginx 디렉토리에 있습니다. (NGINX 오픈소스의 경우 위치는 NGINX를 설치하는 데 사용되는 패키지 시스템과 운영 체제에 따라 다릅니다. 일반적으로 /usr/local/nginx/conf, /etc/nginx 또는 /usr/local/etc/nginx 중 하나입니다.)

지시문(Directives)

구성 파일은 지시문(directives)과 해당 매개변수로 구성됩니다. 단순(한 줄) 지시문은 각각이 세미콜론으로 끝납니다. 다른 지시문은 관련 지시문을 함께 그룹화하여 중괄호( {} )로 묶는 “컨테이너” 역할을 합니다. 이들은 종종 블록(blocks)이라고 합니다. 다음은 간단한 지시문에 대한 몇 가지 예입니다.

user             nobody;
error_log        logs/error.log notice;
worker_processes 1;

기능별 구성 파일

구성을 유지 관리하기 쉽게 하려면 /etc/nginx/conf.d 디렉토리에 저장된 기능별 파일 세트로 분할하고 기본 nginx.conf 파일의 include 지시문을 사용하여 내용을 참조하는 것이 좋습니다. 기능별 파일.

include conf.d/http;
include conf.d/stream;
include conf.d/exchange-enhanced;

컨텍스트(Contexts)

컨텍스트(contexts)라고 하는 몇 가지 최상위 지시문(directives)은 서로 다른 트래픽 유형에 적용되는 지시문을 그룹화합니다.

  • events – 일반 연결 처리
  • http – HTTP 트래픽
  • mail – 메일 트래픽
  • stream – TCP 및 UDP 트래픽

이러한 컨텍스트 외부에 배치된 지시문은 main 컨텍스트에 있다고 합니다 .

가상 서버(Virtual Server)

각 트래픽 처리 컨텍스트에서 하나 이상의 server 블록을 포함하여 요청 처리를 제어하는 가상 서버를 정의합니다. 서버 컨텍스트에 포함할 수 있는 지시문은 트래픽 유형에 따라 다릅니다.

HTTP 트래픽(http 컨텍스트)의 경우 각 서버 지시문은 특정 도메인 또는 IP 주소의 리소스 요청 처리를 제어합니다. 서버 컨텍스트에서 하나 이상의 위치 컨텍스트는 특정 URI 세트를 처리하는 방법을 정의합니다.

메일 및 TCP/UDP 트래픽(메일 및 스트림 컨텍스트)의 경우 서버 지시문은 각각 특정 TCP 포트 또는 UNIX 소켓에 도달하는 트래픽 처리를 제어합니다.

여러 컨텍스트가 있는 샘플 구성 파일

다음 구성은 컨텍스트 사용을 보여줍니다.

user nobody; # a directive in the 'main' context

events {
    # configuration of connection processing
}

http {
    # Configuration specific to HTTP and affecting all virtual servers  

    server {
        # configuration of HTTP virtual server 1       
        location /one {
            # configuration for processing URIs starting with '/one'
        }
        location /two {
            # configuration for processing URIs starting with '/two'
        }
    } 
    
    server {
        # configuration of HTTP virtual server 2
    }
}

stream {
    # Configuration specific to TCP/UDP and affecting all virtual servers
    server {
        # configuration of TCP virtual server 1 
    }
}

계승(Inheritance)

일반적으로 일반적으로 다른 컨텍스트(부모)에 포함된 자식 컨텍스트는 부모 수준에 포함된 지시문 설정을 상속합니다. 일부 지시문은 여러 컨텍스트에 나타날 수 있으며, 이 경우 자식 컨텍스트에 지시문을 포함하여 부모로부터 상속된 설정을 재정의할 수 있습니다. 예는 proxy_set_header 지시문을 참조하십시오.

구성 다시 로드(Reloading Configuration)

구성 파일에 대한 변경 사항을 적용하려면 다시 로드해야 합니다. nginx 프로세스를 다시 시작하거나 reload 신호를 보내 현재 요청 처리를 중단하지 않고 구성을 업그레이드할 수 있습니다. 자세한 내용은 런타임 시 NGINX 프로세스 제어를 참조하세요.

NGINX Plus를 사용하면 구성을 다시 로드하지 않고도 업스트림 그룹의 서버 간에 로드 밸런싱을 동적으로 재구성할 수 있습니다. NGINX Plus API 및 key-value store를 사용하여 예를 들어 클라이언트 IP 주소를 기반으로 액세스를 동적으로 제어할 수도 있습니다.