DOCSEARCHbyAlgolia
Submit Docs

Camunda 8 Documentation

website·Indexed 35 days ago

https://docs.camunda.io

Technical documentation for Camunda 8, covering Orchestration REST and gRPC TLS mode configuration, CA and server certificate setup, and performance tuning for flush intervals, queue sizes, and exporter batching.

Tokens
47.5K
Snippets
211
Records
347
Agent score
22%

What's inside Camunda

  1. Overview of Camunda 8 Run for local development

    Camunda 8 Run is a lightweight, self-managed local distribution of Camunda 8 designed for prototyping and development. It bundles the Orchestration Cluster, Connectors, and H2 (as the default secondary storage). It is not intended for production use; for production, the Orchestration Cluster should be installed manually as a Java application.

  2. Orchestration Cluster components and communication

    The Orchestration Cluster single JAR includes Zeebe, Operate, Tasklist, and Admin. It handles:

    • gRPC communication: Used by client workers and for inter-broker communication between Zeebe brokers.
    • HTTP endpoints: Used by the REST API and Web UI.

    Both gRPC and HTTP endpoints should ideally be routed through a load balancer for availability and security. Connectors also expose HTTP(s) endpoints for webhooks, which can share the same HTTP load balancer.

  3. Understand the Orchestration Cluster components

    The Orchestration Cluster is the core of Camunda 8 and bundles several key components into a single artifact for seamless communication and state management. It includes:

    • Zeebe: The cloud-native workflow engine.
    • Operate: Monitoring and troubleshooting tool.
    • Tasklist: UI for managing user tasks.
    • Admin: Integrated authentication and authorization service for the cluster's components and APIs.

    Additionally, Optimize (BI tool) and Connectors (external system integration) are tightly integrated with the Orchestration Cluster.

  4. Choose a Camunda 8 Reference Architecture

    Select a deployment architecture based on organizational goals and infrastructure requirements:

    • Kubernetes: Best for teams experienced with containerization and microservices; provides dynamic scaling and high resilience via orchestration.
    • Containers (Docker): A middle ground providing isolation and consistency across environments without the full overhead of Kubernetes.
    • Manual (Bare Metal/VMs): Best for traditional infrastructure, IaaS, or environments requiring highly customized security and strict data residency.
    • Local Development: Use Camunda 8 Run for local evaluation and development.

  5. Understand Camunda 8 Orchestration Cluster secondary storage requirements

    The Orchestration Cluster (Zeebe, Operate, Tasklist, and Admin) uses a secondary storage backend to persist state.

    • RDBMS: Used as the primary secondary storage for the Orchestration Cluster. A single external managed RDBMS instance is used; Camunda does not manage database HA (this is handled by the database provider).
    • Elasticsearch/OpenSearch: Required only if Optimize is enabled. If Optimize is used, it must be deployed alongside the RDBMS. If Optimize is not used, an RDBMS-only stack is fully supported.

    Critical Constraints:

    • No Migration: Migration between Elasticsearch/OpenSearch and RDBMS is not supported. The backend must be chosen before production.
    • Uniformity: All brokers in the Orchestration Cluster must export to the same secondary storage backend.
    • API Version: Only the v2 Orchestration Cluster REST API is supported when using RDBMS.

  6. Understand Physical Tenants in Camunda 8.10

    Camunda 8.10 introduces Physical Tenants, which are strongly isolated execution units within a single Orchestration Cluster. This is an opt-in feature and is backward compatible. For existing single-tenant 8.9 clusters, the root-level configuration automatically becomes the configuration for the default Physical Tenant. The default tenant cannot be renamed, disabled, or deleted. Existing REST, gRPC, and Web app requests without specific tenant headers continue to route to the default Physical Tenant without requiring client code changes.

  8. Create a Zeebe broker runtime backup

    Create a runtime backup of Zeebe's primary storage using either the REST API (requires BACKUP:CREATE permission) or the Management API.
    # Using REST API
curl -XPOST "$ORCHESTRATION_CLUSTER_API/backups/runtime" \
     -H "Content-Type: application/json" \
     -d "{\"backupId\": $BACKUP_ID}"

# Using Management API
curl -XPOST "$ORCHESTRATION_CLUSTER_MANAGEMENT_API/actuator/backupRuntime" \
     -H "Content-Type: application/json" \
     -d "{\"backupId\": $BACKUP_ID}"

  9. Restore Camunda Hub data backup

    To restore a Camunda Hub database dump, the Hub must be stopped first. Restoration is performed using the psql command-line tool. Note that users' IDs in the OIDC provider (e.g., Keycloak) must not change between the backup and restore, otherwise users may lose access to their projects.
    psql -U <DATABASE_USER> -h <DATABASE_HOST> -p <DATABASE_PORT> -f dump.psql <DATABASE_NAME>

  10. Prepare for Camunda 8.10 upgrade

    Before upgrading to Camunda 8.10, perform the following preparation steps:

    • Verify Version: Ensure you are on version 8.9.x. It is strongly recommended to upgrade to the latest available 8.9.x patch first for maximum fix coverage.
    • Check Environment: Verify that the platform and dependencies are supported in 8.10.
    • Audit Customizations: Identify non-default values in Helm values, application YAML files, Ingress configurations, exporters, and secondary storage (Elasticsearch/OpenSearch or RDBMS).
    • Back up Database: Create a backup of Web Modeler/Camunda Hub data before upgrading, as data will be migrated to a new structure in 8.10.

  11. Validate Camunda 8 Helm upgrade rollout

    After performing a Helm upgrade, monitor the pod status to ensure they are healthy and verify that the correct image versions (e.g., 8.10.x) are deployed. Check for [camunda][warning] DEPRECATION messages in the Helm upgrade output to identify keys that need migration.
    # Watch rollout progress
kubectl -n <NAMESPACE> get pods -w

# Verify image versions
kubectl -n <NAMESPACE> get pods -o jsonpath="{range .items[*]}{.metadata.name}{':\t'}{range .spec.containers[*]}{.image}{'\n'}{end}{end}"

  12. Execute the Camunda Hub database migration sequence

    Follow these steps to migrate the Hub database from 8.9 to 8.10:

    1. Quiesce Workloads: Stop all writers and set the phase to quiesce to ensure zero replicas.
    2. Backup: Create a verified database backup.
    3. Migrate: Set the phase to migrate and disable the REST API liveness probe to prevent restarts during long migrations. Verify success via logs (look for DbMigrate - Successfully applied...).
    4. Restore Traffic: Set the phase to normal to restore full service.
    # 1. Quiesce
helm upgrade <RELEASE> camunda/camunda-platform --set camundaHub.upgrade.phase=quiesce --wait

# 2. Migrate
helm upgrade <RELEASE> camunda/camunda-platform \ 
  --set camundaHub.upgrade.phase=migrate \ 
  --set camundaHub.restapi.livenessProbe.enabled=false --wait

# 3. Restore Traffic
helm upgrade <RELEASE> camunda/camunda-platform --set camundaHub.upgrade.phase=normal --wait