GitOps: 또 다른 유행어인가 아니면 자동화의 혁신인가?

우리 대부분은 IT 블로그나 컨퍼런스에서 또 다른 새로운 용어를 발견하면 조만간 비슷한 질문을 던집니다. “이게 뭐죠? 또 다른 유행어, "유행어", 아니면 정말 관심을 갖고 연구하고 새로운 지평을 약속할 만한 가치가 있는 것일까요?” 나에게도 같은 일이 일어났다. GitOps 전자. 기존의 많은 기사와 회사 동료들의 지식으로 무장 GitLab, 나는 이것이 어떤 종류의 짐승인지, 실제로 그 용도가 어떤지 알아 내려고 노력했습니다.

그건 그렇고, 용어의 참신함에 대해 GitOps 우리의 최근 설문조사에 따르면 설문조사에 참여한 사람 중 절반 이상이 아직 이 원칙을 적용하기 시작하지 않았습니다.

따라서 인프라 관리 문제는 새로운 것이 아닙니다. 많은 클라우드 제공업체가 수십 년 동안 일반 대중에게 제공되어 왔으며 인프라를 담당하는 팀의 작업을 간단하고 간단하게 만들었어야 했던 것 같습니다. 그러나 자동화가 새로운 수준에 도달하는 애플리케이션 개발 프로세스와 비교할 때, 인프라 프로젝트에는 여전히 많은 수동 작업이 포함되고, 특히 내결함성, 유연성, 확장성 및 탄력성에 대한 오늘날의 요구 사항을 고려할 때 전문 지식과 전문 지식이 필요한 경우가 많습니다.

클라우드 서비스는 이러한 요구 사항을 매우 성공적으로 충족했으며 접근 방식 개발에 큰 자극을 준 사람이었습니다. IAC. 이것은 이해할 수 있습니다. 결국 물리적 서버, 랙 또는 네트워크 구성 요소가 없고 스크립트와 구성 파일을 사용하여 전체 인프라를 설명할 수 있는 완전한 가상 데이터 센터 구성이 가능해졌습니다.

그렇다면 차이점은 정확히 무엇입니까? GitOps 부터 IAC? 제가 조사를 시작한 것은 바로 이 질문이었습니다. 동료들과 이야기를 나눈 후 다음과 같은 비교를 생각해낼 수 있었습니다.

GitOps

IAC

모든 코드는 git 저장소에 저장됩니다.

코드 버전 관리는 선택 사항입니다.

선언적 코드 설명/멱등성

선언적 설명과 명령형 설명 모두 허용됩니다.

병합 요청/풀 요청 메커니즘을 사용하여 변경 사항이 적용됩니다.

계약, 승인 및 협업은 선택 사항입니다.

업데이트 출시 프로세스가 자동화되었습니다.

업데이트 롤아웃 프로세스가 표준화되지 않았습니다(자동, 수동, 파일 복사, 명령줄 사용 등).

즉 GitOps 원리를 정확하게 적용하여 탄생했습니다. IAC. 첫째, 이제 인프라와 구성을 애플리케이션과 동일한 방식으로 저장할 수 있습니다. 코드는 저장하기 쉽고, 공유, 비교 및 ​​버전 관리 기능을 사용하기 쉽습니다. 버전, 분기, 기록. 그리고 이 모든 것이 팀 전체가 공개적으로 접근할 수 있는 장소에 있습니다. 따라서 버전 관리 시스템의 사용은 완전히 자연스러운 발전이 되었습니다. 특히 git이 가장 인기가 많습니다.

한편, 인프라 관리 프로세스를 자동화하는 것이 가능해졌습니다. 이제 이 작업을 더 빠르고 안정적이며 저렴하게 수행할 수 있습니다. 더욱이 CI/CD의 원칙은 이미 소프트웨어 개발자들 사이에서 알려져 인기를 끌었습니다. 이미 알려진 지식과 기술을 새로운 영역으로 이전하고 적용하는 것만으로도 충분했습니다. 그러나 이러한 관행은 코드형 인프라의 표준 정의를 넘어섰습니다. GitOps.

호기심 GitOps, 물론 이는 어떤 공급업체와도 관련된 제품, 플러그인 또는 플랫폼이 아니라는 사실에도 마찬가지입니다. 이는 우리에게 익숙한 또 다른 용어인 DevOps와 유사한 패러다임이자 일련의 원칙에 가깝습니다.

회사 GitLab 우리는 이 새로운 용어에 대해 이론적 정의와 실제적 정의라는 두 가지 정의를 개발했습니다. 이론적인 것부터 시작해 보겠습니다.

GitOps는 버전 제어, 협업, 오케스트레이션, CI/CD 등 애플리케이션 개발에 사용되는 최고의 DevOps 원칙을 취하고 이를 인프라 관리 자동화 과제에 적용하는 방법론입니다.

모든 공정 GitOps 나는 기존 도구를 사용하여 작업합니다. 모든 인프라 코드는 이미 익숙한 git 저장소에 저장되고 변경 사항은 다른 프로그램 코드와 동일한 승인 프로세스를 거치며 롤아웃 프로세스가 자동화되어 인적 오류를 최소화하고 안정성과 재현성을 높일 수 있습니다.

실용적인 관점에서 설명하자면 GitOps 다음과 같이

우리는 이미 이 공식의 핵심 구성 요소 중 하나로 코드형 인프라에 대해 논의했습니다. 나머지 참가자들을 소개하겠습니다.

병합 요청(대체 이름 풀 요청). 프로세스 측면에서 MR은 코드 변경 사항을 적용한 다음 분기를 병합하라는 요청입니다. 그러나 우리가 사용하는 도구 측면에서 볼 때 이는 모든 변경 사항에 대한 완전한 그림을 얻을 수 있는 기회에 더 가깝습니다. 특정 수의 커밋에서 수집된 코드 차이점뿐만 아니라 컨텍스트, 테스트 결과 및 최종 예상 결과. 인프라 코드에 대해 이야기하는 경우 인프라가 정확히 어떻게 변경되는지, 얼마나 많은 새로운 리소스가 추가 또는 제거되고 변경되는지에 관심이 있습니다. 좀 더 편리하고 읽기 쉬운 형식을 사용하는 것이 좋습니다. 클라우드 제공업체의 경우 이러한 변화가 재정적으로 어떤 영향을 미칠지 아는 것이 좋습니다.

하지만 MR은 협업, 상호작용, 커뮤니케이션의 수단이기도 합니다. 견제와 균형 시스템이 작동하는 곳입니다. 간단한 의견부터 공식적인 승인 및 승인까지.

마지막 구성 요소인 CI/CD는 우리가 이미 알고 있듯이 인프라 변경 및 테스트(간단한 구문 확인부터 보다 복잡한 정적 코드 분석까지) 프로세스를 자동화할 수 있게 해줍니다. 또한 후속 드리프트 감지에서도 시스템의 실제 상태와 원하는 상태 간의 차이가 발생합니다. 예를 들어, 무단 수동 변경이나 시스템 오류로 인해 발생합니다.

응, 용어야 GitOps 우리에게 완전히 새로운 것을 소개하지도 않고, 바퀴를 재발명하지도 않으며, 이미 축적된 경험을 새로운 영역에 적용할 뿐입니다. 하지만 그의 강점은 여기에 있다.

그리고 갑자기 이 모든 것이 실제로 어떻게 보이는지에 관심이 생긴다면, 우리를 보도록 권유합니다. 마스터 클래스, GitLab 사용 방법을 단계별로 설명합니다.

• GitOps의 기본 원칙 구현

• 클라우드 인프라 생성 및 변경(Yandex Cloud 예시 사용)

• 활성 모니터링을 사용하여 원하는 상태에서 시스템 드리프트를 자동으로 감지

https://bit.ly/34tRpwZ

출처 : habr.com