For steps to configure OpenShift see OpenShift documentation To determine the <docker-registry-ip> run the following commands:

oc project default
oc rsh <docker-registry-pod>
printenv DOCKER_REGISTRY_SERVICE_HOST

See the section "Working with HTTP Proxies" for information about configuring your OpenShift installation to use a proxy.

RHMAP Proxy is a separate component which routes requests from a single external host to Cloud Apps and RHMAP Core instances deployed on OpenShift.

For example, when RHMAP Proxy receives a request for https://rhmapproxy.internal.com/cloud_app_id/hello, that request is translated to http://cloud_app_id.internal.com/hello.

The RHMAP Proxy component is bundled within the RHMAP RPM in the form of an OpenShift template. Provisioning this template creates an OpenShift route and exposes this service.

Deploy an RHMAP Proxy for each MBaaS project:

If you have provisioned the RHMAP Proxy as described in Provisioning the RHMAP Proxy and you later decide that you do not require it, complete the following procedure:

RHMAP Core pods can be scaled using either oc command tool or web console.

To scale pods execute following commands:

Example commands that would scale most used components:

oc scale --replicas=2 dc fh-ngui
oc scale --replicas=2 dc millicore
oc scale --replicas=2 dc fh-supercore
oc scale --replicas=2 dc fh-aaa
oc scale --replicas=2 dc ups

Not all RHMAP Core pods can be scaled using OpenShift api.

After modifying the deployment configuration, a redeploy of the millicore pod is triggered automatically. Once the pod is running again, you can verify the changes.

Verify the SMTP server setup by trying the forgotten password procedure:

You should receive an email with instructions for password recovery.

If the password recovery email doesn’t arrive, verify the SMTP settings in the running millicore pod.

oc env pod -l name=millicore --list | grep SMTP

It may help to view the millicore logs while attempting the password recovery, looking for any errors related to SMTP or email.

oc logs -f millicore-<deploy-uuid>

If the test email seems to be sent, but fails to arrive, check it hasn’t been placed in your spam or junk folder.

You can back up a Core by following this procedure. After completing the procedure and storing the backup data safely, you can restore a Core to the state at the time of backup using the Restoring a Core Backup procedure.

Other factors that have an impact on how much storage is required for backups include:

You must back up the following items to back up a Core:

Back up the Mongodb data using the mongodump command in combination with the oc exec command:

oc exec `oc get po --selector='deploymentconfig=mongodb-1' --template="{{(index .items 0).metadata.name}}"` bash -- -c '/opt/rh/rh-mongodb32/root/usr/bin/mongodump -u admin -p ${MONGODB_ADMIN_PASSWORD} --gzip --archive' > ./core7_mongodb.gz

Back up the MySQL data using the mysqldump command in combination with the oc exec command:

oc exec `oc get po --selector='deploymentconfig=mysql' --template="{{(index .items 0).metadata.name}}"` bash -- -c '/opt/rh/mysql55/root/usr/bin/mysqldump -h mysql -u ${MYSQL_USER} -p${MYSQL_PASSWORD} --all-databases' > mysql-backup.sql

Back up the Nagios, metrics, git and scm files by copying the files on the associated persistent volumes:

Red Hat recommends backing up at least once per day, but you might decide to back up critical data more frequently.

You can back up a Core by following the Backing up a Core procedure. Once you have created the backup, you can restore a Core to the state at the time of backup.

Before restoring the data:

To restore the data:

Once all the components data has been restored, you can scale the components up through the web interface or start the components using the following commands:

oc scale --replicas=1 dc/fh-aaa
oc scale --replicas=1 dc/fh-appstore
oc scale --replicas=1 dc/fh-messaging
oc scale --replicas=1 dc/fh-metrics
oc scale --replicas=1 dc/fh-ngui
oc scale --replicas=1 dc/fh-scm
oc scale --replicas=1 dc/fh-supercore
oc scale --replicas=1 dc/gitlab-shell
oc scale --replicas=1 dc/memcached
oc scale --replicas=1 dc/millicore
oc scale --replicas=1 dc/nagios
oc scale --replicas=1 dc/redis
oc scale --replicas=1 dc/ups

After running this command, wait until all pods have been scaled up. Verify they are running using the following command:

oc get pods

All the components should be listed, including mysql and mongo and the left and right values in the READY column should be equal.

Log in to the Studio and ensure that all the projects, environments and MBaaS targets are correctly restored.

Red Hat Mobile Application (RHMAP) 4.x has a hybrid deployment model — the Core and the MBaaS are deployed in different locations.

The Mobile Backend-as-a-Service (MBaaS) is a core component of RHMAP – the back-end platform hosting containerized Cloud App in conjunction with database storage (MongoDB). The Cloud Apps deployed in an MBaaS can make use of RHMAP APIs, such as data synchronization, caching, or push notifications, and integrate with enterprise systems or other Cloud Services.

The RHMAP MBaaS 4.x is built on top of several technologies, including OpenShift v3, Kubernetes, Containers, and Red Hat Software Collections. The MBaaS consists of several components, each running in its own container. Similarly, every Cloud App deployed to the MBaaS runs in a container. Those containers are deployed and orchestrated by Kubernetes.

In the MBaaS, the users can configure multiple isolated runtime and storage environments to support software development life-cycle stages, such as development, testing, and production. Each environment can host multiple Cloud Apps.

Since the MBaaS is not hosted in Red Hat’s public multi-tenant cloud, the data transmitted between the mobile device and the Cloud App does not pass through any servers operated by Red Hat or any other third party. Private data from backend systems is transmitted directly between mobile devices and the MBaaS.

The following data still resides in the RHMAP Core:

This guide assumes several prerequisites are met before the installation:

For information on installation and management of an OpenShift cluster and its users, see the official OpenShift documentation.

The installation of an MBaaS in OpenShift 3 results in a resilient three-node cluster:

The installation consists of several phases. Before the installation, you must prepare your OpenShift cluster:

Follow these steps after configuring the OpenShift cluster:

oadm pod-network make-projects-global live-mbaas

oc get netnamespaces

oc label node mbaas-1 type=mbaas
oc label node mbaas-2 type=mbaas
oc label node mbaas-3 type=mbaas

oc get nodes -L type

NAME          STATUS                     AGE       TYPE
ose-master    Ready,SchedulingDisabled   27d       master
infra-1       Ready                      27d       infra
infra-2       Ready                      27d       infra
app-1         Ready                      27d       compute
app-2         Ready                      27d       compute
app-3         Ready                      27d       compute
mbaas-1       Ready                      27d       mbaas
mbaas-2       Ready                      27d       mbaas
mbaas-3       Ready                      27d       mbaas

oc label node mbaas-1 mbaas_id=mbaas1
oc label node mbaas-2 mbaas_id=mbaas2
oc label node mbaas-3 mbaas_id=mbaas3

oc get nodes -L mbaas_id

NAME          STATUS                     AGE       MBAAS_ID
10.10.0.102   Ready                      27d       <none>
10.10.0.117   Ready                      27d       <none>
10.10.0.141   Ready                      27d       <none>
10.10.0.157   Ready                      27d       mbaas3
10.10.0.19    Ready,SchedulingDisabled   27d       <none>
10.10.0.28    Ready                      27d       mbaas1
10.10.0.33    Ready                      27d       <none>
10.10.0.4     Ready                      27d       <none>
10.10.0.99    Ready                      27d       mbaas2

{
  "kind": "DeploymentConfig",
  "apiVersion": "v1",
  "metadata": {
    "name": "mongodb-1",
    "labels": {
      "name": "mongodb"
    }
  },
  "spec": {
    ...
    "template": {
      ...
      "spec": {
        "nodeSelector": {
          "mbaas_id": "mbaas1"
        }

Once the process of creating the MBaaS has successfully completed, you can see the new MBaaS in the list of MBaaS targets.

In your OpenShift account, you can see the MBaaS represented by a project.

In the RHMAP 4.x MBaaS based on OpenShift 3, each Cloud App and and each MBaaS component runs in its own container. This architecture allows for granular control of CPU and memory consumption. A fine level of control of system resources helps to ensure efficient use of nodes, and to guarantee uninterrupted operation of critical services.

An application can be prepared for various situations, such as high peak load or sustained load, by making decisions about the resource limits of individual components. For example, you could decide that MongoDB must keep working at all times, and assign it high, guaranteed amount of resources. At the same time, if the availability of a front-end Node.js server is less critical, the server can be assigned less initial resources, with the possibility to use more resources when available.

The system resources of MBaaS components and Cloud Apps in the MBaaS can be regulated using the mechanisms available in OpenShift – resource requests, limits, and quota. Before proceeding with the instructions in this guide, we advise you to read the Quotas and Limit Ranges section in the OpenShift documentation.

The RHMAP MBaaS is composed of several components, each represented by a single container running in its own pod. Each container has default resource requests and limits assigned in the MBaaS OpenShift template. See the section Overview of Resource Usage of MBaaS Components for a complete reference of the default values.

Depending on the deployment model of the MBaaS, you may have to adjust the resource limits and requests to fit your environment. If the MBaaS components are deployed on the same nodes as the Cloud Apps, there is no adjustment required.

However, when the MBaaS components are deployed on nodes dedicated to running the MBaaS only, it is strongly recommended to adjust the resource limits to take full advantage of the available resources on the dedicated nodes.

14 GiB / 5 = 2.8 GiB of RAM per component

3000 m / 5 = 600 m per component

The resource requests and limits of Cloud Apps can be set the same way as for MBaaS components. There is no particular guideline for doing the adjustment in Cloud Apps.

The procedure for setting the resource requests and limits is the same for both MBaaS components and Cloud App components.

For more information on resources, see Deployment Resources in the OpenShift documentation.

It is possible to view the immediate and historical resource usage of pods and containers in the form of donut charts and line charts using the Cluster Metrics deployment in OpenShift. Refer to Enabling Cluster Metrics in the OpenShift documentation for steps to enable cluster metrics.

Once cluster metrics are enabled, in the OpenShift web console, navigate to Browse > Pods and click on the component of interest. Click on the Metrics tab to see the visualizations.

Each Cloud App can automatically send alerts by e-mail when specified events occur, such as when the Cloud App gets deployed, undeployed, or logs an error. See Alerts & Email Notifications for more information.

For the RHMAP 4.x MBaaS based on OpenShift 3, the e-mail function is not available immediately after installation. You must configure an SMTP server to enable e-mail support.

The FH_EMAIL_SMTP and FH_EMAIL_ALERT_FROM environment variables in the fh-mbaas DeploymentConfig need to be set, using the below commands:

oc project <mbaas-project-id>
oc env dc/fh-mbaas FH_EMAIL_SMTP="smtps://username:password@localhost" FH_EMAIL_ALERT_FROM="rhmap-admin@example.com"

After modifying the DeploymentConfig, a redeploy of the fh-mbaas pod should be triggered automatically. Once the pod is running again, you can verify the changes.

You should receive an e-mail from the e-mail address set as FH_EMAIL_ALERT_FROM.

If the test email fails to send, verify the SMTP settings in the running fh-mbaas Pod.

oc env pod -l name=fh-mbaas --list | grep EMAIL

It may help to view the fh-mbaas logs while attempting to send an email, looking for any errors related to SMTP or email.

oc logs -f fh-mbaas-<deploy-uuid>

Ensure the Cloud App you are using to send a test mail with is running. If the test email sends OK, but fails to arrive, check it hasn’t been placed in your spam or junk folder.

As most of the data being backed up is the data stored in the platform’s Cloud Apps, the amount of backup storage space required is proportional to the amount of data stored by the Cloud Apps.

Other factors that have an impact on how much storage is required for backups include:

You must back up the following items to back up an MBaaS:

Back up the MongoDB data using the mongodump command in combination with the oc exec command:

oc exec `oc get po --selector='deploymentconfig=mongodb-1' --template="{{(index .items 0).metadata.name}}"` bash -- -c '/opt/rh/rh-mongodb32/root/usr/bin/mongodump -u admin -p ${MONGODB_ADMIN_PASSWORD} --gzip --archive' > ./mbaas_mongodb.gz

Back up the Nagios data by copying the files from the Nagios pod using the oc exec command:

oc exec <nagios-pod-name> bash -- -c 'tar -zcf - /var/log/nagios/' > nagios-backup.tar.gz

For example, if the <nagios-pod-name> is nagios-1:

oc exec nagios-1 bash -- -c 'tar -zcf - /var/log/nagios/' > nagios-backup.tar.gz

Red Hat recommends backing up at least once per day, but you might decide to back up critical data more frequently.

The example script below shows how you can back up an MBaaS from a backup server, assuming that the user on the backup server has permission to execute commands via the oc binary:

ts=$(date +%y-%m-%d-%H-%M-%S)
# Backup the Mongo services
project=mbaas
for pod in $(oc get pods -n $project | grep mongodb-[0-9]-[0-9]-[0-9a-zA-Z] | awk '{print $1}'); do
	service=$(echo $pod | cut -f1,2 -d"-");
    oc exec $pod bash -- -c '/opt/rh/rh-mongodb32/root/usr/bin/mongodump -u admin -p ${MONGODB_ADMIN_PASSWORD} --gzip --archive' > $project-$service-$ts.gz
done

# Backup the Nagios service
oc exec -n $project <nagios-pod-name> bash -- -c 'tar -zcf - /var/log/nagios/' > nagios-backup-$ts.tar.gz

You can back up an MBaaS by following the Backing up an MBaaS procedure. Once you have created the backup, you can restore a MBaaS to the state at the time of backup.

To restore the MongoDB data, the replicaset must be operational. If this is not the case, see the MongoDB doesn’t respond after repeated installation of the MBaaS section of this guide.

Should you encounter isses with MongoDB, see Troubleshooting MongoDB Issues.

Log in to the Studio and ensure that all the projects, environments and MBaaS targets are correctly restored.

This document provides information on how to identify, debug, and resolve possible issues that can be encountered during installation and usage of the RHMAP MBaaS on OpenShift 3.

In Common Problems, you can see a list of resolutions for problems that might occur during installation or usage of the MBaaS.

The first step to check whether an MBaaS is running correctly is to see the output of its health endpoint. The HTTP health endpoint in the MBaaS reports the health status of the MBaaS and of its individual components.

From the command line, run the following command:

curl https://<MBaaS URL>/sys/info/health

To find the MBaaS URL:

If the MBaaS is running correctly without any errors, the output of the command should be similar to the following, showing a "test_status": "ok" for each component:

{
 "status": "ok",
 "summary": "No issues to report. All tests passed without error",
 "details": [
  {
   "description": "Check fh-statsd running",
   "test_status": "ok",
   "result": {
    "id": "fh-statsd",
    "status": "OK",
    "error": null
   },
   "runtime": 6
  },
...
}

If there are any errors, the output will contain error messages in the result.error object of the details array for individual components. Use this information to identify which component is failing and to get information on further steps to resolve the failure.

You can also see a HTTP 503 Service Unavailable error returned from the health endpoint. This can happen in several situations:

Alternatively, you can see the result of this health check in the Studio. Navigate to the Admin > MBaaS Targets section, select your MBaaS target, and click Check the MBaaS Status.

If there is an error, you are presented with a screen showing the same information as described above. Use the provided links to OpenShift Web Console and the associated MBaaS Project in OpenShift to help with debugging of the issue on the OpenShift side.

To see the logging output of individual MBaaS components, you must configure centralized logging in your OpenShift cluster. See Enabling Centralized Logging for a detailed procedure.

The section Identifying Issues in an MBaaS provides guidance on discovering MBaaS failures by searching and filtering its logging output.