들어가며
NGINX를 사용하는데 있어 꼭 필요한 기초 개념들을 정리한 글입니다. 전반적인 기초를 다룬 뒤 NIGNX를 web server로 이용하는 방법에 초점을 두어 작성하였습니다. 또한 너무 자세한 내용은 다루지 않았습니다.
NGINX 시작, 종료, 재시작
NGINX의 파일을 invoke 하기 위해 -s 옵션을 사용합니다.
$ nginx -s [signal]
[signal]에는 다음 4가지 설정이 가능합니다.
- stop: fast shutdown
- quit: graceful shutdown - 이 명령어는 NGINX를 시작한 사람만 사용할 수 있습니다.
- reload: reloading config file
- reopen: reopening the log files
즉, 새로 바꾼 configuration 파일을 적용하고 싶다면 다음과 같이 이용해야 합니다.
$ nginx -s reload
물론 kill 과 같은 명령어를 이용하여 프로세스를 직접 종료할 수도 있습니다. 이때 NGINX의 PID는 /usr/local/nginx/logs 또는 /var/run 에서 확인할 수 있습니다.
Configuration File 구조 분석하기
NGINX의 기본 설정 파일은 nginx.conf 이며 다음 /usr/local/nginx/conf, /etc/nginx, or /usr/local/etc/nginx 경로 중 하나에 있습니다.
NGINX의 모듈들은 configuration 파일에 있는 directives에 의해 제어됩니다. 먼저 기본적으로 주어지는 nginx.conf 파일은 다음과 같이 생겼습니다.
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
events {
worker_connections 768;
# multi_accept on;
}
http {
...
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
directives에는 두 가지 종류가 있습니다. 위의 네 줄은 simple directive, 아래 { } 로 둘러쌓인 것은 block directive입니다.
simple directive
이름, 인자값이 있고 세미콜론(;)으로 끝납니다.
- user: linux 시스템의 어떤 사용자가 NGINX 서버를 동작시킬지 기술합니다.
- worker_processes: 몇 개의 thread가 사용될지 정의한다. CPU 코어 수에 맞추는 것이 권장됩니다.
- pid: NGINX pid가 적혀있는 파일입니다.
- include: 외부 configuration 내용을 가져옵니다. 모듈에 따라 다른 파일에 작성하고 include하는 것이 권장됩니다.
block directive
simple directive와 구성이 같지만 세미콜론 대신 추가적인 내용들이 { } 안에 들어갑니다. 위 예시에서 event 블럭과 http 블럭이 있습니다.
Include Configuration files
configuration 파일들을 쉽게 관리하기 위해 기능들 단위로 파일을 나눠 저장하는 것이 좋습니다. 파일을 /etc/nginx/conf.d 디렉토리에 저장한 후 include를 이용하여 configuration 파일을 불러옵시다. 이때, block directive 안에서 include를 쓸 경우, 해당 블럭 안에 파일 내용이 포함됩니다.
Context
block directive 안에 다른 directive가 들어가 있는 경우 context라고 하며, 대표적으로 events, http, server, location directive들이 있습니다. 바깥의 directive들은 main context 안에 있는 것으로 간주합니다.
- events: 일반적인 connection proecess를 담당합니다.
- http: HTTP traffic
- mail: Mail traffic
- stream: TCP and UDP traffic
Virtual Servers
트래픽을 다루는 context에서 request를 처리하기 위해 한 개 이상의 server block을 추가해야 합니다. 트래픽 타입에 따라 server context 안에 추가할 수 있는 directives들이 다릅니다.
가상 호스트란?
가상 호스트
http context 안에 있는 server directive는 특정 도메인이나 IP 주소로의 요청을 처리합니다. server context 안에 있는 location context가 특정 URI set을 어떻게 처리할지 정합니다.
다음은 전체 configuration file의 예시입니다.
user nobody; # a directive in the 'main' context
events {
# configuration of connection processing
worker_connections 768;
}
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
}
}
- worker_connections: worker process 하나 당 몇 개의 connection을 처리할지 정합니다.
- location: 처리할 URI 형식을 표시합니다.
directive 상속
하나의 context(부모) 안에 있는 또 다른 context(자식)는 상위 레벨의 directive들을 상속받습니다. 몇 가지 directives들은 여러 개의 context에서 동시에 나타날 수 있는데, 이럴 경우 자식 directive는 부모 설정을 override하게 됩니다.
Web Server로 NGINX 사용하기
가상 서버 세팅하기
NGINX configuration 파일에는 적어도 하나의 server directive가 있어야 합니다. NGINX가 요청을 처리할 때, 가장 먼저 요청을 처리할 virtual server를 선택합니다. 위 예시처럼 하나의 http context안에 여러 개의 server directive가 있을 수 있습니다. 보통 server configuration block에는 요청을 listen할 특정 IP address와 포트, 혹은 Unix domain socket과 path를 적어웁니다.
아래 예시는 IP 주소 127.0.0.1 과 포트 8080으로 listen하는 configuration입니다.
server {
listen 127.0.0.1:8080;
# The rest of server configuration
}
또는 server_name directive를 사용하여 도메인 명을 사용할 수도 있습니다. 이때 NGINX는 요청의 Host header의 필드값과 server_name을 비교하여 맞는 server를 찾습니다. server name으로는 wild card와 정규식 등을 사용할 수 있습니다.
server {
listen 80;
server_name example.org www.example.org;
...
}
Location 세팅하기
NGINX는 요청 URI에 따라 다른 서버로 트래픽을 전송합니다. 이는 server block 안의 location directive를 이용해 정할 수 있습니다. 여러 location 블럭을 사용할 수도 있고, location 안에 다른 location directive를 설정할 수도 있습니다.
location은 URI 경로의 일부인 prefix string이거나 정규식 표현이 될 수 있습니다. 다음 예시는 /some/path/document.html 과 같은 경로의 요청을 처리합니다.
location /some/path/ {
...
}
location context 안에 있는 directive는 요청을 어떻게 처리할지 정할 수 있습니다. static file을 보여주거나 proxy server로 요청을 전송합니다. 다음 예시의 첫 번째 location context와 일치하는 패턴은 /data 디렉토리에서 파일들을 보여줍니다. 두 번째 location context와 일치하는 패턴은 www.example.com 도메인으로 요청을 전송합니다.
server {
location /images/ {
root /data;
}
location / {
proxy_pass http://www.example.com;
}
}
- root: static file이 있는 파일 시스템의 경로입니다. 이때 root 뒤에 location의 경로가 추가된 상태로 파일의 경로를 찾습니다. 예를 들어 /images/example.png의 요청이 들어오면 NGINX는 /data/images/example.png에서 파일을 찾습니다.
- proxy_pass: 위의 예시에서 /images/와 맞지 않는 모든 패턴의 요청은 프록시 서버로 전송됩니다. 이후 프록시 서버에서의 응답이 클라이언트에게 전송됩니다.
참고 문서
'기술' 카테고리의 다른 글
[Yarn] Yarn 사용법, yarn global add 설정하기 (1) | 2019.10.04 |
---|---|
[JavaScript] Object 기초부터 Destructed Assignment까지 자세히 알아보기 (0) | 2019.09.23 |
[Google Apps Script] 구글 설문으로 자동 드라이브 공유 및 슬랙 초대하기 (0) | 2019.09.18 |
[Javascript] 배열 기초 (0) | 2019.09.18 |
[Javascript] 함수 기초: 함수 선언식, 표현식, 호이스팅, 화살표 함수 (1) | 2019.09.17 |