Im ersten Teil dieser Serie haben wir gelernt wie Service Commander das Verwalten bestehender TCPSVR-Instanzen auf der IBM i vereinfacht. Zusätzlich dazu kann Service Commander verwendet werden, um fortlaufende Dienste und Serverinstanzen, die mit PASE-Technologien wie Node.js und Python entwickelt wurden, zu verwalten. In diesem Teil werden wir ein Node.js-Projekt einrichten, um diese Funktionalitäten zu erkunden.
Voraussetzungen
Service Commander muss auf dem System installiert sein (siehe den oben verlinkten Artikel).
In diesem Artikel werden wir Node.js verwenden, jedoch gelten alle beschriebenen Schritte auch für Python oder andere PASE-Sprachen bzw. Laufzeitumgebungen. Dabei ist zu beachten, dass auf der IBM i die jeweiligen Laufzeitumgebungen installiert sein müssen:

scinit
Wie im ersten Teil der Serie beschrieben ermöglicht scinit die Erstellung von Konfigurationsdateien für einen beliebiges ausführbares Programm. Ich habe das obige Beispielprojekt mit git auf meine IBM i geklont und kann nun im Projektordner scinit ausführen. Hiermit kann ich nun eine Konfigurationsdatei erstellen, die diesen Dienst repräsentiert.
Da ich diesen Dienst nur für meinen Benutzer einrichte, befindet sich die Konfigurationsdatei in folgendem Ordner:
/home/GUENEY/.sc/services/node_sc_beispiel.yml
Globale Dienste werden in
/QOpenSys/etc/sc/services/genie_copilot.yml
gespeichert.

Und nun können wir den Dienst mit Service Commander starten und stoppen. Sobald der Dienst gestartet ist, können wir uns mit ihm über den entsprechenden Port verbinden. In meinem Beispiel: http://ibmi:10123

Über den Pfad /hello können wir testen, ob der Dienst läuft:

Und über den Pfad /db, können wir die DB2-Verbindung testen. In diesem Fall erhalten wir eine JSON-Darstellung der aktiven Jobs:

Dienste bei Systemstart automatisch starten
Oft möchte man, dass Dienste dieser Art automatisch beim IPL gestartet werden. Dafür gibt es die „autostart“-Gruppe in Service Commander. Alle Dienste, die dieser Gruppe angehören, werden beim Start der IBM i automatisch gestartet. Mit dem scedit-Befehl können wir die Konfigurationsdatei für den obigen Dienst editieren:
scedit ~/.sc/services/node_sc_beispiel.yml

Und den Gruppeneintrag hinzufügen:

Beim nächsten IPL des Systems wird dieser nun automatisch gestartet, jedoch gibt es hier einige Feinheiten, die beachtet werden müssen!
Wichtig
Dienste, die über Service Commander automatisch gestartet werden, werden vom QTCP-Benutzer gestartet. Dies hat gewisse Nachteile, z. B. kann QTCP sich nicht problemlos per ODBC mit der DB2 verbinden.
Eigentlich soll es möglich sein, dass man solche Jobs als Batchjobs einrichtet und dem SBMJOB die Option „user(<username>)“ übergibt, jedoch gibt es aktuell einen Bug in Service Commander, welcher dies verhindert:
GitHub / ThePrez / ServiceCommander-IBM i / issues #220
Da man Service Commander Instanzen aber auch per STRTCPSVR starten kann, kann man alternativ ein eigenes QSTRUPPGM erstellen: IBM i / 7.2 / Changing the IPL startup program
Eine weitere Möglichkeit ist es einen geplanten Job zu erstellen, welcher kurz nach IPL alle Service Commander Instanzen der *AUTOSTART Gruppe startet:

Wenn man diese Variante verwenden möchte, ist es sinnvoll den AUTOSTART-Wert des *SC Servers auf *NO zu setzen:
CHGTCPSVR SVRSPCVAL(*SC) AUTOSTART(*NO)
Wenn man mehrere Instanzen mit STRTCPSVR in Kombination mit Service Commander startet, sollte man folgende Umgebungsvariable einrichten:
ADDENVVAR ENVVAR(SC_TCPSVR_SUBMIT) VALUE('Y') LEVEL(*SYS) REPLACE(*YES)
Um anzuzeigen welche Dienste der *AUTOSTART Gruppe gehören, kann man folgenden Befehl ausführen;
sc status group:autostart
Natürlich ist es auch möglich und empfehlenswert eigene Gruppen zu erstellen. Dazu braucht man lediglich eine beliebige Gruppe in die Konfigurationsdatei schreiben.
Beispiel:


Empfehlungen für automatisch startende Dienste
In der Regel dienen Dienste, die automatisch gestartet werden sollen, als globale Dienste und sollten mit Service Commander als solche erstellt werden. Wie globale Dienste erstellt werden, kann man aus dem ersten Teil dieser Serie entnehmen. Globale Dienste bzw. die dazugehörigen Anwendungen sollten außerhalb von Benutzerspezifischen IFS-Verzeichnissen abgelegt werden. Ein beliebtes Verzeichnis in UNIX und UNIX-ähnlichen Dateisystemen für solche Anwendungen ist /opt.
Der Benutzer, der die Dienste starten soll, muss Zugriff auf die jeweilige Anwendungsverzeichnisse und auf alle Dateisystempfade, die die Anwendung nutzt, haben. D. h. es kann hier sinnvoll sein einen Benutzer nur für Service Commander oder den jeweiligen Service Commander Gruppen zu erstellen. Dadurch erhöht man auch die Granularität der Einstellungen für Zugriffsrechte.
Schlusswort
Hiermit haben wir gelernt, wie wir Node.js, Python und andere PASE-Dienste per Service Commander erstellen, verwalten und autostarten können. Wir haben einige Tücken von Service Commander kennengelernt und Lösungen für diese gefunden. Im nächsten Teil der Serie werden wir einige erweiterte Features erkunden.
Der Autor Kerim Güney schreibt regelmäßig für den TechKnowLetter.
Sie erreichen ihn unter kerim@gueney.io
Für 88 Euro gibt’s hier sechs Monate lang tiefgreifendes IBM i und SQL Wissen. Hier kann man abonnieren.