• 일반적인 개념
• 템플릿 네이밍
• 감지 고려 사항
• 메시지 형식
• 새로운 확인 활성화

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.*의 네이밍 규칙을 따라야 합니다. *은 예를 들어 redis.both와 같이 이 구성이 무엇과 관련이 있는지를 나타내는 정보적인 이름으로 대체되어야 합니다.

감지 고려 사항

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

메시지 형식

모든 메시지는 다음 형식을 가져야 합니다:

chart:
    message

• 메시지 앞의 if 문은 메시지 뒤의 새 줄을 자르지 않아야 합니다. (}}로 끝나야 함, -}}이 아니어야 함) 이렇게 하면 사용자에게 포맷과 가독성이 유지됩니다.
• 메시지는 해당 차트에 상대적인 차트를 선언해야 합니다. 이는 사용자가 구성 값과 차트에서 속성이 나온 위치를 이해하는 데 도움이 됩니다. 예: gitlab.puma, minio, registry.
• 메시지는 사용자에게 실패의 원인이 되는 속성과 취해야 할 조치를 알려야 합니다. 영향을 받는 차트에 상대적인 속성의 이름을 명시해야 합니다. 예를 들어, gitlab.puma.minio.enabled는 영향을 받는 차트가 gitlab.puma인 것으로, 이 에러가 발생한 경우 minio.enabled로 참조되어야 합니다. 여러 차트가 영향을 받는 경우 완전한 속성 이름을 사용하세요.
• 메시지에는 단락을 감싸는 하드한 줄 바꿈이 없어야 합니다. 구성 값이 보간되어 이는 하드한 줄 바꿈을 깨뜨리기 때문입니다.

예시 메시지:

redis: both providers
    `redis.enabled`와 `redis-ha.enabled` 둘 다 true로 보입니다. 이는 정의되지 않은 동작을 유발할 것입니다. 하나만 활성화하세요.

새로운 확인 활성화

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

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