Mojaloop Helm Charts

• Mojaloop Helm Charts
  • Quick Links
  • Pre-requisites
    • Configure remote Mojaloop Helm repo on your Helm Client
  • Deployment
    • Deploying Backend Dependencies
    • Deploying Mojaloop Helm Charts
    • Deploying development versions
  • Upgrading Deployments from Repo
  • Deployment from Source for local repo deployments
    • Update Chart Dependencies for Source for local repo deployments (i.e. from the cloned github repository)
    • Deployment
  • Upgrading Deployments from Source
  • Testing Deployments
    • Validation
    • Ingress
  • Removing Deployments
  • Debugging Charts
  • Helper scripts
  • Monitoring Mojaloop
  • Batch Processing

Quick Links

• http://mojaloop.io/helm/repo/ Mojaloop Published Helm Repo
• Documentation - Deploying Mojaloop
• Helm v3 Docs
• Changelogs
  • release-v15.1.0.md
  • release-v15.0.0.md
  • release-v14.1.1.md
  • release-v14.1.0.md
  • release-v14.0.0.md
  • release-v13.1.0.md
  • release-v13.0.2.md
  • release-v13.0.1.md
  • release-v13.0.0.md

Pre-requisites

1. Add Helm dependency repositories:

   helm repo add stable https://charts.helm.sh/stable
   helm repo add incubator https://charts.helm.sh/incubator
   helm repo add kiwigrid https://kiwigrid.github.io
   helm repo add kokuwa https://kokuwaio.github.io/helm-charts
   helm repo add elastic https://helm.elastic.co
   helm repo add codecentric https://codecentric.github.io/helm-charts
   helm repo add bitnami https://charts.bitnami.com/bitnami
   helm repo add mojaloop-charts https://mojaloop.github.io/charts/repo 
   helm repo add redpanda https://charts.redpanda.com

Configure remote Mojaloop Helm repo on your Helm Client

1. Add Mojaloop repo

   helm repo add mojaloop https://mojaloop.io/helm/repo/

2. Keep your local Mojaloop repo up to date

   helm repo update

Deployment

Deploying Backend Dependencies

It is recommended and it is a best practice that you deploy each External Backend Dependencies (i.e. MySQL, Kafka, MongoDB, etc) as a separate deployment as to ensure that each deployment is operationally isolated and maintainable.

We have provided an example Helm Wrapper chart that packages all dependencies, called the example-mojaloop-backend Helm chart. The example-mojaloop-backend is provided purely for convenience and should only be used for PoC environments, and for testing purposes. You can also use this as a reference to determine which External Dependency Helm charts can be utilized for this purpose, and how to potentially configure them.

Refer to example-mojaloop-backend/README.md#installation on how to deploy the example-mojaloop-backend.

The following Helm Charts have the following external dependencies:

Chart	Dependency	Notes
Account-Lookup-Service	MySQL
Quoting-Service	MySQL
ML-API-Adapter	Kafka
Central-Ledger	Kafka, MySQL, MongoDB
Central-Settlements	MySQL
Central-Event-Processor	Kafka, MongoDB
Transaction-Request-Service	N/A
Thirdparty Auth-Service	Redis, MySQL
Thirdparty Consent Oracle	MySQL
Thirdparty SDK	N/A
Simulator	N/A
Mojaloop-Simulator	Redis	There is a dependency on Redis, however due to the dynamic nature of the Mojaloop-Simulator, a Redis container will be created dynamically for each configured Simulator.
Mojaloop-Testing-Toolkit	MongoDB
Mojaloop-TTK-Simulators	Redis, MongoDB
SDK-Scheme-Adapter	Redis, Kafka
Bulk-API-Adapter	Kafka, MongoDB

Deploying Mojaloop Helm Charts

1. Deploy the Mojaloop chart

   This chart is a "Wrapper" chart that packages the core Mojaloop components that one would use as a base "Switch" deployment. It includes all the components that one needs for executing and testing the Discovery, Quoting, and Transfer phases of the FSPIOP API specification, as well as supporting components for Bulk, and Settlement Processing.

   Warning: This will deploy all core Mojaloop charts with default backends configurations. See #deploying-backend-dependencies on how to deploy them using the example-mojaloop-backend/README.md Helm chart.

   • helm --namespace <namespace> install <release_name> mojaloop/mojaloop

   e.g. helm --namespace moja install dev mojaloop/mojaloop

2. Deploy Mojaloop with Bulk-API-Adapter

   Warning: This will deploy all core Mojaloop charts. and the Bulk-API-Adapter

   • helm --namespace <namespace> install <release_name> mojaloop/mojaloop --set mojaloop-bulk.enabled=true --set ml-ttk-test-val-bulk.tests.enabled=true

   e.g. helm --namespace moja install dev mojaloop/mojaloop --set mojaloop-bulk.enabled=true --set ml-ttk-test-val-bulk.tests.enabled=true

3. Deploy Mojaloop with Thirdparty components

   Refer to thirdparty/README.md for more information on what pre-requisites are required to enable Thirdparty components and how to manually deploy backend dependencies.

4. Deploy Mojaloop with Bulk-API-Adapter and SDK-TTK Bulk simulators

   Warning: This will deploy all core Mojaloop charts., the Bulk-API-Adapter and additional SDK+TTK simulators

   • helm --namespace <namespace> install <release_name> mojaloop/mojaloop --set mojaloop-bulk.enabled=true --set ml-ttk-test-val-bulk.tests.enabled=true

   e.g. helm --namespace moja install dev mojaloop/mojaloop --set mojaloop-bulk.enabled=true --set ml-ttk-test-val-bulk.tests.enabled=true --set mojaloop-ttk-simulators.enabled=true --set global.kafka.host=<MOJALOOP_INSTALL_NAME>-kafka --set global.redis.host=<REDIS_INSTALL_NAME>-redis-master --set ml-ttk-test-val-sdk-bulk.tests.enabled=true

5. Deploy specific chart

   Warning: This will deploy a single Mojaloop charts. You will need to ensure that you have met all pre-requisites for that chart (e.g. external dependencies such as MySQL, Kafka, AND internal dependencies such as the Central-Ledger API Service). This can be done by customization the values.yaml of each chart to suite your environment.

   • helm --namespace <namespace> install <release_name> mojaloop/<chart_name> -f {custom-values.yaml}

   e.g. helm --namespace moja install dev mojaloop/centralledger -f ./values.yaml

   Refer to the following default chart config file for configurable values: http://mojaloop.io/helm/<chart_name>/values.yaml

   Alternatively one can set specific values via cli arguments based on the config file above:

   • helm --namespace <namespace> install <release_name> mojaloop/<chart_name> --set foo=bar --set {key.subkey.subsubkey}={value}

6. Deploy specific version for a chart

   • helm --namespace <namespace> install <release_name> mojaloop/<chart_name> --version {version}

   e.g. helm --namespace moja install dev mojaloop/centralledger --version v1.0.0

   Refer to the following default chart config file for values: http://mojaloop.io/helm/<chart_name>/values.yaml

Deploying development versions

1. To deploy the latest development version, use the --devel flag:

   • helm --namespace <namespace> install <release_name> mojaloop/mojaloop --devel

     This is useful if you've had some work merged into master but it has not yet been released.

     The --devel flag can also be supplied to helm search and helm upgrade commands.

     Development versions can be specified in a requirements.yaml file if you're using Mojaloop as a child chart.

Upgrading Deployments from Repo

helm --namespace <namespace> upgrade <release-name> mojaloop/<chart_name>

e.g. helm --namespace moja upgrade dev mojaloop/centralenduserregistry

Deployment from Source for local repo deployments

Update Chart Dependencies for Source for local repo deployments (i.e. from the cloned github repository)

Run the following script sh ./update-charts-dep.sh in the helm root folder.

This script will ensure that all dependencies and child-dependencies are updated correctly. This is temporary until recursive updates is supported in future: helm/helm#2247.

Deployment

1. Deploy specific chart

   • helm --namespace <namespace> install <release_name> <chart_folder>

   e.g. helm --namespace mojaloop install dev ./centralledger

2. Deploy the Mojaloop chart

   Warning: This will deploy all core Mojaloop charts with default backends. See #deploying-backends on how to disabled the default backends and deploy them using the example-mojaloop-backend/README.md Helm chart.

   • helm --namespace <namespace> install <release_name> mojaloop

   e.g. helm --namespace mojaloop install dev ./mojaloop

Upgrading Deployments from Source

• helm --namespace <namespace> upgrade <release-name> <chart_folder>

e.g. helm --namespace mojaloop upgrade dev ./centralenduserregistry

Testing Deployments

Validation

Note: This is currently only supported by Helm v3.

Mojaloop Helm deployments currently include the following provisioning (setup) and test (val) collections:

Helm Test	Test Cases	Description	Enabled by default?	Notes
ml-ttk-test-setup.tests	hub/provisioning	Standard Provisioning Collection	Yes	Required as a pre-requisite for all tests.
ml-ttk-test-val-gp	hub/golden_path	Golden-Path (GP) Test Collection	Yes	Previously named ml-ttk-test-validation prior to v13.1.0 release.
ml-ttk-test-val-bulk	hub/other_tests/bulk_transfers	Bulk Test Collection	No	mojaloop-bulk.enabled=true must be set to deploy the Bulk-API-Adapter components.
ml-ttk-test-setup-sdk-bulk	hub/provisioning_sdkbulk	SDK Bulk Provisioning Collection	No	mojaloop-bulk.enabled=true & mojaloop-ttk-simulators.enabled=true must be set to deploy the Bulk-API-Adapter and TTK Simulators components.
ml-ttk-test-val-sdk-bulk	hub/sdk_scheme_adapter/bulk	SDK Bulk Test Collection	No	mojaloop-bulk.enabled=true & mojaloop-ttk-simulators.enabled=true must be set to deploy Bulk-API-Adapter and TTK Simulators components. components.
ml-ttk-test-val-sdk-r2p	hub/sdk_scheme_adapter/request-to-pay	SDK Request To Pay Test Collection	No	mojaloop-ttk-simulators.enabled=true must be set to deploy the TTK Simulators components. components.
ml-ttk-test-setup-tp	hub/provisioning_thirdparty	Thirdparty Provisioning Collection	No	thirdparty.enabled=true, account-lookup-service.account-lookup-service.config.featureEnableExtendedPartyIdType=true & account-lookup-service.account-lookup-service-admin.config.featureEnableExtendedPartyIdType=true must be set to deploy the Thirdparty components.
ml-ttk-test-val-tp	hub/thirdparty	Thirdparty Test Collection	No	thirdparty.enabled=true, account-lookup-service.account-lookup-service.config.featureEnableExtendedPartyIdType=true & account-lookup-service.account-lookup-service-admin.config.featureEnableExtendedPartyIdType=true must be set to deploy the Bulk-API-Adapter components.
ml-ttk-test-cleanup	hub/cleanup	Thirdparty Test Collection	Yes	Post cleanup scripts, e.g. executes position reset test collection. Note that ml-ttk-test-cleanup.test.config.saveReport is disabled by default.

1. Ensure Tests are enabled

   Ensure the following properties are set in your values.yaml file depending on which tests you wish to execute:

   • ml-ttk-test-setup.tests.enabled=true
   • ml-ttk-test-val-gp.tests.enabled=true
   • ml-ttk-test-val-bulk.tests.enabled=true (Note: only applicable if mojaloop-bulk.enabled=true is set)
   • ml-ttk-test-setup-sdk-bulk.tests.enabled=true (Note: only applicable if mojaloop-bulk.enabled=true, mojaloop-ttk-simulators.enabled=true is set)
   • ml-ttk-test-val-sdk-bulk.tests.enabled=true (Note: only applicable if mojaloop-bulk.enabled=true, mojaloop-ttk-simulators.enabled=true is set)
   • ml-ttk-test-val-sdk-r2p.tests.enabled=true (Note: only applicable if mojaloop-ttk-simulators.enabled=true is set)
   • ml-ttk-test-setup-tp.test.enabled=true (Note: only applicable if thirdparty.enabled=true, account-lookup-service.account-lookup-service.config.featureEnableExtendedPartyIdType=true & account-lookup-service.account-lookup-service-admin.config.featureEnableExtendedPartyIdType=true is set)
   • ml-ttk-test-val-tp.test,enabled=true (Note: only applicable if thirdparty.enabled=true, account-lookup-service.account-lookup-service.config.featureEnableExtendedPartyIdType=true & account-lookup-service.account-lookup-service-admin.config.featureEnableExtendedPartyIdType=true is set)
   • ml-ttk-test-cleanup.test.enabled=true

   Or alternatively add --set for each of the above parameters on the install command:

   helm install ... --set ml-ttk-test-setup.tests.enabled=true --set ml-ttk-test-val-gp.tests.enabled=true ...

2. Run Tests

   Run tests: helm test <RELEASE_NAME>

   Run tests with logs:

   helm test <RELEASE_NAME> --logs

Ingress

1. Add the following to your hosts file and ensure you have installed Ingress Controller on your Kubernetes Cluster:

   <ip-of-k8s-node-ingress> ml-api-adapter.local central-ledger.local account-lookup-service.local quoting-service.local central-settlement.local moja-simulator.local testing-toolkit.local testing-toolkit-specapi.local

2. Curl Health End-points for ML-API-Adapter

   • curl http://ml-api-adapter.local/health

   Expected output:

   {"status":"OK"}

3. Curl Health End-points for Central Ledger

   • curl http://central-ledger.local/health

   Expected output:

   {"status":"OK"}

4. Testing Toolkit

   Open http://testing-toolkit.local in your browser.

   Or access the Mobile Simulator Demo directly on http://testing-toolkit.local/mobilesimulator.

   Check out the User Guide to learn more about the Testing Toolkit.

Removing Deployments

• helm --namespace <namespace> del <release-name>

e.g. helm --namespace mojaloop del dev

Debugging Charts

1. Execute a dry-run to display all the Kubernetes deployment files

   • helm --namespace <namespace> install <release_name> <chart_folder> --dry-run

2. Enable debug to display raw configurations that will be injected into Helm templates

   • helm --namespace <namespace> install <release_name> <chart_folder> --dry-run --debug

3. Use Helm Linter to check for any issues

   • helm lint --strict <chart_folder>

Helper scripts

# lint all parent charts and ensure they conform to Helm's standards
./lint-charts.sh

# Update all charts, and their respective dependencies (requirements).
./update-charts-dep.sh

# Package all charts, and created an index.yaml in ./repo directory
./package.sh

Monitoring Mojaloop

Refer to Monitoring Documentation

Batch Processing

To enable batch processing in your system, please follow the steps below:

• 1. Add a New Kafka Topic: Add a new topic named topic-transfer-position-batch to your Kafka configuration. If you are using the example-mojaloop-backend for your backend dependencies, this topic is already added to the Kafka provisioning section by default.

• 2. Update Mojaloop Values File: In the Mojaloop values file, make sure to enable the batch_processing_enabled flag in the global configuration.

  global:
      batch_processing_enabled: &CL_BATCH_PROCESSING_ENABLED true

  Enabling this variable does the following

  a. Activates Batch Position Handler: Triggers the activation of the Batch Position Handler.

  b. Configures Prepare Handler for Kafka Events: The configuration change also sets up the Prepare Handler to publish Kafka events to the newly designated batch topic.

  Note:

  Please note that this configuration change relies on the use of the YAML anchor CL_BATCH_PROCESSING_ENABLED._

  It's essential to consider the context of your deployment. If you have the entire Helm values file as an override, this configuration change will work seamlessly.

  However, if you are using a Helm override file with only a subset of values overridden, ensure that you include all the configuration parameters associated with the CL_BATCH_PROCESSING_ENABLED anchor. Failing to include these parameters might result in unexpected behavior.

Known Issues

1. Snapshot releases will fail if the commit SHA starts with a 0 - helm/helm#7064