배포시 문제점
새로운 버전을 배포할 시
배포하는 시간동안 서비스를 사용할 수 없게되는 문제가 생긴다.
이를 해결하기 위해서 무중단 배포를 하는것이다.
또한 새로운 버전을 개발하고 이를 직접 배포하는것이 아닌
새로운 버전을 인식하고 자동으로 배포되게 하면 더 좋을것이다.
이게 CI/CD가 필요한 이유다.
지속적 통합 지속적 배포 라고하는데
그냥 무중단 자동 배포라고 보면된다.
1. nginx 리버스 프록시
nginx에 리버스 프록시 기능을 활용하면 아래와 같은 구조로 동일한 서버를 여러개띄워
트래픽을 분산시킬 수 있다.
쉽게말해
사용자는 nginx의 리버스프록시서버인 localhost 8079로 접속
nginx가 알아서 사용자의 요청을 8080 혹은 8082에 전달 후
그 응답을 다시 사용자에게 전달.
사용자는 8080인지 8082인지 모름
2. config 설정
리버스 프록시 사용하는 법은 너무 쉽다
nginx.conf 만 설정해주면된다
nginx.conf기본 내용 싹다 지우고 아래와같이 작성해보자
worker_processes 1;
events {
worker_connections 1024;
}
http {
upstream tomcat_servers {
server localhost:8082 weight=3; # 더 많은 트래픽을 처리할 서버
server localhost:8083 weight=1; # 상대적으로 적은 트래픽을 처리할 서버
}
}
server {
listen 8079;
location / {
proxy_pass http://tomcat_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
}
코드에 대한 설명
worker_process 1;
Nginx의 워커 프로세스 수를 설정한다. 워커프로세스란 실제로 요청을 처리하는 프로세스를 뜻한다. 일반적으로 CPU 코어수와 동일하거나 그보다 약간 많은 수로 설정하는 것이 좋다. 1로 설정되어 있으므로, Nginx는 하나의 워커 프로세스만 실행한다.
events { worker_connetions 1024;}
이벤트 블록 내에서 worker_connections는 각 워커 프로세스가 처리할 수 있는 최대 동시 연결 수를 설정한다. 1024로 설정되어있는데, 이는 각 워커가 최대 1024개의 연결을 동시에 처리할 수 있음을 의미한다.
http {...}
HTTP 블록은 HTTP 서버의 동작을 정의한다. 내부에 설정된 여러 지시어는 HTTP 요청을 처리하는 방법을 지정한다.
upstream tomcat_servers { server localhost:8082;}
upstream 블록은 로드 밸런싱을 위한 서버 그룹을 정의한다. tomcat_servers 라는 의름의 그룹을 만들고, 이 그룹의 서버로localhost:8082를 추가했다. 이 설정은 Nginx가 이 서버로 요청을 전달할 때 사용할 서버 그룹을 정의한다.
server { listen 8079; ... }
server 블록은 특정 포트에서 요청을 수신하고 처리하는 서버의 구성을 정의한다. 여기서는 8079 포트에서 요청을 수신하도록 설정되어 있다.
location / { ... }
location 블록은 특정 URI 패턴에 대한 요청을 처리한다. / 는 루트 URI를 의미하며, 모든 요청이 이 블록 내의 지시어에 따라 처리된다.
proxy_pass http://tomcat_servers;
proxy_pass 지시어는 요청을 upstream 블록에서 정의한 서버 그룹으로 전달한다. 여기서는 http://tomcat_servers로 설정되어 있어, 요청이 localhost:8082로 전달된다.
proxy_set_header Host $host;
원래 요청의 호스트 헤더를 전달한다.
proxy_set_header X-Real-IP $remote_addr;
클라이언트의 실제 IP주소를 전달한다.
proxy_set_header X-Forwarded_For $proxy_add_x_forwarded_for;
클라이언트의 IP 주소를 포함한 X-Forwarded-For 헤더를 설정한다. 이 헤더는 프록시를 거친 IP 주소를 나열한다.
proxy_set_header X-Forwarded_Proto $scheme;
원래 요청의 프로토콜(HTTP 또는 HTTPS)을 전달한다.
수정했다면
시작을 시켜보자
3. nginx 사용법
아래는 시작하고 중지하고 리로드하는 기본적인 사용법이다.
1) Nginx 시작
cd C:\path\to\nginx
start nginx
2) Nginx 중지
cd C:\path\to\nginx
nginx -s stop
3) Nginx 설정 변경 후 리로드
cd C:\path\to\nginx
nginx -s reload
4. 무중단 배포
그림과 같이 8080, 8082 두개의 서비스를 우선 켜놓고
구버전은 8082라고 가정하자
그럼 아래와같이 config가 작성되어있어야한다.
worker_processes 1;
events {
worker_connections 1024;
}
http {
upstream tomcat_servers {
server localhost:8082;
}
}
server {
listen 8079;
location / {
proxy_pass http://tomcat_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
}
이후 8080을 최신버전으로 배포하고 테스트까지 거쳐서 이상이 없다고 판단됐다 가정
아래와같이 config 파일에서 8082를 8080으로 수정
worker_processes 1;
events {
worker_connections 1024;
}
http {
upstream tomcat_servers {
server localhost:8080;
}
}
server {
listen 8079;
location / {
proxy_pass http://tomcat_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
}
이후 reload해주면 끝
nginx -s reload
이 config를 수정해주는 것이 전부다.
이제 윈도우 배치파일을 작성해서
이를 자동화해보겠다.
https://jwinjection.tistory.com/246?category=1198562
nginx활용한 CICD 구현(2)
1. 윈도우 배치파일작성8080에 A웹서버8778에 B웹서버 를 실행시킨다음 실제 서비스하는 포트두개(8080,8778)를 배치파일 상단에 적어준다 코드로직을 간단히 설명하자면8080으로 작성되어있으면 877
jwinjection.tistory.com
'DevOps > 🛠️ CICD' 카테고리의 다른 글
CICD | Webhook을 이용한 Blue-Green 배포 구현 (2) | 2024.10.05 |
---|---|
Jenkins | GitLab webhook설정 (1) | 2024.10.01 |
DuckDNS로 무료 도메인 등록하기 (0) | 2024.10.01 |
윈도우환경에서 nginx활용한 초간단 CICD 구현(2) (0) | 2024.09.06 |
리버스 프록시란? (0) | 2024.09.05 |