나도 방금 이것에 부딪쳤다. 일반적으로 차트를 패키징할 때 이미지 태그를 지정하고 싶지만 디버깅을 위해 앱에서 다른 태그로 설치를 하고 싶었습니다.

90일 동안 사용하지 않으면 문제가 부실해집니다.
/remove-lifecycle stale 하여 문제를 최신으로 표시합니다.
부실 문제는 추가로 30일 동안 사용하지 않으면 썩고 결국 닫힙니다.

이 문제를 지금 종료하는 것이 안전하다면 /close .

sig-testing, kubernetes/test-infra 및/또는 fejta에 피드백을 보내십시오.
/수명 주기 부실

https://github.com/kubernetes/charts/pull/5919 에서 제기된 대로 다시 가져오기

내 최근 댓글의 일부 복사:

우리는 차트의 부 버전을 부 응용 프로그램 버전과 정렬되도록 특별히 선택합니다(패치 버전 번호는 차이가 있을 수 있고 차이가 날 수 있지만).

이는 cert-manager의 새 릴리스에 새 플래그를 추가할 수 있고 Helm 차트에 이에 대한 지원을 추가하면 플래그를 지원하지 않는 cert-manager의 이전 릴리스와의 호환성이 깨질 수 있기 때문입니다. 이것은 일반적인 IMO의 Helm 차트 버전 관리와 관련된 매우 기본적인 질문이며 우리가 이에 대한 좋은 이야기를 가지고 있지 않습니다.

appVersion을 차트 버전과 정렬하는 것이 권장되지 않는다는 것을 알고 있지만 이렇게 하면 사용자는 Helm 차트 버전 0.3.x를 cert-manager 0.3.x와 함께 사용할 수 있고 차트 버전 0.4.x를 cert와 함께 사용할 수 있다는 것을 압니다. -관리자 0.4.x. 호환성은 부 버전 내에서 정의됩니다.

/remove-lifecycle 부실

나는 이것을 토론을 위해 다시 가져오고 싶습니다.

전반적으로 변경되는 모든 것이 일부 구성 요소에서 사용되는 이미지 태그일 때 내부 앱용 차트 버전 관리에 찬성하는 것은 그다지 매력적이지 않습니다. 릴리스를 업그레이드할 때 appVersion 필드는 이 정보에 적합한 위치인 것 같습니다.

위에서 언급한 내 원래 제안 복사:

helm 차트 배포를 위한 현재 워크플로에는 helm upgrade CLI 명령을 호출하는 가능한 작업이 포함되며 동일한 차트 버전의 릴리스를 수정할 때 appVersion을 설정하는 플래그를 전달할 수 있으면 좋을 것입니다.

appVersion이 릴리스가 아닌 차트와 연결되어 있기 때문에 개념적으로 약간 이상할 수 있지만 우리의 경우 일부 컨테이너에 사용되는 이미지 태그를 업데이트하고 있으며 워크플로에 차트 버전 및/또는 차트 저장소가 통합되지 않았습니다. 아직. 이것은 미래에 변경될 수 있지만 현재로서는 이 필드가 순전히 정보 제공용이므로 설치 및 업그레이드 시 --app-version 플래그를 추가하는 데 문제가 없다고 생각합니다.

자체 내부 애플리케이션을 개발할 때 앱 자체는 앱을 배포하는 차트보다 훨씬 더 많이 변경됩니다. 일반적으로 지속적인 배포 명령은 helm upgrade 이며 --set imageTag=<new_version> (컨테이너 버전을 설정하기 위해 차트의 다른 곳에서 분명히 사용됨)를 --app-version으로 바꾸면 다음이 제공됩니다. 배포된 차트 버전과 함께 배포된 코드 버전을 보려면 helm ls 또 다른 시각적 지점을 사용하세요.

이를 더 잘 보이게 하기 위해 설치/업그레이드 시 전달된 imageTag로 설정되는 imageTag 의 메타데이터 태그 설정에 대해 표준화했습니다. 이를 통해 K8s 대시보드를 사용하거나 imageTag가 표시된 Graphana 대시보드를 쉽게 생성할 수 있지만 명령줄을 떠나 마우스를 클릭해야 합니다.

이것에 대한 소식이 있습니까?

감사 해요

이에 대한 모든 업데이트. @Eraac의 PR이 요청한 helm upgrade --set imageTag=<imagetag> 도 실행하지만 helm ls 출력에 나열된 APP VERSION은 업데이트하지 않습니다. --set app-version 또는 --set version 를 실행할 수 있으면 helm ls 가 배포된 버전을 올바르게 표시하도록 helm upgrade 를 실행할 수 있습니다.

업데이트가 있습니까?

Aaaaany 시간이 곧 사랑스러울 것입니다!

매우 유용할 것입니다

또한 공통 차트를 사용하여 애플리케이션을 배포하므로 설치 시 앱 버전을 설정하는 기능을 원합니다.

+1

+1

매우 도움이 될 것입니다

같은 것을 요구

스팸은 +1로 막아주세요. 이미 PR(https://github.com/helm/helm/pull/4961)이 있고 사람들이 제안에 대해 논의하고 있습니다. 마지막 답장은 2일 전이었다.

안녕하세요 @filipre

이미 PR(#4961)이 있고 사람들이 제안에 대해 논의하고 있습니다.

그 PR에 따르면, 이것은 여기로 옮겨졌습니다:
https://github.com/helm/helm/pull/5492
이것은 #4961에 대한 최신 PR이며 리뷰가 병합되기를 기다리는 것처럼 보입니다 ...

@filipre 말씀해 주 시겠습니까? PR은 어떻게 됩니까? PR이 한달 반 동안 움직이지 않은 것 같습니다.

이것은 매우 유용할 것입니다. 앱 버전 0.6.0에 고정해야 하는 상황이 발생했는데 차트 버전은 앱 버전과 관련이 없습니다.

동의합니다. 또한 이것이 매우 유용할 것이라고 생각합니다. 업데이트가 있습니까?

https://github.com/helm/helm/pull/5492#issuecomment -509662190을 참조

많은 애플리케이션에 재사용할 계획인 Helm 차트를 작성하는 동안 이것이 문제가 될 것이라는 것을 깨달았을 때 지금 이 문제를 해결하십시오. 간단한 방법(즉, 설치 시 앱 버전을 설정하는 플래그 사용)으로 이 문제를 해결하는 데 진전이 없다는 점을 감안할 때 현재 작동해야 하는 대안을 생각해 냈습니다. 정말 매우 간단이다 - 바로 않는 helm fetch 먼저 다음의 압축을 풉니 옵션과와 helm package 와 --app-version 존재를 수행 플래그, 그 지역의 차트를 설치를 진행합니다.

이상적이지는 않지만 helm list 의 최종 결과는 정확하며 CI 서버에서 이 작업을 수행하는 것은 매우 간단합니다. helm install 및 helm upgrade --app-version 를 사용할 수 있기를 바랍니다.

#5492에서 논의한 내용을 요약하면 helm package 및 helm install 의 논리를 래핑하는 명령이 이 문제에서 원래 설명된 사용 사례를 해결할 수 있다는 것입니다.

즉, 다음을 실행하여 이 문제를 해결할 수 있습니다.

$ helm package myapp --app-version 1.0.0
$ helm install myapp-1.0.0.tgz

(최근에 닫은 PR의 주석을 여기로 이동 - Nirvana에서 끝나지 않도록)

여기에 내 2 센트가 있습니다.
appVersion Y 하여 서비스를 배포하는 chart version X 가 있다고 가정합니다.

helm 차트는 appVersion Y 서비스를 호스팅하는 데 사용되는 chart version X 의 Kubernetes 내부 인프라를 설명하는 데 사용됩니다.

초기 개발 중에 X 및 Y 모두 정기적으로 변경됩니다. 그러나 어느 시점에서 X 는 다소 안정적 이 될 것이며 Y 는 계속 변경될 것입니다( Y 가 인프라에 대한 몇 가지 새로운 요구 사항을 충족하지 않는 한 훨씬 덜 자주 발생합니다. Y 의 개발 주기에서).

이 티켓에서 제안된 접근 방식을 사용하면 X 버전에서 안정적인 조타수 차트 패키지를 사용하여 appVersion Y , Y+1 , Y+N 등을 배포할 수 있습니다.

그러나 이 플래그가 helm 설치 또는 업그레이드 중에 재정의되는 것을 허용하지 않고 대신 예를 들어 패키지에서만 효과적으로 X 및 Y 함께 묶어 항상 새로운 X+1 만들도록 합니다 Y+1 . 이것은 나에게 불필요한 것처럼 보이며 새로운 appVersion 참조하는 것 외에는 사실상 변경되지 않은 수많은 helm 패키지가 발생합니다. 내 관점에서 볼 때 애플리케이션 버전과 해당 애플리케이션을 호스팅하는 인프라 버전은 관계가 있지만 여전히 독립적으로 버전이 지정되어야 하거나 여전히 있을 수 있습니다. 어떻게 하느냐는 각 개발팀에 맡겨야 한다.

요약:

이 접근 방식은 확실히 효과가 있지만 AppVersion 변경된 불필요한 Helm 패키지가 많이 발생합니다.
$ helm package myapp --app-version 1.0.0 $ helm install myapp-1.0.0.tgz

네, 하지만 위에서 언급한 접근 방식을 취하면 큰 문제가 되지 않는다고 생각합니다. 앱 버전이 설정되지 않은 차트 리포지토리(또는 0.0.0 또는 기타)로 차트를 푸시한 다음 사용하려는 경우 helm fetch 를 사용하고 올바른 앱 버전으로 패키징한 다음 로컬 .tgz 파일을 만들고 해당 차트를 푸시하지 마십시오. 그렇게 하면 차트 리포지토리가 깨끗하게 유지되고 실제 차트 변경 사항만 표시됩니다.

예, 작동합니다. 이 경우 배포 아티팩트를 직접 사용할 수 없지만(예: Helm 저장소에서 직접 설치하여) 항상 아티팩트를 변경하는 추가 단계를 통해 보내야 합니다.

Charts.yaml 가 변경 불가능해야 한다고 주장하는 경우 배포 아티팩트가 있어야 한다고 주장합니다.

에서 내 생각을 _Summarising https://github.com/helm/helm/pull/5492#issuecomment -520029902_

커뮤니티가 패키지, 차트 및 버전을 해석하는 방식에 문제가 있습니다. @BenjaminSchiborr , 이것이 당신에게 의미가 있기를 바랍니다.

차트 - 릴리스의 소스 코드입니다. 앱의 소스 코드와 같습니다. 템플릿, 코드 파일로 구성됩니다.
패키지 - 릴리스의 빌드, 아티팩트입니다. 소스 코드에서 빌드된 바이너리와 같습니다. 고정 프로덕션 버전(차트 버전 및 앱 버전 모두)으로 구성됩니다.
릴리스 - 지정된 구성으로 배포된 빌드입니다.

Chart 에서 릴리스를 만들 수 있는 방법은 없습니다 . 이 방법으로 작동하지 않습니다!

스테이지에 앱을 배포하기 전에 차트가 있어야 합니다. 그런 다음 helm package 사용하여 두 버전을 모두 수정하여 차트와 함께 앱을 패키징해야 합니다. 모든 단계에서 배포할 수 있는 패키지가 생성됩니다. 그런 다음 이 패키지를 예를 들어 QA 단계에 설치하고 helm install 사용하여 UA 및 프로덕션에서 승격합니다.

모든 패키지 지향 소프트웨어가 작동하는 방식입니다.

혼란

helm install 에는 소스가 필요하며 설치해야 합니다. 소스는 다음과 같을 수 있습니다.

1. 레지스트리에서 사용할 수 있는 패키지 이름
2. 패키지가 이미 다운로드되었거나 생성된 경우 패키지 파일 경로
3. HTTP를 사용하여 사용 가능한 경우 패키지 URL
4. 차트 디렉토리 경로

네 번째 접근 방식은 여기에서 검은 양처럼 느껴지지 않습니까? 이것이 ppl이 패키지와 차트를 혼동하는 이유입니다. 그리고 이것이 문제의 근원입니다.

추리

야생에는 두 가지 종류의 앱이 있습니다.

Big/Medium - 더 나은 내성 및 품질 보증을 위해 세부적이고 세분화된 흐름을 설정하기 위한 시간, 돈 및 리소스가 있는 곳입니다.
소규모 - 마이크로서비스, 애완동물 프로젝트, PoC, 저비용 프로젝트, DevOps 지식이 없거나 개발 프로세스 테스트를 주도하지 않는 프로젝트.

소규모 프로젝트의 경우 패키징을 만들거나 처리할 시간이나 필요가 없습니다. 몇 가지 템플릿 파일을 작성하고 하나의 명령으로 배포하고 싶습니다 !

이것이 helm install 가 helm package & helm install 와 같은 사용을 허용하는 이유입니다. 그러나 --app-version 와 같은 완전한 helm package 기능은 제공하지 않습니다.

helm install 는 helm package & helm install 일 수 있지만 helm install 를 엉망으로 만들고 지원, 테스트 및 모범 사례 만들기에 지옥입니다.

제안 1

helm install 단순화합니다. helm 대한 이해를 단순화하기 위해 코드베이스, 테스트 및 의견을 단순화하기 위해 제공되는 패키지만 허용해야 합니다.

제안 2 - helm run

새로운 명령 도입: helm run . 작동 해야 하는 명령입니다. 작은 앱에 이상적입니다. 또는 중형 및 대형일 수도 있습니다.

helm package 와 helm install 결합해야 하며 이러한 사용 사례에서 의미가 없는 명령은 제외하고 두 명령의 기능을 모두 제공해야 합니다.

helm package go build 가 하는 것처럼 helm package 는 빌드를 생성합니다. go run 사용하면 빌드 프로세스 없이 앱을 시작할 수 있으므로 helm run 는 여기에서 확실한 이름처럼 보입니다.

고려해야 할 추가 사항:

• 대신 upgrade --install 를 사용해야 합니까?
• 기본적으로 --atomic 활성화해야 합니까?

@iorlas ,
귀하의 의견이 의미가 있습니다. 그러나 인프라 버전과 소프트웨어 버전 모두를 상속적으로 연결하는 최종 패키지가 하나만 있을 수 있다고 가정하고 있습니다. 반면 내 소프트웨어 버전용 패키지와 인프라용 패키지가 있다고 가정하고 이를 묶고 싶습니다. 릴리스에서(예: 소프트웨어 버전 및 인프라 버전을 참조하는 원하는 상태 구성을 통해).

나는 왜 개발 프로세스가 책임 있는 개발 그룹이 helm 패키지 수준 이상에서 인프라와 소프트웨어 버전을 함께 묶을 것인지 결정하도록 남겨둘 수 있는 패턴으로 강제되어야 하는지 모르겠습니다. 현재 배포 프로세스는 항상 새로운 helm 패키지를 사용해야 하는 반면 소프트웨어 버전만 변경됩니다. 이로 인해 저장소에 수천 개의 쓸모없는 패키지가 생깁니다.

장기적으로 이점이 있다면 괜찮습니다. 나는 그것을 보지 않는다.

@BenjaminSchiborr 좋아요, 조금 분해하겠습니다.

X 버전의 Chart(== 인프라)를 가질 수 있습니다.
Y 버전의 애플리케이션을 가질 수 있습니다.

helm 가 현재 작동하는 방식은 helm package 단계에서 인프라와 애플리케이션 버전을 연결합니다. 그런 다음 k8 네임스페이스와 연결하여 Release를 생성해야 합니다.

따라서 공식은 package(infra + app) + k8s = Release

정말로 원하는 것은 이 중간 단계를 건너뛰고 3개의 구성 요소를 모두 한 단계인 릴리스로 묶는 것입니다. 다음과 같이: infra + app + k8s = Release . 나 맞아?

이것이 표면적으로 helm run 가 하는 일입니다. 후드 아래에서는 동일할 것입니다.

하지만... Helm의 요점을 놓치고 있는 것 같습니다 . 어떤 도구든 사용자가 원하는 대로 사용할 수 있지만 커뮤니티에 영향을 미치고 "길"을 만드는 아이디어가 항상 있으므로 망원경은 맥주를 양조할 수 있는 험머로 끝나지 않습니다.

어떻게 사용되어야 하는지 설명하려고 노력하겠습니다. 그리고 여러분의 관점에서 그것을 보는 것은 정말 멋질 것입니다.

Helm 자체는 k8s 템플릿 및 배포를 추상화하고 종속성과 함께 애플리케이션과 인프라를 연결하도록 만들어졌습니다. 템플릿을 수동으로 다시 작성하고 K8s에 적용한 다음 새 이미지 태그를 제공하는 대신 helm upgrade 명령 하나만 있으면 됩니다.

새로운 앱 버전을 설치하거나 다운그레이드해야 하는 경우에는 helm을 사용해야 합니다. 앱을 관리하는 대신 전체 패키지를 관리합니다. 문제가 발생했을 때 앱 버전과 인프라를 별도로 롤백하는 것은 골치 아픈 일입니다. 저는 거기에 가본 적이 있으며 누구에게도 제안하지 않을 것입니다.

따라서 레지스트리에 많은 패키지가 있는 것은 올바른 일입니다. 패키지는 인프라가 아니고 패키지가 앱이기 때문입니다. 앱은 인프라가 없는 K8에서 의미가 없기 때문입니다.

리포지토리에 패키지가 너무 많다는 문제가 있는 경우 리포지토리 대신 아티팩트를 사용하는 것이 좋습니다. 저는 CI에서 그렇게 합니다. 앱을 빌드하고, 도커 레지스트리로 보내고, 패키지를 만들고, 릴리스를 위해 아티팩트로 저장합니다. CircleCI, Travis, Azure Pipelines는 아티팩트로 빌드에 첨부된 파일 생성을 지원합니다. 당신도 똑같이 할 수 있습니까?

어쩌면 내가 Helm의 요점을 놓치고 있는지도 모릅니다. 아마도 Helm은 여기서 요점을 놓쳤을 것입니다. 나는 이 티켓이 바로 그것을 평가하기 위한 것이라고 생각한다. 그리고 개인적으로 - 또한 나의 지평을 넓히는 것에 대해 :)

그러나 네, 추상적으로 말씀하신 것이 맞습니다. 나는 helm 패키지/릴리스에 연결된 소프트웨어 버전을 원하지 않으므로 본질적으로 infra + app + k8s = Release 입니다. 내 소프트웨어 버전의 속성이 내 helm 패키지/릴리스에 연결되는 것을 원하지 않는 것과 동일합니다(무시할 수 있는 정상적인 기본값은 제외).

당신이 더 아래로 제공하는 예와 관련하여. 나는 이것이 이 접근 방식이 어떻게 문제가 되는지를 보여주지 않습니다. 여전히 helm을 사용하여 롤백 또는 롤포워드합니다. 인프라가 변경되면 변경된 helm 차트 버전을 사용합니다. 소프트웨어 버전이 변경되면 다른 앱 버전을 사용합니다. 매개변수가 변경되면 다른 매개변수를 사용합니다. 서비스당 항상 (단일) 조타 장치 호출이 됩니다.

자세히 설명해 주시겠습니까?

리포지토리에 패키지가 너무 많다는 문제가 있는 경우 리포지토리 대신 아티팩트를 사용하는 것이 좋습니다.

내가 언급한 것은 너무 많은 패키지된 helm 차트(이미 appVersion이 포함되어 있음)입니다. 안정적인 하나의 helm 차트 버전과 하루에 수백 번 변경되는 appVersion으로 생각하십시오. 따라서 나중에 자동화에 의해 사용되는 리포지토리의 서비스당 매일 수백 개의 패키지된 helm 차트가 있습니다.

(내 파이프라인은 일반적으로 귀하의 파이프라인과 동일하게 보입니다. 앱 빌드 --> Docker 이미지(결과는 appVersion) --> 패키지 차트(업데이트된 appVersion 포함) --> 저장소로 푸시합니까?

나는 이 티켓이 바로 그것을 평가하기 위한 것이라고 생각한다.

확실히! 제 생각에는 이미 추상화 수준이 너무 높기 때문에 여기에 조타 장치를 사용하는 것이 다소 부담스럽습니다. 하지만 그건 다른 시간에 할 얘기죠, 히히.

안정적인 하나의 helm 차트 버전과 하루에 수백 번 변경되는 appVersion으로 생각하십시오. 따라서 나중에 자동화에 의해 사용되는 리포지토리의 서비스당 매일 수백 개의 패키지된 helm 차트가 있습니다.

네, 확실히 너무 과한 느낌이 들지만 의도한 것입니다. 예를 들어 빌드 실행이 있고 일부 아티팩트를 생성한 다음 스테이지에 배포하는 데 사용하기 위해 저장해야 합니다. 예를 들어... 빌드 결과가 없는 빌드 실행을 어떻게 할 수 있습니까? 배포할 때 빌드를 생성해야 합니까? 정말 잘못된 것입니다. 일부 CI 파이프라인은 JS 빌드를 위해 그렇게 합니다.

도커와 동일한 문제가 있습니다. 각 빌드는 도커 레지스트리에 들어가는 새 도커 이미지를 생성합니다. 우리는 그것을 저장해야합니다. 우리가 그것을 가지고 있지 않다면 어떻게 배포해야합니까?

물론 docker save 레지스트리의 공간을 절약하고 나중에 빌드 자산 보존 정책을 쓸 수 있습니다. 하지만 helm package 파일로 보관할 수 있습니다.

그러나 나는 당신의 요점을 확실히 알았습니다. 우리는 앱 버전을 수용할 수 있는 하나의 "설치 프로그램"을 가질 수 있습니다. 이러한 설치 프로그램에는 인프라가 있으므로 앱 버전을 변경하기만 하면 그대로 유지할 수 있습니다. 깔끔하고 단순해 보이지만 문제가 있습니다.

앱 자체는 인프라가 없는 k8s 환경에서 의미가 없습니다 .

앱이 일부 인프라에 의존한다면 어떻게 될까요? 기본 예 - configmap.

그런 다음 앱을 롤백해야 하는 경우 어떻게 하시겠습니까?
앱을 다운그레이드해야 하지만 인프라도 다운그레이드해야 합니다.

그러면 인프라를 롤백해야 하는 경우 어떻게 합니까?
이전 인프라에는 연결되어 있지 않기 때문에 설치해야 하는 앱 버전에 대한 단서가 없습니다. 따라서 어떤 앱이 어떤 인프라를 지원하는지 기억하고 수동으로 설정해야 합니다.

정말, 그것은 지옥이 될 것입니다. 그리고 당신이 조타 장치가 없는 지금은 지옥입니다. 그리고 그것은 잘못이 아닙니다. 그러나 이 경우에는 투구를 사용할 이유가 거의 없습니다.

우리는 이미 너무 많은 추상화 수준을 가지고 있습니다.
모두 멋지고 단순한 윙크

나는 당신의 마지막 요점이 매우 설득력 있다고 생각합니다.

이전 인프라에는 연결되어 있지 않기 때문에 설치해야 하는 앱 버전에 대한 단서가 없습니다.
이러한 것들을 분리하고 Helm 패키지/릴리스를 진실의 소스로 사용한다면 이것은 확실히 문제입니다.

그러나 많은 사람들에게 이것은 아마도 사실이 아닐 것입니다. 여러 개의 helm 차트(및 appVersions)를 함께 묶는 Helm(예, 추상화의 또 다른 계층) 위에 오케스트레이션이 있습니다(helmsman, 마구 등을 생각하십시오). 그리고 해당 레이어 자체에도 버전이 지정됩니다. 이 경우 설명하는 내용은 더 이상 문제가 되지 않습니다. 그 이유는 이전 버전의 helm 차트로 되돌리지 않고 오케스트레이션 계층의 이전 버전(앱 및 인프라를 의미함)으로 되돌리기 때문입니다.

하지만 키만 가지고는 100% 문제 💣. 이것이 아이디어가 명시적으로 appVersion 재정의를 허용하고 기본적으로 허용하지 않는 이유라고 생각합니다.

차트 버전과 애플리케이션 버전을 함께 결합하는 것에 대해 내가 좋아하는 한 가지는 어떤 애플리케이션 버전이 어느 차트에 속하는지 명확해진다는 것입니다. 특정 버전을 다시 배포해야 하는 경우 어떤 애플리케이션 버전이 어떤 차트 버전과 호환되었는지 기억할 필요가 없습니다. 그것들은 함께 연결되어 있기 때문에 올바른 차트 버전을 참조하기만 하면 해당 응용 프로그램과 차트가 일치한다는 것을 확신할 수 있습니다. 기본적으로 @iorlas가 설명한 내용이라고 생각합니다. 맞나요?

결국 차트 버전은 "슈퍼" 버전으로 작동합니다.

• 모든 변경(응용 프로그램 또는 인프라, 즉 차트가 변경되었는지 여부에 관계 없이)은 새 차트 버전을 생성합니다. 즉, 새 응용 프로그램 버전은 차트 버전도 변경되었음을 의미합니다.
• 새 차트 버전은 애플리케이션 버전이 변경되었음을 의미하지 않습니다.

문서화 목적(그리고 다른 멋진 아이디어)을 위해 차트 정의 자체만 참조하는 또 다른 "차트 전용" 버전을 직접 소개할 수 있습니다.

@필리프레
넵 넵! 이것이 현재 아키텍처 설계 결정을 기반으로 하는 Helm이 작동하는 방식입니다. 내가 볼 때.

문제는 때때로 이상하게 느껴진다는 것입니다. 앱과 인프라를 함께 묶는 것에 대한 설정과 의심스러운 아이디어가 너무 많습니다. 이것이 올바른 접근 방식입니까 - 그것이 문제입니다.

@BenjaminSchiborr

그러나 많은 사람들에게 이것은 아마도 사실이 아닐 것입니다

확실히! 전체 k8에서도 컨테이너화는 너무 많을 수 있습니다.

조타 장치가 생성된 문제를 찾기 위해 조금 다른 관점에서 분석해 보겠습니다.

• 인프라 인스턴스는 전체 제품이 작동하는 방식입니다: SaaS 인스턴스, VM 풀, k8s 설정, 앱 버전(데이터베이스, 관찰 도구, 라우터, 사이드카 및 제품 앱 인스턴스 포함)
• 인프라 인스턴스에는 하나의 진실 소스가 필요합니다. 이제 Terraform과 같은 유틸리티가 있습니다.
• 한 폴더에 너무 많은 항목 = 어렵습니다. 분해해야 합니다. 안녕하세요 Terraform 모듈입니다.
• 하나의 폴더에 있는 플랫폼과 응용 프로그램 = 하드. 분해해야 합니다. 안녕하세요 플랫폼과 컨테이너입니다. K8s가 들어옵니다.
  
  
  
  1. 따라서 Terraform 모듈 은 즉시 사용할 수 있는 빈 컨테이너 레이어 생성을 포함하여 플랫폼을 관리할 수 있습니다.
  
  
  2. K8s 는 컨테이너를 관리하여 YAML을 사용하여 기본 리소스를 생성할 수 있습니다.
  
  
• 많은 K8s 앱(데이터베이스 및 항목 포함)에 대한 많은 YAML 파일 = 하드. 앱별로 폴더로 나눕니다.
  
  
  
  1. PostgreSQL, Redis, MyPetShop과 같은 폴더 가 있습니다. 각 파일에는 보유한 리소스에 대한 YAML 파일이 있습니다. 그리고 K8에 적용하려면 앱 버전을 설정해야 합니다.
  
  
• Hello Helm - 이 폴더(차트라고 함)를 설정할 수 있는 도구이지만 더 많은 기능을 함께 적용하고 롤백합니다.
• 차트가 견고해 보입니다. 변수를 지원하여 재사용합시다. 이제 차트는 인프라가 아니라 인프라 템플릿입니다.
• 차트가 굉장해 보입니다. 친구들과 공유해 봅시다. 차트를 업데이트할 때마다 인덱스가 있는 파일 리포지토리에 차트를 푸시해야 합니다.

따라서 패키지가 전혀 없이 굉장하고 모든 것이 느껴집니다. 따라서 이 차트를 적용한 후 애플리케이션 버전을 제공해야 합니다. 그리고 그것이 되어야 합니다.

그러나 문제가 발생합니다. 아무도 어떤 앱 버전에 어떤 차트가 필요한지 기억하고 싶어하지 않습니다. 어떤 차트가 업데이트되어 어떤 앱 버전에 대한 새로운 구성 값을 제공하는지.

결국 우리가 원하는 것은 "Setup myApp version 1.4.2 as K8s app" 입니다 . 모든 위험, 종속성, 변경 사항을 하나의 아티팩트인 apps versions + hooks + setup logic + infrastructure to connect it all 애플리케이션 설치 프로그램으로 캡슐화합니다. 이것이 우리가 MSI, Deb, RPM, 심지어 NPM, Go mod, Pip, Gem과 같은 것을 가지고 있는 이유입니다.

이것이 바로 패키지가 등장하는 곳입니다. 그리고 패키지는 정의에 따라 CI/CD 흐름 내에서 설치 가능한 릴리스로 생성되어야 합니다. 따라서 레지스트리 및/또는 시스템 설정(k8s 클러스터)으로 보낼 수 있습니다.

그리고 다른 프로젝트도 다르지 않습니다. 패키지 없이 직접 helm install 차트를 작성할 때 동일한 작업을 수행합니다. 그러나 패키지 생성 대신 다른 단계에서 생성합니다. 앱 빌드 프로세스에서 빌드하는 대신 릴리스 단계에서 빌드합니다. 우리는 여전히 인프라와 앱 버전을 함께 묶습니다 . 암시적으로 .

재미있는 점은 다음과 같습니다.

• 종속성 업데이트 = 인프라 템플릿(차트) 버전 업데이트
• 앱 업데이트됨 = 자체 버전과 함께 인프라 템플릿(차트)의 하위 집합인 포크 생성 - 패키지

그래도 k8s 운영자는 현재 문제에 대해 예상해야 하므로 운영자처럼 작동해야 하지만 helm이 하는 것처럼 쉬운 릴리스 프로세스를 제공하는 하나의 도구만 있어야 합니다.

이견있는 사람? 우리는 여기서 새로운 것을 만들 수 있지만 더 나은

귀하가 설명하는 내용은 제어할 수 없는 인프라의 다른 사람들이 사용하도록 되어 있는 응용 프로그램에 대해 많은 의미가 있습니다. 그러나 엔터프라이즈 시나리오에서 패키지를 만드는 것은 바쁜 작업이 됩니다. 공유 또는 쿠키 커터 환경에 배포되고 리포지토리 자체에 있는 CI/CD 파이프라인 정의 덕분에 수십 개의 쿠키 커터 마이크로서비스가 있을 수 있습니다. azure-pipelines.yaml)에서 "패키지 버전"은 마스터 분기의 특정 버전에서 생성된 빌드일 뿐입니다. 의미, "패키지"를 아무데나 저장할 필요가 없습니다. 내 빌드는 configmaps 등에서 사용되는 동일한 비트와 동일한 변수를 사용하여 동일한 패키지를 생성합니다. 아주 드물게 발생하는 서비스 인프라 변경. Helm이 이 그림에 있는 이유는 1) 이미 일부 인프라(예: nginx)를 배포하는 데 사용해야 하기 때문입니다. 2) k8s yaml 템플릿을 사용하여 휠을 재발명할 필요가 없습니다.

@wasker

예를 들어 docker에 투영해 보겠습니다. Docker 이미지도 패키지입니다. 바이너리를 OS 이미지 = 인프라와 함께 묶습니다. 빌드를 할 때마다 docker 이미지를 만드는 이유는 helm 패키지를 만드는 것과 같다고 생각합니다.

모든 것을 도커 이미지로 추상화할 필요가 없다면 도커가 필요 없고 일반 VM으로 살 수 있습니다.

따라서 도커 사용을 helm에 투영하려고 하면 helm을 인프라 도구로만 사용하는 것은 도커를 사용하여 초기 이미지를 만든 다음 새 바이너리를 보내 k8s 호스트 자체에서 이러한 이미지를 업데이트하는 것과 같습니다. 투구를 사용하고 매번 다시 포장하지 않는 것과 같은 종류의 나쁜 것입니다.

어쨌든 우리는 잘못된 길을 갔다고 생각합니다. 아무도 helm을 사용하고 수동으로 이미지를 업데이트합니까? 제 생각에는 3가지 일반적인 사용 사례가 있습니다.

1. helm package chart -> helm install package
2. helm install chart
3. helm install -> kubectl set image

@wasker 어느 쪽이 당신의 것입니까? 3번이 아니라 믿습니다. 인프라 구성과 애플리케이션 버전 관리를 실제로 분리하더라도 작업하기가 어렵습니다. 인프라를 업데이트해야 할 때 모든 버전을 잃게 되기 때문입니다. 차트에서 수동으로 업데이트하거나 각 배포에 대해 kubectl set image 로 업데이트해야 합니다.

그래서, 우리는 두 번째 helm install chart "w/o 포장"에 대해 이야기하고 있습니다. 따라서 조타 장치는 항상 그림에 있습니다. 문제는 패키지가 빌드지만 런타임에 앱을 배포할 때라는 것입니다. 따라서 CI 빌드는 배포해야 할 때 암시적으로 패키지 생성을 담당합니다.

그리고 golang에 프로젝션하면 빌드하고 바이너리를 사용하는 대신 소스 코드를 보내고 docker에서 go run 로 실행하는 것과 같습니다.

따라서 패키징 단계를 건너뛰는 단순화하기 위한 것입니다. 그것은 ?

이것이 우리가 이야기를 시작할 수 있는 곳입니다. 여기 https://github.com/helm/helm/issues/3555#issuecomment -529022699가 제 제안입니다. 추가 helm run 하고로 모델링 go run .

인프라와 앱 버전 관리를 분리해야 하는 경우 인프라 를 업데이트/시드하는 데에만 helm을 사용한다는 의미입니다. 이 작업을 수행하는 방법을 보고 싶지만 업데이트에 두통을 추가하지 않는 방법을 볼 수 있습니다. 현재 배포 버전과 내용을 무시할 수 있지만... 너무 잘못된 것 같아서 만드는 데 시간 낭비가 될 것입니다.

예를 들어 docker에 투영해 보겠습니다. Docker 이미지도 패키지입니다. 바이너리를 OS 이미지 = 인프라와 함께 묶습니다. 빌드를 할 때마다 docker 이미지를 만드는 이유는 helm 패키지를 만드는 것과 같다고 생각합니다.

문제는 새 Docker 이미지를 만드는 경우 해당 이미지 내의 무언가가 변경되었기 때문인 것 같습니다. 여기에 설명된 시나리오에서 패키지된 Helm 차트의 내용은 앱 버전이라는 한 줄을 제외하고 변경되지 않았습니다. 이것은 최종 결과에 영향을 미치지만 자체적으로 Helm 차트가 작동하는 방식을 변경하지는 않습니다. 다른 값을 사용하여 동일한 방식으로 동일한 작업을 수행합니다. 자체적으로 엔터티로서의 Helm 차트는 해당 앱 버전 변경의 결과로 조금도 변경되지 않았습니다. 마지막에 공개되는 것만이 있습니다.

Docker 이미지에 대한 구성 사용과 같은 작업을 수행할 수 있는 기능으로 여기에서 유사점을 그릴 수 있습니다. 환경 변수를 Docker 이미지에 전달하면 런타임에 실행되는 방식에 영향을 미치며 이러한 변수를 변경하기 위해 이미지를 다시 빌드하지 않습니다. 이미지의 내용은 변경되지 않았지만 최종 결과는 - 매우 유사한 상황이지만 이 경우 동작은 바람직하고 정상적입니다.

그리고 golang에 프로젝트를 수행하면 빌드하고 바이너리를 사용하는 대신 소스 코드를 보내고 docker에서 go run으로 실행하는 것과 같습니다. [...] 따라서 패키징 단계를 건너뛰는 진짜 이유는 엔지니어의 전체 그림을 단순화하기 위한 것입니다. 그렇습니까?

내 생각에는 그렇지 않습니다. 현실적으로 여기에서 주장하는 것은 사람들이 앱 버전을 "차트의 일부"로 고려하는지 여부와 Helm 차트를 차트의 결과로 배포되는 Docker 이미지와 구별되는 것으로 간주하는지 여부입니다. 이에 대한 나의 견해는 위에서 언급한 바와 같다. Docker 이미지에서 컴파일된 Go 바이너리를 가져와서 다른 환경 변수로 실행하는 것과 같습니다.

즉, 새로운 애플리케이션 버전으로 Helm 차트를 재패키징하고 차트 버전을 일종의 "수퍼 버전"으로 사용하기 위해 만들어진 주장은 설득력이 있습니다(즉, 항상 호환되는 앱 버전을 차트 - 값을 통해 애플리케이션 버전을 사용자 정의할 수 없는 경우).

제 질문은 - _두 가지 접근 방식을 모두 지원하지 않는 이유는 무엇입니까?_ 각 접근 방식에는 장단점이 있습니다. 기본적으로 이를 지원하지 않으면 완벽하게 유효한 일부 워크플로가 더 어려워질 뿐입니다. 예를 들어 Flux CD와 Helm Operator를 사용합니다. 공유 Helm 차트가 있는 경우(즉, 많은 서비스를 배포하고 동일한 특성을 공유하는 특정 유형의 서비스가 있기 때문에) 유용한 helm list 출력을 얻으려면 새 Helm이 있어야 합니다. 각 앱의 차트와 각 릴리스에는 고유한 Helm 차트도 필요합니다. 이것만으로도 파이프라인이 복잡해집니다. 차트를 공유할 수 있다면 차트가 업데이트되었을 때만 실행되는 자체 파이프라인이 있을 수 있고 애플리케이션 파이프라인이 단일 Helm 명령을 실행할 필요도 없기 때문입니다(Flux CD에 설치/업그레이드 시 새 앱 버전 플래그).

제 질문은 - 두 가지 접근 방식을 모두 지원하지 않는 이유는 무엇입니까?

그것이 바로 내가 생각하는 것입니다.

제 경우에 "수퍼 버전"은 조타 장치 차트가 아니라 과다한 조타 장치 차트를 사용하는 또 다른 레이어입니다. 나에게 단일 Helm 차트는 다른 많은 서비스 중에서 작은 서비스만 설명하므로 의미가 없습니다. 그것들은 함께만 의미 있는 릴리스를 형성합니다.
따라서 제 경우에 "수퍼 버전"은 모든 릴리스를 함께 요약한 것입니다(실제로 버전이 지정되는 방식입니다).

여전히 Helm 차트 자체를 설명적인 "슈퍼 버전"으로 사용하는 것에 대한 논쟁이 있습니다.

@seeeruk 의 요점으로 돌아가기: 둘 다 지원하지 않는 이유는 무엇입니까?

현재 토론에서 외부의 목소리를 얻는 것이 도움이 될 수 있습니다. 약간의 맥락에서, 저는 총 _11일 동안 helm 를 사용해 왔습니다._ 저는 고급 학습에 참여하지 않았기 때문에 이것이 저에게 추가할 독특한 관점을 제공한다고 생각합니다. 내가 수집한 모든 것은 문서화와 실험에서 나온 것입니다.

내가 투구를 보는 방법

Helm이 차트가 아닌 패키지를 설치하는 것에 대한 이 현재 논쟁을 읽기 전까지 나는 Helm이 주로 관련된 Kubernetes 리소스를 설명하기 위한 인터페이스라고 믿었습니다. 이 믿음은 주로 다음과 같은 Helm 문서에서 나옵니다.

Helm은 Kubernetes에 차트를 설치하여 각 설치에 대한 새 릴리스를 생성합니다. 그리고 새로운 차트를 찾기 위해 Helm 차트 저장소를 검색할 수 있습니다.

컨텍스트의 경우 현재 안정적인 helm 문서도 다음과 같이 명시되어 있습니다.

차트는 투구 패키지입니다. 여기에는 Kubernetes 클러스터 내에서 애플리케이션, 도구 또는 서비스를 실행하는 데 필요한 모든 리소스 정의가 포함됩니다. Homebrew 수식, Apt dpkg 또는 Yum RPM 파일에 해당하는 Kubernetes처럼 생각하십시오.

그래서 지금 약간의 혼란이 있습니다! Helm 문서에는 "차트가 조타 장치 패키지"라고 분명히 명시되어 있지만, 그렇다면 도대체 왜 helm install 가 패키지되지 않은 차트 리포지토리를 수락합니까?

조타 장치가 무엇이며 어떻게 작동해야 하는지에 대한 나의 현재 견해에 영향을 미친 것은 이 동작입니다.

Helm은 _what_의 구조가 클러스터로 들어가는 것과 _what properties_ 사이에서 매퍼 역할을 합니다.

이제 질문은 "Helm이 배포하는 것은 무엇입니까?"입니다.

Helm 배포란 무엇입니까?

helm install release-name ./local_chart 실행하면 helm이 지정된 값으로 모든 차트 템플릿을 로컬로 렌더링하고(기본값 또는 재정의를 통해) 렌더링된 버전을 Kubernetes로 푸시할 것으로 예상합니다. 또한 내가 롤백하는 경우 Helm이 이전에 배포된 Kubernetes 개체를 유지할 것으로 기대합니다. (일부 메타 데이터를 포함한다) "렌더링 템플릿 컬렉션"의이 개념은 릴리스 및 패키지입니다. 이러한 모든 리소스 정의(변경되지 않았더라도)는 릴리스가 존재하거나 롤백되기 위해 _번들에 설명된 상태_에 있어야 합니다.

이것으로부터 나는 helm 만이 진정으로 packages 를 배포 한다고 추측

_내 개인적인 의미론에 따르면 이 질문에 대한 대답은 yes 입니다. 변경되지 않는 한 버전 번호를 올리지 않을 것이라는 주장에 따르면 일부 기본 속성이 변경된 경우에만 애플리케이션의 버전 번호를 조정하면 됩니다. 여기에는 레지스트리에서 다른 도커 이미지를 가져오거나 환경 변수를 통해 기능 플래그를 설정하거나 일부 코드 아티팩트의 동작을 변경하는 데 사용할 수 있는 다양한 방법이 포함될 수 있습니다.

이 때문에 레지스트리를 정리하기 시작했고 개발을 제외하고 :latest 에서 배포하지 않았습니다 . 도커 이미지의 릴리스 태그 대신 "메타 태그"를 사용하면 주어진 배포를 주어진 코드 베이스에 묶는 것이 불가능합니다. 우리는 이것을 어렵게 배웠습니다.

어떤 패턴을 사용해야 합니까?

이것은 이미 Helm: packages에 의해 의견이 제시되었습니다.

이 패턴 이 100% 명확하지 않더라도 --appVersion 플래그가 제공되는 것이 논리적으로 일관성이 있어 보입니다. 이것의 "이유"에 답하는 것이 아마도 다른 어떤 것보다 더 중요할 것이므로 그 대답으로 제 기여를 마무리하겠습니다.

--appVersion을 지원하는 이유는 무엇입니까?

배포의 특별한 경우를 살펴보겠습니다.

회사에 두 가지 주요 버전이 있는 애플리케이션이 있습니다. 이 회사의 클라이언트 중 일부는 이 응용 프로그램의 최신 주 버전으로 업그레이드하기로 약정하지 않았고 둘 중 이전 버전을 사용하고 있습니다. 유료 개발 계약으로 인해 라이브 개발은 여전히 ​​구 메이저 버전에서 이루어 지지만 제품은 "동일"합니다. 이 애플리케이션의 두 버전에 배포할 인프라는 동일합니다. 그러나 앱 버전은 이러한 배포 간에 크게 다릅니다.

이 회사는 무엇을 할까요?

1. appVersion 만 다른 두 개의 별도의 거의 동일한 조타 장치 차트를 만드시겠습니까?
2. 하나의 투구 차트를 사용하지만 주요 앱 버전 간에 계속해서 appVersion 업데이트합니까?
3. appVersion 를 플래그(현재 지원되지 않음)로 재정의하여 명령줄에서 잠재적인 개발자 오류를 발생시키시겠습니까?
4. Rescope appVersion 밖으로의 Chart.yaml 와에 values.yaml ?

제안 1은 다른 제안보다 약간 더 많은 오버헤드를 도입하지만 이러한 애플리케이션 버전에 대한 차트가 서로 다른 경우 별도로 유지하는 이점도 있습니다. 명확한 사용 사례가 있으며 아마도 이 문제의 많은 경우에 채택될 것입니다.

제안 2는 제안 1보다 오버헤드가 적지만 차트에 높은 변동성을 도입합니다. helm install release-name https://remote-repo.com/chart 를 실행하고 차트의 최신 버전이 잘못된 버전의 응용 프로그램인 경우 어떻게 됩니까? 이런. 아마도 최선의 접근 방식은 아닐 것입니다.

제안 3은 현재 논의 중인 것입니다. 나는 개인적으로 이 옵션을 싫어하지만 문제에 대한 잘못된 해결책 이라고 생각하기 때문 helm install release-name https://remote-repo/chart 를 실행할 때 발생하는 것과 동일한 문제가 있습니다 . 메타데이터는 임시적이며 Helm에서만 유지 관리됩니다.

아직 아무도 제안 4 또는 이와 유사한 것을 제안하지 않았다는 사실에 상당히 충격을 받았습니다. 이는 appVersion을 재정의할 수 있는 상태로 만들고( helm run 와 유사한 것을 활성화) helm package 의해 생성된 패키지에 포함될 수 있으며 애플리케이션 버전의 개념을 진정으로 풀립니다. appVersion 개념을 조타 장치 배포와 결합하면서 차트 버전에서 가져옵니다(appVersion이 어딘가에 맞아야 합니까?).

도움이 되었기를 바랍니다. 👀 이번 홍보.

@jrkarnes : 어떤 의미에서 4)는 이미 제안되었으며 많은 사람들이 해결 방법으로 사용하고 있습니다(https://github.com/helm/helm/pull/5492#issuecomment-517255692 참조). 차트 템플릿에서 다음과 같은 것을 사용할 수 있습니다.

{{ default .Values.appVersion .Chart.AppVersion }}

이것은 당신이 사용할 수 있도록 할 appVersion 에서 Charts.yaml 뭔가에 기본으로하고 재정의 Values.yaml (전화를 설치 / 업그레이드시 무시 될 수있다). 단점은 예를 들어 helm ls 수행할 때 appVersion 없거나 잘못된 것으로 표시된다는 것입니다.

@BenjaminSchiborr 이에 대해 helm 작업 공간에 있었으므로 이 시점에서 모든 지식은 좋은 지식 입니다.

네 번째 제안이 약간 오해가 있었던 것 같아요. {{ default .Values.appVersion .Chart.AppVersion}} 와 같은 것을 사용하는 대신 {{ .Values.Helm.AppVersion}} 를 사용하고 values.yaml 는 appVersion 대신 Chart.yaml

@jrkarnes
그게 내가 지금 생각하는 것입니다. 예를 들어 앱 버전이 고유한 눈송이로 취급되어야 하는 이유입니다. 차트의 값입니다.

이유는 간단합니다. 모든 것이 인프라의 일부입니다. 따라서 인프라에는 버전이 있습니다. 왜 두 가지 버전입니까?

그러나 나는 너무 바빠서 사이드 케이스와 프로젝션에 대해 머리를 싸매고 있습니다. 그러나 일반적으로 이것이 질문입니다. 간단히 말해서 모든 인프라인데 앱 버전이 필요한 이유는 무엇입니까? 또는 Chart가 인프라 템플릿일 때 인프라 버전으로, 인프라에 앱 버전이 포함된 경우 앱 버전으로 사용할 수 있습니까?

조금 더 생각해볼게

@jrkarnes
그게 내가 지금 생각하는 것입니다. 예를 들어 앱 버전이 고유한 눈송이로 취급되어야 하는 이유입니다. 차트의 값입니다.

이유는 간단합니다. 모든 것이 인프라의 일부입니다. 따라서 인프라에는 버전이 있습니다. 왜 두 가지 버전입니까?

기본적으로 차트 버전을 애플리케이션 버전과 별도로 유지하는 것이 합리적 입니다. 빠른 예는 아마도 이것이 사실임을 증명하는 가장 좋은 방법일 것입니다.

ver 1.1.0 버전의 차트에서 실행 중인 ver 4.0.0 애플리케이션이 배포되어 있다고 가정해 보겠습니다. 작업하는 동안 이 응용 프로그램에 대한 cron 작업 실행을 시작해야 한다는 것을 알게 됩니다. cronJob 개체를 작성하여 클러스터에 적용하는 대신 이 차트를 실행하는 다른 사람들에게도 cron 작업이 필요할 수 있음을 깨닫고 차트에 추가합니다. 이제 차트가 ver 1.2.0 되었지만 차트가 관리하는 응용 프로그램에는 변경 사항이 없으며 여전히 ver 4.0.0 있습니다.

그 반대의 경우에도 적용할 수 있으며 이미 이 PR에서 논의의 주제입니다.

그러나 나는 너무 바빠서 사이드 케이스와 프로젝션에 대해 머리를 싸매고 있습니다. 그러나 일반적으로 이것이 질문입니다. 간단히 말해서 모든 인프라인데 앱 버전이 필요한 이유는 무엇입니까? 또는 Chart가 인프라 템플릿일 때 인프라 버전으로, 인프라에 앱 버전이 포함된 경우 앱 버전으로 사용할 수 있습니까?

조금 더 생각해볼게

사이드 케이스나 프로젝션에 대해 생각하기보다 널리 사용되고 지원되는 세 가지 엔진 버전이 있는 MySql과 같은 것을 생각해 보십시오. [5.6, 5.7, 8.0] . mysql 인스턴스를 클러스터에 배포하려면 항상 다음이 필요합니다.

• 선택한 버전의 MySql 인스턴스를 실행하는 파드
• 포드(또는 HA에서 실행 중인 경우 포드)에 대한 kube-dns 확인을 허용하는 서비스
• Pod가 함께 제공되는 PVC와 함께 데이터를 기록할 PV

MySql 5.6, 5.7 또는 8.0 배포 차트는 모든 엔진(애플리케이션) 버전에서 비교적 동일 해야 합니다

앱 버전의 "필요"에 대해 궁금해하는 것이 무슨 말인지 알겠습니다. helm ls 또는 helm inspect 실행할 때 개발자 또는 운영 편의에 달려 있다고 생각합니다.

@jrkarnes 마지막 게시물에 +1. 차트 버전이 "인프라 버전"이기 때문에 차트와 앱 버전을 별도의 개념으로 유지하는 것은 많은 가치가 있습니다.

다른 사람들이 사용할 수 있도록 차트를 게시하는 경우 차트에 의존하는 프로젝트를 위한 인프라의 일부가 됩니다. 그러나 내 응용 프로그램을 다른 사람이 사용하도록 할 생각이 없다면 차트 자체가 변경될 때 때때로 내 자신의 차트 버전을 helm install last-known-good-chart-version 하여 배포를 롤백하는 대신 포인터를 사용하여 CD 파이프라인을 다시 실행하기만 하면 됩니다. 마지막으로 알려진 양호한 커밋 ID.

@iorlas helm run 대한 귀하의 제안을 읽었 으며 그것에 대해 아무런 문제가 없습니다. 설치/실행 이분법을 가질 필요 는 없다고 생각하지만 앱 버전을 변경 가능하게 만드는 데 있어 키 유지 관리자의 마음을 편안하게 해준다면 저는 괜찮습니다. :)

@iorlas 이 제안으로 무엇을 하고

{{ default .Values.appVersion .Chart.AppVersion}} 와 관련된 해결 방법이 어떻게 작동하는지 이해하지 못하는 것 같습니다. 이 오류가 발생합니다.

오류: YAML을 JSON으로 변환하는 중 오류 발생: yaml: 잘못된 맵 키: map[interface {}]interface {}{".Values.appVersion | default \"0.0.1\"":interface {}(nil)}[

내 Chart.yaml은 다음과 같습니다.

name: demo-helm
version: 0.0.1
appVersion: {{ .Values.appVersion | default "0.0.1" }}
home: http://example.com
description: Demo Helm

@IRobL 이 스니펫을 templates/deployment.yaml 에 넣어야 합니다. 여기서 version이 사용됩니다. values.yaml 와 같은 파일은 템플릿으로 취급되지 않습니다.

@jrkarnes 저는 메인테이너가 아니므로 마지막 말은 다른 사람들이 하게 될 것 같습니다. 그러나 어쨌든 지난 몇 주 동안 나는 꽤 바빴습니다. 다음 주에 저는 helm 및 packages 를 관리하기 위한 현재 접근 방식을 재평가할 것입니다.

우리는 내가 설명한 접근 방식을 사용합니다.

• Helm Chart 는 앱 저장소의 일부입니다.
• 애플리케이션 빌드 는 다음을 생성합니다.
  
  
  
  • 도커 이미지 -> 도커 레지스트리
  
  
  • 정적 파일 -> CDN 서비스
  
  
  • 투구 패키지 -> CI 보관
  
  
• 따라서 Helm 패키지는 모든 애플리케이션 아티팩트를 함께 바인딩하는 주요 아티팩트입니다.
• 배포 시 install 패키지

현재 우려 사항:

• 빌드 프로세스의 복잡성.
  
  
  
  • 도커 이미지 및 정적 파일 대신 추가 파일( helm package ) 생성
  
  
  • go build / make install 결과 파일 외에 필요한 주요 이유는 무엇입니까?
  
  
  • 비용이 얼마에요?
  
  
  • 신청하는 이유는?
  
  
  • 언제 신청하나요?
  
  
• 빌드 기간
  
  
  
  • 배포할 필요가 없더라도 여전히 시간과 비용을 낭비하고 있습니다. 2-5초. 많지는 않지만 의미 없는 일은 의미가 없습니다.
  
  
• 인프라 템플릿 업데이트의 복잡성
  
  
  
  • 차트가 업데이트되면 값도 업데이트되어야 합니다.
  
  
  • 차트는 하나의 리포지토리이고 값은 다른 리포지토리이며 값에 대한 각 업데이트는 약간의 골칫거리를 의미합니다.
  
  

그러한 재평가는 추가적인 단순화와 아이디어로 이어질 수 있습니다. 우리는 볼 것입니다 :)
다음주 금요일에 업데이트를 보내드리겠습니다.

아, 당신이 저를 위해 이것을 지적해 주셔서 왜 그 트릭이 작동하지 않는지 알겠습니다. 감사합니다. 다음은 이러한 종류의 오버헤드 조각으로 helm 도구를 감싸는 것이 편하다고 가정할 때 Helm 2.x를 사용하는 많은 사람들에게 잘 작동한다고 생각하는 트릭입니다.

APP_VERSION=0.0.7
sed -i.bak "s/^appVersion:.*\\\$/appVersion: $APP_VERSION/" helm/Chart.yaml
helm install --name helm_demo helm/

@IRobL

일반적으로 배포를 sed로 래핑하는 경우 템플릿 엔진이 필요한 작업을 수행하지 않는다는 것을 의미하며 이것이 이 논의의 요점입니다.

gitlab이 초기 단계에 있고 조타 장치를 지원하지 않았을 때 우리는 말 그대로 손으로 만든 매니페스트 파일의 대체 대상에 값을 입력했습니다.

이와 같은 일에 대한 나쁜 습관이며 가능하면 이를 멀리할 것을 촉구합니다.

2019년 10월 7일 오후 3시 33분에 IRobL [email protected]에서 다음과 같이 썼습니다.

아, 당신이 저를 위해 이것을 지적해 주셔서 왜 그 트릭이 작동하지 않는지 알겠습니다. 감사합니다. 다음은 이러한 종류의 오버헤드 조각으로 helm 도구를 감싸는 것이 편하다고 가정할 때 Helm 2.x를 사용하는 많은 사람들에게 잘 작동한다고 생각하는 트릭입니다.

앱_버전=0.0.7
sed -i.bak "s/^a ppVersion:. *\\$/appVersion: $APP_VERSION/" helm/Chart.yaml
helm 설치 --name helm_demo helm/
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

@jrkarnes , 나쁜 습관이라고 하면 helm 명령을 스크립팅으로 감싸야 하는 것이 바람직하지 않다는 말씀이신가요? 그렇다면 전적으로 동의합니다. --app-version 플래그를 추가하는 것에 반대한다는 말은 아닙니다. 반대로 나는 그것이 조타 장치에 매우 편리한 추가 기능이 될 것이라고 생각합니다. 분명히 이 PR을 기반으로 하여 배포되는 실제 빌드와 appVersion 변수를 일관되게 유지하려는 helm을 사용하는 유일한 사람은 아닙니다. 나는 재현 가능한 빌드를 생성하기 위해 다양한 빌드 도구를 함께 래핑하는 재사용 가능한 빌드 파이프라인 라이브러리를 개발하고 있습니다. 이것은 대규모 기술 조직의 일반적인 관행입니다. 내 사용의 경우, 파이프 라인 라이브러리를 발행의 고정 표시기 용기를 구축하고, 궁극적으로 응용 프로그램의 빌드 파이프 라인에서 투구를 통해 그들을 배포 (예를 들어, 응용 프로그램 버전 고려 1.0.1-pr-3.1 의 세 번째 PR의 첫 번째 빌드를 버전 1.0.1의 시험판일 가능성이 있는 앱).

이 문제가 우리 회사의 빌드 파이프라인 라이브러리에서 해결된 후에도 --app-version 스위치가 Helm에 내장되어 있으면 확실히 더 편할 것입니다. 배포를 처리하는 더 유연한 방법처럼 느껴집니다. 내 말은, 실수로 숫자를 엉망으로 만들 수 없는 빌드 플랫폼에서 자동화할 수 있다면 왜 외부 시스템이나 엔지니어가 차트 파일로 이동하여 모든 배포 전에 yaml을 업데이트해야 합니까? 내 관점에서 보면 appVersion 기능은 우리 조직에서 완전히 포기해야 하거나 "엉성한" sed 해결 방법을 파이프라인 라이브러리 코드에 추가해야 하므로 공유할 생각입니다. 이 문제를 해결하는 다른 사람.

@IRobL
일반적으로 모든 유틸리티는 자체 추상화 수준에서 자급자족해야 합니다. 충분한 API를 제공하여 해결하는 문제를 추상화해야 합니다. 투구도 예외는 아니다. 따라서 작동 방식을 사용자 정의해야 하는 경우 먼저 질문해야 합니다. 아키텍처, 디자인 원칙과 일치하는지 아니면 내가 놓친 부분이 있습니까?

이 PR이 그렇게 쉽게 해결되지 않은 이유입니다. 수정은 분명하지만 Helm 디자인과 일치하지 않기 때문입니다. 그렇기 때문에 임시 솔루션이 거의 제공되지 않습니다.

그리고 당신은 app-version 플래그에 대해 옳습니다. 제공해야 하며 Helm은 모든 것을 자체적으로 처리해야 합니다.

질문해도 될까요? 제품에서 Helm을 어떻게 활용합니까? helm install 를 사용할 때? 정확히 어떻게 사용합니까? helm package 사용을 고려해 보셨습니까?

어제 밤에 helm package 다시 살펴보았습니다. 나는 그것에 대해 정말로 팔리지 않았다. sed 은 매우 오랫동안 사용되어 왔으며 매우 안정적입니다. 이러한 모든 tiller / package / install 하위 명령은 상대적으로 새롭고 덜 안정적입니다. 내 요점을 명확히 하기 위해 몇 달 전에 나는 Tiller의 필요성을 우회하는 누군가의 플러그인을 보았음에도 불구하고 "분명히 Tiller가 해결될 수 있다"고 결정했습니다. 나는 플러그인을 덜 주류가 되어야 하는 것으로 보았지만 그 이후로 스스로를 걷어차고 있습니다. 플러그인을 믿었더라면 지금보다 훨씬 더 나은 위치에 있었을 것입니다. Helm의 유지 관리자는 유지 관리할 수 없는 디자인이며 향후 릴리스에서 사라질 것이라는 데 동의했습니다.

이러한 간단한 sed 작업을 수행하기 위해 helm package 를 사용하는 것은 제 실수라고 생각합니다. 어쨌든 package 의 사용 사례는 무엇입니까? 나는 helm package 의 전체 개념이 웹 2.0/버전 제어 릴리스의 요점을 놓치는 것처럼 느낍니다. 현대 기술 그룹이 동일한 프로세스를 달성하기 위해 태깅의 힘을 활용하고 있을 때 처음에는 바이너리 zip으로 패키징함으로써 그러나 더 간결하고 감사 가능한 방식으로.

제 사용 사례의 경우 앱 개발자가 컨테이너화된 애플리케이션을 코드화하고 유지 관리 가능한 방식으로 배포할 수 있도록 하고 있으므로 오버헤드(운영/경정 시스템 관리자, 중복 릴리스 아티팩트 관리 등)를 최소화하는 것이 가장 중요합니다. 내 사용법은 가장 잘하는 도구를 사용하기로 결정하고 적절한 경우 다른 도구(예: sed)로 전환하는 유닉스 철학을 더 밀접하게 따른다고 생각합니다. 모든 것을 완벽하게 수행할 수 있는 하나의 도구를 찾지 못할 것이라고 생각합니다. 하지만 현재 작업 흐름에 만족한다면 자신의 철학을 따르는 것을 단념하지 마십시오.

@IRobL

나쁜 습관이라고 하면 helm 명령을 스크립팅으로 감싸야 하는 것이 바람직하지 않다는 말씀이신가요?

예. 이것은 정확하게.

내 사용 사례에서 파이프라인 라이브러리는 도커 컨테이너를 빌드하고 게시하고 궁극적으로 애플리케이션의 빌드 파이프라인에서 helm을 통해 배포합니다.

이것이 바로 우리가 하고 있는 일이기도 합니다.

우리 회사의 빌드 파이프라인 라이브러리에서 이 문제를 해결한 후에도 Helm에 --app-version 스위치가 내장되어 있으면 확실히 더 편할 것입니다.

나는 이것을 한 단계 더 나아가 appVersion 가 Chart.yaml 파일의 속성이 되도록 하는 것이 아마도 올바르지 않다고 말할 것입니다. 값을 즉석에서 변경할 수 있는 경우 "불변 값 집합"으로 간주되지 않아야 합니다. 나는 이전 의견에서 같은 것을 옹호했다고 생각합니다.

이러한 모든tiler/package/install 하위 명령은 비교적 새롭고 덜 안정적입니다.

FWIW, Tiller 는 Helm 3에서 다루지 않을 것입니다. 당신은 나중에 당신의 포스트에서 이것을 언급했습니다. 그러나 "kubernetes 바이너리"를 생성하고 이를 Tiller 로 배송하는 helm package 구문이 아마도 나쁜 습관일 수 있음을 보여주기 때문에 이것을 반복합니다.

이러한 간단한 sed 작업을 수행하기 위해 helm 패키지를 사용하는 것은 내 실수라고 생각합니다. 어쨌든 패키지의 사용 사례는 무엇입니까?

나는 아마도 이것에 대해 Helm 팀을 옹호할 수 있을 것입니다. 내가 주도권을 잡은 것은 애플리케이션 개발자 가 Kubernetes 내부에서 애플리케이션을 올바르게 실행 하는 방법을 지정하도록 하는 방법이었습니다. 그렇기 때문에 애플리케이션 공급자는 배포의 주어진 버전을 다운로드하기 위해 추가할 수 있는 자체 Helm 저장소를 실행합니다. Helm 팀은 의도한 대상 프로덕션 팀이 CI/CD에서와 같이 일상적인 워크플로에서 Helm을 사용하지 않을 것이기 때문에 애플리케이션 코드와 인프라 코드가 서로 얽혀 있는 것으로 보았을 것입니다. 예: 우리는 평균적으로 하루에 helm upgrade 130번 사용합니다. 의도된 용도는 아닌 것 같아요.

아마도 사람들이 "나는 mysql을 kubernetes에 설치하고 싶습니다"라고 말하는 것이 훨씬 더 일반적이었고 helm은 kubernetes에 대해 거의 알지 못하고 그냥 가지고 노는 사람들을 위해 (상대적으로) 쉬운 방법이었습니다.

따라서 helm package 는 궁극적으로 _그 청중_이 소비하도록 의도되었습니다. 이 도구는 팀(내 생각에)이 도구를 선택하지 않을 것이라고 생각했거나 원래대로 사용할 의도가 전혀 없었던 영역에서 훨씬 더 많이 사용되고 있습니다.

내 사용법은 가장 잘하는 도구를 사용하기로 결정하고 적절한 경우 다른 도구(예: sed)로 전환하는 유닉스 철학을 더 밀접하게 따른다고 생각합니다.

나는 기본적으로 awk 처럼 Helm을 kubectl apply -f 다음에 처리합니다. 인적 오류를 피하기 위해 자동화된 도구가 값을 처리하도록 하는 것이 훨씬 더 깔끔합니다.

당신과 나는 같은 가치관을 많이 갖고 있고 비슷한 일을 많이 하고 있는 것 같습니다.

@IRobL

경운기

저에게 tiller 는 허용되지 않습니다. 노출 지점이 하나 더 추가되고 보안 위험이 추가되고 가장 중요한 것은 다른 API를 사용하여 yaml 파일을 적용하는 또 다른 방법을 만드는 것뿐입니다. Tiller는 프로세스를 적용하는 Helm 패키지를 보호하고 정렬하도록 설계되었지만 위험이 너무 많고 추가 소프트웨어(및 버전 관리)가 있습니다. 그래서 Helm 3rd에서는 사용하지 않습니다.

이러한 간단한 sed 작업을 수행하기 위해 helm 패키지를 사용하는 것은 내 실수라고 생각합니다.

내 요점을 놓치고 있는 것 같아요. 다시 시도하겠습니다. sed 는 무엇을 위해 만들어졌습니까? 데이터 스트림을 변환합니다. 변환 문제를 추상화하여 주어진 입력에 대한 API와 결과를 제공해야 합니다.

sed 명령이 작동하지 않는 스크립트를 만든 경우(즉, 정규식에 실수가 있는 경우)? 그래서 당신은 결론을 내렸지만 작동하지 않습니다. sed 가 자체적으로 작동하지 않는 이유를 이해하려고 합니까, 아니면 펄 스크립트로 파이프를 하나 추가하시겠습니까?

모든 솔루션이 마찬가지입니다. API를 제공하고, 입력을 받고, 출력을 제공해야 하며, 한 가지 문제를 추상화해야 합니다. 유닉스 스타일입니다.

Helm에 투영하여 릴리스 버전을 지정하고 K8에 푸시하도록 설계되었습니다. 템플릿을 사용하여 구성을 사용자 정의할 수 있습니다. 따라서 문제를 관찰하고 있는 경우 버전을 제공해야 합니다. Helm은 버전을 관리하는 간단한 메커니즘을 제공하고 빌드 작동 방식을 사용자 정의하는 쉬운 방법을 제공합니다. 따라서 추가 소프트웨어로 해결 방법을 추가하는 대신 작동 방식을 이해하려고 하지 않겠습니까?

@jrkarnes

예, 우리 둘 다 비슷한 관심사를 염두에 두고 주도권에 접근하고 있습니다. package 명령의 뿌리가 틸러가 만든 실수와 얽혀 있다는 사실을 전혀 깨닫지 못했습니다. 이러한 통찰력을 저와 공유해 주셔서 감사합니다!

그것은 이미 정의되어 있기 때문에 실제로이 기능을 방금 추가되지 않는 이유의 역사를 검토하고이 기능을 추가 할 수 없습니다 이유에 두 개의 인수를 보았다, 사람 이었다는 것을 package 그들은 또한 안 install / upgrade 에도 정의해야 합니다. 나는 그것에 대해 공감합니다. 이것은 기술 부채 문제처럼 들립니다. 기술 부채가 없는 공개적으로 사용되는 소프트웨어는 없습니다. 다른 이유는 Chart.yml 파일이 메타데이터이고 업데이트되어서는 안 된다는 것이었습니다. 그것은 나를 이상하게 생각했습니다... 사람들이 조타력 차트를 개발할 때, 확실히 그들은 상황이 변할 때 수동으로 그 파일을 업데이트하므로 그 자체가 불변하지 않습니다. 대조적으로 실제로 변경할 수 없는 배포 개체를 빌드할 때 helm 바이너리에 매개 변수를 제공하는 방법으로 Chart.yml 파일을 보는 것이 더 쉽습니다.

빌드 플랫폼은 무엇입니까? 내가 작성하는 파이프라인 코드는 Jenkins를 위해 글로벌 파이프라인 라이브러리로 작성되었습니다.

@IRobL 핵심 문제는 Helm을 배포 스크립트로 보고 있다는 것입니다. 하지만 헬름은 그렇지 않습니다. Helm은 추상화 계층입니다. Helm은 모든 아티팩트를 가져와 하나의 작업 단위로 K8에 플랫폼으로 적용합니다.

Helm은 포장업체입니다. Helm은 배포가 용이하도록 설계되었습니다. 아티팩트에서 "설치 프로그램"을 생성하므로 OS - K8에 "설치"할 수 있습니다.

app-version 에서 install 기술 빚과는 아무 상관이 없습니다. install 또는 upgrade 을 원할 때 전혀 필요하지 않습니다. Chart.yml 입니다. 실제 차트 버전이 포함된 기본 구성 파일이지만 차트는 소프트웨어가 아니기 때문에 전혀 변경해서는 안 됩니다. 당신은 단지 그것을 잘못 사용하고 있습니다.

그런 관점에서 왜 package 사용을 고려하지 않습니까? 너무 복잡해 보이죠?

이 문제에 대한 루프에서 잠시 벗어났지만 이런 종류의 요점이 몇 번 발생하는 것을 보았습니다.

Helm은 포장업체입니다. Helm은 배포가 용이하도록 설계되었습니다. 아티팩트에서 "설치 프로그램"을 생성하므로 OS - K8에 "설치"할 수 있습니다.

기본적으로 Helm은 _어떤 식으로든_ 설치 프로그램을 생성하지 않습니다. "바이너리"를 생성하지 않습니다. ".deb" 파일이나 이와 유사한 것을 생성하지 않습니다. 일부 기본값 및/또는 사전 설정 값을 사용하여 Kubernetes 매니페스트의 일부 템플릿 아카이브를 생성합니다. 실제 소프트웨어는 해당 Helm 차트에 존재하지 않습니다. 함께 포장되어 있지 않습니다. 불변성을 보장하지 않습니다.

대부분의 경우 Helm 차트가 Chart를 통해 배포하는 소프트웨어보다 _lot_ 적게 변경될 것이라고 말하는 것이 공정하다고 생각합니다.

이것이 --app-version 가 helm install 및 helm upgrade 사용 가능한 근본적인 이유(적어도 IMO)입니다. 말 그대로 아무 것도 변경되지 않은 경우 차트를 다시 패키지해야 하는 이유는 무엇입니까?

나는 Helm Chart를 Kubernetes 매니페스트에 대한 버전 설명으로 보고 있으며, 애플리케이션을 성공적으로 실행할 Kubernetes 구성 요소 세트를 설명합니다. 그게 제가 보는 전부입니다. 이 지침을 변경해야 하는 경우 차트를 업데이트하고 싶습니다. 애플리케이션이 변경될 때마다가 아니라 이미지 버전(어쨌든 값을 통해 설정하는 경우가 많음)만 업데이트하면 됩니다.

예를 들어 Flux와 Helm Operator가 어떻게 작동하는지 살펴보십시오. 이미지 태그 값을 자동으로 업데이트하도록 할 수 있습니다. 차트는 업데이트하지 않고 배포 중인 이미지 태그만 업데이트합니다.

일부 기본값 및/또는 사전 설정 값을 사용하여 Kubernetes 매니페스트의 일부 템플릿 아카이브를 생성합니다.

그러나 deb 파일은 구성 파일, 명령, 매니페스트 및/또는 사전 설정 값의 동일한 집합입니다. MSI 설치 프로그램과 동일하거나 젠토 이머징 패키지 시스템의 ebuild에 더 가깝습니다. 또한 Brew 패키지와 동일합니다.

K8의 패키지 관리자가 아닌 경우 Helm은 무엇입니까? 당신이 보는 차이점은 무엇입니까?

불변성을 보장하지 않습니다.

왜 안 돼? 패키지 생성 후 패키지를 변경하면 잘못된 것입니다. install/upgrade 프로세스 중에 추가 옵션을 제공하면 모든 패키징 시스템에서와 같이 의도된 것입니다.

Kubernetes 매니페스트의 버전 설명으로 Helm 차트가 표시됩니다.

이미 GIT가 있습니다. 그렇다면 왜 투구가 필요할까요?

대부분의 경우 Helm 차트가 Chart를 통해 배포하는 소프트웨어보다 훨씬 적게 변경될 것이라고 말하는 것이 공정하다고 생각합니다.
이것이 helm 설치 및 helm 업그레이드에서 --app-version을 사용할 수 있는 근본적인 이유(적어도 IMO)입니다. 말 그대로 아무 것도 변경되지 않은 경우 차트를 다시 패키지해야 하는 이유는 무엇입니까?

이 디자인에서 appVersion은 Helm 패키지 빌드의 속성으로 취급되어서는 안됩니다. 값에서 구성 매개변수로 처리되어야 합니다.

예를 들어 Flux와 Helm Operator가 어떻게 작동하는지 살펴보십시오. 이미지 태그 값을 자동으로 업데이트하도록 할 수 있습니다. 차트는 업데이트하지 않고 배포 중인 이미지 태그만 업데이트합니다.

이 경우 앱 인프라 매니페스트와 앱 버전의 결합이 느슨해집니다. 이미지 태그를 변경해도 새 조타 장치 업그레이드가 트리거되지 않기 때문에(Flux 사용자가 다른 방식으로 수행하는 경우 수정하십시오). 이 경우 Helm을 구성 템플릿으로 사용할 수 있습니다. 이 경우 --app-version 가 전혀 필요하지 않습니다.

그러나 deb 파일은 구성 파일, 명령, 매니페스트 및/또는 사전 설정 값의 동일한 집합입니다. MSI 설치 프로그램과 동일하거나 젠토 이머징 패키지 시스템의 ebuild에 더 가깝습니다. 또한 Brew 패키지와 동일합니다.

.deb 및 .msi 패키지에 대한 귀하의 설명에는 하나의 핵심 구성요소가 누락되었습니다. .deb 파일의 내용을 살펴보면 빌드된 소프트웨어 - 설치될 _THE_ 소프트웨어를 찾을 수 있습니다. 일반적으로 말해서(항상 .deb ?의 경우) 배포되는 응용 프로그램은 본질적으로 연결되어 있으며 해당 패키지의 일부입니다(brew의 경우 아님).

양조 패키지는 다르며 실제로 같은 방식으로 비교할 수 없습니다. Brew는 설치 방법과 소스/패키지를 다운로드해야 하는 위치에 대한 지침일 뿐이므로 실제로 현재 Helm과 훨씬 유사합니다.

여기에서 절대적으로 명확합니다. Helm 차트는 _본질적으로 특정 애플리케이션 버전에 연결되어 있지 않으며_ 배포되는 인공물(예: Docker 이미지)을 포함하지 않습니다. 여기에는 참조만 포함되며 해당 참조 뒤에 있는 값은 변경될 수도 있습니다(예: 원하는 경우 동일한 Docker 태그로 푸시할 수 있음). 따라서 어떤 일이 있어도 Helm 차트는 애플리케이션의 패키지 버전이 아니며 특정 버전의 애플리케이션에도 엄격하게 연결되어 있지 않습니다.

예를 들어 안정적인 차트 리포지토리를 살펴보기만 하면 됩니다. 값을 통해 사용 중인 이미지를 재정의할 수 있는 애플리케이션이 몇 개나 될까요? (많이_)

K8의 패키지 관리자가 아닌 경우 Helm은 무엇입니까? 당신이 보는 차이점은 무엇입니까?

Kubernetes 매니페스트를 템플릿화하고 쉽게 배포 및 설치하는 기능을 제공하는 도구입니다. 여기서 핵심은 Helm이 다루는 모든 것입니다. Kubernetes 매니페스트입니다.

이 모든 것이 제 요점으로 돌아갑니다. 해당 매니페스트가 변경되거나 어떤 이유로든 해당 매니페스트에 대한 템플릿이 변경되어야 하는 경우 Helm 차트를 실제로 변경해야 하는 경우입니다.

내가 보는 주요 합병증은 2가지 사용 사례가 있다는 것입니다.

• 타사 애플리케이션 배포.
• 자사 애플리케이션 배포.

타사 응용 프로그램의 경우 Helm 소비자로서 각 새 응용 프로그램 버전과 함께 Helm 차트가 릴리스되는 것이 바람직합니다. 여기서 한 가지 주요 차이점은 릴리스 빈도입니다. MySQL 또는 무엇이든 간에 타사 Helm 차트는 하루에 여러 번 변경되지 않을 가능성이 높습니다. 이 경우 실수로 새 버전의 소프트웨어와 함께 이전 버전의 차트를 사용하는 것을 원하지 않습니다. 직접 작성하지 않은 소프트웨어와 차트를 사용하면 훨씬 쉽게 실수를 할 수 있습니다.

자사 응용 프로그램의 경우 응용 프로그램 클래스를 배포하는 표준 방법이 있을 수 있습니다. 예를 들어 Icelolly에서는 거의 동일한 방식으로 Go 서비스를 작성하고 배포합니다. 이를 위해 실제로 Kubernetes에 배포된 모든 Go 서비스에 대해 단일 차트를 사용할 수 있습니다(현재 helm package 해결 방법 사용). 자체 애플리케이션 배포에 대한 접근 방식이 변경되면 차트를 업데이트합니다. SemVer로 차트의 버전을 지정하므로 업데이트되지 않은 애플리케이션은 업데이트할 때까지 영향을 받지 않습니다.

그냥 이 메모에; go-service 차트는 약 한 달 전에 마지막으로 업데이트되었습니다. 그 기간 동안 우리는 차트를 변경하지 않고 수십에서 수백 개의 배포를 수행했을 것입니다.

어떤 경우에는 단순함을 원합니다. 다른 경우에는 제어 및 관리 용이성을 원합니다.

이 경우 앱 인프라 매니페스트와 앱 버전의 결합이 느슨해집니다. 이미지 태그를 변경해도 새 조타 장치 업그레이드가 트리거되지 않기 때문에(Flux 사용자가 다른 방식으로 수행하는 경우 수정하십시오). 이 경우 Helm을 구성 템플릿으로 사용할 수 있습니다. 이 경우 --app-version이 전혀 필요하지 않습니다.

Flux는 실제로 차트를 업그레이드하는 데 사용하는 값을 변경한 다음 새 이미지 값으로 업그레이드를 실행합니다. 인프라 매니페스트와 앱 버전의 결합을 잃는 것에 대한 귀하의 요점은 여전히 ​​유효합니다. 내가 주장하는 요점은 일부 사용 사례에서는 실제로 그렇게 하는 것이 바람직하다는 것입니다. 하지만 이 사용 사례에서는 --app-version 가 필요하지 않습니다. 현재 존재하지 않기 때문에 사용되지 않습니다. 만약 그렇다면 Flux가 그것을 사용할 수 있을 것입니다. 그런 경우에 실제로 도움이 됩니다.

helm list 는 유용한 명령입니다. 어떤 애플리케이션 버전이 배포되었는지 확인할 수 있다는 것은 여전히 ​​유용합니다. 현재와 투구를 통해 설치 우리의 응용 프로그램의 경우 helm package 우리는 (를 통해 응용 프로그램 버전 설정 방법 --app-version 에 helm package ) 정도의 출력 것을 helm list 있다 유용한. 그렇기 때문에 helm install|upgrade 설정할 수 있다면 더 간단할 것입니다. 버전을 변경하기 위해 차트를 가져와 다시 패키징할 필요가 없습니다.

사실, helm list 및 롤백 처리는 우리가 자사 소프트웨어에 대해 Helm을 사용하는 유일한 이유일 것입니다.

여기에 있는 .deb 및 .msi 패키지에 대한 설명에는 하나의 핵심 구성 요소가 누락되어 있습니다.

"설치"는 대상 플랫폼에 필요한 기능(폴더, 구성, 바이너리, db 가져오기, 데이터 새로 고침/이전)을 설정하는 과정입니다.

deb는 모든 것을 처리합니다. Helm 패키지도 마찬가지입니다. Helm 패키지가 "실제로 설치"되지 않았다는 것은 무엇을 의미합니까?

.deb 파일의 내용을 살펴보면 빌드된 소프트웨어, 즉 설치될 소프트웨어를 찾을 수 있습니다.

거짓. 때로는 소프트웨어 자체를 찾을 수 있습니다. 때로는 소프트웨어 조각을 찾을 수 있습니다. 때때로 그러한 소프트웨어를 가져오기 위한 스크립트 세트 외에는 아무것도 찾을 수 없습니다. 따라서 여기서 요점 은 중요하지 않습니다. Linux와 K8은 하나의 범용 응용 프로그램 형식을 허용하는 지정된 응용 프로그램을 호스팅하는 플랫폼 이기 때문입니다. 그리고 이미지 이름, 구성 매개변수는 패키지의 일부입니다.

Brew는 설치 방법과 소스/패키지를 다운로드해야 하는 위치에 대한 지침일 뿐이므로 실제로 현재 Helm과 훨씬 유사합니다.

정확히. Brew가 패키지 관리자가 아니라는 것을 설득하려는 건가요?

여기에서 절대적으로 명확합니다. Helm 차트 _본질적으로 특정 애플리케이션 버전에 연결되지 않습니다 ...
값을 통해 사용 중인 이미지를 재정의할 수 있는 애플리케이션이 몇 개나 될까요? (많이)

너가 확실히 맞아. Helm은 k8s 템플릿을 위한 편리한 템플릿 엔진에 불과합니다. 나는 그러한 소프트웨어 존재에 문제가 없습니다. 약간의 도움이 되지만 현대의 전달 방식을 바꾸지는 않을 것입니다.

문제는 Helm이 템플릿 엔진 이상이라는 것입니다. 모든 장점과 단점이 있는 패키징 관리자입니다. 그리고 패키지 매니저가 존재하는 생태계에서는 다른 패키지 매니저가 관리하게 하는 것은 나쁜 습관입니다. 더 나쁜 것은 패키지 관리자 없이 작동합니다.

이 패키지에 대한 패키지 인수로 앱 버전을 만드는 이유를 봅니다. 그리고 저는 여러분과 여러분 모두가 패키지를 만들지 말아야 할 이유를 봅니다. 문제는 접근 방식이 구식이고 복잡하며 관리하기 어렵다는 것입니다. 재미있는 것은 비용은 적지만 얻을 수 있다는 점입니다.

내가 주장하는 요점은 일부 사용 사례에서는 실제로 그렇게 하는 것이 바람직하다는 것입니다.

네, 이것이 핵심입니다. 어떤 제품에나 바람직한가?

귀하의 주장은 투구 차트는 거의 변경되지 않는데 왜 각 릴리스마다 함께 포장해야 한다는 것입니다. 동의합니다. 불필요한 느낌입니다. 그러나 어쨌든 우리는 여전히 오래된 소스 파일, 오래된 사이드카(Helm이 여러 앱으로 구성된 경우), 오래된 구성, 오래된 Dockerfile을 패키징합니다.

따라서 문제는 전체 차트를 아티팩트로 패키징하면 각 빌드에서 어떤 이점이 있습니까? Dockerfile의 경우 분명합니다(그러나 시장에 컨테이너화가 등장했을 때 분명하지 않았습니다). 소스 파일도 마찬가지입니다.

예전에는 가능한 가장 명확한 전달 메커니즘이 있었습니다. FTP를 통해 변경된 파일만 업로드하는 것이었습니다. 이제 우리는 많은 것을 가지고 있습니다. 무엇이 좋은지, 왜 좋은지, 누가 사용해야 하는지를 결정해야 합니다. Helm이 두 가지 접근 방식을 동시에 처리하는 데 만족할지 확신이 서지 않습니다. 너무 복잡합니다.

타사 애플리케이션 배포.

Helm 차트만 사용하여 모든 PSQL/MySQL 버전을 설치할 수 있다면 정말 기쁠 것입니다. 레거시 프로젝트를 유지 관리하고 초보자에게 인프라를 소개하는 것이 훨씬 쉬울 것입니다. 차트 업데이트에 대한 알림을 받는 것이 훨씬 쉽습니다. 바이너리에 대해 각 릴리스에 대해 많은 tar.gz 파일이 있지만 Helm 패키지에 대해 동일한 tar.gz 파일 세트를 가질 수 없는 이유는 무엇입니까?

@iorlas 방금 이 글과 거부된 PR을 읽었으며 아주 좋은 지적을 하셨습니다. 당신은 내가 내 빌드/릴리스의 또 다른 아티팩트로서 내 투구 차트를 패키징하기 시작해야 한다고 확신했습니다.

그러나 나는 helm에 패키지 명령이 있는지조차 몰랐으며 혼자가 아닐 것이라고 생각합니다. 그것은 아마도 소스 디렉토리에서 차트를 설치하는 것이 너무 쉽기 때문일 것입니다. 그러나 문서에서는 개념을 실제로 판매하거나 자세히 설명하지도 않습니다.

package 명령은 분명히 문서화되어 있지만 빠른 시작 가이드 에는 패키지에 대한 몇 가지 매우 일반적인 언급 만 있습니다. 사실 패키지라는 단어는 빠른 시작에 많이 표시되지만 대부분 Helm 및 다른 OS 패키지를 설치하는 방법에 대해 이야기하고 있습니다. . 포장도 모범 사례에서 언급되지 않았으며 포장이 무엇인지, 왜 유용한지 캡처하는 것이 포함되어야 한다고 생각합니다. 나는 또한 약간 다른 구조를 가지고 있지만 사용자가 차트를 패키지화하도록 제안하는 데 슬림한 것으로 보이는 v3 문서 도 확인했습니다.

일반적으로 나는 PR을 제출하고 싶습니다. 단지 뭔가에 대해 불평하는 것처럼 들리지 않지만 3.0 문서 변경 사항이 어떻게 진행되고 있는지 잘 모르겠습니다.

@jonstelly 문서에는 확실히 공백이 있습니다. 나도 처음에는 --app-version 을 사용하는 것이 좋다고 생각했지만 나중에는 이유 없이 누락된 상태로 둘 수 없었습니다.

문서에는 확실히 몇 가지 설명과 일반적인 문제 소개가 필요합니다. 그런 다음 Helm 개발 주기를 소개합니다. 하지만 팀은 3차 버전으로 바쁘다고 생각합니다. 그리고 저도 지금 너무 바쁩니다 :(

"설치"는 대상 플랫폼에 필요한 기능(폴더, 구성, 바이너리, db 가져오기, 데이터 새로 고침/이전)을 설정하는 과정입니다.

deb는 모든 것을 처리합니다. Helm 패키지도 마찬가지입니다. Helm 패키지가 "실제로 설치"되지 않았다는 것은 무엇을 의미합니까?

Helm Chart 자체가 설치되어 있지 않다는 의미는 아닙니다. Helm Chart에는 배포하는 실제 응용 프로그램이 포함되어 있지 않습니다. Docker 이미지는 Helm 차트에 패키징되지 않습니다. Kubernetes가 외부 소스에서 가져옵니다.

거짓. 때로는 소프트웨어 자체를 찾을 수 있습니다. 때로는 소프트웨어 조각을 찾을 수 있습니다. 때때로 그러한 소프트웨어를 가져오기 위한 스크립트 세트 외에는 아무것도 찾을 수 없습니다. 따라서 여기서 요점은 중요하지 않습니다. Linux와 K8은 하나의 범용 응용 프로그램 형식을 허용하는 지정된 응용 프로그램을 호스트하는 플랫폼이기 때문입니다. 그리고 이미지 이름, 구성 매개변수는 패키지의 일부입니다.

내가 아는 한, 실제로 당신은 여기에서 틀렸습니다. .deb 파일은 AR 아카이브입니다. 압축을 풀고 내용을 볼 수 있으며 궁극적으로 일부 메타 데이터와 일부 파일입니다. .deb 파일은 이론적으로 패치를 포함할 수 있지만 종종 그렇지 않습니다. .deb 파일에 소프트웨어를 가져오기 위한 스크립트가 포함되어 있으면 소프트웨어 자체가 아니라 .deb 파일에 의해 설치되는 스크립트임을 의미합니다. 설치 프로그램을 설치하는 것과 같습니다.

.deb 가 .deb 파일을 설치하는 과정의 일부로 설치할 소프트웨어를 다운로드하는 .deb 패키지된 Linux 소프트웨어의 예가 있는 경우 , 그렇다면 정말 보고 싶습니다. Linux를 사용한 수년 동안 문자 그대로 본 적이 없기 때문입니다.

정확히. Brew가 패키지 관리자가 아니라는 것을 설득하려는 건가요?

아니요. 내가 말하고자 하는 것은 Helm과 마찬가지로 Brew를 통해 소프트웨어를 설치하기 위해 제공되는 스크립트가 바로 스크립트라는 것입니다. 응용 프로그램은 별도로 빌드, 패키지 및 배포되며 해당 스크립트에서 가져옵니다. 내가 말했듯이 Helm을 Kubernetes 패키지 관리자로 만들지 않는 것처럼 Brew를 패키지 관리자로 만들지 않습니다. 이것이 이 문제의 요점이 아닙니다. 우리는 Helm이 패키지 관리자인지 아닌지에 대해 토론하는 것이 아니라 --app-version 플래그를 helm install|upgrade 추가해야 하는지 여부를 결정하려고 합니다

이 패키지에 대한 패키지 인수로 앱 버전을 만드는 이유를 봅니다. 그리고 저는 여러분과 여러분 모두가 패키지를 만들지 말아야 할 이유를 봅니다. 문제는 접근 방식이 구식이고 복잡하며 관리하기 어렵다는 것입니다. 재미있는 것은 비용은 적지만 얻을 수 있다는 점입니다.

죄송합니다. 무슨 말씀이신지 잘 모르겠습니다. 구식/복잡/관리하기 어려운 것은 무엇입니까?

따라서 문제는 전체 차트를 아티팩트로 패키징하면 각 빌드에서 어떤 이점이 있습니까? Dockerfile의 경우 분명합니다(그러나 시장에 컨테이너화가 등장했을 때 분명하지 않았습니다). 소스 파일도 마찬가지입니다.

다시 한 번 말씀드리지만 차이점은 기본적으로 귀하가 언급한 모든 것이 본질적으로 연결되어 있다는 것입니다. 앱을 실행하려면 변경된 내용뿐만 아니라 모든 소스 코드가 필요합니다. Dockerfile을 패키징하지 않으므로 그 요점이 무엇인지 확실하지 않습니다. 그러나 새 버전의 이미지를 빌드하기 위해 변경하지 않고 동일한 Dockerfile을 사용하는 경우가 많습니다. 시간, 그렇지?). 이러한 모든 것을 사용하여 필요한 모든 것을 캡슐화하여 격리 배포할 수 있는 것을 만들고 있습니다. 따라서 새 노드를 스핀업하고 기존 노드에 배포하는 것과 같은 방식으로 배포하는 등의 작업을 수행할 수 있습니다.

이미 알고 계시겠지만 FTP를 통해 이전 업로드를 사용하는 것보다 _많은_ 혜택이 있습니다.

어쨌든 이것은 모두 by by입니다. 제 생각에는 궁극적으로 이미 언급했듯이 이 모든 것이 다음과 같습니다. Helm 유지 관리자는 이 다른 사용 사례를 활성화하고 싶습니까? 아니면 사람들이 이 방법을 사용하는 것을 더 어렵게 만드나요? 결국 어느 쪽이든 _정말로_ 큰 차이는 아닙니다. 저에게는 애플리케이션 버전을 설정하기 위해 각 빌드에서 거의 변경되지 않는 내부 차트를 패키지화하지 않아도 된다면 좋을 것입니다. 이 차트는 다시 목록의 현재 버전을 표시하는 데만 사용됩니다. 퍼스트 파티 앱의 경우 솔직히 말해서 Helm이 어쨌든 올바른 접근 방식인지 의문이 들었습니다.

Docker 이미지는 Helm 차트로 패키징되지 않습니다.

사실 그렇게 됐으면 좋겠어요. 하지만 지금은 아닙니다. 내 비전은 K8이 패키지를 설치하기 위한 API로 Helm을 통합하는 플랫폼이 되어야 한다는 것입니다. deb 파일의 단순성으로 돌아가지만 적절한 격리 및 k8 리소스를 일급 시민으로 사용합니다.

.deb 파일은 AR 아카이브입니다.
추출하여 내용을 볼 수 있습니다.
궁극적으로 일부 메타데이터입니다.
그리고 일부 파일

마치.... 투구 패키지!

다음이 있는 경우 ... a .deb가 있는 경우 .deb가 .deb 파일을 설치하는 과정의 일부로 설치할 소프트웨어를 다운로드합니다.
설치 프로그램을 설치하는 것과 같습니다. ...

예, 내부에 설치 프로그램이 있는 설치 프로그램과 같습니다. 재미있지, 그렇지? 앱 인스턴스를 설정하는 데 충분 하다면 가능한 한 하나의 아티팩트를 사용 하겠습니다. 그러나 우리는 다른 소프트웨어, 다른 출처의 진실을 가지고 있으며 때로는 여러 출처를 갖는 것이 편리합니다.

• Brew에는 패키지로 YAML이 있지만 원격 저장소에서 바이너리를 가져옵니다.
• Emerge(gentoo)는 정의로 ebuild를 가지고 있으며, git 클론도 다운로드합니다.

데비안은 모든 것을 내부에 패키징하려고 합니다. 그리고 가능하면 하는 것이 옳습니다. 그러나 내 요점을 증명하기 위해 메타패키지 가 그렇게 할 것입니다. 그것에 대해 들어본 적이 있습니까? 다른 패키지를 설치하는 패키지입니다. 패키지 아닌가요?

하지만 요점을 놓치지 마세요. 중요하지 않습니다 ! 내부에 참조만 있는 빈 패키지도 패키지입니다. 설치기사님, 다른 용어를 받아들이시겠습니까?

Helm과 마찬가지로 Brew를 통해 소프트웨어를 설치하기 위해 제공되는 스크립트는 스크립트일 뿐입니다.
응용 프로그램은 별도로 빌드, 패키지화 및 배포되며 해당 스크립트에서 가져옵니다.

그리고 우리는 모두 도커 이미지를 구축하기 위해 동일한 파이프라인을 가지고 있습니다.

일반적인 사용 사례를 용이하게 하기 위해 helm install|upgrade에 --app-version 플래그를 추가해야 하는지 여부를 결정하려고 합니다.

그게 열쇠야. 하지만 어떻게 결정할 수 있습니까? 우리는 두 가지 질문을 해야 합니다.

• 가능합니까? 네
• 하는 것이 옳은 일입니까? 네? 아니?

ppl이 무언가를 하고 있다면 그것이 좋은 일이라는 의미입니까? 진전을 이루기 위해서는 모든 것에 의문을 제기해야 합니다.

죄송합니다. 무슨 말씀이신지 잘 모르겠습니다. 구식/복잡/관리하기 어려운 것은 무엇입니까?

Brew는 Helm에 정말 가깝고 이미 널리 사용되고 있기 때문에 Brew에 프로젝트를 맡기십시오. Gentroo Ebuilds 또는 deb에 투영할 수 있습니다. 그림은 변경되지 않습니다.

• 시대에 뒤쳐진. 마지막으로 MySQL/PSQL을 수동으로 설치해야 했던 때가 언제였습니까? 왜 우리는 그것에서 옮겼습니까? 이러한 이유, 새싹.
• 복잡한. 이것은 "이유" 중 하나입니다. 인프라를 독립적으로 설정해야 하고 어떤 것이 어떤 소프트웨어 버전과 가장 잘 작동하는지 알아야 합니다. 특정 소프트웨어 버전을 실행하기 위해 인프라를 사용자 지정해야 하는 경우가 있습니다. 귀찮게 왜? 왜 전체 질문을 위임하지 않습니까?
• 관리하기가 더 어렵습니다. 아티팩트가 하나만 있을 수 있는 경우 인프라와 앱 버전을 모두 관리해야 합니다. 왜 당신의 삶을 더 힘들게 만드는가?

죄송합니다. 지금은 깨끗한 롤백, 우아한 업그레이드와 같은 모든 사용 사례를 설명하기가 다소 게으릅니다. 어쨌든 이것이 주요 보너스입니다.

다시 한 번 말씀드리지만 차이점은 기본적으로 귀하가 언급한 모든 것이 본질적으로 연결되어 있다는 것입니다.

항상은 아닙니다. 예를 들어 도커 이미지에는 SSR BE와 CDN에 대한 참조가 포함될 수 있습니다.

Dockerfile, 그래서 그 요점이 무엇인지 확실하지 않습니다. 하지만 새 버전의 이미지를 빌드하기 위해 변경하지 않고 동일한 Dockerfile을 사용하는 경우가 많습니다.

그게 요점입니다. Dockerfile이 변경되지 않은 경우에도 새 이미지를 빌드합니다. 소스 코드가 변경되지 않았지만 Dockerfile이 변경된 경우 새 이미지를 빌드합니다. 간단히 말해서 Dockerfile도 패키지입니다. 헬름도 마찬가지입니다. 그렇게 생각하지 않아?

이러한 모든 것을 사용하여 필요한 모든 것을 캡슐화하여 격리 배포할 수 있는 것을 만들고 있습니다. 따라서 새 노드를 스핀업하고 기존 노드에 배포하는 것과 같은 방식으로 배포하는 등의 작업을 수행할 수 있습니다.

하지만 도커 이미지만으로는 앱을 실행하기에 충분하지 않은 것으로 나타났습니다. 구성 인스턴스가 필요하고 서비스 정의가 필요합니다. 왜 모든 것을 포장하지 않습니까?

결국 어느 쪽이든 실제로 큰 차이는 아닙니다.

나는 믿습니다. 코드베이스에서는 그다지 중요하지 않을 수도 있지만 컨테이너화 발전을 정체시킬 것입니다.

Docker 이미지는 Helm 차트로 패키징되지 않습니다.

이미지 자체는 패키징되지 않지만 참조(핀으로 읽음)는 패키징됩니다. 물론, 우리는 현학적이어서 다양한 크기(MB에서 GB까지)의 문자 이미지가 helm package 의 아티팩트에 포함되는지 여부(스포일러: 그렇지 않음)에 따라잡힐 수 있지만 본질은 "특정 버전의 응용 프로그램 코드가 helm 패키지에 포함되어 있습니다"라는 문장은 여전히 ​​근본적으로 정확합니다. 방법에 얽매이기를 원하는지 여부는 중요하지 않습니다.

예제의 나라로 돌아가서 내부적으로 1.9.9 로 버전이 지정된 애플리케이션이 1.2.5 버전의 차트에서 실행되고 있다고 가정해 보겠습니다. 혼동이 없도록 하기 위해 애플리케이션 컨테이너의 Docker 이미지 샤는 fakeshaA 입니다.

팀은 애플리케이션의 2.0.0 버전에 HTTP를 통해 참조해야 했던 파일의 로컬 파일 시스템 버전이 있을 것이라고 결정했습니다. 그 이유는 중요하지 않지만 당신에게 미치는 결과는 매우 심각합니다. 이제 배포를 위해 pv 및 pvc 필요하므로 업그레이드 사이에 현재 로컬 파일이 손실되지 않습니다. 필요성을 확인하면 pv 및 pvc 되도록 Helm 차트를 업데이트하여 2.0.0 로의 이동이 큰 지장을 주지 않도록 합니다.

차트를 변경하기 전에 Artifact A 애플리케이션 버전 1.9.9 을 인프라 버전 1.2.5 합니다. 이제 차트를 변경합니다... _당신의 투구 차트는 이제 v. 1.3.0 _이고 1.9.9 를 인프라 버전 1.3.0 연결하는 아티팩트를 생성합니다. 이것을 Artifact B 라고 부르겠습니다.

2.0.0 대한 코드 배포가 Docker 이미지 sha fakeShaB 와 함께 실행되면 2.0.0 를 인프라 버전 1.3.0 연결하는 또 다른 아티팩트를 생성합니다. Artifact C

이제 2.0.0 릴리스에서 완전히 이해하지 못하는 문제가 있고 롤백해야 하는 문제가 있다고 가정해 보겠습니다. Artifact B ...를 사용하여 롤백하지만 문제가 해결되지 않으므로 Artifact A 다시 롤백하면 문제가 해결됩니다.

발생하는 유일한 문제는 아티팩트가 참조하는 Docker 레지스트리에 여전히 해당 아티팩트에서 참조되는 이미지가 있는지 여부입니다.

어떤 일이 있어도 애플리케이션 버전과 인프라 버전 간에는 여전히 연결되어 있습니다. 이것이 Helm의 목적입니다. 그렇지 않다고 주장하는 것은 어리석은 일입니다.

@iorlas :

.deb 비교는 제쳐두자. 우리만 곁길로 빠져드는 것 같아요.

항상은 아닙니다. 예를 들어 도커 이미지에는 SSR BE와 CDN에 대한 참조가 포함될 수 있습니다.

그것은 사실입니다. 나중에 더 자세히 설명합니다.

그게 요점입니다. Dockerfile이 변경되지 않은 경우에도 새 이미지를 빌드합니다. 소스 코드가 변경되지 않았지만 Dockerfile이 변경된 경우 새 이미지를 빌드합니다. 간단히 말해서 Dockerfile도 패키지입니다. 헬름도 마찬가지입니다. 그렇게 생각하지 않아?

그렇게 할 수 있지만 이는 해당 빌드 프로세스(예: Docker 이미지)의 끝 부분에 있는 제품이 Dockerfile과 여기에 넣는 것 _둘 다_에 의존하기 때문입니다. 이 두 가지 구성 요소 없이는 이미지가 존재할 수 없습니다.

반면에 Helm 차트는 애플리케이션이 빌드되기 전에도 존재할 수 있습니다. 말 그대로 한 줄의 코드가 작성되기 전입니다. 설치에 실패하는 가상의 차트를 만들 수 있지만 그럼에도 불구하고 Helm 차트는 다른 것이 없이 완전히 존재할 수 있습니다. 내가 말했듯이 이것은 쓸모가 없지만 나는 그것들이 전혀 연결되어 있지 않다는 점을 설명하려고 합니다.

여기서 내 요점은 Helm 차트가 차트에 의해 배포되는 응용 프로그램에 항상 본질적으로 연결되어 있지 않다는 것입니다. 나는 그것이 대담한 주장이라고 생각하지 않습니다. 그것은 이미 사실입니다. 저는 지금 프로덕션 애플리케이션으로 이 작업을 수행하고 있으므로 이 문제에 대해 언급한 다른 사람들도 마찬가지입니다. 그래서 제가 전에 말했듯이, 이 모든 것은 다음과 같습니다. Helm 유지 관리자가 이 사용 사례를 활성화하기를 원하는지 여부 - 다른 것은 없습니다.

하지만 도커 이미지만으로는 앱을 실행하기에 충분하지 않은 것으로 나타났습니다. 구성 인스턴스가 필요하고 서비스 정의가 필요합니다. 왜 모든 것을 포장하지 않습니까?

사실 그렇게 됐으면 좋겠어요. 하지만 지금은 아닙니다.

이것이 사실이고 Helm Chart가 실제로 배포된 모든 것을 패키징했다면(앞서 CDN을 언급했지만 Kubernetes에 배포하지 않았으므로 여전히 차트에 포함되지 않습니다), 저는 다음과 같이 생각합니다. 이 대화는 일어나지 않을 것입니다. 투구 차트는 Docker 이미지를 구축하는 것과 마찬가지로 배포 중인 애플리케이션 버전에 본질적으로 _연결될_ 것입니다. 해당 시나리오에서 투구 차트를 작성하려면 애플리케이션이 변경될 때 다시 작성 해야 하며, 이 시점에서는 문제가 없습니다. 내가 오늘날 사용하는 방식으로 Helm을 사용할 수 없습니다. 그렇게 하면 훨씬 더 명확해질 것입니다.

그러나 그것은 현실이 아닙니다. Helm이 작동하는 방식이 아니며 결국 Helm이 실제로 작동하는 방식이 될지 모르겠습니다. 하지만 절대 안된다고 하지마, 그렇지?

@jrkarnes :

이미지 자체는 패키징되지 않지만 참조(핀으로 읽음)는 패키징됩니다.

물론, 하지만 일반적인 사용 사례는 값을 사용하여 이 값을 재정의하는 것입니다. 타사 및 자사 차트와 함께 사용했습니다. 사람들이 사용하는 것이 아니라면 선택 사항이 아닙니다.

물론 우리는 현학적일 수 있고 다양한 크기(MB에서 GB까지)의 리터럴 이미지가 helm 패키지의 아티팩트에 포함되어 있는지 여부에 따라 잡을 수 있습니다(스포일러: 그렇지 않음).

나는 우리가 현학적이라고 생각하지 않습니다. 이미 지적했듯이 Docker 이미지가 "빌드된" Helm 차트 안에 패키지되어 있다고 말하는 것은 사실 잘못된 것입니다.

"응용 프로그램 코드의 주어진 버전이 helm 패키지에 포함되어 있습니다"는 여전히 기본적으로 정확합니다.

그러나 실제로는 그렇지 않습니다. 내 첫 번째 요점은 반대할 것입니다. 배포 중인 항목을 변경할 수 있습니다. 지옥, 당신은 당신이 원하는 경우 hello-world 이미지를 실행하도록 대부분의 차트를 변경할 수 있습니다. 그것은 쓸모가 없지만 내 요점을 훌륭하게 증명합니다. Helm Chart는 귀하의 응용 프로그램에 연결되어 있지 않습니다. 올바른 이미지와 함께 사용할 것이라는 _기대_가 있으며, 아마도 기본적으로 그렇게 할 것입니다. 그러나 확실히 _할 필요는 없습니다_ - 그리고 다른 방식으로 패키징된 Helm 차트에 포함된 애플리케이션 코드는 _아무도_입니다.

사례의 나라로 돌아가면 [...] 문제가 해결됩니다.

분명히 현재 의도된 방식으로 Helm을 사용하지 않고는 이것이 불가능한 것처럼 들리도록 만들었습니다. 그러나 실제로는 2가지 버전의 차트(즉, 2가지 인프라 버전)와 3가지 버전의 애플리케이션만 가질 수 있습니다. 롤백하고 싶다면 배포할 차트와 이미지를 아주 쉽게 선택하고 선택할 수 있습니다. 차트로 Helm을 실행하고 이미지에 따라 값을 설정하면 모든 설정이 완료됩니다.

무엇이든 간에 애플리케이션 버전과 인프라 버전 간에는 여전히 연결되어 있습니다. 이것이 Helm의 목적입니다. 그렇지 않다고 주장하는 것은 어리석은 일입니다.

나는 상황이 어떻게 변할 수 있는지 논쟁(이상적으로 논의)하는 것이 종종 개선으로 이어진다고 생각합니다. 나는 Helm의 "목적"이 차트와 애플리케이션 버전을 연결하는 것이라고 생각하지 않습니다. Kubernetes 매니페스트를 DRY 및 재사용 가능하게 유지하면서 Kubernetes 클러스터에 애플리케이션을 더 쉽고 안전하게 배포하는 것이 목적이라고 생각합니다. 차트와 애플리케이션 버전을 엄격하게 연결해야 하는 곳은 어디에도 없습니다.

다시, @iorlas 에게

... 해당 빌드 프로세스의 마지막에 있는 제품(예: Docker 이미지)은 Dockerfile과 여기에 넣는 항목에 따라 다릅니다. ... 이 두 가지 요소 없이는 이미지가 존재할 수 없습니다.

그래서... Helm 패키지는 차트와 앱 버전(= Docker 이미지)이 필요하며 이것이 없으면 존재할 수 없습니다.

Helm 차트는 응용 프로그램이 빌드되기 전에도 존재할 수 있습니다. 말 그대로 한 줄의 코드가 작성되기 전입니다. ... 투구 차트는 다른 것이 없이 완전히 존재할 수 있습니다. 내가 말했듯이 이것은 쓸모가 없을 것입니다.

재미있는 점은 한 프로젝트에서 우리가 프로토타입 아키텍처를 만들기 위해 스텁 도커 이미지를 사용했다는 것입니다. 우리는 말 그대로 한 줄의 코드를 작성하지 않고 차트를 사용했습니다. 또한 하위 차트로만 구성된 차트를 갖는 것은 항상 실행 가능한 경우입니다.

따라서 내 가설은 다음과 같습니다. Helm 패키지는 Docker 이미지가 없으면 거의 쓸모가 없습니다. Docker 이미지는 소스 코드가 없으면 거의 쓸모가 없습니다. 차이점은 추상화 수준입니다. 두 가지 모두 패키지류 객체 입니다.

그러나 나는 그것들이 전혀 연결되어 있지 않다는 제 요점을 설명하려고 할 뿐입니다.

그래, 그래! ppl이 모든 것을 세부적으로 논의할 준비가 되어 있다는 것은 정말 좋은 일입니다. 당신이 없으면, 예측과 주장이 없으면 우리는 미래의 맥아즙을 만들지 않을 것입니다 😃

나는 그것이 대담한 주장이라고 생각하지 않습니다. 그것은 이미 사실입니다. ... 앞서 말했듯이 이 모든 것은 다음과 같습니다. Helm 유지 관리자가 이 사용 사례를 활성화하기를 원하는지 여부 - 다른 것은 없습니다.

사실. 그러한 변화를 받아들이고 받아들이기 위해서는 다음과 같은 평가를 받아야 합니다. 옳은 일 입니까?

이야기를 해보겠습니다. Martini는 훌륭하고 널리 사용되는 웹 프레임워크였습니다. 그 이유는 투자할 시간이 부족해서가 아니라 라이센스에 관한 속임수가 아니었습니다. 따라서 미래를 더 밝게 만드는 유일한 방법은 전체 프레임워크를 사용하지 않고 일부 사람들을 화나게 하고 일부 프로젝트를 고아로 남겨두고 일부 사람들이 자신이 하는 일을 재평가하도록 하는 것입니다.

따라서 저는 이 접근 방식에 반대하지 않습니다. 나는 그것이 어떻게 살 수 있는지 봅니다( helm run 내 제안 참조). 그러나 너무 늦지 않은 동안 개입하고 전체 산업을 수정할 수 있는 기회가 있는 동안 각 사용을 평가하고 단점과 문제에 대해 논의할 것입니다.

해당 시나리오에서 Helm 차트를 작성하려면 애플리케이션이 변경될 때 다시 작성해야 합니다.

예. 지금 당장이라도 그럴 수 있습니다. push 대신 도커 이미지의 save / load 를 수행하는 파이프라인이 하나 있습니다. 그리고 그것은 아주 잘 작동합니다. 지금은 그렇게 느껴지지 않지만 근본적으로 훨씬 깨끗한 방법입니다. 문제는 K8이 "스타터" - 도커 이미지를 전송하기 위해 버스로 원격 도커 레지스트리가 여전히 필요하다는 것입니다.

초점을 좁히자 얘들아

투구 차트는 Docker 이미지를 구축하는 것과 마찬가지로 배포 중인 애플리케이션 버전에 본질적으로 연결됩니다.

이것이 바로 여기에서 중요한 차이점입니다. 그리고 @seeruk 는 그것을 못 박았습니다. 그리고 우리는 그것에 집중할 수 있습니다. 사실대로 바꾸어 보겠습니다.

1. Docker 이미지는 Helm 패키지와 바인딩되지 않습니다. 참고만 하세요.
2. 이렇게 하면 이러한 경로를 독립적으로 해제할 수 있습니다.

주요 질문:

1. 독립적인 접근의 위험은 무엇입니까? (즉, 일부 devops가 그것을 사용할 경우 우리는 그것에 대해 어떤 주장을 할 것입니까?)
2. 패키징 접근 방식으로 해결하는 방법은 무엇입니까?
3. 비용이 얼마에요?
4. 이 특정 질문에서 컨테이너화의 미래를 어떻게 보나요?

@seeruk :

다시, @iorlas 에게

당신은 훌륭한 설명과 요점을 많이 만듭니다. 개인적으로 Helm이 적응해야 한다고 생각합니다. CI/CD는 소프트웨어 구축 방식의 미래이며 솔직히 --atomic 와 같은 취급으로 helm은 이미 안정적인 배포 도구로 더욱 유연해지고 있습니다. 하지만 이 문제는 꽤 오래된 문제이므로 PR을 병합하는 것이 프로세스의 "다음 단계"가 아니라고 생각합니다.

겠습니까 플러그인을 만들라고 helm-ci-cd 이 특정을위한 실현 가능한 --app-version 기능 (@jrkarnes는 PR의 기여 등이 하나의 이야기 아마도 수)? Tiller를 내보내는 것과 관련된 커뮤니티의 요구는 해당 플러그인이 출시된 후에야 실제로 인정되었다고 생각합니다. Helm에는 쉽게 우회할 수 있는 다양한 다른 문제가 있습니다. helm-ci-cd 대한 다른 좋은 후보가 될 수 있는 install/ upgrade 이중성은 우리 CI/CD ppl이 이미 래핑을 통해 통합했습니다.

--app-version 스위치가 템플릿 파일을 볼 필요 없이 k8s 앱을 설치하려는 최종 사용자를 위한 직접적인 부가 가치가 아닐지라도(btw, 내 작업 k8s 인프라를 준수하기 위해 네트워크 정책을 추가해야 하기 때문에) 최종 사용자는 여전히 더 많은 가치를 얻고 있습니다. 왜냐하면 해당 차트를 만든 사람이 빌드를 안정적으로 만드는 helm ci/cd 기능으로 인해 차트를 작성하는 데 더 수월했기 때문입니다. 신뢰할 수 있는 소프트웨어가 더 쉬워집니다.

groovy로 Chart.yaml을 읽은 다음 앱 버전을 설정하고 배포 시간 동안 파일을 덮어씁니다. 그런 다음 투구 업그레이드를 수행하십시오. 그것이 조타 장치의 일부라면 좋겠지만 나는 그것에 의존하지 않을 것입니다.

Google'ing을 통해 찾았습니다. 사실 같은 배.

verison: 가 차트 버전이면 차트의 YAML이 변경될 때 이 버전이 변경됨을 의미합니다. 차트는 구성 가능한 값이 있는 템플릿이므로 차트의 YAML 파일을 수정하지 않고도 차트 1.3을 사용하여 여러 버전(1.2, 1.3, 1.6, 1.8 등)의 앱을 배포할 수 있다고 가정하는 것이 안전합니다.

이제 Chart.yaml 내에 하드 코딩된 appVersion: 제공됩니다. 배포된 애플리케이션의 버전을 업데이트(및 반영)하기 위해 차트 파일을 편집해야 합니다.

동일한 version: 1.3.0 차트로 다른 버전을 배포하기 위해 _application_ 버전을 참조하기 위해 차트 템플릿 내에서 사용할 수 있는 --app-version CLI 옵션이 확실히 필요합니다.

@seeruk

나는 Helm의 "목적"이 차트와 애플리케이션 버전을 연결하는 것이라고 생각하지 않습니다. Kubernetes 매니페스트를 DRY 및 재사용 가능하게 유지하면서 Kubernetes 클러스터에 애플리케이션을 더 쉽고 안전하게 배포하는 것이 목적이라고 생각합니다.

이것이 우리의 논점이며 나는 우리 중 어느 쪽도 상대방을 설득하지 못할 것이라고 생각합니다. 때때로 전문적인 환경에서는 의견 문제에 있어서 화해할 수 없는 차이를 갖는 것이 _괜찮습니다_. 나는 확실히 Stallman이 말하는 모든 것에 동의하지 않으며 우리가 그와 내가 동의하지 않는 모든 것에 대해 참호에 빠지면 합의에 도달하기 전에 죽을 것입니다.

나는 토론에서 그것을 더 말했고 그것이 반복되어야 한다고 생각합니다.

[...] 나는 그 helm이 진정으로 패키지를 배포할 수 있다고 생각합니다. 당신이 말할 수 있는 유일한 의미론적 올바른 것 같습니다. 그러나 이러한 패키지가 배포되는 방식에 대한 논쟁이 실제로 이러한 논쟁의 근본 원인인 것 같습니다. 특히 "앱 버전을 업그레이드하거나 변경하면 새 패키지가 구성됩니까?"

구성이 없는 자사 helm 차트(MySQL을 사용하는 것을 좋아하므로 계속 사용할 것입니다) 는 차트 작성자가 설명하고 의도한 대로 클러스터에 리소스를 설치해야 mysql에 대한 실제 차트를 보면 실제 mysql 엔진과 관련하여 구성할 수 있는 두 가지 속성이 있습니다.

• image (기본 mysql )
• imageTag (기본 5.7.14 )

그런 다음 Chart.yaml 파일에서:

apiVersion: v1
name: mysql
version: 1.4.0
appVersion: 5.7.27

appVersion 와 기본 imageTag 는 일치하지 않습니다 . helm list 실행하면 "앱 버전"(읽기, 엔진 버전)이 _클러스터에 설치된 실제 앱 버전을 반영하지 않는 상태라는 보고서를 받게 됩니다.

차트와 애플리케이션 버전을 엄격하게 연결해야 하는 곳은 어디에도 없습니다.

이것은 정확합니다. 제 생각에는 디자인 결함입니다.

다시, @iorlas 에게

예. 잠시 후 몇 가지 제안을 드리겠습니다.

@IRobL

이 특정 --app -version 기능에 대해 helm-ci-cd와 같은 플러그인을 만드는 것이 가능할까요?

다음과 같이 자신의 질문에 답합니다.

--app-version 스위치가 템플릿 파일을 볼 필요 없이 k8s 앱을 설치하려는 최종 사용자를 위한 직접적인 부가 가치가 아니더라도 최종 사용자는 여전히 더 많은 가치를 얻고 있습니다. 안정적이고 신뢰할 수 있는 소프트웨어를 더 쉽게 구축할 수 있도록 하는 helm ci/cd 기능으로 인해 차트를 구축하는 것이 더 쉬웠습니다.

기능을 올바르게 하기 위해 플러그인으로 수행해야 하는 경우 해당 접근 방식을 지지합니다. 그러나 나는 그것이 잘못된 문제를 해결하고 있다고 생각합니다. 앞서 @seeruk 에게 appVersion 변경할 수 없는 Chart.yaml 파일의 고유 속성으로 두는 것은 설계상의 결함이라고 생각합니다. appVersion 의 속성 인 image 차트를 통해 클러스터에 설치되고, 그것은 그와 함께 참조 영상에서 어떤 방식으로 유도된다 tag .

helm-ci 플러그인에 대해 생각할 때 어떤 다른 기능이나 추가 기능이 있을 것으로 예상하십니까? 변경 불가능한 Chart.yaml 속성에서 appVersion 를 토글하는 것만으로는 플러그인이 될 가치가 충분하다고 생각하지 않습니다.

@IRobL 과 @seeruk 함께:

나는 우리의 다른 의견이 helm의 더 일반적인 최종 사용자를 누구라고 보는가에서 비롯된 것이라고 생각합니다. 최종 사용자가 많은 구성을 하지 않거나 템플릿을 파고 들지 않는 사람이어야 하는 경우 helm ls 는 특히 유용하지 않을 수 있으며 요점은 무의미합니다.

그러나 ... 클러스터를 관리하기 위해 관리 도구 및 도우미로 helm을 사용하거나 더 많은 CI/CD 컨텍스트에서 Helm을 사용하는 경우 --appVersion 스위치가 훨씬 더 많이 사용됩니다. 더 유용 하므로 관심 사항(및 구성),

완벽한 세상에서 appVersion 는 파생 속성이어야 하고 도커 이미지 메타데이터에서 가져와야 한다고 주장합니다. 이것은 조타가 할 수 있는 것이 아닙니다. 즉, 경합의 부족입니다.

내가 말한 것에 대해

예. 잠시 후에 몇 가지 제안을 드리겠습니다...
... helm-ci 플러그인에 대해 생각할 때 어떤 다른 기능이나 추가 기능이 있을 것으로 예상하십니까?

좋은 출발점이 될 수 있는 개인 목록이 있습니다.

• CICD 모드에서 helm 를 실행하면 이전에 릴리스된 패키지의 상태를 현재 적용 중인 패키지와 _만_만_ 비교하지 않습니다. . 대신 릴리스의 모든 배포는 upgrade 가 실행될 때 템플릿화된 모든 매니페스트를 완전히 적용합니다.
• helm-cicd 는 기본 Kubernetes 명령을 래핑해야 합니다. helm describe 또는 helm logs 를 실행하려고 시도한 횟수를 셀 수 없습니다.
• helm-cicd 를 사용하면 다른 사용자가 실행할 때 명령의 결과가 무엇인지 볼 수 있습니다. RBAC를 사용하는 경우 인증되지 않은 사용자가 무언가를 시도하면 어떻게 되는지 알고 싶습니다.
• helm-cicd 는 나중에 편집할 수 있도록 네임스페이스를 매니페스트 컬렉션으로 분해할 수 있어야 합니다.
• helm-cicd 는 릴리스를 네임스페이스로 _이식_할 수 있어야 합니다.

그것들은 큰 것입니다... 그러나 본격적인 helm-ci 플러그인에 대해 논의하는 것은 (현재) 이 PR/이슈의 범위를 벗어납니다.

나는 당신이 입력하는 모든 것을 읽고 나는 그 연설에 감사합니다. 나는 당신의 응답을 기대합니다.

지금은 제 시간에 꽤 바쁘지만 몇 가지 사항을 수정하고 싶습니다. @jrkarnes

appVersion을 변경할 수 없는 Chart.yaml 파일의 고유 속성으로 설정하는 것은 디자인 결함이라고 생각합니다.

그렇지 않다. 무언가가 이렇게 만들어지고 다른 것이 아닌 경우에는 항상 이유가 있습니다. 이 경우 내가 주장하는 이념은 하나의 패키지 = 하나의 빌드, 차트 = 빌드용 템플릿, 패키지 = 앱 + 인프라입니다.

Helm은 K8을 OS로 취급하고 패키지를 앱의 설치 프로그램/업데이터로 취급하기 위해 이 이데올로기를 중심으로 설계되었습니다. 몇 가지 문제가 있고 때로는 너무 많은 것처럼 느껴지지만 확실히 미래입니다.

_왜 그렇게 디자인 된 것 같아요? 동일한 helm list 가 설치된 현재 패키지 버전을 표시하도록 설정됩니다._

좋습니다. 새 릴리스가 나타날 때마다 패키지를 생성하도록 빌드되지 않은 많은 차트(mysql과 같은 공개 및 로컬)가 있습니다. 높은 수준의 솔루션으로 마이그레이션하려면 시간이 필요하기 때문에 이러한 요구 사항을 높이 평가합니다. 또한 누군가는 패키지를 빌드해야 하며 mysql 유지 관리자가 각 빌드에 대해 Helm 패키지를 생성하도록 설득하기 어려울 것입니다.

MySQL 차트에는 추가 문제가 있습니다. 맞습니다. helm list 설치된 MySQL 버전을 보는 것이 더 나을 것입니다. 그러나 이미지 태그도 있기 때문에 버전의 일부일 뿐입니다. 이 태그는 아마도 여기에 있는 버전의 일부일 것입니다.

다시, @iorlas 에게
예. 잠시 후 몇 가지 제안을 드리겠습니다.

이번에도 helm run 를 추가하자는 제안이 있었습니다. 이것이 여러분 모두가 찾고 있는 것입니다. Is는 Chart를 즉시 패키지로 사용하여 앱 버전 및 모든 것을 제공할 수 있도록 하기 위한 것입니다.

완벽한 세상에서 나는 appVersion이 파생 속성이어야 하고 도커 이미지 메타데이터에서 가져와야 한다고 주장합니다. 이것은 조타가 할 수 있는 것이 아닙니다. 즉, 경합의 부족입니다.

도커 이미지를 최종 제품으로, 마지막 패키지로 보고 있으며, 이는 마지막 소스입니다. 그렇지 않다. Docker 이미지 외에는 아무 것도 없으면 소프트웨어라고 믿도록 속일 수 있습니다. 코드에 모듈을 작성할 때 이 모듈이 소프트웨어라고 믿게 됩니다.

문제는 그렇지 않다는 것입니다. 그것은 단지 일부, 인공물입니다. 작은 제품에서 큰 제품에 이르기까지 많은 인공물이 함께 묶여 있습니다. 때로는 빌드 프로세스 내에서 도커 파일의 버전을 전달하고 때로는 여러 아티팩트를 함께 묶는 ConfigMap을 갖게 됩니다. 그리고 당신은 모든 것을 가질 하나의 도커 파일을 갖지 않을 것입니다.

좋은 출발점이 될 수 있는 개인 목록이 있습니다.

나는 당신이 많은 제안을 가지고 있다고 생각하지만, 오히려 야생 플러그인보다는 Helm 포크 가 더 생생하게 느껴집니다. CD의 CI와는 전혀 관련이 없다고 말씀드리고 싶습니다. 나는 그러한 포크/플러그인을 구축하지 말라고 주장하고, 적절한 솔루션을 논의하고 제안합니다. 현재 커뮤니티가 그다지 크지 않다는 점을 고려하면 아무도 3개의 Helm 포크가 필요하지 않습니다.

주목해주세요!

좋아요, 우리는 여기저기서 많은 생각을 합니다. 가장 좋은 시나리오는 다음과 같습니다.

• 먼저 패키지를 생성할 필요 없이 앱 버전을 변경하는 기능
• helm ls 에서 적절한 앱 버전을 볼 수 있는 기능
• 모든 API(예: Helm 연산자)가 중간 상태 없이 앱 버전을 지정/업그레이드하도록 허용

두 가지 접근 방식이 제공됩니다.

1. helm install 는 패키지를 설치하기 위해 생성됩니다. Chart 설치도 지원하지만 제한적입니다. helm install 단순화하고 패키지를 설치하는 목적에 따라 두도록 합시다. 두 번째로 helm run 추가해 보겠습니다. 이 의도는 간소화된 흐름을 제공하는 것입니다. Combine helm package 및 helm run , 두 명령 인수를 모두 제공하지만 이러한 경우 의미가 없는 것은 걸러냅니다. .
2. app-version 를 helm install cmd에 추가합니다. 이 API를 부풀려 패키지 사용에 대한 아이디어를 숨길 것입니다. 패키지를 설치 프로그램으로 사용하는 이데올로기를 숨길 것입니다(지금처럼).

이 두 가지 접근 방식이 지금 우리가 겪고 있는 모든 어려움을 해결할 것이라는 데 동의할 수 있습니까?

플러그인은 핵심 개발자가 지원하기를 원하지 않거나 지원할 시간이 없는 누락된 기능에 대한 해결 방법이므로 플러그인인지 상관하지 않습니다.

Helm은 K8을 OS로 취급하고 패키지를 앱의 설치 프로그램/업데이터로 취급하기 위해 이 이데올로기를 중심으로 설계되었습니다.

오오. 알겠어. helm 차트[패키지]는 Kubernetes의 [말 그대로] "rpm"을 의미합니다. 내가 받은 인상이 전혀 아닙니다. helm은 차트를 사용하여 앱을 배포합니다. 차트/패키지는 "k8s용으로 포맷된" 앱입니다.

나는 괜찮습니다. 의미가 있습니다. 이제 새 컨테이너를 빌드할 때 appVersion을 올리기 위해 빌드 서버를 업데이트해야 합니다.

• 빌드 컨테이너 - "v1.2" 태그
• Chart.yaml 업데이트 - appVersion: "v1.2" --- helm package --app-version 명령도 이미 있습니다.
• 패키지 차트: helm package --app-version v1.2 => 패키지[chart]-v1.2.tgz(예: "패키지[chart]-v1.2.rpm")
• 배포 서버를 사용하여 패키지 배포, helm install package[chart]-v1.2(예: apt install [email protected])

자, 내가 이것에 대해 잘못 이해하고 있습니까? package-v1.2가 v1.2 appVersion이 아닌 경우 그 이유는 무엇입니까? 그런 의도가 아니었을까? 예를 들어 rpm은 패키지(차트)가 아니라 앱의 버전입니다.

편집하다:

package-v1.2가 v1.2 appVersion이 아닌 경우 그 이유는 무엇입니까? 그런 의도가 아니었을까?

이제 사람들이 Chart.version과 Chart.appVersion이 조화를 이루는 것에 대해 논평하는 이유를 알았습니다. 인수는 여기에서 양방향으로 갈 수 있습니다... 안정적인 "차트" 빌드가 있는 앱의 경우 package-v1.2가 버전 번호를 변경할 것으로 예상할 수 있습니다. 그러나 yaml 파일이 변경될 때 package-v1.2가 차트 버전 번호가 될 것이라고 주장할 수도 있습니다.

증가하는 앱 버전(1.6)과 차별화된 안정적인 차트 버전(1.2)을 어떻게 관리합니까? package-[version] 가 1.2가 될까요? 또는 1.6? Chart 버전 1.2를 배포했지만 패키징 시 appVersion이 변경되었다고 가정해 보겠습니다. helm package --app-version 1.6 ?

➜  chart git:(master) ✗ helm package --app-version 1.5 nginx
Successfully packaged chart and saved it to: /Users/Documents/source/docker/nginx/chart/nginx-0.1.0.tgz

:(

.... 너무 혼란스럽습니다.

helm 차트[패키지]는 Kubernetes의 [말 그대로] "rpm"을 의미합니다.

정확히! 하지만 때로 너무 엄격하거나 너무 번거롭게 느껴질 때가 있는데 바로 이 지점이 바로 지름길입니다.

자, 내가 이것에 대해 잘못 이해하고 있습니까? package-v1.2가 v1.2 appVersion이 아닌 경우 그 이유는 무엇입니까? 그런 의도가 아니었을까? 예를 들어 rpm은 패키지(차트)가 아니라 앱의 버전입니다.

이것은 다른 논의의 문제이지만 현재 패키지의 이름은 앱 버전이 아닌 차트 버전으로 지정됩니다. 이유는 모르겠고, 반대가 되어야 한다고 생각합니다. 제 생각에는 역사적인 문제이지만 제 생각에는 귀하와 마찬가지로 package-{app-version}.tgz 이어야 합니다.

이전 메시지에 따르면 버전에는 4가지 구성 요소가 있습니다.

• 차트
• 앱
• 패키지
• 풀어 주다

이 모든 것을 독립적으로 버전화하는 것은 골치 아픈 일이지만 현재 작동하는 방식입니다. 한 가지 예외: 패키지는 차트 버전 이후에 버전이 지정됩니다.

앱 패키징의 이데올로기를 선택한다면 동일한 프로세스가 앱, 이미지 및 패키지를 모두 생성하기 때문에 앱 버전이 완전히 의미가 있습니다. 따라서 전달 단계에 들어갈 때 파일이 어떻게 호출되는지, 어떤 파일을 설치할지 명확할 것입니다. 지금 우리는 파이프라인에서 패키지 이름을 하드코딩해야 합니다 >_<

@iorlas

도커 이미지를 최종 제품으로, 마지막 패키지로 보고 있으며, 이는 마지막 소스입니다. 그렇지 않다. Docker 이미지 외에는 아무 것도 없으면 소프트웨어라고 믿도록 속일 수 있습니다. 코드에 모듈을 작성할 때 이 모듈이 소프트웨어라고 믿게 됩니다.

나는 이 진술에 대해 생각하는 데 몇 주가 걸렸고 나는 당신과 100% 동의합니다. 또한, 나는 이제 우리의 의견 차이가 어디에서 비롯되는지 이해합니다 ...

저는 일련의 작업을 매우 잘 수행하는 작은 구성 요소로 시스템을 구축해야 한다는 개발 및 배포 철학을 따릅니다(UNIX 생각). 그러나 현대 시스템은 "응용 프로그램"을 이러한 작은 도구의 그룹으로 취급할 수 있습니다. 애플리케이션이 도커 아티팩트뿐만 아니라 다른 하위 구성요소(도커 아티팩트일 수도 있음)에 종속되는 경우 애플리케이션의 "버전"을 어떻게 표시해야 합니까? 이러한 유형의 커플링을 던지기 시작하면 그렇게 간단한 대답이 아닙니다.

이 질문에 답하는 것은 이 문제/요청의 범위를 훨씬 벗어납니다 . 문제의 근본으로 돌아가려면 install 와 run 구별하고 싶습니다. 의미론에 따라 install 는 패키지에서만 작동해야 하고 run 는 템플릿을 생성하고 _상태를 유지하지 않고 적용하는 프로세스를 "실행"해야 합니다.

많은 시간에 helm template 를 사용하여 장래 차트가 어떻게 전개될지 확인해야 하지만, vi-ca-vi run 가 발생하는 것을 관찰하는 데는 많은 사용이 있습니다. 개발 파이프라인에서 스타가 되는 이중 목적(속도가 매우 높으면 가치가 없기 때문에 패키지를 유지하고 싶지 않은 경우).

MySQL 차트에는 추가 문제가 있습니다. 맞습니다. helm 목록에 설치된 MySQL 버전을 보는 것이 더 나을 것입니다. 그러나 이미지 태그도 있기 때문에 버전의 일부일 뿐입니다. 이 태그는 아마도 여기에 있는 버전의 일부일 것입니다.

내가 말했듯이 완벽한 우주에서는 설치된 객체의 버전이 내성적입니다. 그러나 이것은 나에게 아이디어를 제공합니다.

차트 배포 방법에 대해 초기에 말한 것을 염두에 둔다면 helm describe 플래그로 모든 하위 구성 요소를 펼칠 수 있다면 어떨까요? 즉, 앱 버전을 지정할 필요가 해결되지 않지만, 더 (플래그와 앱 버전을 조정하고자하는 원동력의 일부입니다) 설치 정확히 명확하게 않습니다.

나는 모든 의견을 읽었으며 문제에 대한 완전한 의견이 없습니다.

우리 회사가 개인 Helm 리포지토리를 유지 관리하고 차트의 90%가 주로 하나의 컨테이너 사양이 있는 하나의 배포이기 때문에 여기에 왔습니다. 이러한 경우 appVersion 를 사용하여 이미지의 태그를 나열할 수 있다면 변수 중복을 피할 수 있고 helm version 실행하는 이 버전을 볼 수 있습니다.

이 스레드를 읽고 나면 이것이 편리할 것 같지만 병합되면 사용할 수 있는 정말 좋은 것입니다.

요청에 따라 다른 사람들이 볼 수 있도록 이전 스레드의 마지막 답변을 포함하겠습니다.

흠. 여기서 appVersion 를 Docker 태그(논리적 연결)에 묶기 시작할 때 상황이 서로 모순되기 시작합니다. 여기서 문제가 발생합니다. 즉, 위에서 언급한 개발 시나리오입니다. version 는 SemVer여야 하므로 Docker 태그를 Chart version 로 사용할 수 없습니다.

appVersion 가 차트에 명확하지 않은 경우 개발자에게 시각적 버전 차이를 만드는 방법은 무엇입니까?

k8s가 응용 프로그램과 함께 작동하는 방식 때문에: dev 세계에서는 보드 전체에 태그 버전을 허용하는 몇 가지 방법이 있습니다.

SemVer가 ~ 또는 ^ 연산자 측면에서 할 수 있는 것과 같은 작업을 수행할 수 없습니다. 버전이 의미 체계 없이 순전히 정렬되었기 때문입니다.

왜 안 돼? 우리는 항상 이것을 php composer 합니다. SemVer를 사용하거나 버전 스키마에서 단순히 구문 분석되거나 무시되는 문자열 버전을 사용할 수 있습니다. 예를 들어 version 가 SemVer 번호가 아니면 ~ 및 ^ 포함하지 마십시오.

#7299 에 대한 내 의견을 인용

.deb 및 .rpm 패키지의 경우 버전 문자열이 특정 방식(하이픈으로)으로 분할되지만 "이것은 API와 호환됩니다"와 같은 의미론적 의미가 없으므로 "Give 최신 API 호환 버전" 또는 "변경되지 않은 API가 포함된 최신 버전 제공"과 같이 SemVer에서 할 수 있습니다.

Debian과 RedHat 모두 일반적으로 soversion 번호를 기반으로 이러한 사용 사례(및 ABI 호환성)를 달성하기 위해 패키지 별칭을 사용했던 것을 기억합니다. 이것은 패키지 이름과 주문 전용 비교만을 사용하여 합리적으로 일관된 동작을 허용했습니다.

일반적인 주제에서 우리 제품에 Helm 차트를 사용하는 방법은 다양한 서비스를 패키징하는 것입니다. 그러나 Docker 이미지는 단순한 아티팩트이며 해당 이름은 API를 제공하기 때문에 SemVer를 채택한 서비스 버전에 따라 결정됩니다.

우리의 CI 파이프라인은 코드 및 관련 스크립트의 git repos를 변환하고 설치할 수 있고 Docker 이미지를 참조할 수 있는 Helm 차트를 생성합니다. Docker 이미지의 태그는 사용자에게 흥미롭지 않습니다. 그런 다음 원본 git SHA로 태그를 지정한 다음 릴리스에 사용된 이미지에 태그를 다시 지정합니다. 태그 다시 지정의 주요 이점은 태그를 해제할 수 없다는 것을 알고 있지만 짧은 기간 후에 git-SHA 버전의 태그를 해제할 수 있다는 것입니다.

version 에는 우리 소프트웨어의 정확한 버전이 포함되어 있고 appVersion 에는 동일한 내용이 있지만 문자열로 포함되어 있고 아무도 보지 않기 때문에 Helm이 작동하는 방식에 매우 만족합니다. Docker 리포지토리에서

https://github.com/helm/charts/ 에서 차트의 버전이 지정되는 방식에 약간 만족하지 않습니다. 소프트웨어가 아닌 차트의 버전이 지정되어 가끔 마이너(안정적인) 차트 version 가 생성되기 때문입니다. version 를 차트에 포함된 항목의 버전과 분리할 때 이것이 가능하고 피하기 어려운 결과라고 생각합니다.

내부 "외부에서 사용되는 라이브러리 및 아티팩트" 페이지의 안정적인/프로메테우스 운영자 차트와 유사한 문제가 있습니다. 여기에는 다양한 소프트웨어 조각이 포함되어 있으므로 "현재 사용 중인 버전은 무엇입니까?" 특히 "업그레이드하는 것이 안전한가요?" 우리와 같은 방식으로 버전을 제공하는 Agones보다 답변하기가 훨씬 더 어렵습니다.

@jrkarnes

차트 배포 방법에 대해 초기에 말한 내용을 염두에 둔다면 조타 장치에 플래그가 설명되어 있는 모든 하위 구성 요소를 펼칠 수 있는 능력이 있다면 어떨까요? 앱 버전을 지정해야 할 필요성이 해결되지는 않지만 설치된 항목이 더 명확해집니다(플래그로 앱 버전을 조정하려는 원동력의 일부임).

정말 보고 싶습니다. 예를 들어 #6932에 관련 기능 요청이 있습니다.

토론을 뒤로 넘기면 appVersion 가 Docker 이미지 메타데이터와 관련이 있다는 생각은 적어도 일부 차트(사용자가 주로 다루는 차트)가 하는 것처럼 우리의 사용 사례에 적합하지 않습니다. Docker 이미지를 포함하지 않으며 대부분 공유 리소스(예: JWT 공개 키, values.yaml )와 다른 차트를 가져오기 위한 requirements.yaml 용 호스트입니다.

appVersion이 Docker 이미지 메타데이터와 관련되어 있다는 생각은 적어도 일부 차트와 같이 우리의 사용 사례에 확실히 맞지 않습니다.

나는 그것이 _의도된 용도라고 말하는 것이 아닙니다. 나는 단지 그것이 논리적 연관성이라고 말했다. 여전히 appVersion 를 내부 yaml의 "논리적 컨테이너"로 사용하고 있습니다.

SemVer에 version 를 잠그는 것이 어떤 이점이 있는지 아직 모르겠습니다. helm이 version (및 appVersion )를 구문 분석하고 거기에서 진행할 수 있습니까?

내 요점은 우리가 사용하지 않을이었다고 생각한다 appVersion 가 우리의 Chart.yaml에 일반적으로 존재하지의 모든에서하고있을 때, 그것은 동일의 version .

version 를 SemVer에 고정하면 다양한 SemVer 연산자를 사용할 수 있고 안정적으로 구문 분석하여 설치를 통해 정렬 및 일치를 생성할 수 있습니다.

RPM 및 DEB 패키징 시스템은 버전 관리 시스템이 다른 구문을 사용한다는 점을 제외하면 동일한 것이지만 의미론적 구문 분석을 위해 여전히 제한된 구문입니다. 그들은 또한 그들이 관심을 갖는 다른 의미를 가지고 있습니다.

helm/charts 리포지토리가 실행된 방식을 감안할 때 DEB 또는 RPM 스타일 버전이 있는 단일 version 필드가 SemVer에 appVersion 문자열을 더한 것보다 더 나은 선택이었을 것 같습니다. 그러나 그것은 완전히 다른 이미 항해한 배입니다. 어린 시절에 업스트림 공급업체이자 데비안 패키지 제작자였기 때문에 "여기서 어떤 버전 번호를 수정해야 하나요?" 우리의 " version is one truth" 패키지에서.

"때때로 SemVer입니다"의 문제는 SemVer가 파서가 손으로 작성하거나 다른 곳에서 접할 수 있는 것과 매우 흡사 하다는 것입니다. .

안녕. 이 기능에 대한 뉴스가 없습니다.

모든 댓글을 읽은 후, 나는 그것이 정말 도움이 될 것이라는 것을 알 수 있습니다.

실제로 우리 회사에는 동일한 기술을 사용하고 동일한 방식으로 배포된 여러 응용 프로그램이 있으므로 중복을 피하기 위해 서로 다른 응용 프로그램에 대한 하나의 차트가 있습니다.
인프라, 구조적 변화가 있을 때만 새로운 차트를 패키징합니다.
그리고 특정 값을 태그, 환경 변수로 적용하는 릴리스를 업그레이드하거나 설치할 때만 ...

우리는 패키지된 helm 차트가 한 종류의 애플리케이션에 대해 예상되는 kubernetes 리소스 및 구조를 나타내는 추상화 계층이라고 생각하며 배포 중에만 "이런 종류의 애플리케이션이 이러한 특정 값을 사용하여 해당 환경에 배포되기를 원합니다"라고 말합니다.

helm 목록에는 릴리스 정보가 표시되어야 하므로 이 릴리스에 배포된 앱 버전을 볼 수 있어야 합니다.

비슷한 문제 https://github.com/helm/helm/issues/7517에 댓글을 남겼습니다.
values.yaml 에서 이것을 재정의하는 기능을 추가할 수 있습니까?
그런 다음 무료 --set 명령줄 옵션을 얻습니다.

우리가 어떤 응용 프로그램에 대해 helm을 사용하려고 하면 이것은 절대적으로 짜증납니다. 아무도 프로덕션 애플리케이션에 시맨틱 버전 관리를 사용하지 않습니다.

나는 동의한다. 현재 변경할 수 없는 _application_ 기반 차트에 대해 차트 박물관을 사용하는 것이 차단되었습니다. 차트 버전 != 앱 버전이므로 차트 뮤지엄을 통해 출시할 수 없습니다.

나는 위의 논의(전부가 아님)를 다 읽었으므로 일부 요점/관점을 반복하고 있다면 죄송합니다. 보다 신중한 답변을 드리기 위해 노력하고 있습니다.

나는 helm ls 할 때 appVersion을 보는 것을 좋아하고 개념적으로 .Values.image.tag 에서 이동하는 것은 좋은 일이지만 배포 시간에 설정할 수 없다는 것은 진정한 쇼 스토퍼이며 내가 가진 것입니다. 되돌리기 위해.

(차트) version 는 차트 버전이고 appVersion 는 도커 태그입니다. CI 프로세스에서 docker 태그는 git 태그이기도 합니다.
우리는 또한 여러 개의 마이크로서비스를 보유하고 있으며 가능한 한 DRY한 상태로 유지하고자 합니다. 대부분의 java-springboot 앱이 동일하기 때문에 로컬 차트 리포지토리에 일반 차트가 있습니다. 대부분의 tomcat 앱은 동일합니다(그러나 springboot 앱과 다릅니다). 다른 기술에 대해 헹구고 반복합니다. 다양한 환경을 통해 배포가 진행됨에 따라 환경적 가치가 있습니다.
그런 다음 이러한 각 마이크로 서비스는 CI/CD를 통해 일반 차트를 사용합니다.
예: helm upgrade release-name private-repo/generic-chart --values <environment>.yaml --set image.tag=<docker tag from build step> --namespace <environment> --install .Values.image.tag 보다 .Chart.AppVersion 를 사용하는 것을 선호하지만 조직에 효율적인 방식으로 배포할 수 있어야 합니다.

helm ls 를 하면 CHART 와 APP VERSION 있으므로 전체 차트 버전이 앱 버전과 일치해야 합니다. 그 길을 계속 가면 사람들이 소외될 뿐 아니라 사고 방식이 너무 엄격하고 많은 사람들이 추구하는 바가 아니기 때문에 어느 시점에서 프로젝트가 분기될 것입니다. 또한 " image.* , nameOverride & fullnameOverride . image.*는 deployment.yaml 등에서 하드 코딩될 수 있습니다." 매우 비슷한 이유로.

마지막 요점은 많은 공개 차트가 사용하는 도커 컨테이너 버전과 정확히 일치하지 않는다는 것입니다. 주 버전과 부 버전이 롤링되지 않는 패치 버전만 있는 롤링 태그인 알파인 또는 nginx와 같이 가장 잘 알려진 도커 컨테이너를 살펴보십시오. 모든 패치 버전에 대해 1:1 매핑을 사용하면 이점이 거의 또는 전혀 없이 상당한 오버헤드가 발생합니다.
프로덕션 환경에서 여러 가지 이유로 최신 버전으로 업그레이드할 수 없는 경우는 드문 일이 아닙니다. 프로덕션에서 롤링 버전에 대해 대부분의 장소에 말하지 마십시오.

위의 모든 결과는 "왜 helm이 차트 저장소를 사용할 수 있습니까?"라는 질문을 제기합니다.
설치/업그레이드 시 appVersion 를 덮어쓸 수 없다는 것은 이미 차트를 다운로드하고 압축을 풀거나 설치/업그레이드당 appVersion 편집해야 하거나 필요한 도커 컨테이너를 도표.
완전한 표준 설치가 이루어지는 경우는 예외이며 자동 생성 암호 등을 둘러싸고 이미 많은 논쟁이 있습니다.
나는 마지막 단락이 내가 토끼굴로 내려가 구석에 몰두하고 있는 것처럼 보였지만 "appVersion이 도커 태그이고 명령줄이나 값을 통해 appVersion을 설정할 수 없다"는 것이 우리를 데려갑니다.

@timothyclarke : 여기에 설명된 helm upgrade 사용 사례의 경우 helm package 먼저 --version 및 --app-version 을 설정할 수 있습니다 helm install 할 수 있으며 --set 매개변수를 추가할 필요가 없기 때문에 설치 재현성을 높이는 CI 아티팩트로 주변에 보관할 수 있습니다. 이것이 바로 우리가 이동한 것입니다. "일반 차트" 측면은 없지만 차트가 일반적이지 않기 때문입니다.

+g<shortCommitSHA> 와 같이 Version 에 빌드 메타데이터를 추가할 수 있는 좋은 기회이기도 합니다.

#7517에 따라 CI 테스트 클러스터에 설치하기 전에 image.tag를 다시 작성하고 나중에 패키징할 때 다시 작성하던 많은 sed 호출을 제거할 수 있습니다.

이 접근 방식은 실제로 대부분의 사람들이 자신의 차트를 작성하는 경우, 특히 체크아웃의 차트 소스에서 설치하는 경우 여기에서 겪을 수 있는 문제를 해결할 수 있습니다. 리포지토리에서 가져온 차트에 이 기능이 필요한 경우에는 실제로 도움이 되지 않지만, 여기 있는 대부분의 사람들이 치는 것과는 다른 문제라고 생각합니다.

나에게 설치 시 앱 버전(또는 버전)을 재정의하는 위험은 차트를 다시 만들려는 다른 사람에게 명확하게 보이지 않아 완료되었다는 것입니다. 값 지원에 어떻게든 해킹되지 않는 한 helm get values -o yaml 사용하여 차트의 현재 구성을 추출할 때 거기에 없을 것이므로 라이브 차트 배포를 사용자가 얻는 것과 다르게 만드는 _하나 더_가 됩니다. helm install <some way to specify a particular package> --values <values from helm get values> , 예를 들어 테스트 설정에서 프로덕션에서 본 문제를 재현하려고 할 때.

나에게 설치 시 앱 버전(또는 버전)을 재정의하는 위험은 차트를 다시 만들려는 다른 사람에게 명확하게 보이지 않아 완료되었다는 것입니다. 값 지원에 어떻게든 해킹되지 않는 한 helm get values -o yaml 사용하여 차트의 현재 구성을 추출할 때 존재하지 않습니다.

머리에 못을 박았습니다. 이것은 첫날부터 values.yml 에 있어야 합니다.

이 기능에 대한 철학적 주장을 이해하지만 현장 실습을 통해 우리를 포함한 사람들에게 많은 도움이 될 것임을 보여줍니다.

values.yml 통해 앱 버전을 설정할 수 있는 많은 차트가 있습니다. 특히 여기서 설정할 수 없기 때문입니다.

그것이 논의되었는지 확실하지 않지만(빠른 CTRL+F를 수행했지만 흔적을 찾을 수 없음), 대체 솔루션으로 appVersion 모두 함께 제거하는 것은 어떻습니까? 제 생각에는 전체 혼란을 피할 수 있을 것 같습니다.

현재 appVersion 는 일종의 "특수" 값으로 취급됩니다. 예를 들어 Prometheus의 차트 버전 123.5.6을 가질 수 있지만 appVersion: 2.17.1이 있을 것이므로 가시성을 제공하기 위해 있다고 가정합니다. helm ls 사용하여 찾을 수 있습니다.

다른 방식으로 제공될 수 있을 것 같습니다. 출시 레이블을 통해? 아니면 jsonPath 쿼리 수있는 것과 유사한 모든 자료, 이상 kubectl 예 :

kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'

그런 다음 helm 자체에 의해 시행되는 대신 모범 사례로 지원이 전환됩니다. 그것은 또한 보풀 일 수 있습니다.

반면에 많은 사람들이 appVersion 의 기존 구현에 의존하고 있다는 점도 고려해야 합니다.

한 걸음 물러서서 정확히 appVersion 가 추가된 이유를 이해하면 이 문제를 해결하는 데 도움이 될까요?

@bokysan 그것은 이전에 있었다 values.yaml 그것은 이동했다 Chart.yaml I 전체에 대한 추측하고있어 helm ls 오히려 명령 등을 실행하는 것보다 차트와 고정 표시기 태그를 모두 보여주는 ~처럼
kubectl get deployment <release name> -o jsonpath='{.spec.template.spec.containers[0].image}'

@TBBle 귀하의 각 요점에 대해

initContainers 및 사이드카 사용을 시작해야 하는 즉시 appVersion의 전제가 완전히 무너집니다. 실제 사례를 제공하기 위해 현재 관리해야 하는 프로젝트 중 하나에 PHP 사이드카가 있는 nginx가 있습니다. nginx 및 php 태그는 자주 변경되지 않습니다. PHP 컨테이너/버전은 코드를 작성하는 개발자에게 매우 중요합니다. 가장 자주 변경되는 컨테이너는 콘텐츠를 제공하는 initContainer 입니다.
appVersion 를 initContainer , php 컨테이너로 설정합니까 아니면 nginx 로 설정하고 이 중 하나만 선택하여 손실된 정보는 무엇입니까?

사용자에게 중요하다면 PHP 버전이어야 하지 않을까요? 그것이 당신이 광고하는 것입니다. appVersion에 세 가지를 모두 넣을 수도 있습니다. 결국 자유 텍스트 필드입니다.

appVersion == 컨테이너 이미지 태그를 강제 적용하려는 경우 중요하지 않은 차트(예: 둘 이상의 컨테이너가 있거나 컨테이너가 없는 차트)에서 이것이 어렵다는 것을 알게 될 것입니다. 그것이 요점은 아니지만 imageVersion 가 될 것입니다. 단일 업스트림 앱을 패키징하는 경우 해당 버전을 사용하십시오. 여러 업스트림 앱의 패키지를 구축하는 경우 prometheus-operator's 차트와 같은 하나를 선택하거나 선택적 필드이므로 appVersion을 무시하십시오.

차트 소스가 애플리케이션의 _일부_인 경우(예: Agones) appVersion 비워두거나 의존하는 도구가 있는 경우 version 에서 복사하십시오.

이 중 어떤 것도 helm install -시간 결정일 필요는 없습니다. 앞서 언급했듯이 helm package 는 "설치 시 타사 차트에 대해 다른 업스트림 버전으로 전환"을 제외하고 모든 워크플로에 대해 충분히 늦고 --values 또는 --set 있어야 합니다 --set 입니다.

솔직히 말해서, 실제 누락된 기능은 아마도 " appVersion through tpl "일 것이므로 .Values.image.tag 또는 귀하에게 적합한 무엇이든 읽을 수 있습니다.

appVersion == 컨테이너 이미지 태그를 강제 실행하려는 경우

그런 다음 우리는 아마도 https://github.com/helm/helm/issues/7517에 있을 것입니다. 이 모든 것이 어디에서 비롯된 것일 수 있습니다.

나는 이 논의가 전혀 이해가 되지 않는다. 사람들에게 가장 적합하다고 생각하는 방식으로 앱 버전을 사용할 수 있는 옵션을 제공하지 않는 것이 큰 문제인 이유는 무엇입니까?

현재 형태에서는 이 APP VERSION 가 전혀 없는 것이 가장 좋습니다. 그것은 우리 프로젝트의 사람들에게 혼란을 가져올 뿐입니다. 우리는 같은 투구 차트를 사용하는> (80) 서비스를하고 수 없기 때문에 쉽게 변경하려면이 APP VERSION 에서 helm upgrade -i ... 나는 우리의 모든 응용 프로그램이 영원히 함께있을 것을 볼 1.0 여기

나는 또한 모든 사람에게 helm list 를 사용하지 말라고 말해야 합니다. 왜냐하면

나는 이 대화를 읽을 때 처음에는 낙관적이었지만 마지막에 가서 당신이 이것을 어떻게 토론하고 사용자가 당신의 생각을 갖도록 강요하는 방법을 보고 지금 희망을 잃었습니다 :(.

helm list , helm history 두 개의 서로 다른 출력 "CHART(version)" 및 "APP VERSION"이 있으면 매우 유용하며 다음을 얻기 위해 명령줄 옵션과 출력 구문 분석을 더 깊이 파고들 필요가 없습니다. 가장 중요한 사실.

"CHART(version)"과 "APP VERSION"이 빌드 시 연결되면("helm package") 두 개의 다른 값을 갖는 전체 이점이 다소 손실됩니다. 차트를 작성하고 차트 버전을 증가/업데이트하지 않고 앱 버전을 업데이트하면 동일한 차트 버전이 매우 다른 결과를 제공하므로 큰 문제가 발생합니다. :-<

따라서 현재로서는 모든 릴리스와 함께 패키지를 빌드하고 "차트(버전)" 및 "앱 버전"을 동기화하여 미친/불분명한 상황에 빠지지 않도록 해야 합니다.

방금 배운 것처럼 "APP VERSION"은 선택 사항이므로 일부 사용자 지정 값을 사용하고 이미지에 대해 {{ Chart.appVersion }} 대신 사용합니다. 하지만 helm list 는 덜 유익합니다. :-<

사용자(개발자) 관점에서:

• 설치 시 일부 버전 속성/플래그/값을 설정하는 기능
• "XX 버전" 레이블이 있는 helm 목록/기록 출력에서 ​​해당 버전 속성/플래그/값을 볼 수 있는 기능

우리가 그 일을 할 수 있는 기회가 있습니까?

"CHART(version)"과 "APP VERSION"이 빌드 시 연결되면("helm package") 두 개의 다른 값을 갖는 전체 이점이 다소 손실됩니다.

이것이 바로 불협화음의 핵심이라고 생각합니다. 내가 사용하는 앱 버전의 이점은 현재 설정에서 의도한 것처럼 보이지만 차트 버전은 전체 차트의 버전이 아니라 전체 차트의 버전이기 때문에 _해당 차트 버전에 대한 래핑된 애플리케이션의 버전을 알 수 있다는 것입니다. 차트의 템플릿 버전입니다. "우리는 Helm 차트의 버전 ~XY가 필요합니다"와 같은 모든 문장에 "아, AppVersion을 엉망으로 만들지 마십시오"를 끝에 추가하는 것을 싫어합니다.

이 이점은 앱 버전(및 앱의 실제 버전)이 설치 시 변경되기 때문에 손실됩니다. 이제 차트 버전이 사용 중인 앱을 알려주지 않고 SemVer를 사용하여 다음을 확인하는 기능을 상실하기 때문입니다. 예를 들어 최신 버전이지만 API와 호환되는 릴리스가 있습니다.

유스 케이스 @pniederlag를 들어이 할 수있는, 묘사하고 appVersion 할을 Values 항목에서 포인트를 만들 것이라고 템플릿을 helm list 원하는 무엇, 한 차트 지원이 필요 않는 한 그 애플리케이션 버전(아마도 컨테이너 태그)은 다른 모든 "설치 시 변경됨" 구성 옵션과 마찬가지로 --set 또는 --values 를 통해 설치 시 변경되었습니다.

여기서 AppVersion 있습니다.

릴리스 버전과 AppVersions를 모두 사용하고 있습니다.

지금을 설정하려면 - 내가 전화를해야하는 helm package 명시 적으로 사전의 helm upgrade --install 두 버전 인 세트와 로컬 타르 아카이브를 만듭니다.

이제 helm-secrets 지원을 추가하고...
그리고 래퍼가 helm package 와 함께 작동할 수 없습니다!

그래서 - 지금은?
모든 버전의 지원 및 흐름을 중단하시겠습니까?
비밀을 사용하여 삭제하시겠습니까?
어떤 아이디어?

실제로는 helm-secrets 대한 문제가 더 많지만 여기에서 논의된 --set app-version 능력과도 관련이 있습니다. 왜냐하면 이런 방식으로 사용할 수 있다면 - helm package 를 호출할 필요가 없기 때문입니다.

UPD 아, 잠깐만... 아직 helm secrets upgrade chart.tgz -f secrets.yaml 를 사용할 수 있습니다 ...
괜찮아.
그러나 여전히 --set app-version 를 추가하려면 +1 하십시오.

그래서 - 지금은?
모든 버전의 지원 및 흐름을 중단하시겠습니까?
비밀을 사용하여 삭제하시겠습니까?
어떤 아이디어?

두 개의 패키지를 빌드합니다. 하나는 차트만 있는 helm 패키지이고 env 값과 secret 파일은 제외됩니다. 차트 버전은 우리에게 아무 의미가 없고 차트 버전도 앱 버전 구문을 지원하지 않기 때문에 이 패키지의 이름을 chart-{app-version}.tgz 합니다. 앱 업데이트에는 잠재적인 차트 업데이트가 포함됩니다(git 태그 지정을 사용하는 동일한 리포지토리).

그런 다음 차트 tgz, 값 yaml 및 암호화된 비밀 파일을 포함하는 환경별 두 번째 tgz, chart-{app-version}-{env}.tgz 가 있습니다. 이 파일에는 helm-secrets 사용하여 배포할 자동화된 스크립트에 대한 태그, 앱 및 환경 이름과 같은 값이 포함된 "package.yaml"도 포함되어 있습니다.

우리는 시맨틱 버전 번호로 애플리케이션 버전 또는 대부분을 식별하는 데 사용됩니다. 그런 다음 APP 버전에서 이 번호를 사용하여 롤백 또는 기타 작업을 위해 helm history 목록에서 쉽게 식별할 수 있습니다.
시스템은 배포 시 자동으로 주입하는 것을 허용하지 않으므로 배포 명령 전에 CI/CD 파이프라인에서 이 간단한 명령을 자동으로 실행합니다.

sed -i -E "s/^appVersion: (.*)/appVersion: ${deploy.project.version}/" ${chartPath}/Chart.yaml

까다롭지만 예상대로 작동합니다.

@bvis
해결 방법의 문제는 CI/CD 파이프라인에서 차트를 편집해야 한다는 것입니다.
중앙 집중식 차트 리포지토리를 사용하는 경우 helm pull repo/chart --untar

Chart.yaml/appVersion을 프로그래밍 방식으로 주입하는 데 더 많은 진전이 있습니까? 해결 방법이 있습니까? 그것은 CI/CD Helm에 엄청난 부스트를 줄 것입니다.

@jakovistuk 내가 말할 수 있는 한, 컨테이너 버전을 표시하기 위해 appVersion 을 사용하는 nginx-ingress/Chart.yaml 에서 볼 수 있듯이 Chart.yaml을 통해 직접 이 작업을 수행합니다...

꽤 오랫동안 이 문제에 대해 깊이 생각하지 않았기 때문에 이것은 정말 어리석은 질문일 수 있지만 Helm CLI를 사용하여 appVersion을 재정의하는 방법이 있습니까?

여기 많은 사람들이 'appVersion' 필드를 재정의하는 방법을 묻는 것 같습니다. 이 문제의 원래 의도/요청은 —version에 대한 대체품으로 —app-version을 허용하여 사용자가 'helm fetch —app-version=v0.15.0'을 실행할 수 있도록 하고 Helm이 최신 차트 버전이 무엇인지 알아낼 수 있도록 하는 것입니다. v0.15.0을 appVersion으로 지정하고 가져옵니다.

우리 프로젝트/차트(cert-manager)에서 우리는 최종 사용자가 어떤 버전을 설치하는지 가능한 한 명확하게 하기를 원하므로 차트 버전 대신 앱 버전 으로 설치할 수 있도록 하는 것이 훨씬 더 자연스러운 설치 경험이 될 것입니다.

즉, 이 문제는 2년 전에 공개되었으며 그 이후로 이 두 버전 번호를 동기화/잠금 단계로 유지하기로 결정했습니다. 몇 년 후 이 작업을 수행한 후 놀라울 정도로 쉽고 고통이 없었습니다. 배포 매니페스트에 변경 사항이 있는 경우 사용자가 새로운 공식 릴리스를 위해 몇 주를 기다려야 하는 경우도 있습니다.

이 문제의 나이, 길이, 약간 다른 기능 게이트의 거대한 다양성, 이후 Helm 프로젝트의 변경 사항(Helm 3, OCI 차트 등)을 감안할 때 이 문제는 좋은 상태가 아니라고 생각합니다. 현재 형식의 기능 요청으로 앞으로 추진됩니다. 나는 이 호를 닫을 것이지만 비슷한 기능 요청이 있는 다른 사람은 증거를 제공하기 위해 새 호 를 하는 것이 가장 좋습니다. Helm 팀의 분류 프로세스에 더 잘 작동하여 요청에 필요한 가시성을 얻을 수 있기를 바랍니다.

나는 또한 이러한 종류의 기능이 외부 도구나 래퍼로 구현될 수 있고 아마도 가장 좋을 것이라고 생각합니다.
Helm, 특히 OCI 변경 사항을 고려할 때 구현하기가 더 까다롭다고 생각합니다.

이것이 해결될 때까지(또는 그렇지 않을 때까지) 내 CI/CD(GitLab)에서 이 문제를 해결한 방법은 다음과 같습니다.

앱 버전으로 차트를 패키징한 다음 배포합니다.
Chart 버전이 appVersion과 동일하지 않다는 것을 알고 있지만 우리의 경우 해결 방법으로 괜찮습니다.

deploy:
  image: alpine/helm:3.2.4
  stage: deploy
  environment:
    name: ${ENV}
  script:
    - helm package --app-version=${CI_COMMIT_TAG} --version=${CI_COMMIT_TAG} ${NAMESPACE}
    -  | 
       helm upgrade -i --wait ${CI_PROJECT_NAME} ./${NAMESPACE}-${CI_COMMIT_TAG}.tgz \
       --set image.repository="${CI_REGISTRY_IMAGE}" \
       --set image.tag="${CI_COMMIT_TAG}" \
       --set-string ingress.enabled="${INGRESS}" \
       --set service.port="${CONTAINER_PORT}" \
       --set service.targetPort="${CONTAINER_PORT}" \
       --set dc="${CI_ENVIRONMENT_NAME}" \
       --set project="${CI_PROJECT_NAME}" \
       --namespace ${NAMESPACE}
    - helm history ${CI_PROJECT_NAME} -n ${NAMESPACE}
  tags:
    - kubernetes
  only:
    - tags

image.tag 를 {{ .Chart.AppVersion }} 로 기본 설정하면 설치 중에 --set 할 필요가 없으며 이미 정확할 것입니다. 이는 Docker 이미지에 SHA1 태그가 지정되어 AppVersion이 Docker 이미지 태그와 일치하고 버전이 자동 빌드 SemVer인 경우 자동 빌드에서도 잘 작동합니다.

AppVersion이 SemVer인 경우 버전이 AppVersion과 동일해도 문제가 없습니다.

우리 팀에서 생산한 패키지의 경우 AppVersion이 설정되지 않은 경우 기본적으로 Version으로 설정되는 image.tag와 같이 AppVersion을 찾는 방향으로 이동하고 있습니다. 큰 차이는 아닙니다. 태그가 있는 릴리스의 경우 helm package 대한 인수가 하나 줄어들 뿐이지만 차트가 패키징하는 것과 동일한 SCM에서 빌드된 경우에만 의미가 있습니다.

이미지 태그를 설정하기 위해 하위 차트를 사용하는 경우 작동하지 않는 @TBBle

image.tag가 하위 차트에 있지만 상위 차트의 버전을 사용하려고 한다는 것을 의미합니까? 그렇다면 매우 어색하고 관리하기 쉽지 않을 것입니다. 방금 https://github.com/googleforgames/open-match/ 의 Helm 차트에서 이 레이아웃을 정확히 표시했습니다. 이 경우 문제의 하위 차트를 다시 기본 차트로 롤링하는 것이 좋습니다.

차트는 상위 차트 동작에 의존하지 않고 독립적으로 격리/사용 가능한 단위여야 합니다. 하위 차트에는 자체 버전이 있습니다. 이미지가 사용해야 하는 버전입니다. 그렇지 않은 경우 하위 차트인 이유는 무엇입니까?

Open Match의 경우 하위 차트가 사용되어 XXX.enable 를 values.yaml의 바로 가기로 사용하여 한 번에 많은 항목을 비활성화할 수 있는 것으로 보이지만 다음과 같은 구조적 문제가 많이 발생합니다. . Open Match의 하위 차트는 모두 템플릿이라는 상위 차트를 많이 사용하고 0.0.0-dev 의 로컬 버전도 있으므로 뭔가 잘 구성되지 않은 두 가지 코드 냄새가 있습니다.

아니면 내가 당신이하고있는 관찰을 오해했을 수도 있습니다.

@haimari 불행히도 작동하지 않습니다(https://github.com/helm/helm/issues/6921 관련 ?):

> helm package $DIR/deployment/chart --app-version="1111e8" --version="3454e5" --namespace stage
Error: Invalid Semantic Version

그러나 이것은 작동합니다.

> helm package $DIR/deployment/chart --app-version="0.0.0-1111e8" --version="0.0.0-3454e5" --namespace stage
Successfully packaged chart and saved it to: /Users/aws/service-0.0.0-3454e5.tgz

그리고 이것조차도 (그러나 더러워 보입니다):

> helm package $DIR/deployment/chart --app-version="0-1111e8" --version="0-3454e5" --namespace stage
Successfully packaged chart and saved it to: /Users/aws/service-0-3454e5.tgz

helm 버전 version.BuildInfo{버전:"v3.4.0", GitCommit:"7090a89efc8a18f3d8178bf47d2462450349a004", GitTreeState:"dirty", GoVersion:"go1.15.3"}

@haimari 의 솔루션은 있는 그대로 CI 파이프라인에서 semver 호환 태그를 사용하기 때문에 작동한다고 생각합니다.

@a0s : 일반적으로 다음을 제안합니다.

helm package $DIR/deployment/chart --app-version="<container image tag>" --version="<semver version>"

그런 다음 컨테이너 이미지 태그 값을 {{ Values.image.tag | default .Chart.AppVersion | default .Chart.Version 와 같게 하여

귀하의 예에는 두 가지 다른 git 버전으로 보이는 것이 있습니다. 맞습니까? 하나는 컨테이너 이미지용이고 하나는 차트용입니까?

SemVer를 사용하면 semver는 순서 지정을 의미하고 git commit SHA는 정렬할 수 없기 때문에 git commit SHA를 semver의 의미 있는 부분에 넣을 수 없습니다.

따라서 0.0.1-alpha.<build-id>+g<gitcommitsha> 와 같은 버전을 사용하고 싶을 것입니다. 여기서 <build-id> 는 CI 시스템의 파이프라인 또는 작업 ID와 비슷하므로 항상 프로젝트에 커밋합니다. 그렇게 하면 요청할 때 항상 최신 빌드를 얻을 수 있습니다.

SemVer에서 - 하는 것은 해당 버전의 시험판임을 의미하므로 0.0.1-<anything> 는 0.0.0과 0.0.1 릴리스 사이에 있습니다. + 뒤의 부분은 빌드 정보이며 정렬을 위해 무시되므로 git SHA 또는 분기 이름 또는 기타 정렬 불가능한 추적 정보를 넣는 것이 좋습니다.

따라서 여기에서 사용한 것과 함께 0-3454e5 는 SHA가 2 로 시작하는 경우 다음 커밋보다 최신 것으로 나타납니다(예: 0-2764e1 .

귀하의 예에는 두 가지 다른 git 버전으로 보이는 것이 있습니다. 맞습니까? 하나는 컨테이너 이미지용이고 하나는 차트용입니까?

예, 앱과 차트 - 두 개의 독립적인 소프트웨어가 있습니다.

그렇게 하면 요청할 때 항상 최신 빌드를 얻을 수 있습니다.

내가 원하지 않는(그리고 상상할 수도 없는) 최신 정보를 요청하면 어떻게 됩니까?

0.0.1-alpha.<build-id>+g<gitcommitsha>

이 문자열(보간 후)은 표준 helm list 출력의 한 열에 맞추기에는 너무 긴 것 같습니다. :)

나는 항상 설치하려는 앱의 버전(sha 해시)을 알고 있습니다( --set 인수로 전달). 그리고 나는 항상 내가 사용하는 차트의 버전을 알고 있습니다( @haimari가 설명 git checkout chart && helm pack && helm upgrade .tar.gz ci/cd에서 로컬로 사용할 것입니다)

무엇이 잘못될 수 있습니까?
1) 일반 helm upgrade 중 오류가 발생했습니다. 알겠습니다. 오류를 수정하고 다시 시도하겠습니다(앱의 다른 sha 커밋 사용 - 99%)(또는 대신 --atomic 사용)
2) 수동 롤백: helm rollback <RELEASE_NAME> 또는 CI/CD를 통한 배포 이전 샤 커밋.

내가 놓친 것은 무엇입니까?

PS 솔직히 말해서, 나는 정보 목적으로만 버전과 앱 버전에서 짧은 샤 부분을 사용하고 싶습니다( helm list 동안)

단지 정보 제공을 위한 것이라면 SemVer에서 - 아니라 + 뒤에 옵니다. 릴리스 순서나 다른 사람에게 Helm 차트를 배포하는 것에 _절대_ 신경 쓰지 않고 차트 또는 앱이 아직 SemVer'd되지 않은 경우 0+g<commitsha> 는 유효한 SemVer입니다(0.0.0에 해당).

예를 들어 Open Match의 Helm 자동 빌드 차트가 수행하는 작업은 다음과 같습니다. 그것들은 현재 모두 0.0.0-dev 이고, 우리는 당신이 설치한 것을 보고 있다면 적어도 당신이 가지고 있는 _what_ 마스터 빌드를 알 수 있도록 그 0.0.0-dev+g<commitsha> 를 만들기 시작했습니다 .