How the platform fits together

Read this page once before you plan the installation. Every later page in the guide refers back to it.

Three things you install, four things you provide

The following table lists each part of an installation and who provides it:

Part	What it is	Who provides it
OpenLM Platform chart (openlm-platform)	One Helm chart that installs every OpenLM service and web UI, about 100 small applications. Each one is a component you can switch on or off.	OpenLM, from the public Helm repository
API gateway chart (openlm-gateway)	Routes /api/... calls from the web UIs to the correct service. You install it as its own small Helm release.	OpenLM, as a chart package
Your values file	One YAML file that describes your installation: your web address, which components are on, how pods are placed.	You, from the template in this guide
SQL Server	Four databases: operational, reporting, identity, and DSS.	You
MongoDB	Document storage for most services.	You
Kafka	Event stream between services.	You
Redis	Cache, shared by the services and the API gateway.	You

OpenLM Platform never stores data inside its own pods. Everything that must survive a restart lives in your SQL Server, MongoDB, Kafka, and Redis, so you can reinstall or upgrade OpenLM Platform without losing data.

You can use managed cloud services, for example Amazon RDS, Azure SQL, or Amazon MSK, or run these four services yourself, inside or outside the cluster. OpenLM Platform needs only their addresses and credentials.

How a request travels

Every request enters through one web address and the ingress controller:

 Browser
   │  https://openlm.example.com/…
   ▼
 Load balancer / ingress controller      ← TLS certificate for openlm.example.com
   │
   ├── /identity …        → identity service        (sign-in)
   ├── /api/…             → API gateway → services   (data)
   └── /<page>/ …         → web UI for that page     (screens)
                               │
                               ▼
                 SQL Server · MongoDB · Kafka · Redis

Two rules follow from this path:

• One web address for everything: Every screen, the sign-in page, and every API call use the same host name. You need one DNS name and one certificate for it.
• Services also call that web address: Several services check sign-in tokens by calling https://<your address>/identity themselves, from inside the cluster. The address must therefore also work from inside the cluster, with a certificate the pods trust. Networking and TLS certificates explain how to set that up.

What runs where in Kubernetes

The installation uses these namespaces:

Namespace	What's in it
openlm	Every OpenLM service and UI, the API gateway, and the secrets you create.
your choice	Your ingress controller, and optionally your own MongoDB, Kafka, and Redis.

Use the namespace openlm

Install OpenLM Platform into a namespace called openlm. The chart is built for that name. Other names need extra configuration, so start with openlm unless OpenLM has agreed on another name with you.

Components

Each service or UI in the chart is a component with its own switch, for example:

homepage:
  enabled: true

Every component is off by default. Your values file switches on the components you install, and the values file step lists them.

What the platform needs from the cluster

OpenLM Platform needs the following from your cluster:

• Room to run about 100 small pods. See Requirements for sizes.
• An ingress controller (or OpenShift Routes) to bring HTTPS traffic in.
• A storage class for a few small volumes, which certain data-processing components use as working space.
• Pull access to the OpenLM image registry, public.ecr.aws/r3q3q2f4, or a mirror of it.

The chart installs no CRDs and no operators. Everything it creates lives in the openlm namespace, with one exception: the optional admissionwebhook component registers a cluster-wide admission webhook, and installing it needs cluster-admin rights. The standard component set in this guide leaves it off.