Github Action으로 시작하는 GitOps 파이프라인(AWS ECR, Github Actions)

Github Actions이 뭘까?

CI/CD와 같은 workflow를 자동화 할 수 있는 도구로, 2018년부터 깃허브에서 제공하는 서비스.

​

깃허브를 통해서 버전 관리나 협업하는 이상, 깃허브 내의 이벤트(push,pull,merge ...) 의 발생에 대해 정해진 동작을 실행해주는 Actions 기능은 Jenkins같은 CI 툴만큼이나 편리할 수 밖에 없다. Public 레포지토리는 제한있는 무료로 사용 가능함.

​

Github CLI를 사용하면 Repository를 push하지 않더라도 Branch의 Actions들을 실행하고 필요한 정보를 넘겨줄 수 있다.

​

​

​

들어가기에 앞서서, 알아둬야할 핵심적인 개념을 소개하겠음

 

Github Actions의 구성

1. Workflow

• Event를 트리거로 여러 Job으로 구성된 프로세스(가장 최상위의 개념)
• YAML로 작성되어 Repository의 .github/workflows 폴더에 저장된다.

1-1. WorkFlow의 대표적인 예시

1. TestCode
2. Deployment
3. 그냥 자동화하고 싶은 스크립트

​

2. Event

• Workflow를 실행하기 위한 Trigger 역할. (on:push 등)
• 특정 branch로 Push, Pull Request, Cron 등을 하는 경우 등

 

3. Job

• 어떤 순서로 실행되어야하는지 명시하는 여러 Step을 가지며, 가상 환경의 instance에서 실행된다.
• 다른 job에 의존 관계를 가질 수 있고, 기본적으로 병렬 처리되지만 순서대로 처리할 수 있다.

3-1. Step

• Task들의 집합으로, 명령어를 선언하거나 Action을 실행할 수 있다.
• 보통 Job안에서 어떤 순서로 실행될지 Step1, Step2 ..처럼 명시한다.

3-2. Job의 의존 관계 설정하기

• yaml 파일에서 jobs의 needs를 사용해서 관계를 설정할 수 있음.

jobs:
    job1:
    job2:
      needs: job1
    job3:
      needs: [job1, job2]

job1은 job2이 시작되기 전에 성공적으로 완료되어야 하고, job3은 job1,과 job2가 모두 완료될떄까지 대기한다.

​

​

4. Action

• Workflow의 가장 작은 단위로 재사용이 가능하다는 특징이 있다.
• Job을 만들기 위해 Step들을 연결할 수 있음.
• Github에서 제공하는 공용 Action도 있지만 개인적으로 만들 수 도 있다.

​

5. Runner

• Github Action Runner app이 설치된 VM.
• Workflow가 실행될 instance로, 각각의 Job 들은 개별적인 Runner라는 컨테이너에서 실행된다고 보면 된다.
• 직접 호스팅하는 Self-hosted runner와 Github에서 호스팅해주는 Github-hosted runner로 구분

(Github-hosted runner의 경우, Azure Standard_DS2_v2 vCPU 2, 메모리 7GB, 임시 storage 14GB)

​

​

​

아래에 간단한 예시를 들겠다.

​

직접 yml 작성도 되고, 제공해주는 action들중에서 골라도 된다.

.github/workflows 경로로 commit하면 폴더안에 파일이 생기고, Event 조건에 맞춰서 Action을 자동 실행해준다.

​

​

​

추가로,

​

Repository의 Setting-> Secrets and variables 항목에 들어가면 있는 Action Secrets 에서 정보에 민감한 값들을 관리할 수 있음.

ex) Slack을 활용해서 테스트 코드 오류시 알람을 보내기 위한 Key값이나 사용하는 Node의 버전을 담는 값 등

​

 

GitOps

GitOps는 애플리케이션의 배포와 운영에 관한 요소를 Git에서 관리(Operation)해서 클라우드 네이티브 애플리케이션을 대상으로 한 지속적 배포(Continuous Deployment)에 초첨을 두고 있다.

 

Weaveworks 사에서 처음으로 사용한 용어로, DevOps의 방법중 하나이다.

​

기본적인 개념은 개발자에게 친숙한 코드를 이용해 인프라 요소를 프로비저닝하고 관리하는 IaC(Intfrastructure as Code)에서 유래했다. GitOps는 이를 인프라에서 전체 애플리케이션 범위로 확장한 셈이다.

​

​

GitOps의 원칙

• 모든 시스템은 선언적(declarative) 선언해야함
  • declarative : 명령들의 집합이 아닌 사실들의 집합임을 보장
• 시스템 상태는 Git 버전을 따라야함
  • 이전 버전을 배포할려면 git revert 사용
• 승인된 변화는 시스템에 자동으로 적용되어야함
  • 코드 수정시 자동으로 시스템에 적용되어서 클러스터 배포마다 자격증명이 필요하지 않아야함
• 배포에 실패하면 사용자에게 경고해야함

​

GitOps Repository는 기본적으로 최소 두 개 이상 사용하도록 권장한다.

(애플리케이션과 배포를 위한 Manifest를 모아둔 Repository, 배포 환경 구성용 Repository)

​

​

​

GitOps 배포 전략

1. Push Type

• 배포 환경의 개수에 영향을 받지 않고 접속 정보의 수정으로 배포 환경을 추가할 수 있다.
• 보안 정보가 외부로 노출될 수 있다

​

2. Pull Type

• 배포하는 클러스터에 위치한 별도의 오퍼레이터가 배포 역할을 대신한다.
• 오퍼레이터는 Git Repository의 Manifest와 배포 환경을 계속 비교하면서 차이가 생길때 전자(Git Repo)를 기준으로 클러스터를 유지한다.

​

​

Pull Type은 오퍼레이터가 애플리케이션과 동일한 환경에서 동직중이라 보안 정보가 외부로 유출되지 않는다. (ArgoCD는 두 전략 모두 지원하긴 하지만, Pull Type을 권장한다.)

​

​

GipOps continuous delivery tool for Kubernetes

개발자가 “You own it, you ship it!” 소유하고, 배포까지 한다!라는 방식으로 운영을 맡을 수 있도록 지원한다.

Kubernetes Cluster의 Manifest 설정을 담은 Repo와 애플리케이션 소스의 Repo의 브랜치를 통합하고 적용하는 골자는 동일하다.

​

Git Repostiory에서 Kubernetes Manifest 파일들을 관리하고, 배포할때도 Git에 등록된 Manifest로 클러스터에 배포한다.

​

​

​

나는 Github Action으로 프로젝트의 통합(Continous Integration)를 진행하고 AWS ECR에 registry 형태로 이미지를 저장하는 걸 선호한다.

​

k8s 환경에서 배포시 ingress는 alb-controller 사용하고 ArgoCD와 연동되는 Argo-Rollout을 사용했다. Argo를 통해 진행니 편리했다.....ㅎ

​

​

​

​

 

중간 과정에서 실패하면 다음과 같이 오류 로그까지 확인할 수 있다.

 

 

​

이제 main branch로 push하거나 pull request하게 되면, 설정해둔 mysql와 gradle을 토대로 애플리케이션을 빌드해보면서 오류가 있는지 테스트해본다.

작업중에 빌드 오류가 발생하면 Github Actions가 해당 작업을 실패로 표시하고 로그 및 출력을 제공해서 개발자가 원인을 파악할 수 있게 해주는데, 이 일련의 과정을 자동화해줘서 Jenkins와 같이 유용한 CI 툴로 이용할 수 있음

​

어설프게나마 틀을 갖춰가고 있다. 지금이야 장난감이지만... 공부중인 내용을 접목시킬 좋은 양분이 될 거같다.

 

 

 

 

출처 및 인용

https://www.gitops.tech/

https://www.weave.works/technologies/gitops