'스프링 부트3 백엔드 개발자 되기' 책을 참고하며 작성 중 입니다.
사전 지식
CI/CD 란?
빌드부터 배포까지의 과정을 자동화할 수 있고, 또 잘되는지 모니터링할 수 있음!
CI : 지속적 통합
CD : 지속적 제공
지속적 통합, CI
Continuous Integration = CI
개발자를 위해 빌드와 테스트를 자동화하는 과정
CI는 변경 사항을 자동으로 테스트해 애플리케이션에 문제가 없다는 것을 보장
코드를 정기적으로 빌드하고, 테스트할므로 여러 명이 동시에 작업을 한느 경우 충돌을 방지하고 모니터링이 가능!
보통 코드 변경 사항이 코드 저장소(github)에 업로드되면 CI를 시작하고, CI 도중 문제가 생기면 실패하므로 코드의 오류도 쉽게 파악 가능
지속적 제공과 지속적 배포, CD
CD는 CI 작업을 끝낸 다음 실행하는 작업
배포 준비가 된 코드를 자동으로 서버에 배포하는 작업을 자동화하는 것
지속적 제공
코드의 빌드와 테스트를 성공적으로 진행했을 때 깃허브와 같은 코드 저장소에 자동으로 업로드하는 과정
지속적 배포
지속적 제공을 통해 성공적으로 병합한 코드 내역을 AWS와 같은 배포 환경으로 보내는 것
릴리즈라고도 한다.
지속적인 배포는 지속적 제공의 다음 단계까지 자동화하여, 개발자가 애플리케이션에 변경 사항을 커밋한 후 몇 분 이내에 애플리케이션을 자동으로 배포되어 적용된다.
깃과 깃허브
Git 은 코드를 저장하고 관리할 수 있는 시스템으로 병렬 작업을 할 수 있음
Github는 깃(Git)과 연동해 작업한 코드를 저장할 수 있는 서비스
깃 설치하기
http://git-scm.com/download/win
git --version
깃 연동하기
git config --global user.name "[깃허브 아이디]"
git config --global user.email "[깃허브 이메일 주소]"설정한 정보로 커밋할 때마다 이 정보를 사용
깃은 SSH로 접속하기 위해 인증 정보를 등록해야 하는데, PC마다 별도의 SSH 키를 등록해야 한다.
터미널 창을 열고 SSH 키를 생성하는 명령어 입력
ssh-keygen -t rsa -C "[깃허브 이메일 주소]"/.ssh/id_rsa에 pub 파일 -> 값 복사 후 깃허브에 등록
[깃허브 홈페이지] -> [프로필] -> [Settings] -> [SSH and GPG keys] -> [New SSH key]
깃허브 액션 사용하기
Github Action (깃허브 액션)은 깃허브에서 제공하는 서비스로 리포지터리 즉, 코드 원격 저장소에 특정 이벤트가 발생하면 특정 작업을 하거나, 주기적으로 특정 작업을 반복할 수 있게 한다.
깃허브 리포지터리 생성하고 코드 푸시
깃허브에 코드를 업로드하는 행위 : 푸시 (push)
깃허브 주소 저장 : https://github.com/{OWNER}/{Repository_이름}.git
git init
git remote add origin (깃허브 주소)git init
특정 폴더를 깃 저장소로 만들 때 사용하는 명령어
숨김 폴더로 .git 폴더가 생기며, 코드의 변경 내역(버전) 관리를 위한 정보를 저장
깃허브에서는 리포지터리를, 로컬에서는 스프링 프로젝트를 깃 저장소로 생성
git remote
깃허브의 리포지터리와 로컬의 깃 저장소를 연결하기 위해 remote 명령어 사용
쉽게 말해, 로컬의 깃 저장소 이력과 파일을 모두 깃허브에 업로드하기 위해 연결하는 것!
origin이라는 단축 이름에 git@github.com:${OWNER}/{Repository_이름}.git 이라는 리포지터리 추가가 되었음
git add .
git commit -m "project init"
git brnach -M main
git push origin maingit add .
현재 프로젝트 폴더의 모든 파일을 대상으로 변경 사항 등을 추적하고 스테이지에 올림
스테이지란 ? 리포지터리에 올리기 전에 파일들의 변경 사항을 미리 모아놓는 곳
git commit -m
커밋은 로컬 저장소에 올리기 위한 것
즉, 커밋을 해야만 로컬 저장소에 변경 이력, 변경할 파일들이 업데이트
git branch -M
브랜치명 main으로 변경
git push origin main
원격 저장소에 저장하기 위해 push 명령어 입력
깃허브 액션 스크립트 작성, CI
프로젝트 최상단에 .github 디렉터리를 만들어, 그 안에 workflows 디렉터리를 다시 만들고,
ci.yml 파일 생성
CI.yml
#워크플로의 이름 지정
name : CI
#워크플로가 시작될 조건 지정
on:
push:
branches:
- main
jobs:
build:
runs-on: ubuntu-latest #실행 환경 지정
#실행 스텝 지정
steps:
- uses: actions/checkout@v3
- uses: actions/setup-java@v3
with:
distribution: 'zulu'
java-version: '17'
- name: Grant execute permission for gradlew
run : chmod +x gradlew
- name: Build with Gradle
run: ./gradlew clean build
- 워크플로의 이름 지정하기
워크플로는 CI를 실행하기 위한 스크립트의 모음- 워크플로를 시작할 트리거 조건 지정
main 브랜치에 푸시를 할 때마다 워크플로 시작- 리눅스나 위도우와 같은 실행 환경을 지정
- 실행 스텝을 그룹화
각 항목은 별도의 작업(uses) 또는 명령어(run)으로 이루어짐
실행 스텝 그룹화 정리
- uses
지정한 리포지터리를 확인하고 코드에 대한 작업을 실행할 수 있다.
action/checkout에는 checkout이라는 작업의 v3 버전 실행 - name
스텝의 이름 지정 - run
실행할 명령어 입력
./gradlew clean build는 gradle을 사용해 프로젝트를 빌드 이전 상태로 돌리고 다시 빌드하는 명령어 실행
CI.yml 파일 올리기
git add .
git commit -m "CI 추가"
git push origin main깃허브 액션 스크립트 작성하기, CD
빌드를 진행하면 총 2 개의 jar 파일이 생성되는데,
하나는 일반 jar 파일이고, 다른 하나는 plain이라는 접미사가 붙은 jar 파일
plain.jar
플레인 아카이브(plain archive)라고 하며 애플리케이션 실행에 필요한 의존성을 포함하지 않고,
소스 코드의 클래스 파일과 리소스 파일만 포함
따라서, 일반 .jar 파일만 생성하도록 gradle 파일 변경
build.gradle
jar { enable = false }
CICD.yml 작성
#워크플로의 이름 지정
name : CICD
#워크플로가 시작될 조건 지정
on:
push:
branches:
- main
jobs:
build:
runs-on: ubuntu-latest #실행 환경 지정
#실행 스텝 지정
steps:
- uses: actions/checkout@v3
- uses: actions/setup-java@v3
with:
distribution: 'zulu'
java-version: '17'
- name: Grant execute permission for gradlew
run : chmod +x gradlew
- name: Build with Gradle
run: ./gradlew clean build
#현재 시간 가져오기
- name: Get current time
uses: josStorer/get-current-time@v2.0.2
id: current-time
with:
format: YYYY-MM-DDTHH-mm-SS
utcOffset: "+09:00"
#배포용 패키지 경로 설정
- name: Set artifact
run: echo "artifact=$(ls ./build/libs)" >> $GITHUB_ENV
#빈스토크 배포
- name: Beanstalk Deploy
uses: einaregilsson/beanstalk-deploy@v20
with:
aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws_secret_key: ${{ secrets.AWS_ACCESS_SECRET_KEY }}
application_name: springboot-developer
environment_name: Springboot-developer-env
version_label: github-action-${{steps.current-time.outputs.formattedTime}}
region: ap-northeast-2
deployment_package: ./build/libs/${{env.artifact}}
- josStorer/get-current-time 플러그인을 사용해 현재 시간을 가져오기
배포 버전을 저장할 때 사용- 빌드 이후에 생성된 jar 파일을 찾아 "artifact" 라는 환경 변수에 값 넣기
$GITHUB_ENV를 사용해 깃허브 워크플로 전체적으로 사용할 수 있는 환경 변수 설정 가능- einaregilsson/beanstalk-deploy 플러그인을 사용해 빈스토크 배포 진행
secrets.AWS_ACCESS_KEY_ID 와 AWS_SECRET_ACCESS_KEY는 깃허브 액션에서 가져오는 비밀값
IAM은 AWS 리소스를 사용하도록 권한을 부여하는 서비스
[AWS] -> [IAM] -> [사용자] -> [사용자 생성] -> 이름 : github-action
[직접 정책 연결] 선택 ->
AdministratorAccess-AWSElasticBeanstalk 선택 (빈스토크를 사용하기 위해 필요한 모든 관리 권한 제공)
사용자 생성 후 [액세스 키 만들기] -> [서드 파티 서비스] -> [설명 태그 값] : github-action
액세스 키 .csv 파일 다운로드 하여 값을 가지고 있기
깃허브 리포지터리 -> [Settings] -> [Secrets and variables] -> [Actions]
[New repository secrets]
.csv 파일로 다운로드 받은 키와 비밀키를 등록
yml 파일 값 수정
깃허브에 커밋, 푸시를 하기 전에 민감한 값을 변경
spring:
# sql:
# init:
# mode: never
#data.sql 실행 X
jpa:
show-sql: true
properties:
hibernate:
format_sql: true
defer-datasource-initialization: true
#애플리케이션 실행 시 일래스틱 빈스토크에서 값을 덮어쓰므로 삭제
# datasource: #데이터베이스 정보 추가
# url : jdbc:h2:mem:testdb
# username : sa
h2: #H2 콘솔 활성화
console:
enabled: true
security:
oauth2:
client:
registration:
google:
client-id: ${client_id} -> id
client-secret: ${client_secret} -> secret
scope:
- email
- profile
jwt:
issuer: minkyeong0244@gmail.com
secretKey: ${jwt_secretKey} -> secretKey
#HMAC-SHA 알고리즘의 보안 요구 사항 준수
11장에서 Beanstalk에 저장했던 환경 변수로 덮어질 예정이므로 어떤 값을 넣던 상관없다!
다시 또 깃허브에 커밋 푸시
git add .
git commit -m "ci.yml > cicd.yml"
git push origin main앞으로 작업을 한 뒤 리포지터리에 업로드하면 깃허브 액션이 빌드를 자동으로 실행하고, 빌드에 성공하면 새 버전을 Beanstalk에 배포!
깃허브 액션을 사용해 코드가 변경될 때마다 자동으로 빌드되고 배포하는 방법을 실습했습니다!
CI, CD, 깃허브