8/10/2023

Configuration

File Structure

NGINX는 구성 파일에 지정된 지시문들에 의해 제어되는 모듈들로 구성된다. 지시문은 간단 지시문과 블록 지시문으로 구분된다. 간단 지시문은 구성 파일에 설정되는 구체적인 구성 옵션으로 이름과 매개변수로 구성되며 공백으로 구분되고 세미콜론(;)으로 끝난다. 블록 지시문은 간단 지시문과 동일한 구조를 가지지만 세미콜론 대신 중괄호({ })로 둘러싸인 추가 지시문 집합으로 끝난다. 블록 지시문 내에 다른 지시문을 가질 수 있는 경우 이를 컨텍스트라고 한다(e.g., events, http, server, location). 본질적으로 컨텍스트는 스코프와 유사하다. 또한 컨텍스트는 중첩되며 부모로부터 상속을 받는데 최상위 컨텍스트(즉, main 컨텍스트)는 구성 파일 자체로 마스터 프로세스에 적용되는 전역 지시문을 구성한다. 구성 파일에 모든 컨텍스트 외부에 배치된 지시문들은 main 컨텍스트에 속하게 되는데 events 컨텍스트와 http 컨텍스트는 main 컨텍스트에 속하며 http 컨텍스트에서 server 컨텍스트, server 컨텍스트에서 location 컨텍스트로 구성된다.


Virtual Host

가상 호스트는 server 컨텍스트 혹은 server 블록이다. 가상 호스트 또는 server 컨텍스트는 기본적으로 특정 IP 주소나 도메인의 포트를 수신 대기하고 있다. 일반적으로 HTTP의 경우 80번 포트 또는 HTTPS의 경우 443번 포트이다. 포트를 listen 지시문에 명시하는데 listen 지시문을 생략할 수도 있다. 이 경우, NGINX는 기본적으로 포트 80을 사용한다. 하지만 이 지시문을 포함하는 것이 좋은 관행으로 간주된다. server_name 지시문은 server 컨텍스트가 존재하는 도메인, 서브도메인 또는 IP 주소이다. server_name 지시문은 와일드카드 문자를 포함할 수 있다. root 지시문은 NGINX가 요청을 처리하거나 정적 요청을 해석할 경로이다. 즉, 서버가 요청을 받는다면 NGINX는 기본적으로 해당 파일을 루트 경로에서 찾는다.
1
2
3
4
5
6
7
8
9
10
11
12
13
events {} # events 컨텍스트에 아무것도 추가하지 않을지라도 유효성을 위해 필요
 
http {
 
    include mime.types; # 파일 포함

    server {
      listen 80; # HTTP 포트
      server_name127.0.0.1; # 서버 이름
 
      root /home/whooa27/Desktop/nginx/demo; # 루트 경로
    }
}
cs


Location Block

location 블록은 모든 NGINX 구성에서 가장 많이 사용되는 컨텍스트이며 특정 URI 또는 요청의 행동을 정의하고 구성하는 방법이다. 총 4가지 방법으로 URI를 일치시킬 수 있다. 접두사(prefix) 일치는 요청을 시작하는 URI와 일치할 경우 적용된다. 정확한(exact) 일치는 URI 앞에 등호(=) 기호를 추가하고 URI와 정확하게 일치하는 경우만 적용된다 정규식 일치는 URI 앞에 물결표(~) 기호를 추가하고 말 그래도 정규식과 일치하는 URI만 적용된다. 정규식 일치는 대소문자를 구분하는데 이를 무시하고 싶을 경우 물결표 기호 뒤에 별표(*) 기호를 추가한다. 살펴본 3가지 방법은 우선순위를 가지는데 이는 다음 코드와 같다. 우선적인(preferential) 접두사 일치는 접두사 일치와 같은데 단지 우선순위가 정규식 일치보다 더 높다. 탈자(^) 기호와 물결표 기호를 추가한다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
events {}
 

http {
    
server {
   listen 80;
    server_name 127.0.0.1;
 
    root /home/ubuntu/Desktop/nginx/exercise;
 
    # 우선순위
    # 1. 정확한 일치 = URI
    # 2. 우선적인 접두사 일치 ^~ URI
    # 3. 정규식 일치 ~* URI
    # 4. 접두사 일치 URI
 
 
    # 접두사 일치
    # location /yawn {
    #   return 200 'Yawn from NGINX.'; 
    # }
 
    # 우선적인 접두사 일치
    # location ^~ /greet {
    #   return 200 'Yawn from NGINX.'; 
    # }
 
    # 정확한 일치
    # location = /greet {
    #   return 200 'Yawn from NGINX.';
    # }
 
    # 정규식 일치 - 대소문자 구분
    # location ~ /greet[0-9] {
    #   return 200 'Yawn from NGINX.'; 
    # }
 
    # 정규식 일치 - 대소문자 무시
    # location ~* /greet[0-9] {
    #   return 200 'Yawn from NGINX.'; 
    # }
    }
}
cs


Variable

변수는 두 가지 형태로 존재한다. 사용자가 직접 설정하는 변수와 내장 변수이다. location 컨텍스트 내부에서 NGINX 조건문을 사용하지 말아야 하는데 예상치 못한 동작을 일으킬 수 있기 때문이다. 사용자 정의 변수의 경우 'set $이름 값' 형식으로 설정할 수 있다. 값은 문자열, 정수 혹은 불리언이 될 수 있다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
events {}
 
http {
 
  include mime.types;
 
  server {
 
    listen 80;
    server_name 127.0.0.1;
 
    root /home/ubuntu/Desktop/nginx/exercise;
    
    # 정적 API 키 확인
    if ( $arg_apikey != 5678 ) { # () 뛰어쓰기 필수
      return 401 "Invalid API Key";
    }
    
    set $weekday 'Yes';
 
    # 평일인지 확인
    if ( $date_local ~ 'Saturday|Sunday' ) {
      set $weekday 'No';
    }
 
    location /is_weekday {
 
      return 200 $weekday;
    }
  }
}
cs


Rewrite & Redirect

리라이트를 위해 사용할 수 있는 두 가지 지시문은 rewrite 지시문(rewrite 패턴 URI)과 return 지시문(return 상태 URI)이다. return 지시문은 상태 코드와 응답 데이터 또는 문자열을 사용하지만 응답 코드가 300 변형인 경우(리다이렉트용) return 지시문의 동작이 바뀌며 두 번째 매개변수로 URI를 받는다. 이는 클라이언트가 리다이렉션되어야 할 URI를 나타낸다. 리다이렉션은 단순히 요청을 수행하는 클라이언트에게 어디로 이동할지 알려주는 반면 리라이트는 URI를 내부적으로 변형한다. 리라이트에 대해 이해해야 할 중요한 점은 URI가 리라이트되면 NGINX에 의해 완전히 새로운 요청으로 다시 평가된다. 즉, 리라이트된 URI는 처음부터 시작되고 다시 평가되는데 이는 리라이트를 매우 강력하게 만들지만 반환보다 더 많은 시스템 자원이 필요하다. 리라이트의 또 다른 중요하고 강력한 기능으로 정규 표현식 캡처 그룹을 사용하여 원본 URI의 특정 부분을 캡처할 수 있다. 또한, 리라이트는 선택적 플래그 기능을 가지는데 마지막 플래그를 살펴본다. 마지막 플래그는 NGINX에게 첫 번째 리라이트 후 더 이상 URI를 리라이트하지 않도록 지시하는 것이다. 리라이트 후 새로운 URI를 다시 평가하지만 이것이 마지막 리라이트라는 것을 보장하여 두 번째 리라이트를 건너뛰고 리로드 요청으로 동일한 URI를 다시 로드하는 것을 의미한다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
events {}
 
http {
 
  include mime.types;
 
  server {
 
    listen 80;
    server_name 127.0.0.1;
 
    root /home/ubuntu/Desktop/nginx/exercise;
 
    # detail로 URI가 리라이트되면 NGINX에 의해 새로운 요청으로 평가되고 처음부터 다시 시작
    # 마지막 플래그 사용
    rewrite ^/item/(\w+) /detail/$1 last;
 
    # 리라이트 적용 X
    rewrite ^/detail/ac /ac.jpg;
 
    # rewrite 지시문을 사용한 리라이트
    # /item/ac -> /item/ac URI 유지
    location /detail {
      return 200 "Item details";
    }
 
    location /detail/ac {
      return 200 "Anti-gravity device";
    }
 
    # return 지시문을 사용한 리다이렉트
    # /thumbnail -> /logo.jpg URI 변경
    location /thumbnail {
      return 307 /logo.jpg; # 들어오는 요청과 같은 호스트로 리다이렉트, 따라서 상대 URI 사용 가능
    }
  }
}
 
cs


Try-Files & Named Location

try_files 지시문은 rewrite 지시문 혹은 redirect 지시문처럼 server 컨텍스트에서 사용할 수 있으며 모든 들어오는 요청 또는 location 컨텍스트 내부에 적용된다. try files는 NGINX가 루트 디렉터리를 기준으로 하여 어떤 위치에 대한 응답으로 사용할 자원을 확인하도록 하고 마지막 인자로 제공되는 것은 리라이트 및 재평가를 일으키며 rewrite 지시문과 같은 역할을 한다. 이름이 있는 위치(named location)는 location 컨텍스트에 이름을 할당하고 try_files와 같은 지시문을 사용하는 것을 의미한다. 위치를 해당 이름으로 사용하며 마지막 인자에 대한 재평가가 발생하지 않도록 하며 대신에 그 이름이 붙은 위치를 명확하게 호출한다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
events {}
 
http {
 
  include mime.types;
 
  server {
 
    listen 80;
    server_name 127.0.0.1;
 
    root /home/ubuntu/Desktop/nginx/exercise;
    
    # 루트 디렉터리를 기준
    # logo.jgp를 확인하고 있으면 해당 자원 제공
    # 만약 logo.jpg가 없으면 다음 인자로 이동
    # 마지막 인자에 도달하면 마지막 인자는 내부 리라이트로 간주되며 재작성된 요청을 재평가
    # 따라서 /sfafs -> /detail
    try_files $uri /logo.jpg /detail @not_found; # @으로 이름있는 위치로 지정
 
    location @not_found {
      return 404 'File not found!'
    }
    
    location /detail {
      return 200 "Item details";
    }

  }
}
cs


Logging

NGINX는 두 가지 로그 유형인 오류 로그와 접근 로그를 제공한다. 오류 로그는 예상대로 작동하지 않거나 예상치 못한 실패가 발생한 모든 것을 기록하는 로그이고 접근 로그는 서버로의 모든 요청을 기록하기 위해 사용된다. 로깅은 기본적으로 활성화되어 있으므로 대부분의 경우 로그 구성을 그대로 두는 것이 좋지만 특정 조건에서 로그를 비활성화하거나 자원별 로그를 생성하는 것은 자원 사용량을 줄이고 로그 파일 구조를 개선하는 데 도움이 될 수 있다. 참고로 가장 흔한 오해 중 하나는 404 오류가 대부분의 경우 오류 로그에 기록된다는 것인데 제대로 처리된 404 오류는 오류 로그 항목을 생성하지 않으며 404는 유효한 응답이며 오류가 아니다. access_log 지시문과 error_log 지시문을 사용하여 특정 컨텍스트에 대한 사용자 정의 로그 파일을 생성하거나 로깅을 완전히 비활성화 해서 서버 로드를 줄이고 로그 파일의 크기를 작게 유지할 수 있다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
events {}
 
http {
 
  include mime.types;
 
  server {
 
    listen 80;
    server_name 127.0.0.1;
 
    root /home/ubuntu/Desktop/nginx/exercise;
    
    # secret.access.log 라는 사용자 정의 로그에 기록
    # 전역 접근 로그에서 더 이상 존재하지 않는 경우에도 이것을 양쪽에 로깅 가능
    location /secret {
      access_log /var/log/nginx/secret.access.log;
      access_log /var/log/nginx/access.log;
      return 200 "Top secrets";
    }
 
    # off를 추가하면 로깅 비활성화
    location /experiment {
      access_log off
      return 200 "Experimental only";
    }
  }
}
cs


Inheritance & Directive Type

NGINX의 상속은 프로그래밍 언어의 스코프처럼 컨텍스트가 설정을 상위 컨텍스트에서 상속한다. 일반적으로 매우 간단한 상속 방식으로 main 컨텍스트에서 시작하여 파일 자체에서 http 컨텍스트로 이동한 다음 server 컨텍스트로 이동하고 마지막으로 location 컨텍스트로 이동한다. 하지만 모든 상속이 항상 간단한 것은 아니며 상속은 상속되는 지시문의 유형에 따라 다양할 수 있다.

지시문은 크게 세 가지 유형이 존재하는데 표준 지시문, 배열 지시문, 행위 지시문이다. 배열 지시문은 이전 지시문을 덮어쓰지 않고 여러 번 선언할 수 있는 지시문이다. 접근 로그가 배열 지시문의 완벽한 예이다. 배열 지시문은 하향식으로 상속되며 main 컨텍스트의 모든 자식 컨텍스트가 지시문을 공유한다. 하지만 자식 컨텍스트가 지시문을 재선언하면 상속한 부모 지시문은 덮어씌어진다. 표준 지시문은 가장 일반적인 지시문으로 지정된 컨텍스트에서 한 번만 선언할 수 있으며 배열 지시문과 동일한 상속 방식으로 작동한다. 자식 컨텍스트는 자체 선언으로 지시문을 재정의할 수 있다. 행위 지시문은 구성에서 어떤 종류의 중단 또는 동작을 호출하는 지시문이다. 예를 들어, return 지시문을 통한 리다이렉션, return 지시문을 통한 응답, rewrite 지시문 또는 try files 지시문을 통한 리라이트 등이 있다. 액션 지시문은 구성의 정상적인 흐름을 중단(e.g., 요청이 중지(리다이렉션/응답) 혹은 재평가(리라이트))하기 때문에 상속은 액션 지시문에 적용되지 않는다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
events {}
 
# (1) 배열 지시문
access_log /var/log/nginx/access.log;
access_log /var/log/nginx/custom.log.gz custom_format;
 
http {
 
  # include 문은 지시문이 아니다.
  include mime.types;
 
  server {
    listen 80;
    server_name server1.com;
 
    # 상위 컨텍스트(1)에서 access_log 상속 (1)
  }
 
  server {
    listen 80;
    server_name server2.com;
 
    # (2) 표준 지시문
    root /sites/server2;
 
    # (1)에서 상속을 완전히 덮어씌운다.
    access_log off;
 
    location /pics {
 
      # (2)에서 상속한 root 지시문 사용한다.
      try_files $uri /ac.jpg;
    }
 
    location /secret {
      # (3) 행위 지시문
      return 403 "Authorization required.";
    }
  }
}
cs


PHP Processing

정적 파일을 제공하는 것 이외에도 대부분의 웹 서버에는 PHP와 같은 서버 측 언어에서 생성된 동적 콘텐츠를 제공하는 능력이 중요하다. 앞서 언급했듯이 NGINX는 서버 측 언어 처리기를 내장할 수 없기에 대신에 독립적인 PHP 서비스, 즉 PHP-FPM을 구성하여 NGINX는 처리를 위해 요청을 전달하고 일반적으로 HTML로 응답을 받은 다음 이를 클라이언트에 반환한다. 이것은 본질적으로 NGINX가 리버스 프록시 서버로 작동하는 것이다.

구성 파일에서 index 지시문은 디렉터리를 가리키는 요청이 올 때 NGINX가 어떤 파일을 로드할지 알려주는 표준 지시문이다. 기본값은 index.html이며 도메인 '/'를 요청하면 루트 지시문에 이 인덱스 지시문을 더한 index.html이 로드된다(즉, /home/ubuntu/Desktop/nginx/exercise/index.html). try files 지시문과 마찬가지로 중요도 순으로 여러 인자를 가질 수 있다. FastCGI로 요청을 PHP-FPM에 전달하려면 fastcgi_pass 지시문을 사용한다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# worker 프로세스는 NGINX의 기본값이며 PHP FPM 프로세스는 www-data
# nobody 사용자는 PHP FPM 소켓에 대한 권한이 없다
# 이 문제를 해결하는 여러 가지 방법이 있지만 가장 안전하고 쉬운 방법은 NGINX를 구성 파일에서 "www-data"와 동일한 사용자로 실행하도록 설정
user www-data;
 
events {}
 
http {
 
  include mime.types;
 
  server {
 
    listen 80;
    server_name 127.0.0.1;
 
    root /home/ubuntu/Desktop/nginx/exercise;
    
    index index.php index.html
    
    # $uri: 요청 URI
    # $uri/: 디렉터리(즉, index.php 혹은 index.html)
    # 모든 정적 콘텐츠 요청을 처리하는 location
    location / {
      try_files $uri $uri/ =404
    }
 
    # php로 끝나는 모든 것, 정규식이라서 더 높은 순위
    location ~\.php$ {
      # PHP 요청을 PHP-FPM 서비스로 전달(FastCGI)
      # FastCGI: HTTP처럼 이진 데이터를 전송하는 프로토콜. 이를 통해서 NGINX가 PHP-FPM과 통신
      include fastcgi.conf; # mime.types처럼 NGINX가 설치 시 제공하는 FastCGI 구성 파일. mime.types처럼 상대 경로
 
      # FastCGI를 사용하여 PHP-FPM에 전달하려면 "fastcgi_pass" 지시문을 사용
      # 전달할 목적지는 PHP-FPM에서 생성한 Unix 소켓
      fastgci_pass unix:/run/php/php8.1-fpm.sock;
      
    }
  }
}
cs


Worker Process

주인(master) 프로세스는 NGINX 서비스 또는 소프트웨어 인스턴스이며 NGINX 자체가 클라이언트 요청을 수신하고 응답하는 일꾼(worker) 프로세스를 생성한다. NGINX의 기본 일꾼 프로세스 수는 하나이며 NGINX가 생성하는 일꾼 프로세스 수를 변경하려면 nginx.conf 파일에서 worker_processes 지시문을 사용한다.

NGINX가 생성하는 일꾼 수를 늘리는 것은 반드시 더 나은 성능을 의미하지 않는다. NGINX 프로세스, 특히 요청을 처리하는 일꾼 프로세스는 비동기적으로 동작한다. 이는 하드웨어가 처리할 수 있는 속도로 들어오는 요청을 처리한다는 것을 의미하며 두 번째 일꾼 프로세스를 생성하는 것은 하드웨어의 능력을 증가시키지 않는다. CPU 코어가 하나 이상 있는 경우(듀얼 코어, 쿼드 코어 또는 옥타 코어), 이러한 코어는 프로세스를 공유할 수 없다. 즉, 단일 NGINX 일꾼 프로세스는 단일 CPU 코어에서만 실행될 수 있다. 따라서, 대부분의 경우 NGINX를 서버 CPU 코어 수와 동일한 프로세스 수로 구성한다. 따라서 서버의 성능을 향상시키기 위해 더 많은 일꾼 프로세스를 생성하기 전에, 단일 코어에서 두 개의 일꾼 프로세스가 최적으로 실행되는 하나의 전용 프로세스 대신 50%만 실행 가능한 두 개의 일꾼 프로세스를 가지고 있다고 생각하라. 서버 CPU 코어 수와 동일한 일꾼 프로세스를 생성하려면 worker_processes 지시문을 auto로 설정한다.

worker_connections 지시문은 각 일꾼 프로세스가 수락할 수있는 연결 수를 설정하며 단순히 증가시킬 수있는 숫자는 아니다. CPU 코어당 열 수있는 파일 수에 제한이 있다. 지시문의 값을 제한 파일 수로 설정하면 서버를 최대로 사용할 수 있다. 매우 중요한 것은 최대 동시 요청 수로 서버는 일꾼 프로세스 * 일꾼 연결 수만큼의 연결 또는 요청을 열 수 있어야 하는데 각각의 일꾼 프로세스는 그만큼의 연결 또는 요청을 열 수 있기 때문이다. 두 가지 지시문은 NGINX 프로세스를 성능 최적화하기 위해 이해해야 할 가장 중요한 두 가지 지시문이다.

pid 지시문을 사용하여 설정 파일을 통해 프로세스 아이디 위치를 재구성할 수 있다. NGINX를 다시 빌드하지 않고도 이를 변경해야 하는 이유가 있다면이 지시문을 사용할 수 있다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
user www-data;
 
pid /var/run/new_nginx.pid;
 
worker_processes auto;
 
events {
  worker_connections 1024;
}
 
http {
 
  include mime.types;
 
  server {
 
    listen 80;
    server_name 127.0.0.1;
 
    root /home/ubuntu/Desktop/nginx/exercise;
    
    index index.php index.html
 
    location / {
      try_files $uri $uri/ =404
    }
 
    location ~\.php$ {
      include fastcgi.conf;
      fastgci_pass unix:/run/php/php8.1-fpm.sock;
      
    }
  }
}
cs


Buffer & Timeout

버퍼링은 프로세스나 NGINX 일꾼이 데이터를 메모리로 읽어서 다음 목적지로 보내기 전에 임시로 저장하는 것을 의미한다. 예를 들어, NGINX는 TCP 포트 80에서 받은 요청을 읽고 요청 데이터를 메모리에 버퍼링하거나 읽은 데이터 양이 버퍼 크기보다 작으면 일부를 디스크에 기록한다. 반대로 NGINX는 디스크에서 읽어서 메모리에 버퍼링한 파일을 클라이언트에게 전송하여 요청에 응답한다. 타임아웃은 주어진 이벤트에 대한 제한 시간을 나타낸다. 예를 들어, 클라이언트로부터 요청을 받을 때, 일정한 시간(초) 후에 중단하여 클라이언트가 무한한 데이터 스트림을 보내고 서버를 고장내는 것을 방지한다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
user www-data;
 
worker_processes auto;
 
events {
  worker_connections 1024;
}
 
http {
 
  include mime.types;
 
  # POST 제출(submission)을 위한 버퍼 크기
  client_body_buffer_size 10K;
  client_max_body_size 8m;
 
  # 헤더용 버퍼 크기
  client_header_buffer_size 1k;
 
  # 클라이언트 헤더/바디를 받는 데 최대 시간
  client_body_timeout 12;
  client_header_timeout 12;
 
  # 연결을 열어둘 최대 시간
  keepalive_timeout 15;
 
  # 클라이언트가 응답을 받는 최대 시간
  send_timeout 10;
 
  # 정적 파일에 대한 버퍼링 스킵
  sendfile on;
 
  # sendfile 패킷 최적화
  tcp_nopush on;
 
  server {
 
    listen 80;
    server_name 127.0.0.1;
 
    root /home/ubuntu/Desktip/nginx/exercise;
 
    index index.php index.html;
 
    location / {
      try_files $uri $uri/ =404;
    }
 
    location ~\.php$ {
      include fastcgi.conf;
      fastcgi_pass unix:/run/php/php8.1-fpm.sock;
    }
 
  }
}
cs


Dynamic Module

동적 모듈은 NGINX  구성에서 선택적으로 로드할 수 있는 모듈을 의미한다. 이는 항상 시작하기 전에 로드되는 정적 모듈과 다르다. 표준 모듈을 추가하는 것과 동적 모듈을 추가하는 것은 정확히 동일하다. NGINX 자체를 더 새로운 버전으로 업그레이드하는 것도 마찬가지이다. NGINX에 새 모듈을 추가하려면 NGINX를 원본 소스 코드로부터 다시 빌드해야 한다. 

다시 빌드하는 첫 번째 단계는 기존 구성을 변경하지 않는 것으로 이를 위해  NGINX를 V 플래그와 함께 실행하여 현재 구성을 얻을 수 있다. 다음 단계는구성에 새 모듈을 추가하는 것으로 소스 코드 다운로드로 사용 가능한 모듈 목록을 보려면 현재 디렉토리에서 configure를 실행하고 도움말 플래그를 사용하여 NGINX 를 구성할 수 있는 모든 모듈과 플래그를 나열한다. =dynamic을 가지고 있는 동적 모듈을 추가할 때 모듈 경로를 지정한다.

Update: 2023-10-10
시간:
라벨:

댓글 없음:

댓글 쓰기

피드 구독하기: 댓글 (Atom)
  • 인프라의 세계
    발단 리팩토링한 애플리케이션을 배포하기 위해서 가장 널리 사용되는 클라우드 서비스인 AWS를 사용하기로 했다. 위코드에서 1차 프로젝트 완료 후 배포를 하기 위해 EC2와 RDS를 사용했는데 처음 사용해서 그런지 인프라가 너무 허접하고 초라했다... ...
  • 캐싱과 Redis
    발단  AWS를 사용해서 애플리케이션을 배포하고 API를 호출했는데 상품 상세 API와 상품 목록 API 응답 속도가 너무 느렸다. 대략 속도가 362ms 정도 나왔는데 사용자 관점에서 보면 정말 불편하고 답답하다고 볼 수 있다. 검색 연산의 속도를 ...
  • Dockerfile
    발단 강의로만 듣다가 실제로 Dockerfile을 작성하는 시간이 왔다! "길을 아는 것과 길을 걷는 것의 차이가 있다."라는 영화 속의 대사처럼 강의보고 주어진 연습문제만 풀다가 실제로 적용하려고 하니 어려움이 굉장히 많았다... ...