GitOps: 풀 및 푸시 방법 비교

메모. 번역: 쿠버네티스 커뮤니티에서는 GitOps라는 트렌드가 확연히 인기를 얻고 있는데, 우리가 개인적으로 본 바로는, 방문 KubeCon Europe 2019. 이 용어는 비교적 최근의 것입니다. 코인 Weaveworks의 책임자인 Alexis Richardson은 운영 문제를 해결하기 위해 개발자에게 친숙한 도구(주로 Git, 따라서 이름)를 사용한다는 의미입니다. 특히 Kubernetes의 구성을 Git에 저장하고 변경 사항을 클러스터에 자동으로 롤아웃하는 방식으로 Kubernetes를 운영하는 방법에 대해 이야기하고 있습니다. Matthias Jg는 이 문서에서 이 출시에 대한 두 가지 접근 방식에 대해 설명합니다.

작년 (사실 공식적으로 이것은 2017년 XNUMX월에 일어났습니다. - 대략 번역) Kubernetes에 애플리케이션을 배포하는 새로운 접근 방식이 있습니다. GitOps라고 불리는 이는 배포 버전이 Git 저장소의 보안 환경에서 추적된다는 기본 아이디어를 기반으로 합니다.

이 접근 방식의 주요 장점은 다음과 같습니다.:

1. 배포 버전 관리 및 변경 기록. 전체 클러스터의 상태는 Git 저장소에 저장되며 배포는 커밋을 통해서만 업데이트됩니다. 또한 커밋 기록을 사용하여 모든 변경 사항을 추적할 수 있습니다.
2. 익숙한 Git 명령을 사용한 롤백. 단순한 git reset 배포 변경 사항을 재설정할 수 있습니다. 과거 상태는 항상 사용 가능합니다.
3. 준비된 액세스 제어. 일반적으로 Git 시스템에는 민감한 데이터가 많이 포함되어 있으므로 대부분의 회사는 이를 보호하는 데 특별한 주의를 기울입니다. 따라서 이 보호는 배포 작업에도 적용됩니다.
4. 배포 정책. 대부분의 Git 시스템은 기본적으로 분기별 정책을 지원합니다. 예를 들어 풀 요청만 마스터를 업데이트할 수 있으며 변경 사항은 다른 팀 구성원이 검토하고 수락해야 합니다. 액세스 제어와 마찬가지로 배포 업데이트에도 동일한 정책이 적용됩니다.

보시다시피 GitOps 방법에는 많은 이점이 있습니다. 지난 해에는 두 가지 접근 방식이 특히 인기를 얻었습니다. 하나는 푸시 기반이고 다른 하나는 풀 기반입니다. 이를 살펴보기 전에 먼저 일반적인 Kubernetes 배포가 어떤 모습인지 살펴보겠습니다.

배포 방법

최근 몇 년 동안 Kubernetes에서는 배포를 위한 다양한 방법과 도구가 확립되었습니다.

1. 네이티브 Kubernetes/Kustomize 템플릿 기반. 이는 Kubernetes에 애플리케이션을 배포하는 가장 쉬운 방법입니다. 개발자는 기본 YAML 파일을 생성하고 적용합니다. 동일한 템플릿을 지속적으로 다시 작성하지 않기 위해 Kustomize가 개발되었습니다(Kubernetes 템플릿을 모듈로 전환). 메모. 번역: Kustomize가 kubectl에 통합되었습니다. 쿠버네티스 1.14 출시.
2. 투구 차트. Helm 차트를 사용하면 템플릿 기반 접근 방식보다 더 유연한 사용자 정의 옵션으로 애플리케이션을 배포하는 데 사용되는 템플릿 세트, 초기화 컨테이너, 사이드카 등을 만들 수 있습니다. 이 방법은 템플릿 기반 YAML 파일을 기반으로 합니다. Helm은 이를 다양한 매개변수로 채운 다음 이를 클러스터에 배포하고 업데이트 및 롤백을 허용하는 클러스터 구성 요소인 Tiller로 보냅니다. 중요한 것은 Helm은 기본적으로 원하는 값을 템플릿에 삽입한 다음 기존 접근 방식과 동일한 방식으로 적용한다는 것입니다. (작동 방식과 사용 방법에 대해 자세히 알아보세요. 헬름의 기사 - 대략. 번역). 광범위한 작업을 다루는 다양한 기성 Helm 차트가 있습니다.
3. 대체 도구. 대체 도구가 많이 있습니다. 이들 모두의 공통점은 일부 템플릿 파일을 Kubernetes에서 읽을 수 있는 YAML 파일로 변환한 다음 사용한다는 것입니다.

우리 작업에서 우리는 중요한 도구에 Helm 차트를 지속적으로 사용하고(이미 많은 것들이 준비되어 있어 삶이 훨씬 쉬워지기 때문에) 자체 애플리케이션을 배포하기 위해 "순수한" Kubernetes YAML 파일을 사용합니다.

당기기 & 밀기

최근 블로그 게시물 중 하나에서 도구를 소개했습니다. 위브 플럭스를 사용하면 Git 리포지토리에 템플릿을 커밋하고 컨테이너를 커밋하거나 푸시할 때마다 배포를 업데이트할 수 있습니다. 내 경험에 따르면 이 도구는 풀 접근 방식을 홍보하는 주요 도구 중 하나이므로 자주 참조하겠습니다. 더 자세한 사용법을 알고 싶으시면 여기를 눌러주세요 기사 링크.

주의! GitOps 사용의 모든 이점은 두 접근 방식 모두 동일하게 유지됩니다.

풀 기반 접근 방식

풀 접근 방식은 모든 변경 사항이 클러스터 내에서 적용된다는 사실을 기반으로 합니다. 클러스터 내부에는 관련 Git 및 Docker 레지스트리 리포지토리를 정기적으로 확인하는 운영자가 있습니다. 클러스터에 변경 사항이 발생하면 클러스터 상태가 내부적으로 업데이트됩니다. 외부 클라이언트가 클러스터 관리자 권한에 액세스할 수 없기 때문에 이 프로세스는 일반적으로 매우 안전한 것으로 간주됩니다.

장점 :

1. 외부 클라이언트에는 클러스터를 변경할 수 있는 권한이 없으며 모든 업데이트는 내부에서 롤아웃됩니다.
2. 일부 도구를 사용하면 Helm 차트 업데이트를 동기화하고 이를 클러스터에 연결할 수도 있습니다.
3. Docker Registry에서 새 버전을 검색할 수 있습니다. 새 이미지를 사용할 수 있으면 Git 리포지토리와 배포가 새 버전으로 업데이트됩니다.
4. 풀 도구는 다양한 Git 리포지토리 및 권한을 사용하여 다양한 네임스페이스에 배포될 수 있습니다. 덕분에 다중 테넌트 모델을 사용할 수 있습니다. 예를 들어 팀 A는 네임스페이스 A를 사용하고, 팀 B는 네임스페이스 B를 사용하고, 인프라 팀은 전역 공간을 사용할 수 있습니다.
5. 일반적으로 도구는 매우 가볍습니다.
6. 오퍼레이터 등의 툴과 결합 비트나미의 봉인된 비밀, 비밀은 Git 저장소에 암호화되어 저장되고 클러스터 내에서 검색될 수 있습니다.
7. 클러스터 내에서 배포가 발생하므로 CD 파이프라인에 대한 연결이 없습니다.

죄수 팀은:

1. Helm 차트에서 배포 비밀을 관리하는 것은 일반 비밀보다 어렵습니다. 먼저 봉인된 비밀의 형태로 생성한 다음 내부 운영자가 암호를 해독하고 그 후에야 끌어오기 도구에서 사용할 수 있게 되기 때문입니다. 그런 다음 이미 배포된 비밀의 값을 사용하여 Helm에서 릴리스를 실행할 수 있습니다. 가장 쉬운 방법은 배포에 사용되는 모든 Helm 값으로 비밀을 생성하고 이를 해독한 후 Git에 커밋하는 것입니다.
2. 당기는 접근 방식을 취하면 당기는 도구에 묶이게 됩니다. 이로 인해 클러스터의 배포 프로세스를 사용자 지정하는 기능이 제한됩니다. 예를 들어 Kustomize는 최종 템플릿이 Git에 커밋되기 전에 실행되어야 한다는 점에서 복잡합니다. 독립 실행형 도구를 사용할 수 없다는 말은 아니지만 배포 프로세스에 통합하기가 더 어렵습니다.

푸시 기반 접근 방식

푸시 접근 방식에서는 외부 시스템(주로 CD 파이프라인)이 Git 리포지토리에 커밋한 후 또는 이전 CI 파이프라인이 성공한 경우 클러스터에 대한 배포를 시작합니다. 이 접근 방식에서는 시스템이 클러스터에 액세스할 수 있습니다.

프로:

1. 보안은 Git 리포지토리와 빌드 파이프라인에 따라 결정됩니다.
2. Helm 차트 배포가 더 쉽고 Helm 플러그인을 지원합니다.
3. 비밀은 파이프라인에서 사용될 수 있고 사용자의 기본 설정에 따라 Git에 암호화되어 저장될 수도 있으므로 관리하기가 더 쉽습니다.
4. 모든 유형을 사용할 수 있으므로 특정 도구에 대한 연결은 없습니다.
5. 컨테이너 버전 업데이트는 빌드 파이프라인을 통해 시작될 수 있습니다.

죄수 팀은:

1. 클러스터 액세스 데이터는 빌드 시스템 내부에 있습니다.
2. 풀 프로세스를 사용하면 배포 컨테이너를 업데이트하는 것이 더 쉽습니다.
3. 우리에게 필요한 파이프라인은 원래 Gitlab Runner용으로 작성되었을 수 있으므로 CD 시스템에 대한 의존도가 높습니다. 그런 다음 팀은 Azure DevOps 또는 Jenkins로 이동하기로 결정하고... 수많은 빌드 파이프라인을 마이그레이션해야 합니다.

결과: 밀거나 당길 것인가?

일반적으로 그렇듯이 각 접근 방식에는 장단점이 있습니다. 일부 작업은 한 가지 작업을 수행하는 것이 더 쉽고 다른 작업을 수행하는 것은 더 어렵습니다. 처음에는 수동으로 배포를 진행했지만 Weave Flux에 대한 몇 가지 기사를 접한 후 모든 프로젝트에 GitOps 프로세스를 구현하기로 결정했습니다. 기본 템플릿의 경우 이는 쉬웠지만 Helm 차트에 어려움을 겪기 시작했습니다. 당시 Weave Flux는 Helm Chart Operator의 초보적인 버전만 제공했지만 지금도 비밀을 수동으로 생성하고 적용해야 하기 때문에 일부 작업이 더 어렵습니다. 클러스터의 자격 증명은 클러스터 외부에서 액세스할 수 없기 때문에 끌어오기 접근 방식이 훨씬 더 안전하고 추가 노력을 기울일 가치가 있을 정도로 훨씬 더 안전하다고 주장할 수 있습니다.

고민 끝에 나는 그렇지 않다는 뜻밖의 결론에 이르렀다. 최대한의 보호가 필요한 구성 요소에 관해 이야기한다면 이 목록에는 비밀 저장소, CI/CD 시스템 및 Git 리포지토리가 포함됩니다. 그 안에 있는 정보는 매우 취약하며 최대한의 보호가 필요합니다. 또한 누군가 Git 리포지토리에 들어가서 코드를 푸시할 수 있다면 원하는 것은 무엇이든(풀이든 푸시든) 배포하고 클러스터 시스템에 침투할 수 있습니다. 따라서 보호해야 할 가장 중요한 구성 요소는 클러스터 자격 증명이 아니라 Git 저장소와 CI/CD 시스템입니다. 이러한 유형의 시스템에 대해 잘 구성된 정책과 보안 제어가 있고 클러스터 자격 증명이 파이프라인에 비밀로만 추출되는 경우 풀 접근 방식의 추가 보안은 원래 생각만큼 가치가 없을 수 있습니다.

그렇다면 풀 접근 방식이 더 노동 집약적이고 보안 이점을 제공하지 않는다면 푸시 접근 방식만 사용하는 것이 논리적이지 않습니까? 그러나 누군가는 푸시 접근 방식에서는 CD 시스템에 너무 묶여 있으므로 나중에 마이그레이션을 더 쉽게 수행할 수 있도록 이렇게 하지 않는 것이 더 나을 것이라고 주장할 수도 있습니다.

제 생각에는 (언제나 그렇듯이) 특정 경우에 가장 적합한 것을 사용하거나 조합하는 것이 좋습니다. 개인적으로 저는 두 가지 접근 방식을 모두 사용합니다. 주로 자체 서비스를 포함하는 풀 기반 배포를 위한 Weave Flux와 Helm 차트를 클러스터에 쉽게 적용하고 비밀을 원활하게 생성할 수 있는 Helm 및 플러그인을 사용하는 푸시 접근 방식입니다. 항상 많은 뉘앙스가 있고 특정 애플리케이션에 따라 달라지기 때문에 모든 경우에 적합한 단일 솔루션은 없다고 생각합니다. 즉, 저는 GitOps를 적극 권장합니다. GitOps는 삶을 훨씬 쉽게 만들고 보안을 향상시킵니다.

이 주제에 대한 제 경험이 귀하의 배포 유형에 더 적합한 방법을 결정하는 데 도움이 되기를 바라며 귀하의 의견을 듣고 싶습니다.

PS 번역가의 메모

풀 모델의 단점은 렌더링된 매니페스트를 Git에 넣기가 어렵다는 것입니다. 그러나 풀 모델의 CD 파이프라인은 롤아웃과 별도로 존재하며 기본적으로 카테고리 파이프라인이 된다는 단점은 없습니다. 지속적인 적용. 따라서 모든 배포에서 해당 상태를 수집하고 어떻게든 CD 시스템을 참조하여 로그/상태에 대한 액세스를 제공하려면 훨씬 더 많은 노력이 필요합니다.

이러한 의미에서 푸시 모델을 사용하면 파이프라인의 수명이 롤아웃의 수명과 동일해질 수 있기 때문에 적어도 일부 롤아웃을 보장할 수 있습니다.

우리는 두 모델을 모두 시험해 본 결과 기사 작성자와 동일한 결론에 도달했습니다.

1. 풀 모델은 다수의 클러스터에서 시스템 구성 요소의 업데이트를 구성하는 데 적합합니다(참조: 애드온 연산자에 관한 기사).
2. GitLab CI 기반 푸시 모델은 Helm 차트를 사용하여 애플리케이션을 출시하는 데 매우 적합합니다. 동시에 도구를 사용하여 파이프라인 내 배포 롤아웃을 모니터링합니다. 워프. 그건 그렇고, 우리 프로젝트의 맥락에서 우리는 KubeCon Europe'19에서 DevOps 엔지니어의 시급한 문제를 논의할 때 끊임없는 "GitOps"를 들었습니다.

번역가의 PPS

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

• «Kubernetes 팁 및 요령: 클러스터에서 실행 중인 리소스를 Helm 2 관리로 전송";
• «Kubernetes 리소스 모니터링을 위한 kubedog 라이브러리 소개";
• «Kubernetes 확장 및 보완(개요 및 동영상 보고서)";
• «GitLab CI에서 사용자 정의 워크플로를 생성하기 위한 팁".

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

GitOps를 사용하고 있나요?

• 예, 풀 접근 방식입니다.

• 응, 밀어

• 예, 당기기 + 밀기

• 응, 다른 거 말이야

• 아니

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

출처 : habr.com