Using Oracle or MySQL as IBM Mobile Foundation database
Using Oracle (or) MySQL as IBM Mobile Foundation database
A pre-configured database is required to store the data for Mobile Foundation server, Push and Application Center components.
Follow the instructions here to setup Mobile Foundation with a non-DB2 database.
By default, Mobile Foundation installers is packaged with IBM DB2 JDBC drivers. For Oracle and MySQL, make sure that the JDBC driver (for MySQL - use the Connector/J JDBC driver, for Oracle - use the Oracle thin JDBC driver) is placed within a Persistent Volume.
For Oracle database:
- Use Oracle Service Name for the property name under the db section in Custom Resource File (
- Make sure the Oracle database user is created with UPPERCASE and the same is used while creating the database secret.
Place the JDBC driver in a NFS mounted volume. Example: /nfs/share/dbdrivers
Create a Persistent Volume (PV) and Persistent Volume Claim (PVC) by providing the correct NFS server details and the path where the JDBC driver is stored. Sample yaml is shown below.
# Sample 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: <nfs_path> server: <nfs_server> EOF
# Sample PersistentVolumeClaim.yaml cat <<EOF | kubectl apply -f - apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mfppvc namespace: projectname-or-namespace spec: accessModes: - ReadWriteMany resources: requests: storage: 20Gi selector: matchLabels: name: mfppvdbdrivers volumeName: mfppvdbdrivers status: accessModes: - ReadWriteMany capacity: storage: 20Gi EOF
NOTE: Make sure you add the right projectname-or-namespace in the yaml above.
[OPTIONAL] Handling Mobile Foundation database operations with special (admin) privileges
We can have a separate database admin secret to execute the database initialization tasks, which would in turn create the required Mobile Foundation schema and tables in the database (if it does not already exist). Through the database Admin secret, you can control the DDL operations on your database instance.
MFP Server DB Admin Secret and
MFP Appcenter DB Admin Secret details are not provided, then the default
Database Secret Name will be used to perform database initialization tasks.
Run the below code snippet to create a
MFP Server DB Admin Secret for Mobile Foundation Server.
# Create MFP Server Admin DB secret for Mobile Foundation server component 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
Run the below code snippet to create a
MFP Appcenter DB Admin Secret for Appcenter.
# Create Appcenter Admin DB secret for Mobile Foundation Appcenter cat <<EOF | kubectl apply -f - apiVersion: v1 data: MFPF_APPCNTR_DB_ADMIN_USERNAME: encoded_uname MFPF_APPCNTR_DB_ADMIN_PASSWORD: encoded_password kind: Secret metadata: name: appcenter-dbadminsecret type: Opaque EOF
Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.