Run

​

Overview

• Automatic scaling based on load
• High availability with multiple replicas
• Environment isolation (dev, staging, test, UAT)
• API Management through Azure APIM
• Service mesh integration for secure communication

​

Environments

​

Environment access

team_members = {
  "[email protected]" = {
    grandcentral = {
      roles = [
        "dev-rw",      # Full access to dev runtime
        "stg-ro",      # Read-only access to staging
        "test-rw"      # Full access to test environment
      ]
    }
  }
}

• {env}-rw: Full access (read-write) to the environment
• {env}-ro: Read-only access to the environment
• {env}-apim-rw: API Management contributor access
• {env}-apim-ro: API Management reader access
• {env}-apim-subs-rw: Subscription management access
• {env}-apim-cred-manager: Credential manager access

​

Accessing Azure resources

​

Azure portal access

1. Navigate to Azure Portal
2. Sign in with your Azure AD credentials
3. Select your subscription/resource group
4. Access resources like:
   • Kubernetes clusters
   • API Management instances
   • Storage accounts
   • Key Vaults

​

Set up kubectl for Azure

# Install Azure CLI (if not installed)
# macOS: brew install azure-cli
# Windows: Download from https://aka.ms/installazurecliwindows
# Linux: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli

# Login to Azure
az login

# Get credentials for your cluster
az aks get-credentials --resource-group <resource-group> --name <cluster-name>

# Verify connection
kubectl get nodes

• Azure CLI Installation
• Azure AKS Documentation
• kubectl Installation

​

Deployment process

​

Applications-live repository

​

Access requirements

• GitHub team membership: applications-live team
• Runtime access: Appropriate Grand Central roles

​

Deployment workflow

​

Prepare your connector

• ✅ Built successfully
• ✅ Tested locally
• ✅ Merged to main branch
• ✅ Version tagged

​

Configure runtime settings

# Example connector configuration
connectors:
  my-custom-connector:
    image: <container-registry>/my-custom-connector:1.0.0
    replicas: 2
    environment: dev
    resources:
      requests:
        memory: "512Mi"
        cpu: "500m"
      limits:
        memory: "1Gi"
        cpu: "1000m"
    env:
      - name: EXTERNAL_API_URL
        value: "https://api.example.com"
      - name: LOG_LEVEL
        value: "INFO"

​

Create deployment pull request

1. Create a branch in applications-live repository
2. Add or update connector configuration
3. Follow PR title format: feat(GC-123): Deploy my-custom-connector to dev
4. Create Pull Request targeting main branch

​

Review and approve

• Default reviewers: All applications-live team members are automatically assigned
• Custom reviewers: Can be configured per runtime in self-service.tfvars
• Auto-approval: Available for specific runtimes (e.g., dev)

​

Deployment execution

1. Pipeline validates configuration
2. Connector is deployed to Kubernetes
3. Health checks verify successful deployment
4. Connector becomes available in the target environment

​

Runtime configuration

​

Environment variables

env:
  # API Configuration
  - name: API_BASE_URL
    value: "https://api.example.com"
  
  # Authentication
  - name: API_KEY
    valueFrom:
      secretKeyRef:
        name: connector-secrets
        key: api-key
  
  # Logging
  - name: LOG_LEVEL
    value: "INFO"
  
  # Performance
  - name: CONNECTION_POOL_SIZE
    value: "10"

​

Secrets management

• GitHub Secrets: Managed in self-service repository
• Kubernetes Secrets: Injected at runtime
• Azure Key Vault: For production secrets

​

Resource limits

resources:
  requests:
    memory: "512Mi"    # Minimum memory
    cpu: "500m"        # Minimum CPU
  limits:
    memory: "2Gi"      # Maximum memory
    cpu: "2000m"       # Maximum CPU

​

Container registry

• Customer ACR: GC_CUSTOMER_ACR_BASE_URL (available as GitHub secret)
• Enterprise ACR: GC_ENTERPRISE_ACR_BASE_URL (available as GitHub secret)

• Images are automatically built and pushed during CI/CD
• Use the image reference in your deployment configuration
• Format: <registry>/<image-name>:<tag>

• Access container registry through Azure Portal
• Use Azure CLI: az acr repository list --name <registry-name>
• Azure Container Registry Documentation

​

API management integration

​

APIM access

• {env}-apim-ro: Read API definitions and subscriptions
• {env}-apim-rw: Create and modify APIs
• {env}-apim-subs-rw: Manage subscriptions and keys
• {env}-apim-cred-manager: Manage OAuth credentials

​

Publish your API

1. Access APIM Portal for your environment
2. Create or import API definition
3. Configure backend to point to your connector
4. Set up policies (rate limiting, authentication, etc.)
5. Publish API for consumers

• Azure API Management Documentation
• APIM Policies Reference

​

Subscription management

• Create subscriptions for API consumers
• Manage keys (primary and secondary)
• Rotate keys for security
• Monitor usage through APIM analytics

​

Scaling and performance

​

Horizontal scaling

• CPU utilization
• Memory usage
• Request queue length
• Custom metrics

​

Manual scaling

replicas: 3  # Number of connector instances

​

Performance tuning

• Connection pooling: Configure pool sizes
• Threading: Adjust thread pool configurations
• Caching: Implement caching strategies
• Batch processing: Process messages in batches

​

Health checks and readiness

​

Health endpoints

• Liveness: /health/live - Is the connector running?
• Readiness: /health/ready - Is the connector ready to serve traffic?

​

Monitoring health

• Restart unhealthy pods
• Route traffic only to ready instances
• Prevent deployment of unhealthy versions

​

Rolling updates and rollbacks

​

Rolling updates

1. New pods are created with updated image
2. Traffic gradually shifts to new pods
3. Old pods terminate after traffic migration
4. Zero-downtime deployment achieved

​

Rollback process

1. Identify problematic version
2. Revert configuration in applications-live
3. Create PR to rollback
4. Merge PR to trigger rollback deployment

​

Environment-specific deployments

​

Development environment

• Purpose: Active development and testing
• Access: Developers with dev-rw role
• Deployment: Frequent, often auto-approved
• Configuration: Development API endpoints

​

Staging environment

• Purpose: Integration testing
• Access: QA teams with stg-rw role
• Deployment: Before production releases
• Configuration: Staging API endpoints

​

Test environment

• Purpose: System and performance testing
• Access: Test teams with test-rw role
• Deployment: For comprehensive testing
• Configuration: Test API endpoints

​

UAT environment

• Purpose: User acceptance testing
• Access: Business users with uat-rw role
• Deployment: Pre-production validation
• Configuration: Production-like settings

​

Troubleshooting

​

Deployment failures

• Check: Configuration syntax in applications-live
• Check: Image availability in container registry
• Check: Resource quotas and limits
• Check: Health check endpoints
• Resources: Kubernetes Troubleshooting

• Check: Application logs in DataDog or Grafana
• Check: Environment variables and secrets
• Check: External API connectivity
• Check: Resource limits (memory/CPU)

​

Runtime issues

• Check: External API response times
• Check: Resource constraints
• Check: Network connectivity
• Check: Connection pool settings

• Check: Resource limits and requests
• Check: Memory leaks in code
• Check: Thread pool configurations
• Check: Message queue backlogs

​

Access issues

• Check: Azure login: az login
• Check: Cluster credentials: az aks get-credentials
• Check: Role assignments in Azure Portal
• Check: kubectl configuration: kubectl config view

​

Best practices

1. Start with dev: Deploy to dev environment first
2. Test thoroughly: Validate in staging before production
3. Monitor deployments: Watch logs during and after deployment
4. Use health checks: Implement proper health endpoints
5. Configure resources: Set appropriate resource limits
6. Manage secrets: Never hardcode credentials
7. Version control: Tag and version all deployments
8. Documentation: Document deployment procedures

​

Accessing runtime resources

​

Kubernetes access

# Get connector pods
kubectl get pods -n <namespace>

# View connector logs
kubectl logs -f <pod-name> -n <namespace>

# Describe connector deployment
kubectl describe deployment <connector-name> -n <namespace>

# Get services
kubectl get svc -n <namespace>

# Get ingress
kubectl get ingress -n <namespace>

• kubectl Cheat Sheet
• Kubernetes Documentation

​

Service Bus explorer

• Requires appropriate Azure roles
• Connect via Service Bus Explorer or Azure Portal
• Monitor queues and topics
• Manage subscriptions

• Azure Service Bus Documentation
• Service Bus Explorer GitHub