Github Actions & Nginx를 이용한 CI/CD 무중단 배포 자동화 구축 - Nginx 설정과 배포시작!
👑 Nginx 설정과 배포 자동화 테스트
두 번의 게시물을 거쳐서 여기까지 오신 것을 축하드립니다!
드디어 한가지 관문만 거치면 지금껏 노력해온 과정들이 어떻게 맞물려서 실행되는지 눈으로 볼 수 있습니다!
Nginx를 이용한 로드 밸런싱 사용을 위해, Nginx를 설치하고 설정 파일을 수정하겠습니다.
- Nginx 설치
// nginx 설치
sudo yum install nginx
// nginx 시작
sudo service nginx start
// 현재 nginx 상태확인
sudo service nginx status
// nginx 중지
sudo service nginx stop
// nginx 서비스를 중지 후 시작
sudo service nginx restart
// nginx 서비스를 정상적으로 다시 시작
sudo service nginx reload위의 코드는 Nginx를 EC2에서 사용할때 자주 쓰게되는 명령어들을 모아보았습니다.
지금은 처음 Nginx를 설치해야 하기 때문에, nginx 설치 -> nginx 시작 -> nginx 상태확인 명령어를 순차적으로 입력하시면 정상적으로 nginx가 설치된 걸 확인할 수 있습니다.
녹색 불이 선명하게 들어와있으면 Nginx가 현재 잘 동작하고 있는 것입니다.
- Nginx 설정 파일 수정(nginx.conf)
sudo vim /etc/nginx/nginx.conf위에 작성된 명령어로 nginx.conf 파일을 문서 편집기로 열어줍니다.
# nginx.conf
# Nginx 이벤트 모듈을 설정합니다.
events {}
# HTTP 요청과 관련된 설정을 하는 부분입니다.
http {
# upstream 서버 그룹을 정의하는 부분입니다. 로드 밸런싱을 위해 여러개의 서버를 가리킬 수 있습니다.
upstream spring-server {
# 로드 밸런싱을 위해 locahost의 8081 포트와 8082 포트에 동작하는 서버를 지정합니다.
server localhost:8081;
server localhost:8082;
}
# 실제 HTTP 서버를 설정하는 부분입니다.
server {
# listen 지시문은 서버가 80포트에서 들어오는 요청을 수신하도록 설정합니다.
listen 80;
include /etc/nginx/default.d/*.conf;
# 모든 경로에 대한 처리를 정의합니다. 프록시 서버로의 요청을 설정하는 부분입니다.
location / {
# proxy_set_header는 프록시 서버로 전달되는 요청 헤더를 설정하는 역할을 합니다.
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header HOST $http_host;
proxy_set_header X-Nginx-Proxy true;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# proxy_pass는 실제 요청을 전달할 upstream 서버 그룹을 지정합니다.
proxy_pass http://spring-server;
# proxy_redirect는 프록시 응답의 리다이렉션을 설정하는 부분입니다.
proxy_redirect off;
}
}
}위와 같이 수정 후 문서 편집기를 닫고 저장해줍니다.
nginx.conf 파일 수정 후에는 아래 작성된 명령어를 입력해 서비스를 다시 시작합니다.
// nginx 서비스를 중지 후 시작
sudo service nginx restart👾 Github push를 통한 테스트 진행
이제 모든 설정이 끝났으니 Github에서 내려받은 프로젝트의 코드를 수정하여 의도한대로 배포가 진행되고 있는지 확인해보겠습니다.
배포까지 진행되려면 지난 게시글에 작성했던 deploy.yml 파일이 실행되도록 해야하는데, 간단하게 테스트를 하기 위해 main 브랜치의 코드를 수정해보겠습니다.
직접 Github에 들어가서 build.yml에 공백만 추가하고 main 브랜치에 바로 반영해보겠습니다.
그러면 Github Actions의 job들이 실행되는 것을 볼 수 있습니다.
모든 job들이 성공적으로 끝났습니다.
설정한대로 Slack 알람도 잘 오는것을 확인할 수 있습니다.
그러다면 EC2 내부에서는 어떻게 배포가 이루어졌는지 보겠습니다.
CodeDeploy를 통해 배포 요청을 하고, 마지막에 deploy.sh 배포 스크립트가 실행되게 됩니다.
배포 스크립트의 실행 순서를 살펴보면 아래와 같습니다.
- 실행중인 blue가 있는지 확인
- blue가 실행중이라면 green up 실행중이지 않으면 blue up
- 30초간 스레드를 멈춥니다.
- blue가 실행중이였다면 blue down 아니라면 green down
이런 과정으로 실행되게 됩니다. 그렇다면 최초 배포 시도시에는 blue & green이 전부 실행중이여야 하고, 30초뒤에 이전 버전이 다운되게 되는 구조를 가지고 있습니다.
정말 그렇게 동작하는지 EC2 서버로 가서 확인해보겠습니다.
- sudo docker ps 명령어로 실행중인 컨테이너 확인
blue와 green이 전부 실행중인 것을 볼 수 있습니다.
- 배포 로그(deploy.log) 확인
EC2에 접속해서 루트 경로에서 cat deploy 명령어로 로그의 내용을 확인합니다.
20:28:47 배포를 시작하고, 실행중이던 green을 중단 시작한 시간은 20:29:23입니다.
배포 스크립트 내용처럼 배포를 시작하고 30초 쉰 후에 green을 중단하고 배포가 완료 되었습니다.
⚽ Trouble Shooting!
설정을 전부 완료하고 커밋도 하고 푸쉬도 완료해서 job도 전부 실행완료인데 배포가 이뤄지지 않아서 처음 겪는 오류에 난감했었습니다. 그래서 배포를 담당하는 CodeDeploy 서비스에 방문해보니 문제가 있었습니다.
배포 스크립트가 문제가 있었던 것을 확인하게 되었습니다. 상세한 로그를 확인해보니 배포 스크립트를 수정하며 경로를 잘못입력하는 실수를 한걸 확인했습니다.
에러 로그를 보고 경로를 home/ec2-user/deploy.log -> /home/ec2-user/deploy.log로 수정한뒤에도 에러는 고쳐지지 않았습니다.
물론 경로가 틀린 것도 문제여서 저 문제를 고치는 것은 맞지만, 저 문제를 해결하니 다른 문제가 찾아왔습니다.
이 문제는 AWS EC2 인스턴스의 볼륨 용량이 꽉찼을때 생기는 문제입니다.
AWS EC2 인스턴스는 볼륨의 default 값이 8GB로 상당히 적은 편입니다. 이 문제를 해결하기 위해서 AWS EC2의 볼륨을 30GB로 증가 시켰고 문제는 해결되었습니다.
AWS EC2 인스턴스의 볼륨을 늘리고 반영시키는 것에 대한 포스팅은 다음에 상세히 다뤄보겠습니다.
🤠 다음으로..
이렇게 서비스가 끊기지 않고 배포가 잘 되는 것까지 눈으로 확인하게 되었습니다.
생각을 하다보니 문제점이 하나가 떠올라서 다음 목표로 잡아야겠다는 생각이 드는 부분이 있었습니다.
Github Actions를 이용하면 프로젝트가 빌드될때 문제만 없다면 배포까지 일사천리로 진행이됩니다.
컴파일타임에 잡히지 않는 런타임 에러를 내장하고 배포가 된다면 서버를 키자마자 애플리케이션은 종료되고, 배포 스크립트대로 기존에 동작하던 애플리케이션까지 종료되어 사용자에게 불편을 야기할 것입니다.
그렇다면 이 문제를 어떻게 해결하면 좋을까? 하는 생각을 하게 되는데 이것에 대해서는 개선할 수 있는 여러 방법들을 고민해보고 제 프로젝트에 적용해서 더 좋은 게시글로 돌아오겠습니다.
런타임 에러 발생시 애플리케이션 전체 종료 문제를 해결한 게시글
Github Actions & Nginx를 이용한 CI/CD 무중단 배포 자동화 구축 - 진짜 무중단 배포가 맞을까?(feat. 런타임 에러)
게시글로 이동 ->
읽어 주셔서 감사합니다.
