Ich bin auch gerade darauf gestoßen. Normalerweise möchte ich, dass das Image-Tag beim Packen des Diagramms angegeben wird, aber zum Debuggen wollte die App eine Installation mit einem anderen Tag durchführen.

Die Probleme veralten nach 90 Tagen Inaktivität.
Markieren Sie das Problem mit /remove-lifecycle stale .
Veraltete Ausgaben verrotten nach weiteren 30 Tagen Inaktivität und werden schließlich geschlossen.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes/test-infra und/oder fejta .
/Lebenszyklus veraltet

Dies noch einmal aufgreifen, wie es in https://github.com/kubernetes/charts/pull/5919 angesprochen wurde

Teile meines letzten Kommentars überschreiben:

Wir haben uns ausdrücklich dafür entschieden, die Nebenversion unseres Diagramms an der Nebenversion der Anwendung auszurichten (obwohl Patch-Versionsnummern auseinanderdriften können und es auch tun).

Dies liegt daran, dass wir möglicherweise ein neues Flag zu einer neuen Version von cert-manager hinzufügen und das Hinzufügen von Unterstützung dafür in das Helm-Diagramm die Kompatibilität mit älteren Versionen von cert-manager beeinträchtigen würde, da sie das Flag nicht unterstützen. Dies ist eine ziemlich grundlegende Frage zur Helm-Chart-Versionierung im Allgemeinen IMO, und wir haben keine gute Geschichte.

Ich weiß, dass es nicht empfohlen wird, appVersion an die Diagrammversion anzupassen, aber auf diese Weise weiß ein Benutzer, dass er die Helm-Diagrammversion 0.3.x mit jedem cert-manager 0.3.x und die Diagrammversion 0.4.x mit cert verwenden kann -Manager 0.4.x. Die Kompatibilität ist in der Nebenversion definiert.

/Remove-Lifecycle-Stale

Ich möchte das gerne wieder zur Diskussion stellen.

Insgesamt haben wir nicht viel für eine Versionierung der Diagramme für unsere internen Apps gesehen, wenn sich nur das Image-Tag ändert, das von einigen Komponenten verwendet wird. Wenn Sie ein Release aktualisieren, scheint das Feld appVersion der richtige Ort für diese Informationen zu sein.

Überschreiben meines ursprünglichen Vorschlags, auf den oben verwiesen wurde:

Unser aktueller Workflow zum Bereitstellen von Helm-Charts beinhaltet ansible Aufgaben, die den Befehl helm upgrade CLI aufrufen, und es wäre schön, ein Flag übergeben zu können, um die appVersion zu setzen, wenn ein Release für dieselbe Chart-Version überarbeitet wird.

Es mag konzeptionell etwas seltsam sein, da eine appVersion eher mit einem Diagramm als mit einer Veröffentlichung verknüpft ist, aber in unserem Fall aktualisieren wir nur das Image-Tag, das für einige Container verwendet wird, und unser Workflow enthält keine Diagrammversion und/oder Diagramm-Repositorys noch. Dies kann sich in Zukunft ändern, aber im Moment sehe ich kein Problem beim Hinzufügen eines Flags für --app-version bei der Installation und beim Upgrade, da das Feld rein informativ ist.

Bei der Entwicklung unserer eigenen internen Anwendungen ändert sich die App selbst viel mehr als das Diagramm, das sie bereitstellt. Normalerweise ist unser Continuous Deployment-Befehl ein helm upgrade mit nichts mehr als --set imageTag=<new_version> (wird offensichtlich an anderer Stelle im Diagramm verwendet, um die Containerversion festzulegen). uns einen weiteren visuellen Punkt in helm ls zu sehen, welche Codeversionen zusammen mit der bereitgestellten Diagrammversion bereitgestellt werden.

Um dies sonst sichtbarer zu machen, habe ich das Setzen eines Metadaten-Tags von imageTag standardisiert, das auf das bei Installation/Upgrade übergebene imageTag gesetzt wird. Dies ermöglicht es mir, das K8s-Dashboard zu verwenden oder ganz einfach Graphana-Dashboards mit angezeigtem imageTag zu erstellen, erfordert jedoch, dass ich die Befehlszeile verlasse und mit der Maus klicke.

Irgendetwas Neues darüber?

Danke

Gibt es hierzu Neuigkeiten. Es scheint, dass PR von @Eraac das tut, was verlangt wird. Wie @TD-4242 erwähnt, führen wir auch helm upgrade --set imageTag=<imagetag> , dies aktualisiert jedoch nicht die APP-VERSION, die in der Ausgabe von helm ls . Wenn wir --set app-version oder --set version ausführen können, können wir helm upgrade so ausführen, dass helm ls die bereitgestellte Version korrekt anzeigt.

Irgendwelche Updates?

Aaaajede Zeit bald wäre schön!

es wird sehr nützlich sein

Ich würde auch gerne die Möglichkeit haben, die App-Version bei der Installation festzulegen, da wir gängige Diagramme zum Bereitstellen von Anwendungen verwenden

+1

+1

Es wäre sehr hilfreich

Dasselbe anfordern

Bitte stoppen Sie den Spam mit dem +1. Es gibt bereits eine PR (https://github.com/helm/helm/pull/4961) und die Leute diskutieren den Vorschlag. Die letzte Antwort ist sogar 2 Tage her.

Hallo @filipre

Es gibt bereits eine PR (#4961) und die Leute diskutieren den Vorschlag.

Laut dieser PR wurde dies hierher verschoben:
https://github.com/helm/helm/pull/5492
Dies ist die neueste PR zu #4961 und sieht so aus, als ob wir darauf warten würden, dass eine Bewertung zusammengeführt wird ...

@filipre Könnten Sie bitte sagen: Was passiert mit der PR? Sieht so aus, als ob sich die PR den halben Monat nicht bewegt

Dies wäre sehr nützlich. Ich bin auf etwas gestoßen, bei dem ich an Version 0.6.0 einer App anheften muss, und die Diagrammversion hat keinen Bezug zur App-Version.

Ich stimme zu, ich denke auch, dass dies sehr nützlich wäre. Irgendwelche Updates?

Siehe https://github.com/helm/helm/pull/5492#issuecomment -509662190.

Ich habe dieses Problem jetzt einfach angesprochen, als mir klar wurde, dass dies ein Problem sein würde, als ich ein Helm-Diagramm schrieb, das wir für viele Anwendungen wiederverwenden möchten. Angesichts des Mangels an Fortschritten bei der Lösung dieses Problems auf einfache Weise (dh mit dem Flag zum Festlegen der App-Version bei der Installation), habe ich eine Alternative entwickelt, die vorerst funktionieren sollte. Es ist wirklich super einfach - machen Sie einfach zuerst helm fetch mit der Option untar und dann helm package mit dem dort vorhandenen Flag --app-version und fahren Sie dann mit der Installation des lokalen Diagramms fort.

Es ist nicht ideal, aber das Endergebnis in helm list ist korrekt, und es ist sehr einfach, dies auf einem CI-Server zu tun. Würde gerne nur --app-version auf helm install und helm upgrade verfügbar haben.

Die Zusammenfassung der Diskussion in #5492 war, dass ein Befehl, der die Logik von helm package und helm install umschließt, den ursprünglich in dieser Ausgabe beschriebenen Anwendungsfall lösen würde.

Mit anderen Worten, Sie können dies umgehen, indem Sie Folgendes ausführen:

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

(Bewegender Kommentar von kürzlich geschlossener PR hier - damit er nicht im Nirvana landet)

Hier meine 2 Cent dazu:
Angenommen, wir haben einen Steuermann chart version X , der einen Dienst mit appVersion Y .

Das Helm-Diagramm wird verwendet, um die Infrastruktur innerhalb von Kubernetes auf chart version X die verwendet wird, um einen Dienst von appVersion Y zu hosten.

Während der anfänglichen Entwicklung werden sowohl X als auch Y regelmäßig geändert. Irgendwann wird X jedoch mehr oder weniger stabil sein und Y wird sich weiter ändern (es sei denn, Y hat neue Anforderungen an die Infrastruktur, was höchstwahrscheinlich viel seltener vorkommt im Entwicklungszyklus von Y ).

Mit dem in diesem Ticket vorgeschlagenen Ansatz könnte man ein stabiles Helmchart-Paket auf Version X , um eine AppVersion Y , Y+1 , Y+N usw. bereitzustellen.

Wenn dieses Flag jedoch während der Installation oder Aktualisierung von Helm nicht überschrieben werden kann und stattdessen nur in einem Paket zB X und Y zusammengebunden wird, muss ich immer ein neues X+1 erstellen. Y+1 . Dies erscheint mir unnötig und würde zu einer Menge Helmpaketen führen, die sich effektiv nicht geändert haben, abgesehen davon, dass sie auf ein neues appVersion verweisen. Aus meiner Sicht haben eine Version einer Anwendung und eine Version der Infrastruktur, die diese Anwendung hostet, eine Beziehung, sollten oder könnten jedoch immer noch unabhängig versioniert werden. Wie das geht, sollte den jeweiligen Entwicklungsteams überlassen werden.

Zusammenfassung:

Dieser Ansatz funktioniert definitiv, führt aber auch zu vielen unnötigen Helm-Paketen, bei denen sich nur die AppVersion geändert haben:
$ helm package myapp --app-version 1.0.0 $ helm install myapp-1.0.0.tgz

Ja, aber ich denke, es ist kein großes Problem, wenn Sie den oben genannten Ansatz verfolgen. Verschieben Sie Ihr Diagramm in ein Diagramm-Repository ohne festgelegte App-Version (oder 0.0.0 oder so). Wenn Sie es dann verwenden möchten, verwenden Sie helm fetch , packen Sie es mit der richtigen App-Version und verwenden Sie dann das lokale .tgz Datei und verschieben Sie dieses Diagramm nicht. Auf diese Weise bleibt Ihr Chart-Repo sauber und Sie haben dort nur die tatsächlichen Chart-Änderungen dargestellt.

Ja, es würde funktionieren. In diesem Fall könnte man das Deployment-Artefakt nie direkt konsumieren (zB durch direkte Installation aus dem Helm-Repository), sondern muss es immer durch einen zusätzlichen Schritt schicken, der das Artefakt mutiert.

Wo argumentiert wurde, dass Charts.yaml unveränderlich sein sollte, argumentiere ich, dass das Bereitstellungsartefakt dies sein sollte.

_Zusammenfassung meiner Gedanken von https://github.com/helm/helm/pull/5492#issuecomment -520029902_

Es gibt ein Problem damit, wie die Community das Paket, das Diagramm und die Versionen interpretiert. @BenjaminSchiborr , ich hoffe, das macht für dich Sinn.

Chart - ist ein Quellcode Ihrer Veröffentlichung. Wie ein Quellcode Ihrer App. Besteht aus Vorlagen, Codedateien.
Paket - ist ein Build Ihres Releases, Artefakts. Wie eine Binärdatei, die aus Ihrem Quellcode erstellt wurde. Besteht aus festen Produktionsversionen: sowohl Chartversion als auch App-Version.
Release - ist ein Build, der mit der angegebenen Konfiguration bereitgestellt wird.

Es gibt keine Möglichkeit, aus Chart ein Release zu machen . So geht das einfach nicht!

Bevor Sie Ihre App auf der Bühne bereitstellen, benötigen Sie ein Diagramm. Dann müssen Sie Ihre App mit einem Diagramm verpacken und beide Versionen reparieren, indem Sie helm package . Das Ergebnis ist ein Paket, das auf jeder Bühne bereitgestellt werden kann. Dann installieren Sie dieses Paket beispielsweise auf der QA-Phase, bewerben es auf UA und dann auf Produktion, indem Sie helm install .

So funktioniert jede paketorientierte Software.

Die Verwirrung

helm install benötigt eine Quelle, die installiert werden sollte. Quelle könnte sein:

1. Paketname, in der Registrierung verfügbar
2. Pfad der Paketdatei, wenn das Paket bereits heruntergeladen oder erstellt wurde
3. Paket-URL, falls über HTTP verfügbar
4. Diagrammverzeichnispfad

Der vierte Ansatz fühlt sich hier wie ein schwarzes Schaf an, findest du nicht? Aus diesem Grund verwechseln ppl Paket und Diagramm. Und das ist eine Wurzel der Probleme.

Argumentation

Es gibt zwei Arten von Apps in freier Wildbahn:

Groß/Mittel – hier haben wir Zeit, Geld und Ressourcen, um detaillierte, granulare Abläufe für eine bessere Introspektion und Qualitätsgarantien einzurichten.
Klein - ein Microservice, ein Haustierprojekt, PoC, kostengünstige Projekte, Projekte ohne DevOps-Kenntnisse oder sogar das Testen von Entwicklungsprozessen.

Bei kleinen Projekten haben Sie keine Zeit oder müssen Verpackungen erstellen oder bearbeiten. Sie möchten einige Vorlagendateien schreiben und mit einem Befehl bereitstellen !

Aus diesem Grund erlaubt helm install eine solche Verwendung wie helm package & helm install . Es bietet jedoch nicht die vollen helm package Funktionen, wie beispielsweise --app-version .

helm install kann helm package & helm install , aber es würde helm install einem Chaos machen, eine Hölle für Support, Tests und gute Praktiken.

Vorschlag 1

Vereinfachen Sie helm install . Es sollte zulassen, dass nur Pakete bereitgestellt werden, um die Codebasis zu vereinfachen, zu testen und sie zu überzeugen, um das Verständnis von helm zu vereinfachen.

Vorschlag 2 - helm run

Führen Sie den neuen Befehl ein: helm run . Ein Befehl, der einfach funktionieren sollte . Ideal für kleine Apps. Oder vielleicht sogar mittel und groß.

Es sollte helm package und helm install kombinieren und Fähigkeiten beider Befehle bereitstellen, außer denen, die in einem solchen Anwendungsfall keinen Sinn machen.

helm package erstellt einen Build, wie es go build tut. go run ermöglicht das Starten der App ohne den Erstellungsprozess, daher sieht helm run wie ein solider Name aus.

Zusätzliche Dinge zu beachten:

• Sollte es stattdessen upgrade --install verwenden?
• Sollte --atomic standardmäßig aktiviert sein?

@iorlas ,
deine Kommentare machen Sinn. Sie gehen jedoch davon aus, dass es nur ein letztes Paket geben kann, das Infrastrukturversion und Softwareversion erblich miteinander verbindet, während ich davon ausgehe, dass ich ein Paket für meine Softwareversion und ein Paket für meine Infrastruktur habe und diese festbinden möchte in einem Release (zB durch eine gewünschte Zustandskonfiguration, die auf Softwareversion und Infrastrukturversion verweist).

Ich sehe nicht ein, warum ein Entwicklungsprozess in dieses Muster gezwungen werden sollte, bei dem es auch den zuständigen Entwicklungsgruppen überlassen werden könnte, ob sie Infrastruktur und Softwareversion auf der Ebene des Helmpakets oder später zusammenführen wollen. Derzeit muss ein Bereitstellungsprozess immer neue Helmpakete verwenden, während sich nur die Softwareversion ändert. Dies führt für mich zu Tausenden von nutzlosen Paketen in einem Repository.

Mir geht es gut, wenn das einen langfristigen Vorteil hat. Ich sehe es einfach nicht.

@BenjaminSchiborr Okay, lass es mich ein bisschen

Sie können Ihr Diagramm (== Infrastruktur) haben, das die Version X .
Sie können Ihre Anwendung haben, Version Y .

Wie helm funktioniert, verbindet es Infrastruktur- und Anwendungsversionen im Schritt helm package . Dann müssen Sie es mit dem Namensraum k8s verbinden, um Release zu erzeugen.

Die Formel lautet also: package(infra + app) + k8s = Release

Was Sie wirklich wollen, ist, diesen mittleren Schritt zu überspringen und alle 3 Komponenten in einem Schritt zusammenzubinden - Release. So: infra + app + k8s = Release . Hab ich recht?

Dies ist, was helm run an der Oberfläche tun wird. Unter der Haube wird es genauso sein.

Aber... ich habe das Gefühl, dass Sie Helm übersehen . Obwohl jedes Werkzeug nach Belieben verwendet werden kann, gibt es immer eine Idee, die die Community beeinflusst, einen "Weg" schafft, damit ein Teleskop nicht als Hummer mit der Fähigkeit, ein Bier zu brauen, endet.

Lassen Sie mich versuchen, zu beschreiben, wie es verwendet werden sollte, und es wäre großartig, es aus Ihrer Perspektive zu sehen.

Helm selbst wurde entwickelt, um die k8s-Vorlagen und -Bereitstellung zu abstrahieren, Anwendung und Infrastruktur mit ihren Abhängigkeiten zu verbinden: Anstatt Vorlagen manuell neu zu schreiben, auf K8s anzuwenden und dann ein neues Image-Tag bereitzustellen, benötigen Sie nur einen Befehl - helm upgrade . Wie ein MSI- oder Deb-Paket.

Wenn Sie eine neue App-Version installieren oder ein Downgrade durchführen müssen, sollten Sie helm dafür verwenden. Anstatt die App zu verwalten, verwalten Sie das gesamte Paket. Es wäre eine Nervensäge, App-Version und Infrastruktur separat zurückzusetzen, wenn etwas schief geht - ich war dort und werde es niemandem empfehlen.

Es ist also richtig, viele Pakete in Ihrer Registry zu haben, denn das Paket ist nicht die Infrastruktur, das Paket ist die App, denn die App bedeutet in K8s ohne Infrastruktur nichts.

Wenn Sie das Problem haben, dass Sie zu viele Pakete im Repository haben, würde ich vorschlagen, Artefakte anstelle von Repositorys zu verwenden. In CI mache ich das so: App erstellen, an die Docker-Registry senden, Paket erstellen, als Artefakt zur Veröffentlichung speichern. CircleCI, Travis, Azure Pipelines unterstützen das Erstellen von angehängten Dateien als Artefakte. Können Sie dasselbe tun?

Vielleicht übersehe ich den Sinn von Helm. Vielleicht hat Helm hier einen Punkt übersehen. Ich denke, in diesem Ticket geht es darum, genau das zu bewerten. Und persönlich - auch darum, meinen Horizont zu erweitern :)

Aber ja, abstrakt ist das, was du sagst, richtig. Ich möchte nicht, dass die Softwareversion mit dem Helm-Paket/-Release gekoppelt ist, also ist es im Wesentlichen infra + app + k8s = Release . Genauso wie ich nicht möchte, dass die Eigenschaften meiner Softwareversion an mein Helm-Paket/-Release gebunden sind (abgesehen von vielleicht gesunden Standardwerten, die ich überschreiben kann).

Bezüglich des Beispiels, das Sie weiter unten angeben. Ich sehe nicht, wie dies zeigt, wie problematisch dieser Ansatz ist. Sie würden immer noch das Ruder zum Zurückrollen oder Vorrollen verwenden. Wenn sich die Infrastruktur ändert, verwenden Sie eine geänderte Helmkartenversion. Wenn sich die Softwareversion ändert, verwenden Sie eine andere Appversion. Wenn sich ein Parameter ändert, verwenden Sie einen anderen Parameter. Es wäre immer ein (einmaliger) Steuerruf pro Dienst.

Können Sie das näher ausführen?

Wenn Sie das Problem haben, dass Sie zu viele Pakete im Repository haben, würde ich vorschlagen, Artefakte anstelle von Repositorys zu verwenden.

Was ich meinte, waren zu viele verpackte Helmdiagramme (die bereits appVersion enthalten). Betrachten Sie es als eine stabile Version des Helmdiagramms und eine App-Version, die sich Hunderte Male am Tag ändert. Also täglich ein paar hundert verpackte Helmcharts pro Dienst in einem Repository, das später von einer Automatisierung verbraucht wird.

(Meine Pipelines sehen im Allgemeinen genauso aus wie Ihre: App erstellen --> Docker-Image (führt zu appVersion) --> Paketdiagramm (mit aktualisierter appVersion) --> Pushs ins Repository?

Ich denke, in diesem Ticket geht es darum, genau das zu bewerten.

Mit Sicherheit! Meiner Meinung nach haben wir bereits zu viele Abstraktionsebenen, so dass es etwas überfordert, hier einen Helm zu haben. 😄Außerdem gibt es hier k8s-Operatoren, die für einige (vielleicht die meisten?) der Probleme erstellt wurden, die Helm löst. Aber das ist ein Thema für ein anderes Mal, hehe.

Betrachten Sie es als eine stabile Version des Helmdiagramms und eine App-Version, die sich Hunderte Male am Tag ändert. Also täglich ein paar hundert verpackte Helmcharts pro Dienst in einem Repository, das später von einer Automatisierung verbraucht wird.

Ja, es fühlt sich definitiv zu viel an, aber es ist beabsichtigt. Wenn Sie beispielsweise einen Build-Lauf haben, sollte er einige Artefakte erzeugen und ihn dann speichern, um ihn auf der Bühne bereitzustellen. Wie können wir einen Build ausführen, der kein Build-Ergebnis hat? Sollen wir den Build bei der Bereitstellung generieren? Es wäre wirklich falsch. Obwohl einige CI-Pipelines dies für die JS-Builds tun.

Das gleiche Problem haben wir mit Docker: Jeder Build generiert ein neues Docker-Image, das in die Docker-Registrierung eingeht. Wir müssen es speichern, wie sollten wir es dann einsetzen, wenn wir es nicht hätten?

Natürlich können wir docker save sparen, um Platz in der Registrierung zu sparen und später in die Aufbewahrungsrichtlinie für Build-Arefakte einfließen zu lassen. Aber so können wir es helm package und als Datei behalten.

Aber ich verstehe definitiv Ihren Punkt, wir können einen "Installer" haben, der eine App-Version akzeptieren kann. Da ein solches Installationsprogramm über eine Infrastruktur verfügt, können Sie diese beibehalten, indem Sie einfach die App-Version ändern. Sieht ordentlich und einfach aus, aber es gibt ein Problem.

Die App selbst macht in einer k8s-Umgebung ohne Infrastruktur keinen Sinn .

Was ist, wenn Ihre App von einer Infrastruktur abhängig ist? Einfaches Beispiel - configmap.

Was ist, wenn Sie die App dann zurücksetzen müssen?
Sie müssten die App herunterstufen, aber dann müssen Sie auch die Infrastruktur herunterstufen.

Was ist, wenn Sie dann die Infrastruktur zurücksetzen müssen?
Die bisherige Infrastruktur hat keine Ahnung, welche App-Version Sie installieren müssen, da sie nicht daran gebunden ist. Sie müssen sich also merken, welche App welche Infrastruktur unterstützt und diese manuell einstellen.

Das wäre wirklich die Hölle. Und es ist im Moment die Hölle, wenn du kein Ruder hast. Und es ist nicht falsch. Aber in diesem Fall haben Sie wenig Gründe, Helm zu verwenden.

wir haben schon zu viele Abstraktionsebenen
Alles schön und einfach zwinker

Deinen letzten Punkt finde ich sehr überzeugend:

Die bisherige Infrastruktur hat keine Ahnung, welche App-Version Sie installieren müssen, da sie nicht daran gebunden ist
Dies ist definitiv ein Problem, wenn Sie diese Dinge entkoppeln und das Helm-Paket/-Release als Quelle der Wahrheit haben.

Für viele Menschen ist dies jedoch wahrscheinlich nicht der Fall. Es gibt eine Orchestrierung über Helm (yay, eine weitere Abstraktionsebene), die mehrere Helmdiagramme (und AppVersions) miteinander verbindet (Think Ruderman, Harness oder ähnliches). Und diese Ebene selbst ist ebenfalls versioniert. In diesem Fall ist das, was Sie beschreiben, kein Problem mehr, da Sie nicht auf eine ältere Version eines Helmdiagramms zurückgreifen würden, sondern auf eine ältere Version der Orchestrierungsschicht (das ist für App und Infrastruktur sinnvoll).

Aber Helm allein, ja, 100% ein Problem 💣. Ich denke, das ist der Grund, warum die Idee war, das Überschreiben der appVersion explizit zuzulassen und standardmäßig nicht zuzulassen.

Was mir an der Kopplung von Chartversion und Applikationsversion gefällt, ist, dass klar wird, welche Applikationsversion zu welchem ​​Chart gehört. Wenn Sie eine bestimmte Version erneut bereitstellen müssen, müssen Sie sich nicht daran erinnern, welche Anwendungsversion mit welcher Kartenversion kompatibel war. Da sie miteinander verknüpft sind, verweisen Sie einfach auf die richtige Diagrammversion und Sie werden sicher sein, dass Anwendung und Diagramm zusammenpassen. Ich denke, das ist im Grunde das, was @iorlas beschrieben hat, oder?

Am Ende fungiert die Chart-Version als "Super"-Version:

• jede Änderung (unabhängig davon, ob die Anwendung oder die Infrastruktur, dh die Karte) geändert wurde, führt zu einer neuen Kartenversion, dh eine neue Anwendungsversion impliziert, dass sich auch die Kartenversion geändert hat
• eine neue Kartenversion bedeutet nicht, dass sich die Anwendungsversion geändert hat

Zu Dokumentationszwecken (und vielleicht anderen ausgefallenen Ideen) könnten Sie selbst eine andere "Nur-Diagramm"-Version einführen, die sich nur auf die Diagrammdefinition selbst bezieht.

@philipre
Yup-yup! So sollte Helm funktionieren, basierend auf aktuellen Entscheidungen zum Architekturdesign. Wie ich es sehe.

Das Problem ist, dass es sich manchmal komisch anfühlt - zu viel für die Einrichtung und fragwürdige Idee, App und Infrarot miteinander zu verbinden. Ist es also der richtige Ansatz - das ist eine Frage.

@BenjaminSchiborr

Für viele Menschen ist dies jedoch wahrscheinlich nicht der Fall

Mit Sicherheit! Sogar ganze K8s, Containerisierung könnte zu viel sein.

Lassen Sie mich versuchen, es aus einer etwas anderen Perspektive aufzuschlüsseln, indem ich versuche, das Problem zu finden, für das Helm geschaffen wurde:

• Infrastrukturinstanz ist die Funktionsweise des gesamten Produkts: SaaS-Instanzen, VM-Pools, k8s-Setups, App-Versionen (einschließlich Datenbanken, Observability-Tools, Router, Sidecars und die Produkt-App-Instanzen)
• Die Infrastrukturinstanz benötigt eine Quelle der Wahrheit. Jetzt haben wir Dienstprogramme wie Terraform.
• Zu viele Dinge in einem Ordner = schwer. Wir müssen es zerlegen. Hallo Terraform-Module.
• Plattform und Anwendung in einem Ordner = schwer. Wir müssen uns zersetzen. Hallo Plattform und Container. K8s greift ein.
  
  
  
  1. So können Terraform- Module die Plattform verwalten, einschließlich der Erstellung leerer, gebrauchsfertiger Container-Layer
  
  
  2. K8s verwaltet die Container und ermöglicht die Erstellung grundlegender Ressourcen mit YAML
  
  
• Viele YAML-Dateien für viele K8s-Apps (einschließlich Datenbanken und so) = schwer. Teilen Sie es pro App in Ordner auf.
  
  
  
  1. Da haben wir also einige Ordner wie PostgreSQL, Redis, MyPetShop. Jede davon hat YAML-Dateien für die Ressourcen, die wir haben. Und es müssen seine App-Versionen eingestellt sein, um in K8s angewendet zu werden.
  
  
• Hallo Helm - Instrument, das es erlaubt, diese Ordner (Charts genannt) einzurichten, aber mehr: zusammen anwenden, Rollback.
• Diagramm sieht solide aus. Lassen Sie es uns wiederverwenden, indem wir Variablen unterstützen. Chart ist jetzt keine Infrastruktur-, sondern eine Infrastruktur-Vorlage.
• Diagramm sieht toll aus. Lass es uns mit Freunden teilen. Jedes Mal, wenn wir das Diagramm aktualisieren, müssen wir es mit Index in das Datei-Repository verschieben.

Es fühlt sich also großartig an und das ganz ohne Pakete. Sie müssen also dieses Diagramm anwenden und dann die Anwendungsversion bereitstellen. Und es sollte es sein.

Aber es taucht ein Problem auf: Niemand möchte sich merken, welches Diagramm für welche App-Version benötigt wird. Welches Diagramm wird aktualisiert, um einen neuen Konfigurationswert für welche App-Version bereitzustellen.

Letztendlich wollen wir nur "myApp Version 1.4.2 als K8s-App einrichten" , die alle Risiken, Abhängigkeiten und Änderungen in einem Artefakt vereint - Anwendungsinstallationsprogramm, das apps versions + hooks + setup logic + infrastructure to connect it all . Aus diesem Grund haben wir solche Dinge wie MSI, Deb, RPM, sogar NPM, Go Mod, Pip, Gem.

Hier kommt Package ins Spiel. Und Package muss per Definition als installierbares Release im CI/CD-Flow erstellt werden. So können wir es in die Registrierung und / oder das Setup auf unserem System (k8s-Cluster) senden.

Und kein anderes Projekt ist anders. Wenn wir direkt helm install Charts ohne Paket erstellen, machen wir dasselbe. Aber anstelle der Paketerstellung erstellen wir es in einem anderen Schritt. Anstatt es auf dem App-Erstellungsprozess aufzubauen, bauen wir es auf dem Release-Schritt auf. Wir verknüpfen nach wie vor Infrastruktur und App-Versionen . Implizit .

Komisch ist:

• Abhängigkeit aktualisiert = Aktualisieren Sie die Version der Infrastrukturvorlage (Diagramm)
• App aktualisiert = einen Fork generieren, Teilmenge der Infrastrukturvorlage (Chart) - Paket, mit eigener Version

Dennoch sollen k8s-Operatoren auf aktuelle Probleme projiziert werden, daher sollte es nur ein Instrument geben, das wie Operatoren funktionieren sollte, aber einen einfachen Freigabeprozess wie helm bietet.

Irgendwelche Gedanken? Wir schaffen hier vielleicht etwas Neues, aber besser

Was Sie beschreiben, ist sehr sinnvoll für Anwendungen, die von anderen Personen in der Infrastruktur verwendet werden sollen, über die Sie keine Kontrolle haben. In Unternehmensszenarien wird das Erstellen von Paketen jedoch zu einer mühsamen Arbeit: Wir haben möglicherweise Dutzende von Cookie-Cutter-Microservices, die in gemeinsam genutzten oder Cookie-Cutter-Umgebungen bereitgestellt werden, und aufgrund der CI/CD-Pipeline-Definition, die im Repository selbst lebt (denken Sie azure-pipelines.yaml), ist die "Paketversion" nur ein Build, der aus einer bestimmten Version des Master-Zweigs erstellt wurde. Das heißt, ich muss das "Paket" nirgendwo wirklich speichern - mein Build erzeugt das gleiche Paket mit den gleichen Bits und den gleichen Variablen, die in configmaps usw. verwendet werden. In Szenarien wie diesem werde ich das Helmdiagramm nur dann aufdrehen, wenn Service-Infra ändert, was ziemlich selten vorkommt. Helm ist in diesem Bild, weil 1) ich es bereits verwenden muss, um einige Teile von Infra (z. B. nginx) bereitzustellen, 2) ich das Rad nicht neu erfinden muss, indem ich k8s-yaml-Templates erstellt.

@wasker

Lassen Sie es uns zum Beispiel auf docker projizieren. Docker-Image ist auch ein Paket. Es verbindet Binärdateien mit OS-Image = Infrastruktur. Ich glaube, der Grund für jedes Mal, wenn wir einen Build erstellen, ein Docker-Image zu erstellen, ist der gleiche wie für die Erstellung eines Helm-Pakets.

Wenn man nicht alles auf die Docker-Images abstrahieren muss, braucht man auch kein Docker und kann mit einfacher VM leben.

Wenn wir also versuchen, die Docker-Nutzung auf helm zu projizieren, wäre die Verwendung von helm nur als Infrastrukturinstrument so, als würde man Docker nur verwenden, um ein anfängliches Image zu erstellen und dann ein solches Image auf dem k8s-Host selbst zu aktualisieren, indem neue Binärdateien gesendet werden. Es ist schlimm, genauso schlimm wie Helm zu benutzen und es nicht jedes Mal neu zu verpacken.

Wie auch immer, ich denke, wir sind den falschen Weg gegangen. Benutzt jemand helm und aktualisiert das Bild dann manuell? Ich glaube, wir haben 3 allgemeine Anwendungsfälle:

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

@wasker Welches ist deins? Ich glaube, nicht der 3. Auch wenn es eine echte Trennung von Infrastrukturkonfiguration und Anwendungsversionierung ist, wäre es unangenehm, damit zu arbeiten. Da dies bedeuten würde, dass Sie alle Versionen verlieren, wenn Sie die Infrastruktur aktualisieren müssen. Sie müssen es in Chart, manuell oder kubectl set image für jede Bereitstellung aktualisieren.

Wir sprechen also über das zweite, helm install chart , "ohne Verpackung". Helm ist also immer im Bild . Das Problem ist, dass das Paket erstellt wird, aber in der Laufzeit - wenn wir unsere App bereitstellen. Der CI-Build ist also implizit für die Paketerstellung verantwortlich, wenn wir ihn bereitstellen müssen.

Und wenn es auf Golang projiziert wird, sieht eine solche Praxis so aus, als würde man Quellcode senden und als go run im Docker ausführen, anstatt ihn zu erstellen und die Binärdatei zu verwenden.

Der wahre Grund , den Verpackungsschritt zu überspringen, besteht also darin, das Gesamtbild für den Ingenieur zu Ist es ?

Hier können wir anfangen zu reden. Hier https://github.com/helm/helm/issues/3555#issuecomment -529022699 ist mein Vorschlag. Fügen Sie helm run und modellieren Sie es als go run .

Wenn wir die Infrastruktur und die App-Versionsverwaltung wirklich aufteilen müssen, würde dies bedeuten, dass

Lassen Sie es uns zum Beispiel auf docker projizieren. Docker-Image ist auch ein Paket. Es verbindet Binärdateien mit OS-Image = Infrastruktur. Ich glaube, der Grund für jedes Mal, wenn wir einen Build erstellen, ein Docker-Image zu erstellen, ist der gleiche wie für die Erstellung eines Helm-Pakets.

Ich denke, das Problem besteht darin, dass sich beim Erstellen eines neuen Docker-Images etwas in diesem Image geändert hat. In dem hier beschriebenen Szenario hat sich der Inhalt des verpackten Helm Charts bis auf eine einzige Zeile nicht geändert - die App-Version. Dies beeinflusst das Endergebnis, ändert jedoch nichts am Verhalten des Helm-Diagramms. Es wird dasselbe auf dieselbe Weise tun, nur mit anderen Werten – das Helm-Diagramm als eigenständige Einheit hat sich durch die Änderung dieser App-Version nicht im Geringsten geändert; nur das, was am ende freigegeben wird, hat.

Sie könnten hier Parallelen zu der Möglichkeit ziehen, beispielsweise die Konfiguration für Docker-Images zu verwenden. Sie übergeben Umgebungsvariablen an ein Docker-Image, dies beeinflusst, wie es zur Laufzeit ausgeführt wird, und Sie erstellen kein Image neu, um diese Variablen zu ändern. Der Inhalt des Bildes hat sich nicht geändert, aber das Endergebnis hat sich geändert - sehr ähnliche Situation dort, aber in diesem Fall ist das Verhalten wünschenswert und normal.

Und wenn es auf Golang projiziert wird, sieht eine solche Praxis so aus, als würde man Quellcode senden und als go run im Docker ausführen, anstatt ihn zu erstellen und die Binärdatei zu verwenden. [...] Der wahre Grund, den Verpackungsschritt zu überspringen, besteht also darin, das Gesamtbild für den Ingenieur zu vereinfachen. Ist es?

Aus meiner Sicht nicht. Realistischerweise wird hier argumentiert, ob die Leute die App-Version als "Teil des Diagramms" betrachten oder nicht und auch, ob sie ein Helm-Diagramm von den Docker-Images unterscheiden, die als Ergebnis des Diagramms bereitgestellt werden. Meine Meinung dazu ist das, was ich oben erwähnt habe. Es ist, als ob Sie eine kompilierte Go-Binärdatei in einem Docker-Image nehmen und sie mit einigen verschiedenen Umgebungsvariablen ausführen.

Die Argumente, ein Helm Chart mit einer neuen Anwendungsversion umzupacken und die Chart Version als eine Art "Superversion" zu verwenden, sind jedoch überzeugend (nämlich für den Vorteil, immer eine kompatible App-Version mit einem Diagramm - vorausgesetzt, dass die Anwendungsversion nicht über Werte anpassbar ist).

Meine Frage lautet: _Warum nicht beide Ansätze unterstützen?_ Jeder Ansatz hat Vor- und Nachteile. Dies nicht zu unterstützen, erschwert im Grunde nur einige vollkommen gültige Workflows. Zum Beispiel mit Flux CD und seinem Helm Operator. Wenn Sie ein gemeinsames Helm-Diagramm haben (dh weil Sie eine bestimmte Art von Dienst haben, von der Sie viele bereitstellen und die viele der gleichen Eigenschaften aufweisen), dann müssen Sie einen neuen Helm haben, um eine nützliche Ausgabe von helm list zu erhalten Diagramm für jede App und jede Version benötigt auch ein eigenes Helm-Diagramm. Dies allein verkompliziert die Pipelines, denn wenn das Diagramm gemeinsam genutzt werden könnte, könnte es eine eigene Pipeline haben, die nur ausgeführt wird, wenn das Diagramm aktualisiert wurde, und die Anwendungspipelines müssten nicht einmal einen einzigen Helm-Befehl ausführen (vorausgesetzt, Flux CD hat Unterstützung für ein neues App-Versions-Flag bei der Installation/Upgrade).

Meine Frage ist - warum nicht beide Ansätze unterstützen?

Genau das denke ich.

In meinem Fall ist die "Superversion" nicht die Helmkarte, sondern eine andere Ebene, die nur eine Fülle von Helmkarten verwendet. Für mich ist ein einzelnes Helm-Diagramm bedeutungslos, da es nur einen kleinen Service unter vielen anderen beschreibt. Nur zusammen bilden sie eine sinnvolle Auslösung.
In meinem Fall ist die "Superversion" also die Zusammenfassung all dieser Releases zusammen (so wird sie eigentlich versioniert).

Dennoch gibt es ein Argument dafür, ein Helm-Diagramm selbst als beschreibende "Superversion" zu haben.

Zurück zum Punkt von @seeruk : Warum nicht beides unterstützen?

Für die aktuelle Debatte kann es hilfreich sein, eine Stimme von außen zu bekommen. Für einen kleinen Kontext habe ich helm für insgesamt _11 Tage verwendet._ Ich denke, dies gibt mir eine einzigartige Perspektive, die ich hinzufügen kann, da ich an keinem fortgeschrittenen Lernen beteiligt war. Alles, was ich herausgefunden habe, stammt aus Dokumentationen und Experimenten.

So sehe ich Helm

Bis ich diese aktuelle Debatte über die Installation von Paketen anstelle von Diagrammen durch Helm gelesen habe, habe ich geglaubt, dass Helm hauptsächlich eine Schnittstelle zur Beschreibung verwandter Kubernetes-Ressourcen ist. Dieser Glaube kommt hauptsächlich aus der Helm-Dokumentation, die Folgendes sagt:

Helm installiert Diagramme in Kubernetes und erstellt für jede Installation eine neue Version. Und um neue Diagramme zu finden, können Sie Helm-Diagramm-Repositorys durchsuchen.

Aus Gründen des Kontexts heißt es in den aktuellen Stable-Helm-Dokumenten auch:

Ein Chart ist ein Helm-Paket. Es enthält alle Ressourcendefinitionen, die zum Ausführen einer Anwendung, eines Tools oder eines Dienstes innerhalb eines Kubernetes-Clusters erforderlich sind. Stellen Sie es sich wie das Kubernetes-Äquivalent einer Homebrew-Formel, einer Apt-Dpkg- oder einer Yum-RPM-Datei vor.

Jetzt gibt es also etwas Verwirrung! Die Helm-Dokumentation sagt klar, dass "eine Karte ein Helm-Paket ist", aber wenn dies der Fall ist, warum in aller Welt akzeptiert helm install nicht verpackte Karten-Repos?

Es ist dieses Verhalten, das meine aktuelle Ansicht darüber beeinflusst hat, was Helm ist und wie es funktionieren soll:

Helm fungiert als Mapper zwischen der Struktur von _was_ in den Cluster geht und _welche Eigenschaften_ diese Dinge haben.

Nun stellt sich die Frage: "Was setzt Helm ein?"

Was ist Helm-Bereitstellung?

Wenn ich helm install release-name ./local_chart ausführe, erwarte ich, dass helm alle Diagrammvorlagen lokal mit den angegebenen Werten rendert (entweder durch Standardeinstellungen oder Überschreibungen) und die gerenderten Versionen in Kubernetes überträgt. Ich erwarte auch, dass Helm die zuvor bereitgestellten Kubernetes-Objekte für den Fall eines Rollbacks behält. Dieses Konzept der „eine Sammlung von Vorlagen gemacht“ (das einige Metadaten enthält) ist ein Release und ist ein Paket. Alle diese Ressourcendefinitionen (auch wenn sie sich nicht geändert haben) müssen sich in _ihrem im Bundle beschriebenen Zustand befinden_, damit das Release existiert (oder auf das zurückgesetzt werden kann).

Daraus vermute ich, dass helm immer nur Pakete wirklich bereitstellt . Es scheint das einzig semantisch richtige zu sein, was Sie sagen können; Der Streit um die Verteilung dieser Pakete scheint jedoch der eigentliche Grund für diese Debatte in der Praxis zu sein. Konkret: "Stellt ein Upgrade oder eine Änderung der App-Version ein neues Paket dar?"

Nach _meiner persönlichen Semantik_ lautet die Antwort auf diese Frage ja . Nach dem Argument, dass Sie die Versionsnummer nicht ändern würden, es sei denn, es würde sich etwas ändern, müssten Sie die Versionsnummer Ihrer Anwendung nur anpassen, wenn sich einige zugrunde liegende Eigenschaften ändern. Dies würde wahrscheinlich das Abrufen eines anderen Docker-Images aus einer Registrierung oder das Festlegen eines Feature-Flags über eine Umgebungsvariable oder eine Reihe verschiedener Praktiken umfassen, die verwendet werden können, um das Verhalten einiger Codeartefakte zu ändern.

Aus diesem Grund habe ich begonnen, unsere Registrierungen zu bereinigen und niemals von :latest bereitzustellen, außer in der Entwicklung. Die Verwendung eines "Meta-Tags" anstelle eines Release-Tags aus einem Docker-Image macht es unmöglich, eine bestimmte Bereitstellung an eine bestimmte Codebasis zu binden. Wir haben dies auf die harte Tour gelernt (aber zum Glück im Test und nicht im Prod).

Welches Muster sollte verwendet werden?

Dies wird bereits von Helm geäußert: Pakete .

Angesichts der Tatsache, dass dieses Muster das erzwungene Muster ist, auch wenn es nicht zu 100% offensichtlich ist, scheint es logisch konsistent zu sein, dass ein --appVersion Flag bereitgestellt wird. Die Beantwortung des "Warums" ist wahrscheinlich wichtiger als alles andere, also lassen Sie mich meinen Beitrag mit dieser Antwort abschließen.

Warum --appVersion unterstützen?

Schauen wir uns einen speziellen Fall der Bereitstellung an:

Ein Unternehmen hat eine Anwendung mit zwei Hauptversionen. Einige Kunden dieses Unternehmens haben sich nicht verpflichtet, auf die neueste Hauptversion dieser Anwendung zu aktualisieren, und verwenden die ältere der beiden. Aufgrund bezahlter Entwicklungsverträge findet die Live-Entwicklung immer noch auf der alten Hauptversion statt... aber das Produkt ist "dasselbe". Die bereitzustellende Infrastruktur für beide Versionen dieser Anwendung ist dieselbe; Die App-Version wird sich jedoch zwischen diesen Bereitstellungen drastisch unterscheiden.

Was soll diese Firma tun?

1. Erstellen Sie zwei separate, fast identische Ruderdiagramme, die sich nur in appVersion ?
2. Verwenden Sie ein Steuerdiagramm, aber aktualisieren Sie ständig appVersion und wechseln Sie zwischen den Hauptversionen der App hin und her?
3. appVersion mit einem Flag überschreiben (derzeit nicht unterstützt), was zu einem möglichen Entwicklerfehler in der Befehlszeile führt?
4. Rescope appVersion aus Chart.yaml und in values.yaml ?

Vorschlag 1 führt etwas mehr Overhead ein als die anderen Vorschläge, hat aber auch den Vorteil, dass die Diagramme für diese Anwendungsversionen getrennt bleiben, wenn sie voneinander abweichen. Es hat einen klaren Anwendungsfall und würde wahrscheinlich in vielen Fällen dieses Problems übernommen.

Vorschlag 2 hat weniger Overhead als Vorschlag 1, führt jedoch zu einer hohen Variabilität in einem Diagramm. Was passiert, wenn Sie helm install release-name https://remote-repo.com/chart ausführen und die aktuellste Version des Diagramms die falsche Version der Anwendung ist? Hoppla. Wahrscheinlich nicht der beste Ansatz.

Vorschlag 3 ist das, was wir derzeit diskutieren. Ich persönlich mag die Option nicht, aber nur, weil ich das Gefühl habe, dass es die falsche Lösung für das Problem ist. Macht es die appVersion konfigurierbar? Sicher. Aber es hat auch das gleiche Problem, auf das Sie stoßen, wenn Sie helm install release-name https://remote-repo/chart ausführen: Die Metadaten sind kurzlebig und werden NUR von Helm verwaltet.

Ich bin eigentlich ziemlich schockiert, dass noch niemand Vorschlag 4 oder ähnliches angeboten hat. Es versetzt die appVersion in einen Zustand, in dem sie überschrieben werden kann (was helm run ähnelt), in dem von helm package generierten Paket enthalten sein kann und das Konzept einer Anwendungsversion wirklich entwirrt von einer Diagrammversion, während das Konzept von appVersion an eine Helm-Bereitstellung gekoppelt bleibt (die appVersion muss irgendwo richtig sein?).

Ich hoffe, dass dies hilfreich war. 👀 diese PR.

@jrkarnes : In gewisser Weise wurde 4) bereits vorgeschlagen und wird von vielen Leuten als Workaround verwendet (siehe hier https://github.com/helm/helm/pull/5492#issuecomment-517255692 ). Sie können so etwas in Ihren Diagrammvorlagen verwenden:

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

Dies würde es Ihnen ermöglichen, appVersion in Charts.yaml als Standard zu verwenden und es mit etwas in Values.yaml zu überschreiben (was während Installations-/Upgrade-Aufrufen überschrieben werden kann). Der Nachteil ist, dass wenn Sie zB ein helm ls machen, Sie entweder kein oder ein falsches appVersion .

@BenjaminSchiborr Danke, dass du mich darüber informiert hast. Wie gesagt, ich bin nur für eine sehr begrenzte Zeit im helm Arbeitsbereich, daher ist jedes Wissen zu diesem Zeitpunkt für mich ein

Ich glaube, dass mein vierter Vorschlag etwas missverstanden wurde. Anstatt etwas wie {{ default .Values.appVersion .Chart.AppVersion}} , würden Sie {{ .Values.Helm.AppVersion}} und das values.yaml enthält appVersion anstelle von Chart.yaml

@jrkarnes
Das denke ich gerade. Warum die App-Version wie eine einzigartige Schneeflocke behandelt werden sollte. Es ist der Wert des Diagramms.

Der Grund dafür ist einfach: Alles ist Teil der Infrastruktur. Infra hat also eine Version. Warum zwei Versionen?

Aber ich bin zu beschäftigt, um meinen Kopf mit Seitenkoffern und Projektionen zu beschäftigen. Aber generell ist das die Frage: Wozu brauchen wir eine App-Version, wenn es kurz gesagt die ganze Infrastruktur ist? oder Können wir die Chart-Version als Infrastruktur-Version verwenden, wenn Chart nur eine Infra-Vorlage ist, und als App-Version, wenn Infra eine App-Version enthält?

Ich werde noch ein bisschen darüber nachdenken

@jrkarnes
Das denke ich gerade. Warum die App-Version wie eine einzigartige Schneeflocke behandelt werden sollte. Es ist der Wert des Diagramms.

Der Grund dafür ist einfach: Alles ist Teil der Infrastruktur. Infra hat also eine Version. Warum zwei Versionen?

Grundsätzlich ist es sinnvoll, die Chartversion von der Applikationsversion zu trennen . Ein kurzes Beispiel ist wahrscheinlich der beste Weg, um zu beweisen, dass dies der Fall ist.

Angenommen, Sie haben eine Anwendung bereitgestellt, die ver 4.0.0 auf Ihrem Diagramm mit der Versionsnummer ver 1.1.0 . Während Ihres Betriebs stellen Sie fest, dass Sie eine Cron-Aufgabe für diese Anwendung ausführen müssen. Anstatt das cronJob-Objekt zu schreiben und auf den Cluster anzuwenden, stellen Sie fest, dass andere Personen, die dieses Diagramm ausführen, wahrscheinlich auch die Cron-Aufgabe benötigen ... also fügen Sie sie Ihrem Diagramm hinzu. Ihr Diagramm ist jetzt zu ver 1.2.0 fortgeschritten, aber es hat keine Änderung an der Anwendung stattgefunden, die das Diagramm verwaltet, es befindet sich immer noch bei ver 4.0.0 .

Auch das Umgekehrte gilt und wird in dieser PR bereits diskutiert.

Aber ich bin zu beschäftigt, um meinen Kopf mit Seitenkoffern und Projektionen zu beschäftigen. Aber generell ist das die Frage: Wozu brauchen wir eine App-Version, wenn es kurz gesagt die ganze Infrastruktur ist? oder Können wir die Chart-Version als Infrastruktur-Version verwenden, wenn Chart nur eine Infra-Vorlage ist, und als App-Version, wenn Infra eine App-Version enthält?

Ich werde noch ein bisschen darüber nachdenken

Anstatt über einen Nebenfall oder eine Projektion nachzudenken, denken Sie an Dinge wie MySql, das drei weit verbreitete und unterstützte Engine-Versionen hat: [5.6, 5.7, 8.0] . Um eine mysql Instanz in einem Cluster bereitzustellen, haben Sie immer Folgendes:

• Ein oder mehrere Pods, auf denen eine Instanz von MySql der ausgewählten Version ausgeführt wird
• Ein Dienst, der die kube-dns-Auflösung für den Pod (oder Pods, wenn er in HA ausgeführt wird) ermöglicht.
• PV(s) in die die Pods ihre Daten mit begleitenden PVC(s) schreiben

Das Diagramm für die Bereitstellung von MySql 5.6, 5.7 oder 8.0 sollte für alle Engine-

Ich verstehe, was Sie damit meinen, sich über den "Bedarf" einer App-Version zu wundern. Ich denke, das hängt von der Bequemlichkeit des Entwicklers oder des Betriebs ab, wenn helm ls oder helm inspect .

+1 an @jrkarnes letzten Beitrag. Es ist sehr wertvoll, Diagramm- und App-Versionen als separate Konzepte zu halten, gerade weil die Diagrammversion die "Infrastrukturversion" ist.

Wenn ich das Diagramm veröffentliche, damit andere es verwenden können, wird es Teil der Infrastruktur für Projekte, die davon abhängig sind. Wenn ich jedoch nie beabsichtige, meine Anwendung von anderen konsumieren zu lassen, ist es mir wichtig, von Zeit zu Zeit meine eigene Chartversion zu überarbeiten, wenn sich die Charts selbst ändern , aber ansonsten muss meine App-Version nur CI-konform sein /CD-Ausgabe. In dieser Art von Nutzungsdiagramm dreht sich relativ selten, aber die App-Version dreht sich bei jedem CI-Vorkommen. Mein Code-Repository behält die Beziehung zwischen dem Code und der Infra-Version bei, die für die Ausführung dieser Codeversion geeignet ist. Mit anderen Worten, anstatt mein Deployment mit helm install last-known-good-chart-version rückgängig zu machen, führe ich einfach meine CD-Pipeline mit einem Zeiger erneut aus zu einer letzten bekannten guten Commit-ID.

@iorlas Ich habe deinen Vorschlag für helm run gelesen und habe keine Probleme damit. Obwohl ich denke, dass die Dichotomie zwischen Installation und Ausführung nicht erforderlich ist , bin ich damit einverstanden, wenn es die Helm-Maintainer beruhigen, die App-Version änderbar zu machen. :)

@iorlas Haben Sie schon einmal darüber

Ich glaube nicht, dass ich verstehe, wie die Problemumgehung mit {{ default .Values.appVersion .Chart.AppVersion}} funktioniert. Ich bekomme diesen Fehler:

Fehler: Fehler beim Konvertieren von YAML in JSON: yaml: ungültiger Kartenschlüssel: map[interface {}]interface {}{".Values.appVersion | default \"0.0.1\"":interface {}(nil)}[

Hier ist meine Chart.yaml:

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

@IRobL Sie müssen dieses Snippet in templates/deployment.yaml einfügen , wo die Version verwendet wird. Dateien wie values.yaml werden nicht als Vorlagen behandelt.

@jrkarnes Ich bin kein Betreuer, also wird das letzte Wort wohl über andere Leute sein, denke ich. Aber egal, ich war in den letzten Wochen ziemlich beschäftigt. In der kommenden Woche werde ich unseren aktuellen Ansatz zur Verwaltung von helm und seinen packages neu bewerten.

Wir verwenden den von mir beschriebenen Ansatz:

• Helm Chart ist ein Teil des App-Repository
• Anwendungserstellung erzeugt:
  
  
  
  • Docker-Image -> Docker-Registrierung
  
  
  • Statische Dateien -> CDN-Dienst
  
  
  • Helm-Paket -> CI-Speicher
  
  
• Das Helm-Paket ist also das Hauptartefakt, das alle Anwendungsartefakte zusammenbindet
• Bei der Bereitstellung sagte install Paket

Aktuelle Bedenken:

• Komplexität des Build-Prozesses.
  
  
  
  • Anstelle von Docker-Image und statischen Dateien wird eine zusätzliche Datei ( helm package ) generiert
  
  
  • Was sind die Hauptgründe, warum wir außer der resultierenden Datei go build / make install noch etwas brauchen?
  
  
  • Was kostet es?
  
  
  • Warum bewerben?
  
  
  • Wann bewerben?
  
  
• Baudauer
  
  
  
  • Auch wenn wir es nicht bereitstellen müssen, verschwenden wir dennoch Zeit und Geld. 2-5 Sekunden. Nicht viel, aber sinnlose Arbeit ist sinnlos.
  
  
• Komplexität von Infrastrukturvorlagenaktualisierungen
  
  
  
  • Wenn das Diagramm aktualisiert wird, sollten auch die Werte aktualisiert werden
  
  
  • Chart ist ein Repo, Werte ein anderes, jede Aktualisierung der Werte bedeutet wenig Kopfschmerzen
  
  

Eine solche Neubewertung könnte zu weiteren Vereinfachungen und Ideen führen. Wir werden sehen :)
Ich werde am nächsten Freitag ein Update senden.

Ah, ich verstehe, warum dieser Trick jetzt nicht funktionieren würde, nachdem Sie mich darauf hingewiesen haben, danke. Hier ist ein Trick, von dem ich denke, dass er für viele Leute, die Helm 2.x verwenden, gut funktioniert, vorausgesetzt, Sie können Ihr Helmwerkzeug bequem mit diesen Arten von Überkopfteilen umwickeln:

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

@IRobL

Wenn Sie eine Bereitstellung mit sed umschließen, bedeutet dies im Allgemeinen, dass eine Templating-Engine nicht das tut, was Sie brauchen, und das ist der springende Punkt dieser Diskussion.

Als gitlab noch in den Kinderschuhen steckte und keine Helm-Unterstützung hatte, haben wir buchstäblich Werte für Ersatzziele in eine handgefertigte Manifestdatei eingefügt.

Es ist eine schlechte Praxis für so etwas und ich möchte Sie dringend bitten, wenn möglich davon Abstand zu nehmen.

Am 7. Oktober 2019 um 15:33 Uhr schrieb IRobL [email protected] :

Ah, ich verstehe, warum dieser Trick jetzt nicht funktionieren würde, nachdem Sie mich darauf hingewiesen haben, danke. Hier ist ein Trick, von dem ich denke, dass er für viele Leute, die Helm 2.x verwenden, gut funktioniert, vorausgesetzt, Sie können Ihr Helmwerkzeug bequem mit diesen Arten von Überkopfteilen umwickeln:

APP_VERSION=0.0.7
sed -i.bak "s/^a ppVersion:. *\\$/appVersion: $APP_VERSION/" helm/Chart.yaml
helm install --name helm_demo helm/
—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

@jrkarnes , wenn Sie schlechte Praxis sagen, sagen Sie, dass es unerwünscht ist, den Befehl helm mit Skripten zu umschließen ? Wenn ja, dann stimme ich voll und ganz zu. Ich sage nicht, dass ich überhaupt gegen das Hinzufügen eines --app-version Flags bin; im Gegenteil, ich denke, das wäre eine sehr bequeme Ergänzung zum Helm. Basierend auf dieser PR bin ich eindeutig nicht die einzige Person, die helm verwendet, die die Variable appVersion konsistent mit dem tatsächlich bereitgestellten Build halten möchte. Ich entwickle gerade eine wiederverwendbare Build-Pipeline-Bibliothek, die verschiedene Build-Tools zusammenfasst, um reproduzierbare Builds zu erstellen – dies ist eine gängige Praxis für große Technologieunternehmen. In meinem Anwendungsfall erstellt die Pipeline-Bibliothek die Docker-Container, veröffentlicht sie und stellt sie schließlich über helm aus der Build-Pipeline der Anwendung bereit (betrachten Sie zum Beispiel die App-Version 1.0.1-pr-3.1 für den ersten Build des dritten PR von eine App, bei der es sich möglicherweise um eine Vorabversion der Version 1.0.1 handelt.

Selbst nachdem dieses Problem in der Build-Pipeline-Bibliothek meines Unternehmens behoben wurde, würde ich mich definitiv wohler fühlen, wenn ein --app-version Switch in Helm integriert ist; es fühlt sich einfach wie eine flexiblere Art an, Bereitstellungen zu handhaben. Ich meine, warum sollte ein externes System oder ein Ingenieur vor jeder Bereitstellung in die Chart-Datei gehen und eine yaml aktualisieren müssen, wenn dies von einer Build-Plattform automatisiert werden kann, die die Zahlen nicht versehentlich durcheinander bringt? Aus meiner Sicht müsste die appVersion-Funktionalität von meiner Organisation vollständig aufgegeben werden, oder die "schlampige" sed Umgehung müsste unserem Pipeline-Bibliothekscode hinzugefügt werden, also dachte ich, ich würde sie für teilen jemand anderen, der dieses Problem gelöst hat.

@IRobL
Im Allgemeinen sollte jedes Dienstprogramm auf seiner eigenen Abstraktionsebene autark sein: Es sollte das Problem, das es löst, durch Bereitstellung einer ausreichenden API abstrahieren. Helm ist keine Ausnahme. Wenn Sie also das Verhalten anpassen müssen, müssen Sie sich zuerst fragen: Entspricht es der Architektur, den Designprinzipien oder vermisse ich vielleicht etwas?

Deshalb war diese PR nicht so einfach zu lösen. Da ist Fix offensichtlich, aber es entspricht nicht dem Helm-Design. Aus diesem Grund werden nur wenige Übergangslösungen angeboten.

Und Sie haben Recht mit dem app-version Flag. Sie sollten es bereitstellen, dann sollte Helm alles selbst erledigen.

Kann ich dir eine Frage stellen? Wie verwenden Sie Helm in Ihrem Produkt? Wenn Sie helm install ? Wie genau verwenden Sie es? Haben Sie überlegt, helm package ?

Gestern Abend habe ich mir helm package . Ich war nicht wirklich davon überzeugt. sed gibt es schon sehr lange und ist sehr stabil. Alle diese tiller / package / install Unterbefehle sind relativ neu und weniger stabil. Um meinen Standpunkt zu artikulieren, habe ich vor Monaten entschieden, dass "Tiller sicher funktionieren könnte", obwohl ich jemandes Plugin gesehen hatte, das die Notwendigkeit von Tiller umgangen hatte. Ich habe das Plugin als etwas angesehen, das weniger Mainstream gewesen sein muss, aber seitdem trete ich mir selbst einen Tritt. Hätte ich dem Plugin vertraut, wäre ich in einer viel besseren Position als jetzt. Die Betreuer von Helm haben sogar bestätigt, dass sie sich einig sind, dass es sich um ein nicht wartbares Design handelte und es in zukünftigen Versionen verschwinden wird.

Ich denke, es wäre ein Fehler meinerseits, helm package für diese einfache Sed-Operation zu verwenden. Was ist Ihr Anwendungsfall für package ? Ich habe das Gefühl, dass das gesamte Konzept von helm package den Sinn von Web 2.0-/Versionskontroll-Releases verfehlt, indem es in eine binäre Zip-Datei verpackt wird, wenn moderne Technologiekonzerne die Leistungsfähigkeit des Taggings nutzen, um denselben Prozess zu erreichen aber schlanker und prüffähiger.

Für meinen Anwendungsfall ermögliche ich App-Entwicklern, ihre containerisierten Anwendungen zu kodifizieren und sie auf eine wartbare Weise bereitzustellen. Daher ist die Minimierung des Overheads (Ops/Tiller-Systemadministratoren, redundantes Release-Artefakt-Management usw.) von größter Bedeutung. Ich denke, meine Verwendung folgt mehr der Unix-Philosophie, um zu entscheiden, ein Tool für das zu verwenden, was es am besten kann, und dann gegebenenfalls auf andere Tools (usw. sed) umzusteigen. Ich glaube nicht, dass Sie jemals ein Tool finden werden, das alles perfekt für Sie erledigt, aber wenn Sie mit Ihrem aktuellen Workflow zufrieden sind, lassen Sie sich nicht davon abhalten, Ihrer eigenen Philosophie zu folgen.

@IRobL

Wenn Sie schlechte Praktiken sagen, meinen Sie damit, dass es unerwünscht ist, den Befehl helm mit Skripten zu umschließen?

Ja. Dies genau.

In meinem Anwendungsfall erstellt die Pipeline-Bibliothek die Docker-Container, veröffentlicht sie und stellt sie schließlich über helm aus der Build-Pipeline der Anwendung bereit

Genau das tun wir auch.

Selbst nachdem dieses Problem in der Build-Pipeline-Bibliothek meines Unternehmens behoben wurde, würde ich mich definitiv wohler fühlen, wenn ein --app-version-Schalter in Helm integriert ist

Ich würde noch einen Schritt weiter gehen und sagen, dass es wahrscheinlich falsch ist, dass appVersion eine Eigenschaft der Datei Chart.yaml ist. Wenn der Wert im Handumdrehen geändert werden kann, sollte er nicht in einem "unveränderlichen Wertesatz" enthalten sein. Ich glaube, ich habe mich in einem früheren Kommentar für dasselbe ausgesprochen.

Alle diese Tiller/Package/Install-Unterbefehle sind relativ neu und weniger stabil.

FWIW, Tiller wird in Helm 3 keine Rolle spielen. Sie haben später in Ihrem Beitrag darauf angespielt; Ich wiederhole dies jedoch nur, weil es zeigt, dass die helm package Syntax zum Erstellen einer "Kubernetes-Binärdatei" und deren Versand an Tiller wahrscheinlich eine schlechte Vorgehensweise ist.

Ich denke, es wäre ein Fehler meinerseits, das Helmpaket für diese einfachen Sed-Operationen zu verwenden. Was ist Ihr Anwendungsfall für das Paket überhaupt?

Ich kann mich hier wahrscheinlich für das Helm-Team einsetzen. Das Gefühl hinter dem Ruder war eine Methode, bei der Anwendungsentwickler angeben, wie ihre Anwendung innerhalb von Kubernetes helm upgrade im Durchschnitt 130 Mal am Tag. Ich glaube, das war nie der Verwendungszweck.

Es war wahrscheinlich viel üblicher, dass Leute sagten: "Ich möchte nur mysql in Kubernetes installieren", und helm war eine (relativ) einfache Möglichkeit, dies für Leute zu tun, die wenig über Kubernetes wussten und nur damit herumspielten.

Somit war helm package letztendlich dafür gedacht, von _diesem Publikum_ konsumiert zu werden. Das Tool wird definitiv in Bereichen verwendet, von denen das Team (glaube ich) entweder nicht glaubte, dass es das Tool aufnehmen würde, oder es nie so verwenden wollte, wie es ist.

Ich denke, meine Verwendung folgt mehr der Unix-Philosophie, um zu entscheiden, ein Tool für das zu verwenden, was es am besten kann, und dann gegebenenfalls auf andere Tools (usw. sed) umzusteigen.

Ich behandle Helm im Grunde wie awk mit einer Menge kubectl apply -f s danach. Es ist einfach viel sauberer, ein automatisiertes Tool zu haben, das sich um Werte kümmert, um menschliche Fehler zu vermeiden.

Klingt so, als ob Sie und ich viele der gleichen Werte haben und möglicherweise viele ähnliche Dinge tun.

@IRobL

Pinne

Für mich ist tiller nicht akzeptabel. Da es einen weiteren Gefährdungspunkt hinzufügt, zusätzliche Sicherheitsrisiken und vor allem nichts anderes tut, als eine weitere Möglichkeit zum Anwenden von yaml-Dateien zu schaffen, jedoch mit einer anderen API. Tiller wurde entwickelt, um den Anwendungsprozess von Helm-Paketen zu sichern und auszurichten, birgt jedoch so viele Risiken, zusätzliche Software (und Versionierung!). Deshalb verwendet Helm der 3. es nicht.

Ich denke, es wäre ein Fehler meinerseits, das Helmpaket für diese einfachen Sed-Operationen zu verwenden.

Ich glaube, du verfehlst meinen Standpunkt. Lass mich es nochmal versuchen. Wofür ist sed gemacht? Um einen Datenstrom zu transformieren. Es sollte das Problem der Transformationen abstrahieren und Ihnen API und Ergebnis für jede gegebene Eingabe liefern.

Was ist, wenn Sie ein Skript erstellen, bei dem Ihr sed Befehl nicht funktioniert (dh Sie haben einen Fehler in Ihrer Regex)? Sie haben also eine Schlussfolgerung gezogen, es funktioniert nicht. Versuchen Sie zu verstehen, warum sed alleine nicht funktioniert, oder würden Sie eine zusätzliche Pipe mit Perl-Skript hinzufügen?

Das Gleiche gilt für jede Lösung: Sie sollte API bereitstellen, Eingaben entgegennehmen und Ausgabe bereitstellen, wodurch ein Problem abstrahiert wird. Weißt du, Unix-Stil.

Es wird auf Helm projiziert und wurde entwickelt, um Ihre Version zu versionieren und in die K8s zu übertragen. Es ermöglicht die Anpassung der Konfiguration mithilfe von Vorlagen. Wenn Sie also ein Problem beobachten, müssen Sie eine Version bereitstellen. Helm bietet einen einfachen Mechanismus zum Verwalten von Versionen und bietet eine einfache Möglichkeit, die Funktionsweise Ihres Builds anzupassen. Warum also nicht versuchen zu verstehen, wie es funktioniert, anstatt einen Workaround mit zusätzlicher Software hinzuzufügen?

@jrkarnes

Ja, wir nähern uns beide dem Ruder mit ähnlichen Interessen. Ich hatte nicht wirklich erkannt, dass die Wurzel des Befehls package mit den Fehlern verflochten ist, die von der Pinne gepflastert wurden. Vielen Dank, dass Sie diese Erkenntnisse mit mir geteilt haben!

Ich habe mir tatsächlich die Geschichte angesehen, warum diese Funktion nicht nur hinzugefügt wurde, und habe zwei Argumente gesehen, warum sie diese Funktion nicht hinzufügen konnten. Das eine war, dass sie, da sie bereits in package sie auch nicht sollten muss es auch in install / upgrade . Ich habe Verständnis dafür, das klingt nach einem technischen Schuldenproblem. Es gibt keine öffentlich genutzte Software ohne technische Schulden. Der andere Grund war, dass die Datei Chart.yml Metadaten enthielt und nicht aktualisiert werden sollte. Das kam mir seltsam vor ... wenn Leute Helm-Charts entwickeln, aktualisieren sie diese Datei sicherlich manuell, wenn sich die Dinge ändern, und daher ist sie selbst nicht unveränderlich. Es ist für mich einfacher, die Datei Chart.yml als eine Möglichkeit zu betrachten, Parameter in die Helm-Binärdatei einzugeben, da sie die Bereitstellungsobjekte erstellt, die im Gegensatz dazu tatsächlich unveränderlich sind.

Was ist übrigens deine Build-Plattform? Der Pipeline-Code, den ich schreibe, wurde für Jenkins als globale Pipeline-Bibliothek geschrieben.

@IRobL Das Hauptproblem ist: Sie betrachten Helm als Bereitstellungsskript. Aber Helm ist nicht so. Helm ist eine Abstraktionsschicht. Helm nimmt alle Ihre Artefakte und wendet sie als eine Arbeitseinheit auf K8s als Plattform an.

Helm ist ein Paketierer. Helm wurde entwickelt, um die Bereitstellung zu erleichtern. Es erstellt "Installer" aus Ihren Artefakten, so dass Sie es auf Ihrem Betriebssystem "installieren" können - K8s.

app-version in install hat nichts mit Tech-Schulden zu tun. Es wird überhaupt nicht benötigt, wenn Sie es install oder upgrade möchten. Das gleiche gilt für Chart.yml . Es sollte überhaupt nicht geändert werden, da es sich um eine Standardkonfigurationsdatei handelt, die eine Version des aktuellen Diagramms enthält, aber Diagramm nicht Ihre Software ist. Du verwendest es nur falsch.

Warum ziehen Sie von diesem Standpunkt aus nicht in Betracht, package ? Sieht dir zu komplex aus oder was?

Ich war bei diesem Thema seit einiger Zeit nicht mehr auf dem Laufenden, aber ich habe diese Art von Punkt ein paar Mal gesehen:

Helm ist ein Paketierer. Helm wurde entwickelt, um die Bereitstellung zu erleichtern. Es erstellt "Installer" aus Ihren Artefakten, so dass Sie es auf Ihrem Betriebssystem "installieren" können - K8s.

Grundsätzlich erstellt Helm _in keiner Weise_ ein Installationsprogramm. Es wird keine "Binärdatei" erstellt. Es erstellt nichts Ähnliches wie eine ".deb"-Datei oder ähnliches. Es erstellt ein Archiv einiger Vorlagen von Kubernetes-Manifesten mit einigen Standard- und/oder voreingestellten Werten. Ihre eigentliche Software lebt nicht in diesem Helm-Diagramm. Es ist nicht mit verpackt. Es kann nicht garantiert werden, dass es unveränderlich ist.

Ich denke, es ist fair zu sagen, dass sich Ihr Helm-Diagramm in den meisten Fällen _viel_ weniger ändert als die Software, die Sie über Ihr Diagramm bereitstellen.

Dies ist der grundlegende Grund (zumindest IMO) dafür, dass --app-version auf helm install und helm upgrade verfügbar ist. Warum sollten Sie Ihr Diagramm erneut verpacken müssen, wenn sich buchstäblich nichts geändert hat?

Ich sehe ein Helm-Diagramm als eine versionierte Beschreibung von Kubernetes-Manifesten, die eine Reihe von Kubernetes-Komponenten beschreibt, die eine Anwendung erfolgreich ausführen, und das ist alles, was ich sehe. Wenn sich diese Anweisungen ändern müssen, möchte ich mein Diagramm aktualisieren - nicht jedes Mal, wenn sich meine Anwendung ändert, und ich muss nur eine Image-Version aktualisieren (die Sie sowieso oft über Werte festlegen).

Schauen Sie sich zum Beispiel Flux an und wie ihr Helm Operator funktioniert. Sie können einen Image-Tag-Wert automatisch aktualisieren lassen. Dadurch wird nicht das Diagramm aktualisiert, sondern nur das bereitgestellte Image-Tag.

Es erstellt ein Archiv einiger Vorlagen von Kubernetes-Manifesten mit einigen Standard- und/oder voreingestellten Werten.

Aber deb file ist der gleiche Satz von Konfigurationsdateien, Befehlen, Manifesten und/oder voreingestellten Werten. Das gleiche wie das MSI-Installationsprogramm oder sogar das nähere Ebuild im gento-emerge-Paketsystem. Ebenso wie Brew-Pakete.

Was also ist der Helm, wenn nicht ein Paketmanager für K8s? Was ist der Unterschied, den Sie sehen?

Es kann nicht garantiert werden, dass es unveränderlich ist.

Warum nicht? Wenn Sie das Paket nach der Paketgenerierung mutieren, ist dies falsch. Wenn Sie während des install/upgrade Prozesses zusätzliche Optionen angeben, ist dies wie bei allen Verpackungssystemen beabsichtigt.

Ich sehe ein Helm-Diagramm als versionierte Beschreibung von Kubernetes-Manifesten

Sie haben bereits einen - GIT. Warum brauchen Sie also einen Helm?

Ich denke, es ist fair zu sagen, dass sich Ihr Helm-Diagramm in den meisten Fällen viel weniger ändern wird als die Software, die Sie über Ihr Diagramm bereitstellen.
Dies ist der grundlegende Grund (zumindest IMO) dafür, dass --app-version bei der Helminstallation und beim Helm-Upgrade verfügbar ist. Warum sollten Sie Ihr Diagramm erneut verpacken müssen, wenn sich buchstäblich nichts geändert hat?

In diesem Design sollte appVersion nicht als Attribut des Helm-Paket-Builds behandelt werden. Es sollte als Konfigurationsparameter in Werten behandelt werden.

Schauen Sie sich zum Beispiel Flux an und wie ihr Helm Operator funktioniert. Sie können einen Image-Tag-Wert automatisch aktualisieren lassen. Dadurch wird nicht das Diagramm aktualisiert, sondern nur das bereitgestellte Image-Tag.

In diesem Fall verlieren Sie die Kopplung von App-Infrastruktur-Manifesten und App-Version. Da das Ändern des Image-Tags kein neues Helm-Upgrade auslöst (korrigiert mich, wenn die Flux-Leute es anders machen). In diesem Fall haben Sie Helm als Konfigurationsvorlage. In diesem Fall brauchen Sie --app-version überhaupt nicht.

Aber deb file ist der gleiche Satz von Konfigurationsdateien, Befehlen, Manifesten und/oder voreingestellten Werten. Das gleiche wie das MSI-Installationsprogramm oder sogar das nähere Ebuild im gento-emerge-Paketsystem. Ebenso wie Brew-Pakete.

In Ihrer Beschreibung hier für .deb und .msi Pakete fehlt eine Schlüsselkomponente - die eigentliche Installation. Wenn Sie sich den Inhalt einer .deb Datei ansehen, finden Sie die erstellte Software - _DIE_ Software, die installiert werden soll. Im Allgemeinen (immer im Fall von .deb ?) ist die bereitgestellte Anwendung intrinsisch verknüpft und Teil dieses Pakets (nicht der Fall bei brew).

Brew-Pakete sind unterschiedlich und nicht wirklich vergleichbar. Brew ist derzeit jedoch Helm viel ähnlicher, da es nur die Anweisungen sind, wie es installiert werden sollte und wo die Quelle / das Paket heruntergeladen werden sollte.

Um hier absolut klar zu sein; ein Helm-Diagramm _ist nicht intrinsisch an eine bestimmte Anwendungsversion gebunden_ und enthält nicht das bereitgestellte Artefakt (dh das Docker-Image). Es enthält nur eine Referenz darauf, und der Wert dahinter kann sich sogar ändern (dh Sie können auf dasselbe Docker-Tag pushen, wenn Sie dies wünschen). Auf jeden Fall ist ein Helm-Diagramm keine Paketversion einer Anwendung und auch nicht strikt mit einer bestimmten Anwendungsversion verknüpft.

Sie müssen sich nur das Stable Charts Repo als Beispiel ansehen. Bei wie vielen Anwendungen können Sie das verwendete Bild über Werte überschreiben? (Viel_)

Was also ist der Helm, wenn nicht ein Paketmanager für K8s? Was ist der Unterschied, den Sie sehen?

Es ist ein Tool, das die Erstellung von Vorlagen für Kubernetes-Manifeste sowie deren einfache Verteilung und Installation erleichtert. Der Schlüssel hier ist, dass Helm sich damit beschäftigt - Kubernetes-Manifeste.

Dies alles kommt auf meinen Hauptpunkt zurück – wenn sich diese Manifeste ändern oder die Vorlagen für diese Manifeste aus irgendeinem Grund geändert werden müssen, dann muss ein Helm-Diagramm wirklich geändert werden.

Die Hauptkomplikation, die ich sehe, ist, dass es 2 Anwendungsfälle gibt:

• Bereitstellung von Drittanbieteranwendungen.
• Bereitstellung von Erstanbieteranwendungen.

Bei Anwendungen von Drittanbietern ist es als Helm-Verbraucher wünschenswert, dass mit jeder neuen Anwendungsversion ein Helm-Diagramm veröffentlicht wird. Ein wesentlicher Unterschied besteht hier in der Häufigkeit der Veröffentlichungen. Es ist wahrscheinlich, dass sich ein Helm-Diagramm eines Drittanbieters für etwas wie MySQL oder was auch immer mehrmals am Tag ändert. In diesem Fall möchten Sie auch nicht versehentlich eine alte Kartenversion mit einer neuen Softwareversion verwenden - ein Fehler, der mit Software und Karten, die Sie nicht selbst geschrieben haben, viel einfacher ist.

Im Fall von Erstanbieteranwendungen haben Sie möglicherweise eine Standardmethode zum Bereitstellen einer Klasse von Anwendungen. Bei Icelolly zum Beispiel schreiben und implementieren wir unsere Go-Dienste alle auf die gleiche Weise. Zu diesem Zweck können wir derzeit tatsächlich ein einziges Diagramm für alle unsere in Kubernetes bereitgestellten Go-Dienste verwenden (wir verwenden derzeit die Problemumgehung von helm package ). Wenn sich unser Ansatz zur Bereitstellung unserer eigenen Anwendungen ändert, aktualisieren wir das Diagramm. Wir versionieren unser Diagramm mit SemVer, sodass die Anwendungen, die nicht aktualisiert werden, nicht betroffen sind, bis wir sie aktualisieren möchten.

Nur auf diese Anmerkung; unser go-service Diagramm wurde zuletzt vor etwa einem Monat aktualisiert. Während dieser Zeit hatten wir wahrscheinlich Dutzende bis Hunderte von Bereitstellungen – alles ohne dass sich dieses Diagramm geändert hätte.

In einem Fall möchten Sie einfach nur Einfachheit. Im anderen Fall wollen Sie Kontrolle und einfache Verwaltung.

In diesem Fall verlieren Sie die Kopplung von App-Infrastruktur-Manifesten und App-Version. Da das Ändern des Image-Tags kein neues Helm-Upgrade auslöst (korrigiert mich, wenn die Flux-Leute es anders machen). In diesem Fall haben Sie Helm als Konfigurationsvorlage. In diesem Fall benötigen Sie --app-version überhaupt nicht.

Flux ändert tatsächlich die Werte, die zum Aktualisieren des Diagramms verwendet werden, und führt dann das Upgrade mit dem neuen Bildwert aus. Ihr Punkt, die Kopplung von Infrastrukturmanifesten und App-Version zu verlieren, bleibt bestehen. Der Punkt, den ich behaupte, ist, dass es in einigen Anwendungsfällen tatsächlich wünschenswert ist, dass dies der Fall ist. Sie haben jedoch Recht, in diesem Anwendungsfall brauche ich --app-version , es würde nicht verwendet, weil es gerade nicht existiert. Wenn ja, könnte Flux es vielleicht gebrauchen. In diesem Fall wäre es tatsächlich hilfreich.

helm list ist ein nützlicher Befehl. Es ist in der Tat immer noch nützlich, zu sehen, welche Anwendungsversionen bereitgestellt werden. Für unsere derzeit über Helm installierten Anwendungen mit dem helm package Ansatz setzen wir nur die Anwendungsversion (über --app-version auf helm package ) so, dass die Ausgabe von helm list ist sinnvoll. Deshalb wäre es für uns einfacher, wenn wir es auf helm install|upgrade setzen könnten. Wir müssten das Diagramm nicht holen und neu verpacken, nur um die Version zu ändern.

Tatsächlich sind helm list und die Handhabung von Rollbacks wahrscheinlich die einzigen Gründe, warum wir Helm überhaupt für Erstanbieter-Software verwenden.

In Ihrer Beschreibung hier für .deb- und .msi-Pakete fehlt eine Schlüsselkomponente - die eigentliche Installation.

"Installieren" ist ein Prozess zum Einrichten der erforderlichen Einrichtungen (Ordner, Konfigurationen, Binärdateien, DB-Abruf, Datenaktualisierung/Migration) auf der Zielplattform.

deb übernimmt das alles. Ebenso das Helm-Paket. Was meinst du damit, dass das Helm-Paket nicht "eigentlich installiert" ist?

Wenn Sie sich den Inhalt einer .deb-Datei ansehen, finden Sie die erstellte Software - DIE Software, die installiert wird.

Falsch. Manchmal finden Sie die Software selbst. Manchmal finden Sie einige Softwareteile. Manchmal finden Sie nur eine Reihe von Skripten, um solche Software abzurufen. Der entscheidende Punkt hier - es spielt keine Rolle , da Linux und K8s Plattformen zum Hosten einer bestimmten Anwendung sind, die ein universelles Anwendungsformat akzeptieren. Und Bildnamen, Konfigurationsparameter - sind die Bestandteile des Pakets.

Brew ist derzeit jedoch Helm viel ähnlicher, da es nur die Anweisungen sind, wie es installiert werden sollte und wo die Quelle / das Paket heruntergeladen werden sollte.

Exakt. Wollen Sie mich überzeugen, dass Brew kein Paketmanager ist?

Um hier absolut klar zu sein; ein Helm Chart _ist nicht intrinsisch an eine bestimmte Anwendungsversion gebunden ...
Bei wie vielen Anwendungen können Sie das verwendete Bild über Werte überschreiben? (Viel)

Du liegst absolut richtig. Helm könnte nicht mehr als eine praktische Templating-Engine für k8s-Templates sein. Ich habe keine Probleme mit einer solchen Software-Existenz: Es hilft ein bisschen, ändert nichts an der modernen Lieferpraxis.

Das Problem ist, dass Helm mehr als nur eine Template-Engine ist. Es ist ein Verpackungsmanager mit allen Vor- und Nachteilen. Und in dem Ökosystem, in dem ein Paketmanager existiert, ist es eine schlechte Praxis, einen anderen Paketmanager zu haben. Schlimmer noch - funktioniert ohne Paketmanager.

Ich sehe die Gründe dafür, die App-Version als Paketargument für diese Pakete zu erstellen. Und ich sehe Gründe, warum Sie und Sie alle keine Pakete machen müssen. Das Problem ist, dass der Ansatz veraltet, komplex und schwieriger zu verwalten ist. Komische Sache, die Kosten sind gering, aber gewinnen Sie es großartig.

Der Punkt, den ich behaupte, ist, dass es in einigen Anwendungsfällen tatsächlich wünschenswert ist, dass dies der Fall ist.

Yup, das ist der zentrale Punkt: Ist es für jedes Produkt wünschenswert?

Ihr Argument ist, dass sich Helm Chart selten ändert, also warum sollten wir es bei jeder Veröffentlichung zusammenpacken. Ich stimme dir zu, es fühlt sich überflüssig an. Aber wie auch immer, wir packen immer noch einige alte Quelldateien, alte Sidecars (wenn Helm aus mehreren Apps besteht), alte Configs, alte Dockerfile.

Die Frage ist also, wenn wir bei jedem Build das gesamte Diagramm als Artefakt verpacken, was ist der Gewinn? Für Dockerfile ist es offensichtlich (aber sicher war es nicht offensichtlich, als die Containerisierung auf dem Markt erschien). Auch für Quelldateien.

Früher hatten wir den klarsten Liefermechanismus: Laden Sie nur geänderte Dateien über FTP hoch. Jetzt haben wir so viele Dinge. Wir müssen entscheiden, was gut ist, warum es gut ist und wer es verwenden soll. Ich bin mir nicht sicher, ob ich glücklich wäre, wenn Helm beide Ansätze gleichzeitig behandelt - zu komplex.

Bereitstellung von Drittanbieteranwendungen.

Ich wäre sooooo glücklich, wenn ich eine PSQL/MySQL-Version ausschließlich mit Helm-Diagramm installieren könnte. Es wäre so viel einfacher, Legacy-Projekte zu pflegen und Neulingen die Infrastruktur vorzustellen. Es ist noch einfacher, über Chart-Updates benachrichtigt zu werden. Warum haben wir so viele tar.gz-Dateien für jede Veröffentlichung für die Binärdateien, können aber nicht denselben Satz von tar.gz-Dateien für Helm-Pakete haben?

@iorlas Ich habe dies und die abgelehnte PR gerade

Aber ich möchte erwähnen, dass ich nicht einmal wusste, dass Helm einen Paketbefehl hat und ich denke, ich bin nicht allein. Das liegt wahrscheinlich daran, dass es einfach so einfach ist, ein Diagramm aus dem Quellverzeichnis zu installieren, aber auch die Dokumentation verkauft das Konzept nicht wirklich oder erklärt es auch nicht im Detail.

Der Paketbefehl ist offensichtlich dokumentiert, aber es gibt nur ein paar sehr allgemeine Erwähnungen von Paketen in der Schnellstartanleitung. Tatsächlich v3-Dokumente überprüft, die eine etwas andere Struktur haben, aber auch kaum vorschlagen, dass Benutzer ihre Diagramme packen.

Normalerweise würde ich gerne eine PR einreichen und nicht nur so klingen, als würde ich mich über etwas beschweren, aber ich bin mir nicht sicher, was mit den 3.0-Dokumentationsänderungen los ist.

@jonstelly Es gibt definitiv eine Lücke in der Dokumentation. Sogar ich dachte zuerst, dass --app-version gut zu gehen ist, aber dann durfte es einfach nicht ohne Grund fehlen.

Dokumente benötigen auf jeden Fall einige Erläuterungen und die Einführung allgemeiner Probleme. Dann Einführung in den Helm-Entwicklungszyklus. Aber ich glaube, das Team ist mit der 3. Version beschäftigt. Und ich bin gerade auch zu beschäftigt :(

"Installieren" ist ein Prozess zum Einrichten der erforderlichen Einrichtungen (Ordner, Konfigurationen, Binärdateien, DB-Abruf, Datenaktualisierung/Migration) auf der Zielplattform.

deb übernimmt das alles. Ebenso das Helm-Paket. Was meinst du damit, dass das Helm-Paket nicht "eigentlich installiert" ist?

Ich meine nicht, dass ein Helm-Diagramm selbst nicht installiert ist - alles, was ich sage, ist, dass das Helm-Diagramm nicht die eigentliche Anwendung enthält, die Sie bereitstellen. Ein Docker-Image wird nicht in ein Helm-Diagramm gepackt. Es wird von Kubernetes aus einer externen Quelle gezogen.

Falsch. Manchmal finden Sie die Software selbst. Manchmal finden Sie einige Softwareteile. Manchmal finden Sie nur eine Reihe von Skripten, um solche Software abzurufen. Der entscheidende Punkt hier - es spielt keine Rolle, da Linux und K8s Plattformen zum Hosten einer bestimmten Anwendung sind, die ein universelles Anwendungsformat akzeptieren. Und Bildnamen, Konfigurationsparameter - sind die Bestandteile des Pakets.

Soweit mir bekannt ist, liegst du hier eigentlich falsch. Eine .deb Datei ist ein AR-Archiv. Sie können es extrahieren und sich den Inhalt ansehen, und letztendlich sind es einige Metadaten und einige Dateien. .deb Dateien könnten theoretisch Patches enthalten, tun dies aber oft nicht. Wenn eine .deb Datei ein Skript zum Abrufen der Software enthält, bedeutet dies, dass das Skript von der .deb Datei installiert wird, nicht die Software selbst. Das ist wie die Installation eines Installers.

Wenn Sie ein Beispiel für eine Linux-Software haben, die in einem .deb Paket verpackt ist, in das .deb geht und die Software herunterlädt, um sie als Teil des Installationsprozesses der .deb Datei zu installieren , dann würde ich es wirklich gerne sehen - da es etwas ist, das ich in vielen Jahren der Verwendung von Linux buchstäblich noch nie zuvor gesehen habe.

Exakt. Wollen Sie mich überzeugen, dass Brew kein Paketmanager ist?

Nein. Ich sage nur, dass die Skripte, die zum Installieren von Software über Brew bereitgestellt werden, wie bei Helm genau das sind - Skripte. Die Anwendungen werden separat erstellt, verpackt und verteilt und von diesen Skripten abgerufen. Das macht Brew nicht weniger zu einem Paketmanager, genauso wie das, was ich gesagt habe, Helm nicht weniger zu einem Kubernetes-Paketmanager macht. Das ist jedoch nicht der Sinn dieses Problems, wir diskutieren nicht, ob Helm ein Paketmanager ist oder nicht, wir versuchen zu entscheiden, ob ein --app-version Flag zu helm install|upgrade hinzugefügt werden sollte oder nicht.

Ich sehe die Gründe dafür, die App-Version als Paketargument für diese Pakete zu erstellen. Und ich sehe Gründe, warum Sie und Sie alle keine Pakete machen müssen. Das Problem ist, dass der Ansatz veraltet, komplex und schwieriger zu verwalten ist. Komische Sache, die Kosten sind gering, aber gewinnen Sie es großartig.

Entschuldigung, mir ist nicht klar, was Sie damit meinen. Was ist veraltet / komplex / schwieriger zu verwalten?

Die Frage ist also, wenn wir bei jedem Build das gesamte Diagramm als Artefakt verpacken, was ist der Gewinn? Für Dockerfile ist es offensichtlich (aber sicher war es nicht offensichtlich, als die Containerisierung auf dem Markt erschien). Auch für Quelldateien.

Der Unterschied besteht im Wesentlichen darin, dass all diese Dinge, die Sie erwähnt haben, untrennbar miteinander verbunden sind. Sie benötigen den gesamten Quellcode, um die App auszuführen – nicht nur, was sich geändert hat. Sie packen das Dockerfile nicht, sind sich also nicht sicher, worum es geht - aber Sie werden oft dasselbe Dockerfile verwenden, ohne es zu ändern, um neue Versionen von Images zu erstellen (ich meine, warum sich mit Automatisierung beschäftigen, wenn Sie jedes Mal etwas manuell ändern müssen? Zeit, oder?). Mit all diesem Zeug erstellen Sie etwas, das alles kapselt, was Sie brauchen, sodass es isoliert bereitgestellt werden kann. Sie können also beispielsweise einen neuen Knoten erstellen und ihn auf die gleiche Weise bereitstellen wie einen vorhandenen Knoten usw.

Es gibt _viele_ Vergünstigungen, wie Sie sicher bereits wissen, gegenüber der Verwendung des alten Uploads über FTP.

Wie auch immer, das ist alles nebenbei. Ich denke, wie ich bereits erwähnt habe, ist meiner Meinung nach alles, was dabei herauskommt; Wollen die Helm-Maintainer diesen anderen Anwendungsfall ermöglichen oder es den Leuten erschweren, ihn auf diese Weise zu verwenden? Letztendlich ist es _wirklich_ kein großer Unterschied. Für mich wäre es einfach schön, wenn ich nicht unser internes Diagramm, das sich selten ändert, bei jedem Build zusammenpacken müsste, nur um eine Anwendungsversion festzulegen, die wiederum nur verwendet wird, um die aktuelle Version in einer Liste anzuzeigen. Bei First-Party-Apps habe ich mich ehrlich gesagt gefragt, ob Helm sowieso der richtige Ansatz ist.

Ein Docker-Image ist nicht in ein Helm-Diagramm verpackt

Eigentlich wünschte ich, es wäre so. Aber es ist jetzt nicht so. Meine Vision ist, K8s wird/sollte eine Plattform sein, die Helm (also kein Helm) als API zum Installieren von Paketen integriert: Sie müssen Ihre Sachen in das Archiv packen und installieren. Zurück zur Einfachheit der deb-Dateien, aber mit angemessener Isolierung und k8s-Ressourcen als erstklassige Bürger.

Eine .deb-Datei ist ein AR-Archiv
Sie können es extrahieren und sich den Inhalt ansehen
und letztendlich sind es einige Metadaten
und einige Dateien

Wie .... ein Helm-Paket!

Wenn Sie ... eine .deb-Datei haben, in die die .deb-Datei verschoben wird und die Software herunterlädt, die als Teil des Installationsprozesses der .deb-Datei installiert werden soll ...
Das ist wie die Installation eines Installers. ...

Ja, es wäre wie ein Installer, der einen Installer enthält. Lustig, richtig? Ich würde ein Artefakt verwenden, wenn es möglich ist , wenn es ausreichen würde, um eine App-Instanz einzurichten. Aber wir haben unterschiedliche Software, verschiedene Quellen der Wahrheit, manchmal ist es sogar praktisch, mehrere Quellen zu haben.

• Brew hat YAML als Paket, ruft aber Binärdateien aus dem Remote-Speicher ab
• Emerge(gentoo) hat Ebuild als Definition, die sogar Git-Klone herunterlädt

Debian versucht, alles darin zu verpacken. Und es ist richtig, wenn möglich. Aber um meinen Standpunkt zu beweisen, reichen Metapakete aus . Hast du davon gehört? Es ist ein Paket, das einige andere Pakete installiert. Ist es nicht ein Paket?

Aber bitte vergiss das Wesentliche nicht: Es spielt keine Rolle ! Sogar ein leeres Paket, das nur eine Referenz enthält, ist ein Paket. Vielleicht würden Sie einen anderen Begriff akzeptieren, Installateur?

Ich sage, dass die Skripte, die zum Installieren von Software über Brew bereitgestellt werden, wie bei Helm genau das sind - Skripte
Die Anwendungen werden separat erstellt, gepackt und verteilt und von diesen Skripten abgerufen

Und wir haben alle dieselbe Pipeline - um ein Docker-Image zu erstellen.

wir versuchen zu entscheiden, ob ein --app-version-Flag zu helm install|upgrade hinzugefügt werden sollte oder nicht, um einen gemeinsamen Anwendungsfall zu erleichtern.

Das ist ein Schlüssel. Aber wie können wir uns entscheiden? Wir sollten uns zwei Fragen stellen:

• Ist es möglich? ja
• Ist es richtig? Ja? Nein?

Wenn es Leute gibt, die etwas tun, bedeutet das, dass es eine gute Sache ist? Um Fortschritte zu machen, müssen wir alles hinterfragen.

Entschuldigung, mir ist nicht klar, was Sie damit meinen. Was ist veraltet / komplex / schwieriger zu verwalten?

auf Brew projizieren lassen, da Brew sehr nah am Helm liegt und bereits weit verbreitet und erfolgreich eingesetzt wird. Sie können auf Gentroo Ebuilds oder deb projizieren, das Bild ändert sich nicht.

• Veraltet. Wann mussten Sie MySQL/PSQL das letzte Mal manuell installieren? Warum haben wir uns davon entfernt? Diese Gründe, Kumpel.
• Komplex. Dies ist eines der „Warum“: Sie müssen die Infrastruktur unabhängig einrichten, Sie müssen wissen, welche mit welchen Softwareversionen am besten funktioniert. Manchmal müssen Sie die Infrastruktur anpassen, um eine bestimmte Softwareversion auszuführen. Warum die Mühe? Warum delegieren Sie nicht die ganze Frage?
• Schwieriger zu handhaben. Sie müssen sowohl die Infrastruktur- als auch die App-Version verwalten, wenn Sie nur ein Artefakt haben könnten. Warum dir das Leben schwerer machen?

Entschuldigung, im Moment ist es etwas faul, alle Anwendungsfälle zu beschreiben, wie saubere Rollbacks, anmutige Upgrades, dies sind sowieso die Hauptboni.

Der Unterschied besteht im Wesentlichen darin, dass all diese Dinge, die Sie erwähnt haben, untrennbar miteinander verbunden sind.

Nicht immer. Docker-Image könnte beispielsweise SSR BE und einen Verweis auf CDN aufweisen.

Dockerfile, also nicht sicher, worum es bei diesem Punkt geht - aber Sie werden oft dasselbe Dockerfile verwenden, ohne es zu ändern, um neue Versionen von Images zu erstellen (ich meine, warum sich die Mühe mit der Automatisierung machen, wenn Sie jedes Mal etwas manuell ändern müssen, oder?).

Das ist der Punkt. Auch wenn Dockerfile nicht geändert wird, erstellen Sie ein neues Image. Wenn Ihr Quellcode nicht geändert wird, Dockerfile jedoch, erstellen Sie ein neues Image. Kurz gesagt, Dockerfile ist auch ein Paket. Gleiches gilt für Helm. Meinst du nicht?

Mit all diesem Zeug erstellen Sie etwas, das alles kapselt, was Sie brauchen, sodass es isoliert bereitgestellt werden kann. Sie können also beispielsweise einen neuen Knoten erstellen und ihn auf die gleiche Weise bereitstellen wie einen vorhandenen Knoten usw.

Aber es stellt sich heraus, dass das Docker-Image nicht ausreicht, um eine App auszuführen. Wir brauchen eine Konfigurationsinstanz, wir brauchen Service-Definitionen. Warum nicht alles verpacken?

Letztendlich ist es auch kein wirklich großer Unterschied.

Ich glaube, das ist es. Vielleicht ist es in der Codebasis nicht viel von der Sache, aber es wird die Entwicklung der Containerisierung stagnieren.

Ein Docker-Image ist nicht in ein Helm-Diagramm verpackt

Das Bild selbst ist nicht verpackt, aber die Referenz (gelesen als: Pin). Sicher, wir können pedantisch sein und uns darüber aufregen, ob das wörtliche Bild unterschiedlicher Größe (von MBs bis GBs) im Artefakt von helm package ist oder nicht (Spoiler: ist es nicht), aber die Essenz der Aussage "Eine bestimmte Version des Codes einer Anwendung ist in einem Helm-Paket enthalten" ist immer noch grundsätzlich richtig. Ob Sie sich im Wie verfangen wollen oder nicht, ist irrelevant.

Kehren wir zum Land der Beispiele zurück. Nehmen wir an, Sie haben eine Anwendung, die Sie intern als 1.9.9 versioniert haben und die auf einem Diagramm mit der Versionsnummer 1.2.5 . Damit es nicht zu Verwechslungen kommt, lautet das Docker-Image-Sha für den Anwendungscontainer fakeshaA .

Ihr Team entscheidet, dass es in Version 2.0.0 Ihrer Anwendung eine lokale Dateisystemversion einer Datei geben wird, auf die Sie früher über HTTP verweisen mussten. Der Grund dafür ist unwichtig, aber die Konsequenzen für Sie sind ziemlich schwerwiegend. Jetzt benötigen Sie ein pv und ein pvc für Ihre Bereitstellungen, damit diese jetzt lokalen Dateien zwischen Upgrades nicht verloren gehen. Wenn Sie die Notwendigkeit erkennen, aktualisieren Sie Ihr Helm-Diagramm, um diese pv und pvc damit der Wechsel zu 2.0.0 nicht sehr störend ist.

Bevor Sie das Diagramm ändern, müssen Sie Artifact A die Anwendungsversion 1.9.9 mit der Infrastrukturversion 1.2.5 verknüpfen. Jetzt ändern Sie das Diagramm... _Ihr Helm-Diagramm ist jetzt v. 1.3.0 _ und Sie erzeugen ein Artefakt, das 1.9.9 mit der Infrastrukturversion 1.3.0 verknüpft. Wir nennen das Artifact B

Wenn die Codebereitstellung für 2.0.0 mit dem Docker-Image sha fakeShaB live geht, erstellen Sie ein weiteres Artefakt, das 2.0.0 mit der Infrarotversion 1.3.0 verknüpft. Das ist Artifact C

Nehmen wir nun an, es stellt sich heraus, dass es ein Problem gibt, das Sie mit der Version 2.0.0 nicht vollständig verstehen und Sie ein Rollback durchführen müssen. Sie führen einen Rollback mit Artifact B ... aber das löst das Problem nicht, also machen Sie einen Rollback auf Artifact A und das Problem ist gelöst.

Das einzige Problem, auf das Sie stoßen, ist, ob die Docker-Registrierung, auf die Ihre Artefakte verweisen, noch das Bild enthält, auf das in diesen Artefakten verwiesen wird.

Egal was passiert, Sie haben immer noch eine Verbindung zwischen einer Version einer Anwendung und einer Version der Infrastruktur . Dies ist der Zweck von Helm. Anders zu argumentieren ist töricht.

@iolas :

Lassen Sie uns die .deb Vergleiche beiseite legen. Ich denke, wir werden nur abgelenkt.

Nicht immer. Docker-Image könnte beispielsweise SSR BE und einen Verweis auf CDN aufweisen.

Das ist wirklich wahr. Dazu aber später mehr.

Das ist der Punkt. Auch wenn Dockerfile nicht geändert wird, erstellen Sie ein neues Image. Wenn Ihr Quellcode nicht geändert wird, Dockerfile jedoch, erstellen Sie ein neues Image. Kurz gesagt, Dockerfile ist auch ein Paket. Gleiches gilt für Helm. Meinst du nicht?

Sie tun es, aber das liegt daran, dass das Produkt am Ende dieses Build-Prozesses (dh ein Docker-Image) von _sowohl_ der Dockerfile als auch von dem, was Sie darin einfügen, abhängt. Ein Bild kann ohne diese beiden Komponenten nicht existieren.

Auf der anderen Seite kann ein Helm-Diagramm existieren, bevor eine Anwendung überhaupt erstellt wird - buchstäblich bevor eine einzige Codezeile geschrieben wird. Sie könnten ein imaginäres Diagramm erstellen, das sich nicht installieren lässt – aber dennoch könnte das Helm-Diagramm ganz ohne etwas anderes existieren. Wie gesagt, das wäre nutzlos, aber ich versuche nur zu veranschaulichen, dass sie überhaupt nicht miteinander verbunden sind.

Mein Punkt hier und in Bezug auf dieses spezielle Problem ist nur, dass Helm-Diagramme nicht immer untrennbar mit den Anwendungen verbunden sind, die vom Diagramm bereitgestellt werden. Ich glaube nicht, dass das eine kühne Behauptung ist, es passiert - es ist bereits Tatsache. Ich mache es gerade mit Produktionsanwendungen, ebenso wie andere, die sich zu diesem Problem geäußert haben. Wie ich bereits sagte, läuft alles darauf hinaus; wollen die Helm-Maintainer diesen Anwendungsfall aktivieren oder nicht - es gibt nichts anderes.

Aber es stellt sich heraus, dass das Docker-Image nicht ausreicht, um eine App auszuführen. Wir brauchen eine Konfigurationsinstanz, wir brauchen Service-Definitionen. Warum nicht alles verpacken?

Eigentlich wünschte ich, es wäre so. Aber es ist jetzt nicht so.

Wenn dies der Fall wäre und ein Helm-Diagramm tatsächlich alles verpackt hat, was es bereitgestellt hat (Sie erwähnen CDN vorhin, aber Sie stellen das dann nicht für Kubernetes bereit, also würde es noch nicht einmal in Ihrem Diagramm erscheinen), dann denke ich, dass dieses Gespräch würde nicht stattfinden. Ihr Helm-Diagramm _wäre_ intrinsisch mit der bereitgestellten Anwendungsversion verknüpft - genau wie beim Erstellen eines Docker-Images. Ein Helm - Diagramm in diesem Szenario bauen Sie es erforderlich wären , neu zu erstellen , wenn die Anwendung ändert, bei der keine Frage gibt es zeigen. Sie könnten Helm nicht so verwenden, wie ich es heute benutze - so wäre es viel klarer.

Das ist jedoch nicht die Realität. So funktioniert Helm nicht, und ich weiß nicht, ob es jemals wirklich so sein wird. Aber sag niemals nie, oder?

@jrkarnes :

Das Bild selbst ist nicht verpackt, aber die Referenz (gelesen als: Pin).

Sicher, aber ein häufiger Anwendungsfall ist die Verwendung von Werten, um diesen Wert zu überschreiben. Ich habe es sowohl mit Charts von Drittanbietern als auch von Erstanbietern verwendet. Es wäre keine Option, wenn es nicht etwas wäre, das die Leute benutzten.

Sicher, wir können pedantisch sein und uns darüber informieren, ob das wörtliche Bild unterschiedlicher Größe (von MBs bis GBs) im Artefakt des Helmpakets enthalten ist oder nicht (Spoiler: ist es nicht).

Ich glaube nicht, dass wir bei irgendetwas pedantisch sind - wie Sie bereits erwähnt haben, wäre es sachlich falsch zu sagen, dass das Docker-Image in einem "gebauten" Helm-Diagramm verpackt ist.

"Eine bestimmte Version des Codes einer Anwendung ist in einem Helm-Paket enthalten" ist immer noch grundsätzlich richtig.

Aber nicht wirklich, da mein erster Punkt dagegen sprechen würde. Sie können ändern, was bereitgestellt wird. Verdammt, Sie können die meisten Diagramme ändern, um das hello-world Bild auszuführen, wenn Sie möchten. Das wäre nutzlos, aber es beweist gut meinen Standpunkt - das Helm-Diagramm ist nicht mit Ihrer Bewerbung verknüpft. Es gibt eine _Erwartung_, dass Sie es mit dem richtigen Bild verwenden, und wahrscheinlich wird es standardmäßig funktionieren, aber es _muss es sicherlich nicht_ - und _auf keinen Fall_ ist der Code der Anwendung in einem Helm-Diagramm enthalten, anders verpackt.

Zurück ins Land der Beispiele, [...] und das Problem ist gelöst.

Sie haben es so klingen lassen, als wäre dies nicht möglich, ohne Helm so zu verwenden, wie es anscheinend derzeit beabsichtigt ist. Aber in Wirklichkeit können Sie nur 2 Versionen des Diagramms (dh Ihre beiden Infrastrukturversionen) und 3 Versionen Ihrer Anwendung haben. Wenn Sie ein Rollback durchführen möchten, können Sie ganz einfach auswählen, welche Diagramme und Bilder Sie bereitstellen möchten. Führen Sie Helm mit Ihrem Diagramm aus, legen Sie Ihre Werte für das Bild entsprechend fest, und Sie sind fertig.

Egal was passiert, Sie haben immer noch eine Verbindung zwischen einer Version einer Anwendung und einer Version der Infrastruktur. Dies ist der Zweck von Helm. Anders zu argumentieren ist töricht.

Ich denke, zu argumentieren (idealerweise zu diskutieren), wie sich Dinge ändern könnten, führt oft zu einer Verbesserung. Ich glaube nicht, dass der "Zweck" von Helm darin besteht, eine Diagramm- und Anwendungsversion zu verknüpfen. Ich denke, der Zweck besteht darin, die Bereitstellung von Anwendungen in einem Kubernetes-Cluster einfacher und sicherer zu machen, während Ihre Kubernetes-Manifeste DRY und wiederverwendbar bleiben. Nirgendwo müssen Sie eine Chart- und eine Anwendungsversion strikt miteinander verknüpfen (genau wie in der Realität jetzt brauchen Sie sie nicht).

Also, wie ich @iorlas gesagt

... das Produkt am Ende dieses Build-Prozesses (dh ein Docker-Image) hängt sowohl von der Docker-Datei als auch von dem ab, was Sie darin einfügen. ... Ein Bild kann ohne diese beiden Komponenten nicht existieren.

Also... Helm-Paket benötigt Chart- und App-Version (= Docker-Image) und kann ohne sie nicht existieren.

ein Helm-Diagramm kann existieren, bevor eine Anwendung überhaupt erstellt wird - buchstäblich bevor eine einzige Codezeile geschrieben wird. ... die Helmkarte könnte ganz ohne etwas anderes existieren. Wie gesagt, das wäre nutzlos

Das Lustige ist, dass wir in einem Projekt Stub-Docker-Images verwendet haben, um eine Prototyparchitektur zu erstellen. Wir haben Charts buchstäblich verwendet, ohne eine einzige Codezeile zu schreiben. Außerdem ist es immer praktikabel, ein Diagramm zu haben, das nur aus Unterdiagrammen besteht.

Meine Hypothese ist also : Helm-Paket ist ohne Docker-Image fast nutzlos. Docker-Image ist ohne Quellcode fast nutzlos. Der Unterschied ist eine Abstraktionsebene. Beide Dinge sind paketähnliche Objekte .

aber ich versuche nur, meinen Standpunkt zu veranschaulichen, dass sie überhaupt nicht miteinander verbunden sind.

Ja, ja! Das ist wirklich schön, wir haben Leute bereit, um alles bis ins Detail zu besprechen. Ohne dich, ohne Projektionen und Behauptungen, werden wir keine Zukunftswürze leben

Ich glaube nicht, dass das eine kühne Behauptung ist, es passiert - es ist bereits Tatsache. ... Wie ich bereits sagte, kommt es nur darauf an; wollen die Helm-Maintainer diesen Anwendungsfall aktivieren oder nicht - es gibt nichts anderes.

Tatsache. Um eine solche Änderung vorzunehmen und zu akzeptieren, sollte sie bewertet werden: Ist dies richtig ?

Lass mich dir eine Geschichte erzählen. Martini war ein großartiges, weit verbreitetes Web-Framework. Der Grund war nicht der Mangel an Stunden zum Investieren, der Grund waren nicht irgendwelche Spielereien mit Lizenzen. Die einzige Möglichkeit, die Zukunft besser zu machen, bestand darin, das gesamte Framework abzuschaffen, einige Leute wütend zu machen, einige Projekte verwaist zu lassen und einige Leute zu zwingen, ihre Aktivitäten neu zu bewerten.

Also, ich bin nicht so gegen diesen Ansatz. Ich sehe, wie es leben kann (siehe meinen Vorschlag mit helm run ). Aber obwohl wir die Möglichkeit haben, einzugreifen und möglicherweise die ganze Branche zu reparieren, solange es noch nicht zu spät ist, würde ich jede Nutzung bewerten und alle Nachteile und Probleme diskutieren.

Um in diesem Szenario ein Helm-Diagramm zu erstellen, müssen Sie es neu erstellen, wenn sich Ihre Anwendung ändert.

Jep. Auch jetzt könnte es ein Fall sein. Wir haben eine Pipeline, in der wir anstelle von push save / load des Docker-Images erstellen. Und es funktioniert ganz gut. Ich habe gerade keine Lust dazu, aber im Grunde ist es viel sauberer. Das Problem ist, dass K8s immer noch eine Remote-Docker-Registrierung als Bus benötigen, um das "Starter" - Docker-Image zu übertragen.

Lasst uns unseren Fokus eingrenzen, Leute

Ihr Helm-Diagramm wäre untrennbar mit der bereitgestellten Anwendungsversion verknüpft – genau wie beim Erstellen eines Docker-Images.

Dies ist hier ein wesentlicher Unterschied. Und @seeruk hat es geschafft. Und wir können uns darauf konzentrieren. Lassen Sie es mich in die Fakten umschreiben:

1. Docker-Image ist nicht an das Helm-Paket gebunden. Nur darauf verweisen.
2. Dies gibt die Möglichkeit, diese Pfade unabhängig freizugeben.

Schlüsselfrage:

1. Welche Risiken birgt eine unabhängige Vorgehensweise? (dh was, wenn einige Entwickler es verwenden, welche Argumente werden wir dagegen sagen)
2. Wie der Verpackungsansatz das löst?
3. Was kostet es?
4. Wie sehen wir in dieser speziellen Frage eine Zukunft der Containerisierung?

@seeruk :

Also, wie ich @iorlas gesagt

Du machst viele tolle Klarstellungen und Punkte. Ich persönlich denke, Helm sollte sich anpassen. CI/CD ist die Zukunft, wie Software erstellt wird, und ehrlich gesagt, mit Leckereien wie --atomic helm als zuverlässiges Bereitstellungstool bereits flexibler. Dieses Thema ist jedoch ziemlich alt, daher denke ich, dass die Zusammenführung dieser PR nicht der "nächste Schritt" in diesem Prozess ist.

Wäre die Erstellung eines Plugins, beispielsweise helm-ci-cd , für diese spezielle --app-version Funktion machbar ( helm-ci-cd des Aussehen install/ upgrade Dualität , dass wir CI / CD ppl bereits über Verpackung vereinigt hat.

Auch wenn der --app-version Schalter kein direkter Mehrwert für die Endbenutzer ist, die versuchen, eine k8s-App zu installieren, ohne sich die Vorlagendateien ansehen zu müssen (was übrigens nie wirklich geklappt hat ich, weil ich Netzwerkrichtlinien hinzufügen muss, um mit meiner Arbeits-K8s-Infrastruktur konform zu sein) gewinnt der Endbenutzer immer noch mehr Wert, weil die Person, die dieses Diagramm erstellt hat, es aufgrund der helm ci/cd-Funktionen, die das Erstellen stabil machen, einfacher hatte und zuverlässige Software einfacher.

Wir lesen einfach die Chart.yaml mit groovy ein, legen dann die App-Version fest und überschreiben die Datei während der Bereitstellungszeit. Führen Sie dann das Helm-Upgrade durch. Es wäre schön, wenn es ein Teil von Helm wäre, aber ich würde nicht darauf zählen.

Habe das über Google gefunden. Eigentlich dasselbe Boot.

Wenn verison: die Diagrammversion ist, bedeutet dies, dass sich diese Version ändert, wenn sich die YAMLs des Diagramms ändern. Da ein Diagramm eine Vorlage mit konfigurierbaren Werten ist, können Sie davon ausgehen, dass Sie Diagramm 1.3 verwenden können, um Apps mehrerer Versionen, 1.2, 1.3, 1.6, 1.8 usw. bereitzustellen, ohne die YAML-Dateien des Diagramms ändern zu müssen.

Kommt jetzt in appVersion: das in Chart.yaml fest codiert ist – und zwingt Sie, eine Diagrammdatei zu bearbeiten, um die Version der bereitgestellten Anwendung zu aktualisieren (und wiederzugeben).

Es ist definitiv eine --app-version CLI-Option erforderlich, die wir in den Diagrammvorlagen verwenden können, um auf die Version der _Anwendung_ zu verweisen, um verschiedene Versionen mit demselben version: 1.3.0 Diagramm bereitzustellen.

@seeruk

Ich glaube nicht, dass der "Zweck" von Helm darin besteht, eine Diagramm- und Anwendungsversion zu verknüpfen. Ich denke, der Zweck besteht darin, die Bereitstellung von Anwendungen in einem Kubernetes-Cluster einfacher und sicherer zu machen, während Ihre Kubernetes-Manifeste DRY und wiederverwendbar bleiben.

Das ist unser Streitpunkt und ich glaube nicht, dass einer von uns den anderen überzeugen wird. Manchmal ist es in einem professionellen Umfeld _okay_, unüberbrückbare Meinungsverschiedenheiten zu haben. Ich stimme sicherlich nicht allem zu, was Stallman sagt, und wenn wir bei allem, worüber er und ich uns nicht einig sind, in die Gräben geraten würden, würden wir sterben, bevor wir einen Konsens gefunden haben.

Ich habe es weiter oben in der Diskussion gesagt und ich denke, es muss wiederholt werden:

[...] Ich vermute, dass helm immer nur Pakete wirklich bereitstellt. Es scheint das einzig semantisch richtige zu sein, was Sie sagen können; Der Streit um die Verteilung dieser Pakete scheint jedoch der eigentliche Grund für diese Debatte in der Praxis zu sein. Konkret: "Stellt ein Upgrade oder eine Änderung der App-Version ein neues Paket dar?"

Ein Helm-Diagramm eines Erstanbieters (ich verwende gerne MySQL, daher werde ich es weiterhin verwenden) ohne Konfiguration sollte eine Ressource in einem Cluster installieren, wie der Diagrammersteller es beschrieben und beabsichtigt hat . Wenn man sich das eigentliche Diagramm für MySQL ansieht, gibt es zwei Eigenschaften, die mit der eigentlichen MySQL-Engine konfigurierbar sind:

• image (Standard mysql )
• imageTag (Standard 5.7.14 )

Dann in ihrer Chart.yaml Datei:

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

Beachten Sie, dass appVersion und der Standardwert imageTag nicht übereinstimmen . Wenn ich helm list ausführe, erhalte ich einen Bericht, dass die "App-Version" (gelesen; Engine-Version) ein Zustand ist, _der nicht die tatsächliche App-Version widerspiegelt, die im Cluster installiert ist_.

Nirgendwo müssen Sie eine Chart- und eine Anwendungsversion strikt miteinander verknüpfen (genau wie in der Realität jetzt brauchen Sie sie nicht).

Das ist richtig; und meiner Meinung nach ein Konstruktionsfehler.

Also, wie ich @iorlas gesagt

Ja. Ich werde gleich auf einige Vorschläge eingehen.

@IRobL

Wäre die Erstellung eines Plugins, beispielsweise helm-ci-cd, für diese spezielle --app-version-Funktion möglich ( @jrkarnes kann wahrscheinlich als PR-Mitarbeiter mit diesem sprechen)?

Sie beantworten Ihre eigene Frage mit:

Auch wenn der Schalter --app-version kein direkter Mehrwert für die Endbenutzer ist, die versuchen, eine k8s-App zu installieren, ohne sich die Vorlagendateien ansehen zu müssen, erhält der Endbenutzer immer noch mehr Wert, da die Person, die Das Erstellen dieses Diagramms hatte es aufgrund der helm ci/cd-Funktionen, die das Erstellen stabiler und zuverlässiger Software einfacher machen, einfacher.

Wenn wir es als Plugin tun müssen, um die Funktion richtig zu machen, dann würde ich für diesen Ansatz plädieren; Ich denke jedoch, dass das das falsche Problem anspricht. Wie ich bereits zu @seeruk sagte, Konstruktionsfehler ist, dass appVersion eine intrinsische Eigenschaft in der unveränderlichen Chart.yaml Datei ist. appVersion ist eine Eigenschaft von image , die über das Diagramm im Cluster installiert wird, und wird in irgendeiner Weise von dem mit tag referenzierten Bild abgeleitet.

Wenn Sie an ein helm-ci Plugin denken, welche anderen Funktionen oder Add-Ins würden Sie erwarten? Ich glaube nicht, dass das einfache Umschalten der appVersion aus den unveränderlichen Chart.yaml Eigenschaften einen Mehrwert darstellt, um zu rechtfertigen, dass es sich um ein Plugin handelt.

@IRobL und @seeruk zusammen:

Ich denke, unsere unterschiedlichen Meinungen stammen von dem, was wir als den häufigsten Endbenutzer von Helm ansehen. Wenn der Endbenutzer jemand sein soll, der nicht viel konfigurieren oder in Vorlagen graben wird, dann ist helm ls möglicherweise nicht besonders nützlich und der Punkt ist strittig.

Wenn Sie jedoch helm als Verwaltungstool und Assistent zum Verwalten eines Clusters verwenden ODER wenn Sie Helm eher in einem CI/CD-Kontext verwenden, dann ist der Schalter --appVersion viel zu viel nützlicher und daher ein Punkt der Besorgnis (und Konfiguration),

In einer perfekten Welt würde ich behaupten, dass appVersion eine abgeleitete Eigenschaft sein sollte und aus Docker-Image-Metadaten stammen sollte; das ist für helm nicht machbar, ergo, der fehlende streit.

Zu dem, was ich gesagt habe

Ja. Ich werde gleich auf einige Vorschläge eingehen...
... wenn Sie an ein helm-ci Plugin denken, welche anderen Funktionen oder Add-Ins würden Sie erwarten?

Ich habe eine persönliche Liste, die ein guter Ausgangspunkt sein könnte:

• Das Ausführen von helm im CICD Modus würde nicht _nur_ den Status von zuvor veröffentlichten Paketen mit dem, was derzeit angewendet wird, vergleichen. . Stattdessen würde jede Bereitstellung eines Releases jedes Manifest vollständig anwenden, das als Vorlage erstellt wurde, wenn upgrade wird.
• helm-cicd sollte grundlegende Kubernetes-Befehle umschließen. Ich kann nicht zählen, wie oft ich versucht habe, helm describe oder helm logs auszuführen.
• helm-cicd sollte mir erlauben zu sehen, was die Ergebnisse von Befehlen sind, wenn sie von einem anderen Benutzer ausgeführt werden. Wenn wir RBAC verwenden, würde ich gerne sehen, was passiert, wenn ein nicht authentifizierter Benutzer versucht, etwas zu tun.
• helm-cicd sollte in der Lage sein, einen Namespace in eine Sammlung von Manifesten zu zerlegen, um sie später zu bearbeiten.
• helm-cicd sollte in der Lage sein, ein Release in einen Namespace zu _transplantieren_.

Das sind die großen... aber die Diskussion eines vollwertigen helm-ci Plugins liegt außerhalb des Rahmens dieser PR/Ausgabe (derzeit).

Ich lese alles, was Sie schreiben, und ich schätze den Diskurs. Ich freue mich auf Ihre Antworten.

Ich bin gerade ziemlich beschäftigt mit meiner Zeit, aber ich möchte Sie in einigen Punkten korrigieren. @jrkarnes

Ich denke, dass es ein Konstruktionsfehler ist, wenn appVersion eine intrinsische Eigenschaft in der unveränderlichen Chart.yaml-Datei ist

Es ist nicht. Wenn etwas so gemacht wird und nicht anders, dann gibt es immer einen Grund, auch den wilden . In diesem Fall ist es die Ideologie, die ich vertrete: ein Paket = ein Build, Diagramm = Vorlage für die Builds, Paket = App + Infra.

Helm wurde um diese Ideologie herum entwickelt, um K8s als Betriebssystem und Paket als Installer/Updater für Ihre App zu behandeln. Es hat einige Probleme, es fühlt sich manchmal zu viel an, aber es ist sicherlich eine Zukunft.

_Warum ich denke, dass es so konzipiert ist? Dasselbe helm list ist so eingestellt, dass die aktuell installierten Paketversionen angezeigt

Okay, wir haben viele Diagramme (öffentlich wie mysql und lokal, wie Sie wahrscheinlich haben), die nicht erstellt werden, um jedes Mal ein Paket zu erstellen, wenn eine neue Version erscheint. Und ich bewundere diese Notwendigkeit, denn die Migration zu einer High-Level-Lösung braucht Zeit. Außerdem muss jemand Pakete bauen und es wäre schwer, MySQL-Betreuer davon zu überzeugen, Helm-Pakete für jeden Build zu erstellen.

Bei MySQL-Chart gibt es ein zusätzliches Problem. Sie haben Recht, es wäre besser, die MySQL-Version in helm list installiert zu sehen, aber es ist nur ein Teil der Version, da es auch ein Image-Tag gibt, das wahrscheinlich ein Teil der Version hier ist.

Also, wie ich @iorlas gesagt
Ja. Ich werde gleich auf einige Vorschläge eingehen.

Auch hier gab es einen Vorschlag, helm run hinzuzufügen, wonach Sie alle suchen. Es ist beabsichtigt, Chart sofort als Paket zu verwenden, um App-Versionen und alles bereitzustellen.

In einer perfekten Welt würde ich behaupten, dass appVersion eine abgeleitete Eigenschaft sein und aus Docker-Image-Metadaten stammen sollte. das ist für helm nicht machbar, ergo, der fehlende streit.

Sie sehen Docker-Image als Endprodukt, als letztes Paket, das die letzte Quelle der Wahrheit ist. Es ist nicht. Wenn Sie nur ein Docker-Image haben, können Sie glauben, dass es sich um Ihre Software handelt. Wenn Sie ein Modul in Ihren Code schreiben, werden Sie dazu getäuscht zu glauben, dass dieses Modul Ihre Software ist.

Das Problem ist, das ist es nicht. Es ist nur ein Teil, Artefakt. Von kleinen bis hin zu großen Produkten haben Sie viele Artefakte miteinander verbunden. Manchmal übergeben Sie Versionen in einer Docker-Datei innerhalb des Build-Prozesses, manchmal haben Sie eine ConfigMap, die mehrere Artefakte miteinander verbindet. Und Sie werden nicht eine Docker-Datei haben, die alles enthält.

Ich habe eine persönliche Liste, die ein guter Ausgangspunkt sein könnte

Ich glaube, Sie haben viele Vorschläge, aber es fühlt sich mehr an, als wäre es ein Helm-Fork , eher ein wildes Plugin. Ich würde sagen, es hat nichts mit ausschließlich CI von CD zu tun. Ich würde argumentieren, solche Fork/Plugins nicht zu bauen, sondern zu diskutieren und geeignete Lösungen zu finden. Niemand braucht 3 Helmgabeln, wenn man bedenkt, dass die aktuelle Community derzeit nicht so groß ist.

Aufmerksamkeit bitte!

Okay, da und da haben wir viele gedacht. Ich glaube, das beste Szenario wäre:

• Möglichkeit, die App-Version zu ändern, ohne dass zuerst Pakete erstellt werden müssen
• Möglichkeit, die richtige App-Version in helm ls
• Erlauben Sie jeder API (wie dem Helm-Operator), die App-Version ohne mittleren Status anzugeben/zu aktualisieren

Wir haben zwei Ansätze zur Verfügung gestellt:

1. helm install wird erstellt, um ein Paket zu installieren. Es unterstützt auch die Installation des Diagramms, aber es ist begrenzt. Lassen Sie uns helm install vereinfachen und es seinem Zweck überlassen - Pakete installieren. Zweitens fügen wir helm run , was einen vereinfachten Ablauf bieten soll: Kombinieren Sie helm package und helm run , geben Sie beide Befehlsargumente an, filtern Sie jedoch diejenigen heraus, die in einem solchen Fall keinen Sinn haben .
2. Fügen Sie app-version zu helm install cmd hinzu. Es wird diese API aufblähen und die Idee der Verwendung von Paketen verbergen, es wird (wie jetzt) ​​die Ideologie der Verwendung von Paketen als Installer verbergen, was zumindest für einige, wenn nicht die meisten Projekte absolut sinnvoll ist.

Können wir uns darauf einigen, dass diese beiden Ansätze alle Kämpfe lösen werden, die wir derzeit haben?

Ein Plugin ist eine Problemumgehung für eine fehlende Funktion, die Core-Entwickler nicht unterstützen möchten oder keine Zeit haben, daher wäre es mir egal, ob es sich um ein Plugin handelt.

Helm wurde um diese Ideologie herum entwickelt, um K8s als Betriebssystem und Paket als Installer/Updater für Ihre App zu behandeln.

Ooooh. Ich verstehe es. Ein Helmdiagramm [Paket] ist als "rpm" [pro-say] für Kubernetes gedacht. Völlig nicht der Eindruck, den ich hatte: helm verwendet Charts, um eine App bereitzustellen. Das Diagramm/Paket ist die App "formatiert für k8s".

Ich bin damit zufrieden. Es macht Sinn - wir müssen gerade unseren Build-Server auf die appVersion aktualisieren, wenn wir neue Container bauen:

• Container erstellen - Tag "v1.2"
• Aktualisieren Sie Chart.yaml - appVersion: "v1.2" --- Ich sehe, es gibt sogar bereits einen helm package --app-version Befehl.
• Paketdiagramm: helm package --app-version v1.2 => Paket[diagramm]-v1.2.tgz (dh ein "Paket[diagramm]-v1.2.rpm")
• Paket mit Bereitstellungsservern bereitstellen, helm install package[chart]-v1.2 (zB apt install [email protected])

Verstehe ich das jetzt falsch? Wenn Paket-v1.2 nicht v1.2 appVersion ist, warum nicht? Wäre das nicht Absicht? zB rpm ist die Version der App, nicht das Paket (Chart).

Bearbeiten:

Wenn Paket-v1.2 nicht v1.2 appVersion ist, warum nicht? Wäre das nicht Absicht?

Jetzt verstehe ich, warum die Leute Chart.version und Chart.appVersion im Einklang kommentieren. Argumente können hier in beide Richtungen gehen ... eine App mit einem stabilen "Diagramm"-Build, Sie würden erwarten, dass Paket-v1.2 seine Versionsnummern ändert. Sie könnten aber auch argumentieren, dass package-v1.2 die Chart-Versionsnummer ist - wenn sich yaml-Dateien ändern.

Wie verwaltet man eine stabile Chart-Version (1.2), die sich von einer steigenden App-Version (1.6) unterscheidet? Wird package-[version] 1,2 sein? oder 1,6? Angenommen, Sie stellen eine Chart-Version 1.2 bereit, aber die appVersion hat sich beim Packen geändert: 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

:(

.... So verwirrend.

Ein Helmdiagramm [Paket] soll eine "rpm" [pro-say] für Kubernetes sein

Exakt! Aber manchmal fühlt es sich zu streng oder zu viel Aufwand an, hier ist eine Abkürzung erforderlich.

Verstehe ich das jetzt falsch? Wenn Paket-v1.2 nicht v1.2 appVersion ist, warum nicht? Wäre das nicht Absicht? zB rpm ist die Version der App, nicht das Paket (Chart).

Dies ist ein Problem für eine andere Diskussion, aber derzeit wird das Paket nach der Diagrammversion benannt, nicht nach der App-Version. Ich kenne den Grund dafür nicht, ich denke, es sollte anders herum sein. Ich denke, es ist ein historisches Thema, aber in meinen Augen, wie in Ihrem, sollte es package-{app-version}.tgz .

Wie aus meinen vorherigen Nachrichten hervorgeht, gibt es 4 Komponenten für die Version:

• Diagramm
• App
• Paket
• Freisetzung

Es bereitet Kopfzerbrechen, all diese Dinge unabhängig voneinander zu versionieren, aber im Moment funktioniert es so. Mit einer Ausnahme: Das Paket wird nach der Diagrammversion versioniert.

Wenn wir eine Ideologie zum Verpacken der App auswählen, wäre die App-Version absolut sinnvoll, da der gleiche Prozess sowohl App, Image als auch Paket erzeugt. Wenn wir also in den Auslieferungsschritt gehen, ist es offensichtlich, wie Dateien aufgerufen werden und welche Datei installiert werden soll. Im Moment müssen wir den Paketnamen in Pipelines >_< . festcodieren

@iorlas

Sie sehen Docker-Image als Endprodukt, als letztes Paket, das die letzte Quelle der Wahrheit ist. Es ist nicht. Wenn Sie nur ein Docker-Image haben, können Sie glauben, dass es sich um Ihre Software handelt. Wenn Sie ein Modul in Ihren Code schreiben, werden Sie dazu getäuscht zu glauben, dass dieses Modul Ihre Software ist.

Ich habe ein paar Wochen gebraucht, um über diese Aussage nachzudenken, und ich stimme Ihnen zu 100% zu. Außerdem verstehe ich jetzt, woher unsere Meinungsverschiedenheiten kommen...

Ich verfolge eine Entwicklungs- und Bereitstellungsphilosophie, dass Sie ein System aus kleinen Komponenten aufbauen sollten, die eine Reihe von Dingen unglaublich gut machen (denken Sie an UNIX); moderne Systeme behandeln eine "Anwendung" jedoch möglicherweise als eine Gruppierung dieser kleinen Werkzeuge. Wie soll man die "Version" einer Anwendung markieren, wenn sie nicht nur vom Docker-Artefakt abhängt, sondern auch von den anderen Unterkomponenten (die auch Docker-Artefakte sein können)? Es ist keine so einfache Antwort, wenn Sie anfangen, diese Art von Kopplung herumzuwerfen.

Die Beantwortung dieser Frage würde den Rahmen dieser Ausgabe/Anfrage bei weitem sprengen. Um auf die Wurzel des Problems zurückzukommen, möchte ich zwischen install und run . Aus semantischen Gründen sollte install nur mit Paketen arbeiten, und run sollte helm durch den Prozess des Generierens von Vorlagen und deren Anwendung _ohne Zustandsbeibehaltung_ laufen lassen.

Während wir oft helm template zu sehen, wie ein potenzielles Diagramm bereitgestellt wird, ist es sehr nützlich, zu beobachten, wie es passiert vi-ca-vi run das eine zweifacher Zweck, ein Star in Entwicklungspipelines zu sein (wo wir nicht unbedingt ein Paket behalten wollen, weil es keinen Wert hat, wenn die Geschwindigkeit sehr hoch ist).

Bei MySQL-Chart gibt es ein zusätzliches Problem. Sie haben Recht, es wäre besser, die MySQL-Version in der Helmliste installiert zu sehen, aber sie ist nur ein Teil der Version, da es auch ein Image-Tag gibt, das wahrscheinlich ein Teil der Version hier ist.

Wie ich schon sagte, in einem perfekten Universum würde die Version eines installierten Objekts introspektiert. Dies gibt mir jedoch eine Idee.

Wenn wir uns an das erinnern, was ich zu Beginn über die Bereitstellung von Diagrammen gesagt habe, was wäre, wenn wir die Möglichkeit hätten, alle Unterkomponenten mit einem Flag auf helm describe auszubreiten? Das in Ordnung bringen nicht die Notwendigkeit , die App-Version angeben, aber es macht es genau mehr klar , was installiert ist (die App-Version mit einer Flagge einzustellen Teil der Antriebskraft hinter wollen ist).

Ich habe alle Kommentare gelesen und habe keine voll qualifizierte Meinung zu diesem Thema.

Ich bin hierher gekommen, weil meine Firma ein privates Helm-Repository unterhält und 90% unserer Diagramme hauptsächlich eine Bereitstellung mit einer Containerspezifikation sind. Wenn wir in diesen Fällen appVersion könnten, um das Tag des Bildes aufzulisten, würden wir vermeiden, eine Variable zu duplizieren, und wir könnten sehen, dass diese Version helm version .

Nachdem ich diesen Thread gelesen habe, scheint mir dies eine Annehmlichkeit zu sein, wenn auch eine wirklich nette, die ich verwenden würde, wenn sie jemals zusammengeführt wird.

Wie gewünscht, füge ich meine letzte Antwort aus dem vorherigen Thread hinzu, damit andere sie sehen können

Hmm. An dieser Stelle geraten die Dinge in Konflikt, wenn Sie beginnen, appVersion mit einem Docker-Tag (einer logischen Assoziation) zu verknüpfen. Hier haben wir Probleme, dh das oben erwähnte Entwicklungsszenario. Da version ein SemVer sein muss, können wir Docker-Tags einfach nicht als Diagramm version .

Wie können wir den Entwicklern einen visuellen Versionsunterschied erstellen, wenn appVersion in den Diagrammen nicht sichtbar ist?

Wegen der Art und Weise, wie k8s mit seinen Anwendungen arbeitet: In einer Entwicklungswelt gab es eine Möglichkeit, Tag-Versionen flächendeckend zuzulassen.

Es konnte keine Dinge wie SemVer in Bezug auf die Operatoren ~ oder ^ tun, weil die Version rein geordnet war, ohne Semantik.

Warum nicht? Wir tun dies die ganze Zeit mit php composer . Wir können SemVer verwenden oder wir können String-Versionen verwenden, die im Versionierungsschema einfach geparst oder ignoriert werden, dh wenn version keine SemVer-Zahl ist, füge sie nicht in ~ und ^ Musterabgleich.

Da Sie meinen Kommentar zu #7299 zitieren , werde ich "Es konnte nicht" als "Es ging nicht" (und vielleicht immer noch nicht) klarstellen.

Bei .deb- und .rpm-Paketen wird die Versionszeichenfolge auf bestimmte Weise (durch Bindestriche) aufgeteilt, aber sie haben keine semantische Bedeutung wie "Dies ist API-kompatibel damit" und daher können Sie keinen Ausdruck wie "Give mir die neueste API-kompatible Version" oder "Geben Sie mir die neueste Version mit unveränderter API", wie Sie es mit SemVer können.

Ich erinnere mich, dass sowohl Debian als auch RedHat Paket-Aliasnamen verwendet haben, um diese Anwendungsfälle (und ABI-Kompatibilität) im Allgemeinen basierend auf Soversionsnummern zu erreichen. Dies ermöglichte ein einigermaßen konsistentes Verhalten, bei dem nur Paketnamen und Nur-Reihenfolge-Vergleiche verwendet wurden.

Was das allgemeine Thema betrifft, so verwenden wir Helm-Charts für unser Produkt zum Verpacken unserer verschiedenen Dienstleistungen. Die Docker-Images sind jedoch nur ein Artefakt, und ihre Benennung wird von der Dienstversion bestimmt, für die wir SemVer übernommen haben, da sie APIs bieten.

Unsere CI-Pipeline verwandelt Git-Repos von Code und verwandten Skripten und erzeugt Helm-Diagramme, die installiert werden können und zufällig auf Docker-Images verweisen. Die Tags auf den Docker-Images sind für unsere Benutzer nicht interessant. Wir taggen dann mit dem git SHA, von dem sie stammen, und taggen dann die in einer Veröffentlichung verwendeten Bilder neu. Der Hauptvorteil des Retaggings besteht darin, dass wir diese niemals enttaggen sollten, während wir die git-SHA-Versionen nach kurzer Zeit enttaggen können.

Ich bin also ziemlich zufrieden mit der Art und Weise, wie Helm für uns arbeitet, denn version enthält die genaue Version unserer Software und appVersion enthält dasselbe, aber als String, und niemand sieht jemals nach in unserem Docker-Repository.

Ich bin etwas weniger zufrieden mit der Art und Weise, wie Karten in https://github.com/helm/charts/ versioniert werden, da dort die Karte versioniert ist, nicht die Software, was zu gelegentlichen kleineren (stabilen) Karten führt version Updates, die die Abwärtskompatibilität unterbrechen . Ich denke, dies ist eine wahrscheinliche und schwer zu vermeidende Konsequenz, wenn Sie die version eines Diagramms von der Version der darin enthaltenen Elemente trennen.

Wir haben ein ähnliches Problem mit dem Stable/Prometheus-Operator- Diagramm auf unserer internen Seite "Extern konsumierte Bibliotheken und Artefakte". Das enthält eine Menge unterschiedlicher Software, also die Frage "Welche Version haben wir?" und insbesondere "Ist ein Upgrade sicher?" sind viel schwieriger zu beantworten als bei Agones, deren Versionen wir es genauso machen.

@jrkarnes

Wenn wir uns an das erinnern, was ich zu Beginn über die Bereitstellung von Diagrammen gesagt habe, was wäre, wenn wir die Möglichkeit hätten, alle Unterkomponenten mit einer Flagge am Steuer zu beschreiben? Das behebt nicht die Notwendigkeit, die App-Version anzugeben, macht aber deutlicher, was genau installiert ist (was Teil der treibenden Kraft ist, die App-Version mit einem Flag anzupassen).

Das würde ich total gerne sehen. Es gibt zum Beispiel eine entsprechende Funktionsanfrage unter #6932.

Nachdem wir die Diskussion gerade wieder aufgegriffen haben, passt die Idee, dass appVersion mit Docker-Image-Metadaten zusammenhängt, definitiv nicht zu unserem Anwendungsfall, wie zumindest einige unserer Diagramme (diejenigen, mit denen sich unsere Benutzer hauptsächlich beschäftigen) keine Docker-Images enthalten, da sie hauptsächlich Hosts für gemeinsam genutzte Ressourcen sind (z. B. öffentliche JWT-Schlüssel, values.yaml ) plus ein requirements.yaml zum Einbinden anderer Diagramme.

Die Idee, dass appVersion mit Docker-Image-Metadaten zusammenhängt, passt definitiv nicht zu unserem Anwendungsfall, wie zumindest einige unserer Diagramme

Ich sage nicht, dass dies _der_ Verwendungszweck war. Ich habe lediglich gesagt, dass es eine logische Assoziation ist. Sie verwenden immer noch appVersion als "logischen Container" Ihrer internen Yamls.

Ich weiß immer noch nicht, wie das Sperren von version an SemVer Vorteile hat. Könnte helm version (und appVersion ) analysieren und von dort aus fortfahren?

Ich denke , mein Punkt war , dass wir nicht mit appVersion überhaupt, es ist in der Regel nicht in unserem Chart.yaml, und wenn es vorhanden ist, dann ist es identisch mit version .

Der Vorteil des Sperrens von version auf SemVer besteht darin, dass Sie die verschiedenen SemVer-Operatoren darauf verwenden und es zuverlässig analysieren können, um Reihenfolgen und Übereinstimmungen durch Installation zu erzeugen.

Die RPM- und DEB-Paketsysteme haben dasselbe, außer dass ihre Versionsverwaltungssysteme eine andere Syntax verwenden, aber aus semantischen Parsing-Gründen immer noch eine eingeschränkte Syntax sind. Sie haben auch unterschiedliche Semantiken, die ihnen wichtig sind.

Wenn man bedenkt, wie das Helm/Charts-Repo ausgeführt wurde, wäre ein einzelnes version Feld mit einer DEB- oder RPM-Stil-Version eine bessere Wahl gewesen als SemVer plus appVersion String. Das ist jedoch ein ganz anderes, bereits gesegeltes Schiff. Und da ich in meiner Jugend sowohl Upstream-Anbieter als auch Debian-Paketierer war, schätze ich es, nicht jonglieren zu müssen "Welche der Versionsnummern muss hier gestoßen werden?" in unseren " version ist die eine Wahrheit"-Pakete.

Das Problem mit "manchmal ist es SemVer" ist, dass SemVer sehr so aussieht, als wäre es ein Parser, nicht zu unterscheiden von etwas, das Sie vielleicht von Hand schreiben oder woanders antreffen, wie zum Beispiel eine Debian-Paketversion, die keine Epoche hat, mit katastrophal verwirrenden Ergebnissen .

Hallo. Es gibt keine Neuigkeiten zu dieser Funktion.

Nachdem ich alle Kommentare gelesen habe, kann ich sehen, dass es wirklich hilfreich wäre.

Da wir in unserem Unternehmen mehrere Anwendungen haben, die dieselben Technologien verwenden und auf die gleiche Weise bereitgestellt werden, haben wir tatsächlich ein Diagramm für verschiedene Anwendungen, um Duplikate zu vermeiden.
Wir verpacken neue Charts nur, wenn es strukturelle Änderungen gibt.
Und nur wenn wir ein Release aktualisieren oder installieren, wenden wir bestimmte Werte als Tag, Umgebungsvariablen an...

Wir sind der Meinung, dass das gepackte Helmdiagramm die Abstraktionsschicht ist, die Kubernetes-Ressourcen und -Strukturen darstellt, die für eine Art von Anwendungen erwartet werden, und wir sagen nur während der Bereitstellung "ok, ich möchte, dass diese Art von Anwendung auf dieser Umgebung mit diesen spezifischen Werten bereitgestellt wird".

Da die Helmliste Versionsinformationen anzeigen sollte, sollten wir die Version der App sehen können, die in dieser Version bereitgestellt wurde.

Ich habe den Kommentar in einem ähnlichen Thema hinterlassen https://github.com/helm/helm/issues/7517
Können wir die Möglichkeit hinzufügen, dies in values.yaml zu überschreiben?
Dann erhalten wir eine kostenlose Befehlszeilenoption --set

Wenn wir versuchen, Helm für irgendeine Anwendung zu verwenden, ist dies absolut scheiße. Niemand verwendet semantische Versionierung für Produktionsanwendungen.

Ich stimme zu. Wir sind derzeit für die Verwendung von Diagrammmuseum für unveränderliche _anwendungsbasierte_ Diagramme gesperrt. Kartenversion != App-Version, wodurch es für uns unmöglich ist, über das Kartenmuseum zu veröffentlichen.

Ich habe einen Haufen (nicht alle) der obigen Diskussion durchgelesen, also tut mir leid, wenn ich einige Punkte / Ansichten wiederhole. Ich versuche, eine überlegtere Antwort zu geben.

Ich mag es, appVersion zu sehen, wenn ich ein helm ls mache und der konzeptionelle Wechsel von .Values.image.tag war gut, ABER nicht in der Lage zu sein, es zur Bereitstellungszeit einzustellen, ist ein echter Showstopper und ist etwas, das ich hatte zurück zu kehren.

Ich bin fest davon überzeugt, dass (Diagramm) version die Version des Diagramms und appVersion das Docker-Tag ist. In unserem CI-Prozess ist das Docker-Tag auch ein Git-Tag.
Wir haben auch mehrere Microservices und möchten die Dinge so trocken wie möglich halten. Wir haben generische Diagramme in einem lokalen Diagramm-Repository, da die meisten Java-Springboot-Apps gleich sind. Der Großteil der Tomcat-Apps ist gleich (aber anders als die Springboot-Apps). Spülen und wiederholen Sie den Vorgang für andere Technologien. Wir haben dann Umweltwerte, während die Bereitstellung durch verschiedene Umgebungen geht
Jeder dieser Microservices nutzt dann das generische Diagramm über CI/CD
zB helm upgrade release-name private-repo/generic-chart --values <environment>.yaml --set image.tag=<docker tag from build step> --namespace <environment> --install Ich würde lieber .Chart.AppVersion als .Values.image.tag aber ich MUSS in der Lage sein, auf eine Weise bereitzustellen, die für unsere Organisation effizient ist.

Wenn ich ein helm ls mache, habe ich sowohl CHART als auch APP VERSION also muss die gesamte Diagrammversion mit der App-Version übereinstimmen, die genau dort auffällt. Diesen Weg fortzusetzen, wird die Leute nur entfremden und irgendwann wird das Projekt gegabelt, weil diese Mentalität zu streng ist und nicht das, was viele Leute suchen. Es beginnt auch, den Weg von "Lassen Sie uns image.* , nameOverride & fullnameOverride entfernen. aus SEHR ähnlichen Gründen.

Ein letzter Punkt ist, dass viele öffentliche Diagramme nicht genau der Docker-Container-Version entsprechen, die sie verwenden. Schauen Sie sich die meisten bekannten Docker-Container an, zB alpine oder nginx, bei denen die Major- und Minor-Versionen Rolling-Tags sind und nur Patch-Versionen nicht Rolling sind. Eine 1:1-Zuordnung für jede Patch-Version bringt einen erheblichen Mehraufwand mit geringem bis gar keinem Nutzen mit sich.
Es ist nicht ungewöhnlich, dass Produktionsumgebungen aus einer Vielzahl von Gründen nicht auf die neueste Version aktualisieren können. Sprechen Sie an den meisten Orten nicht einmal über rollierende Versionen in der Produktion.

Das Ergebnis all der oben wirft dann die Frage : „Warum Helm ein Diagramm Repo überhaupt verwenden kann?“.
Da appVersion bei der Installation/Upgrade-Zeit nicht überschrieben werden kann, müssen Sie bereits das Diagramm herunterladen und entpacken, appVersion pro Installation/Upgrade bearbeiten oder die benötigten Docker-Container in packen die Grafik.
Die Ausnahme ist, wo eine komplette Standardinstallation stattfindet, und es gibt bereits viele Diskussionen über die automatische Generierung von Passwörtern und dergleichen.
Ich weiß, dass die letzten Absätze so aussahen, als würde ich in ein Kaninchenloch gehen und mich in eine Ecke malen, aber das ist, wo "appVersion ist das Docker-Tag UND kann appVersion nicht über die Befehlszeile oder Werte festlegen" führt uns.

@timothyclarke : Was Sie vielleicht für den hier beschriebenen Anwendungsfall helm upgrade tun möchten, ist helm package zuerst, wodurch Sie --version und --app-version festlegen können. helm install und als CI-Artefakt behalten, was Ihre Reproduzierbarkeit für die Installation erhöht, da keine --set Parameter hinzugefügt werden müssen. Darauf sind wir übergegangen, allerdings ohne den Aspekt des "generischen Diagramms", da unsere Diagramme nicht generisch sind.

Es ist auch eine gute Gelegenheit, dem Version Build-Metadaten hinzuzufügen, etwa +g<shortCommitSHA> .

Laut #7517 konnte ich damit eine Reihe von sed Aufrufen entfernen, die image.tag vor der Installation auf unserem CI-Testcluster und dann beim späteren Packen neu schrieben.

Dieser Ansatz könnte tatsächlich die Probleme lösen, auf die die meisten Leute hier gestoßen sind, wenn sie ihre eigenen Diagramme erstellen und insbesondere wenn sie aus der Diagrammquelle in ihrer Kasse installieren. Es hilft nicht wirklich, wenn sie diese Funktionalität für ein Diagramm benötigen, das aus einem Repo stammt, aber ich denke, das ist ein anderes Problem als die meisten Leute hier?

Für mich besteht das Risiko beim Überschreiben einer App-Version (oder -Version) zur Installationszeit darin, dass es für jemand anderen, der versucht, das Diagramm neu zu erstellen, nicht so deutlich sichtbar ist, dass dies getan wurde. Sofern es nicht irgendwie in die Werteunterstützung gehackt wurde, ist es nicht da, wenn man die aktuelle Konfiguration des Diagramms mit helm get values -o yaml extrahiert helm install <some way to specify a particular package> --values <values from helm get values> , zB wenn versucht wird, ein Problem zu reproduzieren, das in der Produktion in einem Test-Setup aufgetreten ist.

Für mich besteht das Risiko beim Überschreiben einer App-Version (oder -Version) zur Installationszeit darin, dass es für jemand anderen, der versucht, das Diagramm neu zu erstellen, nicht so deutlich sichtbar ist, dass dies getan wurde. Sofern es nicht irgendwie in die Werteunterstützung gehackt wurde, ist es nicht da, wenn man die aktuelle Konfiguration des Diagramms mit helm get values -o yaml extrahiert

Sie treffen den Nagel auf den Kopf. Das hätte vom ersten Tag an in values.yml .

Obwohl ich philosophische Argumente gegen diese Funktion verstehe, zeigt die Praxis, dass sie den Menschen sehr helfen würde – einschließlich uns.

Es gibt viele Diagramme in freier Wildbahn, mit denen Sie die Version der App über values.yml einstellen können, insbesondere weil sie hier nicht eingestellt werden kann.

Ich bin mir nicht sicher, ob das diskutiert wurde (habe kurz STRG+F gemacht und konnte keine Spur finden), aber wie wäre es mit dem Entfernen von appVersion als alternative Lösung? Es scheint mir, dass es die ganze Verwirrung vermeiden würde.

Momentan wird appVersion als eine Art "besonderer" Wert behandelt. Ich gehe davon aus, dass es für die Sichtbarkeit da ist, zB kann ich die Chartversion 123.5.6 von Prometheus haben, aber es wird appVersion: 2.17.1 haben, damit ich weiß, welche Sicherheitspatchversion es hat und welche Prometheus-Funktionen zu erwarten sind, und ich kann es mit helm ls nachschlagen.

Ich denke, das könnte auf andere Weise bereitgestellt werden. Vielleicht über Release-Labels? Oder vielleicht jsonPath Abfrage über alle Releases, ähnlich wie es mit kubectl zB:

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

Dann würde die Unterstützung dafür auf Best Practices verlagert, anstatt von helm selbst durchgesetzt zu werden. Es könnte auch fusseln.

Andererseits kann es sein, dass viele Leute auf bestehende Implementierungen von appVersion zurückgreifen, was ebenfalls berücksichtigt werden muss.

Vielleicht hilft es, dieses Problem zu lösen, wenn Sie einen Schritt zurücktreten und verstehen, warum genau appVersion hinzugefügt wurde?

@bokysan Es war zuvor in values.yaml es wurde nach Chart.yaml verschoben Ich vermute, dass für das gesamte helm ls sowohl das Diagramm als auch das Docker-Tag angezeigt werden, anstatt einen Befehl ausführen zu müssen, wie z wie
kubectl get deployment <release name> -o jsonpath='{.spec.template.spec.containers[0].image}'

@TBBle Ich würde jeden Ihrer Punkte ansprechen, aber dieser Beitrag würde dadurch so lang wie der vorherige. Ich denke, dieses ganze Problem läuft darauf hinaus, dass jemand entscheidet, dass ein generisches Diagramm kein gültiger Anwendungsfall ist, nur indem er sich die Diagramme im öffentlichen Repo ansieht.

Die gesamte Prämisse von appVersion fällt auf, sobald Sie initContainer und Sidecars verwenden müssen. Um ein reales Beispiel zu geben, hat eines der Projekte, die ich derzeit verwalten muss, nginx mit einem PHP-Sidecar. Die nginx- und php-Tags ändern sich nicht oft. Der PHP-Container / die PHP-Version ist für die Entwickler, die den Code schreiben, sehr wichtig. Der Container, der sich am häufigsten ändert, ist der initContainer der den Inhalt bereitstellt.
Setze ich appVersion auf den initContainer , auf den php Container oder ist es nginx , und wenn ich nur eine davon auswähle, sind welche Informationen verloren gegangen?

Wenn es für Ihre Benutzer wichtig ist, dann sollte es doch die PHP-Version sein? Damit machen Sie Werbung. Sie könnten auch alle drei in Ihre appVersion stecken, es ist schließlich ein Freitextfeld.

Wenn Sie appVersion == Container-Image-Tag erzwingen möchten, werden Sie dies bei nicht trivialen Diagrammen, dh Diagrammen mit mehr als einem Container oder ohne Container, als schwierig empfinden. Das ist aber nicht wirklich der Punkt, sonst wäre es imageVersion . Wenn Sie eine einzelne Upstream-App packen, verwenden Sie deren Version. Wenn Sie ein Paket aus mehreren Upstream-Apps erstellen, wählen Sie eine aus, zB das Diagramm des Prometheus-Betreibers, oder ignorieren Sie appVersion, da es sich um ein optionales Feld handelt.

Wenn Ihre Diagrammquelle _Teil von_ der Anwendung ist, zB Agones, lassen Sie einfach appVersion leer oder kopieren Sie es von version wenn Sie Werkzeuge haben, die davon abhängig sind.

Keines dieser Dinge muss helm install -zeitliche Entscheidungen sein. Wie ich bereits erwähnt habe, ist helm package für alle Workflows spät genug, mit Ausnahme von "Wechseln einer anderen Upstream-Version zur Installationszeit für ein Diagramm eines Drittanbieters" und das sollte in --values oder --set wie alle anderen "X zur Installationszeit ändern"-Aktionen.

Ehrlich gesagt, das tatsächlich fehlende Feature ist wahrscheinlich " appVersion durch tpl ", also können Sie es von .Values.image.tag oder was auch immer für Sie funktioniert lesen lassen.

Wenn Sie appVersion == Container-Image-Tag erzwingen möchten

Dann sind wir wahrscheinlich in https://github.com/helm/helm/issues/7517 Da kommt vielleicht das alles her.

Ich verstehe diese Diskussion überhaupt nicht. Warum nicht den Leuten die Möglichkeit geben, die App-Version so zu verwenden, wie sie denken, dass sie am besten zu ihnen passt, ist so ein großes Problem?

In einer aktuellen Form ist es für mich am besten, dieses APP VERSION überhaupt nicht zu haben. Es bringt den Leuten in unserem Projekt nur Verwirrung. Wir haben >80 Dienste, die das gleiche Helmdiagramm verwenden, und da es nicht möglich ist, dieses APP VERSION einfach in das helm upgrade -i ... zu ändern, sehe ich, dass alle unsere Anwendungen für immer bei 1.0 bleiben werden

Ich sehe auch, dass ich nur jedem sagen muss, dass er das helm list da es für sie nicht nützlich ist. Um zu überprüfen, welche Version unserer Anwendungen sie haben, müssen sie etwas anderes verwenden.

Ich war zu Beginn dieses Gesprächs optimistisch, aber nachdem ich bis zum Ende gesehen habe, wie Sie darüber diskutieren und wie Sie kämpfen, um Benutzer zu zwingen, Ihre Denkweise zu ändern, habe ich jetzt die Hoffnung verloren :(.

Zwei verschiedene Ausgaben "CHART(version)" und "APP VERSION" in helm list , helm history usw. zu haben, ist sehr hilfreich und vermeidet die Notwendigkeit, tiefer in die Befehlszeilenoptionen einzutauchen und die Ausgabe zu analysieren, um zu erhalten die wichtigsten Fakten.

Wenn "CHART(version)" und "APP VERSION" zur Build-Zeit gebunden sind ("helm package"), geht der ganze Vorteil von zwei verschiedenen Werten etwas verloren. Das Erstellen eines Diagramms und das Aktualisieren der APP-VERSION, ohne die CHART-VERSION zu erhöhen/aktualisieren, wird zu großen Problemen führen, da die gleiche CHART-VERSION Ihnen sehr unterschiedliche Ergebnisse liefert. :-<

Daher sind wir vorerst gezwungen, das Paket mit jedem Release zu erstellen und "CHART(version)" und "APP VERSION" synchron zu erhöhen, um nicht in eine verrückte/unklare Situation zu geraten.

Wie ich gerade erfahren habe, könnten wir "APP VERSION" fallen lassen, da es optional ist und einen benutzerdefinierten Wert verwenden und diesen anstelle von {{ Chart.appVersion }} für unser Bild verwenden.... aber dann würde helm list viel weniger informativ sein. :-<

Aus Sicht der Benutzer (Entwickler):

• Möglichkeit, einige Versionseigenschaften/Flags/Werte bei der Installation festzulegen
• Möglichkeit, diese Versionseigenschaft/das Flag/den Wert in der Helmliste/History-Ausgabe mit dem Label "XX-Version" zu sehen

Gibt es eine Chance, dass wir das hinbekommen?

Wenn "CHART(version)" und "APP VERSION" zur Build-Zeit gebunden sind ("helm package"), geht der ganze Vorteil von zwei verschiedenen Werten etwas verloren.

Ich denke, das ist der springende Punkt an der Fehlstellung. Der Vorteil der App-Version, wie ich sie verwende und die von der aktuellen Einrichtung beabsichtigt zu sein scheint, besteht darin, dass Sie die Version einer umschlossenen Anwendung _für diese Diagrammversion_ kennen, da die Diagrammversion die Version des gesamten Diagramms ist, nicht die Version der Vorlagen im Diagramm. Ich würde es hassen, wenn jede Aussage wie "Wir benötigen Version ~XY des Helm-Diagramms", um "Oh, und leg dich nicht mit der AppVersion an" am Ende angehängt zu haben.

Dieser Vorteil geht verloren, wenn die App-Version (und die tatsächliche Version der App) zum Zeitpunkt der Installation geändert wird, da Ihnen die Chart-Version jetzt nicht mehr mitteilt, welche App Sie verwenden, und Sie die Möglichkeit verlieren, SemVer zu verwenden, um sicherzustellen, Sie haben beispielsweise die neueste, aber API-kompatible Version.

Für den Anwendungsfall, den @pniederlag beschreibt, würde appVersion eine Vorlage sein, die auf einen Werteeintrag zeigt, würde helm list tun lassen, was gewünscht wird, solange das Diagramm dies unterstützt Anwendungsversion (wahrscheinlich ein Container-Tag), die zur Installationszeit geändert wurde, über --set oder --values wie jede andere Konfigurationsoption "zur Installationszeit geändert".

Hier habe ich ein Problem mit dem AppVersion .

Wir verwenden sowohl die Release-Version als auch AppVersions.

Um sie jetzt zu setzen - muss ich helm package vorher explizit von helm upgrade --install aufrufen, um ein lokales tar-Archiv zu erstellen, in dem beide Versionen gesetzt sind.

Jetzt füge ich die helm-secrets Unterstützung hinzu und...
Und sein Wrapper kann nicht mit helm package !

So was jetzt?
Den Support und den Flow aller unserer Versionen abbrechen?
Drop mit Secrets?
Irgendwelche Ideen?

Eigentlich ist es eher ein Problem für die helm-secrets , aber es hängt auch mit der hier besprochenen --set app-version Fähigkeit zusammen, denn wenn ich sie auf diese Weise verwenden könnte - ich muss die helm package nicht anrufen

UPD Oh, warte... Ich kann immer noch helm secrets upgrade chart.tgz -f secrets.yaml ...
Okay.
Aber trotzdem, +1, um die --set app-version hinzuzufügen.

So was jetzt?
Den Support und den Flow aller unserer Versionen abbrechen?
Drop mit Secrets?
Irgendwelche Ideen?

Wir bauen zwei Pakete: ein Helm-Paket mit nur den Charts, ohne die env-Werte und die Secrets-Datei. Wir benennen dieses Paket in chart-{app-version}.tgz da Chart-Version für uns nichts bedeutet und Chart-Version auch unsere App-Version-Syntax nicht unterstützt. Unsere App-Updates beinhalten alle potenziellen Chart-Updates (gleiches Repo, mit Git-Tagging).

Dann haben wir eine zweite tgz, die umgebungsspezifisch ist, chart-{app-version}-{env}.tgz , die die Diagramm-tgz, die Werte-YAML und die verschlüsselte Secrets-Datei enthält. Diese Datei enthält auch eine "package.yaml", die Werte wie Tag, App und Umgebungsname für unsere automatisierten Skripts enthält, die mit helm-secrets bereitgestellt werden.

Wir sind es gewohnt, unsere Anwendungsversionen oder die meisten davon mit einer semantischen Versionsnummer zu identifizieren. Verwenden Sie dann diese Nummer in der APP-VERSION, um sie in der helm history Liste für Rollbacks oder andere Operationen leicht zu identifizieren.
Da das System es nicht zulässt, es in der Bereitstellungszeit automatisch zu injizieren, führen wir diesen einfachen Befehl automatisch vor dem Bereitstellungsbefehl in unserer CI/CD-Pipeline aus:

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

Es ist schwierig, aber es funktioniert wie erwartet.

@bvis
Das Problem bei Ihrer Problemumgehung besteht darin, dass Sie das Diagramm in Ihrer CI/CD-Pipeline bearbeiten müssen.
Wenn Sie ein zentralisiertes Chart-Repository verwenden, werden Sie in helm pull repo/chart --untar gezwungen

Gibt es weitere Fortschritte beim programmatischen Injizieren von Chart.yaml/appVersion ? Gibt es Problemumgehungen? Es würde CI/CD Helm einen enormen Schub geben.

@jakovistuk Soweit ich das beurteilen kann, tun Diagramme, die appVersion verwenden, um die Containerversion anzuzeigen, dies direkt über Chart.yaml, wie zum Beispiel in nginx-ingress/Chart.yaml zu sehen ...

Ich habe lange Zeit nicht viel über dieses Problem nachgedacht, daher ist dies möglicherweise eine wirklich dumme Frage, aber gibt es eine Möglichkeit, die Helm-CLI zum Überschreiben von appVersion zu verwenden?

Es scheint, als würden viele Leute hier nach einer Möglichkeit fragen, das Feld "appVersion" zu überschreiben. Die ursprüngliche Absicht / Nachfrage in dieser Ausgabe ist -app-Version als Ersatz für -Ausführung, zu ermöglichen , so dass ein Benutzer ausführen könnte und Helm würde herausfinden, was die aktuelle Chart -

In unserem Projekt/Chart (cert-manager) möchten wir Endbenutzern so klar wie möglich machen, welche Version sie installieren, daher wäre es ein viel natürlicheres Installationserlebnis, ihnen die Installation nach App-Version statt nach Chart-Version zu ermöglichen.

Das heißt, dieses Problem wurde jetzt vor 2 Jahren geöffnet, und seitdem haben wir uns dafür entschieden, diese beiden Versionsnummern einfach synchron zu halten. Nach ein paar Jahren war dies überraschend einfach und schmerzfrei, auch wenn Benutzer manchmal einige Wochen auf eine neue offizielle Version warten müssen, wenn Änderungen an unseren Bereitstellungsmanifesten vorgenommen werden.

Angesichts des Alters dieser Ausgabe, ihrer Länge, der großen Vielfalt an leicht unterschiedlichen Feature-Gates und der Änderungen im Helm-Projekt seitdem (Helm 3, OCI-Charts usw.) als Feature Request in seiner jetzigen Form vorangetrieben werden. Ich werde dieses Problem schließen, aber jeder andere, der eine ähnliche Funktionsanfrage hat, öffnet am besten

Ich denke auch, dass diese Art von Funktionalität als externes Tool oder Wrapper implementiert werden könnte und wahrscheinlich am besten ist
Helm, insbesondere unter Berücksichtigung der OCI-Änderungen, die meiner Meinung nach die Umsetzung schwieriger machen würden.

Bis dies gelöst ist (oder nicht) So habe ich das in meinem CI/CD (GitLab) gelöst:

Verpacken Sie das Diagramm mit der App-Version und stellen Sie es dann bereit.
Ich weiß, dass die Chart-Version nicht mit der appVersion identisch sein soll, aber in unserem Fall ist sie als Workaround in Ordnung.

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

Wenn Sie image.tag standardmäßig auf {{ .Chart.AppVersion }} Sie es während der Installation nicht --set , es ist bereits korrekt. Dies funktioniert auch gut für Auto-Builds, wenn Ihre Docker-Images mit SHA1 getaggt sind, sodass die AppVersion mit dem Docker-Image-Tag übereinstimmt und die Version eine automatisch erstellte SemVer ist.

Es ist kein Problem, dass Version mit AppVersion identisch ist, wenn Ihre AppVersion zufällig SemVer ist.

Bei Paketen, die von meinem Team erstellt wurden, bewegen wir uns in Richtung Dinge, die nach AppVersion suchen, zB image.tag, die standardmäßig Version verwendet, wenn AppVersion nicht gesetzt ist. Es ist kein großer Unterschied, nur ein Argument weniger für helm package für getaggte Releases, aber es macht nur Sinn, wenn Ihr Diagramm aus demselben SCM erstellt wird wie das, was Sie packen.

@TBBle , das nicht funktioniert, wenn Sie ein Sub-Chart verwenden, um Ihr Image-Tag

Meinen Sie, dass sich das image.tag in einem Unterdiagramm befindet, Sie jedoch versuchen, die Version eines übergeordneten Diagramms zu verwenden? Wenn ja, ist das sehr umständlich und nicht einfach zu handhaben. Ich habe gerade genau dieses Layout in den Helm-Charts von https://github.com/googleforgames/open-match/ abgeprallt. Ich schlage vor, in diesem Fall die fraglichen Sub-Charts wieder in den Haupt-Chart einzufügen.

Diagramme sollten unabhängig voneinander isolierte/verwendbare Einheiten sein und sich nicht auf das Verhalten der übergeordneten Diagramme verlassen, um zu funktionieren. Das Subchart hat seine eigene Version, _das_ ist diejenige, die seine Bilder verwenden sollten, sonst, warum ist es ein Subchart?

Im Fall von Open Match scheinen die Subcharts so verwendet zu werden, dass XXX.enable als Abkürzung in der values.yaml verwendet werden kann, um eine Menge Zeug auf einmal zu deaktivieren, aber dann werden eine Reihe von strukturellen Problemen wie diese eingeführt . Die Subcharts von Open Match machen alle intensiven Gebrauch von den übergeordneten Charts namens templates und haben auch eine lokale Version von 0.0.0-dev , also gibt es bereits zwei Code-Geruch dafür, dass etwas nicht gut strukturiert ist.

Oder vielleicht habe ich Ihre Beobachtung falsch verstanden.

@haimari Leider funktioniert es nicht (bezogen auf https://github.com/helm/helm/issues/6921 ?):

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

Aber das funktioniert:

> 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

und sogar das (scheint aber schmutzig zu sein):

> 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 version.BuildInfo{Version:"v3.4.0", GitCommit:"7090a89efc8a18f3d8178bf47d2462450349a004", GitTreeState:"dirty", GoVersion:"go1.15.3"}

Ich denke, die Lösung von @haimari funktioniert so , wie sie ist, nur, weil sie semver-kompatible Tags in ihrer CI-Pipeline verwenden (dh dies ist ein Beispiel für einen Job, der für getaggte Releases ausgeführt wird und nicht bei jedem Commit ausgeführt wird).

@a0s : Ich schlage im Allgemeinen vor:

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

Und dann lassen Sie den Wert Ihres Container-Image-Tags etwa {{ Values.image.tag | default .Chart.AppVersion | default .Chart.Version , damit Sie ihn nicht sofort ändern müssen, wie es

In Ihren Beispielen haben Sie anscheinend zwei verschiedene Git-Versionen, ist das richtig? Ist einer für das Container-Image und einer für das Diagramm?

Mit SemVer können Sie einen Git-Commit-SHA nicht wirklich in den sinnvollen Teil des Semver einfügen, da Semver eine Sortierung impliziert und Git-Commit-SHAs nicht sortierbar sind.

Sie sollten also eine Version wie 0.0.1-alpha.<build-id>+g<gitcommitsha> wobei <build-id> der Pipeline- oder Job-ID Ihres CI-Systems ähnelt. Auf diese Weise erhalten Sie immer die neueste Version, wenn Sie danach fragen.

In SemVer bedeutet die Verwendung von - dass es sich um eine Vorabversion für diese Version handelt, also liegt 0.0.1-<anything> zwischen den Versionen 0.0.0 und 0.0.1. Der Teil nach + ist die Build-Info und wird beim Sortieren ignoriert.

Mit dem, was Sie hier verwendet haben, scheint 0-3454e5 neuer als der nächste Commit zu sein, wenn sein SHA zufällig mit einem 2 beginnt, zB 0-2764e1 .

In Ihren Beispielen haben Sie anscheinend zwei verschiedene Git-Versionen, ist das richtig? Ist einer für das Container-Image und einer für das Diagramm?

Ja, die App und das Diagramm – es gibt zwei unabhängige Software.

Auf diese Weise erhalten Sie immer die neueste Version, wenn Sie danach fragen.

Was ist, wenn ich nicht nach dem Neuesten fragen möchte (und es mir nicht einmal vorstellen kann).

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

Diese Zeichenfolge (nach der Interpolation) scheint zu lang zu sein, um in eine Spalte der Standardausgabe von helm list zu passen :)

Ich weiß immer, welche Version (sha Hash) der App ich installieren möchte (mit --set Argumenten übergeben). Und ich weiß immer, welche Version des Diagramms ich verwende (wie @haimari beschrieben hat, werde ich immer git checkout chart && helm pack && helm upgrade .tar.gz lokal in meiner ci/cd verwenden)

Was könnte schiefgehen?
1) Ein Fehler während des regulären helm upgrade . Ok, ich werde den Fehler beheben und es erneut versuchen (mit einem anderen sha-Commit der App - 99%) (oder stattdessen --atomic verwenden)
2) Manuelles Rollback: helm rollback <RELEASE_NAME> oder Bereitstellung des vorherigen sha-Commits über CI/CD.

Was habe ich verpasst?

PS Um ehrlich zu sein, möchte ich den kurzen sha-Teil in Version und App-Version nur zu Informationszwecken verwenden (während helm list )

Wenn es nur zu Informationszwecken dient, dann steht es hinter + in einem SemVer, nicht - . Wenn Sie _nie_ daran interessiert sind, Veröffentlichungen zu bestellen oder Helm-Charts an andere zu verteilen, und Ihre Charts oder App noch nicht SemVer'd sind, dann ist 0+g<commitsha> eine gültige SemVer (entspricht 0.0.0).

Dies ist beispielsweise die Aufgabe der automatisch erstellten Helm-Charts von Open Match; Sie sind derzeit alle 0.0.0-dev , und wir haben damit begonnen , 0.0.0-dev+g<commitsha> erstellen, damit Sie, wenn Sie sich ansehen, was Sie installiert haben, zumindest sagen können, _welchen_ Master-Build Sie haben.