가시다님 CI/CD 스터디 1주차 과제입니다.
회사에서 운영 중인 CI 시스템 현황입니다.
사실 DevOps 입장에서 CI 시스템에 별 신경을 안쓰고 있습니다. DevOps로 Join 했을때 이미 잘 구축되어 있어 개발자 분들이 별 어려움 없었습니다. 코드 확인도 안하고 그냥 잘하고 있구나 정도로 넘어갔습니다.
아마 대부분이 그럴 것 같습니다. CI는 처음 구축할 때만 신경쓰고 이 후로는 별 신경을 안쓰게 되더라구요. 이전 회사에서는 젠킨스를 사용했는데, 에러 발생하면 파드 상태만 확인하지 굳이 CI 설정 파일까지 자세하게 보지는 않았습니다. 에러만 발생하지 않으면 좋겠다 정도로. 물론 부끄럽지만요.
현재 회사는 CI - Github Actions, 이미지 레포 - Github 이미지 레지스트리를 사용합니다.
주로 사용하는 CI 도구가 Jenkins, GitLab CI/CD, Travis CI, CircleCI 등이 있는데 최근에는 깃허브 액션을 가장 많이 사용하는 것 같습니다. 주위 DevOps 분에게 물어보면 이전부터 사용하면 굳이 변경하기 귀찮아서 젠킨스를 사용하는데, 신규 프로젝트는 대부분 깃헙 액션을 사용한다고 합니다. 아무래도 거의 모든 개발자들이 깃허브 계정을 가지고 있어 진입 장벽이 낮고 사용하기가 비교적 편리하기 때문인 것 같습니다.
데브옵스 입장에서는 CD에 비하여 어떻게 보면 CI는 단순한 작업이라 CI 용도로 추가 도구를 사용해서 관리 포인트를 늘리는 것보다는 깃저장소와 통합된 CI 시스템을 더 선호합니다. 젠킨스는 추가 플러그인 관리 등이 복잡하고 초기 설정이 까다로워 진입 장벽이 있는 편입니다.
아마 대부분의 스타트업, 중소 기업 등도 깃허브 Team Plan(사용자당 월 $6)을 사용하고 있을텐데 해당 Plan으로도 깃허브 액션을 3,000분까지 무료로 사용할 수 있어 비용 부담도 크지 않습니다. 그리고 깃허브 액션을 EC2 또는 VM에서 Self-Hosted로 사용하면 추가 비용 부담없이 사용할 수 있어 무료 3,000분 이상을 사용하는 조직도 부담이 없습니다.
이미지 레포는 개인적으로 ECR을 선호합니다. EKS 환경이면 별도 레포 Secret도 필요없고 같은 Region에 위치하니 속도도 더 빠를 것 같습니다. 저희 회사는 이미 깃허브 이미지 레포를 사용하고 있어서 변경하지는 않았습니다.
상세한 깃헙 Workflow 세팅입니다. (전체 코드는 공유할 수 없지만 아마도 이해하는데 크게 어려움이 없을 것 같습니다.)
먼저 환경 변수 설정입니다.
jobs:
setup:
name: SetUp
runs-on: ubuntu-latest
outputs:
timestamp: ${{ env.TIMESTAMP }}
scheme: ${{ env.SCHEME }}
kube-scheme: ${{ env.KUBE_SCHEME }}
branch: ${{ env.BRANCH }}- timestamp
이미지 태그 정보를 timestamp로 지정합니다.
TIMESTAMP=$(TZ='Asia/Seoul' date +"%Y%m%dT%H%M%S.%N")
echo "TIMESTAMP=${TIMESTAMP}" >> $GITHUB_ENV-
개인적으로 태그 설정은 SemVer를 선호합니다. 개인 테스트 환경에서는 깃헙의 Tags 정보를 자동으로 이미지 태그로 지정하게 사용하였습니다.
-
branch, scheme, kube-scheme
깃헙 branch 이름에 따라 develop - dev, release - staging, main - prod 로 환경 변수를 세팅합니다. 해당 환경 변수에 따라 아래 예제와 유사하게 별도의 깃헙 헬름 차트의 이미지 태그를 자동으로 수정할 수 있도록 디렉토리 Path를 지정하는 용도로 사용합니다.
TIMESTAMP=${{ needs.setup.outputs.timestamp }}
cd helm-charts/${{ needs.setup.outputs.kube-scheme }}/${{ needs.setup.outputs.scheme }}
그리고 Build and Push
자바가 저희 회사 주 언어라 자바 개발자는 Gradle Jib 사용합니다. 처음와서 Dockerfile이 없어서 꽤 당황했었습니다. 개발자에게 물어보니 멀 그런 초보적인 질문을 하세요 라는 반응을 보여 조금 쪽팔렸습니다. 도커파일도 없고 도커 데몬도 필요없고, Gradle Jib 아주 좋더라구요.
Build and Push 워크플로우 파일은 아주 평범합니다.
마지막으로 별도로 있는 헬름 깃헙 레지스트리의 이미지 태그를 수정하는 작업입니다.
워크플로우 파일은 깃헙 브랜치 이름에 따라 헬름 깃헙의 디렉토리 Path의 dev, prod 태그를 자동으로 수정하여 git commit, push 합니다. 이후 개발자는 Dev 환경은 ArgoCD AutoSync 설정이라 EKS 환경에 잘 배포되는지 확인하고 Prod 환경은 AutoSync 옵션을 사용하지 않아 ArgoCD 콘솔에서 변경 내역을 Diff에서 수동으로 확인하고 배포합니다.
- name: yq scheduler
uses: mikefarah/yq@master
with:
cmd: TIMESTAMP=${{ needs.setup.outputs.timestamp }} yq -i '.image.tag = strenv(TIMESTAMP)' ./${{ needs.setup.outputs.kube-scheme }}/${{ env.KUBE_NS }}/${{ needs.setup.outputs.scheme }}/scheduler/ci/values.yaml
yq를 이용해서 파일의 이미지 태그 부문만 수정합니다.
추가로 이미지 레포에 대하여 사용하지 않는 이전 이미지 자동 삭제, 이미지 보안 스캐닝 기능 등이 필요합니다.
