0. 요약

Github Actions로 개발 환경의 CI/CD를 구축하던 중 발생한 요구 사항을 정의하고 해결하고자 한 내용 정리

---

1. workflow 구성

runner는 workflow 파일에 정의된 파이프라인을 수행한다.
먼저 workflow 파일의 구성 요소와 각 요소의 역할과 사용법을 익히는 것이 필요했다.

구성 : workflow > job > step > action

이 플레이리스트가 workflow에 대한 기본 개념을 잡기 좋은 것 같다.

2. 요구사항

1) docker 컨테이너로 배포

• self-hosted runner가 설치된 서버에서 이미지를 빌드 & 배포
  • build job에서 이미지 빌드(docker build ~)
  • deploy job에서 배포 (docker run -d ~)

...

jobs:
  build:
    name: Build
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v2

      - name: Set up JDK 17
        uses: actions/setup-java@v1
        with:
          java-version: 17

      - name: Build Docker image
        run: docker build -t ${{  env.IMAGE_NAME  }}:${{  env.IMAGE_VERSION  }} .

  deploy:
    name: Deploy
    runs-on: self-hosted
    steps:
      - name: Run Container
        run: docker run -d -p 8889:8080 --restart=always --name ~~

...

2) 특정 조건에서만 CI/CD 파이프라인 실행하기

문제점

매번 commit & push 할 때 마다 workflow 파일이 실행

• actions 탭이 지저분해져서 보기 어려워짐
• 배포를 원하지 않는 commit에서도 파이프라인이 실행
• 불필요한 서버 리소스 낭비

해결

• 특정 조건에서만 workflow 파일을 실행시키기

  • on 에 트리거가 작동할 branch를 설정할 수 있음
  • 현재는 개발용 main branch만 사용하므로 따로 설정하지는 않음

• 특정 조건에서만 특정 job을 실행시키기

  • job의 구성요소 중 if를 사용하여 특정 조건에서만 해당 job을 실행하도록 설정할 수 있음
  • commit message에 특정 단어를 포함시켜서 커밋 할 경우 실행하도록 조건을 추가함
  • 이 외에도 여러 조건 설정이 가능함

name: Github Actions Tutorial

on:
  # on에 조건을 추가 할 경우
  push:
    tags:
      - "image/v*"
    paths-ignore:
      - "charts/**"
  pull_request:
    branches: [master]
    paths-ignore:
      - "charts/**"

jobs:
  check:
    name: check
    runs-on: self-hosted
    # commit message에 #test가 포함될 경우에만 check라는 job이 실행
    if: ${{ contains(github.event.head_commit.message, '#test')
    steps:
      - name: temp image
        run: docker image rm --force ${{  env.TEMP_IMAGE_NAME  }}:latest

...

참조

3) docker 이미지 버전 관리

문제점

새로 CI/CD 파이프라인이 실행되어 배포되었다가, 결함이 발견되어 원복시켜야 하는 경우 대응이 어려움

해결

• self-hosted runner가 build & deploy한 도커 이미지를 docker private registry에 등록하여 버전 관리
  • 등록을 위한 remote tag 부착
  • private registry login
  • private registry push
• bash 환경 변수로 이미지 버전 기록
  • ~/.bashrc 파일에 이미지 버전을 기록

push:
  name: Push
  runs-on: self-hosted
  steps:
    - name: Log in to registry
       run: docker login ${{  secrets.REGISTRY_URL  }} -u ${{  secrets.REGISTRY_USERNAME  }} -p ${{  secrets.REGISTRY_PASSWORD  }}

    - name: Set remote Image Tag
       run: docker tag ${{  env.IMAGE_NAME  }}:${{  env.IMAGE_VERSION  }} ${{  secrets.REGISTRY_URL  }}/${{  env.IMAGE_NAME  }}:${{  env.IMAGE_VERSION  }}

    - name: Push image to registry
       run: docker push ${{  secrets.REGISTRY_URL  }}/${{  env.IMAGE_NAME  }}:${{  env.IMAGE_VERSION  }}

...

update:
  name: Update VAR
  runs-on: self-hosted
  steps:
    - name: add VAR
       run: echo export ${{  env.VAR_NAME  }}=${{  env.IMAGE_VERSION  }} >> ~/.bashrc

    - name: update & check VAR
      run: source ~/.bashrc && echo $${{  env.VAR_NAME  }}

bashrc 사용을 위해 runner 실행하는 유저와 경로 확인이 필요했다.
runner를 설치한 admin 유저였고, 경로는 _work의 하위 경로인 것 확인

4) docker cache 사용하여 build 시간 단축하기

문제점

docker build 명령어 수행시 매번 새로 라이브러리를 받아옴 → build 시간이 너무 길다

특히 hapi fhir6는 매번 15분 이상 시간이 소모되는 빌드 괴물이었다.

해결

docker buildx 명령어로 도커 캐시를 사용해 build 시간을 단축 (15분 -> 약 1~2분)

• before
• after

...

jobs:
  build:
    name: Build
    runs-on: self-hosted
    steps:

      ...
      
      - name: Build Docker image
        run: docker buildx build -t ${{  env.IMAGE_NAME  }}:${{  env.IMAGE_VERSION  }} .

참조1
참조2
참조3
참조4

문제점 추가

원인이 정확히 도커 캐시 때문인지는 모르겠으나, self-hosted runner가 설치된 서버의 docker 용량이 빠르게 증가했다.
docker system prune -a 으로 사용하지 않는 오브젝트를 삭제해서 용량을 확보함
일단 용량 모니터링 하면서 지켜보고 buildx 동작방식을 조금 더 살펴보는 것이 좋겠다.