This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed @nagyv-gitlab @grzesiek @shinya.maeda @emilybauman devops deploy 2023-08-18

서비스

요약

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

동기

GitLab은 전체 DevSecOps 주기에 대한 단일 플랫폼을 제공하기 위한 노력을 기울이는 가운데, 그 제공물은 파이프라인에서 머무르지 않고 배포 및 릴리스 관리뿐만 아니라 사용자가 개발한 애플리케이션과 타사 어플리케이션의 가시화 또한 포함해야 합니다.

GitLab은 파이프라인에서 environment 구문과 같은 개념을 제공하고 있지만, 특정 환경에서 무엇이 실행되고 있는지에 대한 개념은 제공하고 있지 않습니다. 환경은 어떤 것이 “어디”에서 실행 중인지에 대한 답을 제공할 수 있겠지만, “무엇”이 거기서 실행 중인지에 대한 질문에 답을 주지 못합니다. 우리는 이 질문에 답하기 위해 서비스릴리스 아티팩트를 도입해야 합니다. 배포 용어집은 서비스를 다음과 같이 정의합니다.

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

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

서비스의 개념을 갖는 것은 사용자가 CI/CD 파이프라인 뿐만 아니라 제품을 운영 중인 프로덕션 환경에서도 추적할 수 있도록 합니다. 이는 비용 관리와 같은 가능성을 열어줍니다. 분석:가시화의 현재 작업은 서비스를 지원한다면 GitLab에 통합될 수 있습니다.

목표

  • 서비스는 프로젝트 수준에서 정의됩니다.
  • 단일 프로젝트에는 여러 개의 서비스를 보유할 수 있어야 합니다.
  • 그룹 및 조직 수준에서 서비스를 목록화할 수 있어야 합니다. 아키텍처가 그룹 수준 기능을 지원할 준비가 되어있는지 확인해야 합니다. “그룹 수준 환경 보기”는 고객들이 많은 연도 동안 요청해온 기능입니다.
  • 서비스는 환경에 바인딩됩니다. 모든 서비스가 여러 환경에 존재할 수 있으며, 모든 환경이 여러 서비스를 호스팅할 수 있습니다. 모든 서비스가 모든 환경에 존재할 것으로 기대되지는 않으며, 어떤 환경도 모든 서비스를 호스팅할 것으로 기대되지 않습니다.
  • 서비스는 여러 리소스를 그룹화한 논리적인 개념입니다.
  • 서비스는 일반적으로 다른 서비스와 독립적으로 배포됩니다. 서비스는 일반적으로 전체적으로 배포됩니다.
    • 사용자 인터뷰에서 배포는 Helm, helmfiles, 또는 HelmRelease를 통해 CI를 사용하여 이루어 졌습니다.
    • Kubernetes에서도 서비스를 배포하기 위해 Kustomize, 바닐라 매니페스트가 있을 수 있습니다.
    • Kubernetes 외의 다른 도구들을 사용할 수도 있습니다. 예를 들어 Runway는 Terraform을 사용하여 배포합니다.
  • 서비스의 배포를 MRs, 컨테이너, linter 결과를 포함한 릴리스 아티팩트에 연결하고자 합니다.
  • 서비스에는 외부(또는 내부) 페이지로의 링크가 여럿 포함되어 있습니다.

아키텍처 다이어그램

아키텍처 다이어그램의 원본

(배포에 대한 점선 테두리는 대상 인프라에 대한 예상을 나타냅니다)

비목표

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

제안

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

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

DORA 메트릭스

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

  • 오늘, 배포 빈도는 environment_tier=production로 표시된 배포나 작업 이름이 prod 또는 production인 배포를 세는 것입니다.
  • 끝 사용자에게 명확해야 합니다. 파이프라인을 단일 environment_tier=production 작업에 제한하는 것과 같은 관습이 될 수 있으며, 환경별 첫 번째 environment_tier=production과 같은 것으로 정의될 수 있습니다. 나중에 정의될 것입니다.

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

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

  프론트엔드 서비스 백엔드 서비스
dev 릴리스 아티팩트 v0.x  
development 릴리스 아티팩트 v0.y  
production 릴리스 아티팩트 v0.z 릴리스 아티팩트 v1.x

엔티티 관계

  • 서비스와 환경은 다대다 관계를 가집니다.
  • 배포와 릴리스 아티팩트는 일대다 관계를 가집니다(특정 버전의 아티팩트에 대해). 단일 환경에 초점을 맞출 때 배포와 릴리스 아티팩트는 일대일 관계를 가집니다.
  • 환경과 배포는 일대다 관계를 가집니다. 이는 환경별 배포 이력(과거 및 실행 중, 미완료는 없으며, 롤아웃 상태를 포함할 수 있음)을 보여줄 수 있습니다.
  • 환경과 릴리스 아티팩트는 배포를 통해 다대다 관계를 가집니다.
  • 서비스와 릴리스 아티팩트는 다대다 관계를 가집니다. 이는 서비스별 릴리스 이력(과거, 실행 중, 미완료)을 보여줄 수 있게 합니다.
  • 릴리스 아티팩트와 아티팩트는 일대다 관계를 가집니다(예: 아티팩트로서 차트 => 아티팩트로서 값 => 아티팩트로서 이미지).
classDiagram Group "1" o-- "*" Project : 그룹 내에 여러 프로젝트에 서비스가 있을 수 있습니다 Project "1" <.. "*" Service : 서비스는 프로젝트의 일부입니다 Project "1" <.. "*" Environment : 환경은 프로젝트의 일부입니다 Environment "*" .. "*" Service : 서비스는 1개 이상의 환경에 연결됩니다 Service "1" <|-- "*" ReleaseArtifact : 릴리스 아티팩트는 특정 버전의 서비스를 패키징합니다 ReleaseArtifact "1" <|-- "*" Deployment : 릴리스 아티팩트는 배포될 수 있습니다 Deployment "1" --|> "1" Environment : 모든 배포는 특정 환경에 위치합니다

더 많은 정보는 용어집을 참조하세요.

토론: 기존 엔티티(예: DeploymentEnvironment 모델)를 재사용할 지 여부는 미정입니다. 기존 엔티티를 재사용하면 장기적으로 우리를 제한할 수 있지만, 사용자는 기존 CI/CD 워크플로를 급격하게 변경하지 않고도 새로운 아키텍처를 쉽게 채택할 수 있어야 합니다. 이 결정은 이상적인 구조와 엔티티의 행동에 대한 보다 명확한 답변을 얻을 때까지 미뤄져야 합니다. 그러면 기존 엔티티와의 거리, 이동 가능성을 이해하고 새로운 아키텍처가 얼마나 순조로울 지 알 수 있습니다.

대안 솔루션