GitLab 차트 의존성

GitLab Operator(단순히 “Operator”라고도 함)는 GitLab Helm Charts(단순히 “Chart”라고도 함)에 의존합니다.

ADR 0004에서 설명된 바와 같이.

GitLab Chart 변경에 따른 영향 이해하기

Operator가 새로운 버전의 Chart를 수집할 때,

Chart 내의 변경 사항도 함께 수집합니다. 때때로 조정이 필요합니다.

변경 사항을 지원하기 위해 Operator에 대한 조정도 필요할 수 있습니다.

예를 들어, Chart merge request 3278는 NGINX Ingress Controller 이미지 태그의 버전을 업데이트했으며,

변경 사항을 지원하기 위해 NGINX RBAC 객체에 대한 업데이트도 포함되었습니다. 이로 인해 Operator issue 1324에서 파이프라인이 고장났습니다. 문제는 Operator merge request 655로 해결되었습니다.

Chart merge request가 제출될 때, 이상적으로는 Operator에서 의존성이 있는 Chart merge request와 함께하는 merge request가 열려야 했습니다. 이 접근 방식은 Chart에 대한 변경 사항이 Operator의 맥락에서 고려되도록 보장하며,

팀이 두 구성 요소가 가능한 한 원활하게 함께 작동하도록 하는 데 도움을 줍니다.

GitLab Chart 변경에 따른 영향 평가

Chart에 대한 변경을 제출할 때 Operator에 대한 영향을 고려해야 합니다. 이는 Chart merge request 템플릿의 승인 체크리스트 항목에 포함되어 있으며,

상기 사항을 상기시켜 줍니다.

참고:

이를 테스트하기 위한 자동화된 메커니즘 제공이 Chart issue 4900에서 조사되고 있습니다.

변경이 Operator에 미치는 영향을 평가하기 위해,

변경 사항이 Operator에 의해 자동으로 수집될지 여부를 고려합니다.

확실히 이를 수행하는 유일한 방법은 Operator 코드베이스를 수동으로 검사하고, Chart에서 소스된 리소스에 대한 관련 참조를 검색하며,

Operator가 조정을 필요로 하는 관련 변경 사항과 어떻게 상호작용하는지 확인하는 것입니다.

그동안, 다음의 예는 위험한 것으로 간주됩니다:

  • .metadata.name 및/또는 .metadata.labels와 같은 리소스 이름 또는 레이블링 체계 변경
  • .apiVersion과 같은 리소스 그룹 및/또는 버전 변경
  • 새로운 리소스 추가
  • ServiceAccount 이름 또는 RBAC 정책 변경
  • 보안 컨텍스트 변경
  • Redis 또는 PostgreSQL 차트 버전과 같은 Chart 종속성 업그레이드
  • 주요 릴리스 또는 정지 버전에서 도입된 Chart를 파괴하는 변경

낮은 위험의 변경 예는 다음과 같습니다:

  • 기본값 변경
  • 기존 ConfigMaps에 새로운 구성 키 추가
  • 기존 리소스에 새로운 환경 변수 추가

자동으로 수집되는 변경의 예는 Chart merge request 3247입니다. 이는 Operator가 직접 조작하지 않는 리소스 내부에 새로운 필드를 추가했으며,

단지 렌더링된 Helm 템플릿에서 이를 검색하고 클러스터에서 조정합니다.

MR이 위험하다고 생각되면, Operator 리뷰어 또는 관리자에게 검토를 요청해 주세요.