need guide to install and setup REQUEST TRACKER 5 dockerized

Part 2

So it redesigned their architecture using Docker Compose + Kubernetes:

# docker-compose.yml (simplified)
version: '3.8'
services:
  rt-db:
    image: postgres:15
    volumes:
      - ./volumes/client1/db:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=rt_client1
    networks:
      - compliance-net

  rt-app:
    image: bestpractical/rt:5.0.2
    ports:
      - "8081:80"
    volumes:
      - ./volumes/client1/rt-config:/opt/rt5/etc
      - ./volumes/client1/logs:/opt/rt5/var/log
    depends_on:
      - rt-db
    networks:
      - compliance-net

  nginx:
    image: nginx:alpine
    ports:
      - "8081:80"
    volumes:
      - ./volumes/client1/nginx.conf:/etc/nginx/conf.d/default.conf
    networks:
      - compliance-net

 After implementation, they set up the following structure:

Each client is provided with a dedicated Git repository that includes their custom docker-compose.yml, RT plugins, and configuration files. The CI/CD pipeline, powered by GitHub Actions, builds a client-specific RT Docker image, which is tagged with a unique version (e.g., complianceguard/rt-client1:v2.1.3).

Deployments are managed via ArgoCD, which deploys to regional Kubernetes clusters across various cloud providers (such as AWS in EU-Central-1, GCP in Asia-Southeast1, etc.).

The solution is built as a multi-tenant SaaS compliance product, where each client operates their own isolated, auditable, and containerized instance of RT.

A fintech startup, developed an AI-powered regulatory compliance platform tailored for mid-sized banks and neobanks across the EU and APAC regions. Their core offering was designed to automatically detect suspicious transactions (such as potential money laundering), generate comprehensive audit trails, and trigger internal tickets for compliance teams to investigate.

To manage compliance investigations effectively, ComplianceGuard chose Request Tracker (RT) as their ticketing engine. RT was selected not only for its open-source flexibility and robust feature set but also for its support for custom fields, email integration, audit logging, and workflow automation. Initially, RT was deployed on bare-metal servers within the company’s own data center. However, as the platform scaled to support over 12 clients across five different countries, several operational challenges began to surface.

Due to strict data sovereignty regulations—for example, German clients requiring data to remain within Frankfurt—each client required a fully isolated RT instance. This added significant overhead to deployment and management. The complexity further escalated when installing and managing RT across diverse environments: Ubuntu 20.04, 22.04, CentOS, and even RHEL 8. The team encountered extensive dependency conflicts and package mismatches, leading to what was described internally as “dependency hell,” severely hampering scalability and maintainability.