checkConfig 템플릿

이 템플릿의 목적은 알려진 문제있는 구성으로 인해 Helm 차트를 배포하거나 업데이트하는 것을 방지하는 수단을 제공하는 것입니다.

이 설계는 여러 템플릿을 사용하여 선언 및 관리하는 모듈식 방법을 제공하여 개발 및 유지 관리를 간소화하는 데 도움이 됩니다.

일반적인 컨셉

  1. templates/NOTES.txt의 마지막 부분은 templates/_checkConfig.tpl에서 gitlab.checkConfig 템플릿을 include합니다.
  2. gitlab.checkConfig 템플릿은 동일한 파일 내의 추가적인 템플릿을 include하여 그들의 출력(문자열)을 list에 수집합니다.
  3. 각 개별 템플릿은 잘못된 구성을 감지하고 문제를 해결하는 방법에 대한 메시지를 출력하거나 아무것도 출력합니다.
  4. gitlab.checkConfig 템플릿은 수집된 메시지가 있는지 확인합니다. 메시지가 있는 경우 fail 함수를 사용하여 그것들을 CONFIGURATION: 헤더 아래에 출력합니다.
  5. fail 함수는 배포 프로세스를 중단시켜 사용자가 손상된 구성으로 배포하는 것을 방지합니다.

템플릿 명명

이 패턴 내에서 정의된 및 사용되는 템플릿은 gitlab.checkConfig.*의 명명 규칙을 따라야 합니다. * 여기에 알려진 이름과 같은 정보가 포함된 이름으로 바꿉니다.

감지 시 고려사항

개발자는 키나 상위 키가 존재할 것이라고 가정해서는 안 됩니다. if, hasKey, empty의 신중한 적용이 강력히 권장됩니다. 단일 키가 존재할 확률만큼이나 해당 키 이전의 여러 가지 브랜치가 누락되어 전체 속성 맵이 없을 수도 있습니다. Helm에서는 일반적으로 모호한 방식으로 맵 구조 내에서 존재하지 않는 속성에 액세스하려고 하면 불평할 것입니다. 시간을 절약하려면 명확하게 하세요.

메시지 형식

모든 메시지는 다음 형식을 따라야 합니다: 


chart:
    message
  • 메시지 앞의 if문은 메시지 이후의 줄바꿈을 잘라내서는 안 됩니다. (}}로 닫아야 합니다. -}} 아니라는 점에 유의하십시오.) 이렇게 해야 사용자가 포맷을 알아볼 수 있습니다.
  • 메시지에는 속성 맵을 기준으로 하는 속성을 사용자에게 알려주어야 합니다. 이는 사용자가 차트 및 구성 속성에서 속성이 어디에서 왔는지를 이해하는 데 도움이 됩니다. 예: gitlab.puma, minio, registry.
  • 메시지에는 실패의 원인이 되는 속성 및 취해야 할 조치를 사용자에게 알려주어야 합니다. 영향을 받는 차트에 상대적인 속성의 이름을 지정하세요. 예를 들어, 폐기의 영향을 받는 차트가 gitlab.puma이므로 gitlab.puma.minio.enabled를 minio.enabled로 참조합니다. 한 개 이상의 차트가 영향을 받는 경우 전체 속성 이름을 사용합니다.
  • 메시지에는 단락을 랩핑하기 위한 하드한 줄 바꿈이 없어야 합니다. 왜냐하면 메시지가 구성 값을 보간할 수 있고, 이러한 값은 하드 랩핑을 깨뜨릴 수 있기 때문입니다.

예시 메시지: 


redis: both providers
    `redis.enabled` 및 `redis-ha.enabled`이 모두 true로 보입니다. 이는 정의되지 않은 동작으로 이어질 것입니다. 한 가지만 활성화하세요.

새로운 검사 활성화

템플릿이 정의되고 해당 템플릿 내에 영향을 받는 속성을 감지하기 위한 로직을 배치하면 새로운 템플릿을 활성화하기가 간단합니다. 간단히 제시된 형식에 따라 gitlab.checkConfig 템플릿에 add templates here 아래에 한 줄을 추가하면 됩니다.

해당하는 테스트는 spec/integration/check_config_spec.rb에 있습니다.