GitOps를 설계하거나 구현하는 초기 단계에서는 필요한 다양한 도구와 관행에 대해 생각하기가 어려울 수 있습니다. 인프라 및 애플리케이션 배포를 관리하기 위한 강력하고 확장 가능한 워크플로우를 설계하고 있는지 확인하고 싶을 것입니다. 또한 프로세스를 지나치게 복잡하게 만들거나 팀이 코드 변경 사항을 릴리스하기 어렵게 만드는 어떤 것도 도입하고 싶지 않을 것입니다.
초점을 좁히는 한 가지 방법은 배포 관행을 지원하는 도구와 사례를 찾는 것입니다. 가장 중요한 고려 사항은 푸시 기반 접근 방식을 사용할지 풀 기반 접근 방식을 사용할지 여부입니다. 두 가지 모두 장단점이 있으며, 어떤 것을 사용하느냐에 따라 GitOps 전략에 포함하는 도구와 프로세스에 영향을 미칩니다.
워크플로 및 인프라 자동화
먼저 두 가지 핵심 데브옵스 사례를 살펴보겠습니다: 코드형 인프라(IaC)와 지속적 통합 및 지속적 배포(CI/CD)를 통한 자동화입니다.
IaC는 일련의 수동 단계나 대화형 프로세스 대신 코드를 통해 인프라를 배포하고 관리하는 기술입니다. 이 접근 방식은 인프라 기본 요소나 관리형 클라우드 서비스에만 국한되지 않고 구성 파일, 소프트웨어 설치, 네트워크 및 보안 정책 등 관리 가능한 모든 측면에 적용할 수 있습니다. 일반적으로 "X as Code"라고 하는 이러한 유형의 통합 관리는 배포를 위해 템플릿화되고 문서화된 원하는 상태를 제공합니다.
CI/CD는 개발자가 고품질의 안전한 코딩 애플리케이션을 빠르고 안정적으로 제공할 수 있도록 지원하는 방법론이자 일련의 일반적인 관행입니다. CI/CD를 도입한다는 것은 소프트웨어 개발 수명 주기의 적절한 단계에서 자동화를 구현하여 개발팀이 비즈니스와 최종 사용자 요구 사항에 집중할 수 있는 문화를 수용하는 것입니다.
소프트웨어 개발에서 통합은 리포지토리에 있는 코드에 변경 사항을 커밋하는 프로세스입니다. 지속적 통합(CI)은 업데이트된 애플리케이션 코드를 안정적이고 일관된 방식으로 빌드, 테스트 및 패키징하여 변경 사항을 자동으로 검증하는 프로세스입니다. 모든 푸시 이벤트에서 CI 워크플로우를 트리거하면 변경 사항이 환경에 배포되기 전에 버그, 보안 취약성 및 충돌을 발견할 수 있으므로 더 원활하고 빠른 개발 프로세스를 제공합니다.
CI 워크플로우가 성공적으로 완료되면 지속적 배포(CD) 워크플로우가 이어집니다. 이는 업데이트된 애플리케이션 코드를 선택한 환경에 제공하는 자동화되고 일관된 프로세스로, 애플리케이션을 스테이징 또는 프로덕션 서버에 직접 배포하거나 컨테이너 레지스트리 또는 모바일 배포 플랫폼에 새 릴리스를 배포하는 워크플로우가 될 수 있습니다.
이는 개발자 워크플로 자동화와 관련된 핵심 주제입니다. 깃옵스 접근 방식은 이러한 핵심 DevOps 관행에 의존하여 이를 실행에 옮깁니다. git 리포지토리를 IaC 정의 파일의 단일 소스로 활용하고 자동화 파이프라인을 활용하면 인프라의 원하는 상태를 효과적으로 버전 관리할 수 있습니다.
다시 배포 관행으로 돌아와서 푸시 기반과 풀 기반 중 어느 것이 애플리케이션과 GitOps 전략에 가장 적합한지 결정합니다.
푸시 기반 아키텍처와 풀 기반 아키텍처 비교
푸시 기반 또는 에이전트리스 방식은 Jenkins 또는 CircleCI와 같은 외부 CI/CD 클라이언트에 의해 선택한 환경에 변경 사항을 푸시하는 보다 전통적인 접근 방식입니다. 이 방식은 Kubernetes가 아닌 환경이나 워크로드 유형이 혼합되어 각 구성 요소에서 별도의 에이전트와 웹후크를 실행하는 것이 번거로운 환경에 적합할 수 있습니다.
장점:
- 단일 환경에서 여러 유형의 워크로드에 걸쳐 더 간편하게 구현할 수 있습니다.
- 서로 다른 환경(예: 클라우드 네이티브 및 온프레미스) 간의 배포 방법론 표준화.
- 대부분의 CI/CD 프레임워크가 푸시 기반 모델을 활용하므로 툴링 유연성이 뛰어납니다.
단점:
- CI/CD 클라이언트에는 변경 사항이 성공적으로 배포되었는지 또는 그 결과로 서버 측 문제가 발생했는지 알 수 있는 통합 가시성이 없습니다.
- CI/CD 클라이언트가 변경 사항을 배포하려면 추가 도구(예: kubectl, Helm, Docker, Ansible, Terraform, SSH)를 설치해야 할 수 있습니다.
- CI/CD 클라이언트에 환경에 대한 외부 액세스 권한을 부여해야 하므로 보안 및 규정 준수 문제가 발생할 위험이 높아집니다.
풀 기반 또는 에이전트 접근 방식은 환경을 CD 파이프라인의 일부로 만들어서 반대 방향으로 작동합니다. 에이전트나 운영자가 git 리포지토리에서 변경 사항을 감시한 다음 이를 끌어와 적용합니다. 이 작업은 에이전트가 단일 소스에서 구성 편차를 감지할 때마다 수행됩니다. 이 접근 방식은 특히 Kubernetes 네이티브 환경에서 잘 작동합니다.
장점:
- 에이전트/운영자는 환경의 현재 상태 및 배포 상태에 대한 가시성을 확보할 수 있습니다.
- 소스를 볼 수 있는 권한만 필요한 환경이므로 보안이 강화되고 규정 준수가 간소화됩니다.
- 사람의 수동 개입이나 기타 소스로 인한 구성 편차를 빠르게 감지합니다.
단점:
- 쿠버네티스가 아닌 배포의 경우 더 복잡합니다.
- 특정 환경 유형에서 작동하도록 설계된 도구가 필요합니다.
GitOps 전략을 계획할 때 다양한 배포 전략이 애플리케이션을 어떻게 지원할지 고려하세요. 푸시 및 풀 기반 접근 방식 모두 장점이 있으며 다양한 시나리오에 적합합니다. 고려해야 할 많은 도구와 관행이 있으며, 몇 가지 관점을 통해 팀과 스택에 적합한 솔루션이 무엇인지 알 수 있습니다.
자세한 정보가 필요하신가요? 무료 GitOps 전략 전자책을 다운로드하거나 Akamai 클라우드 컴퓨팅 전문가와 무료 상담을 받으세요.
내용