# Temporal Worker Deployment Guide This guide provides instructions for deploying the temporal worker to production using the Argo workflows and Helm charts created for the alga-psa project. ## Prerequisites Before deploying the temporal worker, ensure the following prerequisites are met: 1. **Vault Setup** - INTERNAL_API_SHARED_SECRET is stored in Vault at `secret/data/alga-psa/temporal-worker` - ALGA_AUTH_KEY is stored in Vault at `secret/data/alga-psa/shared` - Vault policy `temporal-worker` is created with read access to these paths - Service account is configured with appropriate Vault role 2. **Harbor Registry** - Harbor credentials are configured in the cluster - Access to push/pull from `harbor.nineminds.com/nineminds/temporal-worker` 3. **Database Access** - PostgreSQL cluster is accessible from the msp namespace - Database credentials are stored in the appropriate secrets 4. **Temporal Server** - Temporal server is running and accessible at `temporal-frontend.temporal.svc.cluster.local:7233` ## Building the Temporal Worker ### Manual Build To manually trigger a build of the temporal worker: ```bash # Submit the build workflow kubectl create -n argo -f - < -n msp` - Verify secrets are mounted: `kubectl exec -n msp -- ls /vault/secrets/` 2. **Database connection errors** - Verify database is accessible: `kubectl exec -n msp -- nc -zv 5432` - Check database credentials in secrets 3. **Temporal connection errors** - Verify Temporal server is running: `kubectl get pods -n temporal` - Check network connectivity to Temporal 4. **Health check failures** - Check worker logs for startup errors - Verify port 8080 is accessible within the pod ### Rollback Procedure If deployment fails, the workflow automatically rolls back. To manually rollback: ```bash # List Helm releases helm history alga-psa -n msp # Rollback to previous version helm rollback alga-psa -n msp ``` ## Monitoring ### Logs Temporal worker logs are collected by the cluster logging solution. Key log patterns to monitor: - `"level":"error"` - Error conditions - `"workflow":"started"` - Workflow executions - `"activity":"completed"` - Activity completions - `"health":"check"` - Health check status ### Metrics The temporal worker exposes metrics that can be scraped by Prometheus: - Worker task queue depth - Workflow execution duration - Activity execution duration - Error rates ### Alerts Recommended alerts: 1. **Worker Pod Down**: Less than minimum replicas running 2. **High Error Rate**: More than 5% of workflows failing 3. **Task Queue Backup**: More than 100 pending tasks 4. **Memory Pressure**: Worker using >80% of memory limit ## Security Considerations 1. **Secret Rotation** - INTERNAL_API_SHARED_SECRET should be rotated quarterly - Update in Vault and restart workers 2. **Network Policies** - Worker should only connect to: - PostgreSQL database - Temporal server - Redis (if caching enabled) - External APIs (Resend, NM Store) 3. **RBAC** - Service account has minimal permissions - No cluster-wide access required ## Maintenance ### Updating the Worker To update the temporal worker code: 1. Make changes in `ee/temporal-workflows/` 2. Commit and push to repository 3. Run the build workflow with new commit SHA 4. Deploy using the deployment workflow ### Database Migrations Database migrations are handled by the main alga-psa migration workflow. The temporal worker uses the same database schema. ### Performance Tuning Adjust these values based on workload: ```yaml temporalWorker: temporal: maxConcurrentActivityExecutions: 20 # Increase for more parallelism maxConcurrentWorkflowTaskExecutions: 20 resources: requests: cpu: 1000m # Increase for CPU-intensive workflows memory: 2Gi # Increase for memory-intensive workflows ```