hippo 데브옵스
2022. 7. 8. 00:50
2022. 7. 8. 00:50
1. GitOps를 도입하기 전과 GitOps를 도입한 후의 kubernetes의 배포 방식 차이
2. GitOps란
2.1. 개발자의 코드가 실제 서비스로 반영되기까지 많은 과정을 거쳐야함
- Repository에 Push 후 CI를 통해 Docker Image로 빌드
- Container Registry(ex: DockerHub)로 업로드
- Kubernetes에 배포 방법 선택 후 kubernetes cluster에 배포
2.2. GitOps를 도입하기 전의 문제화 해결 과정
- 사람마다 선호하는 배포 방식이 제각각이고 여러 소스(원천)로부터 Manifest가 변경됨
- 이미지 태그를 1.1로 업데이트하여 배포했는데, 누군가가 1.0 버전의 Manifest 파일로 배포했다면 문제가 발생 가능
- 여러 사람이 배포하기에 배포한 담당자를 파악하기 힘들고, 다시 1.1 버전으로 배포진행해야함
- Manifest를 가져오는 소스를 Git Repository 한 곳으로 통일하는 방식으로 문제에 해결
- Git Repository에 존재하는 Manifest 파일과 Kubernetes cluster에 존재하는 리소스의 현재 상태를 계속 비교하며 Sync 작업을 수행
- 현재 Manifest에 정의한 리소스가 생성되지 않았으면, 생성하고, 일치하지 않는 경우 Spec에 맞도록 복구 작업을 수행
- 모든 과정을 자동으로 진행하기에 사람이 배포에 개입할 여지를 최소화 → 더 이상 배포를 Imperative 방식이 아닌 Declarative 방식으로 수행
3. 단일 진실의 원천(Single source of truth; SSOT)이란
- 단일 진실의 원천은 "오직 진실(결과)이 오직 한가지의 원천(이유)에서 발생"하는 것을 의미
- 단일 진실의 원천에 대한 예시로, 어떤 아이가 울고 있으면(결과) 그것은 오직 아이스크림을 땅바닥에 떨어뜨렸기 때문(이유)이라고 가정
- 넘어져서 우는 것도 아니고 혼나서 우는 것도 아니라 오직 아이스크림을 땅바닥에 떨어뜨렸기 때문에 우는 것
- 반대로 아이스크림을 제대로 들고 있으면 항상 웃고, 아이가 웃는다면 이유는 칭찬을 받아서도 아니고 과자를 먹어서도 아니고 오직 아이스크림을 떨어뜨리지 않았기 때문임
4. 소프트웨어 배포 관점에서 단일 진실의 원천
4.1. 단일한 방법으로의 소프트웨어 배포
- 어떤 소프트웨어를 개발하여, 운영 환경에 반영할 때 다양한 방법을 통해서 배포 가능
- 예를 들어, 자바 WAR 파일을 운영 환경의 Tomcat 서버에 배포를 한다고 했을 때, scp를 이용하여 파일을 배포할 수도 있고 S3에 파일을 올려놓고 운영 서버에서 그것을 다운 받을 수도 있음
- 자동으로 배포를 하고 싶으면 ansible이나 chef 같은 툴을 이용하여 소프트웨어를 배포 가능
- 소프트웨어를 배포 방법이 다양하면 문제가 발생할 소지가 많아짐 → 사람마다 배포하는 방법이 달라 human error가 증가하게 될 수 있고 다양한 배포 방법이 서로 충돌할 여지 발생 가능
- 배포에서 충돌이 발생하는 human error 문제를 해결하기 위해서 GitOps는 소프트웨어 배포 과정을 체계적으로 관리하고 자동화하기 위해 모든 배포 정의를 한 곳에서 관리하고 한가지 방법으로 배포하는 것을 추구
4.2. 항상 원천(Git Repository)의 상태를 완벽히 반영하는 배포
- 위 아이스크림과 아이의 예시에서 아이가 아이스크림의 상태를 완벽하게 반영한다고 할 수 있음 → 아이스크림을 들고 있으면 아이는 울지 않고 아이스크림을 떨어뜨리면 아이가 울기 때문.
- 소프트웨어 배포 관점에서 보자면, 아이스크림은 배포 작업 정의서(어떻게 소프트웨어를 배포할지 기술한 문서)를 의미하고 아이는 실제 배포된 상태를 의미
- GitOps에서는 배포상태의 모습을 항상 Git Repository과 동일하게 맞출려고 노력
- “단일 진실의 원천(Single source of truth; SSOT)” 방법을 통해 얻을 수 있는 3가지 장점.
- 현재 배포환경의 상태를 쉽게 파악 가능 → 배포환경에 들어가서 상태를 파악할 필요 없이 Git Repository(배포 작업서)만 확인하면 쉽게 파악 가능
- 빠르게 배포 가능 → 단일한 방법으로 소프트웨어를 배포하여 표준화 시켰기 때문에 쉽게 배포 자동화 가능(빠르고 지속적인 배포를 가능)
- 안정적으로 운영 환경에 배포 가능 → 배포할 때 운영 환경에서 발생할 수 있는 human error를 최소화(배포를 관장하는 사람은 Git Repository의 내용만 잘 확인하면 문제 X)
- GitOps는 Git 저장소를 단일 진실의 원천으로 사용
- 쿠버네티스와 같이 선언형 (declarative description)명령은 Git 저장소(Git Repository)에 원하는 배포 형태를 선언하기만 하면 운영에 반영하기 쉬움
5. GitOps 방식의 이점
- Manifest가 위치한 Repository만 신경쓰면 됨 → Manifest Repository에 권한이 있는 인원만 배포 과정에 참여할 수 있으며, Manifest 파일 변경 이력이 Git에 그대로 남기 때문에 추적이 용이
- 배포 과정 단순화 가능 → 터미널에서 'kubectl' 명령어를 실행하거나, 스크립트를 수정하는 등의 작업이 없어지기 때문에 더욱 빠르고 자주 배포 가능
- 사람의 부주의로 발생할 수 있는 Human Error을 줄일 수 있음
- 서비스 업데이트는 해당 Manifest파일을 수정해서 Repository에 Push하는 것으로 실현하고, 새 버전에 문제가 있는 경우, 'git revert'를 해서 이전으로 쉽게 돌아갈 수 있음
6. GitOps에서 요구하는 원칙
- GitOps는 특정 소프트웨어나 프로덕트가 아닌 철학 혹은 방법론에 더 가까움
6.1. 선언형 배포 작업 정의서
- 배포 방법이 명령형 방식으로 정의된 것이 아니라 배포된 상태가 어떤 모양을 가져야 할지 선언되어 있는 방식으로 정의가 되어 있어야 함
- 사용자가 배포의 원하는 상태 (desired state)를 선언적으로 정의
- Git 저장소에 단일 진실의 원천 조건을 만족 가능
- 배포 작업 정의서가 선언형으로 되어 있으면 더 쉽게 배포할 수 있으며 문제 발생시, 롤백하기도 쉬움
- 장애 등으로 인해 손상된 배포 환경을 자가 치유하기 유리
6.2. Git을 이용한 배포 버전 관리
- Git에 모든 배포에 관련된 정보가 정의되어 있어야 함
- 각 버전이 Git 저장소에 기록이 되어야함
- 사용자는 쉽게 예전 버전으로 롤백을 하거나 새로운 버전으로 업그레이드 가능
6.3. 변경 사항 운영 반영 자동화
- 사용자는 Git 저장소에 선언형 정의서를 저장하게 되면 실제 배포가 일어나는 작업은 자동으로 이루어져야함
- 책임지는 주체가 ArgoCD와 같은 배포 주체(deploy operator)가 됨
- 자동으로 하는 경우 human error를 줄이고 지속적 빌드/배포를 가능하게 만듬
6.4. 자가 치유 및 이상 탐지
- 사용자가 원하는 배포 상태 (desired state)를 작성하게 되면 실제 배포 환경이 그에 맞게 유지되고 있는지 책임지는 것 또한 배포 주체(deploy operator)가 됨
- 배포를 관장하는 소프트웨어가 주체가 되어 현재 배포 상태를 확인하고 Git 저장소의 변경 사항 등이 없는지를 체크하여 운영 환경에 반영하는 역할을 함
- 원칙들을 가지고 소프트웨어를 배포하는 모든 Agent를 우리는 GitOps의 구현체 (Deploy Operator)라 부름.
- 현재 GitOps의 구현체로 ArgoCD 뿐만 아니라 Weaveworks flux, Codefresh, Jenkins X 등 다양한 소프트웨어들이 존재