GitOps 란?

출처 : https://coffeewhale.com/kubernetes/gitops/argocd/2020/02/10/gitops-argocd/

GitOps와 ArgoCD

출처 : https://www.gitops.tech/

GitOps

GitOps 는 무엇인가?

GitOps란 Weaveworks라는 회사에서 처음 쓰기 시작하였고 CI/CD 파이프라인 중 특별히 Delivery에 초점을 가지고 탄생한 개념입니다.

GitOps을 설명하기 전에 “Single source of truth” (SSOT), 직역하자면 단일 진실의 원천에 대해서 먼저 짚고 넘어가면 좋을 것 같습니다. 단일 진실의 원천을 풀어서 설명하자면, 어떠한 진실(결과)의 원인이 오직 단일한 원천(이유)에서 나왔다는 것을 의미합니다.

쉽게 예를 들자면, 어떤 아이가 울고 있으면(결과) 그것은 오직 아이스크림을 땅바닥에 떨어뜨렸기 때문(이유)이라고 가정해 봅시다. 넘어져서 우는 것도 아니고 혼나서 우는 것도 아니라 오직 아이스크림을 땅바닥에 떨어뜨렸기 때문에 우는 것입니다. 반대로 아이스크림을 제대로 들고 있으면 항상 웃고 그 아이가 웃는다면 이유는 칭찬을 받아서도 아니고 과자를 먹어서도 아니고 오직 아이스크림을 떨어뜨리지 않았기 때문입니다.

이것이 단일 진실의 원천입니다. 오직 그 진실(결과)이 오직 한가지의 원천(이유)에서 비롯된다는 것입니다. 

왜 GitOps를 사용해야합니까?

더 자주 더 빠르게 배포

공평하게 말하면, 아마도 모든 Continuous Deployment 기술은 더 빠르게 배포하고 더 자주 배포 할 수 있도록 약속합니다. GitOps의 고유 한 점은 응용 프로그램을 배포하기 위해 도구를 전환 할 필요가 없다는 것입니다. 어쨌든 응용 프로그램 개발에 사용하는 버전 제어 시스템에서 모든 것이 발생합니다.

"고속"이라고 말하면 모든 제품 팀이 하루에 여러 번 안전하게 업데이트를 제공 할 수 있습니다. 즉각 배포하고 결과를 실시간으로 관찰 한 다음이 피드백을 사용하여 롤 포워드 또는 롤백 할 수 있습니다.

— 위브 웍스

쉽고 빠른 오류 복구

아뇨! 프로덕션 환경이 다운되었습니다! GitOps를 사용하면 시간이 지남에 따라 환경이 어떻게 변화했는지에 대한 완전한 기록이 있습니다. 이를 통해 git revert환경을 복원하고 복원 하는 것만 큼 오류를 쉽게 복구 할 수 있습니다.

Git 레코드는 감사 로그 일뿐만 아니라 트랜잭션 로그이기도합니다. 모든 스냅 샷으로 롤백 할 수 있습니다.

— 알렉시스 리차드슨

보다 쉬운 자격 증명 관리

GitOps를 사용하면 환경 내부에서 배포를 완전히 관리 할 수 ​​있습니다. 이를 위해 사용자 환경은 저장소 및 이미지 레지스트리에만 액세스해야합니다. 그게 다야. 개발자에게 환경에 직접 액세스 할 필요는 없습니다.

kubectl은 새로운 ssh입니다. 더 나은 툴링을 사용할 수없는 경우 액세스를 제한하고 배치에만 사용하십시오.

— 켈시 하이 타워

자체 문서화 배포

서버에 SSH로 접속하여 무엇이 실행되고 있는지 궁금한 적이 있습니까? GitOps를 사용하면 모든 환경에 대한 모든 변경 사항이 저장소를 통해 이루어져야합니다. 당신은 항상 마스터 브랜치를 체크 아웃하고 어디에 배치되었는지에 대한 완전한 설명과 시스템에 대한 모든 변경 내역을 얻을 수 있습니다. 또한 시스템의 모든 변경 사항을 무료로 감사 추적 할 수 있습니다!

팀의 공유 지식

Git을 사용하여 배포 된 인프라에 대한 완전한 설명을 저장하면 팀의 모든 사람이 시간이 지남에 따라 진화를 확인할 수 있습니다. 커밋 메시지가 커지면 누구나 인프라 변경에 대한 사고 과정을 재현하고 새로운 시스템을 설정하는 방법에 대한 예를 쉽게 찾을 수 있습니다.

코드로 구성한 이후 GitOps가 가장 좋습니다. Git은 공동 작업 방식을 변경했지만 선언적인 구성은 대규모 인프라를 다루는 열쇠이며 차세대 관리 도구를위한 단계를 설정합니다.

— 켈시 하이 타워

GitOps는 어떻게 작동합니까?

Git 리포지토리로서의 환경 구성

GitOps는 코드 리포지토리를 중심으로 배포 프로세스를 중심 요소로 구성합니다. 최소한 두 개의 저장소 (응용 프로그램 저장소 및 환경 구성 저장소)가 있습니다. 응용 프로그램 저장소에는 응용 프로그램의 소스 코드와 응용 프로그램을 배포하기위한 배포 매니페스트가 포함됩니다. 환경 구성 저장소에는 현재 원하는 배치 환경 인프라의 모든 배치 매니페스트가 포함됩니다. 배포 환경에서 어떤 구성 및 버전으로 어떤 응용 프로그램 및 인프라 서비스 (메시지 브로커, 서비스 메시, 모니터링 도구 등)를 실행해야하는지 설명합니다.

푸시 기반 및 풀 기반 배포

GitOps의 배포 전략을 구현하는 방법에는 푸시 기반 및 풀 기반 배포의 두 가지 방법이 있습니다. 두 배포 유형의 차이점은 배포 환경이 실제로 원하는 인프라와 비슷하다는 점입니다. 가능한 경우 GitOps를 구현하는 것이 더 안전하고 더 나은 방법으로 간주되므로 Pull 기반 접근 방식을 선호해야합니다.

푸시 기반 배포

푸시 기반 배포 전략은 Jenkins , CircleCI 또는 Travis CI 와 같은 널리 사용되는 CI / CD 도구로 구현됩니다 . 응용 프로그램의 소스 코드는 응용 프로그램을 배포하는 데 필요한 Kubernetes YAML과 함께 응용 프로그램 저장소 내에 있습니다. 애플리케이션 코드가 업데이트 될 때마다 빌드 파이프 라인이 트리거되어 컨테이너 이미지가 빌드되고 마지막으로 환경 구성 저장소가 새 배치 디스크립터로 업데이트됩니다.

팁 : 응용 프로그램 리포지토리에 YAML 템플릿 만 저장할 수도 있습니다. 새 버전이 빌드되면 템플리트를 사용하여 환경 구성 저장소에서 YAML을 생성 할 수 있습니다.

환경 구성 저장소를 변경하면 배치 파이프 라인이 트리거됩니다. 이 파이프 라인은 환경 구성 저장소의 모든 매니페스트를 인프라에 적용합니다. 이 방법을 사용하면 배포 환경에 자격 증명을 제공하는 것이 필수적입니다. 따라서 파이프 라인에는 갓 모드가 활성화되어 있습니다. 일부 사용 사례에서는 자동화 된 클라우드 인프라 프로비저닝을 실행할 때 푸시 기반 배포가 불가피합니다. 이러한 경우보다 제한적인 배포 권한을 위해 클라우드 공급자의 세분화 된 구성 가능한 권한 부여 시스템을 사용하는 것이 좋습니다.

이 방법을 사용할 때 명심해야 할 또 다른 중요한 사항은 환경 파이프 라인 이 변경 될 때 배치 파이프 라인 만 트리거 된다는 것 입니다. 환경과 원하는 상태의 편차를 자동으로 알 수 없습니다. 즉, 환경이 환경 저장소에 설명 된 것과 일치하지 않으면 개입 할 수 있도록 적절한 모니터링 방법이 필요합니다.

설정 방법을 알고 싶습니까? 클라우드 빌드 및 GKE를 사용하여 푸시 기반 배포를 설정하는 방법에 대한 Google 자습서 를 확인하십시오 .

풀 기반 배포

풀 기반 배포 전략은 푸시 기반 변형과 동일한 개념을 사용하지만 배포 파이프 라인 작동 방식이 다릅니다. 기존 CI / CD 파이프 라인은 외부 코드 (예 : 새 코드를 응용 프로그램 저장소로 푸시 할 때)에 의해 트리거됩니다. 풀 기반 배포 방식을 통해 운영자 가 소개됩니다. 환경 저장소의 원하는 상태를 배치 된 인프라의 실제 상태와 지속적으로 비교하여 파이프 라인의 역할을 담당합니다. 차이점이 발견 될 때마다 운영자는 환경 저장소와 일치하도록 인프라를 업데이트합니다. 또한 이미지 레지스트리를 모니터링하여 배치 할 새 버전의 이미지를 찾을 수 있습니다.

푸시 기반 배포와 마찬가지로이 변형은 환경 저장소가 변경 될 때마다 환경을 업데이트합니다. 그러나 작업자는 다른 방향으로도 변경 사항을 알 수 있습니다. 배치 된 인프라가 환경 저장소에 설명되지 않은 방식으로 변경 될 때마다 이러한 변경 사항이 되돌려집니다. 이렇게하면 클러스터에 대한 모든 직접 변경을 불가능하게하여 Git 로그에서 모든 변경을 추적 할 수 있습니다.

이러한 방향 변경은 환경 저장소가 업데이트 될 때만 환경이 업데이트되는 푸시 기반 배치의 문제점을 해결합니다. 그러나 이것이 모니터링을하지 않아도 완전히 할 수있는 것은 아닙니다. 대부분의 운영자는 컨테이너 이미지를 가져올 수없는 등 어떤 이유로 든 환경을 원하는 상태로 만들 수없는 경우 메일 또는 Slack 알림 전송을 지원합니다. 또한 자동화 배치 프로세스가 없으면 운영자 자체에 대한 모니터링을 설정해야합니다.

운영자는 항상 배포 할 응용 프로그램과 동일한 환경 또는 클러스터에 있어야합니다. 이는 배포를위한 자격 증명이 CI / CD 파이프 라인에 의해 알려진 푸시 기반 접근 방식에서 볼 수있는 갓 모드를 방지합니다. 실제 배포 인스턴스가 동일한 환경 내에있는 경우 외부 서비스에서 자격 증명을 알 필요가 없습니다. 사용중인 배치 플랫폼의 권한 부여 메커니즘을 사용하여 배치 수행에 대한 권한을 제한 할 수 있습니다. 이는 보안 측면에서 큰 영향을 미칩니다. Kubernetes를 사용하는 경우 RBAC 구성 및 서비스 계정을 활용할 수 있습니다.

---

설정 방법을 알고 싶습니까? WeaveWorks Flux를 사용하여 Google GKE에서 풀 기반 GitOps 설정에 대한 자습서를 확인하십시오 .

---

여러 응용 프로그램 및 환경 작업

물론 하나의 응용 프로그램 저장소와 하나의 환경으로 만 작업하는 것은 대부분의 응용 프로그램에서 현실적이지 않습니다. 마이크로 서비스 아키텍처를 사용하는 경우 각 서비스를 자체 저장소에 유지하려고합니다.

GitOps는 이러한 사용 사례를 처리 할 수도 있습니다. 환경 저장소를 업데이트하는 여러 빌드 파이프 라인을 항상 설정할 수 있습니다. 거기서부터 정기적 인 자동화 된 GitOps 워크 플로우가 애플리케이션의 모든 부분을 시작하고 배포합니다.

환경 저장소에서 별도의 분기를 사용하여 GitOps로 여러 환경을 관리 할 수 ​​있습니다. 프로덕션 환경에 배치하고 다른 하나를 스테이징에 배치하여 운영자 또는 배치 파이프 라인을 설정하여 한 분기의 변경 사항에 대응할 수 있습니다.