Umgebungsvariablen eines Modules ändern

Owned by Ingolf Kuss
Last updated: Apr 11, 2022
Englisch language version of this page: Change Environment Variables of a Module

So kann man die Umgebungsvariablen (Env Vars) eines Folio-Backend-Moduls ändern:

Beispiel:

# Die Umgebungsvariablen für mod-pubsub sollen in der laufenden Instanz wie folgt geändert werden:
     {
       "name": "KAFKA_HOST",
       "value": "10.9.2.62"
     },
     {
       "name": "OKAPI_URL",
       "value": "http://10.9.2.62:9130"
     }

Diese Variablen muss man sowieso ändern, es sei denn, man deployt mit Vagrant. Denn standardmäßig ist hier der Vagrant-Host 10.0.2.15 voreingestellt.

1 Wenn das Modul schon bereitgestellt ist

In diesem Fall muss das Modul zunächst undeployed werden, und dann erneut bereitgestellt (deployed). Für die erneute Bereitstellung gibt es zwei Möglichkeiten:

1.1 Bereitstellung ohne Okapi

Anleitung:

  1. Erzeugen eines neuen, laufenden Containers für das Moduls mod-pubsub per Hand (z.B. von der Kommandozeile aus, mit Docker-"Bordmitteln")

# 1.) Ziehe das gewünschte Modul aus dem Dockerhub und baue es (create) aus dem Image:
docker pull folioorg/mod-pubsub:1.2.5
# 1.1) Übergib dabei die gewünschten Umgebungsvariablen, abweichend vom Standard:
docker run --detach --name mod-pubsub-1.2.5 -e KAFKA_HOST=10.9.2.62 -e OKAPI_URL="http://10.9.2.62:9130" -e DB_HOST=10.9.2.62 -e DB_PORT=5432 -e DB_USERNAME=okapi -e DB_PASSWORD=okapi25 -e DB_DATABASE=okapi folioorg/mod-pubsub:1.2.5

2. Deployment-Deskriptor bauen

Dazu muss man zuerst mit "docker inspect" herausfinden, wo im Docker-Netzwerk Docker das Modul deployed hat:

docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' mod-pubsub-1.2.5
172.17.0.54
cat > pubsub-deployment-descriptor.json <<END
{
  "srvcId" : "mod-pubsub-1.2.5",
  "instId" : "mod-pubsub-1.2.5",
  "url" : "http://172.17.0.54:8081"
}
END

3. Alle Module für den Mandanten deaktivieren, außer Okapi

Hole die Liste der Module für diesen Mandanten und schreibe in eine Datei

curl -w '\n' -XGET http://localhost:9130/_/proxy/tenants/diku/modules > disable_modules.sh

Sende LÖSCHEN an /_/proxy/tenants/<tenantId>/modules/<moduleId> für jedes Modul in der Liste, aber lasse Okapi aktiviert!

curl -w '\n' -XDELETE http://localhost:9130/_/proxy/tenants/diku/modules/folio_calendar-1.0.100018
curl -w '\n' -XDELETE http://localhost:9130/_/proxy/tenants/diku/modules/folio_checkin-1.1.100049
curl -w '\n' -XDELETE http://localhost:9130/_/proxy/tenants/diku/modules/folio_checkout-1.1.4000158
...

Aufgrund "fehlender Anhängigkeiten" werden nicht alle Module gelöscht. Zuerst die fehlenden Abhängigkeiten löschen. Dann das Löschen aller Module (ein Skript dafür schreiben!) sooft ausführen, bis alles gelöscht ist. Am Ende darf nur noch stehen:

curl -w '\n' -XGET http://localhost:9130/_/proxy/tenants/diku/modules
[ {
  "id" : "okapi-3.1.2"
} ]


4. Die in Okapi angemeldete Modul-Instanz von mod-pubsub undeployen

# zuerst Service-Id und InstId des Moduls holen:
curl -w '\n' -XGET http://localhost:9130/_/discovery/modules | jq '.[] | .srvcId + "/" + .instId' | grep pubsub
curl -w '\n' -D - -XDELETE http://localhost:9130/_/discovery/modules/mod-pubsub-1.2.5/8cd2ed01-08b3-44f1-8935-ec57a65f386b
HTTP/1.1 204 No Content
Content-Type: application/json
X-Okapi-Trace: DELETE okapi-3.1.2 /_/discovery/modules/mod-pubsub-1.2.5/8cd2ed01-08b3-44f1-8935-ec57a65f386b : 204 10759321us


5.  Bereitstellen: Den neuen Deployment-Deskriptor von mod-pubsub an $OKAPI_URL/_/discovery/modules senden

curl -i -w '\n' -X POST -H 'Content-type: application/json' -d @pubsub-deployment-descriptor.json http://localhost:9130/_/discovery/modules
HTTP/1.1 201 Created
Content-Type: application/json
Location: /_/discovery/modules/mod-pubsub-1.2.5/mod-pubsub-1.2.5
X-Okapi-Trace: POST okapi-3.1.2 /_/discovery/modules : 201 9906us
content-length: 105
 
{
  "instId" : "mod-pubsub-1.2.5",
  "srvcId" : "mod-pubsub-1.2.5",
  "url" : "http://172.17.0.54:8081"
}


6. Re-aktiviere alle Module für den Mandanten

# Alle Backend-Module aktivieren:
curl -w '\n' -D - -X POST -H "Content-type: application/json" -d @/usr/folio/platform-complete/okapi-install.json http://localhost:9130/_/proxy/tenants/diku/install?deploy=false\&preRelease=false
# auch die Frontend- und Edge-Module wieder aktivieren:
curl -w '\n' -D - -X POST -H "Content-type: application/json" -d @/usr/folio/platform-complete/stripes-install.json http://localhost:9130/_/proxy/tenants/diku/install?preRelease=false


Nun mal einen Gesundheitscheck machen:

curl -w '\n' -XGET http://localhost:9130/_/discovery/health
# => Alles "OK"


1.2 Bereitstellung mit Okapi

Die Umgebungsvariablen für das Modul werden beim Deploy mit Okapi aus den Umgebungsvariablen von Okapi vererbt. Daher muss man nur die Umgebungsvariablen von Okapi setzen, und anschließend das Modul Re-Deployen.

Hier die Kurzzusammenfassung:

# 1. Umgebungsvariablen von Okapi setzen

 curl -w '\n' -D - -X POST -H "Content-Type: application/json" -d "{\"name\":\"KAFKA_HOST\",\"value\":\"10.9.2.62\"}" http://localhost:9130/_/env;

 curl -w '\n' -D - -X POST -H "Content-Type: application/json" -d "{\"name\":\"OKAPI_URL\",\"value\":\"http://10.9.2.62:9130\"}" http://localhost:9130/_/env;

# 2. Das Modul deaktivieren

curl -w '\n' -D - -X POST -H "Content-type: application/json" -d '[ { "id" : "mod-pubsub-2.4.2", "action" : "disable" } ]' http://localhost:9130/_/proxy/tenants/diku/install?simulate=true

curl -w '\n' -D - -X POST -H "Content-type: application/json" -d '[ { "id" : "mod-pubsub-2.4.2", "action" : "disable" } ]' http://localhost:9130/_/proxy/tenants/diku/install?deploy=false\&preRelease=false

# 3.  Das Modul undeployen
curl -w '\n' -X DELETE http://localhost:9130/_/discovery/modules/mod-pubsub-2.4.2
# 4. Redploy des Moduls (mit Okapi)

curl -w '\n' -D - -X POST -H "Content-type: application/json" -d '[{ "id": "mod-pubsub-2.4.2", "action": "enable"}]' http://localhost:9130/_/proxy/tenants/diku/install?simulate=true\&preRelease=false
curl -w '\n' -D - -X POST -H "Content-type: application/json" -d '[{ "id": "mod-pubsub-2.4.2", "action": "enable"}]' http://localhost:9130/_/proxy/tenants/diku/install?deploy=true\&preRelease=false\&tenantParameters=loadSample%3Dfalse%2CloadReference%3Dtrue

# 5. Module, die unter 2. deaktiviert wurden, wieder aktivieren

curl -w '\n' -D - -X POST -H "Content-type: application/json" -d@/usr/folio/platform-complete/install.json http://localhost:9130/_/proxy/tenants/diku/install?simulate=true\&preRelease=false

curl -w '\n' -D - -X POST -H "Content-type: application/json" -d@/usr/folio/platform-complete/install.json http://localhost:9130/_/proxy/tenants/diku/install?deploy=false\&preRelease=false\&tenantParameters=loadSample%3Dfalse%2CloadReference%3Dtrue


2 Wenn das Modul noch nicht läuft (noch nicht bereitgestellt ist)

Dieser Anwendungsfall wird üblicherweise auftreten, wenn man das komplette System re-deployt, z.B. bei einem Release-Wechsel.

2.1 Bereitstellung ohne Okapi

Die Umgebungsvariablen des bereitzustellenden Moduls sind im jeweiligen Deployment-Tool einzustellen (z.B. Rancher-UI, Kommandozeilenparameter für "docker", ...)

2.2 Bereitstellung mit Okapi

Hier fallen mir zwei verschiedene Methoden ein:

2.2.1 Steuerung über den Moduldeskriptor (genauer: Launch-Deskriptor)

Streng genommen sind diese Schritte in diese Installationsanleitung einzubauen : https://github.com/folio-org/folio-install/tree/master/runbooks/single-server (andererseits aber auch nicht, denn diese Inst.Anl. ist ausgewiesenermaßen nur für Deployment mit Vagrant):

Nach dem Schritt "Installiere und Konfiguriere Okapi" : "Ziehe Moduldeskriptoren aus dem zentralen Register" den Moduldeskriptor für mod-pubsub noch mal einzeln holen:

wget http://folio-registry.aws.indexdata.com/_/proxy/modules/mod-pubsub-1.2.5 -O pubsub-module-descriptor.json

Die Variablen darin manuell anpassen; den Launch-Deskriptor in dem Moduldeskriptor anpassen:

vim pubsub-module-descriptor.json
"launchDescriptor" : {
    "dockerImage" : "folioorg/mod-pubsub:1.2.5",
    "dockerPull" : true,
    "env" : [ {
      "name" : "JAVA_OPTIONS",
      "value" : "-XX:MaxRAMPercentage=66.0 -XX:+HeapDumpOnOutOfMemoryError"
    }, {
      "name" : "DB_HOST",
      "value" : "10.9.2.62"
    }, {
      "name" : "DB_PORT",
      "value" : "5432"
    }, {
      "name" : "DB_USERNAME",
      "value" : "okapi"
    }, {
      "name" : "DB_PASSWORD",
      "value" : "okapi25"
    }, {
      "name" : "DB_DATABASE",
      "value" : "okapi"
    }, {
      "name" : "DB_QUERYTIMEOUT",
      "value" : "60000"
    }, {
      "name" : "DB_CHARSET",
      "value" : "UTF-8"
    }, {
      "name" : "DB_MAXPOOLSIZE",
      "value" : "5"
    }, {
      "name" : "KAFKA_HOST",
      "value" : "10.9.2.62"
    }, {
      "name" : "KAFKA_PORT",
      "value" : "9092"
    }, {
      "name" : "OKAPI_URL",
      "value" : "http://10.9.2.62:9130"
    } ],

Den Moduldeskriptor in /_/proxy/modules überschreiben (das ist möglich, da das Modul noch nicht deployed/aktiviert ist):

curl -i -w '\n' -X POST -H 'Content-type: application/json' -d @pubsub-module-descriptor.json http://localhost:9130/_/proxy/modules

Jetzt ganz normal mit der Standard-Installationsanleitung fortfahren (Mandanten erzeugen, ..., alle Module mit Okapi bereitstellen (deploy=true) und aktivieren).


2.2.2 Steuerung über globale Umgebungsvariablen ( (warning) geht das ? Habe ich noch nicht ausprobiert!)

Man könnte versuchen, die Systeminstallation nach Schema F durchzuführen, also genauso, also ob man die Module mit Standard-Umgebungsvariablen bereitstellen will. Den Moduldeskriptor nicht ändern. Dafür an der Stelle "Post data source information to the Okapi environment for use by deployed modules" zusätzlich zu den Datenbank-Verbindungsvariablen auch noch die neuen Modul-Umgebungsvariablen als globale Umgebungsvariablen dem Okapi bekanntgeben. Sie würden dann global für alle Module gelten :

curl -w '\n' -D - -X POST -H "Content-Type: application/json" -d "{\"name\":\"KAFKA_HOST\",\"value\":\"10.9.2.62\"}" http://localhost:9130/_/env
curl -w '\n' -D - -X POST -H "Content-Type: application/json" -d "{\"name\":\"OKAPI_URL\",\"value\":\"http://10.9.2.62:9130\"}" http://localhost:9130/_/env

Dann ganz normal alle Backend-Module mit curl -w '\n' -D - -X POST -H "Content-type: application/json" -d @/usr/folio/platform-complete/okapi-install.json http://localhost:9130/_/proxy/tenants/diku/install?deploy=true\&preRelease=false
mit Okapi bereitstellen und für den Mandanten aktivieren. 
Ob das funktioniert, weiß ich allerdings nicht. Jason Root wusste das auch nicht, fand das aber interessant. Ich werde das beim nächsten Release-Wechsel auf jeden Fall ausprobieren. Das wäre die eleganteste Methode, (bei Okapi-Deployment) Modul-Umgebungsvariablen zu überschreiben.