Deployment Guide

Deploying eXate on Kubernetes or OpenShift, in order: confirm you meet the prerequisites, get a cluster running, pull the Docker image and Helm chart, then configure and install.

1. Prerequisites

Before installing on your cloud or on-premises environment, make sure you meet the following:

1. Kubernetes or OpenShift Version: Kubernetes 1.16 or higher, or OpenShift.
2. Resource Requirements: at least 12 vCPU and 36GB RAM minimum.
3. Microsoft SQL Server: MSSQL 2017 or later. Encryption in transit is supported.
4. Elasticsearch (Optional): only needed if you want to aggregate and view audit logs.
5. SSL Certificates: the platform's UI and APIs are exposed over HTTPS via Ingress, so you'll need SSL/TLS certificates for the base domain used in global.fqdn.management and global.fqdn.execution.
6. CLI Tools: Helm (Kubernetes package manager) and kubectl.
7. Key Store: AWS Secrets/Key Management Service, Azure Key Vault, Hashicorp Vault, or Vault Kubernetes Operator, see Cloud Dependencies below for which applies to your environment.
8. Confidential Compute: recommended for APIgator and Discovery API pods.

Make sure all of the above are in place before continuing.

2. Get a Cluster Running

If you don't already have one:

• AWS: EKS Cluster Creation Tutorial
• Azure: AKS Cluster Creation Tutorial
• GCP: GKE Cluster Creation Tutorial

3. Pull the Docker Image

1. Authenticate with eXate's ACR: docker login oneharbor.azurecr.io
2. Pull the image: docker pull oneharbor.azurecr.io/exate-execution/exateapigator:<tag>
3. Authenticate with your internal registry: docker login <internal-registry-url>
4. Tag the pulled image: docker tag oneharbor.azurecr.io/exate-execution/exateapigator:<tag> <internal-registry-url>/<image-name>:<tag>
5. Push it to your internal registry: docker push <internal-registry-url>/<image-name>:<tag>

Example, using version 2.23.01:

docker login oneharbor.azurecr.io
docker pull oneharbor.azurecr.io/exate-execution/exateapigator:2.23.01
docker login myinternalregistry.example.com
docker tag oneharbor.azurecr.io/exate-execution/exateapigator:2.23.01 myinternalregistry.example.com/myapp:2.23.01
docker push myinternalregistry.example.com/myapp:2.23.01

Make sure both eXate's ACR and your internal registry are reachable from wherever you run these commands, and adjust the version tag as needed.

If your deployment also needs Redis or RabbitMQ built from source rather than pulled as managed services, see Build Redis using Dockerfile and Build RabbitMQ using Dockerfile.

4. Get the Helm Chart

Contact eXate to obtain the latest version of the Helm chart.

5. Understand the Chart Structure

Deployment is handled through Helm charts, one per microservice, each in its own directory under templates, plus a shared _helpers.tpl:

exate-helm-chart/
├── templates/
│   ├── apigator/
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   └── ...
│   ├── auditapi/
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   └── ...
│   ├── ...
│   └── _helpers.tpl
├── values.yaml
└── Chart.yaml

6. Configure Global Values

A deployment chooses which modules to install (apigator, Datagator, Datagator-dotnet) and a deployment model (all-in-one, execution, or management), the model determines which Kubernetes namespaces services deploy to, which is what makes running multiple execution instances straightforward. Each template checks global.components and global.deploymentType to decide whether it should deploy at all.

Components, which parts of eXate to deploy:

components:
  - apigator
  - Datagator
  - Datagator-dotnet

Deployment type, which microservices deploy for the chosen components:

deploymentType: management

FQDN, the base domain subdomains are built from:

fqdn:
  management: management.example.com
  execution: execution.example.com

External service communication, false uses internal Kubernetes service DNS; true uses service-specific subdomains on the FQDN:

routeServiceCommunicationExternally: true

Image configuration, the repository and pull secrets images are pulled from:

image:
  repository: oneharbor.azurecr.io/exate-management
  PullSecrets:
    - name: regcred

Database configuration, connection details shared across microservices:

database:
  host: example.db.host,1433
  username: exampleuser
  password: ExamplePassword123!
  shards_db_name: Shards.Example
  dataprotection_db_name: DataProtection.Example
  keys_db_name: Keys.Example
  identity_db_name: Identity.Example
  vault_db_name: Vault.Example
  portal_seed_password: ExamplePassword123!

Redis, RabbitMQ, and Elasticsearch, eXate provides these by default via the Helm chart, or point at your own external services:

redis:
  host: redis.example.com
  port: "6317"
  REDIS_SSL: "True"
  REDIS_ABORT_CONNECT: "False"
  REDIS_ALLOW_ADMIN: "True"
  REDIS_TIMEOUT: "30000"
  username: example
  password: ExamplePassword123!
rabbitmq:
  port: "5672"
  username: exampleuser
  password: ExamplePassword123!
elasticsearch:
  host: https://es.example.com
  port: "9200"
  index: "filebeat-7.14.0"
  username: "elastic"
  password: ExamplePassword123!

Security context, at the container or pod level:

# Kubernetes
podSecurityContext:
  runAsUser: 1000
securityContext:
  runAsUser: 1000

# OpenShift (disabled, since OpenShift randomly assigns pod UIDs)
podSecurityContext: []
securityContext: []

Environment:

environment: prod
APP_ENVIRONMENT: prod
ASPNETCORE_ENVIRONMENT: prod
on_premise: true

Ingress annotations, add any the Ingress resource needs:

ingress:
  annotations: {}
  # Add custom annotations if required

The settings above live in the chart's global section. To override any of them, database, image, environment, or ingress, for one specific microservice instead of globally, add a section under that microservice's own key, for example:

exateapigator:
  database:
    DB_DATAPROTECTION_DATA_SOURCE: ExampleValue
    DB_DATAPROTECTION_USER_ID: ExampleValue
    DB_DATAPROTECTION_INITIAL_CATALOG: ExampleValue
    DB_DATAPROTECTION_PASSWORD: ExampleValue
  image:
    name: exatedatasubjectapi
    pullPolicy: Always
    repository: examplerepo.com
    tag: 2.23.01
    imagePullSecrets:
      - name: regcred
  ingress:
    enabled: true
    className: ""
    annotations:
      kubernetes.io/ingress.class: nginx
    hosts:
      # Subdomain is prepended to global.fqdn as ingress.host
      - subdomain: apigator
        paths:
          - path: /
            pathType: ImplementationSpecific
    tls:
      - secretName: cert
        # Subdomains are prepended to global.fqdn as ingress.tls.hosts[x]
        subdomains:
          - apigator

7. Override Values Instead of Editing values.yaml Directly

Rather than editing values.yaml in place, create a custom-values.yaml containing only the values you want to override, anything not specified there is picked up from values.yaml automatically, which keeps the override file short and easier to maintain:

---
global:
  components:
    - apigator
  deploymentType: all-in-one
  fqdn:
    management: management.custom.com
    execution: execution.custom.com
  routeServiceCommunicationExternally: true
  image:
    PullSecrets:
      - name: regcred
  database:
    host: mssql.dbhost.com,1433
    username: customuser
    password: ExampleCustomPassword123!
    shards_db_name: Shards.Custom
    dataprotection_db_name: DataProtection.Custom
    keys_db_name: Keys.Custom
    identity_db_name: Identity.Custom
    vault_db_name: Vault.Custom
    portal_seed_password: ExampleCustomPassword123!

Keep the original values.yaml in place, don't delete it, custom-values.yaml is referenced alongside it at install time, not instead of it.

8. Install with Helm

Using the default values.yaml:

helm upgrade --install exate . --namespace=<namespace> --debug

Using your custom-values.yaml override file:

helm upgrade --install exate . -f custom-values.yaml --namespace=<namespace> --debug

Database jobs run first to set up the necessary schemas, once those complete successfully, the application installs.

Cloud Dependencies

The table below covers infrastructure eXate depends on but doesn't manage itself, what you're responsible for provisioning per environment:

	AWS	Azure	OpenShift	Mirantis	Kubernetes
SQL Server	Amazon RDS for SQL Server	Azure SQL Server	External SQL Server	External SQL Server	External SQL Server
Redis	AWS ElastiCache	Azure Cache for Redis	Redis Enterprise Operator	External Redis	External Redis
Secret Management	AWS Secrets Manager	Azure KeyVault	Vault Kubernetes Operator	External Hashicorp Vault	External Hashicorp Vault
Key Management	AWS Key Management Service	Azure KeyVault Managed HSM	Vault Kubernetes Operator	External Hashicorp Vault	External Hashicorp Vault
Spark	Amazon EMR	Azure Synapse Spark pools	Redhat ODH Operator	External Spark (e.g. Cloudera)	—
ElasticCache	Elasticsearch Service on AWS	Elastic Cloud on Microsoft Azure	Elastic Cloud on Kubernetes	Elastic Cloud on Kubernetes	Elastic Cloud on Kubernetes
IAM	KeyCloak	KeyCloak	RedHat SSO	KeyCloak	KeyCloak

What's next

Once installed, see Health and Info Endpoints to confirm it's running correctly, and Kubernetes/Helm Troubleshooting if anything doesn't come up as expected.