• 요약
• 동기
  • 목표
  • 비목표
• 제안
  • DORA 메트릭
  • 그룹 수준에서 환경 및 서비스 집계
  • 엔티티 관계
• 대안 솔루션

서비스

요약

현대적인 서비스 지향적 배포 및 환경 관리를 직교적으로 포착하기 위해 GitLab은 서비스를 일등 시민 개념으로 가져야 합니다. 이 설계안은 GitLab CD 솔루션 내에서 서비스 및 관련 엔티티를 어떻게 구축해야 하는지 개요합니다.

동기

GitLab이 전체 DevSecOps 주기에 대한 단일 플랫폼을 제공하도록 노력하는 가운데, 그 제안은 파이프라인에서 머무르지 않고 배포 및 릴리스 관리, 사용자 개발 및 타사 응용프로그램의 가시성도 포함해야 합니다.

GitLab은 파이프라인의 environment 구문과 같은 몇 가지 개념을 제공하지만, 특정 환경에서 무엇이 실행 중인지에 대한 개념을 제공하지는 않습니다. 환경은 무엇이 실행 중인지에 대한 질문에 답하지 않습니다. 우리는 서비스 및 릴리스 아티팩트를 도입하여 이 질문에 대답할 것입니다. Delivery 용어집에서는 서비스를 다음과 같이 정의합니다.

애플리케이션의 (대부분) 독립적으로 배포 가능한 논리적인 개념으로, 특정 기능을 제공하기 위해 다른 서비스와 느슨하게 결합됩니다.

서비스는 SCM, 레지스트리 또는 이슈와 릴리스 아티팩트를 통해 연결되며, 특정 버전의 지정된 릴리스 아티팩트가 배포(또는 배포 중)된 환경에 대한 집중된 뷰가 될 것입니다.

서비스의 개념을 가지면 사용자는 CI/CD 파이프라인뿐 아니라 프로덕션에서도 애플리케이션을 추적할 수 있게 됩니다. 이는 비용 관리와 같은 가능성을 열어주며, 분석:가시성의 현재 작업은 서비스를 지원하는 경우 GitLab에 통합될 수 있습니다.

목표

• 서비스는 프로젝트 수준에서 정의됩니다.
• 단일 프로젝트에는 여러 개의 서비스가 포함될 수 있습니다.
• 그룹 및 조직 수준에서 서비스 디렉터리을 나열할 수 있어야 합니다. 아키텍처가 첫날부터 그룹 수준 기능을 지원할 수 있도록 준비되어야 합니다. “그룹 수준 환경 보기”는 고객들이 많은 연도 동안 요청해온 기능입니다.
• 서비스는 환경에 바인딩됩니다. 각 서비스는 여러 환경에 존재할 수 있으며 각 환경은 여러 서비스를 호스트할 수 있습니다. 모든 서비스가 모든 환경에 존재할 것으로 예상되지 않으며, 모든 환경이 모든 서비스를 호스트할 것으로 예상되지 않습니다.
• 서비스는 여러 리소스를 묶은 논리적인 개념입니다.
• 서비스는 일반적으로 다른 서비스와 독립적으로 배포됩니다. 서비스는 일반적으로 모두 함께 배포됩니다.
  • 사용자 인터뷰에서 배포는 Helm, helmfiles 또는 Flux를 통해 CI를 통해 발생했습니다.
  • Kubernetes에서도 다른 도구(Kustomize, 바닐라 매니페스트)를 사용하여 서비스를 배포할 수 있습니다.
  • Kubernetes 이외의 다른 도구도 사용될 수 있습니다. 예: Runway는 Terraform을 사용하여 배포합니다.
• 서비스의 배포를 MR, 컨테이너, 린터 결과와 함께 릴리스 아티팩트에 연결하고자 합니다.
• 서비스에는 외부(또는 내부) 페이지로의 링크 모음이 포함됩니다.

아키텍처 다이어그램 소스

(배포의 점선 테두리는 대상 인프라로의 투영을 나타냅니다)

비목표

• 서비스와 관련된 메트릭은 프로젝트 유지보수자(개발자?)에 의해 사용자 정의 및 구성 가능해야 합니다. 메트릭은 쿼리와 의미 모두 서비스마다 다를 수 있습니다. (예: 트래픽은 대기열에 대해 의미가 없을 수 있습니다).
• 메트릭은 OpenTelemetry/Prometheus, Datadog 등과 같은 다양한 외부 도구와 통합되어야 합니다.
• 분석:가시성에서 구축한 GitLab 가시성 솔루션에 대한 논의는 하고 싶지 않습니다. 여기서의 제안은 하나의 가시성 통합 백엔드로 취급해야 합니다.
• 경고, SLO, SLA 및 사고 관리를 다루고 싶지 않습니다.
• 일부 인프라는 다른 인프라보다 GitLab에서 더 나은 지원을 이미 제공할 수 있습니다 (쿠버네티스가 순수한 AWS보다 더 잘 지원됩니다). 우리가 쿠버네티스에 대해 제공하거나 제공할 계획인 기능과 다른 인프라에 대한 기능 동등성을 달성하는 방법을 논의할 필요는 없습니다.
• 서비스는 메타데이터(예: 테넌트, 지역)로 필터링될 수 있습니다. 이것들은 고객에 따라 또는 그룹마다 달라질 수 있습니다.

제안

서비스 모델을 도입하려 합니다. 이것은 다음 매개변수를 포함하는 얕은 모델입니다.

• 이름: 서비스의 이름(e.g. 멋진 API)
• 설명: 마크다운 필드. 외부(또는 내부) 페이지로의 링크를 포함할 수 있습니다.
• (미정) 메타데이터: 그룹 또는 프로젝트 수준에서 필터링에 사용될 사용자 정의 키-값 쌍.
  • 예시 필드:
    • 테넌트: 북서
    • 구성요소: Redis
    • 지역: us-east-1
• (미정) 배포 시퀀스: 개발에서 스테이징으로의 프로모션을 허용하기 위해
• (미정) 서비스에 특화된 환경 변수: 환경 내에서 변수를 정의할 수 있어야 합니다.

DORA 메트릭

사용자들은 서비스를 통해 DORA 메트릭을 관찰할 수 있습니다:

• 현재 배포 빈도는 environment_tier=production으로 레이블이 지정된 배포를 또는 작업 이름이 prod 또는 production인 작업을 계산합니다.
• 최종 사용자에게 명확히 전달되어야 합니다. 단일 environment_tier=production 작업으로 파이프라인을 제한하거나 환경마다 첫 번째 environment_tier=production 작업으로 제한하는 것과 같이 규칙으로 정의할 수 있습니다. 이는 나중에 정의될 예정입니다.

그룹 수준에서 환경 및 서비스 집계

그룹 수준에서 GitLab은 특정 그룹 아래의 모든 프로젝트 수준 환경을 가져와서 그 환경의 이름으로 그룹화합니다. 예:

엔티티 관계

• 서비스와 환경은 다대다 관계를 가집니다.
• 배포와 릴리스 아티팩트는 일대다 관계를 가집니다(특정 버전의 아티팩트에 대해). 특정 환경에 중점을 둔다면 배포와 릴리스 아티팩트는 일대일 관계를 가집니다.
• 환경과 배포는 일대다 관계를 가집니다. 이는 환경별로 배포 기록(과거 및 진행 중, 미완료 사항은 포함되지 않을 수 있음)을 보여줄 수 있게 합니다.
• 환경과 릴리스 아티팩트는 배포를 통해 다대다 관계를 가집니다.
• 서비스와 릴리스 아티팩트는 다대다 관계를 가집니다. 이를 통해 서비스별 릴리스 기록(과거, 진행 중, 미완료 사항)을 보여줄 수 있습니다.
• 릴리스 아티팩트와 아티팩트는 일대다 관계를 가집니다(예: 아티팩트로 차트 => 아티팩트로 값 => 아티팩트로 이미지).

자세한 정보는 용어집을 참조하세요.

토론: 기존 엔티티인 배포 및 환경 모델을 재사용할지 여부는 아직 결정되지 않았습니다. 기존 엔티티를 재사용하는 것은 장기적으로 우리를 제한할 수 있지만, 사용자는 기존의 CI/CD 워크플로우를 크게 변경하지 않고도 새로운 아키텍처를 신속하게 채택할 수 있어야 합니다. 이 결정은 이상적인 구조 및 엔티티의 행동에 대한 더 명확한 답변을 얻을 때 만들어야 합니다. 그러면 우리는 기존 엔티티에서 얼마큼 멀리 떨어져 있는지와 기존 CI/CD 워크플로우를 크게 변경하지 않고 새로운 아키텍처를 채택할 수 있는지를 이해할 수 있습니다.

대안 솔루션

• 동적으로 생성된 조직 수준의 환경 페이지 추가. 이 접근 방식은 서비스 컨셉을 우선시하여 실행 불가 결론이 나왔습니다.
• 그룹 환경 엔터티 소개를 위한 대안 제안이 있습니다. 그룹 수준 환경 뷰를 위해요.