Konfiguration angepasster Ressourcen für die IBM Mobile Foundation

Parameter

Kundenspezifische geheime Anmeldeschlüssel für die Konsole erstellen [optional]

Standardmäßig werden die geheimen Anmeldeschlüssel für die Konsole für alle Mobile-Foundation-Komponenten automatisch während der Implementierung erstellt. Sie haben aber die Möglichkeit, explizit einen geheimen Anmeldeschlüssel für den Zugriff auf die Server-, Analytics- und Application-Center-Konsole zu erstellen. Nachfolgend sehen Sie ein Beispiel.

Server:

kubectl create secret generic serverlogin --from-literal=MFPF_ADMIN_USER=admin --from-literal=MFPF_ADMIN_PASSWORD=admin

Analytics:

kubectl create secret generic analyticslogin --from-literal=MFPF_ANALYTICS_ADMIN_USER=admin --from-literal=MFPF_ANALYTICS_ADMIN_PASSWORD=admin

Analytics Receiver:

kubectl create secret generic analytics_recvrsecret --from-literal=MFPF_ANALYTICS_RECVR_USER=admin --from-literal=MFPF_ANALYTICS_RECVR_PASSWORD=admin

Application Center:

kubectl create secret generic appcenterlogin --from-literal=MFPF_APPCNTR_ADMIN_USER=admin --from-literal=MFPF_APPCNTR_ADMIN_PASSWORD=admin

HINWEIS: Wenn diese geheimen Schlüssel nicht zur Verfügung gestellt werden, werden sie während der Installation der Mobile Foundation mit dem Standardbenutzernamen admin und dem Kennwort admin erstellt.

Geheimen TLS-Schlüssel für die Ingress-Konfiguration erstellen [optional]

Mobile-Foundation-Komponenten können so konfiguriert werden, dass externe Clients unter Verwendung des Hostnamens auf die Komponenten zugreifen. Der Zugriff kann mit einem privaten TLS-Schlüssel und einem TLS-Zertifikat geschützt werden. Der private TLS-Schlüssel und das TLS-Zertifikat müssen in einem geheimen Schlüssel mit den Schlüsselnamen tls.key und tls.crt definiert werden.

Der geheime Schlüssel mf-tls-secret wird in demselben Namespace wie die Zugriffsressource (Ingress) erstellt. Verwenden Sie dafür den folgenden Befehl.

kubectl create secret tls mf-tls-secret --key=/path/to/tls.key --cert=/path/to/tls.crt

Der Name des geheimen Schlüssels wird dann im Feld global.ingress.secret der angepassten YAML-Ressourcenkonfigurationsdatei angegeben.

Kundenspezifischen geheimen Keystore-Schlüssel für Implementierungen erstellen [optional]

Sie können Ihren eigenen Keystore und Truststore für die Implementierung von Server, Analytics und Application Center angeben, indem Sie mit Ihrem eigenen Keystore und Truststore einen geheimen Schlüssel erstellen.

Erstellen Sie vorab einen geheimen Schlüssel mit keystore.jks und truststore.jks sowie ein Keystore- und Truststore-Kennwort. Verwenden Sie dafür die Literale KEYSTORE_PASSWORD und TRUSTSTORE_PASSWORD. Geben Sie den Namen des geheimen Schlüssels im Feld “keystoreSecret” für die betreffende Komponente an.

Im folgenden Beispiel wird ein geheimer Keystore-Schlüssel für die Serverimplementierung unter Verwendung von keystore.jks und truststore.jks erstellt. Außerdem werden die zugehörigen Kennwörter festgelegt.

kubectl create secret generic server-secret --from-file=./keystore.jks --from-file=./truststore.jks --from-literal=KEYSTORE_PASSWORD=worklight --from-literal=TRUSTSTORE_PASSWORD=worklight

HINWEIS: Die Namen der Dateien und Literale müssen mit den Angaben im obigen Befehl übereinstimmen. Geben Sie diesen Namen des geheimen Schlüssels im Eingabefeld keystoresSecretName der jeweiligen Komponente an, um die Standard-Keystores beim Konfigurieren des Helm-Charts außer Kraft zu setzen.

Geheime Schlüssel für vertrauliche Clients erstellen [optional]

Mobile Foundation Server ist vorab mit vertraulichen Clients für den Verwaltungsservice definiert. Die Berechtigungsnachweise für diese Clients werden in den Feldern mfpserver.adminClientSecret und mfpserver.pushClientSecret angegeben.

Sie können diese geheimen Schlüssel wie folgt erstellen:

kubectl create secret generic mf-admin-client --from-literal=MFPF_ADMIN_AUTH_CLIENTID=admin --from-literal=MFPF_ADMIN_AUTH_SECRET=admin

kubectl create secret generic mf-push-client --from-literal=MFPF_PUSH_AUTH_CLIENTID=admin --from-literal=MFPF_PUSH_AUTH_SECRET=admin

Wenn die Werte für die Felder mfpserver.pushClientSecret, mfpserver.adminClientSecret und mfpserver.liveupdateClientSecret nicht während der Helm-Chart-Installation angegeben werden, werden standardmäßig geheime Clientschlüssel mit den folgenden Berechtigungsnachweisen erstellt:

• admin / nimda für mfpserver.adminClientSecret
• push / hsup für mfpserver.pushClientSecret
• liveupdate / etadpuevil für mfpserver.liveupdateClientSecret

Angepasste Serverkonfiguration [optional]

Zur Anpassung der Konfiguration (beispielsweise zur Änderung einer Protokolltraceeinstellung, zum Hinzufügen einer neuen JNDI-Eigenschaft usw.) müssen Sie eine Konfigurationszuordnung (configMap) mithilfe der XML-Konfigurationsdatei erstellen. So können Sie eine neue Konfigurationseinstellung hinzufügen oder die vorhandene Konfiguration der Mobile-Foundation-Komponenten überschreiben.

Die Mobile-Foundation-Komponenten greifen auf die angepasste Konfiguration über eine configMap (mfpserver-custom-config) zu, die wie folgt erstellt wird:

kubectl create configmap mfpserver-custom-config --from-file=<Konfigurationsdatei im XML-Format>

Die mit dem obigen Befehl erstellte Konfigurationszuordnung (configMap) muss während der Mobile-Foundation-Implementierung in der angepassten Serverkonfiguration im Helm-Chart angegeben werden.

Es folgt ein Beispiel für die Einstellung der Traceprotokollspezifikation auf Warnungen mithilfe der configMap mfpserver-custom-config. (Standardmäßig ist die Spezifikation auf Informationen eingestellt.)

• XML-Beispielkonfiguration (logging.xml)

<server>
        <logging maxFiles="5" traceSpecification="com.ibm.mfp.*=debug:*=warning"
        maxFileSize="20" />
</server>

• ConfigMap erstellen und während der Helm-Chart-Implementierung hinzufügen

kubectl create configmap mfpserver-custom-config --from-file=logging.xml

• Beachten Sie die Änderung in der Datei messages.log (von Mobile-Foundation-Komponenten): Property traceSpecification will be set to com.ibm.mfp.=debug:*=warning.

Generierte kundenspezifische STPA-Schlüssel verwenden [optional]

Die Mobile-Foundation-Images enthalten standardmäßig eine Reihe von LTPA-Schlüsseln (ltpa.keys) für die Mobile-Foundation-Komponenten. Wenn die sofort einsatzfähigen LTPA-Schlüssel (ltpa.keys) in einer Produktionsumgebung durch generierte kundenspezifische Schlüssel ersetzt werden müssen, können Sie die angepasste Konfiguration nutzen, um generierte kundenspezifische ltpa.keys zusammen mit der Datei config.xml hinzuzufügen.

Nachfolgend sehen Sie eine Beispielkonfigurationsdatei ltpa.xml.

<server description="mfpserver">
    <ltpa
        keysFileName="ltpa.keys" />
    <webAppSecurity ssoUseDomainFromURL="true" />
</server>

Der folgende Beispielbefehl fügt die kundenspezifischen LTPA-Schlüssel hinzu.

kubectl create configmap mfpserver-custom-config --from-file=ltpa.xml --from-file=ltpa.keys

Weitere Einzelheiten zum Generieren von LTPA-Schlüsseln finden Sie in der Liberty-Dokumentation.

Hinweis: Wenn Sie eine kundenspezifische Konfiguration hinzufügen möchten, dürfen Sie nicht mehrere angepasste configMaps verwenden. Sie sollten stattdessen wie folgt eine configmap für die kundenspezifische Konfiguration erstellen:

kubectl create configmap mfpserver-custom-config --from-file=ltpa.xml --from-file=ltpa.keys --from-file=moreconfig.xml