적어도 20시간 정도는 잡고 있다가 결국 자고 일어나서 해결해버렸다.
문제 상황
문제 상황이랄것도 없다. 그냥 nginx 를 연결하고 난 뒤로부터 CORS 에러가 계속 났다.
이전 포스트에 작성했던 코드가 잘 실행되는 줄 알았지만 알고보니 nginx 파일이 전송되지 않고 있었고 이상한점이 많았다. 결국 "폰"블루/그린 배포를 진행중이었다.
암튼 CD workflows 를 수정해주고 정상적으로 nginx 파일을 ec2 환경으로 옮겨주었다.
새로 배포된 환경에 대한 health check 에러
CD 를 진행하면서 이상한점이 있었다. health check 를 진행하기는 했지만 완성됐다던가 성공이라던가 하는 것 없이 계속 수행되는 것이었다.
알고보니 제대로 health check 가 이루어지지 않고 있었다.
until [ "$(curl -s -o /dev/null -w '%{http_code}' http://localhost:8081/tig/health)" == "200" ]; do
echo "Waiting for BLUE environment to be healthy..."
sleep 5
RETRY_COUNT=$((RETRY_COUNT + 1))
if [ "$RETRY_COUNT" -ge "$MAX_RETRIES" ]; then
echo "Health check for BLUE environment failed after $MAX_RETRIES retries."
exit 1
fi
done따라서 위와 같이 추가 했다. 최대 시도횟수를 설정해두고 기다리는 것이다.
추후에 알고보니까 Spring boot 환경이 다 뜨기전에 health check 를 끝내버려서 제대로 안된 것이었다.
만약 비슷한 상황을 겪는다면 sleep 시간을 늘리거나 재시도횟수를 늘려보는 것도 방법이다. (나의 경우에는 서버 환경이 뜨는데 40초 정도 걸렸다)
본격적인 CORS 에러
성공적으로 블루 OR 그린 환경이 뜬다는 것을 확인했다. (docker ps 로 보니까 배포 할 때 마다 계속 환경이 바뀌었음)
이때부터 본격적으로 CORS 에러를 만나기 시작했다.
1 . 첫번째 해결 시도 - Nginx 파일에 헤더 추가
기존에 CORS 에러를 만난 적이 있었기에 자신감있게 nginx.conf 파일에 헤더 관련 설정을 추가해주었다.
location / {
proxy_pass http://green_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# OPTIONS 요청 처리
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' 'https://tigleisure.com';
add_header 'Access-Control-Allow-Methods' 'GET, POST, DELETE, PATCH, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type';
add_header 'Content-Length' '0';
add_header 'Content-Type' 'text/plain charset=UTF-8';
add_header 'Access-Control-Max-Age' 1728000;
return 204;
}
}CORS 에러 쯤이야 ㅋㅋ 하는 마음으로 배포를 다시 했으나 똑같았다.
불안한 마음에 여러 블로그를 찾아보고 지피티에게도 물어봤는데 해결방법을 찾았다.
2 . 두번째 시도 - CORS 설정이 겹치지 않게끔 설정
Spring Boot 에서 설정한 CORS 에러 설정이 있다면 nginx 에서 따로 해주지 않아도 된다
이 말을 보고 바로 Spring Boot 내부에 있던 CORS 설정을 지웠다.
하지만 여전히 에러가 발생했다.
보통의 사람들이라면 여기서 해결이 되었을 것이다. 하지만 나는 다른 문제가 있었다.
로드밸런서 였다. AWS 콘솔에 들어가서 로드밸런서를 확인해보니, health check 항목에 빨간 불이 켜져있고 상당히 불쾌한 unhealthy 라는 말이 떠있었다.
3 . 세번째 시도 - Load Balancer 수정하기
처음엔 무엇이 문제인지 몰랐다. 분명히 보안그룹에서 포트도 잘 열려있고 연결되어 있는데...
구글링 해보았는데 health check 하는 경로를 재설정해주어야 할 수도 있다는 것을 찾았고, 로드밸런서의 helath check 경로를 /tig/health 로 재설정 해주었다.
예상 할 수 있겠지만 CORS는 해결하지 못했다.
4 . 네번째 시도 - 전체 흐름 생각해보기
이때부터는 살짝 뭐랄까 집에 있는데도 집에 가고 싶었다.
전체 프로세스를 생각해보자.
- 로드 밸런서가 80 혹은 443 에 대한 요청을 받고 이를 모두 8080 으로 이어준다.
- nginx 가 이를 받아서 블루 혹은 그린으로 넘겨준다.
- TIG 백엔드 서버가 받은 일을 실행한다.
문제가 되는 부분이 어디일까 하나씩 따져보기로 했다.
일단 3번 TIG 서버가 잘 돌아가는건가?
docker ps 를 통해 떠있는 환경을 확인 해보고 docker logs app-green 과 같이 로그를 확인 해보았다.
-> NO PROBLEM
다음 2번 nginx와 TIG 서버는 잘 연결되어 있는가?
다행히도 도커에서 해당 명령어를 제공한다.
docker network ls # 도커 네트워크 목록 출력
docker network inspect <네트워크의 이름> # 해당 네트워크에 어떤 것들이 연결되어있는지위의 명령어를 통해 배포된 환경(blue or green)과 nginx가 하나의 네트워크에 있음을 확인 했다.
마지막 남은 1번, 그렇다면 로드밸런서가 nginx 로 넘겨주지 못하고 있나?
아차 싶었다. nginx 에서는 listen 80; 와 같이 80 포트를 듣고 있었는데 로드 밸런서는 위의 이미지에서 볼 수 있듯 8080포트로 냅다 던지고 있던 것...!!!
바로 수정했다.
그랬더니 불편했던 로드밸런서의 unhealthy 도 초록색으로 바뀌고 되는 듯 했다.
5 . 다섯번째 시도 - 200인데도 CORS 에러
여기까지 진행했을때 개발자도구의 네트워크 탭을 까보니까 200OK 라고 써있음과 동시에 CORS 에러라고 써져있었다.
이상한 점이 있었다. 잘 보면 Access-Control-Allow-Origin 이 두개나 들어있고 둘다 같은 값을 가지고 있던 것이다.
이때 다시 생각났다.
nginx 와 Spring boot 에서 중복으로 CORS 설정을 해줄 필요가 없다.
nginx 를 붙이기 전에는 CORS 에러를 만난 적이 없었기 때문에 과감히 nginx 에서의 CORS 설정을 지우고, 백엔드 코드 내에서의 CORS 설정을 남기기로 했다.
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
아주 흡족스러웠다. 코딩으로 도파민을 채워본 것은 오랜만이다.
