Administration · Node-RED

Node-RED-Erweiterungen bereitstellen

Prüfen Sie zusätzliche Nodes vor ihrem Einsatz, erproben Sie ausdrücklich freigegebene Pakete kontrolliert und rollen Sie produktive Abhängigkeiten exakt versioniert über das bestehende Flow-Projekt aus.

Eine Node-RED-Erweiterung fügt der Laufzeit ausführbaren Code und häufig neue Verbindungen zu Datenquellen oder Zielsystemen hinzu. Ihre Installation ist deshalb eine administrative Änderung. Sie wird nicht allein dadurch freigegeben, dass ein Paket in der Palette gefunden oder in einer laufenden Instanz installiert werden kann.

Bestand

Vorhandenen Node prüfen

Palette und Projektabhängigkeiten kontrollieren, bevor ein weiteres Paket bewertet wird.

→

Freigabe

Paket bewerten

Version, Lizenz, Wartbarkeit, Kompatibilität und Sicherheitswirkung nachvollziehbar prüfen.

→

Erprobung

Kontrolliert installieren

Den freigegebenen Kandidaten in einer vorgesehenen Test- oder verwalteten Instanz erproben.

→

Produktion

Reproduzierbar ausrollen

Exakte Abhängigkeit und Flow gemeinsam über Git und den bestehenden Bereitstellungsweg ausliefern.

1. Zuerst den vorhandenen Bestand prüfen

Installieren Sie nicht vorschnell ein zweites Paket für dieselbe Aufgabe. Prüfen Sie in der vorgesehenen Node-RED-Instanz:

1. Suchen Sie in der linken Node-Palette nach dem benötigten Node oder seiner fachlichen Aufgabe.
2. Öffnen Sie im Hauptmenü Manage palette und kontrollieren Sie unter Nodes die bereits installierten Pakete und Versionen.
3. Prüfen Sie im aktiven Flow-Projekt, ob die benötigte Abhängigkeit bereits in der package.json geführt wird.
4. Vergleichen Sie die Aufgabe mit der HYPERTEGRITY Node-RED-Bibliothek. Ein gemeinsamer UDSP-Baustein hat Vorrang, wenn er den benötigten Schritt bereits geeignet abbildet.
5. Klären Sie bei einem vorhandenen, aber nicht sichtbaren Node zuerst, ob das richtige Projekt geöffnet ist oder die installierte Abhängigkeit nach dem letzten Rollout fehlerfrei geladen wurde.

Ein ähnlich benannter Node ist noch kein Ersatz. Vergleichen Sie unterstütztes Protokoll, Nachrichtenfelder, Authentifizierung, Fehlerverhalten und Zielversion von Node-RED.

2. Paket und Version für die Erprobung freigeben

Halten Sie die Prüfung für den konkreten Paketstand fest. Eine Freigabe nur auf Basis des Paketnamens oder des Tags latest ist nicht ausreichend.

Prüfpunkt	Zu klären	Nachweis für die Entscheidung
Paket und Herkunft	Ist das richtige Paket aus einer vertrauenswürdigen Registry beziehungsweise dem vorgesehenen Quellrepository ausgewählt?	Eindeutiger Paketname, Herausgeber und Quelladresse
Version	Welcher konkrete Stand soll getestet und später ausgerollt werden?	Exakte Versionsnummer ohne automatische Bereichsaktualisierung
Lizenz	Darf die Erweiterung unter den Bedingungen des Projekts betrieben und verteilt werden?	Geprüfte Lizenz und dokumentierte Freigabe
Wartbarkeit	Wird das Paket nachvollziehbar gepflegt und sind offene Sicherheits- oder Funktionsprobleme vertretbar?	Veröffentlichungsstand, Änderungsverlauf, bekannte Probleme und verantwortliche Stelle
Kompatibilität	Passt die Version zur eingesetzten Node-RED- und Node.js-Version sowie zu vorhandenen Nodes?	Test in einer technisch vergleichbaren Instanz ohne Lade- oder Abhängigkeitsfehler
Sicherheitswirkung	Welche Netzverbindungen, Dateizugriffe, Credentials und Nachrichtendaten verarbeitet der Node?	Begrenzte Rechte, freigegebene Endpunkte und geeigneter Secret-Weg
Betrieb und Rücknahme	Wer beobachtet Fehler und wie wird auf den vorherigen Projektstand zurückgekehrt?	Verantwortung, Testfälle und nachvollziehbarer Rollback über Git und Bereitstellung

Freigabe gilt für eine konkrete Version

Eine neuere Version ist eine neue Änderung. Prüfen Sie Release-Hinweise, Kompatibilität und bekannte Risiken erneut, bevor die Projektabhängigkeit angehoben wird. Aktivieren Sie keine automatische Aktualisierung produktiver Node-RED-Pakete.

3. Freigegebenes Paket kontrolliert über die Node-RED-Oberfläche erproben

Der Palette Manager ist ein geeigneter Bedienweg, wenn die Installation für eine ausdrücklich vorgesehene Testinstanz oder einen administrativ verwalteten Erprobungsweg freigegeben wurde:

1. Öffnen Sie die richtige Test- beziehungsweise verwaltete Node-RED-Instanz und kontrollieren Sie das aktive Projekt.
2. Öffnen Sie das Hauptmenü und wählen Sie Manage palette.
3. Wechseln Sie zum Reiter Install und suchen Sie nach dem vollständigen, geprüften Paketnamen.
4. Vergleichen Sie Herausgeber, Beschreibung und angezeigten Versionsstand mit der Freigabeentscheidung.
5. Wählen Sie Install nur für den ausdrücklich freigegebenen Kandidaten und bestätigen Sie die angezeigten Hinweise.
6. Prüfen Sie nach dem Laden, welche neuen Nodes in der Palette erschienen sind und ob bestehende Nodes weiterhin ohne Ladefehler verfügbar sind.
7. Bauen Sie einen kleinen Testflow mit ungefährlichen Beispieldaten. Prüfen Sie einen Erfolgsfall und mindestens einen kontrollierten Fehlerfall.

Eine UI-Installation ist noch kein produktiver Rollout

Eine ausschließlich über Manage palette vorgenommene Installation beschreibt den benötigten Projektstand nicht zuverlässig. Sie kann nach Neustart, Neuaufbau oder Verschieben der Instanz fehlen. Verwenden Sie diesen Weg deshalb nur für die freigegebene Erprobung beziehungsweise einen ausdrücklich verwalteten Ablauf. Für Produktion muss die Abhängigkeit zusätzlich exakt im Flow-Projekt versioniert und über den bestehenden Bereitstellungsweg ausgerollt werden.

4. Produktive Abhängigkeit im Flow-Projekt versionieren

Tragen Sie nach erfolgreicher Freigabe genau die geprüfte Version in die package.json des Node-RED-Projekts ein. Verwenden Sie weder latest noch einen Versionsbereich mit ^ oder ~:

package.json – schematisches Beispiel

{
  "dependencies": {
    "node-red-contrib-beispiel": "1.2.3"
  }
}

Die Paketänderung wird gemeinsam mit dem Flow umgesetzt:

1. Nehmen Sie die exakt versionierte Abhängigkeit und den Testflow in den vorgesehenen Projektbranch auf.
2. Prüfen Sie im Git-Diff, dass keine Credentials, Tokens oder produktiven Payloads in Projektdateien gelangt sind.
3. Versionieren und prüfen Sie die Änderung nach Node-RED-Flows versionieren.
4. Lassen Sie Paketänderung, Flow und Rücknahmeweg nach dem vereinbarten Reviewverfahren freigeben.
5. Rollen Sie den freigegebenen Projektstand über den für die Instanz bereits bestehenden Git- und Bereitstellungsweg aus.
6. Kontrollieren Sie nach Deployment beziehungsweise Neustart, dass die Laufzeit genau den freigegebenen Paketstand geladen hat.

Eine nachträgliche manuelle Installation in jedem Pod oder jeder Instanz ist kein reproduzierbarer Bereitstellungsweg. Ebenso wird eine produktive Erweiterung nicht direkt im Palette Manager aktualisiert, ohne die Projektabhängigkeit und den geprüften Git-Stand nachzuführen.

Sicherheitsgrenze für Credentials

Aktuell ist kein Projekt-Credential-Secret konfiguriert

Der aktuelle UDSP-Bootstrap setzt für ein automatisch verbundenes Node-RED-Projekt credentialSecret: false. Damit ist für dieses Projekt kein projektspezifisches Secret zur Verschlüsselung der Credential-Datei eingerichtet. Behandeln Sie Credential-Felder deshalb nicht allein aufgrund der maskierten Editoranzeige als ausreichend geschützten Speicher und übernehmen Sie keine produktiven S3-, Datenbank- oder API-Zugangsdaten in Flow-Dateien, Projektdateien oder Git.

Eine Erweiterung, die produktive S3-, Datenbank- oder API-Credentials benötigt, darf erst ausgerollt werden, wenn für die Zielinstanz ein sicherer Secret-Weg bereitsteht. Dabei gilt:

• Das Secret wird außerhalb von Git, Flow-Exporten, Screenshots und normalen Nachrichten verwaltet.
• Der ausgewählte Node kann das Secret über einen dafür vorgesehenen Credential-, Secret- oder geschützten Konfigurationsweg beziehen.
• Zugriff, Rotation, Wiederherstellung und Zuständigkeit sind für die konkrete Instanz geklärt.
• Das technische Konto besitzt nur Rechte auf den benötigten Bucket, die benötigte Datenbank beziehungsweise den vorgesehenen API-Bereich.
• Debug-Ausgaben und Fehlerpfade geben weder Secrets noch vollständige schützenswerte Payloads aus.

Solange diese Voraussetzung nicht erfüllt ist, beschränkt sich die Erprobung auf ungefährliche Testdaten und Testzugänge. Die Installation einer Erweiterung behebt die fehlende Secret-Bereitstellung nicht.

5. Bereitstellung nach Deployment oder Neustart prüfen

Palette

Node geladen

Der erwartete Node erscheint genau einmal und ohne Ladefehler in der Palette.

Projekt

Version stimmt

Die geladene Paketversion entspricht der exakt freigegebenen Abhängigkeit im Projekt.

Flow

Datenweg funktioniert

Erfolgsfall und erwartetes Ergebnis wurden nach dem Rollout erneut geprüft.

Fehlerpfad

Fehler bleiben kontrolliert

Ungültige Eingaben und ein nicht erreichbares Ziel führen in den vorgesehenen Fehlerpfad, ohne Secrets offenzulegen.

Prüfen Sie zusätzlich, dass vorhandene Flows keine unbekannten Nodes melden, Deploy und Neustart ohne wiederholte Ladefehler funktionieren und der freigegebene Projektstand im Git-Repository nachvollziehbar ist. Schlägt die Prüfung fehl, nehmen Sie nicht nur den Node aus der sichtbaren Palette, sondern stellen Sie den letzten freigegebenen Projektstand über den vereinbarten Rücknahme- und Bereitstellungsweg wieder her.

Referenzen