Upgrading RHMAP 4.6 to 4.7

Red Hat Mobile Application Platform 4.7

For Red Hat Mobile Application Platform 4.7

Red Hat Customer Content Services

Abstract

This document contains detailed instructions for upgrading an RHMAP 4.6 installation to RHMAP 4.7.

Preface

Note

Upgrading RHMAP is a resource intensive process. Allow each step to complete before proceeding to the following step.

Chapter 1. Preparing Infrastructure for Upgrading

You can upgrade RHMAP by either

  • Installing Ansible version 2.4 and running the installer scripts.
  • Running a docker container, which has ansible installed, and running the installer scripts in that container.

To prepare for the upgrade:

  1. Ensure that RHMAP is deployed to a compatible OpenShift installation.
  2. Install Ansible version 2.4 as described in Ansible Installation Guide. After installing Ansible, configure Ansible for installing RHMAP components.
  3. Install the RHMAP OpenShift Templates.
  4. Set up an inventory file.
Note

Before proceeding with the automated upgrade, Red Hat recommends you use the RHMAP Ansible scripts to download the new images onto each of the target nodes. For instructions, see Seeding the Nodes with the RHMAP Images.

This step improves the robustness of the upgrade process, especially on low speed networks.

1.1. Using Docker to Upgrade RHMAP (Optional)

An alternative method for upgrading is to use the RHMAP installer docker image, which includes Ansible and the templates, so you do not need to install Ansible.

Enter the following command to download the docker image: 

docker pull rhmap47/installer

The procedures in this guide provide example commands for using this container.

Chapter 2. Upgrading the Core Project 4.6 to 4.7.0

2.1. Overview

Upgrading Red Hat Mobile Application Platform from version 4.6 to version 4.7.0 includes the following changes:

  • Existing images versions are updated to RHMAP 4.7 versions by modifying the deployment configurations for all objects in the RHMAP Core, which triggers a redeployment of each component.
  • The project version in the platform-info ConfigMap in the RHMAP Core project is updated to 4.7.
Warning

Before proceeding with the upgrade:

2.2. Upgrading to RHMAP Core Version 4.7

Note

The OpenShift templates for RHMAP Core are installed into the /opt/rhmap/4.7/templates/core directory.

  1. If you are using the docker image option, mount an inventory file and a valid SSH key for targeting that inventory, for example: 

    docker run -it \
       -v ~/.ssh/id_rsa:/opt/app-root/src/.ssh/id_rsa:Z \
       -v ${HOME}/Desktop/rhmap-ansible/inventories:/opt/app-root/src/inventories \
       -e ANSIBLE_PRIVATE_KEY_FILE=/opt/app-root/src/.ssh/id_rsa \
	   rhmap47/installer bash

  2. To upgrade your existing RHMAP Core from 4.6 to 4.7 you must specify:

    • the name of the current project
    • an inventory file

    • project_type which must be set to core.

      An example command is shown below: 

      cd /opt/rhmap/4.7/rhmap-ansible
ansible-playbook -i my-inventory-file playbooks/upgrade.yml -e project_type=core -e project_name=my-rhmap-core-project

      This command reads the current deployment information and chooses the next available upgrade path. A warning message is displayed advising you to back up your data before proceeding. Press Enter to confirm that you have backed up and to continue with the upgrade.

2.3. Verifying RHMAP Core Upgrade

  1. Review the output to verify there were no failures.
  2. Verify all Nagios checks are healthy.
  3. Make sure the component versions match those in the Container Catalog for the erratum.

See the troubleshooting documentation in cases where the upgrade fails.

Chapter 3. Upgrading Each MBaaS Project 4.6 to 4.7.0

3.1. Overview

Upgrading your deployment of Red Hat Mobile Application Platform from version 4.7 to version 4.7.0:

  • Adds the MONGODB_ENDPOINT_COUNT to the Nagios deployment configuration.
  • Adds annotations to group related services together in the OpenShift UI.
  • Adds the node-proxy ConfigMap Volume mount to fh-statsd.
  • Existing images versions are updated to RHMAP 4.7 versions by modifying the deployment configurations for all objects in the RHMAP MBaaS, which triggers a redeployment of each component.
  • Updates the version in fh-mbaas-info-info ConfigMap in the RHMAP MBaaS project to 4.7
Warning

Before proceeding with the upgrade:

  • Ensure you have administrator permissions for the OpenShift cluster hosting RHMAP.

3.2. Upgrading to RHMAP MBaaS Version 4.7

  1. If you are using the docker image option, mount an inventory file and a valid SSH key for targeting that inventory, for example: 

    docker run -it \
       -v ~/.ssh/id_rsa:/opt/app-root/src/.ssh/id_rsa:Z \
       -v ${HOME}/Desktop/rhmap-ansible/inventories:/opt/app-root/src/inventories \
       -e ANSIBLE_PRIVATE_KEY_FILE=/opt/app-root/src/.ssh/id_rsa \
	   rhmap47/installer bash

  2. With all pods running, back up all persistent volumes using the following commands: 

    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

  3. To upgrade your existing RHMAP MBaaS from 4.6 to 4.7 you must specify:

    • the name of the current project
    • an inventory file

    • project_type which must be set to 1-node-mbaas or 3-node-mbaas.

      An example command is shown below: 

      cd /opt/rhmap/4.7/rhmap-installer
ansible-playbook -i my-inventory-file playbooks/upgrade.yml -e project_type=3-node-mbaas -e project_name=my-rhmap-mbaas-project

      This command reads the current deployment information and chooses the next available upgrade path. A warning message is displayed advising you to back up your data before proceeding. Press Enter to confirm that you have backed up and to continue with the upgrade.

3.3. Verifying RHMAP MBaaS Upgrade

  1. Review the output to verify there were no failures.
  2. Verify all Nagios checks are healthy.
  3. Make sure the component versions match those in the Container Catalog for the erratum.

  4. Verify the mongo replica set has persisted throughout the upgrade. On any mongo pod:

    1. Run oc rsh {{MONGO_POD}}

    2. Log in to the mongo cli:

      mongo admin -u admin -p $MONGODB_ADMIN_PASSWORD

    3. Run rs.status()

      Review the json output and make sure there is one PRIMARY and two SECONDARY members.

See the troubleshooting documentation in cases where the upgrade fails.

Legal Notice

Copyright © 2018 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.