nginx를 CentOS 7에 설치하고 난 후, 한국에서만 접속을 허용하도록 하기 위해서는 다음과 같은 방법으로 할 수 있다.

1. GeoIP 설치
yum install -y geoip #install location : /usr/share/GeoIP/
2. nginx module dynamic 설치
yum install -y nginx-module-geoip #install location : /etc/nginx/modules/
3. nginx 설정 변경
vi /etc/nginx/nginx.conf
#nginx 설정 파일의 맨 위에 다음 2줄 추가
load_module modules/ngx_http_geoip_module.so;
load_module modules/ngx_stream_geoip_module.so;
http {
......
# 아래 설정 추가
# geoip national data file location
geoip_country /usr/share/GeoIP/GeoIP.dat;
# geoip national code mapping, default no, korea yes
map $geoip_country_code $allowed_country {
    default no;
    KR yes;
}
 #log_format에 국가코드 출력
log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    '$status $body_bytes_sent $proxy_host $upstream_addr "$http_referer" '
    '"$http_user_agent" "$http_x_forwarded_for" "$geoip_country_code"';
4. nginx 설정 syntax check
nginx -t
5. nginx 재기동
service nginx restart
service nginx status



CentOS 7.5에 nginx 최신 버전(1.14.2) 설치

2019/03/07 16:52
Pre-Built Package를 이용하여 설치하는 경우

01. Install the prerequisites
sudo yum install yum-utils

02. Repository 생성
vi /etc/yum.repos.d/nginx.repo
[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key

[nginx-mainline]
name=nginx mainline repo
baseurl=http://nginx.org/packages/mainline/centos/$releasever/$basearch/
gpgcheck=1
enabled=0
gpgkey=https://nginx.org/keys/nginx_signing.key
03. Default로는 stable 버전으로 설정되어 있으나 mainline을 사용하고자 할 경우
sudo yum-config-manager --enable nginx-mainline

04. nginx 설치
sudo yum install nginx

소스코드로부터 설치하는 경우

01. Nginx 다운로드
wget https://nginx.org/download/nginx-1.14.2.tar.gz
02. 압축풀기
tar -xvf nginx-1.14.2.tar.gz
03. 의존성 라이브러리 설치
sudo yum -y install gcc gcc-c++ make zlib-devel pcre-devel openssl-devel

04. nginx 폴더 생성
mkdir nginx
mkdir log run sbin
05. Configuration Option 설정

./configure \
--user=nginx                          \
--group=nginx                         \
--prefix=$HOME/nginx                   \
--sbin-path=$HOME/nginx/sbin           \
--conf-path=$HOME/nginx/nginx.conf     \
--pid-path=$HOME/nginx/run/nginx.pid         \
--lock-path=$HOME/nginx/run/nginx.lock       \
--error-log-path=$HOME/nginx/log/error.log \
--http-log-path=$HOME/nginx/log/access.log \
--with-http_gzip_static_module        \
--with-http_stub_status_module        \
--with-http_ssl_module                \
--with-pcre                           \
--with-file-aio                       \
--with-http_realip_module             \
--without-http_scgi_module            \
--without-http_uwsgi_module           \
--without-http_fastcgi_module

06. Compile the nginx source

make
make install
07. nginx configuration 변경
기본적으로 80 포트는 root 계정으로 실행해야 하므로 nginx.conf 파일에서 listen 8080으로 변경.
vi nginx.conf
08. nginx oepration shell script 생성
[nginx 시작]
vi start.sh
#!/bin/bash
./sbin/nginx
[nginx 종료]
vi stop.sh
#!/bin/bash
./sbin/nginx -s stop

[nginx 재시작]
vi restart.sh
#!/bin/bash
./sbin/nginx -s reload

[nginx 설정 파일 확인]
vi check.sh
#!/bin/bash
./sbin/nginx -t

09. 확인
시작 : sh start.sh &
브라우저에서 localhost:8080 호출하여 [Welcome to nginx!] 내용 확인
종료 : sh stop.sh


Summary
(요약)

기존 어플리케이션을 마이크로서비스로 마이그레이션하는 과정은 어플리케이션 현대화의 한 형태이다. 어플리케이션을 처음부터 다시 작성하여 마이크로서비스로 옮기면 안 된다. 대신에, 어플리케이션을 일련의 마이크로서비스로 점차적으로 리팩토링해야 한다. 여기에 사용할 수 있는 3가지 전략이 있다. 새로운 기능을 마이크로서비스로 구현한다. 비즈니스 컴포넌트와 데이터 액세스 컴포넌트에서 프리젠테이션 컴포넌트를 분리한다. 기존의 모듈을 monolith에서 마이크로서비스로 변환한다. 시간이 지날수록 마이크로서비스의 수는 증가하고, 개발팀의 민첩함과 속도는 증가할 것이다.

more..



Strategy 3 – Extract Services
(세번째 전략 : 서비스 추출)

세번째 리팩토링 전략은 monolith 내 기존 모듈들을 독립형 마이크로서비스로 변환하는 것이다. 모듈을 추출하여 서비스로 변환할 때마다, monolith는 작아진다. 일단 충분히 모듈로 변환하고 나면, monolith는 문제가 되지 않을 것이다. Monolith는 완전히 사라지거나 또다른 서비스가 될 만큼 충분히 작아지게 된다.

Prioritizing Which Modules to Convert into Services
(서비스 변환 대상 모듈 우선 순위화)

크고 복잡한 monolithic 어플리케이션은 수십, 수백개의 모듈들로 이루어져 있다. 그리고 그 모듈들은 모두 추출 대상이다. 우선 변환할 모듈을 알아내는 것은 도전적인 일이다. 좋은 접근 방법은 쉽게 추출할 수 있는 몇 가지 모듈로 시작하는 것이다. 이것은 일반적으로 마이크로서비스와 특히 추출 프로세스에 대한 경험을 제공해 준다. 그 이후에, 가장 큰 이익을 주는 모듈들을 추출해야 한다.

모듈을 서비스로 변환하는 것은 일반적으로 시간이 많이 걸린다. 여러분은 얻을 수 있는 이익을 기반으로 모듈에 대한 순위를 매기기를 원한다. 일반적으로는 자주 변경되는 모듈을 추출하는 것이 유익하다. 한번 모듈을 서비스로 변환하고 나면, monolith와는 독립적으로 개발하고 배포할 수 있기 때문에 개발을 가속화하게 될 것이다.

Monolith의 나머지와 크게 다른 리소스 요구사항을 가지는 모듈을 추출하는 것도 유익하다. 예를 들면, 인메모리 데이터베이스를 가진 모듈을 서비스로 변환하고, 대용량 메모리를 가진 호스트에 배포할 수 있다. 이와 유사하게, 계산하기에는 비싼 알고리즘을 구현하는 모듈을 추출하는 것은 많은 CPU를 가진 호스트에 배포할 수 있기 때문에 가치가 있다. 특정 리소스 요구사항을 가진 모듈을 서비스로 변환함으로써, 어플리케이션을 훨씬 쉽게 확장할 수 있다.

어느 모듈을 추출할지를 알고 나면, 이미 존재하는 대략적인 경계(이음새로 알려진)를 찾는 것이 유용하다. 모듈을 서비스로 더 쉽고 값싸게 한다. 그러한 경계의 한 예로는 비동기 메시지를 통해 나머지 어플리케이션과 커뮤니케이션하는 모듈을 들 수 있다. 상대적으로 싸고 쉽게 모듈을 마이크로서비스로 변환할 수 있다.

How to Extract a Module
(어떻게 모듈을 추출하는가)

모듈을 추출하는 첫번째 단계는 모듈과 monolith 사이에 대략적인 인터페이스를 정의하는 것이다. Monolith는 서비스가 소유한 데이터를 필요로 하고, 그 반대의 경우도 마찬가지이기 때문에 대부분 양방향 API일 것이다. 모듈과 나머지 어플리케이션들 사이의 얽혀 있는 의존성과 잘 정리되어 있는 상호작용 패턴 때문에 양방향 API를 구현하는 것은 종종 어려운 일이다. Domain Model 패턴을 사용하여 구현된 비즈니스 로직은 도메인 모델 클래스 간의 수많은 연관성 때문에 리팩토링하기에 특히 어렵다. 이러한 의존성을 깨기 위하여 종종 중요한 코드를 변경해야만 할 필요가 있다. 다음 다이어그램은 리팩토링에 대해서 보여준다.

대략적인 인터페이스를 일단 구현하고 나면, 모듈을 독립적인 서비스로 변환할 수 있다. 이렇게 하기 위해서, monolith와 서비스가 Inter-Process Communication(IPC : 프로세스간 통신) 메커니즘을 사용하는 API를 통해 서로 통신할 수 있는 코드를 작성해야만 한다. 다음 다이어그램은 리팩토링 전, 도중, 후의 아키텍처를 보여준다.


사용자 삽입 이미지



이 예제에서, 모듈 Z는 추출할 후보 모듈이다. 그 구성요소들은 모듈 X에서 사용되고, 모듈 Y를 사용한다. (즉, X 모듈에서는 Z 모듈의 구성요소를 사용하고, Z 모듈의 구성요소들은 Y 모듈을 사용한다.) 첫번째 리팩토링 단계는 대략적인 API 쌍을 정의하는 것이다. 첫번째 인터페이스는 모듈 Z를 호출하기 위해서 모듈 X에서 사용하는 인바운드 인터페이스이다. 두번째는 모듈 Y를 호출하기 위해 모듈 Z에서 사용하는 아웃바운드 인터페이스이다. (인바운드 : 모듈 Z의 입장에서 요청이 들어오는 방향, 아웃바운드 : 모듈 Z의 입장에서 요청이 나가는 방향)

리팩토링의 두번째 단계는 모듈을 독립적인 서비스로 변환하는 것이다. 인바운드, 아웃바운드 인터페이스는 IPC 메커니즘을 사용하는 코드로 구현된다. 서비스 검색과 같은 Cross-Cutting Concern(AOP에서 여러 비즈니스 로직에 공통으로 필요하여 별도 모듈로 쉽게 분리할 수 없는 요구사항. 예:보안, 로깅, 트랜잭션, 등)을 다루는 Microservice Chassis framework와 모듈 Z를 결합하여 서비스를 빌드할 필요가 있다.

일단 모듈을 추출하고 나면, monolith와 다른 서비스들과는 별도로 개발, 배포, 확장하 ㄹ수 있는 또다른 서비스를 가지게 된다. 서비스를 처음부터 재작성하게 될 수도 있다. 이 경우에는, 서비스와 monolith를 통합하는 API 코드가 2개의 도메인 모델 사이를 변환하는 Anti-Corruption Layer(반부패 계층)이 된다. 서비스를 추출하는 경우마다 마이크로서비스의 방향으로 또 한 걸음 나아가는 것이다. 시간이 지날수록 monolith는 작아지고, 마이크로서비스는 늘어날 것이다.

Strategy 2 – Split Frontend and Backend
(두번째 전략 - Frontend와 Backend의 분리)

Monilithic Application을 축소시키는 전략은 비즈니스 로직과 데이터 액세스 레이어에서 프리젠테이션 레이어를 분리하는 것이다.

일반적으로 엔터프라이즈 어플리케이션은 최소한 3가지 다른 유형의 컴포넌트들로 이루어져 있다.

프리젠테이션 레이어 - HTTP 요청을 처리하고, (REST) API나 HTML 기반 Web UI를 구현하는 구성 요소. 정교한 사용자 인터페이스를 가지고 있는 어플리케이션에서 프리젠테이션 계층은 종종 상당한 코드로 구성되어 있다.
비즈니스 레이어 - 어플리케이션의 핵심 영역이며, 비즈니스 규칙을 구현하는 구성 요소.
데이터 액세스 레이어 - 데이터베이스나 메시지 브로커와 같은 인프라 구성 요소들에 액세스하는 구성 요소

일반적으로 프리젠테이션 로직 영역과 비즈니스, 데이터 액세스 로직 사이는 분명하게 분리되어 있다. 비즈니스 계층은 비즈니스 로직 컴포넌트들을 캡슐화하는 하나 이상의 facade(진입점 역할을 하는 인터페이스)로 이루어진 대단위 API를 가지고 있다. 이 API는 monolith를 2개의 더 작은 어플리케이션으로 나눌 수 있는 자연적인 솔기이다. 한 개의 어플리케이션은 프리젠테이션 레이어를 가지고 있다. 다른 어플리케이션은 비즈니스와 데이터 액세스 로직이 포함되어 있다. 이렇게 분리한 후, 프리젠테이션 로직 어플리케이션은 비즈니스 로직 어플리케이션을 원격으로 호출하게 된다. 다음 다이어그램은 리팩토링 전후의 아키텍처를 보여주고 있다.

사용자 삽입 이미지



이 방법으로 monolith를 분할하는 것은 2가지 주요 장점이 있다. 서로간에 독립적으로 2개의 어플리케이션을 개발, 배포, 확장할 수 있다. 특히, 프리젠테이션 레이어 개발자는 사용자 인터페이스를 빠르게 반복하여 개발할 수 있다. 그리고 예를 들면, 쉽게 A|B 테스트를 수행할 수 있다. 이 접근방법의 또다른 장점은 개발한 마이크로서비스에서 호출할 수 있는 원격 API를 제공한다는 것이다.

그러나, 이 전략은 단지 부분적인 해결책일 뿐이다. 한 두개의 관리할 수 없는 monolith 어플리케이션에 대한 해결책일 공산이 크다. 나머지 monolith를 제거하기 위해서는 3번째 전략을 사용하는 것이 필요하다.