개인 회고 | w4 정민 - boostcampwm2023/web08-ByeolSoop GitHub Wiki

도커로 배포를 진행할 때 모르는 부분이 많아 검색을 계속 했다. 진행할 때 노션에 끄적끄적 했는데, 왜 이런 근거로 이렇게 구현을 했다! 라고 작성된 부분이 별로 없다. 그때는 분명 생각하고 한 것 같은데.. 제대로 기록을 정리해보고 싶다.
GitHub Action 배포 자동화에 대한 workflow yml 파일을 작성해보면서 될까? 싶었는데 역시나 직접 돌려보지를 못하니까 예상하지 못하는 문제들이 발생했다. Hotfix로 수정하고 이후에 배포가 잘 되는 것을 보면서 너무 뿌듯했다.. 🥹
새벽까지 구현하는데, 뭔가 몰입해서 계속 코드를 작성했던 것 같다. 영양가있는 코드를 작성했는지는 모르겠지만..? 그래도 억지로 구현을 하려고 한 것이 아니라 얼른 완성하고 싶어서 열심히 한 느낌이 들었다.
피어세션 시간에 다들 왜 도커로 배포하려고 하세요? 라는 질문에 명확하게 답을 생각하지 못했다. 왜 이렇게 배포하려고 했는지도 모른채로 열심히 했나.. 싶었다. 물론 새롭게 해본 과정이라 경험으로 좋았는데, 명확한 근거를 다시 한번 생각하며 기록하는 습관이 필요하다.

nginx.conf 파일을 작성해보면서 Nginx가 요청을 어떻게 처리해야 하는지를 정의해볼 수 있었다.
fetch 는 브라우저에서 요청을 보내기 때문에, ip를 제대로 명시해주어야 한다.
- 도커 컨테이너들을 같은 도커 네트워크에 두면서 도커 서비스 이름으로 통신을 시도했었는데, 안되었던 이유가 위와 같았다.
React로 작성한 코드는 웹 서버에서 정적 파일 서빙만으로도 제공할 수 있다.
- 프로젝트 현황공유 시간에 FE 서버를 굳이 도커 컨테이너로 띄우지 않아도 될 것 같다는 의견을 통해 알 수 있었다.
도커 이미지 빌드의 경우 CI 시스템을 통해 수행하는 것이 일반적이다. 운영 중인 서버에서 직접 이미지 빌드를 수행하는 것보다 효율적이다.
테스트 코드를 통과했을 때 main 브랜치에 merge 될 수 있도록 workflow를 작성할 수 있다는 사실을 프로젝트 현황공유 / 피어세션 시간에 배웠다.