GitLab Charts에 대한 종속성

GitLab Operator(또는 “Operator”로만 알려짐)는 GitLab Helm Charts (또는 “Chart”로만 알려짐)에 의존합니다. ADR 0004에서 설명한 대로입니다.

GitLab Chart 변경 사항에 따른 영향 파악

Operator가 Chart의 새 버전을 흡수할 때, Chart 내의 변경 사항도 함께 흡수합니다. 때로는 Chart의 변경 사항을 지원하기 위해 Operator를 조정해야 하는 경우도 있습니다.

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

Chart의 병합 요청이 제출될 때, 이상적으로는 Operator에 대한 동반되는 병합 요청도 열려야 하고, Chart의 병합 요청에 종속된 것으로 표시되어야 합니다. 이 방식은 Chart의 변경 사항이 Operator의 맥락에서 고려되도록 하여 두 구성 요소가 가능한 원활하게 함께 작동하도록 돕습니다.

GitLab Chart 변경 사항에 따른 영향 평가

Chart에 변경 사항을 제출할 때 Operator에 대한 영향을 고려해야 합니다. 이 항목은 Chart의 병합 요청 템플릿의 승인 체크리스트에 기억할 것으로 포함되어 있습니다.

Operator에 대한 Chart 변경 사항의 영향을 평가하려면, 변경 사항이 Operator에 자동으로 흡수되는지 여부를 고려해야 합니다. 이를 확실하게 하는 유일한 방법은 Operator 코드베이스를 수동으로 검토하여 Chart에서 가져온 리소스에 대한 관련 참조를 찾고, Operator가 조정이 필요한 관련 변경과 상호 작용하는지 여부를 확인하는 것입니다. 이에 대한 자동화된 테스트 메커니즘을 제공하는 것은 Chart 이슈 4900에서 조사 중입니다.

그 동안 다음 예시는 가능한 영향을 식별하는 데 도움이 될 수 있습니다:

  • .metadata.name 또는 .metadata.labels와 같은 리소스 명명 또는 레이블링 체계 변경
  • .apiVersion과 같은 리소스 그룹 또는 버전의 변경
  • ServiceAccount 이름 또는 RBAC 정책 변경
  • Redis 또는 PostgreSQL Chart 버전과 같은 Chart 종속성 업그레이드
  • 주요 릴리스 또는 중단 버전에서 도입된 Chart 파손 변경

자동으로 흡수되는 변경 사항의 예시로는 Chart의 병합 요청 3247이 있습니다. 이는 Operator가 직접 조작하지 않고, 렌더링된 Helm 템플릿에서 가져와 클러스터에서 조정하는 리소스 내에 새로운 필드를 추가했습니다.