디자인 결정

이 문서는 이 리포지터리의 Helm 차트 디자인에 관한 이유와 결정 사항을 모았습니다. 제안은 환영합니다. 의사 결정 방법에 대해서는 의사 결정을 참조하십시오.

문제가 될 수 있는 구성 사항 파악 시도

이 차트의 복잡성과 유연성 수준으로 인해, 일부 중첩이 있으며, 예측할 수 없거나 또는 완전히 기능하지 않는 배포로 이어질 수 있는 구성을 생성할 수 있는 경우가 있습니다. 알려진 문제가 있는 설정 조합을 방지하기 위해, 사용자에게 구성이 작동하지 않을 수 있다는 경고 메시지를 감지하고 표시하도록 설계된 템플릿 논리를 구현했습니다.

이는 폐기를 모방하지만, 기능적인 구성을 보장하기 위한 것입니다.

!757 checkConfig: add methods to test for known errors에서 도입됨

폐기를 통한 변경 사항

이 차트의 개발 과정에서 가끔씩 기존 배포의 속성을 변경해야 하는 개선 사항을 가끔씩 만듭니다. 예를 들어, MinIO의 사용, 외부 오브젝트 스토리지 구성의 속성에서 시크릿으로의 마이그레이션 등이 있습니다.

기능하지 않는 설정으로 업데이트된 버전을 실수로 배포하는 것을 방지하기 위해 우리는 폐기 알림을 구현하기로 결정했습니다. 이러한 알림은 속성의 위치가 변경되었거나 변경되었거나 제거되었거나 한 것을 감지하고 사용자에게 구성을 수정해야 하는 변경 사항에 대해 알립니다. 이는 사용자에게 속성을 시크릿으로 교체하는 방법에 대한 문서를 참조하라는 내용을 포함할 수도 있습니다. 이러한 알림은 Helm install 또는 upgrade 명령을 구문 분석 오류로 중단시키고 해결해야 할 모든 항목의 완전한 디렉터리을 출력합니다. 사용자가 오류, 수정, 반복의 루프에 빠지지 않도록 주의를 기울였습니다.

모든 폐기 사항은 성공적인 배포를 위해 해결되어야 합니다. 우리는 사용자가 예상치 못한 동작이나 디버깅이 필요한 완전한 실패를 경험하는 대신에 변경 사항에 대해 알림을 받길 원할 것으로 믿습니다.

!396 Deprecations: implement buffered list of deprecations에서 도입됨

initContainer에서 환경보다 시크릿을 선호

컨테이너 생태계의 많은 부분이 환경 변수를 통해 구성될 수 있거나 예상한다. 이 구성 관행은 12요소 애플리케이션 개념에서 온 것입니다. 이는 여러 배포 환경에서의 구성을 크게 단순화하지만 연결 암호 및 개인 키와 같은 연결 시크릿을 컨테이너 환경을 통해 전달하는 데 보안상의 우려가 남아 있습니다.

대부분의 컨테이너 생태계는 실행 중인 컨테이너의 상태를 검사할 수 있는 간단한 방법을 제공합니다. 이는 보통 환경을 포함합니다. dind와 같은 특권 컨테이너가 이미 돌고 있는 환경 node의 어떠한 컨테이너의 환경을 검사할 수 있고, 그 안에 포함된 모든 시크릿을 노출시킬 수 있습니다. 완전한 DevOps 라이프사이클의 일부로써, dind는 정기적으로 레지스트리에 푸시되고 후에 배포될 컨테이너를 빌드하는 데 사용됩니다.

이 우려 때문에 우리는 민감한 정보를 initContainers를 통해 공급하는 것을 선호하는 결정을 했습니다.

관련된 이슈:

글로벌 차트에서 배포되는 하위 차트

이 리포지터리의 모든 하위 차트는 글로벌 차트를 통해 배포되도록 설계되었습니다. 각 컴포넌트는 여전히 개별적으로 배포될 수 있지만 글로벌 차트에서 용이하게 유지되는 공통 속성을 사용합니다.

이 결정은 리포지터리 전체의 사용 및 유지보수를 간소화합니다.

관련 이슈:

gitlab/*의 템플릿 부분은 가능한 한 글로벌해야 함

gitlab/*의 모든 템플릿 부분은 글로벌 또는 GitLab 하위 차트 templates/_helpers.tpl의 일부여야 합니다. 포크된 차트의 템플릿은 그 차트의 일부로 남아 있을 것입니다. 이렇게 함으로써 포크의 유지보수 영향을 줄일 수 있습니다.

이에 따른 이점은 명확합니다:

  • 증가된 DRY 동작으로 인한 쉬운 유지보수. 여러 하위 차트 전체에서 동일한 함수가 중복되어 있을 필요가 없어야 합니다.
  • 템플릿 이름 충돌을 줄임. 차트의 모든 부분은 함께 컴파일되기 때문에, 이러한 템플릿을 글로벌 동작처럼 다룰 수 있습니다.

관련 이슈:

포크된 차트

다음 차트는 포킹 지침에 따라 이 리포지터리에서 포크되거나 다시 생성되었습니다.

Redis

GitLab Helm 차트의 3.0 릴리스에서는 더 이상 상류 Redis 차트를 포크하지 않고 의존성으로 포함합니다.

Redis HA

Redis-HA는 3.0 이전에 릴리스에 포함된 차트였습니다. 이제 상류 Redis 차트로 대체되어 선택적인 HA 지원이 추가되었습니다.

MinIO

MinIO 차트는 상류 MinIO에서 변경되었습니다.

  • 속성을 통해 새로운 시크릿을 생성하는 대신 기존의 Kubernetes 시크릿을 사용합니다.
  • 환경을 통해 민감한 키를 제공하는 것을 제거합니다.
  • defaultBucket.* 속성 대신 defaultBuckets를 통해 여러 버킷을 자동으로 생성합니다.

registry

registry 차트는 상류 docker-registry에서 변경되었습니다.

  • 차트 내 MinIO 서비스 사용 가능하도록 활성화합니다.
  • 인증을 GitLab 서비스에 자동으로 연결합니다.

NGINX Ingress

NGINX Ingress 차트는 상류 NGINX Ingress에서 변경되었습니다.

  • TCP ConfigMap을 차트 외부로 허용하는 기능 추가
  • 릴리스 이름에 따라 템플릿화된 Ingress 클래스를 허용하는 기능 추가

차트 전반에 걸쳐 사용된 Kubernetes 버전

다양한 Kubernetes 버전의 지원을 극대화하기 위해 현재 안정 버전의 Kubernetes보다 하위 버전 한 단계 낮은 kubectl을 사용하십시오. 이렇게 하면 적어도 3개의 Kubernetes 하위 버전을 지원할 수 있을 것입니다. kubectl 버전에 대한 자세한 토론은 이슈 1509를 참조하십시오.

관련된 이슈:

관련된 머지 요청:

CNG로 배포된 이미지 변형

날짜: 2022-02-10

CNG 프로젝트는 Debian과 UBI를 기반으로 하는 이미지를 배포합니다. 두 배포에 대한 구성을 유지하기로 결정된 이유는 다음과 같습니다:

  • Debian 기반 이미지를 배포하는 이유:
    • 기록, 선례
    • 배포에 대한 익숙함
    • 커뮤니티 대기업
    • 인식된 공급업체 락인 부재
  • UBI 기반 이미지를 배포하는 이유:
    • 일부 고객 환경에서 필요
    • RHEL 인증 및 OpenShift Marketplace / RedHat Catalog 포함을 위해 필요

이 주제에 대한 더 자세한 토론은 이슈 #3095에서 찾을 수 있습니다.

Kubernetes 릴리스 지원 정책

날짜: 2024-03-26

GitLab은 Kubernetes의 세 가지 마이너 릴리스를 공식으로 지원할 것입니다: N, N-1, 그리고 N-2. N은 다음 중 하나입니다:

  • 최신 릴리스된 Kubernetes의 마이너 버전, 적합성 검사를 완료했다면
  • 만약 최신 릴리스의 마이너 버전을 아직 검사하거나 시작하지 않았다면, 다음으로 최근한 마이너 버전

예를 들어, 현재 사용 가능한 릴리스가 1.28, 1.27, 1.26, 1.25이고, 릴리스 1.28을 검사하지 않았다면, N은 1.27이 되며, 다음 표와 같이 1.25, 1.26, 1.27 릴리스를 공식으로 지원할 것입니다.

릴리스 레퍼런스
1.27 N
1.26 N-1
1.25 N-2

세부 정보는 배포 팀 Kubernetes 및 OpenShift 릴리스 지원 정책에서 확인할 수 있습니다.

OpenShift 릴리스 지원 정책

날짜: 2024-03-26

GitLab은 OpenShift의 네 가지 마이너 릴리스를 공식으로 지원할 것입니다 – N, N-1, N-2, 그리고 N-3. Kubernetes와 마찬가지로, N은 다음 중 하나입니다:

  • 최신 릴리스된 OpenShift의 마이너 버전, 적합성 검사를 완료했다면
  • 만약 최신 릴리스의 마이너 버전을 아직 검사하거나 시작하지 않았다면, 다음으로 최근한 마이너 버전

예를 들어, 현재 사용 가능한 릴리스가 4.14, 4.13, 4.12, 4.11이고, 릴리스 4.15를 검사하지 않았다면, N은 4.14가 되며, 다음 표와 같이 4.14, 4.13, 4.12, 그리고 4.11 릴리스를 공식으로 지원할 것입니다.

릴리스 레퍼런스
4.14 N
4.13 N-1
4.12 N-2
4.11 N-2

세부 정보는 배포 팀 Kubernetes 및 OpenShift 릴리스 지원 정책에서 확인할 수 있습니다.