Github Action - Trigger Another Repository Workflow and Push Self

 GitOps 를 구현하는 과정에서 고민했었던 부분 그리고 해결한 방법을 정리하려고 한다.

GitOps 에서 크게 Application Repository ( Code Repository ) 와 Environment Repository ( State Repository ) 두 가지의 Repository 로 정의가 된다. 조직의 프로세스나 크기, 형태, 철학마다 다르겠지만, 일반적인 회사에서나 어떤 프로젝트에서 협업을 할 때 보통 개발팀과 운영팀이라는 개념으로 나뉠 수 있을 것이다. 이 때 보통 Application Repository 는 개발팀이 Environment Repository 는 운영팀이 관리할 것이다.

개발팀에서 지속적으로 새로운 기능 및 유지 보수를 진행함에 따라서 소프트웨어의 변경이 일어난다. 해당 변경은 CI 를 통해서 새로운 Container Image 를 생산할 것이다. 이 때 운영팀은 Image 들의 버전을 Environment Repository 에 반영해야 한다. 

이 과정에서 여러가지 의문점이 들었다. 운영팀은 Environment Repository 의 Application 들의 버전 변경을 수동으로 반영할까 자동으로 반영할까? 수동으로 반영하는 프로세스라면 휴먼에러가 발생하지 않을까? 발생한다면 어떻게 대처할까? 자동으로 반영한다면 그것또한 무결함을 보장할 수 있을까? 이러한 의문점들은 귀결은 "Environment Repository 를 어떻게 관리하는게 좋을까?" 이다. 조금만 생각해보면 해당 질문에 정답이 있는것은 아니라는 결론이다. 모든것은 현재 해당 프로젝트 해당 조직이 처한 context 에 따라 다를것이다. 규모가 큰 조직일수록 관리해야할 application 이 많아서 수동으로 관리하는 것에 한계를 느낄 것이고, 반대로 규모가 작은 조직일수록 수가 적은 application 들을 관리하기 위해서 자동화를 하는 것에 더 비용을 크게 느낄수 도 있을 것이다. 

개인적으로 자동화는 단기적인 관점에서 보는 것이 아니라 장기적인 관점에서 보는 것이 옳다고 생각한다. 자동화의 대상이 매일매일 아니 보다 몇시간마다 일어나야 하는것이라면 말이 또 다르다. 이는 생산성에 지대한 영향을 줄 수 있다고 생각한다. 따라서 자동으로 반영하는 것을 선택하기로 했다.

자동으로 반영하는 방법에는 어떤 Tool 을 사용하느냐 어떤 프로세스를 선택하느냐에 따라 천차만별이지만, 기존에 사용하고 있는 프로세스인 Github Action 만을 이용하여 CI/CD 를 구축하는 것이다. 이번 글에서는 Github Action 을 이용해서 두 개의 Repository 의 Workflow 을 연결하는 예제를 정리하고자 한다.

시나리오

- Application Repository ( Code Repository ) - Repository A
- Environment Repository ( State Repository ) - Repository B

Repository A 의 Github Action Workflow 에서 Docker Image 를 Build 하고 AWS ECR 에 Push 한다. 그리고 event_dispatch api 를 통해서 Repository B 의 Github Action Workflow 를 호출한다. 호출하는 과정에서 event type 과 Docker Image Tag 를 포함한 payload 를 보낸다.

아래는 Repository A 의 Github Action workflow 이다.
마지막 부분에 event_type 으로 backend-tagging 을 tag 를 client payload 에 보내고 있다.
해당 api 를 사용하기 위해서 access token 을 secrets 을 통해서 사용했다. 



다음은 Repository B 에서 repository_dispatch 의 type 을 통해서 해당 workflow 가 실행된다.
미리 작성한 version_change.sh 스크립트를 통해서 api 를 통해서 받은 tag 를 helm values.yaml 에 반영한다.
그리고 반영한 결과를 main 브랜치에 push 한다.

아래는 version_change.sh 스크립트이다. -t 옵션의 인자를 통해서 tag 를 받고 받은 tag 를 sed 명령어를 통해서 values.yaml 의 형태의 동일하지만 tag 부분만 다르게 해놓 파일을 치환하여 덮어쓰는 로직이다.

스크립트를 작성하는 일은 번거로운 작업이 될 수 있다. 따라서 스크립트를 직접 작성하기 보다 좋은 Tool 을 찾아서 공유한다.

바로 yq 이다. k8s manifest 파일 그리고 helm 차트 yaml 파일이다. yq 는 yaml 파일을 보다 쉽게 다룰 수 있도록 만들어졌다. yq 는 yaml 파일뿐만 아니라 json 도 다룰 수 있다.
또한 Github Action 에서도 사용할 수 있다.

file.yaml 의 .a.b 값을 cool 로 변경하는 예시이다.


Github Action 에서 yq 를 사용할 수 있다.





참고





댓글

이 블로그의 인기 게시물

About JVM Warm up

About idempotent

About Kafka Basic

About ZGC

sneak peek jitpack

Spring Boot Actuator readiness, liveness probes on k8s

About Websocket minimize data size and data transfer cost on cloud

About G1 GC

대학생 코딩 과제 대행 java, python, oracle 네 번째