[멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_78일차_"Jenkins, Github Actions"

🦁멋쟁이사자처럼 백엔드 부트캠프 13기 🦁
TIL 회고 - [78]일차

🚀78일차에는 빌드 자동화 도구 Jenkins와 Github Actions에 대해 모두 학습해볼 수 있었다.

학습 목표 : Jenkins로 자동 빌드 테스트 및 Github Actions로 프로젝트를 빌드할 수 있는 것

학습 과정 : 회고를 통해 작성

---

❓AWS를 사용하는 이유

➡️개발한 애플리케이션이 본인(로컬)만 보는 것이 아닌 다른 사람에게도 보여지도록 하기위함

➡️관리비용을 지불하여 네트워크에 대신 서버를 구축해서 빌려주는 클라우드 시스템이므로 사용

---

Build Trigger

• 트리거 설정은 "언제 빌드를 시작할 것인가"를 정의
• Build after other projects are built
  ➡️다른 프로젝트(혹은 Job)가 빌드에 성공(혹은 실패)했을 때, 해당 Job을 이어서 빌드하도록 설정
  ex. A 프로젝트 빌드 후 B 프로젝트를 빌드하고 싶다면 B 프로젝트에서 이 옵션을 켜고, A 프로젝트 이름을 지정
  
  
• Build periodically
  일정 주기로 빌드를 실행하고 싶을 때 사용 >> CRON 형식( H/15 * * * * )으로 표현
  ex. 특정 시간 간격(ex. 15분마다) 혹은 매 일 특정 시간 등에 빌드가 자동으로 실행
  
  

• Configuration > Triggers > Poll SCM 설정
• Poll SCM Jenkins가 일정 주기로 Git 저장소를 확인(폴링)하여 변경 사항이 있는지 검사하는 것
  ➡️변경이 발견되면 빌드 실행
• Schedule
  ➡️Jenkins가 특정 시간에 자동으로 빌드를 트리거하도록 설정하는 옵션
  Cron 표현식은 5개의 필드로 구성되며, 각각 (분, 시, 일, 월, 요일)
• H/15 = 15분마다 (15분에 하는 작업이 여러개면 해시코드 값을 이용해 작업들 간 약간의 차이를 두어 수행)
  ➡️약간의 시간차를 두고 실행되어 서버 부하를 분산시키는 효과
  ➡️동시에 많은 빌드가 시작되어 발생할 수 있는 성능 저하를 방지하는 데 유용
  
  
• */15 ➡️15분마다 (15분, 30분, 45분, 정시)
  
  
• 3, 13, 23, 43 * * * * ➡️매 시간 3분, 13분, 23분, 43분에 빌드를 트리거
• 0 3 * * 6 ▶️매주 토요일 새벽 3시 작업 수행

---

Build Steps 설정

• Config에선 Build Steps를 설정 (Execute Shell)
• chmod +x gradlew ➡️gradlew 에 실행권한을 부여
• Use Gradle Wrapper ➡️ 할 업무 (Tasks)로 [clean build -x test] 추가

• pem파일의 정보를 Jenkins 관리 탭에서 System에 넣어줌

---

start.sh

pkill -f 'java -jar' || echo "No app running"

nohup /usr/bin/java -jar /home/ec2-user/todoApp-0.0.1-SNAPSHOT.jar > /home/ec2-user/app.log 2>&1 &

 

• pkill -f 'java -jar' || echo "No app running"
  ➡️현재 서버에서 실행 중인 Java 애플리케이션을 종료
  f 옵션: 찾을 패턴을 프로세스의 전체 명령행과 비교
  
  ✅현재 서버에서 java -jar 명령어로 실행 중인 모든 Java 애플리케이션을 찾아서 종료
  만약 실행 중인 Java 애플리케이션이 없다면 'No app running'이라는 메시지를 출력
  
  
• nohup /usr/bin/java -jar /home/ec2-user/todoApp-0.0.1-SNAPSHOT.jar > /home/ec2-user/app.log 2>&1 &
  ➡️Java 애플리케이션을 백그라운드에서 실행하고, 실행 결과를 로그 파일에 기록
  
  nohup: "no hang up"의 약자로, 이 명령어로 실행된 프로세스는
  사용자가 터미널에서 로그아웃하더라도 계속해서 실행
•  
• 2>&1:
  표준 에러(stderr)를 표준 출력(stdout)으로 리디렉션
  
  2>: 표준 에러를 리디렉션
  &1: 파일 디스크립터 1번(표준 출력)을 가리킴
  
  &: 백그라운드 실행 연산자
  ➡️이 명령어를 끝에 붙이면 해당 프로세스를 백그라운드에서 실행

• [publicIPv4주소]:8080 에 접속해보면 변경했던 내용과 함께 App이 잘 실행되는 것을 확인 가능

---

app.log

• app.log라는 파일이 생성되어있는데 앱의 로그들을 기록하고 있음
• type app.log 명령어보다 tail app.log로 확인하면 가장 최신에 찍힌 로그를 가져옴

---

Github Actions 기반의 CI/CD

• 별도의 CI 서버(Jenkins 등)를 설치할 필요 없이,
  GitHub 저장소 안에 워크플로우 (Workflow) 설정 파일을 작성하면 자동으로 빌드·테스트·배포 과정을 수행가능

❓GitHub Actions를 사용하는 이유

• GitHub Issue나 PR 코멘트 등을 이벤트로 활용해 고도의 자동화 가능
• GitHub가 호스팅하는 러너를 사용하여 CI/CD 파이프라인을 간단하게 구성 가능 

---

Github Actions - pem 정보 추가

• 저장소의 Settings에서 Secrets and Variables/Actions/New Repository secret을 지정
• ${{ secrets.MY_KEY }} 형태로 참조
  ex. ${{secrets.EC2_SSH_KEY}}
  ➡️참조는 ci.yml 설정에서 사용

---

이벤트(trigger) 설정

• push 특정 브랜치에 코드가 푸시(push)될 때 워크플로우 실행
  ex. on: push: branches: [ "main" ]

---

Github Actions  - 인바운드 규칙 수정

 

❓로컬 Jenkins vs. GitHub Actions

➡️Jenkins: 직접 서버(혹은 로컬 PC)에 Jenkins를 설치·운영해야 함 ➡️관리 부담
- 기존 Jenkins 파이프라인/플러그인을 광범위하게 활용 중인 기업
- 조직 내부망에서 CI/CD를 운영해야 하는 경우
- DevOps 팀이 Jenkins 관리 경험이 풍부

➡️GitHub Actions: GitHub에서 제공하는 클라우드 기반 CI/CD 플랫폼을 사용
- 세밀한 커스터마이징이 필요한 경우
- GitHub를 메인 저장소로 사용하고 있고, 빠른 CI/CD 도입이 필요한 경우
- 서버 인프라 운영 부담을 줄이고 싶거나, 오픈소스 프로젝트를 운영하는 경우

---

🚀회고 결과 :

Jenkins와 GitHub Actions으로 프로젝트를 관리할수 있음을 회고로 연습할수 있었다.

수동말고도 자동화를 하는 기술을 쓸 수 있게 되어 뜻깊었다.

향후 계획 : 

- EC2 인스턴스 사용종료 : 반환