Diese Komponente benötigt eine lokale Lizenzdatei.
Die Datei wird im Container hier erwartet: /opt/ceyoniq/nscale-pipeliner/workdir/license.xml
.
Achtung! Datenverlust!
Wenn die hier aufgelisteten Ordner nicht persistiert werden, kommt es zum Datenverlust.
Je nach Konfiguration wird der Pipeliner Dateien lesen, schreiben und ändern.
Diese Ordner müssen als Volume oder als Bind-Mount gesichert werden.
Zum Beispiel können folgende Ordner persistiert werden:
/opt/ceyoniq/nscale-pipeliner/workdir/data
/opt/ceyoniq/nscale-pipeliner/workdir/config
docker run --rm \
--network=host \
-v $(pwd)/cold.xml:/opt/ceyoniq/nscale-pipeliner/workdir/config/runtime/cold.xml \
-v $(pwd)/data:/opt/ceyoniq/nscale-pipeliner/workdir/data \
-v $(pwd)/license.xml:/opt/ceyoniq/nscale-pipeliner/workdir/license.xml \
ceyoniq.azurecr.io/release/nscale/pipeliner:ubi.9.2.1501.2024083013
nscale Pipeliner kann als einzige nscale Standard Container-Komponente nicht über Umgebungsvariablen konfiguriert werden. Stattdessen besteht die Möglichkeit, mit nscale Administrator eine Standard-Konfigurationsdatei für nscale Pipeliner zu generieren, ohne nscale Administrator vorher mit nscale Pipeliner verbinden zu müssen.
Das Vorgehen zum Erstellen und Bearbeiten einer solchen cold.xml
ist im nscale Pipeliner Konfigurationshandbuch beschrieben.
Die gesamte nscale-Dokumentation finden Sie in unserem Serviceportal unter https://serviceportal.ceyoniq.com.
Die spezielle Konfiguration richtet sich nach der Umgebung, in der sie verwendet wird. Beachten Sie, dass unter Umständen auch Rechte in nscale für den Betrieb von nscale Pipeliner angepasst werden müssen.
Mit dem Start von nscale Pipeliner wird das Spool-Verzeichnis im aktuellen Ordner angelegt. nscale Pipeliner verwendet das Spool-Verzeichnis, um Dateien kontinuierlich zu importieren.
Unter ./workdir/data
werden später die Eingangsdaten abgeholt.
Die zuvor offline konfigurierte cold.xml
kann ebenfalls in diesem Ordner abgelegt und anschließend in den Container gemappt werden.
Dazu muss die Kommentarzeile unten herausgenommen und der Container neu instanziiert werden.
> vi docker-compose.pipeliner.yml
...
volumes:
- ./workdir/data:/opt/ceyoniq/nscale-pipeliner/workdir/data:rw
#- ./workdir/config/cold.xml:/opt/ceyoniq/nscale-pipeliner/workdir/config/runtime/cold.xml:ro
- ${PIPELINER_LICENSE_FILE}:/opt/ceyoniq/nscale-pipeliner/workdir/license.xml:ro
# Der Container muss neu instanziiert werden
> docker compose up -d pipeliner
# Logs prüfen
> docker compose logs -f pipeliner
In Kubernetes ist nscale Pipeliner als StatefulSet definiert und verwendet vier Volumes:
Volume | Quelle | Beschreibung |
---|---|---|
data |
RWX PersistenceVolumeClaim | Enthält das Spool-Verzeichnis und kann in mehrere Pods gemappt werden, um Daten abzulegen, die vom Pipeliner kontinuierlich importiert werden. |
setup |
config map | Vorbereitung des Pipeliner starts. |
cold |
base/config/pipeliner/cold.xml |
Spezielle, offline erstellte Konfigurationsdatei. |
license.xml |
base/license.xml |
Lizenzdatei |
Zur Aktivierung von nscale Pipeliner müssen Sie in der Datei base/kustomization.yaml
und overlay/*/kustomization.yaml
die Pipeliner Ressourcen einkommentieren.
Die cold.xml
muss offline im nscale Administrator vorkonfiguriert werden damit sie über eine ConfigMap eingebunden werden kann. Da die Konfigurationsdatei Passwörter enthält kann es die Anforderung geben diese in Kubernetes Secrets auszulagern.
Im folgenden wird die Herangehensweise beschrieben, wie Passwörter aus Secrets in die cold.xml
integriert werden bevor der nscale Pipeliner startet.
Achtung: Die Passwörter in der vorkonfigurierten
cold.xml
sind verschlüsselt! Es handelt sich dabei um eine eigene Verschlüsselungsroutine im nscale Administrator. Wenn sich das Passwort ändert muss erneut nscale Administrator benutzt werden um das geänderte Passwort in diecold.xml
einzutragen. Aus dieser neuencold.xml
muss dann das verschlüsselte Passwort extrahiert werden um es in Kubernetes Secrets zu hinterlegen.
-
Erstellen Sie die
cold.xml
offline in nscale Administrator. -
Ersetzen Sie die Passwörter in der
cold.xml
durch Platzhalter und bennen Sie die Datei um incold.tpl
als Vorlage für die anschliesende Transformation. -
Hinterlegen S die Passwörter selbst in Kubernetes Secrets.
kubectl create secret generic pipeliner-secret \
--from-literal=database_user=<user> \
--from-literal=database_pwd=<password> \
--from-literal=appliation_user=<user> \
--from-literal=appliation_pwd=<password> \
--from-literal=storage_user=<user> \
--from-literal=storage_pwd=<password>
- Binden Sie die Passwörter aus dem Secret in den Pipeliner Container als Umgebungsvariablen ein.
env:
- name: DATABASE_USERNAME
valueFrom:
secretKeyRef:
name: pipeliner-secret
key: database_user
- name: DATABASE_PASSWORD
valueFrom:
secretKeyRef:
name: pipeliner-secret
key: database_pwd
- name: APPLICATION_LAYER_USERNAME
valueFrom:
secretKeyRef:
name: pipeliner-secret
key: application_user
- name: APPLICATION_LAYER_PASSWORD
valueFrom:
secretKeyRef:
name: pipeliner-secret
key: application_pwd
- name: STORAGE_LAYER_USERNAME
valueFrom:
secretKeyRef:
name: pipeliner-secret
key: storage_user
- name: STORAGE_LAYER_PASSWORD
valueFrom:
secretKeyRef:
name: pipeliner-secret
key: storage_pwd
- Rollen Sie die erweiterten Skripte in einer Kubernetes Configmap aus.
cold.tpl
: Diecold.xml
Konfiguration ohne Passwörter.cold.xslt
: Style Sheet zur Transformation descold.tpl
Templates mit Umgebungsvariablen in die endgültigecold.xml
.setup.sh
: Erweitertes Setup Skript zur Generierung dercold.xml
aus dem Template bevor der nscale Pipeliner startet.
kubectl create configmap pipeliner-config \
--from-file=template=cold.tpl
--from-file=stylesheet=cold.xslt
--from-file=setup=setup.sh
- Integrieren Sie die Skripte in das Pipeliner Deployment.
volumeMounts:
- name: config
subPath: template
mountPath: /opt/ceyoniq/nscale-pipeliner/workdir/config/runtime/cold.tpl
- name: config
subPath: stylesheet
mountPath: /opt/ceyoniq/nscale-pipeliner/workdir/config/runtime/cold.xslt
- name: config
subPath: setup
mountPath: /setup.sh
volumes:
- name: config
configMap:
name: pipeliner-conf
Die Vorgehensweise kann auch auf andere Konfigurationsdateien angewendet werden.
Die Datei doc_mime_suff.tsv
enthält Konfigurationen für MimeType, DocType und FileExtensions.
Diese Konfiguration kann angepasst werden.
Um Anpassungen an der doc_mime_suff.tsv
vornehmen zu können, benötigen Sie diese Datei auf Ihrem Entwicklungssystem.
Diese Datei können Sie dem Image `ceyoniq.azurecr.io/release/nscale/pipeliner:ubi.9.2.1501.2024083013
Kopieren Sie die Datei doc_mime_suff.tsv
lokal auf Ihr System:
# Erzeugen eines temporären Containers
$ docker create ceyoniq.azurecr.io/release/nscale/pipeliner:ubi.9.2.1501.2024083013
a0123456789
# Kopieren der Datei doc_mime_suff.tsv auf Ihr Entwicklungssystem
docker cp a0123456789:/opt/ceyoniq/nscale-pipeliner/workdir/config/common/doc_mime_suff.tsv ./
# Löschen des temporären Containers
docker rm a0123456789
Um angepasste Dateien in dem jeweiligen Container verwenden zu können, müssen diese dem Container als Bind-Mount oder als Volume zur Verfügung gestellt werden. Je nach Betriebsumgebung unterscheidet sich die Vorgehensweise.
Beispiel Docker:
Um die angepasste doc_mime_suff.tsv
verwenden zu können, muss diese Datei als Bind-Mount verfügbar gemacht werden.
docker run -it ... -v ${PWD}/doc_mime_suff.tsv:/opt/ceyoniq/nscale-pipeliner/workdir/config/common/doc_mime_suff.tsv ceyoniq.azurecr.io/release/nscale/pipeliner:ubi.9.2.1501.2024083013
Beispiel Docker Compose:
Um die angepasste doc_mime_suff.tsv
verwenden zu können, muss diese Datei als Bind-Mount verfügbar gemacht werden.
volumes:
- ./doc_mime_suff.tsv:/opt/ceyoniq/nscale-pipeliner/workdir/config/common/doc_mime_suff.tsv:ro
Beispiel Kubernetes:
Um die angepasste doc_mime_suff.tsv
verwenden zu können, kann diese Datei als ConfigMap
in Kubernetes konfiguriert werden.
Weiter Informationen zu ConfigMap
finden Sie hier:
https://kubernetes.io/docs/concepts/configuration/configmap/