IBM Mobile Foundation für IBM Cloud Private installieren

Übersicht

Folgen Sie den nachstehenden Anweisungen, um eine MobileFirst-Server-Instanz, eine MobileFirst-Analytics-Instanz, eine MobileFirst-Push-Instanz und eine Instanz des MobileFirst Application Center für IBM Cloud Private zu konfigurieren.

• Stellen Sie sicher, dass die Voraussetzungen erfüllt sind.
• Laden Sie das Passport-Advantage-Archiv mit IBM Mobile Foundation für IBM Cloud Private herunter.
• Laden Sie das Passport-Advantage-Archiv in den IBM Cloud-Private-Cluster.
• Installieren und konfigurieren Sie MobileFirst Server, MobileFirst Analytics (optional), (optional) und das MobileFirst Application Center (optional).

Fahren Sie mit folgenden Abschnitten fort:

• Voraussetzungen
• Passport-Advantage-Archiv mit der IBM Mobile Foundation herunterladen
• Passport-Advantage-Archiv mit der IBM Mobile Foundation laden
• Helm-Charts für die IBM Mobile Foundation installieren und konfigurieren
• Erforderliche Ressourcen
• Installation überprüfen
• Beispielanwendung
• Upgrade für -Helm-Charts und -Releases durchführen
• Migration auf das zertifizierte IBM Cloud Pak für die Mobile Foundation Platform
• Sicherung und Wiederherstellung von MFP-Analytics-Daten
• Deinstallation

Voraussetzungen

Sie müssen über ein IBM Cloud-Private-Konto verfügen und den IBM Cloud-Private-Cluster eingerichtet haben.

Für die Verwaltung von Containern und Images müssen Sie im Rahmen des IBM Cloud-Private-Setups Folgendes auf Ihrer Hostmaschine installieren:

• Docker (installieren und konfigurieren)
• IBM Cloud-CLI (cloudctl)
• Kubernetes-CLI (kubectl)
• Helm (helm)

Die unterstützte Docker-CLI-Version finden Sie hier.

Installieren Sie die gleiche Kube-CLI, IBM Cloud-CLI und Helm-Version wie in Ihrem ICP-Cluster (Download in der IBM Cloud-Private-Management-Konsole und Klick auf Menü > Befehlszeilentools > Cloud-Private-CLI).

Beispiel:

Für die Erstellung von Kubernetes-Artefakten wie geheimen Schlüsseln, persistenten Datenträgern und Anforderungen persistenter Datenträger in IBM Cloud Private benötigen Sie die CLI kubectl.

a. Installieren Sie die kubectl-Tools über die Managementkonsole von IBM Cloud Private. Klicken Sie auf Menü > Befehlszeilentools > Cloud-Private-CLI.

b. Erweitern Sie die Anzeige für Kubernetes-CLI installieren, um das Installationsprogramm mit einem curl-Befehl herunterzuladen. Kopieren Sie den curl-Befehl für Ihr Betriebssystem und führen Sie ihn aus. Fahren Sie dann mit der Installationsprozedur fort.

c. Wählen Sie den curl-Befehl für das betreffende Betriebssystem aus. Für Mac OS können Sie beispielsweise den folgenden Befehl ausführen:

   curl -kLo <Installationsdatei> https://<Cluster-IP-Adresse>:<Port>/api/cli/kubectl-darwin-amd64
   chmod 755 <Pfad_zum_Installationsprogramm>/<Installationsdatei>
   sudo mv <Pfad_zum_Installationsprogramm>/<Installationsdatei> /usr/local/bin/kubectl

Referenzinformationen finden Sie unter Installing the Kubernetes CLI (kubectl).

Passport-Advantage-Archiv mit der IBM Mobile Foundation herunterladen

Das Passport-Advantage-Archiv mit dem IBM Mobile Foundation ist hier verfügbar. Das Passport-Advantage-Archiv mit der Mobile Foundation enthält die Docker-Images und Helm-Charts für die folgenden Komponenten der Mobile Foundation:

• MobileFirst Server
• MobileFirst Push
• MobileFirst Analytics
• MobileFirst Application Center

Zur Vereinfachung der Datenbankinitialisierung gibt es die MobileFirst-Komponente DB-Initialisierung. Im Rahmen der Initialisierungsschritte werden das Mobile-Foundation-Schema und die Mobile-Foundation-Tabellen in der Datenbank erstellt (sofern sie nicht vorhanden sind).

Passport-Advantage-Archiv mit der IBM Mobile Foundation laden

Bevor Sie das Passport-Advantage-Archiv mit der Mobile Foundation laden, müssen Sie Docker einrichten. Anweisungen finden Sie hier.

Führen Sie die nachstehenden Schritte aus, um das Passport-Advantage-Archiv in den IBM Cloud-Private-Cluster zu laden:

1. Melden Sie sich mit dem IBM Cloud-ICP-Plug-in (cloudctl) beim Cluster an.

   Lesen Sie die CLI-Befehlsreferenz in der Dokumentation zu IBM Cloud Private.

   Beispiel:

   cloudctl login -a https://ip:port
   

   Falls Sie die SSL-Validierung übergehen möchten, können Sie im obigen Befehl die Option --skip-ssl-validation verwenden. Bei Verwendung dieser Option werden Sie zur Eingabe von Benutzername und Kennwort Ihres Clusterendpunkts aufgefordert. Fahren Sie nach erfolgreicher Anmeldung mit den nachstehenden Schritten fort.

2. Laden Sie mit folgendem Befehl das Passport-Advantage-Archiv mit der Mobile Foundation:

   cloudctl catalog load-ppa-archive --archive <Archivname> [--clustername <Clustername>] [--namespace <Namespace>]
   

   Der Archivname für die Mobile Foundation ist der Name des Archivs, den Sie über IBM Passport Advantage heruntergeladen haben.

   Sie können --clustername ignorieren, wenn Sie den vorherigen Schritt ausgeführt und den Clusterendpunkt zum Standard für cloudctl gemacht haben.

3. Sie können die Docker-Images und Helm-Charts in der Managementkonsole von IBM Cloud Private anzeigen. Gehen Sie zum Anzeigen von Docker-Images wie folgt vor:
   • Wählen Sie Platform > Container-Images aus.
   • Helm-Charts werden im Katalog angezeigt.

Nach Ausführung der obigen Schritte sehen Sie die hochgeladene Version der -Helm-Charts im ICP-Katalog. MobileFirst Server wird als ibm-mobilefoundation-prod aufgelistet.

Helm-Charts für die IBM Mobile Foundation installieren und konfigurieren

Bevor Sie das MobileFirst Server installieren und konfigurieren, benötigen Sie Folgendes:

Im folgenden Abschnitt sind die Schritte für die Erstellung geheimer Schlüssel zusammengefasst.

Geheime Schlüsselobjekte bieten die Möglichkeit, sensible Daten wie Kennwörter, OAuth-Token, SSH-Schlüssel usw. zu speichern und zu verwalten. Die Aufnahme solcher Daten in einen geheimen Schlüssel ist sicherer und flexibler als die Aufnahme in eine Pod-Definition oder in ein Container-Image.

1. Obligatorisch: Eine vorkonfigurierte Datenbank ist erforderlich, um die technischen Daten der Komponenten Mobile Foundation Server und Application Center zu speichern.

   Sie müssen eines der folgenden unterstützten DBMS verwenden:

   1. IBM DB2
   2. MySQL
   3. Oracle

   Führen Sie die folgenden Schritte aus, wenn Sie die Oracle- oder MySQL-Datenbank verwenden.

   • Die JDBC-Treiber für Oracle und MySQL sind nicht im Installationsprogramm für die Mobile Foundation enthalten. Stellen Sie sicher, dass Sie den JDBC-Treiber haben (für MySQL den Connector/J-JDBC-Treiber, für Oracle den Oracle-Thin-JDBC-Treiber). Erstellen Sie einen angehängten Datenträger und platzieren Sie den JDBC-Treiber unter /nfs/share/dbdrivers.

   • Erstellen Sie einen persistenten Datenträger. Geben Sie dazu die NFS-Hostdetails und den Pfad an, unter dem der JDBC-Treiber gespeichert ist. Es folgt eine Beispieldatei PersistentVolume.yaml: ``` cat «EOF | kubectl apply -f - apiVersion: v1 kind: PersistentVolume metadata: labels: name: mfppvdbdrivers name: mfppvdbdrivers spec: accessModes:
     • ReadWriteMany capacity: storage: 20Gi nfs: path: server: EOF ```

       HINWEIS: Sie müssen die Einträge und zur obigen YAML-Datei hinzufügen.

   • Erstellen Sie eine Anforderung eines persistenten Datenträgers und geben Sie den Namen dieser Anforderung während der Implementierung im Helm-Chart an. Es folgt eine Beispieldatei PersistentVolumeClaim.yaml: ```bash cat «EOF | kubectl apply -f - apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mfppvc namespace: my_namespace spec: accessModes:
     • ReadWriteMany resources: requests: storage: 20Gi selector: matchLabels: name: mfppvdbdrivers volumeName: mfppvdbdrivers status: accessModes:
     • ReadWriteMany capacity: storage: 20Gi EOF ```

       HINWEIS: Sie müssen den richtigen Namespace zur obigen YAML-Datei hinzufügen.

2. Obligatorisch: Für die Anmeldung bei Server, Analytics und Application-Center-Konsole ist ein vorab erstellter geheimer Anmeldeschlüssel erforderlich. Beispiel:

   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=ANALYTICS_ADMIN_USER=admin --from-literal=ANALYTICS_ADMIN_PASSWORD=admin
   

   Application Center:

   kubectl create secret generic appcenterlogin --from-literal=APPCENTER_ADMIN_USER=admin --from-literal=APPCENTER_ADMIN_PASSWORD=admin
   

   HINWEIS: Wenn diese geheimen Schlüssel nicht zur Verfügung gestellt werden, werden sie während der Implementierung des Helm-Charts für die Mobile Foundation mit dem Standardbenutzernamen admin und dem Kennwort admin erstellt.

3. 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.

   Speichern Sie die Dateien keystore.jks und truststore.jks sowie die zugehörigen Kennwörter wie nachfolgend angegeben.

   Beispiel:

   kubectl create secret generic server --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.

4. 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 angegeben.

   HINWEIS: Vermeiden Sie die Verwendung eines Hostnames für den Zugriff, wenn dieser bereits für ein anderes Helm-Release verwendet wurde.

5. 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.

6. 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
   

   HINWEIS: Wenn die Werte für die Felder mfpserver.pushClientSecret und mfpserver.adminClientSecret nicht während der Implementierung des Helm-Charts für die Mobile Foundation bereitgestellt werden, werden eine Standardwerte für Authentifizierungs-ID und geheimen Schlüssel generiert und verwendet. Diese lauten admin/nimda für mfpserver.adminClientSecret und push/hsup für mfpserver.pushClientSecret.

7. Für die Analytics-Implementierung können Sie die folgenden Optionen für das persistente Speichern von Analytics-Daten auswählen:

   a) Der persistente Datenträger (Persistent Volume (PV)) und die Anforderung eines persistenten Datenträgers (Persistent Volume Claim (PVC)) sind bereit, sodass im Helm-Chart der PVC-Name angegeben werden kann.

   Beispiel:

   Beispieldatei PersistentVolume.yaml

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      labels:
        name: mfvol
      name: mfvol
    spec:
      accessModes:
      - ReadWriteMany
      capacity:
        storage: 20Gi
      nfs:
        path: <NFS-Pfad>
        server: <NFS-Server>
   

   HINWEIS: Sie müssen die Einträge und zur obigen YAML-Datei hinzufügen.

   Beispieldatei PersistentVolumeClaim.yaml

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: mfvolclaim
      namespace: <Namespace>
    spec:
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 20Gi
      selector:
        matchLabels:
          name: mfvol
      volumeName: mfvol
    status:
      accessModes:
      - ReadWriteMany
      capacity:
        storage: 20Gi
   

   HINWEIS: Sie müssen den richtigen zur obigen YAML-Datei hinzufügen.

   b) Die dynamische Bereitstellung des Charts wird ausgewählt.

8. Obligatorisch: Sie müssen geheime Datenbankschlüssel für Server, Push und Application Center erstellen. In diesem Abschnitt sind die Sicherheitsmechanismen zur Steuerung des Datenbankzugriffs umrissen. Erstellen Sie mit dem angegebenen Unterbefehl einen geheimen Schlüssel und geben Sie unter den Datenbankdetails den Namen des erstellten geheimen Schlüssels an.

   Führen Sie das folgende Code-Snippet aus, um einen geheimen Datenbankschlüssel für Mobile Foundation Server zu erstellen:

    # Geheimen mfpserver-Schlüssel erstellen
    cat <<EOF | kubectl apply -f -
    apiVersion: v1
    data:
      MFPF_ADMIN_DB_USERNAME: encoded_uname
      MFPF_ADMIN_DB_PASSWORD: encoded_password
      MFPF_RUNTIME_DB_USERNAME: encoded_uname
      MFPF_RUNTIME_DB_PASSWORD: encoded_password
      MFPF_PUSH_DB_USERNAME: encoded_uname
      MFPF_PUSH_DB_PASSWORD: encoded_password
    kind: Secret
    metadata:
      name: mfpserver-dbsecret
    type: Opaque
    EOF
   

   Führen Sie das folgende Code-Snippet aus, um einen geheimen Datenbankschlüssel für das Application Center zu erstellen:

    # Geheimen appcenter-Schlüssel erstellen
    cat <<EOF | kubectl apply -f -
    apiVersion: v1
    data:
      APPCNTR_DB_USERNAME: encoded_uname
      APPCNTR_DB_PASSWORD: encoded_password
    kind: Secret
    metadata:
      name: appcenter-dbsecret
    type: Opaque
    EOF
   

   HINWEIS: Sie können den Benutzernamen und das Kennwort mit dem folgenden Befehl verschlüsseln:

    export $MY_USER_NAME=<Benutzer>
    export $MY_PASSWORD=<Kennwort>
   
    echo -n $MY_USER_NAME | base64
    echo -n $MY_PASSWORD | base64
   

   In diesem Abschnitt sind die Sicherheitsmechanismen zur Steuerung des Datenbankzugriffs umrissen. Erstellen Sie mit dem angegebenen Unterbefehl einen geheimen Schlüssel und geben Sie unter den Datenbankdetails den Namen des erstellten geheimen Schlüssels an.

9. Optional: Ein separater geheimer Schlüssel für Datenbankverwaltung kann bereitgestellt werden. Die im geheimen Schlüssel für Datenbankverwaltung enthaltenen Benutzerdetails werden verwendet, um die Datenbankinitialisierung durchzuführen. Bei diesem Prozess werden das erforderliche Mobile-Foundation-Schema und die erforderlichen Tabellen in der Datenbank erstellt (sofern sie noch nicht vorhanden sind). Mithilfe des geheimen Schlüssels für Datenbankverwaltung können Sie die DDL-Operationen für Ihre Datenbankinstanz steuern.

   Wenn der geheime Schlüssel für MFP-Server-Datenbankverwaltung und MFP-Application-Center-Datenbankverwaltung (MFP Server DB Admin Secret und MFP Appcenter DB Admin Secret) nicht angegeben ist, wird für die Datenbankinitialisierung der Standardname für den geheimen Datenbankschlüssel (Database Secret Name) verwendet.

   Führen Sie das folgende Code-Snippet aus, um einen geheimen Schlüssel für MFP-Server-Datenbankverwaltung (MFP Server DB Admin Secret) zu erstellen:

      # Geheimen Schlüssel für MFP-Server-DB-Verwaltung erstellen und Wert im Helm-Chart bei der Implementierung von Mobile Foundation Server aktualisieren
      cat <<EOF | kubectl apply -f -
      apiVersion: v1
      data:
        MFPF_ADMIN_DB_ADMIN_USERNAME: encoded_uname
        MFPF_ADMIN_DB_ADMIN_PASSWORD: encoded_password
        MFPF_RUNTIME_DB_ADMIN_USERNAME: encoded_uname
        MFPF_RUNTIME_DB_ADMIN_PASSWORD: encoded_password
        MFPF_PUSH_DB_ADMIN_USERNAME: encoded_uname
        MFPF_PUSH_DB_ADMIN_PASSWORD: encoded_password
      kind: Secret
      metadata:
        name: mfpserver-dbadminsecret
      type: Opaque
      EOF
   

   Führen Sie das folgende Code-Snippet aus, um einen geheimen Schlüssel für MFP-Application-Center-Datenbankverwaltung (MFP Appcenter DB Admin Secret) zu erstellen:

      # Geheimen Schlüssel für Application-Center-Datenbankverwaltung erstellen und Wert im Helm-Chart bei der Implementierung des Mobile Foundation Application Center aktualisieren
      cat <<EOF | kubectl apply -f -
      apiVersion: v1
      data:
        APPCNTR_DB_ADMIN_USERNAME: encoded_uname
        APPCNTR_DB_ADMIN_PASSWORD: encoded_password
      kind: Secret
      metadata:
      name: appcenter-dbadminsecret
      type: Opaque
      EOF
   

10. Optional: Erstellen Sie die Container für Image-Richtlinien (Image Policy) und für geheime Image-Pull-Schlüssel (Image pull secrets) wenn die Container-Images per Pull-Operation aus einer Registry übertragen werden, die sich außerhalb der Container-Registry von IBM Cloud Private befindet (DockerHub, private Docker-Registry usw.).

	# Image-Richtlinie erstellen
	cat <<EOF | kubectl apply -f -
	apiVersion: securityenforcement.admission.cloud.ibm.com/v1beta1
	kind: ImagePolicy
	metadata:
	 name: image-policy
	 namespace: <Namespace>
	spec:
	 repositories:
	 - name: docker.io/*
	   policy: null
	 - name: <Name_des_Container-Image-Registry-Hosts>/*
	   policy: null
	EOF

   kubectl create secret docker-registry -n <Namespace> <Name_des_Container-Image-Registry-Hosts> --docker-username=<Docker-Registry-Benutzername> --docker-password=<Docker-Registry-Kennwort>

HINWEIS: Die Angaben in spitzen Klammern müssen durch tatsächliche Werte ersetzt werden.

Weitere Informationen finden Sie unter Keystore für MobileFirst Server konfigurieren.

Voraussetzungen für eine Pod-Sicherheitsrichtlinie

Dieses Chart erfordert eine Pod-Sicherheitsrichtlinie (PodSecurityPolicy), die vor der Implementierung an den Ziel-Namespace gebunden wird. Wählen Sie eine vordefinierte Pod-Sicherheitsrichtlinie aus oder lassen Sie einen Clusteradministrator eine angepasste Pod-Sicherheitsrichtlinie für Sie erstellen:

• Name der vordefinierten Pod-Sicherheitsrichtlinie: ibm-restricted-psp

• Definition einer angepassten Pod-Sicherheitsrichtlinie:

    apiVersion: extensions/v1beta1
    kind: PodSecurityPolicy
    metadata:
      name: ibm-mobilefoundation-prod-psp
      annotations:
        apparmor.security.beta.kubernetes.io/allowedProfileNames: runtime/default
        apparmor.security.beta.kubernetes.io/defaultProfileName: runtime/default
        seccomp.security.alpha.kubernetes.io/allowedProfileNames: docker/default
        seccomp.security.alpha.kubernetes.io/defaultProfileName: docker/default
    spec:
      requiredDropCapabilities:
      - ALL
      volumes:
      - configMap
      - emptyDir
      - projected
      - secret
      - downwardAPI
      - persistentVolumeClaim
      seLinux:
        rule: RunAsAny
      runAsUser:
        rule: MustRunAsNonRoot
      supplementalGroups:
        rule: MustRunAs
        ranges:
        - min: 1
          max: 65535
      fsGroup:
        rule: MustRunAs
        ranges:
        - min: 1
          max: 65535
      allowPrivilegeEscalation: false
      forbiddenSysctls:
      - "*"
  

  • Angepasste Clusterrolle (ClusterRole) für die angepasste Pod-Sicherheitsrichtlinie:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: ibm-mobilefoundation-prod-psp-clusterrole
    rules:
    - apiGroups:
      - extensions
      resourceNames:
      - ibm-mobilefoundation-prod-psp
      resources:
      - podsecuritypolicies
      verbs:
      - use
  

  HINWEIS: Die Pod-Sicherheitsrichtlinie muss nur einmal erstellt werden. Sollte sie bereits vorhanden sein, können Sie diesen Schritt überspringen.

  Der Clusteradministrator kann die obigen Definitionen für die Pod-Sicherheitsrichtlinie und die Clusterrolle in der Anzeige für Ressourcenerstellung auf der Benutzerschnittstelle einfügen oder die beiden folgenden Befehle ausführen:

    kubectl create -f <PSP-YAML-Datei>
    kubectl create clusterrole ibm-mobilefoundation-prod-psp-clusterrole --verb=use --resource=podsecuritypolicy --resource-name=ibm-mobilefoundation-prod-psp

Außerdem müssen Sie die Rollenbindung (RoleBinding) erstellen:

    kubectl create rolebinding ibm-mobilefoundation-prod-psp-rolebinding --clusterrole=ibm-mobilefoundation-prod-psp-clusterrole --serviceaccount=<Namespace>:default --namespace=<Namespace>

Erforderliche Ressourcen

Dieses Chart verwendet standardmäßig die folgenden Ressourcen:

Konfiguration

Parameter

In der folgenden Tabelle sind die in der Mobile-Foundation-Server-Instanz, der Mobile-Foundation-Analytics-Instanz, der Mobile-Foundation-Push-Instanz und der Mobile-Foundation-Application-Center-Instanz für IBM Cloud Private verwendeten Umgebungsvariablen angegeben.

Das Lernprogramm zur Analyse von -Protokollen mit Kibana finden Sie hier.

-Helm-Charts aus dem ICP-Katalog installieren

MobileFirst Server installieren

Neben MobileFirst Server können Sie mit dem Chart MobileFirst Analytics und das MobileFirst Application Center implementieren. Die Implementierung von MobileFirst Analytics und des MobileFirst Application Center ist jedoch optional.

Hinweis:

1. Bevor Sie mit der Installation von MobileFirst Server beginnen, benötigen Sie eine vorkonfigurierte DB2-Datenbank.
2. Bevor Sie mit der Installation des MobileFirst-Analytics-Charts beginnen, müssen Sie den persistenten Datenträger konfigurieren. Geben Sie den persistenten Datenträger für die Konfiguration von MobileFirst Analytics an. Führen Sie für die Erstellung des persistenten Datenträgers die Schritte in der IBM Cloud-Private-Dokumentation aus. Die YAML-Beispieldatei finden Sie unter Punkt 6 im Abschnitt Helm-Charts für IBM Mobile Foundation installieren und konfigurieren.

Führen Sie die folgenden Schritte aus, um die IBM Mobile Foundation in der Managementkonsole von IBM Cloud Private zu installieren und zu konfigurieren.

1. Navigieren Sie in der Managementkonsole zum Katalog.
2. Wählen Sie das Helm-Chart ibm-mobilefoundation-prod aus.
3. Klicken Sie auf Konfigurieren.
4. Geben Sie die Umgebungsvariablen an. Weitere Informationen finden Sie unter Konfiguration.
5. Akzeptieren Sie die ** Lizenzvereinbarung **.
6. Klicken Sie auf Installieren.

HINWEIS: Das neueste Paket mit Mobile Foundation für ICP enthält die folgende unterstützte Software:

1. IBM JRE8 SR5 FP37 (8.0.5.37)
2. IBM WebSphere Liberty Version 18.0.0.5

Installation überprüfen

Nachdem Sie MobileFirst Analytics (optional) und MobileFirst Server installiert und konfiguriert haben, können Sie wie folgt Ihre Installation und den Status der implementierten Pods überprüfen:

Wählen Sie in der Managementkonsole von IBM Cloud Private Workloads > Helm Releases aus. Klicken Sie auf den Releasenamen für Ihre Installation.

Zugriff auf die -Konsole

Die Implementierung nach einer erfolgreichen Installation kann einige Minuten dauern.

Rufen Sie in einem Web-Browser die Seite mit der Konsole von IBM Cloud Private auf und navigieren Sie wie folgt zur Seite mit den Helm-Releases:

1. Klicken Sie oben links auf der Seite auf “Menü”.
2. Wählen Sie “Workloads” > “Helm-Releases” aus.
3. Klicken Sie auf das implementierte Helm-Release für IBM Mobile Foundation.
4. Lesen Sie die HINWEISE, um zu erfahren, wie auf die Mobile Foundation Server Operations Console zugegriffen wird.

Beispielanwendung

Gehen Sie die -Lernprogramme durch, um den Beispieladapter zu implementieren und die Beispielanwendung in einem IBM MobileFirst Server in IBM Cloud Private auszuführen.

Upgrade für -Helm-Charts und -Releases

Unter Upgrading bundled products finden Sie Anweisungen zur Durchführung eines Upgrades für Helm-Charts bzw. Releases.

Beispielszenarien für Helm-Release-Upgrades

1. Für das Upgrade eines Helm-Release mit einer Änderung der Werte von values.yaml können Sie den Befehl helm upgrade mit der Option –set verwenden. Sie können die Option – set mehrfach angeben. Priorität erhält die in der Befehlszeile ganz rechts angegebene Option “set”.

  helm upgrade --set <Name>=<Wert> --set <Name>=<Wert> <Name_des_vorhandenen_Helm-Release> <Pfad_des_neuen_Helm-Charts>

1. Wenn Sie ein Upgrade für ein Helm-Release mit Angabe von Werten in einer Datei durchführen, verwenden Sie den Befehl helm upgrade mit der Option -f. Sie können die Option –values oder -f mehrfach verwenden. Priorität erhält die in der Befehlszeile ganz rechts angegebene Datei (Option “-f”). Wenn im folgenden Beispiel sowohl myvalues.yaml als auch override.yaml einen Schlüssel Test enthält, hat der in override.yaml festgelegte Wert Vorrang.

  helm upgrade -f myvalues.yaml -f override.yaml <Name_des_vorhandenen_Helm-Release> <Pfad_des_neuen_Helm-Charts>

1. Wenn Sie ein Upgrade für ein Helm-Release durchführen und dabei die Werte des letzten Release wiederverwenden und einige der Werte überschreiben möchten, können Sie einen Befehl wie den folgenden verwenden:

  helm upgrade --reuse-values --set <Name>=<Wert> --set <Name>=<Wert> <Name_des_vorhandenen_Helm-Release> <Pfad_des_neuen_Helm-Charts>

Migration auf das zertifizierte IBM Cloud Pak für die Mobile Foundation Platform

Das zertifizierte IBM Cloud Pak ermöglicht die Implementierung der Mobile Foundation als einzelnes Helm-Chart. Dieser Ansatz ersetzt die bisherige Vorgehensweise mit drei verschiedenen Helm-Charts (ibm-mfpf-server-prod, ibm-mfpf-analytics-prod und ibm-mfpf-appcenter-prod) für die Implementierung der Mobile-Foundation-Komponenten.

Die Migration der alten, als separate Helm-Releases in der ICP-Implementierung installierten Mobile-Foundation-Komponenten auf das neue konsolidierte Helm-Chart mit zertifiziertem IBM Cloud Pak ist einfach.

1. Sie können alle Konfigurationsparameter für Server, Push, Application Center und Analytics beibehalten.
2. Wenn die gleichen Datenbankdetails wie für die alte Implementierung verwendet werden, enthält Ihre neue Mobile-Foundation-Implementierung (Server, Push und Application Center) die gleichen Daten wie die alte Implementierung.
3. Beachten Sie die Änderung bei den einzugebenden Datenbankwerten. Der Zugriff auf die Datenbank wird jetzt mit geheimen Schlüsseln gesteuert. Unter Punkt 4 des Abschnitts Voraussetzungen erfahren Sie, wie geheime Schlüssel für Berechtigungsnachweise (unter anderem für die Konsolenanmeldung, für Datenbankkonten usw.) erstellt werden.
4. Die Daten von Mobile Foundation Analytics können Sie erhalten, wenn Sie die Anforderung eines persistenten Datenträgers aus der alten Implementierung verwenden.

Sicherung und Wiederherstellung von MFP-Analytics-Daten

Die MFP-Analytics-Daten sind im Rahmen eines Kubernetes-PV oder -PVC verfügbar. Möglicherweise verwenden Sie eines der von Kubernetes angebotenen Volume-Plug-ins.

Sicherung und Wiederherstellung sind von den verwendeten Volume-Plug-ins abhängig. Es gibt diverse Möglichkeiten/Tools für die Sicherung oder Wiederherstellung des Dateträgers (Volume).

Kuberenetes bietet die Optionen VolumeSnapshot, VolumeSnapshotContent und Restore an. Sie können eine Kopie des Clusterdatenträgers erstellen, der von einem Administrator bereitgestellt wurde.

Verwenden Sie die folgenden YAML-Beispieldateien, um das Feature für Momentaufnahmen zu testen.

Sie können auch andere Tools für die Sicherung und Wiederherstellung des Datenträgers nutzen.

• IBM Cloud Automation Manager (CAM) für ICP

  Nutzen Sie die Möglichkeiten und Stategien für Sicherung/Wiederherstellung, Hohe Verfügbarkeit und Disaster Recovery für CAM-Instanzen.

• Portworx für ICP

  Diese Speicherlösung wurde für Anwendungen entwickelt, die als Container oder über einen Containerkoordinator wie Kubernetes implementiert werden.

• Stash von AppsCode

  Mithilfe von Stash können Sie die Datenträger in Kubernetes sichern.

Deinstallation

Verwenden Sie zum Deinstallieren von MobileFirst Server und MobileFirst Analytics die Helm-CLI. Mit dem folgenden Befehl werden die installierten Charts und die zugehörigen Implementierungen vollständig gelöscht:

helm delete <Release> --purge --tls

Hier steht Release für den Namen des implementierten Release des Helm-Charts.

Dieser Befehl entfernt alle Kubernetes-Komponenten des Charts (mit Ausnahme von Anforderungen persistenter Datenträger). Dieses Standardverhalten von Kubernetes stellt sicher, dass die geschäftskritischen Daten nicht gelöscht werden.