[Bootcamp W11 회고] 이 죽일놈의 AWS Elastic Beanstalk - 배포 실패 시 긴급처방

진짜 이놈 때문에 죽다 살아난 기분이다. 거의 온전히 3일을 여기에만 매달렸다. (지금 이걸 하는게 맞나? 응?) 그럼에도 불구하고

난 나중에 프론트엔드 개발자로 나갈거니까 에라 모르겠다~

 

이런걸 할 수 없는 입장이다. 배포는 제품이 최종적으로 세상에 선보여지는 화룡점정과 같은 것. 이것을 못하면 결국 완성된 사업구상을 진행할 수 없고 그것은 결국 최악의 망삘. 무조건 해내야 한다. 겨우 이따위 가벼운 배포툴에 지는건 말도 안된다.

 

여튼 이기긴 이겼는데 뭔가 말끔하진 않다. 네가 못났냐 내가 못났냐 싸움 같은 느낌이랄까;;; 어쨌거나 근본적인 해결책은 아니라 할지라도 긴급한 불 끄는 정도의 솔루션은 이 글에서 얻어갈 수 있을듯.

손쉽다구요? 님... 맞을래요?

전제조건

이 배포는 아래와 같은 구성으로 이뤄져 있다.

• node.js
• express
• mongoDB (w mongoose)
• passport
• 등등...

 

전쟁의 서막

백신3차 접종으로 몸살 후유증을 엄청 앓았음에도 기능구현은 수요일에 얼추 끝났다. 그래서 배포 후 나머지 디테일을 손봐야겠다고 생각. 가벼운 마음으로 찬찬히 AWS 계정설정 및 IAM 설정, AWS CLI 및 EB CLI 설정을 후다닥 마쳤다. 뭐야 이거? 그냥 찬찬히 해나가니 금방 끝나네? 싶었다. 차분하고도 신속하게 이것저것 문서를 보면서 eb deploy를 향해간다. 모든것이 순조로웠다. 여기까지는.

 

문제의 시작 : Codecommit은 사용하지 말자. (502 에러 단계)

세팅하면서 그런 생각이 들었다.

어차피 git으로 배포하는거잖아? 그럼 CodeCommit도 함께 활용하면 굳이 pipeline 세팅을 하지 않아도 푸시와 배포를 한번씩 해주면 되는거 아니야? 

 

아니다. 그러면 안됐다. Gitlab과 연동해서 함께 관리를 시작하면 checkout 버전을 여러개 관리하는게 답이다. 이렇게되면 여간 번거로운게 아니다. git 저장소를 왔다갔다하면 꼬이고 꼬이고 꼬인다. 한큐에 모든걸 해결할 수 있는게 아니라면 중복으로 git을 활용하는 것은 적절하지 않다. 물론 목적이 분명하고 프로페셔널하게 앞으로 벌어질 모든 일들을 책임질 수 있다면야 가능한 시나리오이긴하나 최소한 권장되는 방식은 아니라고 본다. CodeCommit Repositories 생성/삭제만 몇번을 했는지 모른다. local에서는 잘 돌아가는데 배포하면 502에러가 뜨는건 다 이 과정에서 문제가 있다는 생각이 들었다. 파이프라인 설정을 괜히 하는게 아닌듯...하고 읊조리면서. 하지만 깃허브에 올리기는 싫었다. 이번에 만든거 못생겼어... 이런거 올리고 싶지 않아... 뭐 이런 마음. 여튼...

 

이때는 적당히 502에러 정도에서 멈춰있었다. 스포를 하자면 여기로 다시 돌아온다. 복기해보니 빡치는 수미상관... ㅠ

얻은 것	잃은 것
- 온갖 삽질을 통한 git 활용경험 축적 - git 작동방식 완전 이해	- CodeCommit Repositories 공간 낭비 - 시간, 체력, 정신건강

이런 수미상관은 씹덕들의 전유물...(이라고 루리웹에 나와있음요)

 

늪에 발을 들이다 : 온갖 추가 설정들 (deploy fail 단계)

시간이 점점 흐르고 마음은 조급해진다. 다른 리전에 배포하는 귀여운 실수도 해본다. stackoverflow 로 브라우저 탭이 채워진다. 물론 그지같이 복잡하고 구성도 더러운  AWS 공식문서들도 함께. 영문/한글 가리지 않고 블로그나 유튜브로 갖가지 가이드와 경험담들을 탐독한다. eb logs와 함께 이것저것 하나하나 대입해본다. 그러면서 했던 주요 삽질들은 아래와 같다.

• 환경 구성에서 온갖 값들을 우겨 넣는다. port 포함 (5000? 8080? 이게 제일 삽질)
• package.json 에서 node 버전을 특정한다. ^ 이렇게? ~ 이렇게? >= 이렇게? 뭐 이런걸로도 한참 고민한다.
• 환경설정용 파일을 추가로 구성한다. .ebextensions/nodejs-settings.config 뭐 이런걸 구성해서 아래 코드같이 넣는다던지... (당연히 아래 코드를 넣지는 않았다;;;)
  

  option_settings:
    aws:elasticbeanstalk:environment:proxy:
      ProxyServer: apache​

• 기존 어플리케이션에 추가로 deploy해서 안되는건가 싶어 eb create를 남발한다. 
• node module 들을 하나씩 제거하고 깔고를 반복하면서 그 버전들을 다시 배포하고 또 배포해본다.

이젠 502에러가 그리울 지경이다. 배포 자체가 안된다. 에러 메시지들도 아주 가지각색이다. 짜증이 솟구친다. 아무리 검색해도 시원한 이야기는 없다. 도대체 여긴 어디? 난 누구? 시간과 정신의 방에 갖혀서 낮밤 및 시간 인지능력이 증발한다. 

얻은 것	잃은 것
- 기본적인 eb 구동방식 완전 내재화 - 그 어느것도 참조하지 않고 명령어를 쳐내는 자신을 마주하게 됨	- S3 공간 낭비 - eb 환경 및 애플리케이션 공간 낭비 - 시간, 체력, 정신건강

시간과 정신의 방

 

다시 처음으로, 순수하게 : express-generator로 돌아가보자

멘토 찬스를 썼음에도 멘토도 고개를 절레절레하게 만드는 상황까지 맞이하다보니 이런 생각이 들었다. 이럴땐... 처음으로 돌아가보자. 다시 처음부터 시작하자. 그래서 아래와 같이 시작했다. 기본 전제는 이렇다. 결국 eb는 환경변수 정보를 바탕으로 자체적으로 빌드를 한다. 그러므로 매번 node module을 설치하고 하지 말고 환경변수 정보만 계속 넘기면서 테스트를 해보자. 그럼 환경변수 문제가 뭔지 파악이 되겠지. 그럼 내가 잘못한건지, 특정 module 호환성이 안좋은건지, eb 네가 잘 못하고 있는건지 알게 되겠지. 그래서 시도한 내용은...

• 폴더를 새로 만들고 그곳에 express-generator로 생성 > git init > git add > git commit > eb init > eb deploy
  => 된다! 심지어 기존에 그 뻑나던 환경과 어플리케이션에 배포했는데 된다!
• package.json에 기존 정보들을 하나씩 추가하면서 배포.
  => 된다! 결국 설치한 node module 문제는 아니었던 것.
• 기존 프로젝트 파일들을 하나씩 추가한다. 그리고 계속 배포.
  => 안된다... 확실히 서비스를 구성하는 파일들 조각이 안맞으니 작동하는게 이상하겠지...
• 그러다 발견한 활용하지 않는 router의 get 요소가 눈에 밟혀서 삭제. 배포. 성공!!!
  => 된다! 우와 이게 문제였던거야???!!!!

찾아서 기쁘기는 한데... 어...? 이게 된다고? 이상했다. 회한의 담배를 한대 물어본다. 이상하다. 되는게 이상하다. 그럼 이제까지 왜 안된거지? 안되는게 맞는건가? 라우터 항목 하나 때문에? 이상한데...

얻은 것	잃은 것
- package.json이 더 이상 안무서움 - 배포 서비스 작동방식 파악 - 의외로 이게 제일 시간이 덜걸림	- 정신건강

자이언티 선글라스를 벗기듯...

 

아니 왜 또~!!! : 배포 공간에서 npm install 과 git remote 및 push를 지양하자

그렇다면 이제 손보고 싶었던걸 좀 보자. 여기저기 하나씩 고쳐본다. 확인이 필요하다. 이제까지 설치하지 않았던 module들 확인을 위해 npm install을 실행하고 로컬서버를 가동한다. 음... 그래 이렇게 고치니 잘 작동하는군. 좋다. Gitlab에도 푸시. 오케이. 이제 eb에도 다시 배포. 그런데....

502 Bad Gateway

 

아 왜~!!!!! 또!!!! ㅠ 짜증의 담배를 한대 물어본다. 그래도 나에게는 아까 성공 경험이 있다. 차근차근 앞의 방식으로 다시 진행한다. 방법을 아니까 시간이 확 줄어든다. 총 소요시간 15분 내외. 배포가 되었다. 여기서 얻은 결론. 결국... 이건 나의 문제가 아닌거 같은데?

얻은 것	잃은 것
- 그래 어디 와봐! X바 맞짱 떠!	- 정신건강

502 다시 봤을때... 실제 내 모습

 

AWS Elastic Beanstalk 배포 실패자를 위한 긴급처방

아직 무엇이 문제인지는 명확하게 모르겠다. 만약, 만약에... AWS Elastic Beanstalk 배포방식 자체가 이게 맞는거라면 이건 eb의 문제라고 본다. 뭐 이렇게 불편하게 만들어놨어? 이정도를 커버하지 못한다고? 이런걸로 이렇게 개고생을 시킨다고? 이게 맞는 방식이라면 이것에 대한 안내나 문서화도 제대로 안해놓는다고? 뭐야 이게...

 

뭐 여튼 일단. AWS Elastic Beanstalk를 배포하다가 빡친다면 이렇게 해보자. 내가 만들어낸 문제가 아니라면, local에서 문제가 없다면 십중팔구 해결될듯.

1. 새롭게 폴더를 만든다.
   - 새로운 폴더의 폴더명은 기존 프로젝트 폴더명 뒤에 -deploy 정도를 붙여주면 적절하겠다.
2. express-generator로 기본 프로젝트 생성 > git init > git add > git commit > eb init
   - 이때 기존 환경과 어플리케이션을 활용해도 문제 없다. 굳이 새로 만들지 않아도 된다.
   - 샘플앱으로 시작해도 되는데 deploy를 하려면 결국 commit 하나는 필요하다. 뭐 원하는대로.
3. eb deploy > 배포성공 확인
   - 특별한 목적이 없다면 굳이 CodeCommit 쓰지 말자.
4. AWS Elastic Beanstalk 환경 > 구성 > 소프트웨어 > 환경속성에 적절한 값 입력
   - DB 주소나 session 정보는 프로젝트가 올라가기 전 챙기고 세팅하자.
5. package.json에 기존 module 정보들 입력 > eb deploy > 배포성공 확인
   - npm install 하지 않아도 된다. 이 폴더는 배포만을 위한 폴더다.
6. 기존에 작업한 프로젝트 파일들 복사해서 이동  > eb deploy > 배포성공 확인
   - 당연히 /node_moduels 폴더나 .gitignore, .env 파일 등은 복사하지 않아도 된다. 다시 한번. 이 폴더는 배포만을 위한 폴더다.

수고하셨다. 구석에 박혀있는 이 포스트까지 찾아와서 본 사람이라면 정말 수고하셨다.

 

아직도 완전 속시원하게 명확하진 않다. 그래도 추측을 해보자면...

git branch를 default(as master)로 유지해서 배포를 해야하는걸까?

package-lock.json 파일이 배포에 영향을 주는건가?

뭔가 한번 잘못 배포되면 기존 어플리케이션 버전이 캐싱되서 이후 배포에도 영향을 주는건가?

설마...이거 나만 이런건가???

 

Voting Platform by jinho

 

여튼 이런 삽질은 기록해둘 필요가 있다. 나중을 위해서라도.

해가 떴다. 이제 졸리다. 배도 고프고... 자야지... 어우야...