Warum wir YAML templatisieren (2019)

 (leebriggs.co.uk)
2 Punkte von GN⁺ 2024-01-24 | 1 Kommentare | Auf WhatsApp teilen

Zweifel am Einsatz von YAML-Templates

  • Es wird die Frage aufgeworfen, seit wann der Einsatz von YAML-Templates als normal gilt und wie das überhaupt akzeptiert werden konnte.
  • Auf der cfgmgmtcamp 2019 wurde über die Notwendigkeit des Konfigurationsmanagements für Kubernetes und die Lösung kr8 gesprochen.
  • Während des Vortrags wurden Zweifel an YAML-Templates geäußert, was online und auf der Konferenz zu lebhaften Diskussionen führte.

Konfigurationsprobleme

  • Wenn Anwendungen und Infrastruktur über eine gewisse Größe hinauswachsen, stößt man auf das Problem der Konfigurationskomplexität.
  • Die Konfiguration von Anwendungen, die in verschiedenen Umgebungen (Entwicklung, Staging, Produktion) oder Regionen (Europa, Nordamerika) bereitgestellt werden, kann unterschiedlich sein.
  • Systemadministratoren oder DevOps-Ingenieure kennen die Komplexität des Konfigurationsmanagements gut, und die jeweiligen Tools versuchen, dieses Problem mit YAML zu lösen.

Sind wir einen Schritt zurückgegangen?

  • Mit dem Wandel der Anforderungen in der Branche durch Cloud Computing sind neue Tools entstanden.
  • Tools wie CloudFormation und Helm sind hervorragende Konfigurationswerkzeuge, aber es wird die Ansicht vertreten, dass die Branche bei der Gestaltung von YAML-Templates insgesamt einen Fehler gemacht hat.
  • Dies wird anhand eines Beispiels erläutert, bei dem ein Helm-Chart benutzerdefinierte Parameter entgegennimmt.

Helm-Chart

  • Ein Helm-Chart übernimmt externe Parameter über die Datei values.yaml und rendert damit das Chart.
  • Ausgehend von einfachen String-Parametern wird die Komplexität beim Konfigurieren optionaler Felder, Arrays und Maps erläutert.
  • Es wird auf die strengen Anforderungen von YAML an Einrückungen und auf die Grenzen des Template-Systems hingewiesen.

JSON, Jsonnet & YAML

  • YAML ist eine Obermenge von JSON, und die Umwandlung zwischen den beiden Formaten ist einfach.
  • Jsonnet ist eine Daten-Templating-Sprache mit dem Ziel, JSON-Konfigurationen zu erzeugen.

Die Kirche von Jsonnet

  • Jsonnet ist eine neue Sprache, die außerhalb der Kubernetes-Community nicht besonders bekannt ist.
  • Mit Jsonnet lassen sich JSON-Konfigurationen unter Verwendung externer Variablen leicht erzeugen.
  • Es wird erläutert, wie optionale Felder, Maps und Parameter behandelt werden und welche zusätzlichen Funktionen Jsonnet bietet.

Kr8

  • Kr8 nutzt alle Methoden, die für das einfache Erstellen und Bearbeiten von Konfigurationen für mehrere Kubernetes-Cluster geeignet sind.
  • Wenn Sie mit den hier beschriebenen Konzepten übereinstimmen, lohnt es sich, einen Blick auf Kr8 zu werfen.

Meinung von GN⁺

  • Die Komplexität von YAML-Templates: Dieser Beitrag weist auf die Komplexität und Grenzen von YAML-Templates hin und zeigt die Probleme gut auf, mit denen die Branche beim Konfigurationsmanagement konfrontiert ist.
  • Die Vorteile von Jsonnet: Jsonnet wird als Alternative zu YAML-Templates vorgestellt, und durch die Betonung seiner einfachen Nutzung und Flexibilität wird das Interesse an neuen Tools geweckt.
  • Die Zukunft des Konfigurationsmanagements: Dieser Beitrag bietet Einblicke in die Zukunft des Konfigurationsmanagements und gibt DevOps- und Systemadministrations-Teams die Gelegenheit, neue Ansätze zu erkunden.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-24
Hacker-News-Kommentare

  • Es gibt viel Unzufriedenheit mit YAML-Konfigurationsdateien. Es gilt auch bei GitHub Actions als der schlechteste Teil, und bei anderen proprietären Konfigurationssprachen (HCL, ASL usw.) stellt sich ein ähnliches Gefühl ein. Deklarative APIs sind gut, aber es gibt den Wunsch, Deklarationen programmatisch erzeugen zu können.

  • Konfiguration als Code zu deklarieren und zu erzeugen, bietet die bessere Erfahrung. AWS CDK versteht diesen Punkt genau und ermöglicht es, mit typsicheren Sprachen und IDE-Unterstützung deklarative Definitionen für Konfiguration und Cloud-Infrastruktur zu schreiben.

  • Zustimmung dazu, dass YAML-Templating unvernünftig ist; wenn komplexe Logik nötig ist, sollte man eine echte Programmiersprache verwenden, um YAML/JSON usw. zu erzeugen. Damit lassen sich viele Probleme lösen.

  • Es gab eine Diskussion über Kubernetes: Obwohl die Kubernetes-API ein intuitives und gut definiertes JSON-Schema hat, verbringen Menschen dennoch viel Zeit damit, den Umgang mit Helm Charts zu lernen. Jsonnet, Ksonnet, Nu und CUE haben keine große Popularität erlangt, und die meisten scheinen das in kubectl eingebaute Kustomize zu verwenden.

  • Es wird angemerkt, dass Entwickler nicht genug darüber nachdenken, wie Konfiguration richtig behandelt werden sollte. Man könnte sagen, dass jede Programmierung letztlich ein Konfigurationsproblem ist, und jede Konfiguration am Ende als Parameter an irgendeine Funktion übergeben wird. Es könnte besser sein, Konfiguration in einer zentralen Datenbank zu speichern.

  • In CI/CD wird YAML manchmal fast wie eine Programmiersprache verwendet; das ist sehr wortreich und wenig intuitiv und wird als schlecht definierte, anbieterspezifische Sprache angesehen.

  • Bedauern darüber, dass Helm gewonnen hat. Die Arbeit mit Helm Charts ist sehr mühsam, der Editor kann nicht helfen, und alle Daten müssen über indent 4 korrekt ausgerichtet werden. Es gibt die Vorhersage, dass Helm das Ende von Kubernetes herbeiführen wird.

  • Es gibt die persönliche Philosophie, dass es nicht wünschenswert ist, maschinenlesbaren Code mittels String-Interpolation zu erzeugen. Probleme wie SQL Injection und Cross-Site Scripting werden sonst immer wieder auftreten. Es wird behauptet, dass man keine Template-Dateien verwenden sollte, um HTML zu erzeugen.

  • Es gibt die Ansicht, dass Menschen, die YAML wählen, das Problem nicht zu erkennen scheinen. Zwischen menschenzentrierter und computerzentrierter Datenrepräsentation besteht ein direkter Konflikt. YAML und JSON sind in Wirklichkeit unterschiedliche Datenformate.

  • Jemand mag YAML, verflucht es aber täglich bei der Arbeit mit Helm Charts. Trotz Abneigung gegen Helm wird es weiter verwendet, weil es alle benutzen.

  • Es wird erwogen, zu cuelang zu wechseln, das als besser gestaltet als Jsonnet angesehen wird. Kubernetes hat bereits eine Zustandsabstimmung, es müsste also nur noch eine Löschfunktion ergänzt werden.