Github Action을 이용한 CI/CD Workflow

 

이전 글에서 Docker를 통한 자동화 과정 때 사용하는 CI/CD 툴 중 하나가 Github Action이라고 설명한 바 있다.

 

여기에서 워크플로우가 어떻게 진행되는지를 상세히 서술해보려고 한다.

 

0.    ".github / workflows / action.yml"

먼저, docker와 마찬가지로 github Action 또한 yml파일을 통해서 workflow를 구성한다.

빌드 한 후 이를 배포에 사용하고자 하는 Repository의 .github/workflows 디렉토리를 만들고, 

거기에 {action-file-name}.yml 파일에 상세한 워크플로우를 기술하면 된다.

여기서 사용되는 yml은 이하 action.yml이라 부르겠다.

 

이 과정에서 사용되는 용어에 대해 먼저 얘기해보겠다.

 

1. 용어 정리

 

위는 공식 github actions에서 제공하는 그림인데, 위 그림처럼 action.yml은 크게 다음과 같은 flow를 갖는다.

workflow상에서 이루어지는 행위들이 이렇게 진행되는구나 라고 이해하면 좋다.

1. Event가 발생했을 시,
2. 이를 실행할 Runner라는 가상 머신, 혹은 호스트를 정하고
3. 이 Runner에서 수행할 Job을 "정의"하고
4. 여러번의 Step을 통해서 하나의 Job을 완수한다.

실제로 yml파일에서 다루는 위의 행위들을 정의하는 속성들은 아래와 같다.

(즉, yml파일에 적혀있는 실제로 사용되는 문법들이라 보면 된다.)

• ON 속성 : 하나의 workflow가 trigger되는 시점, Event를 정의한다.
  • 앞서 말했듯, Repository를 기반으로 이뤄지는 행위들이기에 특정 브랜치에 push하거나,
    PR을 하는 경우에도 트리거 되도록 하는게 가능하다. (또는 시간, 이슈 등이 발생했을 때도 가능)
• JOB 속성 : 하나의 큰 작업의 단위라고 보면 된다.
  • 하나의 workflow, 즉 action.yml에는 최소 하나, 여러개의 job으로 구성되어 있다.
    (또는 여러개의 job을 묶어서 jobs로 정의하기도 함)
  • 기본적으로 병렬 수행을 한다
  • 1 Workflow : N job 
• RUN-ON 속성 : Job 수행을 위한 OS 또는 머신을 정의
  • workflow 전체에서 돌아가는 것을 설정하는게 아닌, 각각의 job별로 실행하도록 머신을 정의하는게 가능.
  • 1 job : 1 Runner
• Step 속성 : Job을 구성하는 작업 단위, 실행 방식에 따라 아래의 두 가지로 분류한다.
  
  • Run : github action Platform에서 커맨드나 스크립트를 직접 입력하는 방식
  • Uses : 라이브러리 성격의 스크립트(다른 사람이 특정 목적을 위해서 미리 만들어놓은 실행 묶음)을
    가져와서 사용할 때 이를 사용한다.

 

 

2. Github Action Workflow

 

위의 그림에서 1. trigger만 제외한다면

이후에 일어나는 2~7까지의 모든 과정이 Github Action을 통해 자동화가 진행된다.

막말로 디버깅 정도만 진행한 후 코드가 실행하는 것만 확인했다면 이에 대한 테스트 및 빌드도 안하고

main에 push하기만 한다면 이 모든 과정이 전부 다 자동적으로 진행이 되어서 프로덕션 존에 배포가 되는 것이다.

 

이제부터, 이를 사용한 CI/CD절차를 순서대로 상세히 설명하도록 하겠다.

 

 

3. 상세 설명

• Trigger : 위의 그림에서도 그렇고 trigger라고 서술한 이유는 이게 좀 더 와닿는 단어이기 때문이다.
  공식 홈페이지에서는 Event로 설명을 하는데, push를 하건 무엇을 하건 배포를 할 조건
  (action.yml에 정의한 Event 가 이뤄질 때) github action의 workflow가 실행된다.
  
  
• Test : 설정한 Test가 있다면 이 또한 진행한다.
  (Java를 기준으로 Build할 때 Test를 하게끔 되어 있어서, 사실상 자바에서는 2+3이 통합된 과정이다.)
  
  
• Build : 소스 코드 뿐만 아니라 의존성 관리, 코드 테스트, 패키징, 배포를 위한 준비 과정이 통합해 빌드한다.
   
• Build Docker Image : 빌드된 결과물을 Dockerfile.yml을 통해 Docker Image화 하기 위한 빌드 작업이다.
  
  ✅ 참고로, 위의 과정에서 사용되는 자원들은 github action에서 제공한다. 그것도 무료로!
  굳이 컴퓨터의 리소스를 할당하지 않아도 된다는 것이다.
  
  
• Push to Registry : build한 Docker Image를 Registry에 push한다. 여기서는 Docker Hub를 예시로 들었다.
  다만, 여기서 Docker Hub에 푸시 할 때 필요한 username과 pw, 그리고 image의 이름은 환경변수화 해서 
  Repository의 변수에 세팅해주어야 한다.
   
• ------------------------------------ 위 까지가 CI, 지속적 통합의 과정이다. ----------------------------------------------------------
   
• Pull 하기 전에, CD과정에서는 github action에게 서버에 대한 접속 권한과 실행 권한을 부여해야 한다.
  특히 CD 자동화 과정에서는 스크립트를 통해 직접적인 shell 명령을 진행하기 때문에
  이러한 권한과 id, pw, IP, 서버 설정등을 진행하고 이를 사용할 부분에 환경 변수를 명시 후 사용해야 한다.
   
• Pull from Registry : Docker hub에 저장된 image를 서버로 pull해서 이미지를 업데이트 한다.
   
• Run Container : Docker image를 기반으로 container화 시킨다.
  이때, 필요한 서버만 내리고 업데이트 후 다시 올리거나 하는 식의 세부 조작 또한 가능하다.
   
• ----------------------------------- 여기까지가 CD, 지속적 배포의 과정이다. --------------------------------------------------------

 

 

 

 

 

https://docs.github.com/ko/actions/about-github-actions/understanding-github-actions

GitHub Actions 이해 - GitHub Docs