이 기사에서는 인프라 구성 관리의 개념인 GitOps와 그 과제에 대해 설명합니다. GitOps는 일관성, 보안 및 자동화 이점으로 유명합니다. 인프라 및 애플리케이션 코드 관리를 위해 Git 리포지토리를 활용합니다. 이 기사에서는 GitOps 원칙, Flux 아키텍처 및 Flux와 함께 Helm 사용에 대해 설명합니다. GitOps가 복잡한 종속성을 관리하고 단일 정보 소스를 유지하는 데 얼마나 부족한지 강조합니다. 다음 부분에서는 여러 환경, 비밀, 보안, 롤백 및 적용 가능성과 같은 문제를 다룹니다.
새로운 항공사에서.스튜어디스가 객실에 들어갑니다. "당신은 우리의 새로운 항공사에 있습니다. 항공기 기수에는 영화관이 있습니다. 꼬리 부분에는 슬롯머신 홀이 있습니다. 아래쪽 데크에는 수영장이 있습니다. 상부 데크 - 사우나 자 여러분, 안전벨트를 매시고 불필요한 것들을 모두 이륙해 보겠습니다.
안녕하세요, 제 이름은 안드리입니다. 저는 평생 동안 IT 업계에서 일해 왔습니다. 저는 인프라 구성 관리 엔지니어링의 발전에 매우 관심이 있습니다. 지난 8년 동안 저는 DevOps 에 참여해 왔습니다.
새로운 인기 트렌드 중 하나는 Weaveworks의 CEO인 Alexis Richardson이 2017년에 도입한 GitOps 개념입니다. Weaveworks는 2020년에 GitOps 개발을 위해 3,600만 달러 이상의 투자를 유치한 대규모 성인 회사입니다.
이전 기사에서는 Elastic Stack에서 Grafana로 전환한 방법에 대한 비용 절감 성공 사례를 논의했습니다. 이제 저는 이 개념을 채택할 때 발생할 수 있는 분명하지 않은 문제에 대해 이야기하려고 합니다. 간단히 말해서 GitOps는 "실버 총알"이 아닙니다. 많은 복잡한 해결 방법을 사용하여 재구성하게 될 가능성이 높습니다. 나는 직접 이 길을 걸어왔고 GitOps에 대한 다른 기사를 읽을 때 볼 수 없는 가장 실망스러운 문제를 보여주고 싶습니다.
콘텐츠 개요
GitOps가 무엇이며 왜 필요하지 않습니까?
눈송이 서버 문제
GitOps - 모든 문제에 대한 만병통치약(또는 그렇지 않음)
Helm과 함께 Flux를 사용하는 논리
맞춤형 Flux 리소스
GitOps 체크리스트
단일 진실 소스 개념 위반
작은 결론
GitOps가 무엇이며 왜 필요하지 않습니까?
바로 뛰어 들어 봅시다!
무상태 및 상태 저장
오늘날 인프라 구축의 가장 유망한 개념은 불변 인프라입니다. 핵심 아이디어는 인프라를 상태 비저장(Stateless)과 상태 저장(Stateful)이라는 근본적으로 다른 두 부분으로 나누는 것입니다.
인프라의 상태 비저장 부분은 불변이며 멱등성을 갖습니다. 상태를 축적하지 않고(데이터를 저장하지 않음), 축적된 상태에 따라 동작을 변경하지 않습니다. 상태 비저장 부분의 인스턴스에는 몇 가지 기본 아티팩트, 스크립트 및 어셈블리가 포함될 수 있습니다. 원칙적으로 클라우드/가상화 환경의 기본 이미지에서 생성합니다. 취약하고 일시적입니다. 새로운 기본 이미지에서 인스턴스를 다시 생성하여 새로운 버전의 애플리케이션을 제공합니다.
영구 데이터는 Stateful 부분에 저장됩니다. 이는 전용 서버를 사용하는 기존 방식이나 일부 클라우드 메커니즘(DBaaS, 객체 또는 블록 스토리지)을 통해 실현될 수 있습니다.
이 "동물원"을 관리 가능하고 올바르게 작동하려면 엔지니어링 팀과 DevOps 팀 간의 협업은 물론 완전히 자동화된 제공 파이프라인이 필요합니다.
CI 부분
익스트림 프로그래밍은 애자일 개발 방법론 중 하나입니다. 이는 클라이언트의 요구 사항과 동기화를 유지할 수 있는 많은 피드백 루프로 구별됩니다.
CI/CD 시스템을 사용하여 전달 파이프라인의 자동화를 구현합니다. CI(지속적 통합)라는 용어는 1994년 Grady Booch에 의해 제안되었으며, 1997년에는 Kent Beck과 Ron Jeffries가 이를 익스트림 프로그래밍 분야에 도입했습니다. CI에서는 변경 사항을 프로젝트의 주요 작업 분기에 최대한 자주 통합해야 합니다.
이를 위해서는 먼저 작업을 보다 세부적으로 분해해야 합니다. 작은 변경 사항은 더 원자적이고 추적, 이해 및 통합이 더 쉽습니다. 둘째, 새로 작성된 코드를 병합할 수는 없습니다. 브랜치를 병합하기 전에 이전에 작동했던 것이 손상되지 않았는지 확인해야 합니다. 이를 위해서는 최소한 애플리케이션을 구축해야 합니다. 테스트를 통해 코드를 다루는 것도 좋은 생각입니다.
이것이 바로 CI 시스템이 수행하는 작업입니다. CI 시스템은 개발 과정에서 많은 발전을 이루었으며 이 경로의 중간쯤에서 CI/CD 시스템으로 전환되었습니다.
CD부분
CD란 무엇입니까? .
지속적인 전달. 이는 지속적인 통합 방식과 DevOps 문화의 도움으로 프로젝트의 기본 브랜치를 프로덕션에 지속적으로 배포할 준비를 유지하는 경우입니다.
지속적인 배포. 메인 브랜치로 들어가는 모든 것이 클러스터와 프로덕션으로 덤프되는 것은 지속적인 전달입니다.
더 나아가자.
Snowflake 서버 문제
불행하게도 불변 인프라에는 몇 가지 문제가 있습니다. 그 중 가장 큰 부분은 IaC(Infrastructure as Code) 개념에서 상속되었습니다.
우선 구성 드리프트입니다. 이 용어는 Puppet Labs(잘 알려진 Puppet SCM의 작성자)에서 탄생했으며 대상 시스템의 모든 변경 사항이 시스템 구성 관리(SCM)의 도움으로 이루어지지는 않는다는 것을 나타냅니다. 일부는 이를 우회하여 수동으로 수행됩니다.
이러한 여러 변경 과정에서 구성 드리프트(SCM에 설명된 구성과 실제 상황 간의 차이)가 나타납니다.
이로 인해 자동화 공포의 악순환이 발생합니다.
수동으로 변경한 내용이 많을수록 SCM 스크립트를 실행하면 기록되지 않은 변경 내용이 중단될 가능성이 높아집니다. 실행하는 것이 더 무서울수록 새로운 수동 편집이 이루어질 가능성이 더 높습니다.
결국 이 악의적인 긍정적인 피드백은 눈송이 서버의 형성으로 이어지며, 이는 너무 일관성이 없어 아무도 더 이상 내부 내용을 이해하지 못하게 됩니다. 수동으로 편집한 후에는 노드가 폭설 속의 개별 눈송이만큼 고유해집니다.
이 드리프트로 인해 서버는 변경 불가능한 인프라 내에서 더 높은 수준에 있게 됩니다. 이제 GCP 프로젝트/AWS VPC/Kubernetes-cluster-snowflakes에 대해 이야기할 수 있습니다. 이는 변경 불가능한 인프라에서 변경 구현이 규제되지 않기 때문에 발생합니다. 게다가 제대로 하는 방법을 아는 사람도 없습니다.
GitOps - 모든 문제에 대한 만병통치약(또는 그렇지 않은)
그리고 Weaveworks가 나타나서 "얘들아, 우리는 당신이 필요로 하는 GitOps를 가지고 있습니다"라고 말합니다. GitOps를 홍보하기 위해 그들은 만든 Kelsey Hightower와 같은 유명 인사를 영입했습니다. 그는 PR 과정에서 "남자가 되어라, b..! 스크립팅을 중단하고 배송을 시작하라"는 메시지를 많이 방송했다. 그리고 그는 어느 정도의 마케팅 헛소리 빙고를 말합니다.
제 생각에 가장 흥미로운 이점은 다음과 같습니다.
배포의 일관성 및 표준화 개선
향상된 보안 보장
더 쉽고 빠른 오류 복구
액세스 및 비밀 관리가 더 쉬워졌습니다.
자체 문서화 배포
팀 내 지식 배포
GitOps가 무엇인지 알아내려는 사람이라면 누구나 이 교과서 슬라이드를 보게 될 것입니다.
다음으로 IaC 원칙이 약간 강화된 GitOps 원칙을 찾습니다.
GitOps는 선언적입니다.
GitOps 앱은 버전이 지정되어 있으며 변경할 수 없습니다.
GitOps 앱이 자동으로 당겨집니다.
GitOps 앱은 지속적으로 조정됩니다.
그럼에도 불구하고 이는 진공 상태에서의 구형 설명이므로 우리는 연구를 계속하고 있습니다. GitOps.tech 웹사이트에서 몇 가지 중요한 설명을 찾을 수 있습니다.
먼저, GitOps는 이를 인프라에 자동으로 적용하는 CD 도구가 포함된 Git의 인프라와 유사한 코드라는 점을 알아봅니다.
GitOps 내에 최소 2개의 저장소가 있어야 합니다.
애플리케이션 저장소. 해당 애플리케이션의 배포를 설명하는 애플리케이션 소스 코드와 매니페스트를 설명합니다.
인프라 저장소. 인프라 매니페스트와 배포 환경에 대해 설명합니다.
또한 GitOps 이데올로기에서는 푸시 지향 접근 방식보다 풀 지향 접근 방식이 선호됩니다. 이는 중량급 풀 몬스터인 Puppet 및 Chef에서 경량 푸시 기반 Ansible 및 Terraform으로 SCM 시스템이 진화하는 것과 다소 반대됩니다.
그리고 GitOps가 주로 툴킷 이야기라면 Weaveworks 자체에서 Flux 기반 개념을 가져와 해체하는 것이 합리적입니다. 아이디어 작성자가 참조 구현을 수행했어야 합니다.
Flux는 이제 버전 2까지 올라갔으며 구조적으로 클러스터 내에서 작동하는 컨트롤러로 구성됩니다.
소스 컨트롤러
컨트롤러를 사용자화하세요
HELM 컨트롤러
알림 컨트롤러
이미지 자동화 컨트롤러
다음으로 Flux와 Helm을 사용한 작업에 대해 논의해 보겠습니다.
Helm과 함께 Flux를 사용하는 논리
Flux 2에서 Helm 패키지 관리자를 사용하여 애플리케이션을 배포하는 예를 더 자세히 설명하겠습니다.
왜? 에 따르면 HELM 패키지 관리자는 50% 이상의 점유율로 가장 인기 있는 패키징 애플리케이션이었습니다.
아쉽게도 더 최신의 데이터를 찾을 수 없었지만 그 이후로 크게 변한 것은 없다고 생각합니다.
이제 Flux 2가 Helm과 어떻게 작동하는지에 대한 기본 논리를 살펴보겠습니다. 우리는 애플리케이션과 인프라라는 2개의 저장소를 가지고 있습니다.
애플리케이션 저장소에서 HELM 차트와 Docker 이미지를 만들어 각각 Helm 차트 저장소와 Docker 레지스트리에 추가합니다.
다음으로 Flux 컨트롤러를 실행하는 Kubernetes 클러스터가 있습니다.
애플리케이션을 출시하기 위해 사용자 정의 리소스(CR) HelmRelease를 설명하는 YAML을 준비하고 이를 인프라 저장소에 추가합니다.
Flux를 얻을 수 있도록 Kubernetes 클러스터에 CR GitRepository를 만듭니다. 소스 컨트롤러는 이를 보고 git으로 이동하여 다운로드합니다.
이 YAML을 클러스터에 배포하기 위해 사용자 정의 리소스를 설명합니다.
Kustomize 컨트롤러는 이를 확인하고 소스 컨트롤러로 이동하여 YAML을 가져와 클러스터에 배포합니다.
Helm 컨트롤러는 CR HelmRelease가 클러스터에 나타난 것을 확인하고 소스 컨트롤러로 이동하여 설명된 HELM 차트를 가져옵니다.
Helm-controller는 Source-controller에서 차트를 가져와 릴리스를 생성하고 이를 클러스터에 배포합니다. 그런 다음 Kubernetes는 필요한 Pod를 생성하고 Docker 레지스트리로 이동하여 해당 이미지를 다운로드합니다.
따라서 애플리케이션의 새 버전을 출시하려면 새 이미지, 새 HelmRelease 파일 및 새 HELM 차트를 만들어야 합니다. 그런 다음 이를 적절한 저장소에 넣고 Flux 컨트롤러가 위에서 설명한 체인의 작업을 반복할 때까지 기다려야 합니다.
그리고 작업을 끝내기 위해 무엇이 잘못되었는지 알려주는 알림 컨트롤러를 어딘가에 배치했습니다.
커스텀 Flux 리소스
이제 Flux가 작동하는 사용자 정의 리소스에 대해 논의해 보겠습니다.
첫 번째는 Git 저장소입니다. 여기에서 Git 저장소의 주소(14행)와 Git 저장소의 주소(10행)를 지정할 수 있습니다.
따라서 전체 저장소가 아닌 단일 분기만 다운로드합니다. 하지만! 우리는 책임 있는 엔지니어이고 제로 트러스트 개념을 고수하려고 노력하기 때문에 저장소에 대한 액세스를 잠그고 Kubernetes 클러스터에 키를 사용하여 비밀을 생성한 후 Flux가 그곳으로 이동할 수 있도록 제공합니다(라인 12).
다음은 Kustomization입니다. 여기에서는 Flux의 Kustomize 컨트롤러와 Kubernetes 작성자의 Kustomize가 서로 다른 두 가지라는 사실에 주목하고 싶습니다. 왜 이렇게 혼란스러운 이름을 선택했는지는 모르겠지만 혼동하지 않는 것이 중요합니다.
Kustomization은 Git 저장소에서 클러스터로 YAML(모든)을 배포하는 방법입니다. 여기서는 YAML을 넣을 소스(12행 - 위에서 설명한 CR GitRepository의 이름), YAML을 가져오는 디렉터리(8행)를 지정해야 하며, 이를 저장할 대상 네임스페이스를 지정할 수 있습니다. (라인 13).
다음은 Helm 릴리스입니다.
여기에서 이름과 차트 버전을 지정할 수 있습니다(10,11행). 여기에서는 Helm이 환경별로 릴리스를 사용자 정의할 수 있도록 변수 값을 지정합니다(15-19행). 환경이 크게 다를 수 있으므로 이는 매우 중요하고 필요한 기능입니다. 또한 Helm 차트를 가져올 소스를 지정합니다(12, 13, 14행). 이 경우 Helm 저장소입니다.
하지만! 우리는 여전히 책임 있는 엔지니어이기 때문에 Helm 저장소에 가까이 접근할 수 있으며 Flux에 거기에 도달할 수 있는 비밀을 제공합니다(7, 8행).
GitOps 체크리스트
그럼 방금 살펴본 내용을 파악하기 위해 간단한 체크리스트를 작성해 보겠습니다. GitOps를 시작하려면 갑자기 많은 스크립트를 작성해야 합니다(불변 인프라는 완전히 자동화된 전달 파이프라인에 관한 것임을 기억합니다). 따라서 우선 다음을 생성해야 합니다.
이미지를 빌드하고 Docker 레지스트리에 푸시하는 스크립트
인프라 Git 저장소
인프라 GIT 저장소에 대한 CI 시스템 액세스 계정
HelmRelease 파일을 생성하고 푸시하는 스크립트
투구 저장소
Helm 저장소에 대한 CI 시스템 액세스 계정
Helm 차트를 구축하고 게시하는 스크립트`
인프라 저장소를 위한 Flux 계정
Helm 차트 저장소의 Flux 계정
좋습니다. 이제 GitOps에 대한 체크리스트가 생겼습니다. 계속하세요.
단일 진실 소스 개념 위반
일반적으로 Helm 릴리스를 통해 무엇을 얻을 수 있는지 살펴보겠습니다. 이 특별한 경우에는 Git이 유일한 정보 소스가 될 수 없다는 것은 분명합니다. 이 Helm 릴리스가 의존하는 git 외부에 최소한 2개의 리소스, 2개의 아티팩트가 있습니다.
Helm 차트(8-14행)
도커 이미지(19행)
그리고 상황을 더욱 복잡하게 만들고 Helm 차트 버전의 범위를 지정할 수 있습니다.
이 경우 Flux는 이 범위 내에 나타나는 새로운 Helm 차트를 모니터링하고 설정합니다. 또한 우리가 보유한 소스 컨트롤러는 S3 번들을 포함하여 YAML을 소스로 사용할 수 있습니다.
여기에서 YAML 및 Helm 차트를 모두 유지할 수 있습니다.
또한 Docker 레지스트리의 새 이미지를 감시하고 인프라 저장소를 편집할 수 있는 이미지 자동화 컨트롤러가 있습니다.
그러나 우리는 HELM Chart repo-Ops 또는 Docker Registry-Ops를 원하지 않습니다. 우리는 가능한 한 GitOps가 되기를 원합니다. 따라서 문서를 살펴보고 GIT 저장소에서 Helm 차트를 배포하는 프로세스를 수정합니다(저장할 애플리케이션 저장소를 선택합니다).
이로 인해 애플리케이션 저장소에 대한 또 다른 CR GitRepository를 만들고 Flux가 액세스할 수 있는 계정을 만들고 키가 있는 비밀을 생성해야 합니다.
동시에 우리는 Docker 이미지에 대한 복잡한 종속성 문제를 어떤 식으로든 해결하지 않습니다.
작은 결론
오늘은 이 정도면 충분할 것 같아요. 2부에서는 이 선함이 어떤 문제를 가지고 있는지 말씀드리겠습니다. 나는 다음을 논의할 것이다:
