GitHub Actions CI-CD 실습 하기
이번에는 실제로 GitHub Actions 이용해서 WorkFlow 통해 CI-CD 해보도록 하겠습니다. 실제로 배포가 완료가 된다면 ASW ECR 에 docker image 가
저장되고 이를 이용해 AWS EKS 에 배포 되는 FLOW 로 진행 될 예정 입니다.
CI-CD 진행 해보기
우선 ‘develop’ 브랜치를 통해서 ‘feature-cicdV2-test1’ 이라는 브랜치를 만들었습니다.
해당 브랜치에서
해당 어플리케이션을 접속 하면 “SpringBoot App CICD TEST 1” 출력 할 수 있도록 코드 추가 했습니다. 실제로 배포 되면 “SpringBoot App CICD TEST 1”
이라는 문구가 웹브라우저에 나타날것 입니다.
‘release-dev’ <- ‘feature-cicdV2-test1’ 브랜치로 merge 할 수 있도록 PR 를 생성 하도록 하겠습니다.
PR 를 생성되면 동시에 CI (TEST) GitHub Actions ‘test’ Job 이 발동 됩니다.
‘test’ Job 이 완료 되었고 정상적으로 CI 가 문제없이 완료 되었습니다.
이후 생성한 PR 를 ‘release-dev’ 로 merge 하도록 합니다.
merge 와 동시에 GitHub Actions 가 발동 됩니다.
이전에 앞써 설명 한대로 CD 작업이 진행하게 됩니다. 우선 ‘set-environment’ Job 통해 배포 환경 변수를 배정되고
‘image-build’ 진행해서 docker image 를 생성 후 AWS ECR Repository 에 해당 개발 전용 저장소에 저장 하게 됩니다.
그리고 ‘deploy’ Job 에서 실질적으로 AWS EKS 서비스를 이용해서 helm 활용해 kubernetes 에 배포 및 쉽게 관리 할수 있도록 합니다.
Slack 메신저를 통해 성공 여부 결과 메시지가 전송 되는 것을 확인 할 수 있습니다.
AWS ECR 개발 전용 Repository 에 접속 하게 된다면 docker image 가 업로드 된것을 확인 할 수 있습니다.
1 | kubectl get ns |
해당 명령어를 통해 네임스페이스 조회 해보면 정상적으로 ‘spring-boot-dev’ 이라는 네임 스페이스가 생성 되었고
1 | kubectl get pods -n spring-boot-dev |
‘spring-boot-dev’ 네임스페이스를 조회 해보면 파드가 만들어졌다는 것을 확인 할 수 있습니다.
1 | kubectl get services -n spring-boot-dev |
‘spring-boot-dev’ 네임스페이스의 서비스를 조회 해보면 로드벨런스 타입으로 리소스가 생성 된것을 확인 할 수 있습니다.
로드벤런스 DNS 접속 하게 되면 정상적으로 “SpringBoot App CICD TEST 1” 출력 되는 것을 확인 할 수 있습니다.
그 다음으로는 ‘feature-cicdV2-test1’ 브랜치에 ‘v1.0.50’ 이라는 tag 를 추가 해서 푸쉬 하도록 하겠습니다.
tag 를 푸쉬 동시에 GitHub Actions WorkFlow 가 발동 하게 됩니다.
‘create-pr-develop’ 이라는 job 을 실행 하게 되는데 역활은 release/${tag name} 이라는 브랜치를 생성해서
‘release/${tag name}’ <- ‘feature-cicdV2-test1’ merge 하기 위한 PR 이 동시에 생성 하게 됩니다.
workflow 통해 PR 이 자동적으로 생성 되면 PR 생성이 되었으니 또 workflow 가 발동하게 됩니다.
‘test’ 이라는 job 발동 되어서 CI 작동 되는 것을 확인 할 수 있습니다.
생성된 PR 통해 merge 를 진행 하도록 합니다. (develop 로 merge 진행)
merge 진행과 동시에 GitHub Actions WorkFlow 진행 하게 됩니다.
‘create-pr-prod’ 이라는 Job 을 실행 하게 됩니다. 이때 ‘develop’ -> ‘release-prod’ 브랜치로 merge 하기 위한 PR 이 생성 하게 됩니다.
workflow 통해 PR 이 자동적으로 생성 되면 PR 생성이 되었으니 또 workflow 가 발동하게 됩니다.
‘test’ 이라는 job 발동 되어서 CI 작동 되는 것을 확인 할 수 있습니다.
생성된 PR 통해 merge 를 진행 하도록 합니다. (release-prod 로 merge 진행)
merge 진행과 동시에 GitHub Actions WorkFlow 진행 하게 됩니다.
CD 작업이 진행하게 됩니다. 우선 ‘set-environment’ Job 통해 배포 환경 변수를 배정되고
‘image-build’ 진행해서 docker image 를 생성 후 AWS ECR Repository 에 해당 상용 전용 저장소에 저장 하게 됩니다.
여기서 개발 서버로 배포하는 WorkFlow 와 차이점을 있다면 ‘approve’ 이라는 job 단계가 있습니다.
앞써 설명한대로 GitHub 페이지에서 ‘Approve Process’ 라는 환경을 구성하고 ‘Protection Rule’ 을 설정을 한 다음 GitHub Actions Job 에서 Environment 값으로 Approve Process 를
사용하면 승인을 받아야만 Approve Job 이 실행이 됩니다.
‘Review Deployments’ 이라는 버튼을 클릭하게 되면 승인 할 수 있는 팝업이 나타납니다. 지정된 사용자로 승인 처리 합니다.
‘prod-deploy’ 이라는 Job 이 실행하게 되면서 실질적으로 AWS EKS 서비스를 이용해서 helm 활용해 kubernetes 에 배포 하게 됩니다.
Slack 메신저를 통해 성공 여부 결과 메시지가 전송 되는 것을 확인 할 수 있습니다.
1 | kubectl get ns |
해당 명령어를 통해 네임스페이스 조회 해보면 정상적으로 ‘spring-boot-prod’ 이라는 네임 스페이스가 생성 되었고
1 | kubectl get pods -n spring-boot-prod |
‘spring-boot-prod’ 네임스페이스를 조회 해보면 파드가 만들어졌다는 것을 확인 할 수 있습니다.
1 | kubectl get services -n spring-boot-prod |
‘spring-boot-prod’ 네임스페이스의 서비스를 조회 해보면 로드벨런스 타입으로 리소스가 생성 된것을 확인 할 수 있습니다.
상용 전용 로드벤런스 DNS 접속 하게 되면 정상적으로 “SpringBoot App CICD TEST 1” 출력 되는 것을 확인 할 수 있습니다.
Tag 이용해서 rollback 진행하기
만약에 상용배포 후 알수 없는 에러가 발생 되는 경우 이전 버전으로 rollback 해야 합니다. ‘feature’ 브랜치에서 ‘develop’ 브랜치로 PR 생성
하는 과정에서 tag 생성하고 push 통해 관리 하고 있었습니다.
이전 tag 값으로 rollback 으로 진행을 원할 경우 GitHub Actions 페이지에 접속해서 ‘release-prod’ 브랜치로 PR Close 된 기록을 찾아 해당되는
tag 로 rollback 을 진행 하면 됩니다. 이미지 통해 확인 하면 빨간 버튼 클릭 후 rollback 진행 하도록 합니다.
Copyright 201- syh8088. 무단 전재 및 재배포 금지. 출처 표기 시 인용 가능.
