Einspielen von Patches in die Datei config.ini mithilfe des Kubernetes-Inventarisierungsagenten von Flexera

IT Asset Management (Cloud)

Der Kubernetes-Inventarisierungsagent von Flexera delegiert mehrere Funktionen an den in seinem Container installierten FlexNet-Inventarisierungsagenten. Wie überall in IT Asset Management nutzt der FlexNet-Inventarisierungsagent die Datei config.ini als primäre Konfigurationsquelle. Außerhalb von Containern werden Änderungen, die auf dem zentralen Anwendungsserver vorgenommen werden, in der Datei config.ini an die Inventarisierungsstationen verteilt und der lokal auf inventarisierten Geräten installierte FlexNet-Inventarisierungsagent fordert seine aktualisierte Konfiguration regelmäßig von dort an.

Dieser Vorgang wird für die in Containern installierten FlexNet-Inventarisierungsagenten jedoch nicht nach einem regelmäßigen Zeitplan wiederholt. Die Datei config.ini wird von der Inventarisierungsstation nur einmal aktualisiert, nämlich beim Start des Containers (siehe auch die Verarbeitungsübersicht am Ende dieses Hilfethemas). Außerdem kann es sein, dass die Konfiguration für bestimmte Kubernetes-Bereitstellungen benutzerdefiniert angepasst werden muss. Auch wenn es in Kubernetes schwierig ist, solche Änderungen an einer Datei im Container vorzunehmen, enthält der Kubernetes-Inventarisierungsagent von Flexera eine Möglichkeit, die lokale config.ini im Container automatisch zu patchen.

Hier eine grobe Übersicht:

Änderungen werden als Patch-Dateien ausgeliefert, von denen jede eine oder mehrere Änderungen enthält, die in die Datei config.ini für den FlexNet-Inventarisierungsagenten im Container übernommen werden müssen.
Die Patch-Dateien werden in einer ConfigMap im Cluster hinterlegt (eine Ressource, die Schlüssel-Wert-Paare als Datensets speichert). Wenn ConfigMap als Datenquelle für ein verbundenes Volume im Container verwendet wird, wird aus jedem Eintrag eine Datei, wobei der Schlüssel zum Namen der Datei wird und der Wert zum Inhalt. (Wenn mehrere Änderungen erforderlich sind, können diese zu einer Patch-Datei zusammengefasst oder als einzelne Patch-Dateien aufgelistet werden, je nachdem, was besser in Ihre Abläufe passt.)
Wenn Richtlinienaktualisierungen aktiviert sind (was standardmäßig der Fall ist, es sei denn, Sie haben in der YAML-Datei spec.monitor.downloadFromBeacon auf false gesetzt), werden die Patches automatisch in die config.ini übernommen, und zwar sowohl:
- bevor die Agentenrichtlinie heruntergeladen wird (für den Fall, dass zur Kommunikation mit der Inventarisierungsstation SSL-Konfigurationsoptionen erforderlich sind), und
- nachdem der Kubernetes-Inventarisierungsagent von Flexera die jüngsten Updates für die config.ini von seiner Inventarisierungsstation heruntergeladen und dabei sichergestellt hat, dass ein Richtlinien-Update vom zentralen Anwendungsserver die lokalen Patches für die Datei config.ini in diesem Cluster nicht negiert.
(Eine vollständigere Beschreibung dieser Interaktion finden Sie in der Auflistung im Anschluss an diesen Vorgang.)

So nutzen Sie den Kubernetes-Inventarisierungsagenten von Flexera zum Einspielen von Patches in die config.ini:

Stellen Sie sicher, dass eine ausreichend neue Version des Kubernetes-Inventarisierungsagenten von Flexera installiert ist/wird.
Es muss mindestens Version 1.3.0 installiert sein/werden. Wenn diese oder eine neuere Version bereits installiert ist, sind an dieser Stelle keine weiteren Aktionen erforderlich. Wenn eine frühere Version installiert ist, aktualisieren Sie diese, indem Sie den Standardprozess zum Herunterladen/Installieren befolgen, bis das Skript install.sh erfolgreich ausgeführt wurde.
Tipp: Wenn Sie nicht wissen, welche Version des Kubernetes-Inventarisierungsagenten von Flexera im Cluster installiert ist: Diese wird in der Version der bereitgestellten Containerimages wiedergegeben. Beispielsweise enthält folgendes Containerimage:
```
flexera/krm:1.3.0
```
die Version 1.3.0 des Kubernetes-Inventarisierungsagenten von Flexera. Sie können das Image mithilfe der entsprechenden Controller-Bereitstellung untersuchen (alles in einer Befehlszeile, hier zur Darstellung mit Zeilenumbruch):
```
kubectl get deployments --namespace flexera 
    krm-controller -o jsonpath={.spec.template.spec.containers[0].image}
```
Bereiten Sie auf dem Gerät, das zur Installation des Kubernetes-Inventarisierungsagenten von Flexera verwendet wurde, eine Datei mit dem Patch für die config.ini vor. Speichern Sie die fertige Patch-Datei im aktuellen Verzeichnis, sodass Ihre Kubernetes-Befehle darauf zugreifen können:
- Sie können Ihren Patch-Dateien beliebige Namen geben, aber alle Patch-Dateien müssen die Dateinamenserweiterung .ini haben.
- Patches legen einen Wert für eine Einstellung fest. Sie finden alle Agenteneinstellungen mit einer ausführlichen Beschreibung im Referenzhandbuch Gathering FlexNet Inventory (Erfassen von FlexNet-Inventar). In jeder Beschreibung ist auch der Registrierungspfad für die Computer-Einstellung enthalten.
- Der Patch muss in dem Format definiert sein, das in der config.ini verwendet wird:
  - In der ersten Zeile befindet sich das Äquivalent des Registrierungspfads in eckigen Klammern.
  - In der zweiten Zeile steht der Name der Einstellung und (falls erforderlich) der Wert.
Beispiel: Ihr Patch soll die Nutzung von CRLs (Sperrlisten für Zertifikate) innerhalb des Clusters deaktivieren. Wenn Sie die Einstellung nachschlagen, sehen Sie, dass der Registrierungspfad in der Form [Registry]\ManageSoft\Common definiert ist (wobei der Platzhalter für verschiedene Formen von [Registry] ausgelassen werden muss, da config.ini als eine dieser Formen fungiert). Sie erstellen also eine Datei namens (sagen wir) patch.ini, die diese beiden Zeilen enthält:
```
[ManageSoft\Common]
CheckCertificateRevocation=False
```
Tipp: So gehen Sie bei mehreren Änderungen vor:
- Um mehrere Patches mit derselben Datei auszuliefern, fügen Sie ein ähnliches Zeilenpaar für jede Einstellungsänderung hinzu. Zur besseren Lesbarkeit können Sie eine Leerzeile zwischen den patchdefinierenden Zeilenpaaren einfügen.
- Um mehrere einzelne Dateien aufzunehmen, listen Sie diese im nächsten Schritt einzeln auf. Hüten Sie sich jedoch davor, in den einzelnen Dateien sich überschneidende Änderungen zu definieren. Wenn mehrere Dateien angegeben werden, werden sie in der Reihenfolge verarbeitet, in der sie im Verzeichnis aufgeführt sind (in der Regel alphabetisch nach Dateinamen). Wenn es sich überschneidende Änderungen gibt, hat der Wert Bestand, der in der zuletzt verarbeiteten Datei vorhanden ist.
Erstellen Sie eine configmap im flexera-Namensraum, um Ihre Patch-Datei(en) zu hinterlegen.
Tipp: Der flexera-Namensraum ist Pflicht.
Sie können der configmap einen beliebigen Namen geben (der wie üblich nur aus Kleinbuchstaben, Zahlen, '-' oder '.' bestehen darf). Der Name könnte zum Beispiel agent-config lauten. Wenn wir patch.ini aus unserem vorherigen Beispiel als die Datei zugrunde legen, die den zu übernehmenden Patch enthält, sieht die Befehlszeile folgendermaßen aus:
```
kubectl create configmap agent-config --namespace flexera --from-file=patch.ini
```
Hier müssen Sie die vorhandenen Werte natürlich durch Ihre eigenen Namen für configmap und die Patch-Datei ersetzen.
Ändern Sie die YAML-Datei für den Kubernetes-Inventarisierungsagenten von Flexera (siehe Ändern der Konfiguration für den Kubernetes-Inventarisierungsagenten von Flexera), um auf die neu erstellte configmap zu verweisen.
Dies erreichen Sie, indem Sie das Attribut spec.monitor.configPatch setzen, dessen Wert eine ConfigMapVolumeSource ist, ein Kubernetes-Typ also, der beschreibt, wie eine configmap in ein Speicher-Volume konvertiert werden muss. In der Regel muss der Wert nur durch den Namen auf die configmap verweisen. Beispiel: Wenn wir den Namen agent-config aus dem obigen Beispiel für die configmap verwenden, sieht der geänderte Abschnitt der YAML-Datei folgendermaßen aus:
```
apiVersion: agents.flexera.com/v1
kind: KRM
spec:
  monitor:
    configPatch:
      name: agent-config
```

Tipp: Weitere Hintergrundinformationen für ein tieferes Verständnis der involvierten Prozesse: Nachdem Sie Ihre Patches angelegt und in einer configmap ausgewiesen haben, wird der automatische Vorgang der Übernahme der Updates in die Datei config.ini folgendermaßen in die allgemeine Instanziierung und den Betriebszyklus des Kubernetes-Inventarisierungsagenten von Flexera integriert:

Der Container für den Kubernetes-Inventarisierungsagenten von Flexera wird erstellt und enthält zu diesem Zeitpunkt die unveränderte Pseudo-Registry-Konfigurationsdatei config.ini, die ursprünglich mit dem FlexNet-Inventarisierungsagenten ausgeliefert wurde.
Die in der YAML-Datei definierte configmap wird als Dateisystem eingebunden.
Das Binärprogramm für den Kubernetes-Inventarisierungsagenten von Flexera wird innerhalb des Containers ausgeführt.
Der Kubernetes-Inventarisierungsagent von Flexera erstellt eine einfache Bootstrap-Config-Datei, in der die Links von/zu seiner Inventarisierungsstation mit den Einstellungen MGSFT_BOOTSTRAP_DOWNLOAD und MGSFT_BOOTSTRAP_UPLOAD spezifiziert sind (weitere Informationen dazu finden Sie im Referenzleitfaden Gathering FlexNet Inventory (Erfassen von FlexNet-Inventar) im Thema Agent third-party deployment: Configure the Bootstrap File for UNIX). Danach führt er mgsconfig -a aus, wodurch die „Antwortdatei“ auf die Konfiguration angewendet wird.
Jetzt erkennt der Kubernetes-Inventarisierungsagent von Flexera das verbundene ConfigMap-Dateisystem und führt für jede Datei mit dem Suffix .ini in diesem Dateisystem mgsconfig -i aus. Dadurch werden die Patches in die Datei config.ini übernommen. Diese Patches enthalten möglicherweise Einstellungen, die zur Kommunikation mit der Inventarisierungsstation erforderlich sind, und sie werden deshalb zu diesem Zeitpunkt übernommen, bevor der Versuch unternommen wird, eine Richtlinie herunterzuladen.
Der Kubernetes-Inventarisierungsagent von Flexera nutzt jetzt die Richtlinienkomponente vom FlexNet-Inventarisierungsagenten und führt mgspolicy -t machine aus, um die neueste config.ini-Datei abzurufen, die auf seiner Inventarisierungsstation verfügbar ist.
Anmerkung: Diese Aktualisierung der config.ini von der Inventarisierungsstation erfolgt nur einmal, nämlich zum Zeitpunkt des Container-Starts. Langfristig laufende Container fragen bei keiner Inventarisierungsstation nach, ob es Änderungen/Updates bei den Einstellungen für die Agentenrichtlinie (in der Datei config.ini) gibt. Darin unterscheiden sie sich vom FlexNet-Inventarisierungsagenten, der auf einem eigenständigen Gerät (nicht in einem Container) installiert ist.
Da die heruntergeladene Geräterichtlinie vermutlich keine clusterspezifischen Patches enthält, führt der Kubernetes-Inventarisierungsagent von Flexera den Befehl mgsconfig -i für alle verfügbaren .ini-Dateien erneut aus, um die Patches in die neu heruntergeladene config.ini-Datei zu übernehmen.
Der Kubernetes-Inventarisierungsagent von Flexera verbindet sich mit Kubernetes und beginnt mit der Erfassung von Inventardaten, wobei die gesammelten Daten in eine .ndi-Datei einfließen.
Asynchron kann der FlexNet-Inventarisierungsagent angestoßen werden, auch Softwarebestand (Inventar) aus dem Container zu erfassen. Er hinterlegt sein Inventar in seiner eigenen .ndi-Datei an dem dauerhaften Speicherplatz, den Sie in der YAML-Datei deklariert haben.
Der Kubernetes-Inventarisierungsagent von Flexera führt dann eine weitere Komponente des FlexNet-Inventarisierungsagenten aus, ndupload, um die .ndi-Datei(en) unter Anwendung der Einstellungen in der Datei config.ini an die Inventarisierungsstation zu übertragen.
Die beiden Agenten fahren eine Zeit lang (per Voreinstellung 24 Stunden) mit der Erfassung von Inventardaten fort und wiederholen dann den Zyklus, der darin besteht, die erfassten Daten in (einer) .ndi-Datei(en) zu sammeln und diese Datei dann zur Inventarisierungsstation hochzuladen.

IT Asset Management (Cloud)

Current