해당 내용은 Class101의 현직 대기업 개발자 푸와 함께하는 진짜 백엔드 시스템 실무! 강의를 기반으로 작성했습니다.

1. 목표

• DB를 이용한 한줄 게시판 애플리케이션 포크 후 코드 이해

• Postman을 이용해 API 테스트

• GCP 인스턴스에 애플리케이션 배포

2. 애플리케이션 포크 후 실행(Local)

• 저장소를 포크하고 프로젝트를 열어 확인한다.

2-1. 애플리케이션 실행

• 애플리케이션을 실행시키면 5432 포트가 refused 뜰 것이다.
  PostgreSql이 실행이 안됬기 때문이다.

2-2. PostgreSql 실행

docker run --name pgsql -d -p 5432:5432 -e POSTGRES_USER=postgresql -e POSTGRES_PASSWORD=postgrespassword postgres

• run 명령어로 docker 컨테이너를 띄울것이다.

• 간단히 설명하면 5432 포트로 백그라운드에서 도커 컨테이너를 실행시키는 것이다.

• 로컬에 postgres 도커 이미지가 없기 때문에 자동으로 dockerhub에 접근해서 이미지를 가져와서 실행시킨다.

2-.3 PostgreSql 실행 에러 해결

• 도커가 실행되지 않는다. 해결방법은 매우 간단하다. Docker Desktop 재실행 하면된다.

• postgreSql 컨테이너가 올라간걸 볼 수 있다.

• 이후 애플리케이션을 실행해보면 정상적으로 실행된다.

3. Postman으로 api 동작 테스트

• 설치방법이나 사용법들은 생략한다.

3-1. 글 생성 테스트

• Post 엔티티에는 id 필드와, content 필드밖에 없다. 따라서 json으로 content 내용만 body에 담아 보내주면 된다.

• 정상적으로 응답이 오는 걸 볼 수 있다.

3-2. 글 조회 테스트

• 설명할게 없다. 정상적으로 조회된다.

4. GCP 인스턴스에 PostgreSql DB 설치

• 이제 애플리케이션을 인스턴스에 배포할 건데 그 전에 DB를 애플리케이션 인스턴스에 같이설치하는게 아니라 별도의 인스턴스에 DB를 설치 후 애플리케이션 인스턴스가 DB 인스턴스에 접근하도록 할 것이다.

4-1. 인스턴스 생성 후 datasource 설정

• 인스턴스 생성하는 과정은 많이 했기 때문에 생략하고
  생성된 PostgreSql 인스턴스의 내부 ip를 datasource에 추가해준다.

4-2. 인스턴스에 PostgreSql 도커 컨테이너 띄우기

• 생성된 인스턴스에 접근해서 도커 설치 후 PostgreSql 컨테이너를 띄운다.

sudo yum install -y docker // 도커 설치
sudo systemctl start docker // 도커 실행
sudo chmod 666 /var/run/docker.sock // 도커 실행 권한 주기
docker run --name pgsql -d -p 5432:5432 -e POSTGRES_USER=postgresql -e POSTGRES_PASSWORD=postgrespassword postgres // 도커 컨테이너 생성 및 실행

5. 배포

이전에 cpu-worker인스턴스들을 생성할 때 처럼 io-worker 인스턴스들을 새로 생성하고
젠킨스로 배포해도 되지만, 편의를 의해 cpu-worker 인스턴스를 재활용한다.

젠킨스에 접속하려는데 역시나 접속되지 않는다. 젠킨스 인스턴스를 다시 실행시켜주고, 다시 실행되면 외부ip주소가 변경되기 때문에 GitHub Webhook 설정에서 ip를 변경해줘야한다. (이전에 사용한 cpu 레포지토리)

5-1. 젠킨스 설정

• 이전에 만들어둔 cpu-bound-application 설정을 그대로 가져와서 새로운 아이템을 만든다.

• GitHub 주소를 변경해줘야 한다.

• 인텔리제이로 돌아가 패키징하여 jar파일을 만들어주자. 위 jar:jar를 실행시키면된다.

• 생성된 jar파일이름으로 변경해주면 된다. 총 세 개의 인스턴스 모두 변경해주자.
• cpu → io

5-2. datasource 수정사항 커밋

• 아까 4-1에서 datasource의 url을 localhost에서 인스턴스의 ip로 변경했기 때문에
  변경사항을 푸시해줘야 한다.

• cpu 레포지토리에는 Webhook 이벤트를 걸어놨기 때문에 푸시하면 젠킨스가 자동으로 배포해주지만 io 레포지토리에는 이벤트를 걸어놓지 않았기 때문에 수동으로 배포해야 한다.

5-3. 배포

• 그전에 io 레포지토리의 브랜치는 main이므로 젠킨스 설정에서 변경해줘야한다.

• 이후 Build Now를 클릭해 수동으로 배포하자.

5-4. 빌드실패 후 젠킨스 인스턴스 스케일 업

• 시간이 지나도 안되더니 결국 인스턴스가 죽어버렸다

• 로그를 확인해보면 저 상태에서 더 이상 진행되지 않는다.

• 젠킨스 인스턴스의 메모리가 부족해서 발생하는 현상일 수도 있다고 한다.
  젠킨스 인스턴스를 스케일 업 해보자

• 젠킨스 인스턴스 세부정보에서 수정으로 들어가 머신 유형을 변경해주자.

• 정상적으로 배포 되었다..

6. 배포 확인

• Nginx의 외부ip의 /post 경로로 요청을 보내면 정상적으로 응답이 오는 걸 볼 수 있다.

• 이후 크롬에서 /posts 경로로 요청을 보내면 정상적으로 응답이 오는 걸 볼 수 있다.

7. 마무리

• 이번에 진행한 내용들은 아래와 같다.

  1. 이미 만들어진 애플리케이션을 가져와서 Local 환경에서 테스트
  2. 이전에 만들어둔 젠킨스와 워커인스턴스들을 재활용해 io bound 애플리케이션 배포

• 다음에는 io bound 애플리케이션에 기능들을 추가해 볼 것이다.