Inhalte des Git-Repositories

SUSE® Rancher Prime Continuous Delivery erstellt Bundles aus einem Git-Repository. Dies geschieht entweder explizit durch Angabe von Pfaden oder wenn ein fleet.yaml gefunden wird.

Das Verzeichnis könnte ein Helm-Chart enthalten oder auf eines verweisen. Es könnte ein einfaches Kubernetes-Manifest oder ein Kustomize-Verzeichnis sein. Jedes Bundle wird in ein einzelnes Helm-Chart für die Bereitstellung umgewandelt.

Die fleet.yaml-Datei enthält alle Optionen für die Bereitstellung.

Bundle-Namen

Standardmäßig werden Bundle-Namen auch aus dem Namen des GitRepo und dem Pfad, aus dem das Bundle erstellt wird, generiert. Der Name eines Bundles kann jedoch durch die Verwendung des name-Feldes in einer fleet.yaml-Datei überschrieben werden.

Die Lebenszyklen der Bundles werden zwischen den Versionen durch das Helm releaseName-Feld verfolgt, das zu jedem Bundle hinzugefügt wird. Wenn der releaseName nicht innerhalb von fleet.yaml angegeben ist, wird er aus GitRepo.name + path generiert. Lange Namen werden gekürzt und ein -<hash>-Präfix wird hinzugefügt (Bundle-Namen sind auf 53 Zeichen begrenzt).

Wie Repos gescannt werden

Das Git-Repository hat keine ausdrücklich erforderliche Struktur. Es ist wichtig zu erkennen, dass die gescannten Ressourcen als Ressource in Kubernetes gespeichert werden, sodass Sie sicherstellen möchten, dass die Verzeichnisse, die Sie in Git scannen, keine willkürlich großen Ressourcen enthalten. Derzeit gibt es eine Einschränkung, dass die bereitgestellten Ressourcen gzip auf weniger als 1MB müssen. Es können mehrere Pfade für ein GitRepo definiert werden, und jeder Pfad wird unabhängig gescannt. Intern wird jeder gescannte Pfad zu einem Bundle, das SUSE® Rancher Prime Continuous Delivery verwalten, bereitstellen und unabhängig überwachen wird.

SUSE® Rancher Prime Continuous Delivery sucht nach den folgenden Dateien, um zu bestimmen, wie Ressourcen bereitgestellt werden.

Datei Standort Bedeutung

Chart.yaml

/ relativ zu path oder benutzerdefiniertem Pfad von fleet.yaml

Die Ressourcen werden als Helm-Chart bereitgestellt. Weitere Optionen finden Sie im fleet.yaml.

kustomization.yaml

/ relativ zu path oder benutzerdefiniertem Pfad von fleet.yaml

Die Ressourcen werden mit Kustomize bereitgestellt. Weitere Optionen finden Sie im fleet.yaml.

fleet.yaml

Jeder Unterpfad

Wenn eine fleet.yaml gefunden wird, wird ein neuer Bundle definiert. Dies ermöglicht das Mischen von Charts, Kustomize und rohem YAML im selben Repository.

.yaml

Jeder Unterpfad

Wenn eine Chart.yaml oder kustomization.yaml nicht gefunden wird, wird davon ausgegangen, dass jede .yaml oder .yml Datei eine Kubernetes-Ressource ist und bereitgestellt wird.

overlays/{name}

/ relativ zu path

Beim Bereitstellen mit rohem YAML (nicht Kustomize oder Helm) ist overlays ein spezielles Verzeichnis für Anpassungen.

Alternative Scan, ausdrücklich vom Benutzer definiert

Zusätzlich zur zuvor beschriebenen Methode unterstützt SUSE® Rancher Prime Continuous Delivery auch einen direkteren, benutzergesteuerten Ansatz zur Definition von Bundles.

In diesem Modus lädt SUSE® Rancher Prime Continuous Delivery alle Ressourcen, die im angegebenen Basisverzeichnis gefunden werden. Es wird nur versucht, eine fleet.yaml Datei im Stammverzeichnis dieses Verzeichnisses zu finden, wenn keine Optionsdatei ausdrücklich bereitgestellt wird. Im Gegensatz zur traditionellen Scanning-Methode ist diese nicht rekursiv und versucht nicht, Bundle-Definitionen zu finden, die nicht ausdrücklich vom Benutzer angegeben sind.

Beispielverzeichnisstruktur

driven
     |___helm
     |      |__ fleet.yaml
     |
     |___simple
     |      |__ configmap.yaml
     |      |__ service.yaml
     |
     |___kustomize
            |__ base
            |      |__ kustomization.yaml
            |      |__ secret.yaml
            |
            |__ overlays
            |         |__ dev
            |         |     |__ kustomization.yaml
            |         |     |__ secret.yaml
            |         |__ prod
            |         |     |__ kustomization.yaml
            |         |     |__ secret.yaml
            |         |__ test
            |               |__ kustomization.yaml
            |               |__ secret.yaml
            |__ dev.yaml
            |__ prod.yaml
            |__ test.yaml

Entsprechende GitRepo-Definition

kind: GitRepo
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: driven
  namespace: fleet-local
spec:
  repo: https://github.com/0xavi0/fleet-test-data
  branch: driven-scan-example
  bundles:
  - base: driven/helm
  - base: driven/simple
  - base: driven/kustomize
    options: dev.yaml
  - base: driven/kustomize
    options: test.yaml

Im obigen Beispiel definiert der Benutzer ausdrücklich vier Bundles, die generiert werden sollen.

  • Im ersten Fall wird das Basisverzeichnis als driven/helm angegeben. Wie in der Verzeichnisstruktur gezeigt, enthält dieser Pfad eine fleet.yaml Datei, die zur Konfiguration des Bundles verwendet wird.

  • Im zweiten Fall ist das Basisverzeichnis driven/simple, das nur Kubernetes-Ressourcenmanifeste (configmap.yaml und service.yaml) enthält. Da keine fleet.yaml oder Optionsdatei angegeben ist, wird SUSE® Rancher Prime Continuous Delivery ein Bundle mit dem Standardverhalten generieren – einfach alle Ressourcen zu verpacken, die im Verzeichnis gefunden werden.

  • Der dritte und vierte Fall beziehen sich beide auf dasselbe Basisverzeichnis: driven/kustomize. Jeder gibt jedoch eine andere Optionsdatei an (dev.yaml und test.yaml jeweils). Diese Optionsdateien definieren overlay-spezifische Konfigurationen für jede Umgebung (z. B. dev, test), indem sie die entsprechenden kustomize-overlay-Unterverzeichnisse auswählen und diese über das gemeinsame Basisverzeichnis anwenden.

SUSE® Rancher Prime Continuous Delivery wird diese als unterschiedliche Bundles verarbeiten, obwohl sie aus demselben Basisverzeichnis stammen, da die angegebenen Optionsdateien auf unterschiedliche Konfigurationen verweisen.

Ein Beispiel für die in den dritten und vierten Bundles verwendeten Dateien wäre das Folgende: (Diese Dateien folgen demselben Format wie fleet.yaml, aber da wir sie jetzt namentlich referenzieren können, können wir eine verwenden, die am besten zu unseren Bedürfnissen passt)

namespace: kustomize-dev
kustomize:
  dir: "overlays/dev"

Es ist wichtig zu beachten, dass jeder Pfad, der in diesen Dateien definiert ist, relativ zu dem Basisverzeichnis sein muss, das verwendet wurde, als das Bundle beschrieben wurde.

Zum Beispiel definieren wir mit der zuvor genannten Struktur das Basisverzeichnis als driven/kustomize. Das ist das Verzeichnis, das wir als Wurzel für die in Kustomize-Dateien verwendeten Pfade nutzen müssen.

Wir könnten entscheiden, die dev.yaml Datei am Pfad driven/kustomize/overlays/dev zu platzieren (das wird unterstützt), und dann das Bundle wie folgt zu definieren:

bundles:
    - base: driven/kustomize
      options: overlays/dev/dev.yaml

Der innerhalb von dev.yaml definierte Pfad sollte jedoch weiterhin relativ zu driven/kustomize sein. Das liegt daran, dass SUSE® Rancher Prime Continuous Delivery beim Lesen der Optionsdateien immer das Basisverzeichnis als Wurzel verwendet.

Mit anderen Worten, mit dem vorherigen Beispiel…​ wäre dies falsch:

namespace: kustomize-dev
kustomize:
  dir: "."

Und die korrekte Definition sollte weiterhin sein:

namespace: kustomize-dev
kustomize:
  dir: "overlays/dev"

Mit dieser neuen Art der Definition von Bundles wird SUSE® Rancher Prime Continuous Delivery viel direkter und vereinfacht auch die Übernahme von Bereitstellungen mit Kustomize. Im Beispiel sehen wir einen vollständigen Kustomize-Anwendungsfall, bei dem wir für jedes Bundle angeben können, welche Version wir möchten.

Mit der vorherigen Scan-Option kann SUSE® Rancher Prime Continuous Delivery nicht bestimmen, welche YAML wir verwenden möchten, um das Bundle zu konfigurieren, daher versucht es, es selbst zu finden (was manchmal nicht genügend Flexibilität bietet).

Ausschluss irrelevanter Dateien aus benutzerscannten Bundles

Beim Verwenden dieses Bundle-Scan-Modus schließt SUSE® Rancher Prime Continuous Delivery keine Bundle-Konfigurationsdateien aus, die nicht ausdrücklich im GitRepo referenziert werden. Zum Beispiel in der obigen Verzeichnisstruktur:

  • Standardmäßig würden weder prod.yaml noch test.yaml vom Bundle ausgeschlossen, wenn dev.yaml als Optionsdatei verwendet wird.

  • Ähnlich würden standardmäßig weder dev.yaml noch prod.yaml vom Bundle ausgeschlossen, wenn test.yaml als Optionsdatei verwendet wird.

Dies kann gemildert werden, indem eine .fleetignore-Datei neben {dev,test,prod}.yaml verwendet wird, die alle drei ausschließt. Siehe den nächsten Abschnitt für weitere Details zu .fleetignore-Dateien.

Ausschluss von Dateien und Verzeichnissen aus Bundles

SUSE® Rancher Prime Continuous Delivery unterstützt den Ausschluss von Dateien und Verzeichnissen mittels .fleetignore-Dateien, ähnlich wie .gitignore-Dateien in Git-Repositories funktionieren:

  • Die Glob-Syntax wird verwendet, um Dateien oder Verzeichnisse zuzuordnen, unter Verwendung von Golang’s filepath.Match.

  • Leere Zeilen werden übersprungen und können daher zur Verbesserung der Lesbarkeit verwendet werden.

  • Zeichen wie Leerzeichen und # können mit einem Backslash escaped werden.

  • Nachfolgende Leerzeichen werden ignoriert, es sei denn, sie sind escaped.

  • Kommentare, d.h. Zeilen, die mit unescaped # beginnen, werden übersprungen.

  • Eine gegebene Zeile kann eine Datei oder ein Verzeichnis zuordnen, auch wenn kein Trennzeichen bereitgestellt wird.

  • Ein Treffer kann auf jeder Ebene unter dem Verzeichnis gefunden werden, in dem sich eine .fleetignore befindet.

  • Mehrere .fleetignore-Dateien werden unterstützt.

root/
├── .fleetignore            # contains `ignore-always.yaml'
├── something.yaml
├── bar
│   ├── .fleetignore        # contains `something.yaml`
│   ├── ignore-always.yaml
│   ├── something2.yaml
│   └── something.yaml
└── foo
    ├── ignore-always.yaml
    └── something.yaml

Nicht unterstützt:

  • Doppelte Sterne (**)

  • Explizite Einschlüsse mit !

fleet.yaml

Die fleet.yaml ist eine optionale Datei, die im Git-Repository enthalten sein kann, um das Verhalten zu ändern, wie Ressourcen bereitgestellt und angepasst werden. Die fleet.yaml befindet sich immer im Wurzelverzeichnis relativ zur path der GitRepo und wenn ein Unterverzeichnis mit einer fleet.yaml gefunden wird, wird ein neues Bundle definiert, das dann anders konfiguriert wird als das übergeordnete Bundle.

Abhängigkeiten von Helm-Charts:

SUSE® Rancher Prime Continuous Delivery verwaltet automatisch die Aktualisierung von Helm-Chart-Abhängigkeiten, es sei denn, das Flag disableDependencyUpdate (false standardmäßig) ist auf true gesetzt.

Wenn automatische Updates der Abhängigkeiten deaktiviert sind, müssen Sie manuell ausführen:

helm dependencies update $chart oder helm dependencies build $chart

Verweisen Sie auf die SUSE® Rancher Prime Continuous Delivery Dokumentation von Rancher für weitere Informationen.

Die verfügbaren Felder sind in der fleet.yaml-Referenz dokumentiert. Für ein privates Helm-Repository können Benutzer ein Geheimnis aus der Git-Repository-Ressource referenzieren. Siehe Verwendung privater Helm-Repositorys.

Verwendung von Helm-Werten

Wie Änderungen auf values.yaml angewendet werden:

  • Die zuletzt angewendeten Änderungen überschreiben vorherige Werte.

  • Merge-Reihenfolge: helm.values → helm.valuesFiles → helm.valuesFrom

Ablauf der Fleet-Werte-Stufen

Der Zielschritt kann Werte als Vorlagen unter Verwendung von Clusterinformationen behandeln. Weitere Informationen: Vorlagen in fleet.yaml.

Sie können dies mit disablePreProcess deaktivieren.

Anmeldeinformationen in Werten

Wenn das Chart Anmeldeinformationen generiert, überschreiben Sie diese, oder das Chart könnte kontinuierlich neu bereitgestellt werden.

Anmeldeinformationen, die über valuesFrom geladen werden, sind verschlüsselt, wenn die Kubernetes-Verschlüsselung im Ruhezustand aktiviert ist.

Vorlagenverarbeitung

Der Zielschritt kann die Werte als Vorlage behandeln und Informationen aus der clusters.fleet.cattle.io-Ressource übernehmen. Für weitere Informationen siehe Helm-Wertvorlagen.

Sie können dies in fleet.yaml deaktivieren, indem Sie disablePreProcess festlegen. Dies ist nützlich, um Konflikte mit anderen Vorlagensprachen zu vermeiden.

Es ist nicht notwendig, auf die eigenen values.yaml eines Charts über valuesFiles: zu verweisen. Die im Chart enthaltene values.yaml-Datei wird immer als Standard verwendet, wenn der Agent das Chart installiert.

Wenn das Chart Zertifikate oder Passwörter in seinen Vorlagen generiert, müssen diese Werte überschrieben werden. Andernfalls könnte das Chart kontinuierlich bereitgestellt werden, da sich diese Werte ändern.

Anmeldeinformationen, die mit valuesFrom aus dem Downstream-Cluster geladen werden, sind standardmäßig verschlüsselt, wenn Datenverschlüsselung in Kubernetes aktiviert ist. Anmeldeinformationen, die in der Standard-values.yaml-Datei enthalten sind oder über values: oder valuesFiles definiert werden, sind nicht verschlüsselt, da sie beim Erstellen des Bundles aus dem Repository geladen werden.

Härtete Cluster sollten die Fleet-CRDs zur Liste der im Ruhezustand verschlüsselten Ressourcen im Upstream-Cluster hinzufügen, wenn Anmeldeinformationen in den Bundles gespeichert werden.

Verständnis von Helm values.yaml vs Fleet valuesFiles

Die Installation von Helm-Charts mit Fleet bietet mehrere Möglichkeiten zur Konfiguration und Referenzierung von Werten, unter Verwendung der integrierten values.yaml des Charts und zusätzlicher Werte-Dateien, die in fleet.yaml referenziert werden. Diese Dateien dienen unterschiedlichen Zwecken, und es ist wichtig zu verstehen, wie sie interagieren.

Verständnis von Helm values.yaml vs Fleet‑Werte‑Dateien mit Best Practices

Beispielverzeichnisstruktur:

.
├── Chart.yaml
├── fleet.yaml
├── README.md
├── templates/
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml   # chart defaults

Sie können die values.yaml-Datei eines Helm-Charts verwenden, um:

  • Standardwerte bereitzustellen und Benutzern zu ermöglichen, die Standardwerte zu überschreiben, ohne das Chart selbst zu ändern.

  • Definieren Sie gemeinsame Standardwerte für Kubernetes-Ressourcen.

Ein Helm-Chart-values.yaml unterstützt kein Templating. Alle Ersetzungen erfolgen während des Renderns des Charts, bevor Fleet das Chart anwendet.

  • Sie können keine Shell-ähnlichen Variablen (zum Beispiel `${var}`) in dieser Datei verwenden.

  • Wenn `${var}` erscheint, behandelt Helm es als reinen Text – Sie müssen es nicht escapen.

Fleet-Werte-Dateien, die aus fleet.yaml referenziert werden.

Fleet ermöglicht es Ihnen, zusätzliche Werte-Dateien über fleet.yaml zu referenzieren. Diese Dateien überschreiben oder erweitern die Baseline-Standardeinstellungen des Charts.

  • Ein valuesFiles-Eintrag entspricht dem Kopieren und Einfügen des Inhalts dieser Datei in den Werte-Bereich von fleet.yaml.

  • Es ist hauptsächlich eine Komfortfunktion, um Werte in mehrere Dateien aufzuteilen.

  • Im Gegensatz zu Helm-Chart-values.yaml unterstützen die Werte-Dateien von Fleet Templating, was eine dynamische Konfiguration pro Umgebung ermöglicht.

Beispiel fleet.yaml:

helm:
  valuesFiles:
    - values.prod.yaml   # overrides baseline

Sie können fleet valuesFiles verwenden, das von fleet.yaml referenziert wird, um:

  • Umgebungs-spezifische Überschreibungen anzuwenden (dev, staging, prod).

  • Erweiterte Funktionen zu aktivieren, die nicht in den Chart-Standardeinstellungen enthalten sind.

Bewährte Praxis: Egal, ob Sie helm values.yaml, fleet.yaml Werte: oder valuesFiles verwenden, speichern Sie niemals Anmeldeinformationen in diesen Dateien. Der empfohlene und sicherere Ansatz ist die Verwendung von valuesFrom, das auf Kubernetes-Secrets oder ConfigMaps verweist. Obwohl dies die Erstellung der Secrets in Downstream-Clustern erfordert, stellt es sicher, dass sensible Daten sicher gespeichert werden.

Verwendung von ValuesFrom

Diese Beispiele zeigen den Stil und das Format für die Verwendung von valuesFrom.

Weiterleiten von ConfigMaps und Secrets an Downstream-Cluster: ConfigMaps und Secrets sollten im Allgemeinen direkt in Downstream-Clustern erstellt werden.

Von SUSE® Rancher Prime Continuous Delivery v0.14.0 an können sie jedoch auch über das downstreamResources-Feld eines HelmOps referenziert werden, um automatisch an die Ziel-Downstream-Cluster propagiert zu werden.

Siehe experimentelle Downstream-Ressourcen für weitere Informationen.

Beispiel ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: configmap-values
  namespace: default
data:
  values.yaml: |-
    replication: true
    replicas: 2
    serviceType: NodePort

Beispiel Secret:

apiVersion: v1
kind: Secret
metadata:
  name: secret-values
  namespace: default
stringData:
  values.yaml: |-
    replication: true
    replicas: 3
    serviceType: NodePort

Sie beziehen sich darauf:

helm:
  chart: simple-chart
  valuesFrom:
    - secretKeyRef:
        name: secret-values
        namespace: default
        key: values.yaml
    - configMapKeyRef:
        name: configmap-values
        namespace: default
        key: values.yaml
  values:
    replicas: "4"

Anpassung pro Cluster

Das GitRepo definiert, in welche Cluster ein Repository bereitgestellt wird. Das fleet.yaml definiert Anpassungen pro Ziel.

Alle Cluster und Gruppen im selben Namespace werden gegen die Ziele bewertet. Die erste Übereinstimmung gilt.

targetCustomizations:
- name: all
  clusterSelector: {}
- name: none
  clusterSelector: null

Übereinstimmung nach Clustername:

targetCustomizations:
- name: prod
  clusterName: fleetname

Siehe Anpassung pro Cluster.

Roh-YAML-Ressourcenanpassung

# Base files
deployment.yaml
svc.yaml

# Overlay files
overlays/custom/configmap.yaml
overlays/custom/svc.yaml
overlays/custom/deployment_patch.yaml

Regeln:

  • Übereinstimmende Namen ersetzen Basisdateien.

  • _patch. Dateien wenden Patches an (JSON/strategisch/JSONPatch).

Cluster- und Bundle-Zustand

Siehe Statusfelder.

Verschachtelte GitRepo-CRs

Verschachtelte GitRepo-CRs werden unterstützt.

Weitere Informationen finden Sie in: https://github.com/rancher/fleet-examples/tree/master/single-cluster/multi-gitrepo