오늘 진행한 일

프론트엔드 메인 서버 이슈 해결

블링과 함께 프론트엔드 메인 서버의 nginx가 정적 파일을 뱉어내지 않는 오류를 해결했다. nginx 설정을 초기화 해보기도 하고, nginx를 아예 지우고 다시 설치해보기도 했는데, 정말 황당한 오류였다. nginx에 권한을 제대로 주지 않은 오류였다. 권한을 적절히 주고 나니 이상 없이 프론트엔드 서버를 돌릴 수 있었다.

nginx 포트포워딩

스프린트 3 백엔드 요구사항 중에 WS + WAS 연결을 통해 443포트로 데모가 있다. 그래서 아직 https는 적용하지 않았지만 80포트로 대신해서 WS + WAS 연결을 통해 80포트로 데모를 시도해봤다. 백엔드 ec2에 nginx를 설치하고, 80포트를 WAS가 떠있는 8080포트로 포트포워딩 해줬다. 프론트엔드 코드를 수정할 수 없어서 Postman을 통해 테스트 해봤는데, 80 포트로 api 요청을 해도 정상적으로 응답을 해 주는 것을 볼 수 있었다. 고민한 부분은 백엔드 nginx를 따로 ec2를 올려서 사용할 지 여부였는데, 브라운이 한 대의 ec2에서 전부 다 띄우면 안되는지 ec2 여러 대를 꼭 띄워야 한다고 생각하는거 같아서 물어보는거에요 라고 해주셨다. 그래서 당연히 API 서버를 감춰야 하니까 여러 대 띄워야 하는 것 아니냐고 얘기했는데, API를 감추라는게 요구사항이 아니라 "WS + WAS 연결을 통해 443포트로 데모"가 요구사항이니까 이 말 그대로 받아드려도 괜찮을 것 같아요 라고 해주셨다. 그렇다. 그냥 ec2 한 대에 다 올려도 트래픽만 버티면 문제 없을 것 같다. (그런데 못 버틸 정도로 트래픽이 발생하지도 않을 테니까…) 그래서 일단은 ec2 한 대에 WS와 WAS를 모두 올려놓고 사용하려고 한다.

오늘 발생한 이슈

PR에 달린 라벨을 기준으로 프론트엔드와 백엔드 CI/CD 분리하기

여태까지 우리 팀의 Jenkins CI/CD 환경은 빌드가 유발되면 프론트엔드 코드와 백엔드 코드를 한 번에 빌드하고, 배포하고 있었다. 하지만 백엔드 코드만 수정했는데 프론트엔드 배포도 동시에 진행되는 상황을 보니, 백엔드와 프론트엔드 배포 과정을 분리하고, 각각 트리거를 다르게 적용하고 싶었다. 백엔드와 프론트엔드를 구분할 수 있는 방법으로 뭐가 있을까 생각하다가 GitHub PR에 달리는 라벨을 이용하는 것이 어떨까 하는 생각을 했고, 칙촉과 함께 라벨을 기준으로 빌드를 유발하도록 설정했다. 고작 라벨을 기준으로 빌드를 분리하는 것 하나에 수많은 난관이 있었고(정작 대부분은 휴먼 에러로 인한 것이었다.) 빡빡이 아저씨만 보면 화가 날 지경에 이르렀다.

젠킨스, 웹훅, 라벨을 사용해 빌드를 유발하는 방법은 여기를 참고하자.

내일 목표

내일은 코드리뷰 해야 한다…