Github Action - Trigger Another Repository Workflow and Push Self

- 12월 15, 2021

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 을 통해서 사용했다.