Home
MATRIXX Configuration
Configuring MATRIXX Using Helm
Configure MATRIXX by adding values for properties from the MATRIXX Helm chart in your Helm values file. The MATRIXX Helm chart includes component sub-charts in a hierarchy of reusable components.
Common Sub-Chart Properties
Each MATRIXX component has an corresponding Helm sub-chart that can be configured from the main chart.
Configuration Sources
Configuration for MATRIXX components can come from configuration sources based on Docker images, Git repositories, or Kubernetes ConfigMaps. Configuration sources can be defined at a global level and used by as many components as required. Attributes of a configuration source can be overridden when referenced at the component level as needed.
Secure Git Repositories
Use SSH keys to secure Git repositories that contain configuration information. Git-based configuration sources allow you to define the name of a Kubernetes secret in the same namespace containing your private SSH key.

Welcome
MATRIXX Release Notes
MATRIXX Architecture
MATRIXX Installation and Upgrade
MATRIXX Configuration
- About MATRIXX Configuration
  MATRIXX Configuration describes the tasks required to configure MATRIXX components.
- Configuring MATRIXX Using Helm
  Configure MATRIXX by adding values for properties from the MATRIXX Helm chart in your Helm values file. The MATRIXX Helm chart includes component sub-charts in a hierarchy of reusable components.
  - Managing Helm Values Files
    In complex installations it may be necessary or helpful to use more than one Helm values file. The helm install and helm upgrade commands can accept multiple values files, with values in files listed later taking precedence. Layering Helm values files in this way can be used to reduce duplication.
  - MATRIXX Helm Chart Properties
    The MATRIXX Helm chart, and by extension a cloud native MATRIXX deployment, are configured using a Helm values file or files.
  - Topology Operator Configuration
    For information about Topology Operator configuration, including Topology Operator-related health checking, pricing, tax, and multi-tenancy configuration, see the discussion about Topology Operator configuration in MATRIXX Installation and Upgrade.
  - Common Sub-Chart Properties
    Each MATRIXX component has an corresponding Helm sub-chart that can be configured from the main chart.
    - Enablement
      Each MATRIXX component can be individually enabled.
    - Replicas
      The number of pods, or replicas, of a MATRIXX component can be individually specified.
    - Overriding Image Characteristics
      Characteristics of images for MATRIXX components can be overridden.
    - Configuration Sources
      Configuration for MATRIXX components can come from configuration sources based on Docker images, Git repositories, or Kubernetes ConfigMaps. Configuration sources can be defined at a global level and used by as many components as required. Attributes of a configuration source can be overridden when referenced at the component level as needed.
      - Docker-Based Configuration Sources
        A configuration source of type docker specifies the name, registry, Kubernetes image pull credentials, and directories to unpack for an image. The default assumption is that the image resides in the same image repository as the MATRIXX images, but an alternative repository can also be specified. You can specify access credentials or reference an existing Kubernetes secret that has those details.
      - ConfigMap-Based Configuration Sources
        A configuration source of type configmap either dynamically defines a Kubernetes ConfigMap or references an existing ConfigMap in the same namespace.
      - Git-Based Configuration Sources
        A configuration source of type git performs a git clone command of a Git repository into an initContainer before unpacking files to the shared volume on the pod.
      - Secure Git Repositories
        Use SSH keys to secure Git repositories that contain configuration information. Git-based configuration sources allow you to define the name of a Kubernetes secret in the same namespace containing your private SSH key.
      - Pricing Configuration
        Pricing information can be updated from a configuration source. docker_kubernetes/c_conf_sources_pricing.html#c_conf_sources_pricing__table_xzh_tpc_nqb describes the available configuration properties.
      - Configuration Sources for MATRIXX Engine
        Configuration sources for MATRIXX Engine and Traffic Routing Agent (TRA-PROC, and TRA-PUB) pods can be defined at a number of different levels as shown in docker_kubernetes/c_conf_sources_eng_tra.html#c_conf_sources_eng_tra__table_xzh_tpc_nqb. Values are not merged. The most specific definition is used.
      - Configuration Sources for Other Components
        MATRIXX components outside of MATRIXX Engine can retrieve configuration data from configuration sources defined at the global level using the property described in docker_kubernetes/c_conf_sources_other.html#c_conf_sources_other__table_xzh_tpc_nqb.
      - Configuration Image Contents
        The default configuration for a MATRIXX component can be overridden as needed, using a configuration source. The contents of images for Docker-type configuration sources vary depending on the component the image reconfigures.
      - Pre-Set Sideloader Configurations
        Certain default configurations for MATRIXX components must not be changed using a MATRIXX Engine or Traffic Routing Agent (TRA) configuration source.
      - Configuration Image Template for Java Apps
        MATRIXX provides a template to help you build custom configuration images for the MATRIXX Java-based MATRIXX gateways and web apps.
    - Dynamic Configuration
      The configuration properties described in docker_kubernetes/c_config_helm_sub_chart_dyn_config.html#c_config_helm_sub_chart_sideload2__table_ljx_525_ylb allow a ConfigMap to be dynamically created for a component and mounted to /sync/conf, which is synchronized with /opt/mtx/conf in the component container at start-up, using rsync.
    - Logging Level
      docker_kubernetes/c_config_helm_sub_chart_logging.html#c_config_helm_sub_chart_logging__table_llp_wdp_ylb describes the property that controls the logging level in Helm sub-charts.
    - Environment Variables and Command Arguments
      Use configuration properties to set environment variables and pass command arguments for a component.
    - Extensions for External Volumes
      These configuration properties allow an external volume to be mounted as /sync/ext, which is synchronized with the /opt/mtx/ext directory in the component container at start-up.
    - Service and Service Account Configuration
      These configuration properties specify Services for components and the ServiceAccount that the components should run under. This might be an existing ServiceAccount or one that needs to be created.
    - Role-Based Access Control
      There are three types of users with different levels of access to the Kubernetes cluster(s) and the Kubernetes APIs which they can use.
    - Ingress
      These sub-chart configuration properties can be used to configure an Ingress for a component. Typically, these settings would only be used for components that support web traffic such as RS Gateway, My MATRIXX, or MATRIXX Backoffice Customer Tool. A joint Ingress for these components can also be created using a Proxy Ingress. This might be preferred if all three web apps are configured to run on the same host.
    - Autoscaling Configuration
      The number of pods for MATRIXX gateways and web apps in ReplicaSets can scale up and down based on metrics. Metrics that can trigger scaling include but are not limited to memory usage, CPU usage, transactions per second (TPS), and latency.
    - Other Overrides
      The component sub-charts allow you to override default settings for several Kubernetes features.
  - Component-Specific Sub-Chart Properties
    Each MATRIXX Helm sub-chart has component-specific properties.
- Configuring MATRIXX Engine
  MATRIXX Engine configuration can be applied from a configuration source.
- Configuring Traffic Routing Agent
  Traffic Routing Agent (TRA) configuration can be added to the deployment with a configuration source.
- Configuring Sub-Domain Routing (Multiple Sub-domains)
  In a MATRIXX environment where multiple customer sub-domains are implemented in separate engine chains, you configure sub-domain routing so that traffic is directed to the correct customer sub-domain where the subscriber is homed. You must configure different components across MATRIXX for sub-domain routing to work.
- Example Single Domain Deployments
  Example configurations are provided for single-engine, dual-engine, and dual-engine with Traffic Routing Agent in disaster recovery mode (TRA-DR) cloud native MATRIXX examples.
- Configuring MATRIXX Gateways and Web Apps
  In a non-containerized installation of MATRIXX, configure MATRIXX gateways and web apps using files in the /opt/mtx/conf directory in the pod(s) hosting those components. In a cloud native deployment, configuration files can be provided in the /opt/mtx/conf directory of the component container(s) using the following methods:
- Configuring CDR Processing
  The MATRIXX Engine can import and rate Solution42® call detail records (CDRs) and generate MATRIXX Event Detail Records (EDRs) from them. Generally, this is used only when integrating with an Oracle BRM system. Other projects should use external mediation to convert external CDRs into Diameter messages for MATRIXX processing.
- Configuration Input Settings
  In a cloud native MATRIXX installation, MATRIXX Engine configuration specified in the create_config.info file is applied with a configuration source. This file contains a list of the questions asked by the configuration script during the configuration process and the answers provided by the administrator. Each question sets a configuration parameter. The engine(s) are configured with these parameters with a helm upgrade command.
MATRIXX Security
MATRIXX Integration
MATRIXX Diameter Integration
MATRIXX Call Control Framework Integration
MATRIXX TM Forum Integration
MATRIXX 5G Integration
MATRIXX 5G Event Streaming
MATRIXX Event Streaming
MATRIXX Administration
MATRIXX Web App Administration
MATRIXX Monitoring and Logging
MATRIXX Policy
MATRIXX Kafka CDR Consumer
MATRIXX Pricing and Rating
MATRIXX Pay Now
MATRIXX Subscriber Management
MATRIXX Subscriber Management API
MATRIXX Business API SDK
My MATRIXX Help
MATRIXX Backoffice Customer Tool Help
MATRIXX Third-Party Licenses
Glossary

Secure Git Repositories

Use SSH keys to secure Git repositories that contain configuration information. Git-based configuration sources allow you to define the name of a Kubernetes secret in the same namespace containing your private SSH key.

Procedure

Create an SSH key pair with the following command:
```
ssh-keygen -t ed25519
```
You are prompted to enter a location to save the keys. The default is an .ssh directory in your home directory.
(Optional) Supply a passphrase.
Create a known_hosts file within the secret allowing access to the Git repository server. This file can be created using the following command:
```
ssh-keyscan -H gitlab.acme.com >> known_hosts
```
Create the secret from the private key file, the known_hosts file, and the passphrase (if you specified one when creating the SSH key) with the following command:
```
kubectl create secret generic acme-gitlab-sshkey --from-file id_ed25519 --from-file known_hosts --from-literal=passphrase=mypassphrase
```

What to do next

If you are unable to use SSH keys for securing access to your Git repository, use the repositoryCredentials.secretName property to reference a Kubernetes secret, the contents of which are copied to ~/.config/git within the initContainer. This can include a credentials file that can be used to store your Git repository user credentials. See Git documentation for more information.