github action으로 CI/CD 구축하기 - 1. CI

어쩌다보니 ci/cd를 인수인계받게 됐다.(devops를 담당하던 팀장이 이직했다)

 

때문에 내가 알아야할 것들이 많이 늘어났다.

(ci/cd 배포 스크립트, aws 권한 관리, aws 인프라 관리, 모니터링 ㅠ)

 

일단 ci/cd부터 인수인계 받게됐고, 들었던 내용들을 리뷰해보려고한다.

 

이번 포스팅에서는 CI만 다룬다.

 

전반적인 github action을 이용한 CI는 아래와 같이 진행된다.

1. github action vm에 linux를 설치
2. java를 설치 
3. 소스 코드 불러오기
4. (java와 gradle을 캐시)
5. 빌드(jar 파일 생성)
6. 빌드한 파일로 container image 생성
7. (AWS 인증 or dockerhub 로그인)
8. 원격 container repository로 전송(ECR or docker hub)

 

나는 일단 컨테이너 저장소로 ECR(Amazon Elastic Container Registry)을 사용했다.

 

docker hub를 사용해도 되고, 인증과정만 잘 넘긴다면 다른 서드파티 저장소를 사용해도 상관 없다.

 

레지스트리는 각자 준비하도록 하고 차근차근 진행해보자.

 

1. 간단한 웹 서비스 프로젝트 만들기

이 정도는 알아서 준비해야하지만 그냥 짚고 넘어감

 

1. springboot init 프로젝트 만들기

 

별다른 설정은 건드리지 않았다.

2. github repository 생성

 

일단은 push를 한 상태

3. 간단한 컨트롤러 생성

@RestController
public class HelloController {

    @GetMapping("/")
    public String hello() {
        return "hello world!!";
    }
}

 

잘 출력된 걸 확인

 

 

4. first push

 

이러면 준비 소스 코드는 끝

 

여기서부터 action에서 사용할 스크립트를 작성한다.

 

2. github action 스크립트 작성

2.1 기본 스크립트

action 탭에 가서 java with gradle 찾기

 

그러면 스크립트가 나오는데 그대로 복사한다. (설정이 맞으면 위에 commit changes를 누르면 된다)

 

 

페이지 우측 Marketplace에서 몇 가지 스크립트를 검색해서 가져올 수 있다.

 

예시에 있는 checkout을 찾아봤다.

 

스크립트엔 v3인데 최신이 v4.1.1이다. 당장 바꿔주도록 하자.

 

github action 스크립트의 기본 경로 /.github/workflows/[이름].yml 이다.

 

 

# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.
# This workflow will build a Java project with Gradle and cache/restore any dependencies to improve the workflow execution time
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-java-with-gradle

name: Java CI with Gradle

on:
  push:
    branches: [ "master" ]
  pull_request:
    branches: [ "master" ]

permissions:
  contents: read

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up JDK 11
      uses: actions/setup-java@v3
      with:
        java-version: '11'
        distribution: 'temurin'
    - name: Build with Gradle
      uses: gradle/gradle-build-action@bd5760595778326ba7f1441bcf7e88b49de61a25 # v2.6.0
      with:
        arguments: build

복붙한 스크립트를 뜯어보면

 

on은 어떤 브랜치가 어떤 동작을 할 때 action 스크립트가 동작할 것인지를 지정해주는 것이다.

 

actions/checkout은 소스코드를 받아온 후 자바 버전을 설치하고 gradle 빌드를 하는 것 같다.

 

내가 아는 방식과 조금 다르지만 빌드까지 해준다니 이대로 push를 해보자.

 

그럼 push에 액션이 돌도록 지정했기 때문에 돈다.

실패

 

에러 코드를 뜯어보면 빌드를 위한 gardlew의 경로를 못 찾는 것 같다.

 

2.2 디폴트가 잘안되는 것 같으니 하나씩 진행

그냥 아는 방식대로 한단계씩 진행

2.2.1 자바 설치,  소스코드 가져오기, 빌드

name: 자바 배포 테스트

on:
  push:
    branches: [ "master" ]
  pull_request:
    branches: [ "master" ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: java 17 설치
        uses: actions/setup-java@v3
        with:
          distribution: 'corretto'
          java-version: '17'

      - name: 소스코드 체크 아웃
        uses: actions/checkout@v4

      - name: 소스코드 빌드
        run: |
          chmod +x gradlew

 

일단 빌드까지는 정상 동작하는 걸 확인

 

 

그런데, 매번 액션 동작마다 자바를 설치하고 gradle을 설정하면 시간이 걸린다.

 

다행히 github에서 캐시 스크립트를 만들어 놨다.

 

2.2.2 캐시 적용

GitHub Action Java Gradle Cache 를 구글링하면 Gradle 캐시를 할 수 있는 워크플로가 나온다.

이 워크플로를 적용하고 Github Action을 재시작하면, 좌측 메뉴에 캐시가 생성된 것을 확인 할 수 있다.

 

 

체크아웃과 빌드 사이에 캐시 추가

  - name: 소스코드 체크 아웃
    uses: actions/checkout@v4

  - name: 캐시
    uses: actions/cache@v3
    with:
      path: |
        ~/.gradle/caches
        ~/.gradle/wrapper
      key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
      restore-keys: |
        ${{ runner.os }}-gradle-

  - name: 소스코드 빌드
    run: |
      chmod +x gradlew
      ./gradlew build

2.2.3 컨테이너 생성

일단은 docker를 이용한 컨테이너를 생성해보자.

 

jar파일을 도커로 밀어넣고 docker image를 만드는 간단한 Dockerfile을 만들어준다.

jdk: amazon 구글에 검색
FROM amazoncorretto:17.0.9

WORKDIR /app

# 내 PC -> 도커 이미지 안으로 옮기는 작업
COPY build/libs/*-SNAPSHOT.jar app.jar

# 누군가 이 이미지를 실행시켰을 떄, 자동시작되는 명령어
ENTRYPOINT ["java","-jar","app.jar"]

 

그 다음에는 이제 본인이 사용할 docker 저장소에 인증을 하고, build and push를 하면 된다.

 

dockerhub를 이용하려면 아래의 링크를 참고하자.

https://docs.github.com/en/actions/publishing-packages/publishing-docker-images

 

위에서도 언급했지만 본 포스팅에서는 ECR(Amazon Elastic Container Registry)을 이용했다.

 

2.2.4 컨테이너 레지스트리에 업로드

ECR을 사용하려면, aws credential과 ecr login을 해야한다.

  - name: AWS Credentials 설정
    uses: aws-actions/configure-aws-credentials@v4
    with:
      aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
      aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      aws-region: ${{ secrets.AWS_REGION }}

  - name: AWS ECR 인증
    id: login-ecr
    uses: aws-actions/amazon-ecr-login@v1
    with:
      registries: [계정ID]

  - name: 이미지 업로드
    uses: docker/build-push-action@v5
    with:
      context: .
      push: true
      tags: ${{ steps.login-ecr.outputs.registry }}/cicd-demo:testbed-${{ github.sha }}

 

AWS credential은 iam에서 발급받은 정보들이다.

 

AWS ECR 인증에서 registries는 아래의 계정 ID를 의미한다.

 

 

이미지 업로드에서 주의할 점이 있는데

 

사실상 하드코딩처럼 보이지만 네이밍 룰이 있다. 이걸 지키지 않으면 레지스트리로 업로드 되지 않는다.

[사용하는 레지스트리의 URL]/[레지스트리 이름]:[태그]

 

위와 같이 구성되니 반드시 네이밍 규칙을 지켜야한다.

 

다해놓고 왜안되지 하지말자(나처럼)

 

위처럼 작성해놓고 push 하고, 결과를 확인해보자.

 

 

action 스크립트는 정상적으로 끝났다.

 

이미지가 ECR에 정상적으로 들어있는지 확인해보면, 아래가 생성된 이미지이다. 

 

뭘 가려야할지 몰라서 다가림

이러면 일단 ci는 끝이다.

 

대충 아래의 github 레포지토리에 정리해놨다. 한동안은 계속 업데이트하지 싶다.

https://github.com/imsosleepy/ci-test

 

마치며

사실 BE는 우리 서비스 ci는 위와 같이 동작하지 않는다.

 

JIB을 사용하고 있는데, 이건 다음 포스팅에서 소개해 보도록 하겠다.

 

어쩌다보니 github action부터 작성하게 됐는데, 

 

jenkins 구성에서 뭐가 잘못됐는지도 알게됐고 하니

 

1년전부터 작성하던 jenkins를 이용한 배포 시스템 구축도 마무리 지어야 할 것 같다.

 

한걸음 뗐는데 알아야하게 너무 많다.