코딩하는 미미

AWS로 배포하기 생각보다 쉽지 않아..

Node.js 프로젝트를 배포하기 위해서 우분투로 EC2 접속하고

열심히 npm i, ls, node ... 투닥투닥

낯설지만 많이 봐왔던 명령어들이 있어서 어렵지 않게 잘 진행하고 있는데

서버가 가동되다가 몇 초가 지나면 아래와 같은 커넥션 타임아웃 에러가 무한 발생...

하지만 언젠가 마주해야 할 업무이지 않을까 해서 끝까지 도전해서 해결 완료.

에러 :

events.js:291
      throw er; // Unhandled 'error' event
      ^

Error: connect ETIMEDOUT

...

해결 :

- 연동할 EC2 정보 확인- RDS(DB) 보안그룹 생성- RDS(DB) 서브넷 그룹 생성

RDS의 보안규칙을 새로 생성해 주고, 사용하는 EC2에 맞게 설정하고 연결해 주었다.

이게 또 다른 누군가에게 일어난 동일한 에러에 대한 정답이 아닐 수도 있기에

검색을 통해 이 글을 보고 있다면, 더 다양하게 키워드를 잡고 검색해서

여러 방식으로 해결을 시도해 보면 좋을 것 같다.

한 번에 해결하는 것도 좋지만, 이런저런 시도를 통해 다양한 정보를 얻을 수 있을 것이다.

수시간동안 삽질을 하면서 검색하면서 나온 수많은 내용들을 시도해 보면서

방화벽 설정, timeout이 짧아서 그런 것인가? 하고 timeout도 변경을 시도해보고 했다.

추후에 보안 그룹 설정이 원이이었던 것을 어느 정도 인지하고

분명 RDS와 EC2를 동일하게 설정해 주어도 안 됐는데

새로운 규칙을 생성해서 설정해 준 뒤에 RDS에 연결을 해주니까

드.디.어. 정상적으로 서버도 가동되고 RDS도 정상적으로 작동했다.

이번 에러에 대한 해결은 살짝 시간이 걸렸지만

다양한 에러에 대해서도 알게 되었고, 이렇게 해결하게 되어 내심 뿌듯한 마음이 들었다.

Netlify로 프런트 프로젝트는 2회 배포해 본 경험이 있는데
백엔드 프로젝트, 그것도 3일만에 속성 학습한 Node.js 프로젝트를 배포해 보니

이건 내심이 아니라 정~~말 뿌듯하다고 생각했고

스프링부트 프로젝트도 얼른 배포해 봐야겠다는 의욕이 생겼다.

근데 과금 안되겠지?! 두근두근

팀프로젝트 했을 때 배포 담당한 팀원 2명이

이용중일 때 1주일마다 1달러씩 빠져나갔다는 얘기를 들었어서

내 AWS도 과금될까..하는 약간의 걱정 :)

ps. 백엔드 위주 작업이다보니 디자인은 코드펜에서 가져와서 작업해보았는데

기능부분에 집중할 수 있어서 굉장히 만족스러웠다!

부트스트랩은 틀 위주로 있고 직접 수정해야하는 부분이 많았는데

마음에 드는 페이지 디자인 코드를 통으로 가져올 수 있어서 꽤 유용하게 쓸 수 있겠다.

참고 사이트

AWS EC2 기본 세팅 후 접속하려고 했는데..

우분투였다면 아래 한 문장으로 쉽게 접속할 것이 윈도우를 사용해서 문제를 마주하게 되었다.

chmod 400 펨이름.pem

에러 내용 :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for '펨파일명.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "펨파일명.pem": bad permissions
퍼플릭DNS: Permission denied (publickey).

해결 :

.pem 파일의 속성 > 보안탭 진입하고 고급버튼 클릭

상속 사용을 눌러 alert창에서 사용 권한을 모두 제거를 누른다.

사용 권한 리스트가 깔끔하게 전부 제거가 된 것을 확인하고

추가 버튼 클릭 > 보안 주체 선택 클릭 

선택할 개체 이름에 본인의 유저 이름을 적고 이름 확인을 눌러보고

맞으면 확인 버튼이 뜨면 전부 확인 누르고 창을 닫고

.pem 위치에서 터미널을 실행 후 다음 내용을 입력하면 정상적으로 접속 OK!

AWS에서 인스턴스에 연결 페이지에 나와있는 예: 부분의코드를 복사하고 붙여 넣는다.

ssh -i "펨이름.pem" 블라블라

과금이 안되도록 잘 관리하면서 프로젝트 배포를 해보아야겠다.

생각보다 정보가 잘 나와있어서

어렵지 않게 배포하는 과정을 밟고 있는 중이다.

국비강의를 들었을 때 React 강의에서 nodejs를 사용해 본 적이 있었고

맛보기로 npm i 라던지...정말 기본적인 부분들만 알고 썼던 상태여서

기초부터 응용까지 학습하고 있었다.

오늘 AWS 세팅을 수월하게 마치고(과금위험 때문에 꼼꼼히 체크)

DB와 node.js 프로젝트를 연동하기 위한 세팅 후 npm start를 해보니

서버가 정상적으로 실행되다말고 에러를 마주하게 되었다.

이때부터 오랜만에 엄청난 삽질이 시작되었다.

에러 내용 :

Error: ER_ACCESS_DENIED_ERROR: Access denied for user ''@'localhost' (using password: NO)

...

code: 'ER_ACCESS_DENIED_ERROR',
errno: 1045,
sqlMessage: "Access denied for user ''@'localhost' (using password: NO)",
sqlState: '28000',
fatal: true

원인은 일단 pw가 없어서 권한이 거절되고 있는 상황이라고 나왔는데

애초에 ''로 username도 인식을 못하는 것 같았다.

뭔가 이상한데? 왜 공백이지?

권한부여도 mysql 8 버전부터 변경되었다고 해서

정상적으로 부여를 다 한 상태였는데..

MySQL 8이상 권한 부여 방식

GRANT ALL PRIVILEGES ON DB이름 TO 'username'@'localhost';
FLUSH PRIVILEGES;

기존 방식

GRANT ALL PRIVILEGES ON DB이름 TO 'username'@'localhost' IDENTIFIED BY 'password';

하지만 검색을 좀 더 해보니 dotenv(.env) 파일의 경로 설정도 중요한 부분이었던 것이다.

경로 설정 없이 app.js와 같은 형제 위치여서

별도로 세팅을 안한 config() 공백상태였는데 사실은 이게 문제였나보다.

해결 :

정말 허무하게도 MySQL, 터미털에서 열심히 삽질했지만

VScode에서 단 한줄 수정을 끝으로 해결했다.

app.js와 동일한 위치에 존재해서

'/'로 경로를 잡고 적는 것이 아닌 파일명 자체로 넣어줬다.

dotenv.config( {path: '.env} );

백, 프론트 모두 할 때 마다 느꼈던 건데

경로가 기본인 것 같지만 실수가 발생할 수 있는 부분인데

다른 경우에 비해 명확하게 에러가 나오지 않는 경우가 꽤 있어서

놓치지 않고 꼼꼼하게 봐야겠다고 또 한번 다짐하게 되었다.

연관 사이트

개발자가 되기 위해 개념들을 학습하고, 다양한 프로젝트를 진행해 보면서

좀 더 정확하게 개념을 짚고 넘어가고 싶다는 생각이 들었다.

그러기 위해서 다양한 IT 용어들에 대해서 기본 개념부터 이해도를 높이고자 기록을 해본다.

이번에는 기본 중의 기본인 API에 대한 내용이다.

API  (Application Programming Interface)

- 직역 : 응용 프로그램 프로그래밍 인터페이스

- 정의 및 프로토콜 집합을 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘입니다.

예를 들어, 기상청의 소프트웨어 시스템에는 일일 기상 데이터가 들어 있습니다.

휴대폰의 날씨 앱은 API를 통해 이 시스템과 ‘대화’하여 휴대폰에 매일 최신 날씨 정보를 표시합니다.

AWS 사이트에서도 예시를 잘 들어서 이해하는데 도움이 되었다.

쉽게 말해서 한 프로그램에서 다른 프로그램으로 데이터를 주고 받기 위한 방법이다.

API 종류

Private API

- 내부 API

- 사내에서 쓰는 API로, 제 3자에게 노출되지 않음

Public API

- 개방형 API

- 제약없이 누구나 사용 가능한 공개 API

 Partner API

- 특정 비즈니스 파트너 간의 데이터 공유

참고 사이트

아래는 유튜버 코딩애플님의 영상이다.

IT현황부터 프론트, 백 구분 없이 정말 유용한 내용들이 많아 즐겨보는 유튜버 중 한 명이다.

 SOLID

객체지향적으로 설계할 때 지켜야 하는 5대 원칙

1. SRP(단일 책임 원칙),
2. OCP(개방-폐쇄 원칙),
3. LSP(리스코프 치환 원칙),
4. ISP(인터페이스 분리 원칙),
5. DIP(의존 역전 원칙)를 말하고 앞글자를 따서 SOLID 원칙이라고 부른다.

SRP (Single Responsiblity Principle)
단일 책임 원칙
- 모든 클래스는 각각 하나의 책임만 가져야 한다.
 
OCP (Open Closed Principle)
개방-폐쇄 원칙
- 확장에는 열려있고, 수정에는 닫혀있는,
  기존 코드를 변경하지 않고서도(Closed) 기능을 추가할 수 있도록(Open) 설계가 되어야 한다.
 
LSP (Liskov Substitution Principle)
리스코프 치환 원칙
- 자식클래스는 부모클래스를 대체할 수 있어야 한다.
  자식클래스는 부모클래스의 확장만 수행하도록 해야 LSP가 만족된다.
 
ISP (Interface Segregation Principle)
인터페이스 분리 원칙
- 하나의 일반적인 인터페이스보다 여러 개의 구체적인 인터페이스를 사용하는 것이 좋다.
 
DIP (Dependency Inversion Principle)
의존 역전 원칙
- 의존관계를 맺을 때 구체적인 클래스보다 좀 더 추상화된 클래스와 관계를 맺는 것이 좋다.
 
 
객체지향프로그래밍은 배워도 배워도 끝이 없는 것 같다.
OOP 그 자체에 머무르지 않고 구체적인 OOP 설계 방법을 알게 되었는데
이 5가지 원칙들은 전부 연결이 된다고 생각했다.

이 원칙들에 대해서 좀 더 확실한 이해를 돕도록
예시 코드도 직접 작성해 보면서 정확하게 숙지하도록 해야겠다.
 
 

참고 영상
- 개발자 장고님의 유튜브