🛳️ 배포 및 인프라

지금까지의 설정으로는 메인 브랜치에 코드가 merge될 때마다 EC2에 접속해서 배포를 위한 쉘 스크립트 파일을 직접 실행해주는 과정을 거쳐야 합니다. 이러한 주기가 빈번할수록 매번 EC2에 접근하여 쉘 스크립트를 실행하는 과정은 더욱 번거로워집니다. 이번 글에서는 CD 기술인 Jenkins를 적용하여 위의 문제들을 해결해 보도록 하겠습니다. 🧐 CI/CD 플로우 다음과 같은 과정으로 CI/CD가 이루어집니다. PR이 생성되면 Github Actions으로 테스트를 진행합니다. 위 과정이 성공해야만 main 브랜치에 merge할 수 있습니다. github의 메인 브랜치에 merge합니다. 아래의 과정을 젠킨스에서 진행합니다. 테스트를 진행 (CI) JAR파일 빌드 JAR파일을 EC2에 전송 EC2 접속 ..

이번 글에서는 PR을 날렸을 때 해당 PR이 문제가 없는지 자동으로 테스트를 수행하고, 만약 테스트에 실패한다면 merge할 수 없도록 메인 브랜치를 보호하는 방법에 대해 살펴보겠습니다. 🧐 Github Actions 설정 Repository에 들어가서 Actions - Java with Gradle을 클릭합니다. 위 yml 파일을 아래와 같이 수정합니다. name: Java CI with Gradle on: pull_request: branches: [ "main" ] permissions: contents: read jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: 🐳 JDK 11 세팅 uses: actions/..

이전 글에서 애플리케이션을 데이터베이스와 연동할 때 환경변수를 통해서 민감한 정보를 관리했습니다. 이번에는 환경변수 대신 Git Submodule이라는 기능을 통해서 이러한 정보를 관리해 보도록 하겠습니다. 🧐 Git Submodule 깃 공식 문서에는 다음과 같이 설명되어 있습니다. 프로젝트를 수행하다 보면 다른 프로젝트를 함께 사용해야 하는 경우가 종종 있다. 함께 사용할 다른 프로젝트는 외부에서 개발한 라이브러리라던가 내부 여러 프로젝트에서 공통으로 사용할 라이브러리일 수 있다. 이런 상황에서 자주 생기는 이슈는 두 프로젝트를 서로 별개로 다루면서도 그 중 하나를 다른 하나 안에서 사용할 수 있어야 한다는 것이다. Atom 피드를 제공하는 웹사이트를 만드는 것을 예로 들어보자. Atom 피드를 생성..

이전 글에서는 애플리케이션용 EC2 서버에서만 접근할 수 있는 데이터베이스용 EC2 인스턴스를 생성하고 해당 인스턴스에 MYSQL을 설치하는 과정을 진행했습니다. 이번에는 스프링 애플리케이션과 DB를 직접 연동해보도록 하겠습니다. 🧐 데이터베이스를 사용하는 스프링 코드 작성하기 우선 테스트를 위해서 간단한 코드를 하나 작성할 예정입니다. public class Member { private Long id; private String email; private String password; public Member(Long id, String email, String password) { this.id = id; this.email = email; this.password = password; } publ..

이전 글에서는 EC2 서버에 애플리케이션을 배포하는 과정을 쉘 스크립트를 통해서 자동화를 했었는데요, 사실 이때 배포한 애플리케이션은 내장 H2 DB를 사용하는 간단한 프로젝트였습니다. 그러나 실제로 프로젝트를 배포할 때에는 Mysql 등의 데이터베이스를 서버에 띄워서 사용하게 되는데요, 이번 글에서는 새로운 EC2 인스턴스를 생성한 뒤, 그곳에서 Mysql을 실행시켜보도록 하겠습니다. 🧐 새로운 EC2 생성하기 해당 글의 과정에서 진행했던 것 처럼 EC2 인스턴스를 생성해 주면 되는데요, 중복된 과정이지만 아주 살짝 차이점이 있기 때문에 차례차례 진행해보려 합니다. 먼저 EC2 대시보드에 접속합니다. 이후 인스턴스 시작을 클릭해주세요. 이름은 마음대로 지어주세요. 애플리케이션 및 OS 이미지는 Ubun..

이전 글에서는 EC2 서버에서 직접 깃허브 프로젝트를 clone받고 직접 실행해 보았는데요, 사실 이러한 방법을 통해서 배포를 진행한다면 여러 귀찮은 상황이 발생할 것입니다. 새로운 기능을 개발해서 레포지토리에 커밋을 했다고 생각해 보겠습니다. 우선 EC2 인스턴스에 접근하여 변경된 사항을 PULL 받아야 합니다. PULL 을 받은 이후에는 이를 빌드하고, 기존에 실행중인 애플리케이션을 종료시키고, 새롭게 애플리케이션을 다시 띄워야 합니다. 즉 기능의 개발이 이루어질 때 마다 해야 하는 귀찮은 반복 작업들이 너무 많습니다. 그래서 이러한 반복 작업을 쉘 스크립트를 통해서 자동화 해보도록 하겠습니다. 🧐 어떠한 순서로 배포가 이루어질까? 쉘 스크립트를 작성하기 전에, 우선 배포가 어떠한 순서로 이루어질지 ..

이번 글에서는 이전 글에서 생성한 EC2에 스프링 애플리케이션을 띄워보도록 하겠습니다. 이때 스프링 애플리케이션은 자신의 아무런 스프링 애플리케이션이나 상관없습니다. (단 maven이 아닌 gradle을 대상으로 진행합니다) 🧐 깃허브 레포지토리에 프로젝트 올리기 이미 깃허브에 프로젝트를 올려두셨다면 해당 과정은 건너뛰어도 상관없습니다. 저는 레포지토리를 하나 생성해서 다음과 같이 예제 애플리케이션을 올려두었습니다. 이제 해당 프로젝트를 clone받을 수 있도록, code 버튼을 누른 뒤 주소를 복사합니다. 🧐 EC2 에서 프로젝트 clone받기 이전 글에서도 다루었지만 다음과 같이 입력하여 접속할 수 있습니다. ssh -i [키페어] ubuntu@[퍼블릭 IPv4 주소] ssh -i mallang-ke..

🧐 어려운 배포 배포는 참 어렵습니다. 저는 지금 정말 너무 어려워서 울 것 같아요. 하지만, 배포를 처음 해보는 모두가 다 저와 같은 감정일 것이라 생각합니다. 그래서 배포를 처음하는 제가, 이 글을 써가면서 자동 배포까지 진행하는 과정을 세세히 정리함으로써, 누군가에게 도움을 줄 수 있지 않을까 하는 생각으로 이렇게 정리를 하게 되었습니다. (무엇보다, 다른 블로그들이 너무 불친절하달까... 정말 아무것도 모르는 사람이 이걸 따라할 수 있다고..? 하는 생각이 들어서 제가 그냥 저를 위해서 정리를 하고 있네요..😭) 예상하는 목차는 다음과 같습니다. AWS 계정 만들기 ~ EC2 인스턴스 만들고 접속하기 (이번 글) 간단한 스프링 프로젝트 생성하고 깃허브에 올리기 -> EC2에서 손수 clone받아 ..