들어가며
평소에도 그렇고 일을 하면서도 그렇고, 프로젝트에서도 배포쪽으로 다양하게 서포트하는 쪽이라 nginx를 굉장히 많이 사용하는 편이다. 특히 학교에서 일하게 되면서 네트워크 정책이 전산을 관리하는 곳에서 통제하기 때문에 제한된 구조로 특정 포트밖에 이용할 수 없게 된다. 이 때 nginx를 극한으로 사용하는 방법에 대해서 알아보기 시작하였다.
nginx를 리버스 프록시 및 로드 밸런싱과 같이 다양한 방법으로 사용하다가 Nginx Proxy Manager라는 것을 알게 되었다. 굉장히 신세계였는데, 매번 nginx.conf를 직접 설정하고 nginx -t로 문법 체크하고, reload하는 것과는 다르게, 손쉽게 SSL을 통한 https 접속 및 서브 도메인 로드 밸런싱을 지원하는 점이 좋았다. 더 말하면 입이 아플 지경으로 UI도 깔끔하고 좋고 많은 이점이 있어 정말 좋게 사용하고 있다.
이번 포스팅에서는 간단하게 nginx 프록시 매니저를 사용하는 방법에 대해서 알아본다.
본론
nginx?
먼저 nginx는 웹 서버이자 리버스 프록시 서버, 로드 밸런서 등의 역할을 수행하는 고성능의 서버이다. 넓게 보면 HTTP 요청을 처리하는 역할을 한다. 이 HTTP 요청에 대하여 HTML+CSS+JS와 같은 정적 파일을 응답으로 주게 되면 웹 서버의 역할을 하는 것이다. 혹은 HTTP 요청인 80번 포트로 요청이 오면 다른 포트로 트래픽을 틀어준다면 리버스 프록시의 역할을 하는 것이다.
이 외에도 로드 밸런서의 역할로, 여러 서버에 트래픽을 분산시켜 서버의 부하를 줄이는 로드 밸런싱의 기능도 제공한다. 요청한 도메인의 서브 도메인으로 (e.g. api.example.com )으로 트래픽이 온 경우에는 api 서버로 보낸다거나 하는 클라이언트의 HTTP 요청을 다양하게 핸들링할 수 있게 해주는 툴이다.
굉장한 성능을 자랑하기 때문에 WAS(Web Application Server)를 서빙하기 전에 앞단에서 트래픽을 한번 태우는 역할을 한다. HTTP로 들어온 요청을 HTTPS로 말아서 WAS에 던져줄 수도 있고, 보안 상의 다양한 이유로 nginx 뒤에 API 서버를 띄우는 것이 일반적이다.
Nginx Proxy Manager?
이러한 nginx를 GUI를 통해서 보다 간편하게 설정할 수 있게 도와주는 툴이 있다. 그것은 바로 Nginx Proxy Manager로 이번 포스팅에서는 NPM이라고 부른다. 공식 홈페이지의 내용은 아래에 있으며 보다 자세한 사용법이 궁금하다면 아래의 링크를 참고하는 것이 좋아 보인다.
- nginx proxy manager : https://nginxproxymanager.com/
위의 사이트를 참고하면 다양한 quick start를 위한 yml파일을 볼 수 있다. Setup Instructions에 들어가 MySQL과 MariaDB를 사용하는 섹션에 들어가면 아래와 같은 docker-compose.yml을 확인할 수 있다.
이 때, db를 사용하는 이유로는 인증서를 저장하기 위함이라고 한다.
version: '3.8'
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: unless-stopped
ports:
- '80:80'
- '443:443'
- '81:81'
environment:
DB_MYSQL_HOST: "db"
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: "npm"
DB_MYSQL_PASSWORD: "npm"
DB_MYSQL_NAME: "npm"
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
depends_on:
- db
db:
image: 'jc21/mariadb-aria:latest'
restart: unless-stopped
environment:
MYSQL_ROOT_PASSWORD: 'npm'
MYSQL_DATABASE: 'npm'
MYSQL_USER: 'npm'
MYSQL_PASSWORD: 'npm'
MARIADB_AUTO_UPGRADE: '1'
volumes:
- ./mysql:/var/lib/mysql
docker-compose up -d
docker-compose.yml 파일을 작성하고 위 명령어를 통해서 docker-compose를 실행시키면 nginx proxy manager를 금방 확인할 수 있다!
실행 후 서버의 81번 포트에 접속하면 위와 같은 페이지를 볼 수 있다. 로컬에서 띄었다면 http://localhost:81으로 접속한다. 초기 계정은 아래와 같다.
- Email : admin@example.com
- Password : changeme
접속 후 적당한 이름으로 계정을 바꿔주면 위와 같은 페이지를 볼 수 있다. 다양한 프록시를 UI를 통해서 관리할 수 있으며, Redircetion 및 Streams 등 nginx가 할 수 있는 모든 기능들을 손쉽게 UI로 제공한다. Proxy host에 들어가서 add proxy host를 눌러보자.
위와 같이 특정 서브도메인으로 들어오는 트래픽을 다른 포트로 넘겨줄 수 있다. example.com이라고 가정했을 때, npm.example.com으로 들어오면 NPM을 볼 수 있게 위와 같이 설정해준다. 그후 SSL 섹션을 눌러 넘어간다
위와 같이 SSL을 손쉽게 발급받을 수 있다. I Agree to the Let's Encrpy Terms of Service를 눌러주고 Save를 하면 프록시 호스트가 생성된다.
이제 npm.example.com으로 들어가게 되면 example.com이라는 도메인이 바라보고 있는 서버의 81번 포트에서 제공되는 애플리케이션으로 프록시되게 된다. 이 부분에서 DNS를 타기 때문에, 만약 다양한 에러가 발생한다면, Route53이나 DNS 리졸빙에 관련한 트러블슈팅이 필요하다.
필자는 api.example.com을 쓰는데, api.example.com과 *.api.example.com이 트래픽을 route53에서 모두 서버를 가르키게 설정해두었다. 결과적으로 외부에서 모든 트래픽이 갈 수 있도록 설정이 완료되었다!
마치며
이걸 왜 이제 알았을까 하는 생각이 들면서 동시에 nginx proxy manager를 쓸 수준까지 오면 그냥 쿠버네티스가 낫지 않을까 하는 생각이 들기도 한다. 컴퓨팅 리소스가 부족한 프로젝트였기 때문에 Jenkins를 통해서 CI/CD만 하는 수준으로 아키텍처를 설계하였으나, 나중에 컴퓨팅 리소스가 있다면 가용성을 위해 쿠버네티스를 써보는 것도 좋을 것 같다. ( AWS ECS 기반의 Serverless에서 비용 문제로 온프레미즈로 옮겼다는 슬픈 사연 ... )
'DevOps > On-premise' 카테고리의 다른 글
AWS에서 온프레미즈 Jenkins로의 여정 (5) | 2024.11.08 |
---|