🥇GitOps란 무엇인가요?

메모. 번역: 최근 출판 이후 자료 GitOps의 풀 및 푸시 방법에 대해 우리는 일반적으로 이 모델에 대한 관심을 보았지만 이 주제에 대한 러시아어 출판물은 거의 없었습니다(Habré에 관한 출판물은 전혀 없습니다). 따라서 우리는 비록 거의 XNUMX년 전이지만 다른 기사의 번역을 여러분의 관심에 제공하게 된 것을 기쁘게 생각합니다! — "GitOps"라는 용어를 만든 Weaveworks에서. 본문에서는 접근 방식의 본질과 기존 접근 방식과의 주요 차이점을 설명합니다.

XNUMX년 전에 우리는 출판했습니다. GitOps 소개. 당시 우리는 Weaveworks 팀이 완전히 Kubernetes를 기반으로 SaaS를 출시하고 클라우드 네이티브 환경에서 배포, 관리 및 모니터링하기 위한 일련의 규범적인 모범 사례를 개발한 방법을 공유했습니다.

해당 기사가 인기를 얻었습니다. 다른 사람들은 GitOps에 대해 이야기하기 시작했고 GitOps를 위한 새로운 도구를 게시하기 시작했습니다. git push, 발전, 비밀, 기능들, 지속적인 통합 등등. 우리 웹사이트에 등장했어요 다수 출판물 및 GitOps 사용 사례. 그러나 어떤 사람들은 여전히 질문을 가지고 있습니다. 이 모델은 기존 모델과 어떻게 다른가요? 코드로서의 인프라 지속적인 전달(지속적인 배달)? Kubernetes를 사용해야 하나요?

우리는 곧 다음과 같은 새로운 설명이 필요하다는 것을 깨달았습니다.

수많은 사례와 이야기;
GitOps의 구체적인 정의
기존 지속적 전달과 비교.

이 기사에서 우리는 이러한 모든 주제를 다루려고 노력했습니다. GitOps에 대한 업데이트된 소개와 개발자 및 CI/CD 관점을 제공합니다. 모델이 일반화될 수 있지만 우리는 주로 Kubernetes에 중점을 둡니다.

GitOps를 만나보세요

앨리스를 상상해 보세요. 그녀는 너무 바빠서 계약 내용을 직접 파악할 수 없는 사람들에게 건강, 자동차, 주택 및 여행 보험을 제공하는 가족 보험(Family Insurance)을 운영하고 있습니다. 그녀의 사업은 Alice가 은행에서 데이터 과학자로 일할 때 사이드 프로젝트로 시작되었습니다. 어느 날 그녀는 고급 컴퓨터 알고리즘을 사용하여 데이터를 보다 효과적으로 분석하고 보험 패키지를 구성할 수 있다는 것을 깨달았습니다. 투자자들이 이 프로젝트에 자금을 지원했고, 이제 그녀의 회사는 연간 20천만 달러 이상을 벌어들이며 빠르게 성장하고 있습니다. 현재 다양한 직위에서 180명의 직원을 고용하고 있습니다. 여기에는 웹 사이트, 데이터베이스를 개발, 유지 관리하고 고객 기반을 분석하는 기술 팀이 포함됩니다. 60명으로 구성된 팀은 회사의 기술 이사인 Bob이 이끌고 있습니다.

Bob의 팀은 클라우드에 프로덕션 시스템을 배포합니다. 핵심 애플리케이션은 GKE에서 실행되며 Google Cloud의 Kubernetes를 활용합니다. 또한 그들은 업무에 다양한 데이터 및 분석 도구를 사용합니다.

Family Insurance는 컨테이너 사용에 착수하지 않았지만 Docker 열정에 사로잡혔습니다. 회사는 GKE를 사용하면 클러스터를 쉽게 배포하여 새로운 기능을 테스트할 수 있다는 사실을 곧 알게 되었습니다. 컨테이너 레지스트리를 구성하기 위해 CI 및 Quay용 Jenkins가 추가되었으며, 새 컨테이너와 구성을 GKE에 푸시하는 Jenkins용 스크립트가 작성되었습니다.

시간이 좀 지났습니다. Alice와 Bob은 자신들이 선택한 접근 방식의 성과와 그것이 비즈니스에 미치는 영향에 실망했습니다. 컨테이너를 도입해도 팀이 기대했던 만큼 생산성이 향상되지는 않았습니다. 때때로 배포가 중단되고 코드 변경이 원인인지 여부가 불분명했습니다. 또한 구성 변경 사항을 추적하는 것도 어려운 것으로 나타났습니다. 새 클러스터를 생성하고 애플리케이션을 그 클러스터로 이동해야 하는 경우가 많았는데, 이것이 시스템의 혼란을 제거하는 가장 쉬운 방법이었기 때문입니다. Alice는 애플리케이션이 개발됨에 따라 상황이 더욱 악화될 것을 두려워했습니다(또한 기계 학습을 기반으로 한 새로운 프로젝트가 준비 중이었습니다). Bob은 대부분의 작업을 자동화했는데 왜 파이프라인이 여전히 불안정하고, 확장이 잘 안 되고, 주기적으로 수동 개입이 필요한지 이해하지 못하셨나요?

그런 다음 GitOps에 대해 배웠습니다. 이 결정은 그들이 자신감 있게 앞으로 나아가는 데 꼭 필요한 결정이었습니다.

Alice와 Bob은 수년 동안 Git, DevOps 및 코드 워크플로로서의 인프라에 대해 들어왔습니다. GitOps의 독특한 점은 Kubernetes의 맥락에서 이러한 아이디어를 구현하기 위한 일련의 명확하고 규범적인 모범 사례를 제공한다는 것입니다. 이 테마 반복해서 장미, 포함 위브웍스 블로그.

Family Insurance는 GitOps를 구현하기로 결정했습니다. 이제 회사는 Kubernetes와 호환되고 다음을 결합한 자동화된 운영 모델을 보유하고 있습니다. 속도 과 안정왜냐하면 그들은:

누구도 미쳐버리지 않고 팀의 생산성이 두 배로 증가했다는 사실을 발견했습니다.
스크립트 제공을 중지했습니다. 대신 이제 새로운 기능에 집중하고 엔지니어링 방법을 개선할 수 있습니다. 예를 들어 카나리아 출시 및 테스트 개선 등이 있습니다.
우리는 배포 프로세스가 거의 중단되지 않도록 개선했습니다.
부분적인 실패 후 수동 개입 없이 배포를 복원할 수 있는 기회를 얻었습니다.
구입한 중고о배송 시스템에 대한 신뢰도가 높아졌습니다. Alice와 Bob은 팀을 병렬로 작업하는 마이크로서비스 팀으로 나눌 수 있다는 것을 발견했습니다.
각 그룹의 노력을 통해 매일 프로젝트를 30~50개 변경하고 새로운 기술을 시도할 수 있습니다.
몇 시간 내에 끌어오기 요청을 사용하여 프로덕션 업데이트를 출시할 수 있는 기회를 가진 새로운 개발자를 프로젝트에 쉽게 유치할 수 있습니다.
SOC2 프레임워크 내에서 쉽게 감사를 통과합니다. (서비스 제공업체의 안전한 데이터 관리 요구 사항 준수를 위해, 자세한 내용은 다음과 같습니다. 여기에 - 대략. 번역).

무슨 일이 있었죠?

GitOps는 두 가지입니다.

Kubernetes 및 클라우드 네이티브를 위한 운영 모델입니다. 컨테이너화된 클러스터와 애플리케이션을 배포, 관리, 모니터링하기 위한 일련의 모범 사례를 제공합니다. 형식의 우아한 정의 슬라이드 하나 부터 루이스 파세이라:
개발자 중심의 애플리케이션 관리 환경을 구축하는 경로입니다. 우리는 운영과 개발 모두에 Git 워크플로우를 적용합니다. 이는 단지 Git 푸시에 관한 것이 아니라 전체 CI/CD 및 UI/UX 도구 세트를 구성하는 것에 관한 것입니다.

Git에 대한 몇 마디

버전 제어 시스템과 Git 기반 워크플로우에 익숙하지 않다면 이에 대해 학습하는 것이 좋습니다. 브랜치 및 끌어오기 요청 작업은 처음에는 흑마법처럼 보일 수 있지만 노력한 만큼의 이점을 얻을 수 있습니다. 여기 좋은 기사 시작한다.

Kubernetes 작동 방식

우리 이야기에서 Alice와 Bob은 한동안 Kubernetes로 작업한 후 GitOps로 전환했습니다. 실제로 GitOps는 Kubernetes와 밀접한 관련이 있습니다. 이는 Kubernetes 기반 인프라 및 애플리케이션을 위한 운영 모델입니다.

Kubernetes는 사용자에게 무엇을 제공합니까?

다음은 몇 가지 주요 기능입니다.

Kubernetes 모델에서는 모든 것을 선언적 형식으로 설명할 수 있습니다.
Kubernetes API 서버는 이 선언을 입력으로 받아들인 다음 클러스터를 선언에 설명된 상태로 만들기 위해 지속적으로 시도합니다.
선언은 다양한 워크로드, 즉 "애플리케이션"을 설명하고 관리하는 데 충분합니다.
결과적으로 다음과 같은 이유로 애플리케이션과 클러스터가 변경됩니다.
- 컨테이너 이미지의 변경;
- 선언적 사양 변경
- 환경 오류(예: 컨테이너 충돌)

Kubernetes의 뛰어난 융합 기능

관리자가 구성을 변경하면 Kubernetes 오케스트레이터는 상태가 다음과 같은 한 이를 클러스터에 적용합니다. 새로운 구성에 근접하지 않을 것입니다. 이 모델은 모든 Kubernetes 리소스에 대해 작동하며 CRD(사용자 정의 리소스 정의)로 확장 가능합니다. 따라서 Kubernetes 배포에는 다음과 같은 훌륭한 속성이 있습니다.

오토메이션: Kubernetes 업데이트는 변경 사항을 적시에 적절하게 적용하는 프로세스를 자동화하는 메커니즘을 제공합니다.
수렴: Kubernetes는 성공할 때까지 계속 업데이트를 시도합니다.
멱등성: 융합을 반복적으로 적용하면 같은 결과가 나온다.
결정론: 리소스가 충분하면 업데이트된 클러스터의 상태는 원하는 상태에만 의존합니다.

GitOps 작동 방식

GitOps의 작동 방식을 설명하기 위해 Kubernetes에 대해 충분히 배웠습니다.

Family Insurance의 마이크로서비스 팀으로 돌아가 보겠습니다. 그들은 보통 무엇을 해야 합니까? 아래 목록을 살펴보세요. (혹시 낯설거나 낯설게 보이는 항목이 있으면 비판을 잠시 멈추고 함께해주세요.) 이는 Jenkins 기반 워크플로의 예일 뿐입니다. 다른 도구로 작업할 때 다른 프로세스도 많이 있습니다.

가장 중요한 점은 각 업데이트가 구성 파일 및 Git 리포지토리의 변경으로 끝나는 것을 확인한다는 것입니다. Git에 대한 이러한 변경으로 인해 "GitOps 운영자"가 클러스터를 업데이트합니다.

1.작업 과정: "Jenkins 빌드 - 마스터 브랜치".
작업 목록:

Jenkins는 태그된 이미지를 Quay에 푸시합니다.
Jenkins는 구성 및 Helm 차트를 마스터 스토리지 버킷에 푸시합니다.
클라우드 기능은 마스터 스토리지 버킷의 구성과 차트를 마스터 Git 저장소로 복사합니다.
GitOps 운영자가 클러스터를 업데이트합니다.

2. Jenkins 빌드 - 릴리스 또는 핫픽스 분기:

Jenkins는 태그가 지정되지 않은 이미지를 Quay로 푸시합니다.
Jenkins는 구성 및 Helm 차트를 스테이징 스토리지 버킷에 푸시합니다.
클라우드 기능은 스테이징 스토리지 버킷의 구성 및 차트를 스테이징 Git 저장소로 복사합니다.
GitOps 운영자가 클러스터를 업데이트합니다.

3. Jenkins 빌드 - 브랜치 개발 또는 기능:

Jenkins는 태그가 지정되지 않은 이미지를 Quay로 푸시합니다.
Jenkins는 구성 및 Helm 차트를 개발 스토리지 버킷에 푸시합니다.
클라우드 기능은 개발 스토리지 버킷의 구성 및 차트를 개발 Git 저장소로 복사합니다.
GitOps 운영자가 클러스터를 업데이트합니다.

4. 새 클라이언트 추가:

관리자(LCM/ops)는 Gradle을 호출하여 초기에 네트워크 로드 밸런서(NLB)를 배포하고 구성합니다.
LCM/ops는 업데이트 배포를 준비하기 위해 새 구성을 커밋합니다.
GitOps 운영자가 클러스터를 업데이트합니다.

GitOps에 대한 간략한 설명

각 환경에 대한 선언적 사양을 사용하여 전체 시스템의 원하는 상태를 설명합니다(이 이야기에서는 Bob의 팀이 Git에서 전체 시스템 구성을 정의합니다).
- Git 저장소는 전체 시스템의 원하는 상태에 관한 단일 정보 소스입니다.
- 원하는 상태에 대한 모든 변경은 Git의 커밋을 통해 이루어집니다.
- 원하는 모든 클러스터 매개변수는 클러스터 자체에서도 관찰할 수 있습니다. 이러한 방식으로 우리는 그것들이 일치하는지(수렴, 모이다) 또는 다릅니다 (발산, 분기하다) 원하는 상태와 관찰된 상태.
원하는 상태와 관찰된 상태가 다른 경우:
- 조만간 대상 상태와 관찰된 상태를 자동으로 동기화하는 수렴 메커니즘이 있습니다. 클러스터 내에서 Kubernetes는 이 작업을 수행합니다.
- 프로세스는 "변경 커밋" 경고와 함께 즉시 시작됩니다.
- 구성 가능한 일정 기간이 지난 후 상태가 다른 경우 "diff" 경고가 전송될 수 있습니다.
이런 방식으로 Git의 모든 커밋은 클러스터에 대해 검증 가능하고 멱등적인 업데이트를 발생시킵니다.
- 롤백은 이전에 원하는 상태로 수렴하는 것입니다.
수렴은 최종적입니다. 그 발생은 다음과 같이 표시됩니다.
- 특정 기간 동안 차이 알림이 표시되지 않습니다.
- "수렴형" 경고(예: 웹훅, Git 쓰기 저장 이벤트).

다이버전스란 무엇인가?

다시 반복해 보겠습니다. 원하는 모든 클러스터 속성은 클러스터 자체에서 관찰 가능해야 합니다..

발산의 몇 가지 예:

Git의 브랜치 병합으로 인해 구성 파일이 변경되었습니다.
GUI 클라이언트의 Git 커밋으로 인해 구성 파일이 변경되었습니다.
Git의 PR로 인해 원하는 상태가 여러 번 변경된 후 컨테이너 이미지가 빌드되고 구성이 변경되었습니다.
오류로 인한 클러스터 상태 변경, "잘못된 동작"을 초래하는 리소스 충돌 또는 단순히 원래 상태에서 무작위로 벗어난 경우입니다.

수렴 메커니즘은 무엇입니까?

몇 가지 예 :

컨테이너와 클러스터의 경우 Kubernetes에서 수렴 메커니즘을 제공합니다.
동일한 메커니즘을 사용하여 Kubernetes 기반 애플리케이션 및 디자인(예: Istio 및 Kubeflow)을 관리할 수 있습니다.
Kubernetes, 이미지 저장소 및 Git 간의 운영 상호 작용을 관리하는 메커니즘은 다음을 제공합니다. GitOps 운영자 Weave Flux, 이는 일부입니다 위브 클라우드.
기본 머신의 경우 수렴 메커니즘은 선언적이고 자율적이어야 합니다. 우리 자신의 경험을 통해 다음과 같이 말할 수 있습니다. 테라 폼 이 정의에 가장 가깝지만 여전히 인간의 통제가 필요합니다. 이러한 의미에서 GitOps는 코드형 인프라의 전통을 확장합니다.

GitOps는 Git과 Kubernetes의 탁월한 융합 엔진을 결합하여 활용 모델을 제공합니다.

GitOps를 사용하면 다음과 같이 말할 수 있습니다. 설명하고 관찰할 수 있는 시스템만 자동화하고 제어할 수 있습니다..

GitOps는 전체 클라우드 네이티브 스택(예: Terraform 등)을 대상으로 합니다.

GitOps는 단순한 Kubernetes가 아닙니다. 우리는 전체 시스템이 선언적으로 구동되고 수렴을 사용하기를 원합니다. 전체 시스템이란 Kubernetes와 함께 작동하는 환경 모음을 의미합니다(예: "개발 클러스터 1", "프로덕션" 등). 각 환경에는 시스템, 클러스터, 애플리케이션은 물론 데이터, 모니터링을 제공하는 외부 서비스용 인터페이스가 포함됩니다. 등등

이 경우 부트스트래핑 문제에 Terraform이 얼마나 중요한지 확인하세요. Kubernetes는 어딘가에 배포되어야 하며 Terraform을 사용한다는 것은 동일한 GitOps 워크플로를 적용하여 Kubernetes와 애플리케이션을 뒷받침하는 제어 계층을 생성할 수 있음을 의미합니다. 이는 유용한 모범 사례입니다.

Kubernetes 위에 있는 레이어에 GitOps 개념을 적용하는 데 중점을 두고 있습니다. 현재 Istio, Helm, Ksonnet, OpenFaaS 및 Kubeflow를 위한 GitOps 유형 솔루션이 있으며, 예를 들어 클라우드 네이티브용 애플리케이션 개발을 위한 계층을 생성하는 Pulumi용 솔루션도 있습니다.

Kubernetes CI/CD: GitOps와 다른 접근 방식 비교

언급했듯이 GitOps는 두 가지입니다.

위에서 설명한 Kubernetes 및 클라우드 네이티브의 운영 모델입니다.
개발자 중심 애플리케이션 관리 환경으로 가는 길.

많은 경우 GitOps는 주로 Git 푸시를 기반으로 하는 워크플로입니다. 우리도 그를 좋아해요. 하지만 그게 다가 아닙니다. 이제 CI/CD 파이프라인을 살펴보겠습니다.

GitOps를 사용하면 Kubernetes에 대한 CD(지속적 배포)가 가능합니다.

GitOps는 별도의 "배포 관리 시스템"이 필요 없는 지속적인 배포 메커니즘을 제공합니다. Kubernetes는 사용자를 위해 모든 작업을 수행합니다.

애플리케이션을 업데이트하려면 Git에서 업데이트해야 합니다. 이는 원하는 상태에 대한 트랜잭션 업데이트입니다. 그런 다음 업데이트된 설명을 기반으로 Kubernetes 자체에 의해 클러스터 내에서 "배포"가 수행됩니다.
Kubernetes 작동 방식의 특성으로 인해 이러한 업데이트는 수렴됩니다. 이는 모든 업데이트가 원자성인 지속적인 배포를 위한 메커니즘을 제공합니다.
참고 : 위브 클라우드 Git과 Kubernetes를 통합하고 클러스터의 원하는 상태와 현재 상태를 조정하여 CD를 수행할 수 있는 GitOps 연산자를 제공합니다.

kubectl 및 스크립트 없이

클러스터를 업데이트하기 위해 Kubectl을 사용하는 것을 피해야 하며, 특히 kubectl 명령을 그룹화하기 위해 스크립트를 사용하는 것을 피해야 합니다. 대신 GitOps 파이프라인을 사용하면 사용자가 Git을 통해 Kubernetes 클러스터를 업데이트할 수 있습니다.

혜택은 다음과 같습니다.

오른쪽. 일련의 업데이트를 적용하고 수렴하고 최종적으로 검증할 수 있어 원자 배포 목표에 더 가까워질 수 있습니다. 대조적으로, 스크립트를 사용하면 수렴이 보장되지 않습니다(자세한 내용은 아래 참조).
Безопасность. 인용 Kelsey Hightower: "Kubernetes 클러스터에 대한 액세스를 자동화 도구와 디버깅 또는 유지 관리를 담당하는 관리자로 제한하세요." 또한보십시오 내 출판물 안전 및 기술 사양 준수에 관한 것뿐만 아니라 Homebrew 해킹에 관한 기사 부주의하게 작성된 Jenkins 스크립트에서 자격 증명을 훔쳐서.
사용자 경험. Kubectl은 상당히 복잡한 Kubernetes 개체 모델의 메커니즘을 공개합니다. 이상적으로는 사용자가 더 높은 추상화 수준에서 시스템과 상호 작용해야 합니다. 여기서 다시 Kelsey를 언급하고 시청을 권장합니다. 그런 이력서.

CI와 CD의 차이점

GitOps는 기존 CI/CD 모델을 개선합니다.

최신 CI 서버는 오케스트레이션 도구입니다. 특히 CI 파이프라인을 조정하기 위한 도구입니다. 여기에는 빌드, 테스트, 트렁크로 병합 등이 포함됩니다. CI 서버는 복잡한 다단계 파이프라인 관리를 자동화합니다. 일반적인 유혹은 Kubernetes 업데이트 세트를 스크립팅하고 이를 파이프라인의 일부로 실행하여 변경 사항을 클러스터에 푸시하는 것입니다. 실제로 많은 전문가들이 이렇게 하고 있습니다. 그러나 이는 최적이 아니며 그 이유는 다음과 같습니다.

CI를 사용하여 업데이트를 트렁크에 푸시해야 하며, Kubernetes 클러스터는 해당 업데이트를 기반으로 자체적으로 변경하여 CD를 내부적으로 관리해야 합니다. 우리는 그것을 부른다 CD용 풀 모델, CI 푸시 모델과 다릅니다. CD는 일부 런타임 오케스트레이션.

CI 서버가 Kubernetes의 직접 업데이트를 통해 CD를 수행하면 안되는 이유

CI 작업 세트로 Kubernetes에 대한 직접 업데이트를 조정하기 위해 CI 서버를 사용하지 마십시오. 이것이 우리가 말하는 안티패턴이다 이미 말했다 당신의 블로그에.

앨리스와 밥의 이야기로 돌아가 보겠습니다.

그들은 어떤 문제에 직면했습니까? Bob의 CI 서버는 변경 사항을 클러스터에 적용하지만 프로세스 중에 충돌이 발생하는 경우 Bob은 클러스터가 어떤 상태인지(또는 있어야 하는지) 또는 이를 수정하는 방법을 알 수 없습니다. 성공할 경우에도 마찬가지이다.

Bob의 팀이 새 이미지를 구축한 다음 배포를 패치하여 이미지를 배포한다고 가정해 보겠습니다(모두 CI 파이프라인에서).

이미지가 정상적으로 빌드되었지만 파이프라인이 실패하는 경우 팀은 다음 사항을 파악해야 합니다.

업데이트가 출시되었나요?
새로운 빌드를 출시하나요? 이로 인해 동일한 불변 이미지의 두 빌드가 발생할 가능성과 함께 불필요한 부작용이 발생합니까?
빌드를 실행하기 전에 다음 업데이트를 기다려야 합니까?
정확히 무엇이 잘못되었나요? 어떤 단계를 반복해야 합니까(그리고 어떤 단계를 반복해도 안전합니까)?

Git 기반 워크플로를 설정한다고 해서 Bob의 팀이 이러한 문제에 직면하지 않는다는 보장은 없습니다. 커밋 푸시, 태그 또는 기타 매개변수를 사용하여 여전히 실수를 할 수 있습니다. 그러나 이 접근 방식은 여전히 명시적인 전부 아니면 전무 접근 방식에 훨씬 더 가깝습니다.

요약하면 CI 서버가 CD를 처리하면 안되는 이유는 다음과 같습니다.

업데이트 스크립트가 항상 결정적이지는 않습니다. 실수하기 쉽습니다.
CI 서버는 선언적 클러스터 모델로 수렴되지 않습니다.
멱등성을 보장하기는 어렵습니다. 사용자는 시스템의 깊은 의미를 이해해야 합니다.
부분적인 실패로부터 복구하는 것이 더 어렵습니다.

Helm에 대한 참고 사항: Helm을 사용하려면 다음과 같은 GitOps 연산자와 결합하는 것이 좋습니다. 플럭스헬름. 이는 수렴을 보장하는 데 도움이 됩니다. Helm 자체는 결정적이지도 원자적이지도 않습니다.

Kubernetes용 지속적 전달을 구현하는 가장 좋은 방법인 GitOps

Alice와 Bob의 팀은 GitOps를 구현하고 소프트웨어 제품으로 작업하고 높은 성능과 안정성을 유지하는 것이 훨씬 쉬워졌다는 사실을 발견했습니다. 그들의 새로운 접근 방식이 어떤 것인지 보여주는 그림으로 이 기사를 마무리하겠습니다. 우리는 주로 애플리케이션과 서비스에 대해 이야기하고 있지만 GitOps는 전체 플랫폼을 관리하는 데 사용될 수 있다는 점을 명심하세요.

Kubernetes의 운영 모델

다음 다이어그램을보십시오. 이는 Git과 컨테이너 이미지 저장소를 두 가지 조정된 수명 주기에 대한 공유 리소스로 제공합니다.

Git에서 파일을 읽고 쓰고 컨테이너 이미지 저장소를 업데이트할 수 있는 지속적인 통합 파이프라인입니다.
배포와 관리 및 관찰 기능을 결합한 런타임 GitOps 파이프라인입니다. Git에서 파일을 읽고 쓰고 컨테이너 이미지를 다운로드할 수 있습니다.

주요 결과는 무엇입니까?

우려의 분리: 두 파이프라인 모두 Git 또는 이미지 저장소를 업데이트해야만 통신할 수 있습니다. 즉, CI와 런타임 환경 사이에 방화벽이 있습니다. 우리는 이를 "불변성 방화벽"이라고 부릅니다. (불변성 방화벽), 모든 저장소 업데이트는 새 버전을 생성하기 때문입니다. 이 주제에 대한 자세한 내용은 슬라이드 72-87을 참조하십시오. 이 프레젠테이션.
모든 CI 및 Git 서버를 사용할 수 있습니다.: GitOps는 모든 구성요소와 작동합니다. 선호하는 CI 및 Git 서버, 이미지 저장소, 테스트 제품군을 계속 사용할 수 있습니다. 시중에 나와 있는 거의 모든 다른 Continuous Delivery 도구에는 자체 CI/Git 서버 또는 이미지 저장소가 필요합니다. 이는 클라우드 네이티브 개발에 제한 요소가 될 수 있습니다. GitOps를 사용하면 친숙한 도구를 사용할 수 있습니다.
통합 도구로서의 이벤트: Git의 데이터가 업데이트되는 즉시 Weave Flux(또는 Weave Cloud 운영자)가 런타임에 이를 알립니다. Kubernetes가 변경 세트를 수락할 때마다 Git이 업데이트됩니다. 이는 아래와 같이 GitOps의 워크플로를 구성하기 위한 간단한 통합 모델을 제공합니다.

결론

GitOps는 최신 CI/CD 도구에 필요한 강력한 업데이트 보장을 제공합니다.

오토메이션;
수렴;
멱등성;
결정론.

이는 클라우드 네이티브 개발자를 위한 운영 모델을 제공하기 때문에 중요합니다.

시스템 관리 및 모니터링을 위한 기존 도구는 Runbook 내에서 운영되는 운영 팀과 연결됩니다. (일련의 절차 및 작업 세트 - 대략적인 번역), 특정 배포와 연결됩니다.
클라우드 네이티브 관리에서 관찰 가능성 도구는 개발 팀이 신속하게 대응할 수 있도록 배포 결과를 측정하는 가장 좋은 방법입니다.

자체 팀과 배포 계획을 갖춘 다양한 클라우드와 다양한 서비스에 분산된 많은 클러스터를 상상해 보세요. GitOps는 이러한 모든 풍부함을 관리하기 위한 규모 불변 모델을 제공합니다.

번역가의 추신

블로그에서도 읽어보세요.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

이 두 가지 번역이 Habré에 게재되기 전에 GitOps에 대해 알고 계셨나요?

응, 난 다 알고 있었어
표면적으로만
아니

35명의 사용자가 투표했습니다. 10명의 사용자가 기권했습니다.

출처 : habr.com

GitOps란 무엇입니까?