IBM Cloud Private への IBM Mobile Foundation のインストール

概説

以下の指示に従い、IBM Cloud Private で MobileFirst Server インスタンス、MobileFirst Analytics、、および MobileFirst Application Center インスタンスを構成します。

• 前提条件を満たす
• IBM Cloud Private 用の IBM Mobile Foundation のパスポート・アドバンテージ・アーカイブ (PPA アーカイブ) をダウンロードする
• IBM Cloud Private クラスターに PPA アーカイブをロードする
• MobileFirst Server、MobileFirst Analytics (オプション)、 (オプション)、および MobileFirst Application Center (オプション) をインストールし、構成する

ジャンプ先:

• 前提条件
• IBM Mobile Foundation パスポート・アドバンテージ・アーカイブのダウンロード
• IBM Mobile Foundation パスポート・アドバンテージ・アーカイブのロード
• IBM Mobile Foundation Helm チャートのインストールおよび構成
• 必要なリソース
• インストールの検査
• サンプル・アプリケーション
• Helm チャートおよびリリースのアップグレード
• Mobile Foundation Platform 用の IBM Certified Cloud Pak へのマイグレーション
• MFP Analytics データのバックアップおよびリカバリー
• アンインストール

前提条件

IBM Cloud Private アカウントが必要であり、IBM Cloud Privateクラスターをセットアップしておく必要があります。

コンテナーおよびイメージを管理するために、IBM Cloud Private セットアップの一部としてホスト・マシンに以下をインストールする必要があります。

• Docker をインストールし、セットアップする
• IBM Cloud CLI (cloudctl)
• Kubernetes CLI (kubectl)
• Helm (helm)

サポートされている Docker CLI のバージョンについては、ここを参照してください。

ICP クラスターと同じバージョンの Kube CLI、IBM Cloud CLI、および Helm をインストールします (IBM Cloud Private 管理コンソールからダウンロードし、「メニュー」>「コマンド・ライン・ツール (Command Line Tools)」>「Cloud Private CLI」をクリックします)。

例えば、次のとおりです。

IBM Cloud Private で、秘密、永続ボリューム (PV)、永続ボリューム要求 (PVC) などの Kubernetes 成果物を作成するために、kubectl CLI が必要です。

a. IBM Cloud Private 管理コンソールから kubectl ツールをインストールし、「メニュー」>「コマンド・ライン・ツール (Command Line Tools)」>「Cloud Private CLI」をクリックします。

b. 「Kubernetes CLI のインストール (Install Kubernetes CLI)」を展開し、curl コマンドを使用してインストーラーをダウンロードします。 ご使用のオペレーティング・システム用の curl コマンドをコピーして実行し、インストール手順を続行します。

c. 該当するオペレーティング・システム用の curl コマンドを選択します。 例えば、macOS では以下のコマンドを実行できます。

   curl -kLo <install_file> https://<cluster ip>:<port>/api/cli/kubectl-darwin-amd64
   chmod 755 <path_to_installer>/<install_file>
   sudo mv <path_to_installer>/<install_file> /usr/local/bin/kubectl

参照: Kubernetes CLI (kubectl) のインストール

IBM Mobile Foundation パスポート・アドバンテージ・アーカイブのダウンロード

IBM Mobile Foundation のパスポート・アドバンテージ・アーカイブ (PPA) は、ここから入手できます。 Mobile Foundation の PPA アーカイブには、以下の Mobile Foundation コンポーネントの Docker イメージと Helm チャートが含まれます。

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

データベース初期化タスクを簡単に実行できるようにするために、MobileFirst DB 初期化コンポーネントが使用されます。 これにより、(必要に応じて) データベースで Mobile Foundation スキーマおよび表の作成が処理されます (存在しない場合)。

IBM Mobile Foundation パスポート・アドバンテージ・アーカイブのロード

Mobile Foundation の PPA アーカイブをロードする前に、Docker をセットアップする必要があります。 こちらの説明を参照してください。

以下のステップに従って、PPA アーカイブを IBM Cloud Private クラスターにロードします。

1. IBM Cloud ICP プラグイン (cloudctl) を使用してクラスターにログインします。

   IBM Cloud Private 資料で、CLI コマンド・リファレンスを参照してください。

   以下に例を示します。

   cloudctl login -a https://ip:port
   

   オプションで、SSL 検証をスキップする場合は、上記のコマンドでフラグ --skip-ssl-validation を使用します。 このオプションを使用すると、クラスター・エンドポイントの username と password の入力を求めるプロンプトが出されます。 ログインに成功したら、以下のステップに進んでください。

2. 以下のコマンドを使用して、Mobile Foundation の PPA アーカイブをロードします。

   cloudctl catalog load-ppa-archive --archive <archive_name> [--clustername <cluster_name>] [--namespace <namespace>]
   

   Mobile Foundation の archive_name は、IBM パスポート・アドバンテージからダウンロードした PPA アーカイブの名前です。

   前のステップに従い、クラスター・エンドポイントを cloudctl のデフォルトにした場合、--clustername は無視できます。

3. IBM Cloud Private 管理コンソールで、Docker イメージおよび Helm チャートを表示します。 Docker イメージを表示するには、以下のようにします。
   • 「プラットフォーム」>「コンテナー・イメージ (Container Images)」を選択します。
   • Helm チャートが「カタログ」に表示されます。

上記のステップを完了すると、アップロードされたバージョンの Helm チャートが ICP カタログに表示されます。 MobileFirst Server は ibm-mobilefoundation-prod としてリストされます。

IBM Mobile Foundation Helm チャートのインストールおよび構成

MobileFirst Server をインストールし、構成するには、以下のものが事前に必要になります。

このセクションでは、秘密の作成手順について説明します。

秘密オブジェクトを使用すると、パスワード、OAuth トークン、ssh キーなどの機密情報を保管および管理できます。 このような情報は、ポッド定義やコンテナー・イメージに保管するよりも、秘密に保管した方がより安全でフレキシブルです。

1. (必須) Mobile Foundation サーバーおよび Application Center コンポーネントの技術データを保管するために、事前構成済みのデータベースが必要です。

   以下のサポートされている DBMS のいずれかを使用する必要があります。

   1. IBM DB2
   2. MySQL
   3. Oracle

   Oracle または MySQL データベースを使用する場合、以下の手順に従います。

   • Oracle および MySQL 用の JDBC ドライバーは、Mobile Foundation インストーラーには含まれていません。 JDBC ドライバーがあることを確認します (MySQL の場合、Connector/J JDBC ドライバーを使用し、Oracle の場合、Oracle シン JDBC ドライバーを使用します)。 マウントされたボリュームを作成し、JDBC ドライバーをロケーション /nfs/share/dbdrivers に配置します。

   • NFS ホストの詳細、および JDBC ドライバーが保管されているパスを指定して、永続ボリューム (PV) を作成します。 以下は、サンプルの 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 ```

       注: 上記の yaml に必ず エントリーと エントリーを追加してください。

   • 永続ボリューム要求 (PVC) を作成し、デプロイ時に Helm チャートで PVC 名を指定します。 以下は、サンプルの 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 ```

       注: 上記の yaml に正しい名前空間を追加したことを確認します。

2. (必須) Server、Analytics、および Application Center コンソールへのログインでは、事前に作成したログイン秘密が必要です。 例えば、次のとおりです。

   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
   

   注: これらの秘密が提供されていない場合、Mobile Foundation Helm チャートのデプロイ時に、デフォルトのユーザー名とパスワード (admin/admin) を使用して作成されます。

3. (オプション) 独自の鍵ストアとトラストストアを使用する秘密を作成することで、Server、Push、Analytics、および Application Center デプロイメントに対して独自の鍵ストアとトラストストアを提供できます。

   リテラル KEYSTORE_PASSWORD および TRUSTSTORE_PASSWORD を使用して鍵ストアおよびトラストストアのパスワードとともに keystore.jks および truststore.jks を含む秘密を事前に作成し、各構成要素の keystoreSecret フィールドに秘密名を指定します。

   以下のように、ファイル keystore.jks、truststore.jks とそのパスワードを保持します。

   例えば、次のとおりです。

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

   注: ファイルおよびリテラルの名前は、上記のコマンドで示したものと同じでなければなりません。 Helm チャートの構成時にデフォルトの鍵ストアをオーバーライドするには、各構成要素の keystoresSecretName 入力フィールドにこの秘密名を指定します。

4. (オプション) 外部クライアントがホスト名を使用して Mobile Foundation コンポーネントに到達できるようにするために、ホスト名ベースの入口を使用してそれらの Mobile Foundation コンポーネントを構成できます。 この入口は、TLS の秘密鍵と証明書を使用することで保護できます。 TLS の秘密鍵と証明書は、tls.key および tls.crt という鍵名を使用して秘密で定義する必要があります。

   以下のコマンドを使用すると、入口リソースと同じ名前空間に秘密 mf-tls-secret が作成されます。

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

   その後、global.ingress.secret フィールドに秘密の名前を指定します。

   注: 他の Helm リリースに対して入口ホスト名が既に使用されている場合、同じ入口ホスト名は使用しないでください。

5. (オプション) 構成をカスタマイズするには (例: ログ・トレース設定を変更する、新しい jndi プロパティーを追加するなど)、構成 XML ファイルを使用して configmap を作成する必要があります。 これにより、新しい構成設定を追加することや、Mobile Foundation コンポーネントの既存の構成をオーバーライドすることができます。

   Mobile Foundation コンポーネントは、configMap (mfpserver-custom-config) を介してカスタム構成にアクセスします。これは、以下のように作成できます。

    kubectl create configmap mfpserver-custom-config --from-file=<configuration file in XML format>
   

   上記のコマンドを使用して作成した configmap を、Mobile Foundation のデプロイ時に Helm チャートのカスタム・サーバー構成で指定する必要があります。

   以下は、mfpserver-custom-config configmap を使用してトレース・ログ仕様を「warning」に設定する例です (デフォルト設定は「info」)。

   • サンプル構成 XML (logging.xml)

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

   • configmap を作成し、Helm チャートのデプロイメント時に同じ内容を追加する

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

   • (Mobile Foundation コンポーネントの) messages.log の変更に注意してください - プロパティー traceSpecification を com.ibm.mfp.=debug:*=warning に設定します。

6. (オプション) Mobile Foundation サーバーを、管理サービスの機密クライアントを使用して事前定義します。 これらのクライアントの資格情報は、mfpserver.adminClientSecret フィールドと mfpserver.pushClientSecret フィールドに指定します。

   これらの秘密は、以下のように作成できます。

   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
   

   注: Mobile Foundation Helm チャートのデプロイメント時に mfpserver.pushClientSecret フィールドと mfpserver.adminClientSecret フィールドに値を指定しなかった場合、mfpserver.adminClientSecret に対してはデフォルトの認証 ID/クライアント秘密である admin/nimda が、mfpserver.pushClientSecret に対してはデフォルトの認証 ID/クライアント秘密である push/hsup が生成され、使用されます。

7. Analytics デプロイメントの場合、Analytics データを保持するために以下のオプションを選択できます。

   a) 永続ボリューム (PV) および永続ボリューム要求 (PVC) を準備し、Helm チャートで PVC 名を指定するには

   例えば、次のとおりです。

   サンプル PersistentVolume.yaml

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

   注: 上記の yaml に エントリーと エントリーを追加したことを確認します。

   サンプル 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
   

   注: 上記の yaml に正しい を追加したことを確認します。

   b) チャートで動的プロビジョニングを選択するには

8. (必須) Server、Push、および Application Center に対してデータベース秘密を作成します。 このセクションでは、データベースへのアクセスを制御するためのセキュリティー・メカニズムについて説明します。 指定のサブコマンドを使用して秘密を作成し、データベースの詳細で作成した秘密の名前を指定します。

   以下のコード・スニペットを実行して、Mobile Foundation サーバーのデータベース秘密を作成します。

    # mfpserver 秘密を作成する
    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
   

   以下のコード・スニペットを実行して、Application Center のデータベース秘密を作成します。

    # appcenter 秘密を作成する
    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
   

   注: 以下のコマンドを使用してユーザー名とパスワードの詳細をエンコードできます。

    export $MY_USER_NAME=<myuser>
    export $MY_PASSWORD=<mypassword>
   
    echo -n $MY_USER_NAME | base64
    echo -n $MY_PASSWORD | base64
   

   このセクションでは、データベースへのアクセスを制御するためのセキュリティー・メカニズムについて説明します。 指定のサブコマンドを使用して秘密を作成し、データベースの詳細で作成した秘密の名前を指定します。

9. (オプション) 個別のデータベース管理秘密を指定できます。 データベース管理秘密で指定されているユーザー詳細を使用して DB 初期化タスクが実行されます。これにより、必要な Mobile Foundation スキーマと表がデータベースに作成されます (存在しない場合)。 データベース管理秘密を使用して、データベース・インスタンスでの DDL 操作を制御できます。

   MFP サーバー DB 管理秘密および MFP Appcenter DB 管理秘密の詳細が指定されていない場合、デフォルトのデータベース秘密名を使用して DB 初期化タスクが実行されます。

   Mobile Foundation サーバー用の MFP サーバー DB 管理秘密を作成するには、以下のコード・スニペットを実行します。

      # Mobile Foundation サーバー・コンポーネントのデプロイ時に、MFP サーバー DB 管理秘密を作成して、Helm チャートで同じものを更新する
      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
   

   Mobile Foundation サーバー用の MFP Appcenter DB 管理秘密を作成するには、以下のコード・スニペットを実行します。

      # Mobile Foundation AppCenter コンポーネントのデプロイ時に、Appcenter DB 管理秘密を作成して、Helm チャートで同じものを更新する
      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. (オプション) コンテナー・イメージが IBM Cloud Private セットアップのコンテナー・レジストリー (DockerHub、プライベート Docker レジストリーなど) の外部にあるレジストリーからプルされる場合、コンテナーのイメージ・ポリシーおよびイメージ・プル秘密を作成します。

	# イメージ・ポリシーを作成する
	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: <container-image-registry-hostname>/*
	   policy: null
	EOF

   kubectl create secret docker-registry -n <namespace> <container-image-registry-hostname> --docker-username=<docker-registry-username> --docker-password=<docker-registry-password>

注: < > 内のテキストを正しい値で更新する必要があります。

詳しくは、MobileFirst Server 鍵ストアの構成を参照してください。

PodSecurityPolicy の要件

このチャートでは、デプロイメント前に PodSecurityPolicy をターゲット名前空間にバインドする必要があります。 事前定義の PodSecurityPolicy を選択するか、クラスター管理者にカスタム PodSecurityPolicy の作成を依頼してください。

• 事前定義の PodSecurityPolicy 名: ibm-restricted-psp

• カスタム PodSecurityPolicy 定義:

    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:
      - "*"
  

  • カスタム PodSecurityPolicy のカスタム ClusterRole:

    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
  

  注: PodSecurityPolicy は 1 回のみ作成する必要があります。PodSecurityPolicy が既に存在する場合、この手順はスキップしてください。

  クラスター管理者は、上記の PSP 定義および ClusterRole 定義を UI のリソース作成画面に貼り付けること、または以下の 2 つのコマンドを実行することができます。

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

RoleBinding も作成する必要があります。

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

必要なリソース

このチャートでは、デフォルトでは以下のリソースが使用されます。

構成

パラメーター

以下の表に、IBM Cloud Private 上の MobileFirst Server インスタンス、MobileFirst Analytics、、および で使用される環境変数を示します。

Kibana を使用して ログを分析する場合のチュートリアルについては、こちらを参照してください。

ICP カタログからの Helm チャートのインストール

MobileFirst Server のインストール

MobileFirst Server とともに、同じチャートから MobileFirst Analytics と MobileFirst Application Center もデプロイできます。 ただし、MobileFirst Analytics と MobileFirst Application Center のデプロイはオプションです。

注:

1. MobileFirst Server のインストールを開始する前に、DB2 データベースが事前構成されていることを確認してください。
2. MobileFirst Analytics チャートのインストールを開始する前に、永続ボリュームを構成します。 MobileFirst Analytics を構成するための永続ボリュームを提供します。 IBM Cloud Privateの資料で詳しく説明されている手順に従い、永続ボリュームを作成します。 サンプル yaml ファイルについて、IBM Mobile Foundation Helm チャートのインストールおよび構成のセクション 6も参照してください。

以下のステップに従って、IBM Cloud Private 管理コンソールから IBM Mobile Foundation をインストールし、構成します。

1. 管理コンソールで「カタログ」に移動します。
2. ibm-mobilefoundation-prod Helm チャートを選択します。
3. 「構成」をクリックします。
4. 環境変数を指定します。 詳しくは、構成を参照してください。
5. 「ご使用条件 (License Agreement)」に同意します。
6. 「インストール」をクリックします。

注: 最新の Mobile Foundation on ICP パッケージには、サポートされている以下のソフトウェアがバンドルされています。

1. IBM JRE8 SR5 FP37 (8.0.5.37)
2. IBM WebSphere Liberty v18.0.0.5

インストールの検査

MobileFirst Analytics (オプション) および MobileFirst Server のインストールと構成が完了したら、以下を実行することにより、インストール済み環境およびデプロイされたポッドの状況を検査できます。

IBM Cloud Private 管理コンソールで、「ワークロード (Workloads)」>「Helm リリース (Helm Releases)」を選択します。 インストール済み環境のリリース名 をクリックします。

コンソールへのアクセス

インストールが成功した後、デプロイメントが完了するまで数分かかる場合があります。

Web ブラウザーから IBM Cloud Private コンソール・ページに移動し、以下のように Helm リリース・ページに移動します。

1. ページの左上にある「メニュー」をクリックします。
2. 「ワークロード (Workloads)」>「Helm リリース (Helm Releases)」を選択します。
3. デプロイ済みの IBM Mobile Foundation Helm リリースをクリックします。
4. Mobile Foundation サーバーの Operations Console にアクセスする手順については、注セクションを参照してください。

サンプル・アプリケーション

IBM Cloud Private で実行される IBM MobileFirst Server 上にサンプル・アダプターをデプロイし、サンプル・アプリケーションを実行するには、 チュートリアルを参照してください。

Helm チャートおよびリリースのアップグレード

Helm チャート/リリースをアップグレードする方法については、バンドル製品のアップグレードを参照してください。

Helm リリース・アップグレードのサンプル・シナリオ

1. values.yaml の値の変更によって Helm リリースをアップグレードするには、--set フラグを指定した helm upgrade コマンドを使用します。 -set フラグは複数回指定できます。 コマンド・ラインで指定された右端のセットの優先順位が最も高くなります。

  helm upgrade --set <name>=<value> --set <name>=<value> <existing-helm-release-name> <path of new helm chart>

1. ファイル内に値を指定して Helm リリースをアップグレードするには、-f フラグを指定した helm upgrade コマンドを使用します。 –values フラグまたは -f フラグは複数回使用できます。 コマンド・ラインで指定された右端のファイルの優先順位が最も高くなります。 以下の例で、myvalues.yaml と override.yaml の両方に Test というキーが含まれている場合、override.yaml に設定された値が優先されます。

  helm upgrade -f myvalues.yaml -f override.yaml <existing-helm-release-name> <path of new helm chart>

1. 最後のリリースの値を再利用し、値の一部をオーバーライドすることによって Helm リリースをアップグレードするには、以下のようなコマンドを使用できます。

  helm upgrade --reuse-values --set <name>=<value> --set <name>=<value> <existing-helm-release-name> <path of new helm chart>

Mobile Foundation Platform 用の IBM Certified Cloud Pak へのマイグレーション

IBM Certified Cloud Pak を使用すると、Mobile Foundation を単一 Helm チャートとしてのデプロイメントで使用できます。 これにより、Mobile Foundation コンポーネントをデプロイするために 3 つの異なる Helm チャート (viz.ibm-mfpf-server-prod、ibm-mfpf-analytics-prod、および ibm-mfpf-appcenter-prod) を使用する以前の方法が置き換えられます。

ICP デプロイメントで個別の Helm リリースとしてインストールされた古い Mobile Foundation コンポーネントから、IBM Certified Cloud Pak を使用する新しい単一の統合 Helm チャートへのマイグレーションは簡単です。

1. Server、Push、Application Center、および Analytics のすべての構成パラメーターを保持できます。
2. 古いデプロイメントと同様のデータベース詳細が使用される場合、新しい Mobile Foundation デプロイメント (Server、Push、および Application Center) で、古いデプロイメントと同じデータが使用されます。
3. 入力するデータベース値の変更に注意してください。 データベースへのアクセスは、秘密を通じて制御されるようになりました。 前提条件のセクション 4 を参照して、資格情報 (コンソール・ログイン、データベース・アカウントなど) の秘密を作成してください。
4. 古いデプロイメントで使用されていた同じ永続ボリューム要求を再使用することで、Mobile Foundation Analytics データを保持できます。

MFP Analytics データのバックアップおよびリカバリー

MFP Analytics データは、Kubernetes PersistentVolume または PersistentVolumeClaim の一部として使用できます。 Kubernetes が提供するボリューム・プラグインのいずれかを使用します。

バックアップおよびリストアは、使用するボリューム・プラグインに基づきます。 ボリュームをバックアップまたはリストアできるさまざまな手段/ツールがあります。

Kuberenetes は、VolumeSnapshot、VolumeSnapshotContent、および Restore のオプションを提供しています。 管理者がプロビジョンしたクラスター内のボリュームのコピーを作成できます。

以下のサンプル yaml ファイルを使用して、スナップショット機能をテストします。

また、他のツールを利用して、ボリュームのバックアップを作成すること、およびその同じバックアップをリストアすることもできます。

• ICP 上の IBM Cloud Automation Manager (CAM)

  CAM の機能、および CAM インスタンスのバックアップ/リストア、高可用性 (HA)、および災害復旧 (DR) の戦略を利用します。

• ICP 上の Portworx

  コンテナーとして、または Kubernetes などのコンテナー・オーケストレーターを介してデプロイされるアプリケーション用に設計されたストレージ・ソリューションです。

• AppsCode によるスタッシュ

  スタッシュを使用すると、Kubernetes でボリュームをバックアップできます。

アンインストール

MobileFirst Server および MobileFirst Analytics をアンインストールするには、Helm CLI を使用します。 以下のコマンドを使用して、インストールされているチャートおよび関連するデプロイメントを完全に削除します。

helm delete <my-release> --purge --tls

my-release は、デプロイ済みの Helm チャートのリリース名です。

このコマンドにより、チャートに関連付けられているすべての Kubernetes コンポーネント (永続ボリューム要求 (PVC) 以外) が削除されます。 このデフォルトの Kubernetes 動作では、有用なデータは削除されません。