Tutorials

Deploy on OpenShift Local

Deploy the complete SWIM ecosystem on your local machine using Red Hat OpenShift Local (formerly CodeReady Containers). This is a self-contained deployment project that includes all Helm charts, operator subscriptions, and infrastructure configuration needed to run the full SWIM Reference Architecture locally.

By the end of this tutorial you will have a fully functional SWIM environment with Digital NOTAM services, ED-254 Arrival Sequence services, validators, message brokers, databases, identity provider, and example applications.

What Gets Deployed

The deployment project installs 19 components organized in layers:

Shared Infrastructure (7) Kafka, Artemis brokers, MongoDB, PostgreSQL, MariaDB, Keycloak, cert-manager PKI

SWIM Services (4) DNOTAM Provider, DNOTAM Consumer, ED-254 Provider, ED-254 Consumer

Validators (4) Mock providers and consumers for isolated testing and conformance validation

Example Applications (4) DNOTAM Dashboard, DNOTAM Event Publisher, ED-254 Arrival Flow Manager, ED-254 AMAN Client

Prerequisites

Podman Desktop (recommended) graphical tool for managing containers, Kubernetes, and OpenShift environments. From podman-desktop.io

OpenShift Local 2.x from Red Hat Developers (download). Can also be installed via Podman Desktop

oc CLI + Make + Git oc is included with CRC. make and git are pre-installed on Linux/macOS. On Windows: choco install make git

Helm CLI Install from helm.sh/docs/intro/install or via package manager: choco install kubernetes-helm (Windows), brew install helm (macOS), sudo snap install helm --classic (Linux)

CPU: 6 minimum, 8 recommended. RAM: 16 GB minimum, 24 GB recommended for the full SWIM stack on CRC

Red Hat Developer Account free account from developers.redhat.com for CRC pull secret and registry.redhat.io container images

1. Clone the Deployment Project

git clone https://github.com/swim-developer/swim-deploy-openshift-local.git
cd swim-deploy-openshift-local

2. Start OpenShift Local

# Configure CRC resources (first time only)
# Minimum: 8 CPUs, 20 GB RAM. Recommended: 10 CPUs, 24 GB RAM
crc config set cpus 8
crc config set memory 24576
crc setup

# Start the cluster
crc start

# Configure CLI
eval $(crc oc-env)
oc login -u kubeadmin https://api.crc.testing:6443

# Configure CRC resources (first time only)
# Minimum: 8 CPUs, 20 GB RAM. Recommended: 10 CPUs, 24 GB RAM
crc config set cpus 8
crc config set memory 24576
crc setup

# Start the cluster
crc start

# Configure CLI
& crc oc-env | Invoke-Expression
oc login -u kubeadmin https://api.crc.testing:6443

The kubeadmin password is displayed by crc start or can be retrieved with crc console --credentials.

Windows: The commands below use GNU Make. Install it via choco install make (Chocolatey) or scoop install make.

3. Deploy Everything

A single command deploys the complete stack in the correct order: operators, infrastructure, services, validators, and example applications.

make all

This takes a few minutes on a fresh CRC instance. The Makefile handles namespace creation, operator installation, CRD readiness checks, Keycloak SPI setup, Helm chart deployment, and Artemis SSL configuration automatically.

4. Step-by-Step (Alternative)

If you prefer to deploy layer by layer, or need to troubleshoot a specific step, use oc and helm directly. All commands run from the swim-deploy-openshift-local project directory.

4.1 Create the Namespace

oc new-project swim-demo

4.2 Install OLM Operators

oc apply -f operators/cert-manager-operator.yaml
oc apply -f operators/amq-streams-operator.yaml
oc apply -f operators/amq-streams-console-operator.yaml
oc apply -f operators/amq-broker-operator.yaml
oc apply -f operators/rhbk-operator.yaml

Wait for all operator CRDs (2-5 minutes on a fresh CRC):

oc wait --for=condition=Established crd/kafkas.kafka.strimzi.io --timeout=300s
oc wait --for=condition=Established crd/clusterissuers.cert-manager.io --timeout=300s
oc wait --for=condition=Established crd/activemqartemises.broker.amq.io --timeout=300s
oc wait --for=condition=Established crd/keycloaks.k8s.keycloak.org --timeout=300s

4.3 Create Keycloak SPI Secret

oc create secret generic keycloak-swim-role-spi -n swim-demo \
  --from-file=keycloak-swim-role-spi.jar=lib/keycloak-swim-role-spi.jar

oc create secret generic keycloak-swim-role-spi -n swim-demo `
  --from-file=keycloak-swim-role-spi.jar=lib/keycloak-swim-role-spi.jar

4.4 Deploy Shared Infrastructure

helm upgrade --install swim-infra charts/swim-infra \
  -n swim-demo \
  -f charts/swim-infra/values.yaml

helm upgrade --install swim-infra charts/swim-infra `
  -n swim-demo `
  -f charts/swim-infra/values.yaml

Wait for all infrastructure pods. Kafka and Keycloak are the slowest to initialize:

oc get pods -n swim-demo -w

4.5 Create Artemis SSL Secrets

Once cert-manager has issued the Artemis TLS certificates, create the broker SSL secrets. This step extracts JKS keystores from cert-manager secrets and is best done with the Makefile target:

make infra-artemis-ssl

For the manual oc commands, see Step 6 in the deployment project README.

4.6 Deploy Digital NOTAM (DNOTAM)

Start with the DNOTAM module. Deploy the provider and consumer first, then their validators.

DNOTAM Services:

helm upgrade --install swim-dnotam-provider charts/swim-dnotam-provider \
  -n swim-demo \
  -f charts/swim-dnotam-provider/values.yaml

helm upgrade --install swim-dnotam-consumer charts/swim-dnotam-consumer \
  -n swim-demo \
  -f charts/swim-dnotam-consumer/values.yaml

helm upgrade --install swim-dnotam-provider charts/swim-dnotam-provider `
  -n swim-demo `
  -f charts/swim-dnotam-provider/values.yaml

helm upgrade --install swim-dnotam-consumer charts/swim-dnotam-consumer `
  -n swim-demo `
  -f charts/swim-dnotam-consumer/values.yaml

DNOTAM Validators:

helm upgrade --install swim-dnotam-consumer-validator charts/swim-dnotam-consumer-validator \
  -n swim-demo \
  -f charts/swim-dnotam-consumer-validator/values.yaml

helm upgrade --install swim-dnotam-provider-validator charts/swim-dnotam-provider-validator \
  -n swim-demo \
  -f charts/swim-dnotam-provider-validator/values.yaml

helm upgrade --install swim-dnotam-consumer-validator charts/swim-dnotam-consumer-validator `
  -n swim-demo `
  -f charts/swim-dnotam-consumer-validator/values.yaml

helm upgrade --install swim-dnotam-provider-validator charts/swim-dnotam-provider-validator `
  -n swim-demo `
  -f charts/swim-dnotam-provider-validator/values.yaml

Verify all four DNOTAM pods are running before proceeding:

oc get pods -n swim-demo -l app.kubernetes.io/part-of=swim-dnotam

4.7 Add More Modules (ED-254)

Each SWIM module follows the same pattern: two services (provider and consumer) and two validators. The only difference between modules is which charts to deploy.

Resource consideration

OpenShift Local runs on a single VM with limited CPU and memory. Running all modules simultaneously is possible with 8 CPUs and 24 GB RAM, but on constrained machines you may prefer to test one module at a time. Remove the current module before deploying the next one to stay within resource limits.

(Optional) Remove DNOTAM before deploying ED-254:

helm uninstall swim-dnotam-provider-validator -n swim-demo
helm uninstall swim-dnotam-consumer-validator -n swim-demo
helm uninstall swim-dnotam-consumer -n swim-demo
helm uninstall swim-dnotam-provider -n swim-demo

ED-254 Services:

helm upgrade --install swim-ed254-provider charts/swim-ed254-provider \
  -n swim-demo \
  -f charts/swim-ed254-provider/values.yaml

helm upgrade --install swim-ed254-consumer charts/swim-ed254-consumer \
  -n swim-demo \
  -f charts/swim-ed254-consumer/values.yaml

helm upgrade --install swim-ed254-provider charts/swim-ed254-provider `
  -n swim-demo `
  -f charts/swim-ed254-provider/values.yaml

helm upgrade --install swim-ed254-consumer charts/swim-ed254-consumer `
  -n swim-demo `
  -f charts/swim-ed254-consumer/values.yaml

ED-254 Validators:

helm upgrade --install swim-ed254-consumer-validator charts/swim-ed254-consumer-validator \
  -n swim-demo \
  -f charts/swim-ed254-consumer-validator/values.yaml

helm upgrade --install swim-ed254-provider-validator charts/swim-ed254-provider-validator \
  -n swim-demo \
  -f charts/swim-ed254-provider-validator/values.yaml

helm upgrade --install swim-ed254-consumer-validator charts/swim-ed254-consumer-validator `
  -n swim-demo `
  -f charts/swim-ed254-consumer-validator/values.yaml

helm upgrade --install swim-ed254-provider-validator charts/swim-ed254-provider-validator `
  -n swim-demo `
  -f charts/swim-ed254-provider-validator/values.yaml

Verify all four ED-254 pods are running:

oc get pods -n swim-demo -l app.kubernetes.io/part-of=swim-ed254

4.8 Deploy DNOTAM Example Applications (Optional)

Two demonstration applications complement the DNOTAM services and show how real-world clients integrate with the SWIM platform from each end of the pipeline.

DNOTAM Operations Dashboard Simulates an ANSP or airport operations centre. Consumes all 6 categorized Kafka topics produced by swim-dnotam-consumer and presents events in a real-time map view, event timeline, critical alerts panel, and a CP1 compliance audit dashboard. Requires swim-dnotam-consumer running and publishing to Kafka.

DNOTAM Event Publisher Simulates an AISP or EAD operator workstation generating and publishing Digital NOTAM events. Browse pre-built AIXM 5.1.1 templates by scenario category (runway closures, airspace activations, obstacles, surface conditions), preview the raw XML, and inject the event into swim-dnotam-provider via HTTP trigger or directly to the Kafka ingress topic. Requires swim-dnotam-provider running. The companion injection tool for the dashboard: publish here, watch the event appear there.

Build the container images (run from the workspace root, one machine needed). Source: github.com/swim-developer/swim-example-apps.

cd example-apps/dnotam-operations-dashboard
make jvm-backend     # backend only
make jvm-frontend    # frontend only
# or: make jvm — builds both at once

cd ../dnotam-event-publisher
make jvm-backend
make jvm-frontend

cd ../..

Each make jvm target builds multi-arch images for linux/amd64 and linux/arm64 and pushes them to quay.io/masales. Run make help inside each directory for all available options.

Deploy the DNOTAM applications:

helm upgrade --install dnotam-dashboard charts/dnotam-dashboard \
  -n swim-demo \
  -f charts/dnotam-dashboard/values.yaml

helm upgrade --install dnotam-event-publisher charts/dnotam-event-publisher \
  -n swim-demo \
  -f charts/dnotam-event-publisher/values.yaml

helm upgrade --install dnotam-dashboard charts/dnotam-dashboard `
  -n swim-demo `
  -f charts/dnotam-dashboard/values.yaml

helm upgrade --install dnotam-event-publisher charts/dnotam-event-publisher `
  -n swim-demo `
  -f charts/dnotam-event-publisher/values.yaml

Verify both pods are running:

oc get pods -n swim-demo -l app.kubernetes.io/part-of=swim-dnotam-apps

To confirm the end-to-end loop works, open the publisher at https://dnotam-event-publisher.apps-crc.testing, publish a RWY.CLS event using HTTP Trigger, then open the dashboard at https://dnotam-dashboard.apps-crc.testing and verify the event appears in the Critical Alerts panel.

ED-254 example applications follow the same pattern. Deploy them after the DNOTAM apps or after switching to the ED-254 module:

helm upgrade --install ed254-arrival-flow-manager charts/ed254-arrival-flow-manager \
  -n swim-demo \
  -f charts/ed254-arrival-flow-manager/values.yaml

helm upgrade --install ed254-aman-client charts/ed254-aman-client \
  -n swim-demo \
  -f charts/ed254-aman-client/values.yaml

helm upgrade --install ed254-arrival-flow-manager charts/ed254-arrival-flow-manager `
  -n swim-demo `
  -f charts/ed254-arrival-flow-manager/values.yaml

helm upgrade --install ed254-aman-client charts/ed254-aman-client `
  -n swim-demo `
  -f charts/ed254-aman-client/values.yaml

5. Verify the Deployment

helm list -n swim-demo
oc get pods -n swim-demo
oc get routes -n swim-demo

Key endpoints on CRC:

Keycloak https://rhbk.apps-crc.testing (username admin, password password)

DNOTAM Provider (mTLS) https://swim-dnotam-provider-mtls.apps-crc.testing

ED-254 Provider (mTLS) https://swim-ed254-provider-mtls.apps-crc.testing

DNOTAM Provider Validator https://dnotam-provider-validator-swim-demo.apps-crc.testing

DNOTAM Dashboard https://dnotam-dashboard.apps-crc.testing

DNOTAM Event Publisher https://dnotam-event-publisher.apps-crc.testing

ED-254 Arrival Flow Manager https://ed254-arrival-flow-manager.apps-crc.testing

ED-254 AMAN Client https://ed254-aman-client.apps-crc.testing

6. Troubleshooting

ED-254 services fail to start after fresh infra deploy

If you see ED-254 pods failing with database connection errors, confirm the ed254 module is active in charts/swim-infra/values.yaml:

modules:
  - dnotam
  - ed254   # must be present (not commented)

After enabling the module and redeploying infra, restart any ED-254 service pods that started before the databases were ready:

oc rollout restart deploy/swim-ed254-provider -n swim-demo
oc rollout restart deploy/swim-ed254-consumer -n swim-demo

swim-ed254-provider-validator stuck in ImagePullBackOff

The swim-ed254-provider-validator image may not be available on the public registry. Build it locally and push directly to the OpenShift internal registry using the oc new-build --binary workflow:

# 1. Install shared modules in local Maven repo (run once)
cd applications/swim-validators
./mvnw clean install -DskipTests

# 2. Build the JAR
cd swim-ed254-provider-validator
./mvnw clean package -DskipTests

# 3. Prepare build context
mkdir -p /tmp/ed254-pv-build/target/quarkus-app
cp src/main/docker/Containerfile.jvm /tmp/ed254-pv-build/Dockerfile
cp -r target/quarkus-app/. /tmp/ed254-pv-build/target/quarkus-app/

# 4. Create BuildConfig and build inside OpenShift
oc new-build --binary --name=swim-ed254-provider-validator \
  --strategy=docker --to=swim-demo/swim-ed254-provider-validator:latest \
  -n swim-demo
oc start-build swim-ed254-provider-validator \
  --from-dir=/tmp/ed254-pv-build --follow -n swim-demo

# 5. Update values.yaml to use the internal registry
# In charts/swim-ed254-provider-validator/values.yaml, set:
# image.repository: image-registry.openshift-image-registry.svc:5000/swim-demo/swim-ed254-provider-validator

# 6. Helm upgrade
helm upgrade swim-ed254-provider-validator charts/swim-ed254-provider-validator \
  -f charts/swim-ed254-provider-validator/values.yaml \
  -n swim-demo

# 1. Install shared modules in local Maven repo (run once)
cd applications\swim-validators
.\mvnw.cmd clean install -DskipTests

# 2. Build the JAR
cd swim-ed254-provider-validator
.\mvnw.cmd clean package -DskipTests

# 3. Prepare build context
New-Item -ItemType Directory -Force -Path "$env:TEMP\ed254-pv-build\target\quarkus-app"
Copy-Item src\main\docker\Containerfile.jvm "$env:TEMP\ed254-pv-build\Dockerfile"
Copy-Item -Recurse target\quarkus-app\* "$env:TEMP\ed254-pv-build\target\quarkus-app\"

# 4. Create BuildConfig and build inside OpenShift
oc new-build --binary --name=swim-ed254-provider-validator `
  --strategy=docker --to=swim-demo/swim-ed254-provider-validator:latest `
  -n swim-demo
oc start-build swim-ed254-provider-validator `
  --from-dir="$env:TEMP\ed254-pv-build" --follow -n swim-demo

# 5. Update values.yaml to use the internal registry
# In charts/swim-ed254-provider-validator/values.yaml, set:
# image.repository: image-registry.openshift-image-registry.svc:5000/swim-demo/swim-ed254-provider-validator

# 6. Helm upgrade
helm upgrade swim-ed254-provider-validator charts/swim-ed254-provider-validator `
  -f charts/swim-ed254-provider-validator/values.yaml `
  -n swim-demo

swim-ed254-provider-validator crashes with UnknownHostException for MariaDB

The swim-infra chart was missing the MariaDB instance for swim-ed254-provider-validator. Add the following entry to charts/swim-infra/values.yaml under mariadb.instances:

    - name: swim-ed254-provider-validator-mariadb
      databaseName: swim_client
      module: ed254

Then redeploy infra and restart the validator:

helm upgrade swim-infra charts/swim-infra \
  -f charts/swim-infra/values.yaml \
  -n swim-demo
oc rollout restart deployment/swim-ed254-provider-validator -n swim-demo

helm upgrade swim-infra charts/swim-infra `
  -f charts/swim-infra/values.yaml `
  -n swim-demo
oc rollout restart deployment/swim-ed254-provider-validator -n swim-demo

OTEL connection refused warnings in consumer logs

The DNOTAM and ED-254 consumers log warnings like Connection refused: localhost/127.0.0.1:4317 because OpenTelemetry is enabled by default but no Jaeger collector is deployed in the CRC environment. These warnings are harmless — all business functionality (AMQP subscription, event processing, Kafka routing) works normally. No action required.

Artemis SSL secrets already exist

If make infra-artemis-ssl fails with "already exists", the secrets are still valid from a previous deployment. No action required.

7. Teardown

Remove components with Helm in reverse deployment order:

# Example applications
helm uninstall ed254-aman-client -n swim-demo
helm uninstall ed254-arrival-flow-manager -n swim-demo
helm uninstall dnotam-dashboard -n swim-demo
helm uninstall dnotam-event-publisher -n swim-demo

# Validators
helm uninstall swim-ed254-provider-validator -n swim-demo
helm uninstall swim-ed254-consumer-validator -n swim-demo
helm uninstall swim-dnotam-provider-validator -n swim-demo
helm uninstall swim-dnotam-consumer-validator -n swim-demo

# SWIM services
helm uninstall swim-ed254-consumer -n swim-demo
helm uninstall swim-ed254-provider -n swim-demo
helm uninstall swim-dnotam-consumer -n swim-demo
helm uninstall swim-dnotam-provider -n swim-demo

# Shared infrastructure
helm uninstall swim-infra -n swim-demo

Alternatively, make destroy removes all components including operator subscriptions in the correct reverse order. For the complete Makefile reference, project structure, and Artemis SSL manual commands, see the deployment project README.