Erstellen von Anwendungen von Drittanbietern

Bevor Sie mit der Entwicklung einer Drittanbieteranwendung beginnen, laden Sie das JET SDK für Junos OS Evolved und das JET Toolkit für Junos OS Evolved herunter und installieren Sie es. Sie finden diese Dateien auf der Seite Juniper Extension Toolkit (For Junos Evolved):

• Das JET-SDK für Junos OS weiterentwickelt: jet-junos-evo-sdk--releaseEVO.deb

• Das JET Toolkit für Junos OS weiterentwickelt: jet-junos-evo-toolkit--releaseEVO.tar.gz

Das Makefile ist eine notwendige Datei zum Erstellen und Installieren Ihrer Drittanbieteranwendung. Das Makefile muss die Pfade für andere Dateien wie die SRC-Datei, die Konfigurationsdatei und .yaml die Datei enthalten. Es steuert auch den Installationsort der erforderlichen Dateien.

SRC-Dateien enthalten den Quellcode für Ihre Anwendung. Sie können SRC-Dateien in C, C++ oder Python schreiben. Diese Dateien sind für die Funktion Ihrer Drittanbieteranwendung erforderlich.

Zu den Skriptdateien gehören Skripts vor der Installation, nach der Installation und vor der Deinstallation. Bei diesen optionalen Dateien handelt es sich um Shellskripts, die Sie an die Anforderungen Ihrer Anwendung anpassen können.

• Vorinstallierte Skripts werden ausgeführt, bevor Sie Ihr Drittanbieterpaket installieren. Diese Skripte werden in der Regel zum Testen und Überprüfen verschiedener Faktoren auf Ihrem Gerät verwendet. Sie können beispielsweise ein Skript vor der Installation erstellen, um die Version von Junos OS Evolved zu überprüfen, die ausgeführt wird, bevor Sie mit der Installation beginnen.

• Skripts nach der Installation werden nach der Installation des Drittanbieterpakets ausgeführt. Diese Skripts enthalten die Befehle, die nach Abschluss der Installation ausgeführt werden sollen. Erstellen Sie z. B. zusätzliche Protokolldateien oder ein Protokollierungsverzeichnis für Ihr Paket.

• Skripts vor der Deinstallation werden ausgeführt, bevor Sie Ihr Drittanbieterpaket deinstallieren. Diese Skripts werden in der Regel verwendet, um Ordner und Dateien zu bereinigen, die während der Installation des Drittanbieterpakets erstellt wurden.

Hinweis:

Alle Skripte müssen bei erfolgreicher Ausführung Null und bei Fehlschlag einen Wert ungleich Null zurückgeben.

Skripte können in jedem beliebigen Ordner erstellt werden. Während der Paketerstellung von Drittanbietern mit dem Jet-evo Tool können Sie die Pfade zu jedem Skripttyp eingeben und sie werden im Ordner /data/var/external//current-evo-version auf Ihrem Gerät installiert. Weitere Informationen zum Jet-evo Werkzeug finden Sie unter Jet-evo-Werkzeugkonfiguration.

Hinweis:

Wenn Sie benutzerdefinierte Skripts erstellen, empfehlen wir, keine Befehle zu verwenden bash , die zusätzliche CLI-Ausgaben erstellen. Sie können die CLI-Ausgabe in Ihre eigene Protokolldatei umleiten.

Servicedateien sind Pflichtdateien für systemd kontrollierte Anwendungen. Diese Dateien steuern die Anwendungsrichtlinien und bestimmen, auf welchen Knoten und Routing-Engines die Anwendung ausgeführt wird.

Sie müssen die Dienstdateien im Ordner etc/systemd/system/ im root-fs Verzeichnis für Ihr Paket ablegen.

Das folgende Beispiel ist eine Datei für eine .service Anwendung mit dem Namen Sample App. Diese .service Datei definiert den Pfad zum Starten der Anwendung und den Systemstatus, der zum Ausführen der Anwendung erforderlich ist.

Die folgenden Felder sind Pflichtfelder und sollten mit der gleichen Syntax wie die Beispieldatei verwendet werden:

• Nach

• Bevor

• OnFailure (OnFailure)

• Arbeitsverzeichnis

• ExecStart

• ExeStopPost

.yamlDateien sind Pflichtdateien für SysMan kontrollierte Anwendungen. Diese Dateien werden verwendet, um anwendungsspezifische Richtlinien zu übergeben, die bei der Erstellung von systemd basierten Service Units und basierten Richtlinien während der Installation verwendet werden. Dateien werden auch verwendet, um zu bestimmen, auf welchen Knoten und SysMan Routing-Engines die Anwendung ausgeführt wird. .yaml

Hinweis:

Wenn Sie sowohl Dateien als auch .yaml .service Dateien für dieselbe Anwendung in ein Paket aufnehmen, haben die Dateiattribute Vorrang, und die .service Anwendung wird als gesteuerte sysman Anwendung behandelt.

An Pakete von Drittanbietern können mehr als ein Dienst angehängt sein. Jede Anwendung, die von gesteuert wird, muss über eine separate .yaml Datei für jeden angehängten Dienst verfügen, wobei die Dienstnamen als Dateinamen gelten.yaml. Dateinamen sollten mit den Dienstnamen und nicht mit dem Paketnamen übereinstimmen, da sich Paketnamen von Drittanbietern von SysMan den im Paket enthaltenen Diensten unterscheiden können. .yaml

Sie müssen Dateien innerhalb des usr/conf Ordners im root-fs Verzeichnis für Ihr Paket ablegen.yaml.

Eine .yaml Datei besteht aus mehreren Feldern, die Informationen über die entsprechende Anwendung enthalten. In der folgenden Liste finden Sie Definitionen der .yaml Dateifelder:

binpath	Definiert den Pfad zur ausführbaren Binärdatei.
exec-start	Definiert, wie die Anwendung gestartet wird, einschließlich des Pfads und der Argumente, die zum Starten der Anwendung erforderlich sind. Dieses Feld entspricht dem ExecStart Feld in einer systemd Serviceeinheit.
working-dir	Definiert den Pfad zum übergeordneten Verzeichnis mit Binärdateien.
id	Steuert den Namen der Anwendung. Sollte mit dem .yaml Dateinamen übereinstimmen.
network	Legt den Netzwerktyp mit den Werten internal oder fest external. Anwendungen, die außerhalb des Geräts kommunizieren, sollten den external Wert verwenden.
on-exit	Steuert die Einstellung für den Neustart der Anwendung beim Beenden. restart: Steuert, ob die Anwendung beim Beenden mit true oder false -Werten neu gestartet wird.
resource	Legt die Grenzwerte für die von der Anwendung verwendeten Systemressourcen fest: max-memory: Steuert die maximale Menge an Arbeitsspeicher, die von jeder Instanz der Anwendung verwendet werden darf. node-attribute: Steuert den Typ des Knotens, auf dem die Anwendung ausgeführt wird, mit Werten wie -re und fpc. node-type: Steuern Sie den Typ des Knotens, auf dem die Aktion ausgeführt werden soll, mit Werten wie -re und fpc. startup: Steuert, ob die Anwendung nach der Installation gestartet wird, wenn eine benutzerdefinierte Junos OS Evolved-Konfiguration mit true oder-Werten false vorhanden ist. instances: Steuert die Knoten, auf denen die Anwendung ausgeführt wird, und die maximale Anzahl von Instanzen, die ausgeführt werden können. all_nodes: Steuern, ob die Anwendung auf allen Knoten mit true oder false -Werten ausgeführt wird. max_num_of_instances: Steuern Sie die maximale Anzahl von Instanzen, die eine Anwendung mit einem Zahlenwert ausführen kann.

Die folgende Beispieldatei zeigt die Konfiguration für eine Beispielanwendung .yaml , die auf der primären Routing-Engine mit nur 1 Instanz ausgeführt wird. Durch Festlegen des all_nodes Felds auf false wird verhindert, dass die Anwendung auf allen Routing-Engines ausgeführt wird. Durch Festlegen des max_number_of_instances Felds 1 wird die Anwendung auf 1 Instanz beschränkt. Durch Festlegen des node-attribute Felds auf wird die Anwendung auf -re der Routing-Engine ausgeführt. Wenn mit dieser Konfiguration die primäre Routing-Engine ausfällt, wird die Anwendung automatisch auf der Backup-Routing-Engine gestartet.

Das Jet-evo Tool wird verwendet, um das Drittanbieterpaket zu benennen, die Versionsnummer festzulegen, Installationsskripts auszuführen und den Installationspfad für das Drittanbieterpaket festzulegen. Diese Variablen werden alle durch Optionen gesteuert, die beim Ausführen des jet-evo Befehls festgelegt werden:

Hinweis:

Unter Generieren von Signaturschlüsseln finden Sie Informationen zum Generieren eines privaten Schlüssels für die Verwendung mit dem Jet-evo Tool.

• Erforderliche Argumente
• Optionale Argumente
• Beispielsyntax