[플젝기록/트러블슈팅] 서버 및 DB 배포(AWS)와 CI/CD 구성 (3)

이전 포스팅에서 npm 컨테이너를 띄워서 포워딩 및 기타 NGINX의 작업을 수행했다고 했는데,

이것 때문에 문제가 생긴 적이 있다.

GitHub Actions를 통한 배포 자동화 시스템 상, 지정한 브랜치에 merge되는 순간 자동으로 새롭게 배포가 되는 방식이다.

API 서버, 즉 애플리케이션은 새로 업데이트를 해야 하는 게 맞으니 별 문제 없다.

문제는, 그 과정에서 매번 npm 컨테이너 또한 새로 빌드되고 있었다는 것이다.

 

---

1. 문제 파악

처음 발견한 문제는 API 서버 컨테이너가 제대로 빌드되지 않는 것이었다.

애플리케이션 자체에는 아무 문제 없고 수동으로 rerun 해주면 되긴 하지만 매번 그렇게 할거면 배포 자동화를 구축하지 않았겠지...

Docker 각 컨테이너의 로그와 EC2의 로그까지 확인한 결과, 이전 컨테이너와의 충돌문제라고 결론을 내렸다.

그런데 분명히 docker-compose.yml 파일에 기존 컨테이너를 지우고 최신 도커 이미지를 가져와 새로 빌드하는 명령어를 둔 것 같은데 왜 기존 컨테이너가 남아있다가 충돌을 일으키는지는 알 수가 없었다.

 

2. 문제 재정의와 의문 제기

응 아니니까...

정확히는 맞긴 한데, 핀트가 어긋난 결론이었다.

API 컨테이너가 기존 컨테이너와 충돌한 게 아니라, npm 컨테이너가 기존 npm 컨테이너랑 충돌한 문제였다.

자, 문제의 원인을 알았으니 해결하면 된다.

npm 컨테이너가 매번 충돌 없이 빌드되도록 삭제 명령어 앞에 sudo를 붙인다든가, compose 파일의 명령어를 조절하든가...

그런데, npm 컨테이너가 계속 새롭게 빌드될 필요가 있는가? 라는 의문이 들었다.

npm은 어차피 정해진 IP 주소와 도메인, HTTP → HTTPS 과정의 SSL 인증과 포워딩 작업, 특정 포트에 대한 일정 이상의 요청 제한 정도를 수행하는데 굳이 매번 새로 배포해야 하는가?

 

3. 새로운 방법 평가 및 실행

npm 컨테이너의 내용이 업데이트 되는 경우가 있는가? 아니오. (언젠가는 있을수도 있지만)

npm 컨테이너가 주기적으로 새로 빌드되어야 하는 이유가 있는가? 아니오.

npm과 application 컨테이너의 배포 주기는 동일해야 하는가? 아니오.

이후 클로드와의 대화를 통해, 컨테이너 빌드 파일을 분리해서 npm은 필요할 때만 수동 빌드하자라는 결론에 이르게 되었다.

그래서 각각 api-compose.yml과 npm-compose.yml로 분리하고 배포 파일도 이를 반영해서 수정해줬다.

다시 배포한 뒤, api 컨테이너가 잘 올라가는 걸 확인했다. 끝!

 

---

슬슬 AWS 온보딩 관련 포스트를 올리려고 했는데 오늘 이래저래 바빠서 하나도 못 봤다.

8월까지니까 굳이 서두를 필요는 없지만, 컨텐츠 없을 때 딱이라 곧 하나씩 볼 예정이다.

오늘은 개표 방송을 보다가 잘 것 같은데, 기분 좋게 잘 수 있으면 좋겠다.