Skip to main content

Welance Non-Production

The welance-noprod tenant manages ArgoCD deployments for non-production Kubernetes clusters.

Overview

The welance-noprod tenant contains GitOps configurations for deploying applications to non-production Kubernetes clusters. It serves as the single source of truth for all non-production environment configurations, managed through ArgoCD.

Purpose

This tenant is used for:

  • Development environments: Testing and development workloads
  • Staging environments: Pre-production testing and validation
  • Management environments: Platform management and administrative tools
  • Other non-production workloads: Any non-production Kubernetes deployments

Repository Structure

The welance-noprod folder structure follows an environment-based organization:

welance-noprod/
├── management/ # Management/administrative environment
├── develop/ # Development environment
├── staging/ # Staging environment
└── [other-environments]/ # Additional non-production environments

Environments

Each subfolder within welance-noprod represents a distinct environment:

Management

The management environment contains:

  • Platform management tools
  • Administrative applications
  • Monitoring and observability tools
  • Infrastructure management components

Develop

The develop environment contains:

  • Development application deployments
  • Development database configurations
  • Development service configurations
  • Testing and development tools

Staging

The staging environment contains:

  • Staging application deployments
  • Pre-production testing configurations
  • Staging database configurations
  • Production-like environment setups

Additional Environments

Other environments may exist based on organizational needs, each following the same structure and GitOps principles.

ArgoCD Integration

The welance-noprod tenant is managed by ArgoCD, which:

  • Monitors Git Repository: ArgoCD watches the welance-noprod folder for changes
  • Syncs to Cluster: Automatically deploys changes to the non-production Kubernetes cluster
  • Manages Applications: Each environment contains ArgoCD Application definitions
  • Helm Values: Contains Helm values files for application configurations
  • Environment Variables: Contains environment-specific variable files

Typical Structure Per Environment

Each environment folder typically contains:

[environment]/
├── [project-id]-[environment]/
│ ├── values.yaml # Helm values for the application
│ ├── env.yaml # Environment variables
│ └── [other-configs]/ # Additional configuration files
└── [other-projects]/ # Other projects in this environment

Configuration Files

values.yaml

Helm values files contain:

  • Image tags and versions
  • Resource limits and requests
  • Ingress configurations
  • Storage configurations
  • Service configurations
  • Environment-specific overrides

env.yaml

Environment variable files contain:

  • Application environment variables
  • Database connection strings
  • API keys and secrets (references)
  • Feature flags
  • Configuration values

Deployment Workflow

  1. Pipeline Updates: CI/CD pipelines update values in welance-noprod repository
  2. Git Commit: Changes are committed to the repository
  3. ArgoCD Detection: ArgoCD detects changes in the Git repository
  4. Automatic Sync: ArgoCD syncs changes to the non-production Kubernetes cluster
  5. Application Update: Applications are updated with new configurations

Code Repository

The welance-noprod tenant source code is available on GitLab:

Repository: https://gitlab.com/welance/platform/tenants

The welance-noprod folder is located in the root of the tenants repository.

Access and Permissions

  • Read Access: Required for viewing configurations
  • Write Access: Typically restricted to CI/CD pipelines and administrators
  • ArgoCD Access: ArgoCD requires read access to sync configurations

Notes

  • All configurations are version-controlled in Git
  • Changes follow GitOps principles (Git as single source of truth)
  • ArgoCD handles the actual deployment to Kubernetes
  • Each environment is isolated within the same cluster or separate clusters
  • Environment-specific configurations override default Helm values