GitLab 차트에 대한 종속성

GitLab Operator(또는 “Operator”로도 알려짐)는 GitLab Helm Charts (또는 “차트”로도 알려짐)에 의존합니다. 이것은 ADR 0004에서 설명되어 있습니다.

GitLab Chart 변경사항의 영향 파악

Operator가 새로운 차트 버전을 수용할 때, 차트 내부의 변경사항도 함께 수용됩니다. 때로는 차트의 변경에 맞게 Operator를 조정해야 하는 경우가 있습니다.

예를 들어, Chart의 병합 요청 3278에서는 NGINX Ingress Controller 이미지 태그 버전이 업데이트되었으며, 해당 변경을 지원하기 위해 NGINX RBAC 객체도 업데이트되었습니다. 이로 인해 Operator의 이슈 1324가 발생하여 master 브랜치의 파이프라인이 실패했습니다. 문제는 Operator의 병합 요청 655로 해결되었습니다.

차트의 병합 요청을 제출할 때, 이상적으로 Operator에서도 해당 차트의 병합 요청에 의존하는 병합 요청이 함께 열려야 합니다. 이러한 접근 방식은 차트의 변경사항이 Operator의 맥락에서 고려되어 두 구성 요소가 가능한 원활하게 작동하도록 도와줍니다.

GitLab Chart 변경사항의 영향 평가

차트에 변경사항을 제출할 때 Operator에 대한 영향도 고려되어야 합니다. 이것은 차트 병합 요청 템플릿의 승인 체크리스트 항목으로 포함되어 있어야 하며, 이를 상기시키는 역할을 합니다.

참고: 이를 테스트하는 자동화된 매커니즘이 Chart의 이슈 4900에서 조사되고 있습니다.

Operator에 대한 차트 변경사항의 영향을 평가할 때, 변경사항이 Operator에 자동으로 수용되는지 여부를 고려해야 합니다. 이를 확실히 확인하는 유일한 방법은 Operator 코드베이스를 수동으로 검토하여 차트에서 가져온 리소스에 대한 관련 참조를 찾고, Operator가 관련 변경사항과 조율되도록 조정이 필요한지 확인하는 것입니다.

그 동안 다음과 같은 예가 위험성이 있는 것으로 간주됩니다:

  • .metadata.name 및/또는 .metadata.labels와 같은 리소스 명명 또는 라벨링 체계의 변경
  • .apiVersion과 같은 리소스 그룹 및/또는 버전의 변경
  • 새로운 리소스 추가
  • ServiceAccount 이름 또는 RBAC 정책 변경
  • 보안 컨텍스트 변경
  • Redis 또는 PostgreSQL 차트 버전과 같은 차트 종속성 업데이트
  • 주요 릴리스에서 도입되거나 릴리스 버전을 중단시키는 차트 파괴적인 변경

저위험 변경사항의 예는 다음과 같습니다:

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

Operator가 직접 조작하는 것이 아닌 차트의 렌더링된 Helm 템플릿에서만 가져와 클러스터에서 조율하는 리소스 안에 새로운 필드를 추가한 것처럼 변경이 자동으로 수용되는 예는 Chart의 병합 요청 3247입니다.

MR을 위험성이 있는 것으로 판단한다면, Operator 리뷰어 또는 유지 관리자로부터 리뷰를 요청하십시오.