AWS서버 띄우기 | CI/CD | 느낀점

로컬에서 개발할 때는 코드를 변경하고 재실행하며 개발이 가능했다.

그리고 이미지, 동영상 등 정적파일 관리에 대한 큰 고민이 없었다. 그냥 내 컴퓨터에 파일을 저장하면 되니까!

하지만 직접 서비스를 운영하기 위해선 24시간 돌아가는 운영서버에 내 프로젝트를 배포해야한다.

그 기틀을 마련하기 위해선 여러가지 설치 및 설정을 해줘야한다.

 

< AWS 서비스 등록 >

1. AWS EC2 인스턴스 생성( 가상 서버 생성 )

2. AWS RDS 생성( 관계형 데이터베이스 )

3. 역할 및 보안 설정

 

1. 수동 배포

• github에 프로젝트 푸쉬 후 EC2서버에서 - git clone  or  git pull
• 테스트 및 빌드  - gradlew test / gradlew clean build (gradle이 없는 환경에서도 gradlew로 빌드가능하다)

[ 주의 ! github에는 중요한 정보가 담긴 설정파일을 올리면 안 된다. (RDS 아이디 비번, OAUTH 설정정보 등)

각 설정 파일들은 운영서버가 직접 갖고 있고, 실행시 그 파일 위치를 지정해줘야한다. ]

 

2. 자동화 CI/CD

로컬에서 코드작성 -> 깃헙에 push -> (자동)Travis CI 에서 테스트 및 빌드후 -> S3에 저장 

-> codeDeploy가 S3에 저장된 빌드파일 EC2에 배포-> EC2에서 무중단 배포를 위해 NGINX 서버 띄움

 

<기본버전> (무중단 배포X)

<무중단배포>

 

< CI/CD 를 위한 프로그램 및 AWS 서비스 >

• 1. travis CI - 깃허브에서 제공하는 무료 CI 서비스 (젠킨스와 같은 유료 서비스를 많이 쓴다)
• AWS S3 - 이미지,동영상, 배포파일 등 정적파일 저장 서비스
• AWS codedeploy - 배포시스템
• Nginx( 무중단 배포를 위한 서버 )

CD/CD란?

https://artist-developer.tistory.com/24 - 잘 설명되어 있다.

 

 

< CI/CD과정 >

1. travis ci에서 빌드 및 S3로 배포한다.

2. EC2 codedeploy 역할설정.

3. EC2에 codedeploy agent 설치, codedeploy 역할 및 배포그룹 설정

4. codedeploy 설정 - appspec.yml

 

---

< 오류 발생 및 원인 찾기 >

배포 후 접속시도 -> 들어가지지 않았다.

오류 발생 원인을 찾아봐야겠다.

 

1. Travis CI - 테스트 및 빌드 확인

travis ci에서 테스트 및 빌드가 성공됏고.

2. CodeDeploy - 배포 확인

codedeploy의 배포 또한 성공되었다.

그렇다면 문제는

EC2에서 배포 및 실행에 문제가 있다는 것이다.

 

3. EC2 - 배포 로그 및 실행 확인

codedeploy의 로그를 살펴봐야겠다.

/opt/codedeploy-agent/deployment-root

1) 배포 파일 확인

99d76d46~~~  - 사용자마다 고유한 CodeDeploy ID가 생성된다.

이 디렉토리에는 배포 단위별 디렉토리가 있다. -> 배포 파일이 정상적으로 왔는지 확인한다.

정상적으로 들어왔다.

 

2) 배포 로그 확인

다시 상위 디렉토리로 가서

deployment-logs 의 codedeploy-agent-deployments.log파일을 vim으로 살펴보면

로그들을 살펴볼 수 있다. 정상 출력되었다.

 

3) 실행 로그 확인

실행시 로그 출력 파일인 nohup.out을 vim으로 확인해보았다.

정상 출력되었고, 에러는 없었다.

 

그렇다면...왜!?

어이없는 실수가 여기서 나타났다. 

EC2 퍼블릭 DNS를 잘못 복사해서 요청한 것이다..... 다시 URI요청을 하니 정상 작동되었다.

어이없는 실수였지만 좋은 경험이었다.

문제의 원인을 처음부터 하나씩 찾아가다 보니 오류가 난 지점을 찾을 수 있었다.

다시 이같은 오류가 났을때 어느 지점에서 어떻게 확인해야 하는지를 명확히 알게되었다.

어이없는 실수였지만 이렇게 또 하나 배우게 됐다.

---

< AWS 배포환경 구축 후기 >

 

 

여러 과정들을 겪으면서 많은 것을 느꼈다.

 

첫번째로, 전체 흐름을 파악하는것이 가장 중요하다.

처음엔 많이 혼란스러웠다. 나는 로컬 컴퓨터에서 코드를 짜고 인테리J가 알아서 테스트 및 빌드해주는 환경에 익숙했다.

Travis CI, EC2, RDS, CodeDeploy 등 모든 환경이 처음 겪어 보는 것이다.

이런 상황에서 무엇이 어디서 어디로 어떻게 흘러가는것인지 전체 구조를 파악하는 것이 가장 첫번째였다.

흐름을 파악하고나니 각 단계의 필요성과 사용 이유를 알게 되었다.

그렇게 막연한 두려움이 없어졌고, 각 단계별 세부적 사용법을 익히는 것에 집중되었다.

 

두번째로, 문제 해결은 각 단계별.

나는 수많은 에러코드를 만났다... 아주 사소한 부분에서부터 오류가 발생했다.

AWS 가입에서부터 무엇을 선택해야하는지 검색해보고 찾아봐야했다.

너무 생소한 AWS환경설정과, 리눅스환경, 코드들을 만나다보니 당장 에러가 난 부분을 수습하기에 급급했다.

무작정 오류가 나기 전 변경했던 코드를 되돌려 놓고 주먹구구식으로 오류를 해결하려고하니 문제가 더 꼬이기만 했다.

제대로 문제를 해결을 하고 있다는 느낌이 들지 않았다.

다시 오류가 발생했을때는 처음부터 천천히 생각하며 문제를 해결해 나가려고 노력했다.

나는 다음의 과정을 거쳐 문제를 해결해 나갔다.

 

1. 문제 파악

  1) 오류 발생 지점 파악 - 오류가 발생한 지점이 어떤 부분인지 파악이 안 된 상황이라면 그 부분을 찾는것이 먼저다.

앞에서부터 한 단계씩 확인하며 어떤 단계에서 발생하는 오류인지 파악한다.

  2) 어떤 오류인지 파악 - 기본적으로 오류 메세지를 읽고 뜻을 파악한다. 모르는 오류일시 오류 메시지를 검색해서 해결방법을 바로 찾을 수 있다.

하지만 검색해봐도 나오지 않거나, 정확한 답이 안 나온다면 다음단계로 넘어간다.

 

2. 문제 좁히기

 

3. 해결방안 검토

 

---

 

개인 프로젝트시 주의할 것 - 욕심부리지 말기!

개인 프로젝트는 나혼자 의사결정을 한다. 머릿 속에 수많은 고려 사항과 기능들이 떠오르게 된다.

이런저런 사항을 모두 고려하면 머릿속에서 구상만 하다가 결국 완성을 못하게 된다. 너무 기획에 함몰되면 안 된다.

쉬운 주제라도 끝까지 완성해서 호스팅까지 해보는게 많은 도움이 된다.

MVP모델 (최소기능제품 모델)

24시간 무중단 환경, 성능 튜닝, 모니터링, 대규모 트래픽 처리 등 어떻게 다루는지를 습득하기 위해선

실제 서비스를 운영하는 회사에서 몇년간 일을 해보는것이 제일 좋은 방법이라는것을 저자는 말하고 있다.!