Helm 차트 개발에 기여하기

우리의 기여 정책은 CONTRIBUTING.md에서 찾을 수 있습니다.

차트에 대한 문서 변경에 참여하려면 텍스트 편집기만 있으면 됩니다. 문서는 doc/ 디렉토리에 저장되어 있습니다.

아키텍처

개발을 시작하기 전에 차트의 목표, 아키텍처, 설계 결정을 검토하는 것이 도움이 됩니다.

이 정보는 GitLab Helm 차트의 아키텍처에서 확인할 수 있습니다.

환경 설정

차트 개발을 위해 워크스테이션을 준비하려면 개발 환경 설정을 참조하십시오.

스타일 가이드

차트 개발을 위한 지침과 모범 사례는 차트 개발 스타일 가이드를 참조하십시오.

테스트 작성 및 실행

차트가 의도한 대로 작동하는지 유효성을 검사하기 위해 여러 유형의 테스트를 실행합니다.

RSpec 테스트 작성

유닛 테스트는 RSpec으로 작성되며 차트 저장소의 spec/ 디렉토리에 저장됩니다.

차트의 기능을 검증하기 위해 RSpec 테스트 작성에 대한 노트를 읽어보세요.

Bats 테스트 작성

쉘 스크립트의 함수를 위한 유닛 테스트는 bats로 작성되며 차트 저장소의 scripts/ 디렉토리에 해당 스크립트 파일과 함께 저장됩니다.

이 프로젝트에서 사용되는 스크립트의 함수를 검증하기 위해 bats 테스트 작성에 대한 노트를 읽어보세요.

GitLab QA 실행

GitLab QA를 사용하여 배포된 클라우드 네이티브 GitLab 설치에 대해 통합 및 기능 테스트를 실행할 수 있습니다.

GitLab QA 차트 문서에서 자세히 알아보세요.

ChaosKube

ChaosKube를 사용하여 고가용성 클라우드 네이티브 GitLab 설치의 내결함성을 테스트할 수 있습니다.

ChaosKube 차트 문서에서 자세히 알아보세요.

ClickHouse

GitLab과 외부 ClickHouse 서버를 구성하기 위한 지침.

버전 및 릴리스

버전 체계, 브랜치 및 태그에 대한 자세한 내용은 릴리스 문서에서 확인할 수 있습니다.

변경 로그 항목

모든 CHANGELOG.md 항목은 변경 로그 항목 작업 흐름을 통해 생성되어야 합니다.

파이프라인

GitLab CI 파이프라인은 다음과 같이 실행됩니다:

  • 병합 요청
  • 기본 브랜치
  • 안정적인 브랜치
  • 태그

이러한 CI 파이프라인의 구성은 다음에서 관리됩니다:

리뷰 앱

CI에서 Review 앱을 사용하여 Helm 차트의 실행 인스턴스를 배포하고 그에 대한 테스트를 실행합니다.

이 Review 앱을 EKS 및 GKE 클러스터에 배포하고 Helm 릴리스가 성공적으로 생성되었는지 확인한 후 GitLab QA 및 다른 RSpec 테스트를 실행합니다.

특히 병합 요청의 경우, vcluster를 사용하여 순간적 클러스터를 생성합니다. 이를 통해 쉽게 구성하고 External DNS나 Cert Manager 종속성이 없는 단순화된 환경을 통해 Kubernetes의 새로운 버전에 대해 더 빨리 테스트할 수 있습니다. 이 경우 Helm 차트를 단순히 배포하고 릴리스가 성공적으로 생성되었는지 확인하며 Webservice가 Ready 상태에 있는지 유효성을 검사합니다. 이 접근 방식은 응용 프로그램이 건강한 상태에 있는지 확인하기 위해 Kubernetes readiness probes를 활용합니다. vcluster 구현 계획에 대한 자세한 내용은 issue 5013을 참조하세요.

리뷰 앱 관리

리뷰 앱은 기본적으로 두 시간 동안 활성 상태로 유지되며 해당 CI 작업에 의해 자동으로 중지됩니다. 이 프로세스는 다음과 같이 작동합니다:

  1. create_review_* 작업은 Review App 환경을 생성합니다.
    • 이러한 작업은 환경 정보를 echo만 합니다. 이렇게 하면 이러한 작업이 실패하지 않고 환경을 일관되게 생성하고 이후 CI 작업에 의해 자동으로 중지되지 않게 할 수 있습니다.
  2. review_* 작업은 환경에 Helm 차트를 설치합니다.
  3. 변수 REVIEW_APPS_AUTO_STOP_IN에 정의된 기간 이후 stop_review_* 작업이 실행됩니다.

하나 이상의 review_* 작업이 실패했음을 알고 환경을 디버깅해야 하는 경우 다음을 수행할 수 있습니다:

  1. 관련된 create_review_* 작업을 찾습니다.
  2. 작업 페이지 상단에서 This job is deployed to <cluster>/<commit>와 같은 제목의 환경 링크를 클릭합니다.
  3. 환경 페이지의 오른쪽 상단에 다음과 같은 버튼이 표시됩니다:
    • 환경 고정: 핀 아이콘이 있는 이 버튼을 누르면 해당 환경이 자동으로 중지되는 것을 방지합니다. 이를 클릭하면 stop_review_* 작업이 취소됩니다. 디버깅을 마친 후 이 작업을 수동으로 실행해야 합니다. 환경 디버깅에 더 많은 시간이 필요한 경우 이 옵션이 유용합니다.
    • 배포 보기: 이 버튼을 클릭하면 실행 중인 GitLab의 환경 URL이 열립니다.
    • 중지: 이 버튼을 클릭하면 연관된 stop_review_* 작업이 실행됩니다.

상위 스트림 차트를 fork하기로 결정할 때

변경 사항이 없으면 fork하지 않음

우리의 사용을 위해 기능을 변경할 필요가 없는 모든 차트는 이 리포지토리로 fork되어서는 안 됨을 명시합니다.

fork 위한 지침

민감한 정보

특정 차트가 환경 내부에서 민감한 통신 비밀을 요구한다면 (예: 비밀번호 또는 암호화 키), initContainers를 사용하는 것이 우선.

기능 확장

상위 스트림이 수용하지 않을 정도로 차트의 기능을 확장해야 하는 경우 몇 가지 경우가 있습니다.

구성 구체화 처리

개발 중에는 동작 변경이 기능적으로 파괴적인 변경을 요구하는 경우가 있습니다. 이러한 변경을 피하려고 노력하지만, 일부 항목은 이러한 변경 없이 처리할 수 없을 수 있습니다.

이를 처리하기 위해 구체화 템플릿을 구현했습니다. 이 템플릿은 대체하거나 이동해야 하는 속성을 인식하고 사용자에게 필요한 조치를 알리도록 설계되었습니다. 이 템플릿은 모든 메시지를 목록으로 컴파일한 다음, fail 호출을 통해 배포를 중지시킵니다. 이렇게 하면 배포를 중지함과 동시에 차트가 손상되거나 예상치 못한 상태로 되지 않도록 사용자에게 알릴 수 있는 방법을 제공합니다.

디자인, 기능 및 새로운 구체화 추가 방법에 대한 자세한 내용은 구체화 템플릿 문서를 참조하세요.

문제가 될 수 있는 구성을 파악하기 위한 시도

이러한 차트의 복잡성과 유연성 수준으로 인해 예측할 수 없거나 완전히 기능이 작동하지 않는 배포로 이어질 수 있는 구성을 생성할 수 있는 겹치는 상황이 있습니다. 이미 알려진 문제가 있는 설정 조합을 방지하기 위해 다음 두 가지 패턴을 적용했습니다.

  • 모든 하위 차트에 대한 스키마 유효성 검사를 사용하여 사용자 지정 값이 기대치를 충족하는지 확인합니다. 더 자세한 내용은 문서를 참조하세요.
  • 사용자의 구성이 작동하지 않을 것으로 감지하고 경고하는 템플릿 로직을 구현했습니다. 디자인, 기능 및 새로운 구성 확인을 추가하는 방법에 대한 자세한 내용은 checkConfig 템플릿 문서를 참조하세요.

레지스트리 확인

개발 모드에서 Docker 클라이언트로 레지스트리를 확인하는 것은 어려울 수 있습니다. 이는 레지스트리의 인증서 문제 때문입니다. 인증서를 추가하거나 HTTP를 통해 레지스트리를 노출할 수 있습니다 (global.hosts.registry.https 참조). 인증서를 추가하는 것이 보안상 더 안전합니다.

레지스트리는 MinIO 서비스의 외부 도메인 이름( global.hosts.minio.name 참조)을 사용합니다. 개발 환경에 사용자 지정 TLD를 사용할 경우와 같은 내부 도메인 이름을 사용하면 오류가 발생할 수 있습니다. 일반적인 증상은 레지스트리에 로그인할 수 있지만 이미지를 푸시하거나 끌어올 수 없는 것입니다. 이는 레지스트리 컨테이너가 MinIO 도메인 이름을 해결하고 올바른 엔드포인트를 찾을 수 없기 때문입니다(컨테이너 로그에 오류가 표시됩니다).

개발 환경의 문제 해결

새로운 차트 기능을 작업하는 동안 개발자는 고유한 문제에 직면할 수 있습니다. 문제 해결 안내에서 개발 클러스터에 이상한 문제가 있는 경우의 정보를 참조하세요.

참고: 위의 링크에 나온 문제 해결 단계는 개발 클러스터 전용입니다. 이러한 절차를 프로덕션 환경에서 사용하지 마세요. 그러면 데이터가 손실될 수 있습니다.

추가 Helm 정보

내부 Helm 작업 동작에 대한 일부 정보: