도커 교과서 20장 리버스 프록시를 이용해 컨테이너 HTTP 트래픽 제어하기

20장 리버스 프록시를 이용해 컨테이너 HTTP 트래픽 제어하기

20.1 리버스 프록시란?

• 여러 웹 애플리케이션으로 통하는 관문 역할을 수행.
• 리버스 프로시는 포트를 외부로 공개한 유일한 컨테이너 이다.
• 외부에서 들어오는 모든 트래픽은 먼저 리버스 프록시를 거치므로 애플리케이션 포트를 외부로 공개하지 않아도 된다.
• 애플리케이션이 응답 내용을 캐시해 두었다가 적절하게 가공해서 클라이언트에게 전달.
• 스케일링, 업데이트 보안 면에서 유리.
• 리버스 프록시를 경량 컨테이너로 실행하게 되면서 모든 환경에서 동일한 프록시 설정을 사용할 수 있다.

Nginx 프록시 설정하기

• Nginx 가 단순히 요청을 전달하는 매개자 역할을 한다.
• 요청을 받을 때마다 이를 처리하는 컨테이너(upstream) 을 호출한다.
• 응답을 다시 클라인어트 (downstream) 로 전달한다.

server {
	server_name whoami.local;  # 도메인
	
	location / {
		proxy_pass <http://whoami>;  # 콘텐츠 주소
		proxy_set_header Host $host; # 호스트 정보를 콘텐츠 위치로 설정
		add_header X-Host $hostname; # 읃답의 호스트 정보를 프록시 이름으로 변경
	}
}

• 리버스 프록시는 HTTP 로 제공되는 콘텐츠라면 무엇이든 사용 가능하다.
• Nginx 는 단순히 요청을 전달하는 매개자 역할이다.
• 모든 애플리케이션 트래픽이 프록시를 경유하므로 설정의 중심 역할을 할 수 있다.
• 또한, 인프라 스트럭쳐 수준의 사항을 애플리케이션 컨테이너와 분리할 수 있다.

20.2 리버스 프록시의 라우팅과 SSL 적용하기

Nginx 를 이용하여 리버스 프록시 적용하기

• Nginx 는 업스트림 컨테이너가 여러개 존재한다면 이들 간의 로드밸런싱 처리가 가능하다.

$ echo $'\\n127.0.0.1 image-gallery.local' | sudo tee -a /etc/hosts

$ docker compose -f ./image-gallery/docker-compose.yml up -d --scale image-gallery=3

$ ./nginx/sites-available/image-gallery.local ./nginx/sites-enabled/

$ docker compose -f ./nginx/docker-compose.yml restart nginx

$ curl -i --head <http://image-gallery.local>

$ vi ./nginx/conf/conf.d/default.conf

server {
	server_name image-gallery.local;
	
	location / {
		proxy_pass <http://image-gallery>;
		proxy_set_header Host $host;
		add_header X-Proxy $hostname;
		add_header X-Upstream $upstream_addr;
	}
}

• X-Upstream 항목은 Nginx 가 응답을 받아 온 컨테이너의 IP 주소가 담긴 항목이다.
• curl 을 사용해 애플리케이션을 호출할 경우 로드밸런싱이 적용되어 매번 호출되는 IP 주소가 변경되는 것을 확인 가능하다.

Nginx SSL 적용하기

• 리버스 프록시를 이용하면 HTTPS 를 적용할 수 있다.
• Nginx 는 Let’s Encrypt 와 같은 실제 도메인 제고아나 서비스에서 발급한 실제 인증서를 설정에 포함할 수 있다.

# 자체 인증서 생성
$ docker container run -v "$(pwd)/nginx/certs:/certs" -e HOST_NAME=image-gallery.local diamol/cert-generator

# 기존 설정 파일 삭재
$ rm ./nginx/sites-enabled/image-gallery.local

# SSL 이 포함된 설정 파일 복사
$ cp ./nginx/sites-available/image-gallery-3.local ./nginx/sites-enabled/image-gallery.local

# 재시작
$ docker compose -f nginx/docker-compose.yml restart nginx

$ vi ./nginx/conf/conf.d/default.conf

server {
	server_name image-gallery.local;
	listen 80;
		return 301 https://$server.name$request_uri;
}

server {
	server_name image-gallery.local;
	listen 443 ssl;
	
	ssl_certificate /etc/nginx/certs/server-cert.pem;
	ssl_certificate_key /etc/nginx/certs/server-key.pem;
	ssl_session_cache shared:SSL:10m;
	ssl_session_timeout 20m;
	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
	
	ssl_prefer_server_ciphers on;
	ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
	
	add_header Strict-Transport-Security "max-age=31536000" always;
	
	location /api/image {
			proxy_pass <http://iotd/image>;
			proxy_set_header Host $host;
			add_header X-Proxy $hostname;
			add_header X-Upstream $upstream_addr;
	}
	
	location / {
		proxy_pass <http://image-gallery>;
		proxy_set_header Host $host;
		add_header X-Proxdy $hostname;
		add_header X-Upstream $upstream_addr;
	}
}

• 인증서와 키 파일 쌍은 하나의 도메인에서만 유효하므로, 애플리케이션 하나마다 인증서와 키 파일 세트가 필요하다.
• 인증서와 키 파일은 민감 정보로 비밀값 형태로 클러스터에 저장된다.
• HTTPS 를 적용하지 않으면, 애플리케이션 컨테이너 설정과 인증서 관리 부담이 줄어들며, 개발자는 단순 HTTP 버전으로 테스트를 진행할 수 있다.

20.3 프록시를 이용한 성능 및 신뢰성 개선

• Nginx 는 고성능 HTTP 서버로 정적 HTML 콘텐츠나 단일 페이지 애플리케이션을 제공하는데 활용할 수 있다.
• 컨테이너 하나만으로도 초당 수천건의 요청을 처리할 수 있다.
• 이를 활용하여 Nginx 를 캐싱 프록시로 사용할 수 있다.
• 애플리케이션의 응답을 로컬 디스크나 메모리에 저장하고, 동일한 요청에 대해 업스트림 콘텐츠에 요청하지 않고, 저장된 것을 사용한다.
• 따라서, 캐싱 프록시를 사용하게 되면 요청 시간을 줄이고, 같은 인프라 스트럭처로 더 많은 요청을 처리할 수 있다.

$ vi ./nginx/sites-available/image-gallery-4.local

server {
    server_name image-gallery.local;
    listen 80;
	return 301 https://$server_name$request_uri;
}

server {
	server_name  image-gallery.local;
	listen 443 ssl;
    
    gzip  on;    
    gzip_proxied any;

	ssl_certificate        /etc/nginx/certs/server-cert.pem;
	ssl_certificate_key    /etc/nginx/certs/server-key.pem;
	ssl_session_cache      shared:SSL:10m;
	ssl_session_timeout    20m;
	ssl_protocols          TLSv1 TLSv1.1 TLSv1.2;

	ssl_prefer_server_ciphers on;
	ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';

	add_header  Strict-Transport-Security "max-age=31536000" always;

    location = /api/image {
        proxy_pass             <http://iotd/image>;
        proxy_set_header       Host $host;
        proxy_cache            SHORT;
        proxy_cache_valid      200  1m;
        add_header             X-Cache $upstream_cache_status;
        add_header             X-Proxy $hostname;         
        add_header             X-Upstream $upstream_addr;
    }

    location / {
        proxy_pass             <http://image-gallery>;
        proxy_set_header       Host $host;
        proxy_cache            LONG;
        proxy_cache_valid      200  6h;
        proxy_cache_use_stale  error timeout invalid_header updating
                               http_500 http_502 http_503 http_504;
        add_header             X-Cache $upstream_cache_status;
        add_header             X-Proxy $hostname;         
        add_header             X-Upstream $upstream_addr;
    }        
}

$ cp ./nginx/sites-available/image-gallery-4.local ./nginx/sites-enabled/image-gallery.local

$ docker compose -f ./nginx/docker-compose.yml restart nginx

• 프록시 설정에 사용자 정의 응답 헤더인 X-Cache 가 포함된다.
• 요청에 해당하는 캐시가 있는지 먼저 확인한 이후, 요청에 일치하는 캐시가 없을 경우 X-Cache: MISS 가 반환된다.
• 추가로 X-Upstream 헤더에 콘텐츠를 제공한 IP 주소가 응답된다.
• 같은 요청이 추가로 들어왔을 경우 X-Cache: HIT 과 함께 응답되며, X-Upstream 헤더는 들어오지 않는다.
• proxy_cache_use_stale 는 Upstream 을 사용하지 못할 경우 만료된 캐시를 사용하라는 의미이다.
• 만료된 캐시라도 사용함으로써 컨테이너가 장애를 일으켜도 애플리케이션이 서비스를 제공할 수 있다.

20.4 클라우드 네이티브 리버스 프록시

• 도커 엔진과 연결된 컨테이너는 도커 API를 통해 다른 컨테이너에 대한 정보를 얻을 수 있다.
• 클라우드 네이티브 리버스 프록스 도구인 트래픽 (Traefik) 이 이런 방식으로 동작한다.
• 트래픽을 사용할 경우 컨테이너에 레이블만 추가하면 스스로 설정과 라우팅 맵을 구성할 수 있다.
• 트래픽을 사용하면 자동으로 리버스 프록시 기능을 사용할 수 있지만, Nginx 와 다르게 캐싱을 할 수 없다.

트래픽 특징

• 동적 설정 구성
  • 트래픽은 시작할 때 설정 파일을 읽지 않고, 런타임 중에 구성을 변경할 수 있다.
• 자동 Service Discovery
  • 인프라스트럭처에 대한 네티이브 지원을 통해 새로운 서비스를 자동으로 감지하고, 트래픽을 해당 서비스로 라우팅한다.
• 최신 프로토콜 지원
  • HTTP/2, WebSocket, GRPC 등의 최신 프로토콜을 지원함으로써, 원할한 통신이 가능하다.
• Let’s Encrypt 를 사용한 HTTPS 지원
  • Let’s Encrypt 를 사용하여 자동으로 SSL/TLS 인증서를 발급하고 관리할 수 있다.

트래픽 구성

• 엔트리 포인트
  • 외부에서 들어오는 트래픽을 주시하는 포트.
  • 해당 포트와 컨테이너의 공개 포트가 매핑
• 라우터
  • 인입된 요청을 배정할 컨테이너를 결정하는 규칙.
  • 호스트 명, 경로 등으로 구성
• 서비스
  • 실제 콘텐츠를 제공하는 업스트림 컴포넌트
• 미들웨어
  • 라우터 서비스 사이에서 서비스에 전달되는 요처을 변경하는 역할
  • 요청에 포함된 경로 또는 헤더를 변경하거나 인증을 강제할 수 있다.

services:
	whoami:
		labels:
			- "traefik.enable=true"
			- "traefik.http.routers.whoami.rule=Host('whoami.local')"

스티키 세션

• 애플리케이션을 만들 때 최대한 많은 부분을 무상태로 만드는 것이 좋다.
• 무상태로 만들면 아무 컨테이너에서나 요청을 처리할 수 있으므로 수평 확 장 및 로드 밸런싱 효과를 극대화 할 수 있다.
• 그러나, 기존 애플리케이션의 경우 상태가 있는 구송 요소를 많이 포함하고있는 경우가 있다.
• 이 경우 스티키 세션이 필요하다.
• 스트키 세션을 활성화하면 클라이언트에 컨테이너를 식별할 수 있는 쿠기가 부여되므로 해당 사용자의 요청을 계속 같은 컨테이너로 라우팅 할 수 있다.

services:
	whoami:
		labels:
			- "traefik.enable=true"
			- "traefik.http.routers.whoami.rule=Host('whoami.local')"
			- "traefik.http.services.whoami.loadBalancer.sticky=true"
			- "traefik.http.services.whoami.loadBalancer.sticky.cookie.name=whoami_cookie"
			- "traefik.http.services.whoami.loadBalancer.sticky.cookie.httpOnly=true"

20.5 리버스 프록시를 활용한 패턴의 이해

한 클러스터에서 각 다른 도메인 이름을 갖는 여러 개의 애플리케이션을 호스팅하는 패턴

• 리버스 프록시만 80번 포트와 443 포트를 통해 외부로 노출한다.
• 그 외의 컨테이너는 모두 외부로 노출되지 않는다.
• 라우팅 규칙을 통해 필요한 컨테이너에 라우팅한다.

마이크로서비스 아키택처의 일부 요소를 외부로 노출시키는 패턴

• 리버스 프록시를 통해 웹 컨테이너와 마이크로서비스 중 일부가 외부로 노출된다.
• 엔트리포인트는 같은 도메인을 사용하지만, HTTP 요청 경로에 따라 요청이 다른 컨테이너로 라우팅된다.

모놀리식 설계를 가진 애플리케이션을 점진적으로 컨테이너로 이주시키기

• 리버스 프록시를 이용해 모놀리식 설계를 점진적으로 마이크로서비스로 분할할 수 있다.
• 새로운 기능은 별도의 컨테이너 형태로 추가하며, 리버스 프록시를 통해 요청 경로에 따라 전달한다.