오늘 만났던 문제를 정리해보니 다음과 같이 정리할 수 있었습니다.
프론트에서 스웨거로 간편하게 API 테스트를 하지 못하는 것
그리고 아이피와 포트 형태로 서버에 접근해야 한다는 것은
매우 불편하다는 걸 알고 있기 때문에 아주 중요한 문제들이었습니다.
결국 주말을 반납할 각오하고 박살내러 출발했습니다.
현재 쓰고있는 서버 인스턴스는 AWS의 Lightsail입니다.
고정 아이피 (static ip)는 발급받아 연결해 놓은 상태였구요.
하지만 보기도 불편, 맘도 불편, 보안적인 이슈등의 이유로
없는 살림에 도메인을 빌리러 갔습니다. ㅜ_ㅜ
AWS에서 서비스하는 Route 53에서 도메인을 결제 후 발급받았습니다.
이제 제 인스턴스와 해당 도메인을 이어야겠죠.
근데 어라라?
단순 라우팅으로 이어주면 되겠다고 생각하여
도메인 레코드에 추가하여 이어주었지만
https로는 접근이 안되었습니다.
알고보니 https는 보안 프로토콜이기 때문에
Load Balancer라는 것이 필요했습니다.
인스턴스를 처음 생성했다는 가정하에 순서는 다음과 같이 진행되었습니다.
인증서를 Verifying 하는 과정이라던지,
인스턴스를 Attach한다던지 하는 과정들이
곧바로 반영되는 작업들이 아니어서 시간이 좀 더 걸린감이 있었지만
이렇게 작업하고나니 https로도 잘 접속되었습니다.
자 이제 도메인도 정상적으로 돌아가겠다
스웨거에서 API 테스트를 해보려하니
CORS관련 메세지를 뱉으며 Response를 확인 할 수 없었습니다.
대부분 CORS관련 오류들은
실행되는 서버의 주소와 호출하는 서버의 주소가 달랐을 때
발생한다는 것을 기억하고 다시 살펴보았습니다.
역시나 로컬에서 테스트로 돌리던 서버에서
AWS 서버를 호출하니 생겼던 문제였습니다.
(cors 라이브러리를 사용했음에도)
테스트 용이성을 위해선 다른 방법이 있는지 좀 더 봐야 하겠지만
서버에 반영시켜 API를 호출해보니 정상적인 값을 받을 수 있었습니다.
혼자서 작업을 쪼개가며 해야 했기때문에
배포 프로세스를 최대한 줄이고 즉시 반영시키고 싶었습니다.
후에 프로젝트 볼륨이 커진다면 후에 혹시나 같이 일하게될 동료를 위해
git-flow와 PR등은 적용할 예정이지만 일단은 혼자기 때문에 스킵하기로 했습니다.
예전 개인 포트폴리오를 작업하며 Docker를 사용했었을 때
Jenkins를 사용했던 기억이 나, 채택해서 인스턴스에 설치하고
간단한 build script로 CI/CD를 구축했습니다. (nodemon, ts-node)
여러가지 적어가면서 작업할 것도 많았고
예전 기억 더듬어가며 했던 작업들도 많았습니다.
아직은 익숙치않고 부실하다 생각이 들지만
하나 하나 고치다보면 언젠간 쓸만한 놈이 되겠죵