Introduction
Rierino core platform installation has various mandatory and optional elements, which can be installed using IaC and CaC automation
Rierino is distributed and modular by design. You can deploy only what you need. You can also swap most dependencies with your preferred alternatives.
All building blocks are accessible. This includes Docker images, Maven packages, Helm charts, and playbooks. All IaC and CaC assets are editable, so you can own the full deployment.
This diagram shows how systems interact during initial setup and later changes.
Key terms (quick mental model)
IaC (Infrastructure as Code): Provisions infrastructure like clusters and networks.
CaC (Configuration as Code): Applies configuration and seed data to systems.
Initial deployment: Bootstraps the platform and its core services.
Later deployments: Add modules, upgrade services, or update configuration.
Why we separate IaC and CaC
IaC changes are slow and high risk. CaC changes are frequent and expected. Keeping them separate keeps upgrades safer.
What participates in a deployment
1) Initial Deployment Host
A bastion host or any machine with access to the deployment cloud. You use it to run kubectl, Helm, Terraform, and Ansible. You typically remove it after the initial deployment.
Treat this machine as “break-glass” tooling. Keep it minimal and short-lived.
2) GitHub Deployment Artifacts
These are the deployment repositories in the rierino-open and rierino GitHub orgs. They include configs, scripts, charts, and deployment assets. You can fork them for heavily customized setups.
Common customization patterns:
Pin to a release branch (e.g.
release-[RIERINO_VERSION]).Maintain a small overlay repo with your values and inventories.
Mirror images to a private registry when required by policy.
3) Rierino Platform Cluster
This is usually a Kubernetes cluster. It runs the Rierino runtime and deployment helpers.
It typically contains three logical layers:
Deployer
Jobs and services that run deployments from inside the cluster. It centralizes credentials and deployment assets. You use it during step-by-step installation and later changes.
Core Platform
The baseline Rierino services that you initialize first. It also enables self-service deployments through the admin UI.
Typical “core-first” charts:
Admin UI
Gateway
Authentication
Spring Runner
Optional charts, depending on your use case:
Session
Samza Runner
Socket Runner
Storefront
Business Apps
Domain modules you deploy after the core is running. Examples include commerce platform modules.
4) Enabling Systems
These are external systems the platform relies on. You can run them yourself or use managed cloud services.
Typical enabling systems:
Database (e.g. MongoDB) for persistence
Streaming (e.g. Kafka) for messaging and async workflows
Authentication provider (e.g. Keycloak) for user and client auth
Optional enabling systems depend on your architecture, such as:
Redis, Elasticsearch
Airflow, Presto, NiFi
HashiCorp Vault, etcd
Rierino usually deploys around these systems, not instead of them. Once enabling systems exist, Rierino playbooks can populate them with required data.
Most production issues come from network and identity misconfiguration. Confirm connectivity and credentials early.
How deployments usually flow
Provision enabling systems and a Kubernetes cluster.
Use the initial deployment host to bootstrap namespaces and core services.
Deploy the in-cluster deployer components.
Use the deployer for upgrades and module installs going forward.
This keeps credentials inside the cluster. It also makes later deployments repeatable.
Where to go next
Start with Prerequisites.
Then pick a path under Deployment Alternatives.
Most users continue with Kubernetes Deployment.
Following sections include details for initial deployment activities, as well as the GitHub repository contents with applicable parameters for customized deployments.
Last updated