먼저, 현재 프로젝트의 github action은 한개의 step으로 이루어져 현재 진행 단계를 알기가 힘들었다.
이것은 빌드 및 배포를 통합한 github action이다. 그래서 해당 작업을 좀 더 알아보기 쉽게 바꾸어 보기로 했다. 먼저 배포 과정부터 정리해 보았다.
- tag 입력 확인
- 디펜던시 다운로드
- 빌드
- 배포환경 설정
- 배포
- 성공 또는 실패 결과 슬랙 전송
위의 4가지 단계로 정규화를 시킬수 있었다. 여기서 공통으로 묶을 수 있는 작업을을 function 형태로 묶어보고 싶었다. 그래서 찾아보던 중 function과 비슷하게 사용 가능한 reusable workflows가 있었다. 해당 기능은 말 그대로 workflow를 재사용 가능하게 하는 기능이였다. 출시된지 얼마 안된거 같지만, 내가 원하는 기능이기에 바로 도입을 시도해 보았다. 사용법은 아래 공식문서를 참고했다.
https://docs.github.com/en/actions/using-workflows/reusing-workflows
내가 사용한 기능만 추리면 다음과 같다.
- 워크플로우 정의
- 워크플로우 정의는 말 그대로 작업을 정의하는 것이다. 코딩하는 관점에서 보면 재사용 가능한 function 형태를 만드는 것이고, 워크플로우의 소스는 같은 파일, 같은 repo, 공개된 reusable workflow 등을 사용 가능하다. 간단하게 reusable_workflow_job을 정의하여 사용할 수 있다. 자세한 내용은 공식문서 참고 -> 해당 기능을 사용해서 각 workflow를 파일로 만들고, main workflow는 각 workflow를 참조하는 방식으로 작성할 수 있다.
- 워크플로우 사용
- 위에서 정의 한 workflow를 사용한다. uses 선언을 통해서 사용이 가능하다.
- inputs 사용
- 함수면은 당연히 입력 변수가 있어야 할 것이다. 이는 워크플로우 정의 시 inputs를 선언하여 타입, required, default 등 다양한 옵션을 설정할 수 있다. 사용할 때는 with를 사용하여 입력변수를 넣어줄 수 있다.
- secret pass
- 외부에 드러내기 싫은 민감한 정보를 pass해야 할 수도 있다. 이럴 때는 secrets: inherit 옵션을 사용하여 secret을 보낼 수 있다.
그리고 여기에 작업을 하는 순서를 임의로 지정할 수 있다. 예를 들어 실수로 빌드가 되지 않는 코드를 올렸는데, 빌드와 배포가 동시에 이루어진다면 잘못된 파일이 배포가 될 수도 있다. (물론 빌드가 안되어서 막히겠지만, 그냥 예시 이니 넘겨주시길...) 그래서 빌드 다음 단계에 배포가 이루어져야 한다. kubernetes의 depends_on과 비슷해 보인다. 해당 기능은 needs 옵션을 사용하면 된다.
해당 기능을 적용하면 workflow는 다음과 같이 바뀐다.
해당 main github action 코드는 500줄 정도에서 100줄 정도로 줄어들어서, 가독성이 훨씬 좋아졌다. (물론 reusable workflow를 제외한 길이...)
'서버 인프라 > DevOps' 카테고리의 다른 글
12 Factor App 이란? (0) | 2023.08.02 |
---|---|
쿠버네티스의 Network Solution에 대하여 (0) | 2023.04.14 |
Terraform 훑어보기 (0) | 2023.04.02 |
자동 배포 환경 Github Action으로 이전하기 (0) | 2022.10.07 |
Jenkins를 이용하여 Docker 애플리케이션 배포하기 [3] (0) | 2022.03.25 |