관련 요청: #2566

나는 이것에 대한 작업을 시작했습니다.
#2566에 대한 의견을 고려할 때 --values ​​또는 --set(또는 둘 다?)을 찾고 있습니까?

내가 열었던 문제( #3198 )에 좋은 사용 사례가 설명되어 있습니다.

helm package --version 1.2.3 --set image.tag 1.2.3

이렇게 하면 차트 버전과 도커 이미지 버전이 하나가 됩니다.

방금 첫 번째 초안을 완성하고 이에 대한 PR을 게시했습니다.

@ngeor , @slavic 제가 제출한 PR은 --set 및 --values ​​옵션을 모두 추가합니다. 한 번 봐주시겠습니까?

안녕하세요 @adshmh , 좋아 보입니다. 불행히도 나는 Go를 모르지만 테스트 케이스와 모든 것으로 당신이 그것을 덮은 것을 보았으므로 아마도 그것이 말하는 대로 할 것입니다 :) 감사합니다!

이 기능은 언제 사용할 수 있습니까? 2.9.0에서?

3471은 2.9의 기한을 놓쳤으므로 2.10이 됩니다.

#3471을 취소해야 하므로 이것을 다시 엽니다.

이것은 아카이브 패키지의 주석/기타에 무엇을 합니까? 예를 들어, 벗겨지거나 혼자 남겨지거나 ??

현재 yq 로 동일한 작업을 시도하고 있지만 처리 후 최종 값만 덤프합니다. 즉, 모든 주석, 정리를 위한 빈 줄 등이 사라졌습니다.

3471은 모든 주석을 제거했기 때문에 해당 PR을 취소해야 했습니다. 자세한 내용은 https://github.com/kubernetes/helm/pull/3471#issuecomment -381779783을 참조하세요.

2.10 "feat: 'helm 패키지'에 --set 및 --values ​​옵션 추가"에서 되돌려졌습니다. https://github.com/helm/helm/commit/7b8aae466761448522acbd3beb2a16ad2283013a

이것에 대한 소식이 있습니까?
감사 해요

같은 상기와; 아무도 #3471의 버그를 수정하기 위해 후속 조치를 취하지 않았으므로 이것이 구현되지 않았습니다. 값 파일에서 주석을 제거해도 괜찮다면 Helm을 분기하고 #3471에 대해 컴파일하는 것을 환영합니다.

완료되었나요? 2.11.0 및 2.12.0 버전에서 시도했는데 $#$2 helm package --set... #$가 없는 것 같습니다.

+1. 패킹하기 전에 yamls의 값을 전달하고 업그레이드하는 것을 중지하기 위해 CI에서 정말 도움이 될 것입니다.

+1

--set-string도 유용할 수 있습니다. 설치/업그레이드에 있는 모든 재정의 옵션을 허용하지 않는 이유는 무엇입니까?
패키지 명령의 값을 재정의하는 데 사용된 것과 동일한 코드를 실행하기만 하면 패키지에 재정의 값이 있다는 것이 이해가 됩니다. 이러한 플래그는 설치/업그레이드와 마찬가지로 공유되어야 합니다.

2.13.1 에도 그런 기능이 없는데 시간표가 있나요?

앞서 언급했듯이 현재 아무도 이 문제에 대해 작업하고 있지 않으며 언제 수정 프로그램을 사용할 수 있는지에 대한 일정도 없습니다. 부담 없이 이 옷을 입으십시오. 아이디어는 #3471을 참조하십시오.

Helm 3 에서 구현되었습니다 . 폐쇄!

코드를 보면 #3471이 실수로 Helm 3에 들어간 것으로 보이지만 다음 주석으로 인해 Helm 2에서와 같이 제거되지 않았습니다. https://github.com/helm/helm/pull/3471#issuecomment -381779783

https://github.com/helm/helm/pull/7201을 사용하여 Helm 3에서 --set 및 --values ​​플래그를 제거할 때 이 기능 요청을 다시 엽니다. 그들은 어쨌든 작동하지 않았습니다... --set 또는 --values 를 통해 설정된 모든 것은 패키지에 주입되지 않았으며 helm package 로 치명적인 회귀를 도입했습니다. 여러 커뮤니티 구성원이 문서로 사용하는 values.yaml에서 주석을 출력합니다.

아마도 내가 오해하고 있을지 모르지만 나는 행복하게 --set with package 를 사용하여 값을 설정했으며 3.0.0에서 3.0.2까지 훌륭하게 작동했으며 확실히 #7201에 설명된 "no-op"이 아닙니다.

내 파이프라인은 3.0.3부터 손상되었습니다. 이것은 3.0.2에서 작동했습니다. --version 및 --app-version이 있는 경우 이것이 유용한 것으로 간주되지 않는 이유는 무엇입니까? --app-version 과 일치하도록 이미지와 태그를 어떻게 편집해야 합니까? 배쉬?

코드를 다시 보면 @lukaslarson 및 @maxhillaert가 맞습니다. 그러나 이것은 패키지의 값 파일에서 모든 주석을 제거할 때 되돌리기 위한 기능이었습니다. Helm 2에서 제거되었지만 실수로 Helm 3에 들어갔습니다. 배송될 예정이 아니었습니다.

누군가 의견을 유지하는 #3471 다시 구현 작업을 원하면 PR을 살펴보겠습니다.

@bacongobbler 이것은 우리를 위해 몇 가지를 망쳤습니다. PR 작업에 관심을 갖고 싶지만 사소하지 않은 것 같아서 접근 방식을 확인하고 싶습니다.

gopkg.in/yaml.v3 는 왕복 이동 시 댓글 유지를 지원하는 것 같습니다. 내 제안은 Values yaml Node 을 만드는 것입니다. 그런 다음 값을 통합할 때 중첩 맵이 아닌 구문 분석된 출력 트리를 살펴봅니다. 이것은 확실히 덜 인체공학적이지만 주석을 보존하는 가장 좋은 방법입니다.

기본 라이브러리의 v2 에 고정된 모든 곳 sigs.k8s.io/yaml 를 사용하고 있기 때문에 이것은 약간의 문제입니다. 최소한 이것은 별도의 종속성으로 도입해야 하며, 이는 일종의 엉터리입니다. 여기서 가장 좋은 접근 방식은 yaml을 다루는 모든 것을 건드리지 않는 것입니다.

가장 좋은 옵션은 yaml.v3으로 마이그레이션하는 것이므로 올바른 방향으로 가고 있는 것 같습니다.

sig.k8s.io/yaml 대신 yaml.v3을 사용하는 Helm의 PoC/포크 작업을 시작하려는 경우 좋은 경로가 될 것입니다. 그렇게 하면 master 에 있는 것과 비교하여 기능을 평가할 수 있습니다.

yaml.v3이 최선의 경로임을 확인한 후에는 SDK의 관점에서 진행하는 방법을 파악할 수 있습니다.

차단 해제에 도움이 되나요?

@jmcelwain 적극적으로 작업하고 있습니까? 그렇지 않은 경우 기꺼이 인수하겠습니다.

@reya92 일이 바빠요. 여기에서 중단했습니다. yaml.v3으로 전환하는 것은 이 부분을 제외하고는 대부분 쉬웠 습니다 . 종속성을 공급하고 v3으로 업데이트하지 않고 이를 처리하는 가장 좋은 방법이 무엇인지 확신할 수 없었습니다.

업그레이드를 위한 작업이 있었던 것 같은데 , 이슈 등에 대한 다른 정보는 없고 귀찮아서 이슈를 열지 않았습니다. 다른 옵션은 두 가지 종속성을 모두 유지하는 것이지만 이는 징그럽게 보입니다.

내 개인적인 의견은 유지 관리자가 유사한 라이브러리의 두 복사본을 가지고 다니는 것이 가치가 있다고 생각하지 않는 한 이것이 이 문제에 대한 차단기라는 것입니다. 여기에 LoE가 무엇인지 확실하지 않지만 github.com/ghodss/yaml을 v3으로 만들고 k8s의 공급업체 버전도 업그레이드해야 합니다. 그러면 이 모든 것이 훨씬 쉬워집니다.

https://github.com/ghodss/yaml/issues/61 을 열어 업그레이드 경로 가능성에 대해 문의했습니다. 다른 작업을 계속하기 전에 응답을 기다리겠습니다. 종속성을 업그레이드하는 것이 다른 옵션 IMO보다 훨씬 좋습니다.

@jmcelwain https://github.com/ghodss/yaml 에는 많은 양의 코드가 없으며 2017년부터 서비스되지 않은 pull 요청이 있습니다: https://github.com/ghodss/yaml/pulls , 코드는 MIT 라이센스.

이 의존성이 정말로 그 무게를 끌어올리고 있습니까? 몇 가지 마샬링 도우미이지만 해결되면 많은 프로젝트가 빌드 시 패키지 기본값을 동적으로 설정하는 기능을 향상시킬 수 있는 문제를 관리하고 있습니다. --set image.tag=${GIT_TAG} 와 같은 것으로 프로젝트의 차트 및 이미지 버전을 고정).

더 이상 기다리지 않고 필요한 코드를 helm에 복사하는 것이 좋습니다. 이 래퍼의 유지 관리를 처리하기에 충분히 큰 프로젝트이며 YAML 마샬링이 핵심 역량이라고 생각합니다(자신의 파서를 유지해야 한다는 말은 아니지만...!)

이것이 지금 우리에게 고통을 주고 있기 때문에(그리고 우리가 helm 3.0.2에서 업그레이드하는 것을 막고 있기 때문에) 기꺼이 그것을 찔러보고 싶습니다.

그런 상황은 피하는 게 좋겠어. 패키지 관리자와 YAML 구문 분석기를 모두 유지 관리할 수 있는 유지 관리자가 충분하지 않습니다. 이는 팀에 상당한 유지 관리 부담을 초래할 것입니다.

@bacongobbler yaml 파서가 _아닙니다_. gopkg.in/yaml.v2 를 사용하여 실제 구문 분석을 수행합니다. 해당 파서 주위에 reflect 래퍼 코드가 약 900줄 있습니다. 문제는 그들이 이 문제를 해결할 gopkg.in/yaml.v3 를 사용하지 않는다는 것입니다.

실제 종속성에 대해 이 사소한 중간을 사용하는 유지 관리 부담이 이 코드를 유지 관리하는 것보다 더 큰 부담인 것 같습니다.

스레드의 앞부분에서 언급했듯이 ghodss/yaml을 yaml.v3으로 업데이트하는 PR 업스트림을 자유롭게 제안하십시오. 그들이 그것을 수락하지 않는다면, 유지 관리 부담을 짊어질 수 있다고 생각되면 자유롭게 프로젝트를 분기하고 유지하십시오.

하지만 분명히 말씀드리겠습니다. 우리는 ghodss/yaml을 Helm으로 분기하고 공급업체인 pull 요청을 수락하지 _않습니다_. 하나의 기능을 지원하기 위해 전체 Go 라이브러리의 추가 유지 관리 부담을 짊어질 수는 없습니다.

@bacongobbler 여기에서 제 PR을 살펴보세요: https://github.com/helm/helm/pull/7963

테스트가 포함되고 불필요한 기능이 제거된 900줄의 코드입니다.

지금 당신은 내가 거기에 추가한 것보다 훨씬 더 큰 공간을 차지하는 상대적으로 관리되지 않은 라이브러리처럼 보이는 것에 의존하고 있습니다.

하나의 기능을 지원하기 위한 전체 Go 라이브러리

이 전체 Go 라이브러리에서 하나의 기능을 모두 사용하고 이를 위해 코드의 출처를 더욱 모호하게 하는 영구적인 포크를 생성하기 위해 노력했습니다.

유지 관리 부담을 짊어질 수 있다고 생각되면 자유롭게 프로젝트를 분기하고 유지 관리하십시오.

내 말은 당신이 이미 이 코드의 단일 목적 포크를 실행하고 있다는 뜻입니다. 프로젝트가 중단되면 원래 작성자의 유지 관리로부터 실제로 이익을 얻지 못합니다.

당신이 원한다면 내 PR에서 그 적은 양의 코드를 가져와서 repo에 넣고 유지하겠다고 말할 수 있지만(그리고 그렇게 하려고 시도할 것입니다), 다소 어리석은 것 같습니다.

하지만 분명히 해두겠습니다. 우리는 ghodss/yaml 및 벤더를 Helm으로 포크하는 풀 리퀘스트를 수락하지 않을 것입니다.

기록을 위해, 이 글을 읽을 즈음에는 이미 그 PR을 밀어냈기 때문에 '벤더링'과 '전체 Go 라이브러리'에 대해 캐시된 생각을 갖고 있다고 생각하기 때문에 다시 생각해 보시기 바랍니다. ) 관련된 코드를 보지 않고. 그러나 PR에서 문제의 실제 코드에 대해 논의해 보겠습니다. 도움이 된다면 이 코드의 코드 소유자가 되어 기쁩니다. 내가 기여로 그것을 썼다고 상상해 봅시다. 나는 일종의 ...

어쩌면 그들은 그것을 병합 할 것입니다 : https://github.com/ghodss/yaml/pull/62

내가 간략하게 살펴본 다른 대안은 다른 종속성을 통해 YAML을 JSON으로 변환하거나 일부 중간 형식을 통해 직렬화하는 가능성이었습니다. 나는 이것이 실행 가능한 경로인지 알기 위해 Go 생태계에 대해 충분히 익숙하지 않습니다. 나는 간략하게 보았을 때 더 많은 직렬화 유형 라이브러리를 찾을 수 없다는 것에 다소 놀랐습니다.

이것을 사용하여 키 패키징을 자동화할 때 --set을 다시 설정할 수 있는 시기에 대한 아이디어가 있습니다. Helm 3.0.2에 있었고 업데이트가 더 이상 지원되지 않기 때문에 지금은.

https://github.com/ghodss/yaml/pull/62 병합이 여전히 차단됩니다.

코드를 다시 보면 @lukaslarson 및 @maxhillaert가 맞습니다. 그러나 이것은 패키지의 값 파일에서 모든 주석을 제거할 때 되돌리기 위한 기능이었습니다. Helm 2에서 제거되었지만 실수로 Helm 3에 들어갔습니다. 배송될 예정이 아니었습니다.

누군가 의견을 유지하는 #3471 다시 구현 작업을 원하면 PR을 살펴보겠습니다.

주석이 제거되는지 여부가 중요합니까? --set 사용에 대한 주의 사항이 있으면 주석에 신경 쓰지 않습니다.

ghods/yaml#62 병합이 여전히 차단됩니다.

나는 3.0.2를 사용하는 데 붙어 있다고 생각합니다 :(

--set 사용 여부에 관계없이 3471개의 댓글이 삭제되었으므로 이 기능을 사용한 적이 없는 사용자를 망쳤습니다. 모든 사람의 이전 버전과의 호환성을 깨뜨렸습니다. 따라서 경고와 함께 다시 도입될 수 없으며 이것이 우리가 업스트림에서 적절한 수정을 기다리는 이유입니다.

이것이 우리가 3.0.2를 고수해야 하는 이유입니다

ghods/yaml#62 병합이 여전히 차단됩니다.

하지만 이 종속성은 더 이상 유지되지 않는 것 같으니 분기된 버전을 사용하는 것이 더 좋지 않을까요?

전환하는 것은 좋은 생각이지만 Helm 4로 연기해야 ​​합니다. 누군가 YAML 파서 전환에 대한 특별 문제를 제출해야 Helm 4 프로세스에서 이를 추적할 수 있습니다.

하지만 분명히 해두겠습니다. 우리는 ghodss/yaml 및 벤더를 Helm으로 포크하는 풀 리퀘스트를 수락하지 않을 것입니다. 하나의 기능을 지원하기 위해 전체 Go 라이브러리의 추가 유지 관리 부담을 짊어질 수는 없습니다.

https://github.com/ghodss/yaml 가 더 이상 유지되지 않고 https://github.com/ghodss/yaml/pull/62 에 로그인이 없는 것 같으면 이 입장을 재고할 가치가 있습니까? 재평가 https://github.com/helm/helm/pull/7963 ?

우리는 하나의 기능에 대해 전체 YAML 구문 분석 라이브러리를 지원하는 유지 관리 부담을 지는 데 관심이 없습니다.

커뮤니티가 ghodss/yaml의 기존 유지 관리자와 협력하여 프로젝트를 지원하거나 프로젝트를 분기하거나 의견을 보존할 수 있는 새 라이브러리를 기꺼이 찾는 새로운 유지 관리자 집합을 찾는 것을 고려할 것을 촉구합니다.

그럼 뭐가 될까요?

• ghodss/YAML을 지원하는 새로운 관리자를 찾으세요!?
• ghodss/YAML을 포크하고 YAML.v3을 사용할 사람을 찾고 계속 지원하세요!!
• YAML.v3을 직접 사용
• helm 4용 YAML 파서를 전환할 것을 제안합니다.

전체 YAML 구문 분석 라이브러리

이것은 여기에 관련된 코드의 범위를 잘못 나타냅니다. 다른 파서를 둘러싼 몇 개의 래퍼입니다.

우리는 하나의 기능에 대해 전체 YAML 구문 분석 라이브러리를 지원하는 유지 관리 부담을 지는 데 관심이 없습니다.

아마도 이 혼란은 많은 것을 설명합니다. 파서는 ghodss/YAML이 아니라 https://github.com/go-yaml/yaml 입니다. https://github.com/ghodss/yaml 에서:

go-yaml을 감싸는 래퍼

따라서 간단한 솔루션은 래퍼 사용을 중지하는 것입니다.

"래퍼"는 일부 동작에 지대한 영향을 미칩니다. 프로젝트 초기에 파서(및 래퍼 라이브러리)를 몇 번 전환한 핵심 유지 관리자는 이들 사이의 작은 불일치, 이것이 어떻게 높은 수준의 호환성 문제를 생성하는지 잘 알고 있습니다.

ghodss/yaml 포크 사용을 고려할 가능성이 있으며 해당 포크 소유자가 지속적인 유지 관리를 약속한 경우에만 가능합니다.

아마도 내가 더 정확할 수 있습니다. 버려진 래퍼 라이브러리 사용을 중지하고 helm에서 동등한/동일한 래핑 동작을 수행합니다. 이는 https://github.com/helm/helm/pull/7963 이 약 ~250 LOC에서 수행하는 것입니다. 테스트.

예, 이상적으로는 누군가가 ghodss/yaml에서 수정하지만 더 이상 유지 관리되지 않습니다. 확실히 대안은 Helm 4까지 기다리고 있지 않습니까?

나는 포크가 아마도 최선의 선택이라고 생각합니다. IMO; @ghodss 는 2019년 초 이후로 GH에 대한 활동이 없는 것으로 보이며 리포지토리에 대한 마지막 커밋은 1년 반 전이었습니다(@bradfitz 작성). 마지막(유일한) 릴리스는 2017년이었습니다. 코드에 잠재적인 보안 문제가 있는 경우 메인에서 수정되지 않습니다.

누군가가 포크를 유지 관리하기로 약속한다면 포크 채택을 강력히 지지합니다. 빈사 상태이고 버려진 패키지를 계속 사용하는 것과 관련하여 어떤 단점도 보이지 않습니다. 다른 래퍼로 이동하는 것이 주요 변경 사항으로 더 합리적이라는 데 동의합니다(Helm 4가 쉽게 될 수 있을 만큼 충분히 무거운 리프트처럼 보이지만 더 이상 추측하지는 않겠습니다). 하지만 이것이 해결될 수 있다고 생각합니다. go.mod 에 replace 라인이 있습니다.

다른 사람도 마찬가지인 경우 포크를 공동 유지 관리하는 데 도움을 줄 의향이 있습니다. 지금은 스스로 할 수 있는 대역폭이 충분하지 않지만 기여할 만큼은 있습니다.

확실히, 저는 Helm 차트를 패키징하기 위해 쌓인 sed 스크립트 더미를 제거할 수 있도록 이 작업에 가장 관심이 있습니다. 하지만 그것이 필요하다면 그렇게 하십시오.

안녕
패키징할 때 값을 설정할 수 있는 플러그인 을 방금 만들었습니다. 현재로서는 set 플래그만 지원하지만(필요한 :sweat_smile: ) 다른 플래그를 추가할 예정입니다. 당신이 그것을 개선하기 위해 비고를 추가하거나 좋아하는 경우 PR을 푸시하는 것을 망설이지 마십시오.
감사합니다

팔로우하지 않은 사람이 있을 경우를 대비하여 ghodss/yaml#62에서 관리자에게 연락하는 과정이 어느 정도 진행되었으므로 곧 좋은 소식을 들을 수 있기를 바랍니다!

이 문제는 90일 동안 활동이 없었기 때문에 오래된 것으로 표시되었습니다. 이 스레드는 더 이상 활동이 발생하지 않으면 30일 후에 자동으로 닫힙니다.

확실히 오래되지 않았습니다. 저는 https://github.com/ghodss/yaml/pull/62 에서 후속 조치를 취하고 이 문제에 대한 진행 상황을 차단 해제하기 위해 병합하는 데 도움이 될 수 있는지 확인하기 위해 시간을 찾고 있습니다. 내 조직에서 Helm에 대한 의존도가 높아짐에 따라 CI별 빌드 패키지 차트에 값을 구울 수 있기를 계속 원합니다.

현재 대화에 아무것도 추가하지 않기 때문에 상태 업데이트를 요청한 모든 댓글을 삭제했습니다. @jmcelwain 은 최소 5일 전에 상태 업데이트를 제공했으며(감사합니다. btw) 무엇보다 좋습니다. 앞서 언급했듯이 이 문제에 대한 솔루션 은 까다롭고 여러 종속성을 업데이트하거나 분기해야 하므로 몇 가지 실사가 필요합니다.

공유할 정보가 더 있으면 스레드를 업데이트하겠습니다.

해결 방법으로 https://github.com/mikefarah/yq 를 사용하여 패키징하기 전에 helm 차트를 업데이트했습니다.

yq w -i values.yaml version $(Build.BuildNumber)

CI에서 동일한 파이프라인에서 앱/도커 이미지와 차트를 빌드합니다(앱과 차트가 동일한 버전 관리로 함께 발전하도록 보장하기 위해). 차트의 기본값은 이전에 빌드한 이미지 버전에 따라 다릅니다.

yq 해결 방법은 파이프라인에 쉽게 통합될 수 있지만 이 사용 사례가 helm 에 의해 올바르게 다루어지지 않는다는 것은 이상하게 보입니다!

따라서 패키지 단계 중/전에 image.tag를 설정하는 helm과 통합된 방법이 없습니까?

편집 : 제 경우에 이 솔루션을 찾았습니다. 동일한 버전으로 차트를 패키징하기 때문에 이미지 태그에 Chart.AppVersion을 사용해야 합니다.

편집 2 : Chart.AppVersion / 공유 차트에서 작동하지 않음(여러 우산 차트에서 사용되는 스프링 부트 차트를 사용함)

내 결론 : 패키지 단계에서 image.tag를 설정해야 합니다.

이 기능에 대한 소식이 있습니까?