[팀 프로젝트] AWS EC2 배포를 수행하다 - 팀원들이 나에게 양보해준 뜻깊은 기회 -2

저번에 블로그를 작성한게 EC2 배포에 대한 블로그아니냐고 의문을 자아할 수 있다.

하지만, 저번의 배포는 임시의 메타 배포로 중간 개발완료인 상태, 한마디로 어드민 사이드의 기능에 대해서만 배포를 우선적으로 했다.

그래서 저번에 배포는 메타 배포로 개발완료된 API가 아니었다.

 

그럼, 이번 블로그의 주제는 무엇일까?

바로 개발 완료된 API를 배포하는 것이었다.

 

저번에 배포를 하면서 처음 배포를 맡아서 어려움이 많았지만, 시간을 많이 들여서 결국엔 배포를 성공할 수 있었다..ㅋㅋ

배포하면서 6 ~ 7시간 걸려서 배포를 했지만, 배포과정에서 어려움을 겪었지만, 하나씩 해결하면서 배포를 했었다 ㅎㅎ..

과거의 나 칭찬한다 ㅎㅎㅋㅋㅋ

 

그래서 이번에 배포를 수행할 때는 비교적 배포에 대해 큰 벽이 없어졌고, 저번보다 훨씬 빠르게 배포를 완료했다 ㅎㅋㅋㅋ

 

이번에 배포를 하면서 겪었던 시행착오에 대해 블로깅을 하겠다.

---

Swagger 를 이용할 수 있게 Swagger.js 수정

저번 배포에서 API를 성공적으로 배포를 했지만, Swagger에서는 API 통신이 안되는 에러가 있었다.

Swagger란, 웹사이트에서 직관적으로 API를 사용하면서 기능들에 대해서 알아갈 수 있도록 도와주는 API 명세서 역할을 하는 도구? 이다. - 프론트 개발진분들이 Swagger 웹사이트를 참고해서 API를 엮는다.

 

어쨋든, 배포는 성공해서 postman에서는 통신이 되었지만, Swagger에서 통신이 안되었다.

알고보니, Swagger.js 에서 서버의 라우팅 경로가 로컬호스트 환경으로 되어있는 걸 알 수 있었다.

왜 로컬호스트로 되어있었냐면, API를 만들 때는 로컬호스트 환경에서 만들면서 테스트를 진행했기 때문이다 ㅎㅎ..

 

 

그래서 다음과 같이 host 주소를 EC2 퍼블릭 주소인 탄력적 IP로 바꿔주었다.

:3000,,, 3000포트는 node.js가 통신하는 포트번호이고, 3000번호를 포트 리스닝해서 node.js 코드를 동작한다.

 

여기서 주의할 점은 EC2에서 배포를 할 때는 터미널 환경에서만 작업이 가능하므로,

vim 편집기를 사용해서 swagger.js 파일을 위와 같이 수정해준다.

vim 사용법은 컴퓨터개론에서 배웠기 때문에 쉽게 쉽게 할 수 있었다 ㅎㅎㅋㅋ

 

 

vim으로 편집한 후 :wq! 로 꼭 저장 후 종료를 수행한다.

 

Git 사용한 과정

코드는 upstream main에서 우선 로컬환경 main에 pull을 받고

약간의 충돌?을 해결하고 origin main에 코드를 push해줬다.

그리고, EC2 터미널에서 origin main을 pull 받아 개발 완료된 API를 받았다.

여기서 origin main -> EC2 터미널로 pull할 때 충돌이 발생해서

git status로 충돌이 발생한 파일을 확인하고,

EC2 터미널 환경에서 vim 편집기로 충돌이 생긴 곳에 대한 코드를 가장 최신버전의 코드로 수정했다.

 최신버전의 코드란, 개발 완료 후 배포 준비가 된 코드로 바꿔준다는 의미다.

그리고, git add , git commit -m 명령으로 EC2 터미널 로컬저장소에 코드를 커밋해두고,

그다음 작업인 pm2 무중단 서비스로 서버 가동을 시작했다.

pm2 무중단 서비스로 서버 가동

이제 다와간다.

pm2를 이용해 서버를 무중단 서비스로 활용하면 된다.

여기서 pm2를 수행할 때 주의할 점은 터미널 EC2 권한 별로 실행 영역이 달라짐을 유의해라.

권한 별로 달라지는 건 사용하면서 깨달은 것..! 이에 대해선 따로 구글링해서 더 알아보도록 하겠다.

 

 

 

그러니깐, sudo 권한으로 pm2로 서버를 가동시키면, 더 확장된 영역에서 서버가 가동되는 듯하다.

아래 명령으로 sudo 권한으로 pm2를 실행시킨다.

$ sudo pm2 start init.js --interpreter ./node_modules/.bin/babel-node

 

그러고 난 뒤 pm2 list를 각 권한별로 실행해보면,

sudo 권한에서 pm2 list 명령으로 init.js 가 가동 중인 상태를 확인 할 수 있었다.

그래서, pm2에서 서버를 가동 시킬 때는 웬만하면? sudo 권한으로 하는게 안정적으로 서버를 관리할 수 있는 것 같았다.

왜냐, sudo권한이 pm2를 사용할 수 있는 기능에 전체집합 성질을 띄고 있는 듯해서 그렇다 ㅎㅎㅋㅋ - 더 자세한 건 구글링 해보면서 알아보겠다.

일반 권한으로 pm2 list

 

sudo권한으로 pm2 list

 

 

그래서 우리는 지금, 이미 저번에 pm2 명령으로 무중단 서비스로 서버를 가동하고 있었다.

그리고, 우리는 개발 완료한 코드를 pull 받아서 충돌을 해결하고 위에서 swagger 라우팅 경로도 바꿔줬다.

그러니깐, 저번에 서버를 가동할 당시의 API와 지금의 API는 업데이트되어서 pm2에게 업데이트한 API로 서버를 가동하라고 지정해줘야 한다.

 

여기서 pm2를 사용하는 방법을 몰라서 애를 좀 써먹었다 ㅎ..ㅋㅋ

 

애를 먹은 이유는 sudo권한으로 pm2 명령을 수행하지 않아서 pm2 명령이 EC2 터미널에 적용되지 않았던 것이다.

이렇게 보면 참 단순하다.. 하지만, 그 당시에는 이유를 몰랐고, 여러번의 pm2 명령을 써보는 경험과 구글링을 통해

pm2 명령을 수행할 때 sudo 권한으로 API를 재시작해줘야 한다.

 

아래 명령으로 새로 바꿔진 API를 실행해서 pm2로 서버를 무중단으로 가동하게 만들었다.

$ sudo pm2 restart init.js --interpreter ./node_modules/.bin/babel-node

 

 

이제 swagger에 가서 확인해보자.

 

짜잔!!~~ 배포 성공한 모습이다.

저번에 안되었던, Swagger에서 API 테스트도 정상적으로 완료되었다 ㅎㅎㅋㅋ

.env 수정한 것도 따로 vim 편집기를 사용해서 수정해줘야 한다. 처음에 안해줘서 JWT 토큰을 인식하지 못했었다 ㅎㅎㅋㅋ

.env 파일은 보안과 직접적으로 관련되어 있는 항목이기에, .gitignore 파일에 기록되어 있다. - gitignore은 예전 블로그에 설명했음 ㅎ

 

 

 

백앤드 개발 완료 후 배포를 성공한 후의 소감

참 할 말이 많다. 그렇지만 핵심만 말하겠다.

지금 졸리기 때문... 이틀간 밥 한 끼만 먹고 백엔드 개발만 했다 ㅎ...ㅋ

 

새로운 걸 도전할 때는 처음엔 원래 어려운 법이다. 그렇기에 어렵다고 뒷걸음질 치는 것보다 그냥 해보면서 어려움을 간파해나가는 게 내 미래의 인생에 있어서 편한 길이다 ㅋㅋ

이건,  백엔드 개발하면서 느낀점이고

 

 

오늘 배포를 하면서 느낀점은

개발과 코딩은 유추하면서 정답일까? 라는 확신으로 다가가는 게 아니라, 이렇게하면 되겠는데? 라는 생각으로 접근을 하는게 더 편하고

더 빠르게 답을 찾아내는 길이라는 걸 깨달았다.

왜냐 확신된 답으로 접근해도 틀린 경우도 많기 때문이다.

그렇기 때문에, 확신된 답이 아닌, 이렇게하면 되겠는데? 라는 생각으로 유추하면서 코딩을 해야지 스트레스도 덜 받고 재밌게 코딩을 할 수 있다.

확신된 답을 찾아나가는 코딩은 나와의 고통이고 전쟁이다. 그래서 금방 코딩을 질려할 수 있다 ㅋㅋ..

그렇기에, 앞으로 나는 답을 찾아나가는 코딩 방식이 아닌, 이렇게하면 어떨까? 라는 유추하면서 코딩을 할 것이다.

이것도 완벽한 정답은 아니며, 내게 좋은 답안 중 하나라고 생각하고 앞으로 더 많은 걸 배우려고 노력하겠다!

 

지금까지 성공하는 개발자 이든이었습니다. 감사합니다.

 

"큰 행복엔 큰 책임감이 뒤따른다."