🐈‍⬛ github actions를 통한 cicd 파이프라인 구축

🚂 프로젝트 전체 구조

• 서버 환경 : AWS EC2 (리눅스 인스턴스)
• 배포 방식 : Docker를 활용한 컨테이너 기반 배포
• 애플리케이션 환경 : Spring Boot, Redis, MySQL
• CI/CD 도구 : GitHub Actions

• Github Actions를 통한 cicd 성공 화면

해당 프로젝트에서 CI/CD 파이프라인을 구축하여 자동 배포한 과정을 아래에서 설명하겠습니다 :)

---

0. CI/CD 도구로 GitHub를 사용한 이유

• GitHub는 코드 저장소에 Actions 기능이 통합되어서 버전 관리와 배포 자동화를 한 번에 처리할 수 있음
• 별도의 설치 없이, .github/workflows 폴더에 YAML 파일만 작성하면 바로 파이프라인 구성 가능
• 공개 저장소(Public)을 사용하면 actions의 실행 시간에 제한이 없어서 무료로 무제한 사용 가능
• 무엇보다 가장 접하기 쉽고 익숙한 도구였기 때문에 처음 CI/CD를 구성하는데 GitHub를 선택함

---

1. GitHub Actions 사용을 위한 설정 : Actions Secrets 등록

🐋 `SSH_KEY` 등록

1. AWS EC2 접속용 키를 메모장으로 열어서 복사 (AWS에서 다운받은 .pem 파일)
2. Repository secrets에서 new repository secret 클릭

3. SSH_KEY 라는 이름으로 첫번째 키 등록 (.pem 파일 내용 붙여넣기)

🐋 `SSH_HOST` 등록

1. AWS 인스턴스에서 퍼블릭DNS 복사

2. SSH_HOST 라는 이름으로 두번째 키 등록

🐋 환경 변수 파일 등록

• docker-compose 파일 설정에 따라 .env 파일 전체 내용을 ENV_FILE로 추가
  • Name : ENV_FILE
  • Secret : (.env 파일 전체 내용 붙여넣기)
• Github Actions는 보안상 로컬 파일을 직접 포함하지 못하므로 원격 서버에 .env 파일을 전달하려면 github 저장소 내부에 넣지 않고 Actions secrets의 기능을 활용하여 민감한 정보를 안전하게 전달해야 함

---

2. Github Actions Workflow 구성

🌊 Workflow 흐름

• Github Actions 작업
  • 코드 checkout : 저장소의 소스 코드 가져옴
  • JDK 설정 : 빌드 환경 구성
  • Gradlew 실행 : 애플리케이션 빌드 (jar 생성)
  • scp-action : EC2로 파일 복사 (jar, Dockerfile, .env 등)
  • ssh-action : 원격 명령 실행 (EC2 내부에서 실행)
• EC2는 빌드 작업 없이, 복사된 .jar 또는 Dockerfile을 실행만 함
• Github Actions가 모든 준비/빌드/실행을 자동으로 처리

🗂️ 폴더/파일 구조

• root 최상단에 `.github` 폴더 생성 - `workflows` 폴더 생성 - `cicd.yml` 파일 생성
• ⚠️ .gitignore에 .github 폴더를 추가하면 actions가 실행될 수 없음 (github이 못읽으니까!)
• cicd.yml
  • 빌드된 파일을 EC2로 복사하고 실행하는 자동화 스크립트
  • 해당 파일에 {SSH_HOST}, {SSH_KEY}, {.ENV} 변수가 있음
  • 🤔 CI/CD를 하나의 파일 내에서 구성한 이유?
    프로젝트 규모가 작고 빌드와 배포 구조가 단순했기 때문에
    하나의 흐름으로 관리하는게 더 직관적이고 유지보수에도 편리했음!

---

3. 웹페이지 화면이 안 뜬다면? EC2 보안그룹 설정하기

• 웹페이지 접속이 안된다면, 8080포트를 열어야 함
• 인바운드 규칙 추가
  • EC2 - 인스턴스 - 보안그룹 클릭
  • 현재 열려있는 포트 외에도 8080 포트를 열어줄것. 인바운드 규칙 편집 클릭.
  • 8080 포트 생성. (IP : ’0.0.0.0/0’은 모든 곳을 가리킴)

---

4. EC2 요금 절약하기

• 사용하지 않을 때는 인스턴스 중지
• 완전히 삭제하려면 종료
• 고정 IP를 할당받으면, 인스턴스를 재시작해도 IP가 유지됨

---

5. 내가 느낀, 수동 배포와 CI/CD 파이프라인을 적용한 자동 배포의 차이

• 수동 배포
  • EC2 직접 접속하여 수동 빌드 & 도커 재시작
  • 팀 프로젝트일수록 번거롭고 실수 잦음

• CI/CD 자동 배포
  • dev 브랜치 push만으로 빌드, 테스트, 배포 자동화
  • 반복 작업 제거하여, 빠르고 안정적인 배포 가능함!

---

🌕 회고

수정한 내용을 바로바로 배포에 반영할 수 있다는 점에서 정말 뿌듯했고, 큰 걸 해낸 기분이었다. 배포 도구는 달라도 배포의 핵심 과정은 동일하다고 해서, 이번 기회에 배포 프로세스 자체를 제대로 이해하고 구축하는 데 집중했다. 이번엔 프로젝트 사이즈가 작아서 GitHub Actions를 사용했지만, 다음에는 회사에서 자주 사용하는 Jenkins 같은 다른 배포 도구도 경험해보며 다양한 CICD 환경에 익숙해지고 싶다.