Linux – WONIZZ.LOG

[DevOps] Nginx Lua module 사용법

워니 — Thu, 18 Jul 2024 06:09:28 +0000

The standard Lorem Ipsum passage, used since the 1500s
"Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."

Section 1.10.32 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?"

1914 translation by H. Rackham
"But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure?"

Section 1.10.33 of "de Finibus Bonorum et Malorum", written by Cicero in 45 BC
"At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat."

1914 translation by H. Rackham
"On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain. These cases are perfectly simple and easy to distinguish. In a free hour, when our power of choice is untrammelled and when nothing prevents our being able to do what we like best, every pleasure is to be welcomed and every pain avoided. But in certain circumstances and owing to the claims of duty or the obligations of business it will frequently occur that pleasures have to be repudiated and annoyances accepted. The wise man therefore always holds in these matters to this principle of selection: he rejects pleasures to secure other greater pleasures, or else he endures pains to avoid worse pains."

안녕하세요? 정리하는 개발자 워니즈입니다. 이번시간에는 nginx lua module에 대해서 정리를 해보도록 하겠습니다. lua script는 이전에 nginx 관련 세미나를 들으면서 알게 됐던 내용인데요. nginx의 config에 마치 개발 코드를 작성하듯 script를 넣어서 제어할 수 있는 부분이 꽤나 인상적이였습니다.

필자의 회사에서도 nginx의 lua script를 통해서 제어가 필요한 요청을 받았습니다. 이를 해결하고자 lua module 탑재를 진행하게 됐습니다.

Nginx에 관한 시리즈 포스팅은 아래에서 확인이 가능합니다.

1. Nginx Lua module 이란?

lua-nginx-module은 Nginx에 Lua 스크립팅 기능을 추가하는 모듈입니다. 이를 통해 Nginx의 요청 처리 흐름에 Lua 코드를 삽입하여 다양한 작업을 수행할 수 있습니다. OpenResty 프로젝트의 일부로, 고성능 웹 애플리케이션을 구축하는 데 유용합니다.

주요 기능

동적 컨텐츠 생성: Lua 스크립트를 사용하여 요청에 대한 동적 응답을 생성할 수 있습니다.
고급 접근 제어 : 요청 헤더, 쿠키, IP 주소 등을 기반으로 접근 제어 로직을 구현할 수 있습니다.
응답 필터링 및 수정 : 응답 본문을 필터링 하거나 수정할 수 있습니다.
복잡한 인증 및 인가 : 외부 인증 서버와 통신하여 복잡한 인증 및 인가 로직을 구현할 수 있습니다.
로깅 및 모니터링 : 맞춤 로깅 메커니즘을 구현하고, 실시간 트래픽 모니터링 데이터를 수집할 수 있습니다.

공식 github은 아래에서 확인이 가능합니다.

openresty / lua-nginx-module

2. Nginx Lua module 설치

필자는 nginx를 직접 compile 해서 사용하고 있습니다. container 기반에 이미 만들어진 이미지를 활용하는것이 훨씬 효율적일 수 있습니다. 필자는 custom module을 추가함에 있어 자유도가 있기 때문에 native로 운영중에 있습니다.

그럼 본격적으로 각 스텝별로 설치 가이드를 작성해보겠습니다.

LuaJIT 설치
- lua-nginx-module을 사용하기 위해선, LuaJIT 또는 Lua 5.1 이상이 필요합니다. LuaJIT를 사용하는 것이 일반적으로 권장되며, 성능상의 이점이 있습니다.

# LuaJIT-2.0.5 설치
wget http://luajit.org/download/LuaJIT-2.0.5.tar.gz
wget https://line-objects-internal.com/fileshare/logs/LuaJIT-2.0.5.tar.gz

# 압축 해제 및 설치
tar -xvzf LuaJIT-2.0.5.tar.gz
cd LuaJIT-2.0.5
make
make install

# LuaJIT 설치 후, LuaJIT 라이브러리 경로를 시스템 라이브러리 경로에 추가
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
luajit -v

Nginx와 ngx_devel_kit (NDK)

# NDK 설치 
wget https://github.com/simplresty/ngx_devel_kit/archive/v0.3.1.tar.gz
tar -zxvf v0.3.1.tar.gz

lua-resty-core와 lua-resty-lrucache를 설치

# lua-resty-core 설치
git clone https://github.com/openresty/lua-resty-core.git
cd lua-resty-core
make install

# lua-resty-lrucache 설치
git clone https://github.com/openresty/lua-resty-lrucache.git
cd lua-resty-lrucache
make install

lua-nginx-module 설치

# lua module 다운로드
git clone https://github.com/openresty/lua-nginx-module.git

위의 작업들은 사전에 필요한 라이브러리 및 모듈을 다운로드, 설치 하는 과정에 대해서 설명했습니다.

이제 본격적으로 Nginx를 re-compile을 수행하여 module을 탑재합니다.

Nginx Compile

export LUAJIT_LIB=/usr/local/lib
export LUAJIT_INC=/usr/local/include/luajit-2.0

# Version Info
NGINX_VERSION=1.20.1
PCRE_VERSION=8.44
OPENSSL_VERSION=1.1.1l
ZLIB_VERSION=1.2.11
NGINX_PATH=/home1/irteam/apps/nginx-${NGINX_VERSION}


# Nginx Compile
./configure --prefix=${NGINX_PATH} \
    --user=irteamsu --group=irteamsu \
    --with-http_ssl_module \
    --with-http_stub_status_module \
    --with-http_realip_module \
    --with-http_v2_module \
    --add-dynamic-module=/pkgs/ngx_http_geoip2_module \
    --with-ld-opt="-Wl,-rpath,/usr/local/lib -lpcre" \
    --add-dynamic-module=/pkgs/lua-nginx-module \
    --add-dynamic-module=/pkgs/ngx_devel_kit-0.3.1 \
    --with-pcre=/pkgs/pcre-${PCRE_VERSION} \
    --with-openssl=/pkgs/openssl-${OPENSSL_VERSION} \
    --with-zlib=/pkgs/zlib-${ZLIB_VERSION}

# Nginx Install
make -j2
make install

3. Nginx Config 수정

위의 과정을 통해서 nginx binary에 lua module을 탑재했습니다. lua module을 사용할 수 있도록 import 합니다.

# add necessary `lua_package_path` directive to `nginx.conf`, in the http context
load_module modules/ndk_http_module.so;
load_module modules/ngx_http_lua_module.so;

events {
    worker_connections  3000;
}

http {
    lua_package_path "/usr/local/lib/lua/?.lua;;";
    ....
}

적용을 하면서 여러가지 이슈 사항들을 겪었습니다. 그 내용에 대해서 정리를 해보겠습니다.

설치시 발생한 이슈

설치시 환경 변수 셋팅

# 오류 내용
adding module in /usr/local/src/ngx_devel_kit-0.3.1
+ ngx_devel_kit was configured
adding module in /usr/local/src/lua-nginx-module-0.10.19
checking for LuaJIT 2.x ... not found
   ./configure: error: unsupported LuaJIT version; ngx_http_lua_module requires LuaJIT 2.x.

nginx를 컴파일하고 설치를 했더니 위와 같은 오류가 발생했습니다. LuaJIT이 필요하다는 내용인데요. 분명히 LuaJIT을 설치했지만 찾을 수 없는 것 같았습니다.

Resolve Ref : https://forum.openresty.us/d/6494-ngx-http-lua-module-requires-luajit-2x

# nginx compile 시에 환경 변수 설정. 
export LUAJIT_LIB=/usr/local/lib
export LUAJIT_INC=/usr/local/include/luajit-2.0

PCRE 옵션 설정

# 오류 내용
/tmp/nginx.lJpu0R.ltrans10.ltrans.o::function ngx_http_lua_log_by_chunk: error: undefined reference to 'pcre_malloc'
/tmp/nginx.lJpu0R.ltrans10.ltrans.o::function ngx_http_lua_log_by_chunk: error: undefined reference to 'pcre_free'
/tmp/nginx.lJpu0R.ltrans10.ltrans.o::function ngx_http_lua_log_by_chunk: error: undefined reference to 'pcre_malloc'
/tmp/nginx.lJpu0R.ltrans10.ltrans.o::function ngx_http_lua_log_by_chunk: error: undefined reference to 'pcre_free'
/tmp/nginx.lJpu0R.ltrans10.ltrans.o::function ngx_http_lua_body_filter_by_chunk: error: undefined reference to 'pcre_malloc'
/tmp/nginx.lJpu0R.ltrans10.ltrans.o::function ngx_http_lua_body_filter_by_chunk: error: undefined reference to 'pcre_free'

pcre와 관련된 내용의 오류가 발생했습니다. Nginx Compile 과정에서 pcre를 적절하게 시스템에서 사용할 수 있도록 link를 해야된다는 것을 알았습니다. 다음의 옵션값으로 설치를 진행합니다.

Resolve Ref : https://github.com/openresty/lua-nginx-module/issues/1984

# pcre 링크 설정
--with-ld-opt="-Wl,-rpath,/usr/local/lib -lpcre"

-Wl,-rpath,/usr/local/lib: 실행 시간(runtime) 라이브러리 검색 경로를 /usr/local/lib으로 설정합니다. 이는 동적 라이브러리(.so 파일)를 로드할 때 사용됩니다.
-lpcre: PCRE(Perl Compatible Regular Expressions) 라이브러리를 링크합니다. 이는 Nginx의 정규 표현식 처리 기능을 위해 필요합니다.
1. Package Path 설정
```
# 오류 내용
nginx: [error] lua_load_resty_core failed to load the resty.core module
```
nginx에서 module을 로딩할 수 없다는 내용입니다. config 설정에서 모듈을 불러 올 수 있도록 설정합니다.

Resolve Ref : https://github.com/openresty/lua-nginx-module/issues/1533

# module 로딩 
http {
   lua_package_path "/usr/local/lib/lua/?.lua;;";
}

3. Nginx Lua script 예제

처음에 lua module을 탑재하게 된 계기는 403 status code를 200으로 전환이 가능한지에서부터 시작했습니다. 개발팀의 특정 상황으로 인해서 어쩔 수 없이 403 code를 반환하는 상황이 있었습니다. 이를 200으로 전환하여 google로 하여금 seo indexing이 되도록 설정하고자 해습니다.

기본적인 Nginx에서는 status code를 변조하는것을 허락하지 않습니다. 이를 lua script를 통해서 변경했고 다음과 같이 config 설정을 작성했습니다.

location / {
    resolver xxx.xxx.xxx.xxx valid=600s;        
    proxy_pass https://$backend;
    proxy_next_upstream error timeout;
    proxy_redirect off;
    proxy_connect_timeout 2s;

    # response header를 변조합니다. 
    header_filter_by_lua_block {
        # .json 확장자에 대해서는 예외처리
        if ngx.var.uri:match("%.json$") then
            return
        end

        local content_type = ngx.header["Content-Type"]
        if content_type and content_type:match("text/html") then
            if ngx.status == 403 then
                # status code를 200으로 반환
                ngx.status = 200
            end
        end
    }
...
}

위의 내용을 통해서 적절하게 status code를 변경할 수 있었습니다. 이 외에도 다양한 활용 사례들이 있습니다. 이는 다음번 포스팅에서 작성을 해보도록 하겠습니다.

4. 마치며…

Nginx는 정말 웹서버 이상으로 강력한 활용 사례가 있다고 생각합니다. 이번에는 lua module을 통해서 header 제어에 대해서 확인을 했지만, 다음번에는 다양한 활용 사례에 대해서도 포스팅을 해보겠습니다.

또한, Nginx에는 유용한 모듈들이 많기 때문에 이러한 부분들에 대해서도 확인하고 학습하면 좋을 것 같다는 생각을 해봤습니다. 이상으로 포스팅을 마칩니다. 감사합니다.

5. 참고

https://www.jacobbaek.com/1369

https://byeong-gook.tistory.com/64

https://blog.naver.com/n_cloudplatform/222182688666

The post [DevOps] Nginx Lua module 사용법 appeared first on WONIZZ.LOG.

[DevOps] Nginx Logrotation 설정

워니 — Thu, 10 Aug 2023 09:23:01 +0000

안녕하세요? 정리하는 개발자 워니즈 입니다. 웹 서버를 운영하다보면, 로그 파일들이 무분별하게 쌓이는 문제가 있습니다. 이를 정리하기 위해서는 logrotation이라는 프로그램을 이용해야 하는데요. logrotation을 어떻게 설정하고 어떤식으로 활용하는지에 대해서 정리를 해보도록 하겠습니다.

Nginx에 관한 시리즈 포스팅은 아래에서 확인이 가능합니다.

1. Logrotation 이란?

간단하게 리눅스에서 사용할 수 있는 프로그램.

Logrotatefㅡㄹ 사용하면 특정 폴더에 쌓이는 로그를 날짜 별로 나누어서 관리를 할 수 있으며, 기준을 정하면 해당일 이전 로그는 삭제하여 시스템 용량을 낭비하지 않을 수 있습니다.

Logrotate 구조

/etc/logrotate.conf : 로그 로테이트의 기본 설정 파일

기본 설정 : log는 주 단위로 백업 -> 4주동안 보관

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# uncomment this if you want your log files compressed
#compress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp and btmp -- we'll rotate them here
/var/log/wtmp {
  monthly
  create 0664 root utmp
      minsize 1M
  rotate 1
}

/var/log/btmp {
  missingok
  monthly
  create 0600 root utmp
  rotate 1
}

# system-specific logs may be also be configured here.

/etc/logrotate.d/ : 로그 로테이트의 개별 설정 파일이 들어있는 폴더

## syslog 예시
/var/log/cron
/var/log/maillog
/var/log/messages
/var/log/secure
/var/log/spooler
{
  missingok
  sharedscripts
  postrotate
      /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
  endscript
}

## custom 예시
## test.txt를 rotation할시에 data.json파일도 강제적으로 날짜별 copy를 수행
/home1/test/apps/devops/logs/test.txt {
  daily
    missingok
  copytruncate
  dateext
  notifempty
  postrotate
      cp -p /home1/test/apps/devops/logs/data.json /home1/test/apps/devops/logs/data.json-`date +%Y%m%d.%H%M%S`
  endscript
}

/etc/cron.daily/logrotate : 로그 로테이트 작업 내역 로그

2. Logrotation 설정 방법

필자는 nginx log에 대해서 rotation설정을 진행했습니다.

nginx logrotation 설정

/apps/nginx-1.20.1/logs/access_log {
        daily
        missingok
        rotate 7
        compress
        delaycompress
        notifempty
        create 640 root root
        sharedscripts
        postrotate
                if [ -f /var/run/nginx.pid ]; then
                        kill -USR1 `cat /var/run/nginx.pid`
                fi
        endscript
}

1️⃣ 로그 정리 대상 파일 : /apps/nginx-1.20.1/logs/access_log
2️⃣ daily : daily(매일), weekly(매주), monthly(매달), yearly(매년) 순환
3️⃣ missingok : 로그파일이 없을 경우에도 에러로 처리하지 않음
4️⃣ rotate 7 : rotate 파일 갯 수
5️⃣ compress : 순환된 로그파일 압축(gz)
6️⃣ delaycompress : 최근파일 외 전부 압축
7️⃣ notifempty : 로그파일이 제로인 경우 rotation하지 않음
8️⃣ sharedscripts : prerotate, postrotate 스크립트를 한번만 실행
9️⃣ postrotate : 로그파일 분할 후 실행할 script 지정 ( nginx 의 경우 SIGUSR1 을 받으면 로그 파일을 새로 읽으므로 새로 만들어진 로그 파일에 로그를 기록합니다. )
🔟 copytruncate : 대부분의 어플리케이션들은 SIGTERM을 받으면, 로그파일을 새로 만듭니다. copytruncate를 이용하면 원본파일을 지우지 않고, truncate(파일 크기를 0으로 만든다)한다.

3. Logrotation 설정 테스트

로그 로테이션 설정을 진행하고나서 설정 테스트를 하기 위해서는 아래와 같이 테스트를 진행합니다.

logrotate -d -f /etc/logrotate.d/nginx

-d, –debug : 디버그 모드, 실제 로그 파일을 변경하지는 않고 처리 과정만 표시합니다.

참고

The post [DevOps] Nginx Logrotation 설정 appeared first on WONIZZ.LOG.

[DevOps] 주로 사용하는 Nginx 설정

워니 — Mon, 03 Jul 2023 01:34:23 +0000

안녕하세요? 정리하는 개발자 워니즈입니다. 이번시간에는 주로 사용하는 Nginx 설정들에 대해서 정리를 해보도록 하겠습니다. 필자가 속한 프로젝트에서는 FE에 대한 서버를 Nginx로 사용하고 있습니다. Nginx에 index.html을 서빙하는 방식으로 이용하고 있습니다. 그러다보니 Nginx에 대한 셋팅 혹은 설정을 많이 하게 되는데 주로 사용하는 것들에 대해서 정리를 해두어서 참고하고자 합니다.

1. nginx.conf 설정

worker_process

nginx의 실행 가능한 worker 프로세스의 수를 지정해 줄 수 있습니다. nginx는 master와 worker 프로세스로 구성이 되는데요. 공식문서에 의하면, 최적값은 cpu core를 사용하라고 권고 하고 있습니다.

worker_processes        4; # number of CPU cores

worker_rlimit_nofile

worker process들에서 최대로 열린 파일들의 수를 제한 할 수 있습니다. 이 수가 클 수록 메인 프로세스를 재시작 할 필요가 없어진다고 합니다. 하지만 너무 많은 수의 파일이 열려있으면, 서버에 부하를 발생시킵니다.

worker_rlimit_nofile    20000; # sockets, fds per worker process

events 블록 – worker_connections

Proxy 서버를 통해 연결된 커넥션들을 포함한 클라이언트들의 모든 커넥션들의 숫자를 고려해야 합니다. worker_rlimit_nofile의 값을 넘어서는 안된다.

events {
    worker_connections  3000; # total supported connection : 4 x 3000 = 12000
}

2. http 블록

Include & default_type

core_module에 있는 설정으로, include는 다른 파일을 가져올 수 있습니다. 아래의 mime.types와 같이 위에서 정의한 types를 파일로 빼내서, include지시어를 이용해 가져올 수 있습니다. 아래에서는 types의 default_type도 정의해 주었습니다.

include       mime.types;
default_type  application/octet-stream;

keepalive

한번 맺어 놓은 연결에 대해서는 keepalive timeout 시점까지는 연결을 지속적으로 허용해두는 설정입니다. 서버를 사용하지 않는 혹은 못하는 Connection까지 모두 keep 하고 있으므로 자원의 손실이 발생하게 됩니다.

keepalive_timeout   30s;
keepalive_requests  128;

client_body_timeout

client의 request body를 읽을 때의 timeout을 정의합니다. 기본값은 60s로 되어 있습니다.

# timeout for client
client_body_timeout     3s;
client_header_timeout   3s;
client_max_body_size    1m;

send_timeout

client에게 response를 전송할 떄의 timeout값을 설정합니다. client가 아무것도 받지 못하면, connection이 closed 됩니다. 기본값은 60초로 되어있습니다.

send_timeout            3s;

3. Server 블록

server

server_name은 가상 서버의 이름을 정할 때 사용합니다. 아래는 80 port로 접속시 443으로 전환 시켜주는 내용입니다.

server {
    listen 80;
    server_name test.store.com;
    rewrite ^(.*) https://test.store.com$1 permanent;
}

Location 우선순위

nginx에서 가장 중요한 부분입니다. request URI에 따른 설정을 하는 곳입니다. URI에 대한 매칭은 텍스트 값을 prefix로 하여서 매칭하거나 주어진 정규식을 이용해서 매칭할 수 있습니다.

=	패턴과 정확하게 일치 할 때 사용. URI검색시 가장 우선순위가 높습니다. $host정보에 /test.png로 정확하게 매치가 될 때 사용합니다. 하지만, 만약 “=/test”와 같이 사용할 경우, “$host/test”는 일치하여서 매칭이 되지만, “$host/test/”는 매칭되지 않아버리므로, 주의를 기울여서 사용해야 합니다.
~	대소문자를 구별하여 정규표현식과 일치할 때 사용 보통은 아래의 기호를 더 많이 사용하게 됩니다.
~*	대소문자 구별하지 않고 정규표현식과 일치할 때 사용 ex) location ~* .(gif\|jpg\|jpeg)$ { return 200 “found” }
^~	지정한 패턴으로 시작할 때 사용.
	아무기호도 없이 텍스트를 사용하면, prefix로 사용해서 해당 텍스트로 시작하는 URI를 찾는다.
@name	이름을 붙여서, location 블럭을 정의한다. 내부 요청에 의해서만 접근할 수 있는데요. 아래와 같이 사용될 수 있습니다. location { try_files $uri @mylabel; } location @mylabel { return 404 “Not Found”}

Header Setting

FE에 대한 서빙을 하다보면, index.html 페이지의 배포가 자주 일어나는데, 이부분이 브라우저 혹은 중간 CDN 서버에 캐싱이 되어있으면, 사용자 측에서 변경이 반영이 안된것으로 노출이 되게 됩니다. 이러한 부분을 캐시 설정을 통해서 서버의 변경사항을 바로 보여줄 수 있도록 설정할 수 있습니다.

        location / {
...
...
            add_header Cache-Control "no-cache, no-store, max-age=0, must-revalidate";
        }

Access Control

Public open을 앞둔 서비스는 사내망에서 혹은 특정 허용된 사용자만을 노출하기 위해서 제한을 할 수 있습니다.

location ~ ^/internal-api/v1/circuit-breaker/(turn-off|turn-on)$ {
            if ($request_method != POST ) {
                    return 405;
            }
            allow 10.XXX.XX.X/32;
            deny all;
}

Rewrite

rewrite은 server, location, if블록에서 사용할 수 있습니다. 마지막 flag값으로는 last, break, redirect, permanent가 있습니다. 마지막 permanent의 값은 301코드와 함께, 영원히 redirect시키는 flag입니다.

location /test/api {
    rewrite ^/test/api(/.*)$ $1 break; // "/test/api를 제외한 URI로 전달"
    proxy_pass https://lan3rd.line.me;
    proxy_next_upstream error timeout;
    proxy_redirect off;
    proxy_connect_timeout 2s;

    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

Return

nginx에서 rewrite를 하는 방법으로는 지시어 rewrite와 return하는 두가지 방법이 있습니다. 되도록 return을 사용하도록 권고하고 있습니다.

server {
    listen 80;
    server_name .test.com;
    location / {
        return 301 https://$host$request_uri;
    }
}

Proxy_set_header

중계 받는 nodejs 같은 서버에 request header를 다시 재정의해서 전달할 때 사용합니다.

        location / {
            proxy_pass http://test_upstream;
            proxy_next_upstream error timeout;
            proxy_redirect off;
            proxy_connect_timeout 2s;

            proxy_set_header Host $http_host;
            proxy_set_header X-Real-IP $remote_addr;

            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header X-Forwarded-Server $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_http_version 1.1;
            proxy_set_header Connection "";

            proxy_hide_header x-envoy-decorator-operation;
            proxy_hide_header x-envoy-upstream-service-time;

            add_header Cache-Control "no-cache, no-store, max-age=0, must-revalidate";
        }

4. 마치며..

Nginx 는 이미 만들어진 미들웨어(중간 소프트웨어) 제품입니다. 여러가지 설정들을 통해서 필자가 운영하는 서비스들에 좀 더 안정적으로 트래픽 제어 혹은 보안적인 측면에서 효율적으로 관리를 할 수 있다는 생각을 했습니다. 설정들에 대해서 하나하나 세세히 알기 쉽지는 않겠지만, 주로 설정하는 내용들에 대해서 미리 알고 있다면 조금 더 운영함에 있어서 손 쉽게 운영할 수 있을 것이라는 생각을 해봤습니다. 다음시간에는 Nginx의 통합 시리즈에 대해서 정리를 해보겠습니다.

함께 보면 좋은 글

The post [DevOps] 주로 사용하는 Nginx 설정 appeared first on WONIZZ.LOG.

[DevOps] ansible nginx config 배포 구성

워니 — Mon, 11 Jul 2022 07:59:14 +0000

안녕하세요? 정리하는 개발자 워니즈입니다. 이번시간에는 ansible을 이용한 nginx config 파일의 배포에 대해서 정리해보도록 하겠습니다. 필자가 속한 프로젝트에서는 nginx를 Front-end의 export된 html 소스를 서빙하기 위한 용도로 사용하고 있습니다. nginx config의 설정 변경을 수행하고 배포시에는 별도의 사내 시스템을 사용하고 있었지만, 이는 scp를 통해서 직접 파일을 카피하고 전송하는 부분이였습니다.

이러한 부분을 좀더 수월하게 개선하기 위해서 필자는 ansible을 통하여 파일을 배포하고 배포된 파일이 정상인지 검증(validation)을 수행하고, 이후에 기동한 뒤 프로세스체크까지 하는 파이프라인구조로 변경을 하기로 했습니다.

Nginx에 관한 시리즈 포스팅은 아래에서 확인이 가능합니다.

1. nginx deploy with ansible

nginx의 config 파일 관리는 github에서 우선적으로 합니다. ansible은 별도 ansible server에서 설치하여 사용하며 ansible을 위한 별도의 git repository도 존재합니다. 흐름은 다음 플로우를 통해서 진행이 되며, ansible을 통해서 nginx config 파일을 배포하고 nginx를 기동합니다.

ansible에서 target되는 nginx config파일을 다운로드 받습니다.
nginx.conf 파일을 nginx의 binary를 통해서 검증(-t)를 수행합니다.
Nginx.conf 파일을 기반으로 restart를 수행합니다. (nginx config 파일을 갖고 기동합니다.)
Nginx의 프로세스(systemctl status)를 통해서 정상 기동되었는지 체크를 합니다.
위의 과정을 serial하게 1대씩 진행을 합니다.

위와 같은 과정을 거쳐서 타겟팅 되는 nginx를 1대씩 배포를 수행하고(Rolling Update) 배포 완료시 알람을 발송합니다.

2. ansible folder 구조

Ansible의 git repository 구성에 대해서 정리를 해보도록 하겠습니다.

├── group_vars
│    └── test-web-nginx-prod.yml
├── nginx_deploy.yml
├── test-web-nginx-prod
└── roles
    ├── common
    │   ├── meta
    │   │   └── main.yml
    │   └── tasks
    │       └── main.yml
    └── nginx
        ├── meta
        │    └── main.yml
        ├── tasks
        │     └── main.yml
        └── templates
            └── index.html.j2

ansible inventory 작성은 배포그룹(ex. test-web-nginx-prod) 에 작성

inventory / test-web-nginx-prod

[test-web-nginx-prod]
test1501
test1502
test1503

[webservers:children]
test-web-nginx-prod

inventory / group_vars / test-web-nginx-prod.yml

phase: "prod"
application: "test-web-nginx"
index: true
maintenence: true
members: false
vosdomain: "test-objects.com"
vosbucket: "test-nft"

inventory에는 서버에 대한 정보 설정을 기입합니다. 그리고 관련하여 참조할 변수들을 group_vars 하위에 기입을 합니다.

3. ssh 접속을 위한 사전설정

ansible 서버에서 target 서버로 접속을 하기 위해서는 ssh 설정이 필요합니다. 별도의 비밀번호 없이 public key와 private key를 통해서 접근을 하기 위한 설정입니다.

키생성

$ ssh-keygen -t rsa

키를 저장할 경로( 기본값 : $HOME/.ssh/id_rsa)
passphrase (추가로 사용할 암호, 기본값 없음)
passphrase 확인

ssh key 등록하기

.pub이 공개키 인데 해당 공개키를 서버에 등록하면 다음부턴 비밀번호를 입력할 필요가 없어집니다.

$ mkdir ~/.ssh
$ touch ~/.ssh/authorized_keys
$ chmod 755 ~/.ssh/authorized_keys

Host의 ~/.ssh/id_rsa.pub 에 있는 모든 내용을 복사해서, 접속한 서버의 .ssh 폴더 내에 있는 authorized_keys 파일을 수정해 해당 내용을 모두 붙여 넣고 저장합니다.

이렇게 되면, ansible서버에서 target 서버로 접속이 비밀번호 없이 바로 할 수 있습니다.

4. jenkins 연계

Jenkins를 통해서 ansible playbook 명령어를 호출하여 target 서버에 nginx config를 배포하고 restart를 해주는 내용을 연계하려고 합니다.

jenkins의 파라미터로는 2가지로 선정을 했습니다. nginx가 FE의 서빙 역할을 하기 때문에 application 별로 있습니다.

따라서 application이라는 파라미터를 설정했고, 각 phase(alpha, beta, real) 순서로 파라미터를 설정했습니다.

applicatoin
phase

설정한 값에 맞춰서 ansible playbook 실행시, nginx-config 와 target 서버 목록을 셋팅합니다.

ansible 명령어

$ ansible-playbook -i ${WORKSPACE}/devops-nginx-deploy/inventory/${APPLICATION}-${PHASE} ${WORKSPACE}/devops-nginx-deploy/playbook/nginx_deploy.yml -u irteamsu

ansible roles

# roles/nginx/tasks/main.yml

---
# tasks file for nginx
#- name: install nginx
#  yum: name=nginx state=installed

- name: git clone
  git:
    repo: https://test:xxxxx@github.com/dongwonlee/test-web-nginx.git
    dest: /home1/test/apps/test-web-nginx/
    update: yes
    version: master

- name: copy nginx.config
  copy:
    src: /home1/test/apps/test-web-nginx/config/{{ application }}/nginx-{{ phase }}.conf
    dest: /etc/nginx/nginx.conf
    remote_src: yes

- name: Verify Nginx config
  command: nginx -t
  changed_when: false

- name: Download Index html
  get_url:
    url: https://{{ vosdomain }}/{{ vosbucket }}-{{ phase }}/index.html
    dest: /etc/nginx/index.html
    force: true
  when: index | bool

- name: Reload nginx config
  service: name=nginx state=reloaded enabled=yes

- name: check nginx status
  command: systemctl status nginx
  register: process
  failed_when: "'running' not in process.stdout"

ansible yaml 파일을 보면, 기존의 수동으로 하던 작업들을 일련의 작업으로 순서화를 시킨내용입니다.

git clone
verify nginx
download resource ( index.html )
reload nginx cofig
check nginx status

5. 테스트

기본적으로 ansible은 병렬 수행을 하는데, serial 수행으로 옵션을 줄 수 있습니다.

Playbook / nginx_deploy.yml

---
- hosts: webservers
  become: yes
  serial: 1
  roles:
    - nginx

위와 같이 serial: 1을 주게 되면, 1대씩 실행을 합니다. 아래 결과에서 보듯이 2대의 서버를 1대씩 진행하고 결과를 출력해주고 있습니다.

PLAY [webservers] **************************************************************

TASK [Gathering Facts] *********************************************************
ok: [test-web-nginx001-dev]

TASK [nginx : git clone] *******************************************************
ok: [test-web-nginx001-jp2v-dev]

TASK [copy nginx.config] *******************************************************
ok: [test-web-nginx001-dev]

TASK [nginx : Verify Nginx config] *********************************************
ok: [test-web-nginx001-dev]

TASK [nginx : Download Index html] *********************************************
changed: [test-web-nginx001-dev]

TASK [Reload nginx config] *****************************************************
changed: [test-web-nginx001-dev]

TASK [check nginx status] ******************************************************
changed: [test-web-nginx001-dev]

PLAY [webservers] **************************************************************

TASK [Gathering Facts] *********************************************************
ok: [test-web-nginx002-dev]

TASK [nginx : git clone] *******************************************************
ok: [test-web-nginx002-dev]

TASK [copy nginx.config] *******************************************************
ok: [test-web-nginx002-dev]

TASK [nginx : Verify Nginx config] *********************************************
ok: [test-web-nginx002-dev]

TASK [nginx : Download Index html] *********************************************
changed: [test-web-nginx002-dev]

TASK [Reload nginx config] *****************************************************
changed: [test-web-nginx002-dev]

TASK [check nginx status] ******************************************************
changed: [test-web-nginx002-dev]

PLAY RECAP *********************************************************************
test-web-nginx001-dev : ok=8    changed=3    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0   
test-web-nginx002-dev : ok=8    changed=3    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0

6. 마치며

ansible은 여러대의 config 설정과 같이 다양한 환경에서 반복적이고 여러대의 작업에서 수행되는 작업을 할 때 굉장히 유용한것 같습니다. 본 포스팅은 사내의 시스템이 있었는데 설정도 배포도 상당히 어려움이 있어서 ansible을 통해서 간단하게 jenkins 연계를 통하여 nginx 설정 배포를 할 수 있도록 구성했습니다.

다음 시간에는 ansible을 실행하고 job들을 관리할 수 있는 ansible tower(AWX)에 대해서 정리해보고 적용해보는 시간을 갖도록 하겠습니다.

The post [DevOps] ansible nginx config 배포 구성 appeared first on WONIZZ.LOG.

[DevOps] Nginx 컴파일 설치

워니 — Wed, 09 Feb 2022 01:39:24 +0000

안녕하세요? 정리하는 개발자 워니즈 입니다. 2022년의 첫 포스팅입니다. 그동안 업무로 인해 블로그 정리에 대해서 소홀했던 것 같습니다. 저의 블로그에 방문해주시는 모든 분들 새해복 많이 많이 받으셨으면 좋겠습니다. 🙇

1월 경에는 이것저것 설치와 구성을 많이 하는 달이였던 것 같습니다. 특히 필자는 nginx에 관심이 굉장히 많습니다. nginx는 간단한게 웹서버를 구성해줄 수 있을 뿐더러, reverse proxy 역할을 수행함으로써 적절한 LB의 역할도 수행을 해줍니다.

Nginx에 관한 시리즈 포스팅은 아래에서 확인이 가능합니다.

1. Nginx compile 설치

필자는 그동안 package manager를 통해서 간편하게 nginx를 설치했었습니다. 이렇게 설치했을 경우에는 별도의 module을 설치하거나 customizing을 하기 어렵다는 단점이 있습니다. 정형화된 nginx만을 사용하게 됩니다.

1. 필수 패키지 다운로드

nginx를 compile 방식으로 설치하기 위해서는 반드시 필요한 의존성 라이브러리들이 있습니다.

PCRE(Perl Compatible Regular Expressions)
Nginx는 Perl5에서 사용하는 정규표현식 라이브러리인 PCRE를 사용합니다. Ngix의 재작성모듈과 HTTP 코어 모듈은 PCRE 구문에 따르는 정규표현식을 사용합니다.
openssl
https 모듈인 HttpSslModule을 사용하기 위해서는 openssl 이 필요합니다.
zlib
zlib 라이브러리는 개발자에게 압축 알고리즘을 제공합니다. ngx_http_gzip_module 을 사용하기 위해서는 zlib 라이브러리가 있어야 합니다.

필자는 위의 소스를 다음과 같은 방법으로 다운로드를 받았습니다.

#root 계정을 통해서 pkgs 폴더 생성 
$ cd /
$ mkdir pkgs 
$ cd pkgs

#필수 패키지 다운로드 
$ wget http://nginx.org/download/nginx-1.20.1.tar.gz
$ wget https://ftp.openssl.org/source/old/1.1.1/openssl-1.1.1l.tar.gz
$ wget https://free.nchc.org.tw/osdn//sfnet/p/pc/pcre/pcre/8.44/pcre-8.44.tar.gz
$ wget https://fossies.org/linux/misc/zlib-1.2.11.tar.gz

#압축 해제 
$ tar -zxvf nginx-1.20.1.tar.gz
$ tar -zxvf openssl-1.1.1l.tar.gz
$ tar -zxvf pcre-8.44.tar.gz
$ tar -zxvf zlib-1.2.11.tar.gz

설치는 아래의 순서대로 진행하게 됩니다.

configure : 환경설정
make : 설치파일을 컴파일
make install : 설치파일을 이용해서 설치

2. configure를 통한

이제 필요한 준비는 모두 됐습니다. 아래의 순서대로 설치가 진행이 됩니다. 먼저 configure를 통해서 위에 준비한 재료들을 사용한다고 설정(configure)를 진행합니다.

# variable 설정
NGINX_VERSION=1.20.1
PCRE_VERSION=8.44
OPENSSL_VERSION=1.1.1l
ZLIB_VERSION=1.2.11
NGINX_PATH=/home1/irteam/apps/nginx-${NGINX_VERSION}

# 필요 패키지 설치
$ yum install gcc-c++ pcre-devel zlib-devel make wget openssl-devel which libxml2-devel unzip libxslt-devel gd-devel perl-ExtUtils-Embed GeoIP-devel git gperftools-devel libcurl-devel file -y

# nginx 경로 생성
$ mkdir -p /pkgs /home1/irteam/apps

# configure
./configure --prefix=${NGINX_PATH} \
    --user=irteamsu --group=irteamsu \
    --with-http_ssl_module \
    --with-http_stub_status_module \
    --with-http_realip_module \
    --with-http_v2_module \
    --with-pcre=/pkgs/pcre-${PCRE_VERSION} \
    --with-openssl=/pkgs/openssl-${OPENSSL_VERSION} \
    --with-zlib=/pkgs/zlib-${ZLIB_VERSION}

위의 설정은 금방 진행이 됩니다.

–with-(zlib | pcre | openssl) : NGINX가 의존하고 있는 라이브러리들의 소스 경로
–with-(http_ssl_module | debug) : NGINX를 설치할 때 ssl, debug 모듈을 활성화한다. 이 모듈들은 NGINX가 제공하는 내부 모듈이지만 기본적으로는 설치가 되지 않는 옵션사항이다.
–prefix : NGINX가 설치될 기본 디렉토리를 의미한다. 이 디렉토리 하위에 NGINX의 실행, 로깅, 설정 파일들이 설치된다. 각각의 항목을 바꿀 수도 있다. 메뉴얼을 참고하자.
–user, –gourp : irteam 사용자의 권한으로 NGXIN를 실행시킨다. Irteam 사용자가 없다면 만들어야 한다. 사용자의 리스트는 아래의 명령을 통해서 알 수 있다. irteam가 아니라 자기 자신의 계정을 사용해도 된다.

3. make & make install

이제는 소스코드의 compile을 진행합니다. 이부분은 다소 시간이 소요되는 부분입니다.

$ make

아래와 같이 설정한 directory에서 정상적으로 빠져나왔다는 문구가 출력이 되면, 컴파일이 정상적으로 된 것입니다.

sed -e "s|%%PREFIX%%|/home1/irteam/apps/nginx-1.20.1|" \
        -e "s|%%PID_PATH%%|/home1/irteam/apps/nginx-1.20.1/logs/nginx.pid|" \
        -e "s|%%CONF_PATH%%|/home1/irteam/apps/nginx-1.20.1/conf/nginx.conf|" \
        -e "s|%%ERROR_LOG_PATH%%|/home1/irteam/apps/nginx-1.20.1/logs/error.log|" \
        < man/nginx.8 > objs/nginx.8
make[1]: Leaving directory `/pkgs/nginx-1.20.1'

정상적으로 compile된 내용물을 설치(디렉토리를 옮김)하는 과정입니다.

$ make install

아래와 같이 정상적으로 지정한 폴더에 내용물을 옮기는 과정이 출력됩니다.

make -f objs/Makefile install
make[1]: Entering directory `/pkgs/nginx-1.20.1'
test -d '/home1/irteam/apps/nginx-1.20.1' || mkdir -p '/home1/irteam/apps/nginx-1.20.1'
test -d '/home1/irteam/apps/nginx-1.20.1/sbin' \
        || mkdir -p '/home1/irteam/apps/nginx-1.20.1/sbin'
test ! -f '/home1/irteam/apps/nginx-1.20.1/sbin/nginx' \
        || mv '/home1/irteam/apps/nginx-1.20.1/sbin/nginx' \
                '/home1/irteam/apps/nginx-1.20.1/sbin/nginx.old'
cp objs/nginx '/home1/irteam/apps/nginx-1.20.1/sbin/nginx'
test -d '/home1/irteam/apps/nginx-1.20.1/conf' \
        || mkdir -p '/home1/irteam/apps/nginx-1.20.1/conf'
cp conf/koi-win '/home1/irteam/apps/nginx-1.20.1/conf'
cp conf/koi-utf '/home1/irteam/apps/nginx-1.20.1/conf'
cp conf/win-utf '/home1/irteam/apps/nginx-1.20.1/conf'
test -f '/home1/irteam/apps/nginx-1.20.1/conf/mime.types' \
        || cp conf/mime.types '/home1/irteam/apps/nginx-1.20.1/conf'
cp conf/mime.types '/home1/irteam/apps/nginx-1.20.1/conf/mime.types.default'
test -f '/home1/irteam/apps/nginx-1.20.1/conf/fastcgi_params' \
        || cp conf/fastcgi_params '/home1/irteam/apps/nginx-1.20.1/conf'
cp conf/fastcgi_params \
        '/home1/irteam/apps/nginx-1.20.1/conf/fastcgi_params.default'
test -f '/home1/irteam/apps/nginx-1.20.1/conf/fastcgi.conf' \
        || cp conf/fastcgi.conf '/home1/irteam/apps/nginx-1.20.1/conf'
cp conf/fastcgi.conf '/home1/irteam/apps/nginx-1.20.1/conf/fastcgi.conf.default'
test -f '/home1/irteam/apps/nginx-1.20.1/conf/uwsgi_params' \
        || cp conf/uwsgi_params '/home1/irteam/apps/nginx-1.20.1/conf'
cp conf/uwsgi_params \
        '/home1/irteam/apps/nginx-1.20.1/conf/uwsgi_params.default'
test -f '/home1/irteam/apps/nginx-1.20.1/conf/scgi_params' \
        || cp conf/scgi_params '/home1/irteam/apps/nginx-1.20.1/conf'
cp conf/scgi_params \
        '/home1/irteam/apps/nginx-1.20.1/conf/scgi_params.default'
test -f '/home1/irteam/apps/nginx-1.20.1/conf/nginx.conf' \
        || cp conf/nginx.conf '/home1/irteam/apps/nginx-1.20.1/conf/nginx.conf'
cp conf/nginx.conf '/home1/irteam/apps/nginx-1.20.1/conf/nginx.conf.default'
test -d '/home1/irteam/apps/nginx-1.20.1/logs' \
        || mkdir -p '/home1/irteam/apps/nginx-1.20.1/logs'
test -d '/home1/irteam/apps/nginx-1.20.1/logs' \
        || mkdir -p '/home1/irteam/apps/nginx-1.20.1/logs'
test -d '/home1/irteam/apps/nginx-1.20.1/html' \
        || cp -R html '/home1/irteam/apps/nginx-1.20.1'
test -d '/home1/irteam/apps/nginx-1.20.1/logs' \
        || mkdir -p '/home1/irteam/apps/nginx-1.20.1/logs'
make[1]: Leaving directory `/pkgs/nginx-1.20.1'

2. 기본 설정

1. /usr/bin

global 하게 nginx binary를 실행할 수 있도록 /usr/bin/경로로 nginx binary를 copy해줍니다.

$ cp /home1/irteam/apps/nginx-1.20.1/sbin/nginx /usr/bin

먼저 설치한 경로로 이동을 해봅니다.

2. systemd 설정

daemon 형태로 명령어를 사용하기 위해서 systemd에 등록을 해줍니다.

$ vi /etc/systemd/system/nginx.service

[Unit]
Description=The NGINX HTTP and reverse proxy server
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/bin/nginx -t
ExecStart=/usr/bin/nginx
ExecReload=/usr/bin/nginx -s reload
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

3. symbolic link 설정

이부분은 필자만의 custom 사용인데, package manager를 사용하여 설치하게 되면 /etc/nginx 경로에 설치가 됩니다. 필자는 이경로로에서 config 제어를 하기 위해서 symbolic link를 걸어두기로 했습니다.

$ ln -s /etc/nginx/nginx.conf /home1/irteam/apps/nginx-1.20.1/conf/nginx.conf

3. 정상 설치 확인

먼저 nginx의 설정이 정상적인지를 체크합니다.

$ nginx -t
nginx: the configuration file /home1/irteam/apps/nginx-1.20.1/conf/nginx.conf syntax is ok
nginx: configuration file /home1/irteam/apps/nginx-1.20.1/conf/nginx.conf test is successful

nginx의 daemon 상태를 확인합니다.

$ systemctl status nginx
   Loaded: loaded (/etc/systemd/system/nginx.service; disabled; vendor preset: disabled)
   Active: inactive (dead)

nginx의 daemon을 기동합니다

$ systemctl start nginx
$ systemctl status nginx
● nginx.service - The NGINX HTTP and reverse proxy server
   Loaded: loaded (/etc/systemd/system/nginx.service; disabled; vendor preset: disabled)
   Active: active (running) since Wed 2022-02-09 10:26:30 JST; 1s ago
  Process: 149360 ExecStart=/usr/bin/nginx (code=exited, status=0/SUCCESS)
  Process: 149359 ExecStartPre=/usr/bin/nginx -t (code=exited, status=0/SUCCESS)
 Main PID: 149363 (nginx)
   CGroup: /system.slice/nginx.service
           ├─149363 nginx: master process /usr/bin/nginx
           └─149364 nginx: worker process

Feb 09 10:26:30 ansible001-lnk8s-temp-jp2v-prod nginx[149359]: nginx: the configura...
Feb 09 10:26:30 ansible001-lnk8s-temp-jp2v-prod nginx[149359]: nginx: configuration...
Hint: Some lines were ellipsized, use -l to show in full.

4. Module 추가

서두에 정리했다시피, nginx를 위의 과정을 통해서 compile하는 이유는 module을 설치할 수 있다는 장점이 있습니다. 모듈에 대한 리스트는 아래의 페이지에서 확인할 수 있습니다.

NGINX 3rd Party Modules

필요한 모듈을 설치 과정에서 pkgs 폴더에 다운로드를 받습니다. 그렇게 된 상태에서 configure과정에서 add-module을 통해서 모듈을 참조하도록 해줍니다. 위의 설치 과정과 다른 부분은 마지막줄이 다릅니다.

./configure --prefix=${NGINX_PATH} \
    --user=irteamsu --group=irteamsu \
    --with-http_ssl_module \
    --with-http_stub_status_module \
    --with-http_realip_module \
    --with-http_v2_module \
    --with-pcre=/pkgs/pcre-${PCRE_VERSION} \
    --with-openssl=/pkgs/openssl-${OPENSSL_VERSION} \
    --with-zlib=/pkgs/zlib-${ZLIB_VERSION} \
    --add-module=/pkgs/sample_module-${SAMPLE_VERSION}-x64

이러한 과정을 통해서 필요한 외부의 모듈을 탑재할 수 있습니다.

5. 마치며…

이번시간에는 nginx의 compile을 통해서 설치하는 과정에 대해서 정리를 해보았습니다. 그동안 패키지 매니저에 너무 익숙해져서 왜 이렇게 복잡한 과정을 걸쳐서 설치를 하는지 이해를 못했었습니다. 하지만, 이러한 과정에는 모듈의 설정이 연관이 있다는 것을 알게 됐습니다.

DevOps 입장에서 이러한 과정들을 하나로 엮어서 자동화 했으면 하는 생각이 들었습니다. 우선 다음시간에는 ansible을 통해서 nginx의 config 설정을 업데이트 하는 내용에 대해서 정리를 해보려고 합니다. 그리고 이후에는 nginx의 설치 과정에 대해서도 ansible을 통해서 손쉽게 구성이 가능하도록 해보려 합니다.

6. 참조

NGINX 컴파일

Nginx 서버 설치와 환경 설정

[Web Server] Nginx 1.6.2 컴파일 설치

Nginx를 CnetOS 7에 소스 컴파일 설치

The post [DevOps] Nginx 컴파일 설치 appeared first on WONIZZ.LOG.

[DevOps] Rinetd를 활용한 portforward

워니 — Wed, 03 Mar 2021 08:36:40 +0000

안녕하세요? 정리하는 개발자 워니즈 입니다. 이번시간에는 Public subnet에있는 Deploy tool을 통해서 Private Subnet에 존재하는 서버들에 대해서 배포를 수행하기 위한 고민을 했던 포스팅 입니다. 필자가 소속된 프로젝트에서는 운영 환경에서 2개 이상의 AWS Region에서 서비스를 하고 있습니다. Deploy 같은 경우 하나의 Tool(Rundeck)에서 수행되어야 하는 것을 목표로 했었습니다. 이번 포스팅에서 소개할 내용은 rinetd라는 포트포워딩 툴입니다.

1. 구성 상황

서두에 기록을 해두었지만, 2개 이상의 Region에서 운영되는 서비스인데다가, 한개의 region의 public영역에서 다른 region의 private영역으로 연결을 시도할 때가 당연히 문제가 되었습니다. 그렇다고, 각 region별로 deploy tool을 둘수도 없는 상황이기에 약간의 꼼수(?)를 부리기 위해서 알아보다보니, rinetd를 알게 되었고, 한개의 region의 public에서 다른 region의 public으로 붙은다음에 거기서 포트포워딩으로 패킷을 전달해주는 방식을 채택하기로 했습니다.

2. rinetd란 무엇인가요?

TCP 연결을 한 IP 주소 및 포트에서 다른 IP로 리다이렉션을 수행하게끔 해주는 툴입니다. 설정 파일을 통해서 from에서 to로 명시적으로 기록을 합니다. 설정 파일을 통해서 수행되지만, nonblocking I/O를 이용하여 단일 프로세스로 수행되기 떄문에 프로세스 수행상에 문제를 발생시키지 않는다고 되어있습니다.

3. rinetd 설치 방법

# /etc/yum.repos.d/nux-misc.repo 내 추가 
[nux-misc]
name=Nux Misc
baseurl=http://li.nux.ro/download/nux/misc/el7/x86_64/
enabled=0
gpgcheck=1
gpgkey=http://li.nux.ro/download/nux/RPM-GPG-KEY-nux.ro

# rinetd 설치
yum --enablerepo=nux-misc install rinetd

설치는 상당히 심플 합니다. yum을 통해서 설치를 진행하면 되고, 포트포워딩을 수행할 서버에서 설치를 진행하면 됩니다.

3. rinetd 설정 방법

# rinetd 설정 파일 수정
vi /etc/rinetd.conf

실제 설정파일에는 가이드도 친절하게 젂혀 있습니다. 예를들어, 10.10.10.2(rinetd가 설치된 서버) 80 포트로 접속을 수행했을때, 192.168.0.2:80 으로 보내라는 설정은 다음과 같습니다.

0.0.0.0 80 192.168.0.2 80

IP기반으로 ACL에 대한 설정도 가능합니다.

# 172.16.32.0/24 대역 ALLOW
allow 172.16.32.*

# 192.168.32.12 아이피 DENY
deny 192.168.32.12

로그에 대한 기록도 수행해 줍니다.

# log 경로 셋팅
logfile /var/log/rinetd.log

설정을 모두 마친후, rinetd를 재시작하게 되면 적용이 됩니다.

[root@testuser ec2-user]# service rinetd restart
Restarting rinetd (via systemctl):                         [  OK  ]

4. 접속 테스트

그럼 서두에 기록했던, 한개의 region public subnet의 인스턴스에서 다른 region의 public subnet의 인스턴스로 접속을 수행합니다. ap regsion public A ec2 -> eu region public B ec2 ->portforward -> eu region private C ec2

5. 마치며..

이번 시간에는 rinetd를 활용한 포트포워딩 프로그램에 대해서 정리해보는 시간을 갖었습니다. 네트워크 쪽은 공부를 하면 할수록 정말 어려운 분야 인 것 같습니다. VPC 설계부터 subnet 그리고 route table, NAT의 개념에 대해서도 다시금 정리를 해두어야 할것 같다는 생각을 해보았습니다.

함께 보면 좋은 글

The post [DevOps] Rinetd를 활용한 portforward appeared first on WONIZZ.LOG.

[DevOps] Apache rewrite rule 정리

워니 — Tue, 03 Nov 2020 05:50:26 +0000

안녕하세요 정리하는 개발자 워니즈입니다. 이번시간에는 아파치 config 중에 rewrite 룰에 대해서 정리를 해보려고 합니다. 필자가 속한 프로젝트에서는 Apache를 웹서버로 사용하고 있습니다. 그러다보니, apache에 들어가있는 configuration에 대해서 알아야 되는데요. 그중에서도 rewrite rule이 있습니다. Apache의 rewrite Module은 아파치 모듈주의 한종류로 서버 Request를 정해진 Rule에 의해서 다른 URL or File로 보내는 모듈입니다.

1. Rewrite 모듈 지시자

RewriteEngine

Rewriting 엔진을 사용할지 여부를 설정합니다. 기본설정은 Off로 되어 있으며 RewriteEngine On으로 설정하면 Rewriting 엔진이 활성화 됩니다.

RewirteLog File-Path

RewriteLog 지시자는 Rewrite 엔진의 로그를 그록할 파일을 지정합니다. RewriteLog 파일을 항상 남기기 보다 잘못된 Rewrite 규칙들을 디버킹할 때 사용하기를 권장합니다. 아파치와 마찬가지로 RewriteLog 파일도 방문자 수가 많은 사이트에서는 많은 로그파일이 쌓이기 때문에 해당 파티션의 여유공간이 많이 없는 시스템에서는 장래를 유발 할수도 있으므로 로그를 잘 관리 해야 합니다.

RewriteLogLevel Level

RewriteLogLevel 지시자는 RewriteLog 지시자로 설정한 로그파일에 기록할 로그들에 대해 얼마나 자세한 내용을 로그로 남길것인가에 대해 설정하는 지시자입니다. 기록할 로그 Level 은 0 ~ 9까지 사용할 수 있으며 0은 로그를 기록하지 않겠다는 의미입니다.

2. Rewrite Flag

RewriteRule 문법중 마지막에 패턴이 일치할 경우 어떤 동작을 취할지 지정하는 부분이며, 이를 플래그라고도 합니다. 지정할 수 있는 플래그중 자주 사용되는 것들은 다음과 같은 항목이 있습니다. 플래그는 전체 단어를 써도 되지만 축약어로 써도 됩니다. 필자의 프로젝트에 적용된 것을 위주로 정리를 해보겠습니다.

Last : L

Last 플래그는 더이상 mod_rewrite 룰 처리를 하지 않겠다는 의미이다. 프로그래밍 언어에서 break 와 비슷한 용도로 사용되며 여러 개의 RewriteRule 룰을 연결해서 사용하는 경우 더 이상의 처리를 하지 않아도 될 때 유용하게 사용할 수 있다.

Nocase : NC

Nocase 는 패턴 매칭할 경우 대소문자 구분을 하지 않겠다는 의미이다.

Noescape: NE 기본적으로 & 및 ?와 같은 특수 문자는 16진수 등가로 변환된다. [NE] 플래그를 사용하면 그런 일이 발생하지 않는다.

RewriteRule “^/anchor/(.+)” “/bigpage.html#$1” [NE,R] 위의 예는 /anchor/xyz를 /bigpage로 리디렉션한다.html#xyz. [NE]를 생략하면 #가 16진수 등가 %23로 변환되어 404 Not Found 오류 상태가 된다.

Redirect:R

리다이렉트 플래그는 규칙에 일치할 경우 HTTP 302 Redirect 응답을 클라이언트에게 전송한다. 만약 HTTP 301 Moved Permanently 응답을 전송해야 한다면 R=301 로 적어주면 된다.

Passthru:PT

RewriteRule 의 target_url 이 http 나 https 로 시작하지 않으면 mod_rewrite 는 target_url 을 로컬 파일의 경로로 인식한다. / 로 시작할 경우 절대 경로로 / 가 아닐 경우 상대 경로로 처리하게 된다. 파일 경로로 처리할 경우 스크립트 파일의 경우 파일의 내용이 그대로 노출될 우려가 있다.

qsappend: QSA

mod_rewrite 는 기본적으로 클라이언트가 GET 으로 전송한 변수를 무시한다. 이 변수 값은 QUERY_STRING 이라는 변수명에 저장된다. QSA(Query String Append) 플래그를 사용하면 QUERY_STRING 을 무시하지 않고 유지시키므로 URL 전환시에도 문제가 없다.

3. RewriteCond

앞에서 RewriteRule 에 대한 설명을 보고 만약 조건문이 필요할 경우는 어떻게 해야 할지 의문이 생긴 독자들도 있을 것이다. RewriteCond 는 그런 독자들의 의문을 해소해 줄 지시자이다. 여러 가지 상황별로 조건을 확인하고 그 조건이 맞을 경우 처리를 하게 할 수 있다. RewriteCond는 다음과 같은 문법을 갖는다. RewriteCond TestString Pattern [Flags] TestString 에는 다음과 같은 값등을 사용할 수 있다.

직전 RewriteRule 에서 일치한 캡처값 – RewriteCond 앞에 RewriteRule 을 사용했고 정규 표현식에서 그룹으로 지정된 값이 있을 경우 TestString 에 사용할 수 있다. 사용할 경우 $N (N 은 0 에서 9사이 값) 형식으로 사용한다.
직전 RewriteCond 에서 일치한 캡처값 – RewriteCond 앞에 RewriteCond를 사용했고 정규 표현식에서 그룹으로 지정된 값이 일치했을 경우 %N(N 은 0 에서 9) 형식으로 사용할 수 있다.
서버 변수 – 웹서버가 갖고 있는 변수값을 사용할 수 있다. 서버의 변수를 사용할 경우 %{변수명} 형식으로 사용한다. 제일 많이 사용하는 변수들은 %{HTTP_HOST}, %{QUERY_STRING} 등이다.

변수명	설명
HTTP 요청 변수
HTTP_HOST	URL 에서 호스트 이름 부분이며 클라이언트가 보낸 HTTP 헤더중 Host: 헤더에 있는 값이 된다. 가상 호스트 기반 rewrite 규칙을 설정할 경우에 많이 사용된다.
HTTP_REFERER	사용자가 현재 요청시 어떤 링크를 통해 들어왔는지 알수 있는 변수이다.
REQUEST_METHOD	HTTP 요청 메소드로 보통 GET 또는 POST 가 된다.
QUERY_STRING	GET 방식으로 URL 을 호출했을 때 넘긴 파라미터가 설정된다. 예로 “http://www.example.com/article/view.jsp?one=two&three=four” 로 호출했을 경우, QUERY_STRING 은 “one=two&three=four” 가 된다.
REQUEST_URI	클라이언트가 요청한 리소스로 보통 URL 에서 호스트 이름과 파라미터를 제외한 부분이 된다. 위 QUERY_STRING 예제에서 REQUEST_URI는 “article/view.jsp” 가 된다.
클라이언트 변수
HTTP_USER_AGENT	사용자 브라우저 정보가 설정
HTTP_ACCEPT	브라우저가 처리할 수 있는 컨텐츠의 목록
REMOTE_ADDR	요청 클라이언트가 사용하는 IP
REMOTE_USER	로그인이 필요한 리소스에 접근할 경우 사용자명
서버 내부 변수
DOCUMENT_ROOT	현재 가상 호스트에 설정한 DocumentRoot 의 경로를 얻을 수 있다.
REQUEST_FILENAME	클라이언트가 요청한 파일이나 스크립트가 현재 서버에 위치하는 절대 경로를 의미한다. 현재 가상호스트의 DocumentRoot 가 “/var/www/vhost1” 이고 클라이언트가 /book.php 를 요청했을 경우 REQUEST_FILENAME 은 /var/www/vhost1/book.php 가 된다.
SERVER_NAME	The canonical name of the current virtual host.
SERVER_ADDR	The IP address of the current virtual host.
SERVER_PORT	The port number from which the current request is being served.
HTTPS	SSL 이나 TLS 를 사용할 경우 on 으로 설정되고 HTTP 일 경우 off 이다.

Pattern 에는 정규식으로 일치시킬 문자열의 패턴을 기술하면 된다. 마지막 플래그는 다음과 같은 값을 사용할 수 있다.

NoCase:NC – RewriteRule 과 마찬가지로 대소 문자를 구분하지 않을 경우 사용한다.
ORNext:OR – OR 플래그는 여러 개의 RewriteCond 를 사용할 경우 논리적인 OR 조건이 필요할 때 사용할 수 있다.(여러 개의 RewriteCond 가 있을 때 기본적으로 AND 로 처리한다.)

4. 실제 사용 사례

필자의 프로젝트에서 사용하는 RewriteRule에 대해서 정리를 해보도록 하겠습니다.

    # 1단계 URL 을 그냥 통과 시킬 리스트 적용
    RewriteCond %{REQUEST_URI} ^/etc/designs(.*) [NC,OR]
    RewriteCond %{REQUEST_URI} ^/etc.clientlibs(.*) [NC,OR]
    RewriteCond %{REQUEST_URI} ^/apps/samsung/login(.*) [NC,OR]
    RewriteCond %{REQUEST_URI} ^/bin(.*) [NC,OR]
    RewriteCond %{REQUEST_URI} ^/aemapi(.*) [NC,OR]
    RewriteCond %{REQUEST_URI} ^/sysapi(.*) [NC,OR]
    RewriteCond %{REQUEST_URI} ^/libs/granite/csrf/token [NC,OR]
    RewriteCond %{REQUEST_URI} ^/samsung(.*) [NC,OR]
    RewriteCond %{REQUEST_URI} ^/content/dam(.*) [NC]
    RewriteRule ^(.*)$ $1 [PT]

위의 예제는 재작성 조건에 대해서 여러개를 연결 시켜 놓은 것입니다. 개발코드로 치면 조건문에서 or조건으로 여러개의 체크 조건을 갖고 있습니다.

대소문자를 가리지 않는다. [NC]
조건체크를 or조건으로 한다. [OR]
최종 나온 path에 대해서 그대로 통과 시킨다. [PT]

# 2단계 /content/samsung 이 붙어 있을 경우 제거
RewriteCond %{REQUEST_URI} ^/content/samsung/(.*)$ [NC]
RewriteRule ^/content/samsung/(.*)$ /$1 [R=302,NE,QSA,L]

위의 조건은 url 요청이 특정 문자열(/content/samsung)을 붙이고 들어올때, 그부분을 제거하는 내용입니다.

/content/samsung을 떼어주되, 특수문자를 그대로 둡니다.[NE]
query string에 대해서 그대로 append 해줍니다.[QSA]
302 redirectino 처리를 하고 break를 수행합니다.[R=302, L]

# 3단계 /가 없거나 확장자가 없을때 / 붙여줌
RewriteCond %{REQUEST_URI} !.*\..*$
RewriteCond %{REQUEST_URI} !.*/$
RewriteRule ^(.*)$ $1/ [R=302,NE,QSA]

# handle requests to pages ending with .html
# 4단계 .html 로 끝날경우 / 를 붙여줌
RewriteCond %{REQUEST_URI} .*.html$
RewriteRule ^(.*).html$ $1/ [R=302,NE,QSA]

3단계와 4단계는 유사합니다. 모든 request에 대해서 끝에 슬래시를 추가해주는 내용입니다.

확장자가 없거나 (!...$), 슬래시가 없거나 (!.*/$)의 조건을 찾음.
.html로 끝나는 경우(.*.html$)
특수문자 처리, query string append, Redirection 처리[R=302,NE,QSA]

# 5단계 앞의 작업이 끝났을경우 인터널로 호출할때 /content/samsung 을 붙여줌  
# 앞에서 빼고 뒤에서 붙이는 이유는 사전 URL 작업을 진행하고 내부로 호출하기 위해서임
RewriteCond %{REQUEST_URI} ^/(.*)$ [NC]
RewriteRule ^/(.*)$ /content/samsung/$1 [NE,QSA]

# 6단계 내부적으로 호출할때 html 을 붙여줌
RewriteCond %{REQUEST_URI} .*/$
RewriteCond %{REQUEST_URI} !^/$
RewriteRule ^(.*)/$ $1.html [PT,NE,L,QSA]

5단계와 6단계를 거치면서 내부의 internal server(was)로 페이지를 요청하기 위해서 다시 /content/samsung과 확장자(.html)을 붙여줍니다.

5. apache debug 방법

아파치 rewriterule을 셋팅하면서 항상 어려웠던 부분이 rewrite rule에 대한 디버깅이였습니다. 서칭을 좀 하다보니, online으로 rewrite rule을 테스팅 해볼 수 있는 사이트가 있었습니다. online rewrite test tool 아래에 rewrite rule에 대해서 읿력을 하고, 위에 request 되는 url에 대해서 입력을 하면, 아래에 debugging된 내용이 노출이 됩니다. 이것을 통해서 개략적인 rewrite rule에 대해서 확인을 해 볼 수 있습니다.

6. 마치며…

이번시간에는 apache rewrite rule에 대해서 정리를 해 보았습니다. apache의 지극히 일부의 모듈에 대해서 정리를 한것이고, 지난 포스팅과 더불어 nginx, apache의 설정들에 대한 정리는 지속적으로 해볼 예정입니다. nginx-aapche-was로 이어지는 트래픽 흐름의 중간에 어디 부분에서 오류를 일으키고, 어떤 부분을 고쳐야 되는지 확인하기 위해서 각각의 미들웨어 + 어플리케이션 로그를 확인할줄도 알아야된다는 것을 느꼇습니다.

함께 보면 좋은 글

The post [DevOps] Apache rewrite rule 정리 appeared first on WONIZZ.LOG.

[DevOps] Nginx Configuration 정리

워니 — Tue, 20 Oct 2020 07:36:12 +0000

안녕하세요? 정리하는 개발자 워니즈입니다. 이번시간에는 Nginx의 configuration에 대해서 정리를 해보고자 합니다. 필자의 프로젝트에서는 웹서버로 Nginx를 사용하고 있습니다. Nginx의 configuration의 변경이 매우잦은 편입니다. 주로 redirection에 대한 처리를 Nginx를 통해서 하다보니 엄청나게 크게 변경이 되는것은 아니지만 이번 포스팅을 통해서 Nginx에서 사용하는 설정에 대해서 정리를 해보고자 합니다 .

1. nginx의 동작 방식

nginx 의 가장 큰 특징은 비동기 Event Driven에 의한 Non Blocking 처리를 한다는 것입니다. apache 서버에 비해 메모리소모량이 젂어지면서 동시 처리수를 급격하게 늘릴 수 있습니다. 요청이 아무리 많아도 Process 또는 Thread 생성 비용이 존재하지 않습니다. Single Thread 기반으로 Master / Worker 프로세스로 구동되면서 context switching을 하지 않기 떄문에 CPU 사용률을 감소 시킬 수 있습니다 . 먼저 apache의 동작 방식을 정리해보겠습니다.

Apache는 병렬 처리 동작방식은 기본적으로 Apache Process 기반 방식으로 클라이언트 요청들을 처리 합니다. 요청에 따라 프로세스를 생성하는 Multi Process Module-prefork 방식과 worker 방식이 있습니다.
요청에 따라 Process가 늘어나고 한개의 요청 처리중 다른 처리를 위한 Context switching으로 인해 부하가 걸림.

다음은 nginx의 동작방식에 대해서 정리하겠습니다.

Event Driven 방식으로 클라이언트 요청 병렬처리를 진행합니다. 기본적으로 싱글 프로세스 기반으로 이벤트를 받는 reactor와 이벤트를 각 worker로 전달하는 handler로 구성되어 있습니다.
process를 prefork하는 과정이 없이 요청온 request에 대한 행동에 대해서만 각 worker로 넘기고 계속해서 요청을 받기 떄문에 처리가 빠릅니다.
비동기 처리로 인한 메모리 사용이 효율적이다.

2. nginx configuration 정리

nginx 공식 document

최상단 모듈 (Core)

user root;                              // 워커 프로세스의 권한을 지정한다. 
worker_processes 1;                     // auto도 무방하지만, 코어 수 만큼 할당하는 것이 보통입니다. 
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;                 // nginx의 마스터 프로세스 ID 정보가 저장됩니다. 
events {
    worker_connections 1024;            // 하나의 프로세스가 처리 할 수 있는 커넥션 수입니다. 
}

http 블락

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    log_format main '[NGINX-ACCESS-LOG] [$time_local] $remote_addr to: $upstream_addr: $status: upstream $upstream_status $request upstream_response_time $upstream_response_time msec $request_time referer: [$http_referer] xff: [$proxy_add_x_forwarded_for] args: [$args] body: $request_body user-agent: [$http_user_agent]';

    sendfile on;                       // 응답을 보낼 때 바로 kernel file buffer를 사용하도록 하여, user-space의 buffuer 메모리를 사용하지 않아 보다 빠른 성능을 보장한다고 합니다.

    keepalive_timeout 65;              // 접속시 커넥션을 몇 초동안 유지할지에 대한 설정값.

    map_hash_bucket_size 10240;        // map 파일을 담을 버킷 사이즈 
    variables_hash_max_size 1024;
    variables_hash_bucket_size 128;
    server_tokens off;                 // NGINX의 버전을 숨길것인가에 대한 옵션이다. 보안상 주석을 제거하여 설정하는 것이 좋다.

    upstream disp_http {
        zone disp80 64k;
        server 127.0.0.1:8080;
    }

    map $uri $rd_mapping {
        include /etc/nginx/maps/*.map;
    }

    map $uri$is_args$args $rd_query_mapping {
        include /etc/nginx/maps_query/*.map;
    }
}

server 블락

하나의 server 블락은 하나의 가상 호스트를 구성합니다. 또한 한 개 이상의 location 블락을 삽입할 수 있습니다.

 server {
        listen 80;                                  //nginx의 가상호스트 포트
        access_log /var/log/nginx/access.log main;  
        error_log /var/log/nginx/error.log warn;

        root /efs/live/html;

        proxy_set_header Proxy "";                 //proxy 서버에 특정 헤더를 전달(proxy 헤더 제거)
        large_client_header_buffers 8 512k;        //대규모 클라이언트 요청 헤더를 읽을 때 사용 

        proxy_buffer_size 64k;                     //백엔드 서버 응답의 첫 부분을 읽기 위한 버퍼 크기를 설정하며, 여기에는 주로 간단한 헤더 데이터가 포함됩니다.
        proxy_buffers 4 64k;                       //백엔드 서버로부터의 응답 데이터를 읽는 데 사용할 버퍼의 수와 크기를 설정합니다.

        if ( $request_method !~ ^(GET|POST|OPTIONS)$ ) {
            return 405;
        }

        location / {

            if ($rd_mapping) {
                rewrite ^(.*)$ https://$http_host$rd_mapping permanent;
            }
            if ($rd_query_mapping) {
                rewrite ^(.*)$ https://$http_host$rd_query_mapping? permanent;
            }

            proxy_pass http://disp_http;

            proxy_set_header Host $http_host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_intercept_errors on;

            error_page 403 404 405 500 501 503 @error_page;
        }


        location /etc/designs/smg/global/fonts/ {
            proxy_pass http://disp_http;
            add_header 'Access-Control-Allow-Origin' *;

            proxy_buffering on;
            proxy_set_header Host $http_host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

    include /etc/nginx/locations/p4_redirection.location;
    include /etc/nginx/locations/error_page.location;
    include /etc/nginx/locations/static_files.location;
    }

location 블락

location / {

           //map파일을 통하는 처리를 위하여 다음과 같이 분기 
            if ($rd_mapping) {
                rewrite ^(.*)$ https://$http_host$rd_mapping permanent;
            }
            if ($rd_query_mapping) {
                rewrite ^(.*)$ https://$http_host$rd_query_mapping? permanent;
            }

            proxy_pass http://disp_http;

            proxy_set_header Host $http_host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_intercept_errors on;

            error_page 403 404 405 500 501 503 @error_page;
        }

3. 마치며..

이번시간에는 nginx의 설정에 대해서 간단히 정리를 해보았습니다. 이번 포스팅은 모든 지시어들을 다 정리하지는 않고,필자가 프로젝트에서 사용하는 지시어들 위주로 정리를 해보았습니다. 주로 reverse proxy 서버의 역할을 수행하면서 backend의 서버로 연결을 짓는 역할을 하고 있습니다. 또한 maps config를 통해서 redirection에 대한 처리와 error에 대한 처리도 같이 하고 있습니다. 이번 포스팅은 미완성으로 남겨두도록 하겠습니다. 앞으로 nginx에 대해 습득되는 지식에 대해서는 포스팅 업데이트를 하도록 하겠습니다. 다음시간에는 대비되는 웹서버인 apache에 대해서도 정리를 해보도록 하겠습니다.

4. 참고

Nginx와 Apache의 구동방식 비교 엔진엑스 기본 환경 설정

함께 보면 좋은 글

The post [DevOps] Nginx Configuration 정리 appeared first on WONIZZ.LOG.

[Linux] Load Average와 시스템 부하

워니 — Mon, 14 Sep 2020 06:54:57 +0000

안녕하세요? 정리하는 개발자 워니즈입니다. 이번시간에는 리눅스의 Load Average에 대해서 정리하는 시간을 갖도록 하겠습니다. 필자의 아는 지인분이 저에게 물어본적이 있습니다.

지인 : TOP 명령어를 치고 나오는 Load Average가 뭘 의미하는지 알아요?
필자 : 로드 평균.... 로드가 걸린다....모르겠습니다.

사실 정의는 간단합니다. 이전에 정리해놓은 포스팅에서 R, D상태에 있는 job들의 갯수라고 보시면 됩니다. 즉, 현재 진행중인 job이거나 아니면 D상태로 I/O와 같은 요청을 하고 잠시 대기 상태에 빠져있는 job들이 갯수 입니다.

얼마나 많은 프로세스가 실행 중 혹은 실행 대기중이냐를 의미하는 수치입니다. Load Average가 높다면 많은 수의 프로세스가 실행 중이거나 I/O 등을 처리하기 위한 대기 상태에 있다는 것이며, 낮다면 적은 수의 프로세스가 실행 중이거나 대기 중이라는 의미입니다.

위에 보시는 그림에서 각각 Load Average는 2에 가까운 수치가 나올 것입니다. 하지만, Core의 갯수에 따라 그 의미가 달라집니다. 왼쪽 그림은 Run Queu에 두 개의 프로세스가 있으며 이 경우 한 번에 하나만 실행되기 때문에 나머지 하나의 프로세스는 대기 상태에 있을 수 밖에 없습니다. 오른쪽 그림은 Run Queue에 두 개의 프로세스가 있지만 서로 다른 CPU에 있기 때문에 A와 B는 동시에 실행 될 수 있습니다. 현재 시스템에서 처리 가능한 만큼의 프로세스가 있다는 것입니다.

1. CPU Bound vs I/O Bound

앞선 Load Average의 개념에 대해서 정리를 했습니다. 서버에서 부하가 걸리는 원인은 크게 2가지를 꼽습니다.

CPU 부하
I/O 부하

CPU 부하가 높은 경우는 서버에서 실행되고 있는 프로그램 자체의 연산량이 많은 경우나 프로그램에 오류등이 발생하는 경우 입니다. 이러한 경우는 대게 Source Code 레벨에서 수정이 가능합니다. 오류 제거, 알고리즘의 시간, 공간 복잡도를 개선하여 대응 할 수 있습니다. I/O 부하가 높은 경우는 서버에서 실행되고 있는 프로그램의 I/O가 많거나, DB나 하드디스크 등의 저장장치로의 접근이 많아 스왑이 발생하는 경우가 대부분입니다. 저장장치나 하드디스크로의 입출력이 빈번하게 발생하는 경우, 메모리 증설하는 방법으로 대응할 수 있습니다. 메모리 증설로 해결할 수 없는 경우 데이터 자체를 분산 (샤딩이나 파티셔닝) 하거나 캐시서버등을 도입하는 방안을 고려해 볼 수 있습니다. 부하를 일으키는 프로세스는 크게 두가지 종류로 나눌 수 있습니다.

nr_running
nu_uninterruptible

두 종류의 부하 프로세스는 같은 Load Average를 보여준다고 해도 사실 일으키고 있는 부하는 전혀 다른 부하이다.

2. vmstat으로 부하의 정체 확인하기

Load Average 값은 시스템에 부하가 있다는 것을 알려주지만 구체적으로 어떤 부하인지는 알 수 없습니다. 어떤 부하가 일어나는지에 대한 정보는 vmstat을 통해서 확인 할 수 있습니다.

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 293156 134388 21696656    0    0    30    76    0    1  3  2 94  0  0

r: The number of processes waiting for run time.
b: The number of processes in uninterruptible sleep.

r은 실행되기를 기다리거나 현재 실행되고 있는 프로세스의 갯수를, b는 I/O를 위해 대기열에 있는 프로세스의 갯수를 말합니다. 즉 각각이 nr_running, nr_uninterruptible을 의미한다고 볼 수 있습니다.

3. Load Average가 보고하는 부하의 정체

시스템 부하의 원인이 대부분의 경우 CPU나 I/O에 있음을 나타내고 있습니다. Load Average로 시스템에 과부하가 걸리고 있다는 사실을 알게된 후에는, 한단계 더 나아가 CPU와 I/O중 어떤 부분에서 부하가 걸리는지를 조사해야 합니다. CPU는 사용자 모드와 시스템 모드로 나뉘어집니다. 사용자 모드는 사용자 프로그램이 동작할 떄의 CPU 모드이며 시스템 모드는 커널이 동작할 때의 CPU 모드 입니다.

15시 20분 01초     CPU     %user     %nice   %system   %iowait    %steal     %idle
15시 30분 01초     all      0.62      0.00      0.10      0.00      0.00     99.28
15시 40분 01초     all      0.75      0.00      0.14      0.00      0.00     99.11
15시 50분 01초     all      0.63      0.00      0.11      0.00      0.00     99.26
16시 00분 01초     all      0.64      0.00      0.13      0.00      0.00     99.23
16시 10분 01초     all      0.65      0.00      0.15      0.00      0.00     99.20
16시 20분 01초     all      0.63      0.00      0.11      0.00      0.00     99.26
16시 30분 01초     all      0.66      0.00      0.11      0.00      0.00     99.23
16시 40분 01초     all      0.65      0.00      0.12      0.00      0.00     99.23
16시 50분 01초     all      0.65      0.00      0.13      0.00      0.00     99.22
17시 00분 01초     all      0.64      0.00      0.11      0.00      0.00     99.25
17시 10분 01초     all      0.66      0.00      0.14      0.00      0.00     99.20
17시 20분 01초     all      0.69      0.00      0.19      0.00      0.00     99.12
17시 30분 01초     all      0.66      0.00      0.13      0.00      0.00     99.20
17시 40분 01초     all      0.65      0.00      0.14      0.00      0.00     99.21
17시 50분 01초     all      0.65      0.00      0.13      0.00      0.00     99.21

sar명령어를 사용하면 부하를 시킨 경과 별로 확인할 수 있어 매우 편리합니다. 위의 결과에서 %user는 사용자 모드에서의 CPU 사용률을 나타내며 %system은 시스템 모드에서의 CPU 사용률을 나타냅니다. %iowait 이 높은 상태이면 I/O가 시스템 부하의 원인이 될 수 있으며, 이때에는 I/O 관련하여 더 자세한 지표인 메모리 사용률이나 프로세스별 스왑 발생 상황등을 더 자세히 살펴본 후 적절히 대응할 수 있습니다.

4. 마치며…

사실 위의 내용을 정리하면서 2가지의 측정을 사용하였습니다. vmstat과 sar 입니다. 어쩃든 결론을 내리자면 부하의 원인에 대해서 어떠한 명령어가 됐든 확인을 해보고 판단을 내리자는 것을 배웠습니다. 크게 2가지 (cpu bound, i/o bound)에 대해서 분석을 수행 한 후, 원인을 일으키는 것이 어떤것인지를 접근하면 훨씬 편해지는것 같습니다. 다음 이시간에는 메모리의 대한 내용을 정리하고자 합니다. 많은 기대 부탁드립니다.

함께 보면 좋은 글

The post [Linux] Load Average와 시스템 부하 appeared first on WONIZZ.LOG.

[Linux] top을 통해 살펴보는 프로세스 정보들

워니 — Mon, 03 Aug 2020 01:35:52 +0000

안녕하세요? 정리하는 개발자 워니즈 입니다. 이번시간부터 이어지는 포스팅들은 리눅스의 기본정리를 해보려고 합니다. 그동안 시스템 엔지니어 + DevOps 업무를 진행해 왔었습니다. 그런데 시스템적으로 확인해야될 부분에서는 아직은 기초가 부족하다고 생각이 많이 들었습니다. 그래서 DevOps와 SE를 위한 리눅스 커널이야기 라는 책을 읽고 해당 내용을 정리해보기로 했습니다. 이번포스팅부터는 개인적인 공부를 정리해둔 거라고 보시면 됩니다. 필자는 절대 저자와 아무런 관련이 없음을 밝힙니다. 필자는 사실 공부하는 것(?)을 좋아합니다. 그냥 지식을 습득하는 것을 좋아하는 것 같습니다. 그러다보니 이러저러한 책들을, 특히나 IT 서적들을 많이 둘러보는데 이번에 위의 책을 알게 되었습니다. 리눅스의 커널단부터 시스템적인 요소를 하나하나씩 짚어보게끔 되어있습니다. 그래서 기왕 책 읽는거 정리하면서 보자는 마음으로 포스팅을 진행하게 되었습니다.

1. 시스템의 상태 살피기

top 명령은 시스템의 상태를 전반적으로 가장 빠르게 파악 할 수 있는 명령어 중 하나이다. 옵션없이 top 명령을 입력하면 3초의 간격으로 refresh 하면서 정보를 보여줍니다. 순간의 top 정보를 확인하기 위해서는 -b 옵션을 사용합니다. 필자가 처음 TA(Technical Architecture) 업무를 배우게 되면서 알게된 명령어 입니다. top명령어를 치면 다음과 같은 내용들이 보이는데, 처음에는 무슨 내용을 봐야하는지 몰랐습니다 .

up 200 days

현재 서버의 시간과 서버가 얼마나 구동되었는지 구동 시간이 나와 있습니다.

load average : 1.81, 1.44, 1.26

Load Average는 현재 시스템이 얼마나 많은 일을 하고 있는지를 보여주는 데이터로, 높으면 서버가 많은 일을 하고 있다고 볼 수 있습니다.

2 running, 353 sleeping

시스템에서 구동 중인 프로세스의 개를 나타냅니다.

VIRT, RES, SHR

프로세스가 사용하는 메모리의 양이 얼마인지를 확인할 수 있는 정보로, 이를 통해 프로세스에 메모리 누수가 있는지를 확인할 수 있어 중요한 정보중 하나입니다.

2. VIRT, RES, SHR은 무엇인가요?

VIRT는 간단하게 프로세스에 할당된 가상 메모리 전체의 크기라고 보면 됩니다. 이것이 높다고해서 문제가 될 소지는 없습니다. RES는 그중 실제로 메모리에 올려서 사용하고 있는 물리 메모리의 크기, 그리고 SHR은 다른 프로세스와 공유하고 있는 메모리의 크기를 말합니다. 실제 사용하고 있는 메모리는 RES 영역이기 때문에 점유율이 높은 프로세스를 찾기 위해서는 RES 영역이 높은 프로세스를 찾아야 한다.

3. Memory Commit의 개념

VIRT는 프로세스가 커널로부터 사용을 하려고 예약받은 메모리라고 할 수 있습니다. malloc() 과 같은 시스템콜로 자신이 필요로 하는 메모리의 영역을 할당해 줄 것을 요청합니다. 이에 커널은 가용한 공간이 있따면 성공 메시지와 함께 해당 프로세스가 사용할 수 있도록 가상의 메모리 주소를 전달해 줍니다. 그 후 프로세스가 할당받은 메모리 영역에 실제로 쓰기 작업을 하면 Page fault가 발생하며, 그제서야 커널은 실제 물리 메모리에 프로세스의 가상 메모리 공간을 매핑한다. 이것은 Page Table이라고 불리는 커널의 전역 변수로 관리된다. 그리고 이렇게 물리 메모리에 바인딩된 영역이 RES로 계산된다. 프로세스는 자신만의 작업 공간이 필요하고 그 공간은 메모리에 존재한다. 프로세스가 커널에 필요한 만큼의 메모리를 요청하면 커널은 프로세스에 사용 가능한 메모리 영역을 주고 실제로 할당은 하지 않지만 해당 영역을 프로세스에 주었따는 것을 저장합니다. 이 일련의 과정을 Memory Commit이라고 부릅니다.

4. 프로세스 상태 보기

프로세스의 상태는 SHR 옆에 있는 S 항목으로 볼 수 있다. 어떤 항목들이 있을지 man 페이지 설명은 아래와 같다.
  S  --  Process Status
                The status of the task which can be one of:
                    'D' = uninterruptible sleep
                    'R' = running
                    'S' = sleeping
                    'T' = traced or stopped
                    'Z' = zombie

D: uninterruptible sleep

디스크 혹은 네트워크 I/O를 대기하고 있는 프로세스를 의미한다. 이 상태의 프로세스들은 대기하는 동안 Run Queue에서 빠져나와 Wait Queue에 들어가게 된다. D 상태의 프로세스가 많으면 특정 요청이 끝나기를 기다리고 있는 프로세스가 많다는 뜻이고, 이 프로세스들은 요청이 끝나면 R 상태로 다시 돌아가야 하기 떄문에 시스템의 부하를 계산하는데 포함됩니다.

R: running

실행 중인 프로세스를 의미합니다. 실제로 CPU 자원을 소모하고 있는 프로세스 입니다.

S: sleeping

D 상태와의 가장 큰 차이점은 요청한 리소스를 즉시 사용할 수 있는지 여부입니다. 시스템 콜이나, 콘솔 입력을 기다리는 프로세스들은 Interruptible sleep 상태가 됩니다. S 상태의 프로세스가 많은 것은 시스템에 큰 영향을 끼치지 않습니다.

Z: zombie

포 프로세스가 죽은 자식 프로세스를 의미합니다. 좀비 프로세스가 실제로 시스템에 지대한 영향을 끼치는 것은 아니지만, PID가 정리가 되지 않고 쌓이면 새로운 프로세스에 할당할 PID가 모자르게 되고, 이는 결국 더이상 PID를 할당하지 못하여 고갈을 일으 킬 수 있습니다.

5. 프로세스 우선 순위

top을 통해 볼 수 있는 항목 중 PR과 NI 값을 살펴 봅니다. PR과 NI는 커널이 프로세스를 스케쥴링할 떄 사용하는 우선순위를 나타내는 값입니다. 프로세스 스케쥴링이 진행되는 구조는 다음과 같습니다. 스케줄러는 유휴 상태에 있던 프로세스가 깨어나거나 특정 프로세스가 스케줄링을 양보하는 등의 경우에 현재 Run Queu 에 있는 프로세스들 중 가장 우선순위가 높은 프로세스를 꺼내서 디스패처에 넘겨줍니다. 디스패처는 현재 실행중인 프로세스의 정보를 다른 곳에 저장한 후 넘겨 받은 프로세스의 정보를 가지고 다시 연산을 하도록 요청합니다.

함께 보면 좋은 글

The post [Linux] top을 통해 살펴보는 프로세스 정보들 appeared first on WONIZZ.LOG.