Environment Configuration Guide

Purpose: Explain the difference between Azure Resource Groups and Azure Developer CLI (azd) environments

Azure Developer CLI (azd) vs manual Azure resource management

Why azd env instead of creating resource groups manually?

Azure Developer CLI (azd) is a higher-level tool that manages the entire deployment lifecycle for you. Here's the key difference:

Traditional approach (manual):

# 1. Create resource group manually
az group create --name myResourceGroup --location eastus2

# 2. Create individual resources manually
az containerapp env create --name myContainerEnv --resource-group myResourceGroup
az cosmosdb create --name myCosmosDb --resource-group myResourceGroup
az acr create --name myRegistry --resource-group myResourceGroup
az staticwebapp create --name myStaticApp --resource-group myResourceGroup
# ... many more manual steps

Problems with manual approach:

• ❌ Time-consuming: Many individual commands
• ❌ Error-prone: Easy to miss configurations
• ❌ Inconsistent: Different deployments may vary
• ❌ Hard to cleanup: Must delete each resource individually
• ❌ No infrastructure as code: Hard to reproduce

Azure Developer CLI approach (automated):

# 1. Create azd environment (this is a configuration, not an Azure resource)
azd env new dev

# 2. Deploy everything automatically
azd up
# This automatically creates:
# - Resource group
# - Container Apps Environment
# - Container Registry
# - Cosmos DB
# - Static Web App
# - Application Insights
# - All networking and security configurations

Benefits of azd approach:

• ✅ One command deployment: azd up does everything
• ✅ Consistent infrastructure: Same setup every time
• ✅ Infrastructure as Code: Uses Bicep templates under the hood
• ✅ Easy cleanup: azd down removes all resources
• ✅ Multiple environments: Easy dev/staging/prod management
• ✅ Proper networking: Resources configured to communicate securely

What is an azd env?

An azd environment is NOT an Azure resource. It's a local configuration that tells azd:

• Which Azure subscription to use
• Which Azure region to deploy to
• What to name your resources (it generates names like rg-mind-or-machine-dev)
• Environment variables for your application
• Deployment settings and parameters

Think of it as a deployment profile or configuration set.

Local storage location

azd environments are stored locally in:

~/.azd/environments/
├── dev/
│   ├── .env
│   ├── config.json
│   └── .azure/
└── prod/
    ├── .env
    ├── config.json
    └── .azure/

What happens when we run azd env new dev?

azd env new dev

This creates a local folder (not Azure resources) with:

• Environment configuration
• Deployment parameters
• Variable settings

Interactive prompts:

1. Azure subscription (we'll select "Pay-As-You-Go")
2. Azure region (e.g., "East US 2")
3. Environment name (dev)

Example output:

? Select an Azure Subscription to use:  [Use arrows to move, type to filter]
> Pay-As-You-Go (c2bdf438-bbc9-4701-8eb2-58d605c16cd2)
  Azure subscription 1 (175ea360-764d-448f-b029-077752a6378f)

? Select an Azure location to use:  [Use arrows to move, type to filter]
  (Africa) South Africa North (southafricanorth)
  (Asia Pacific) Australia East (australiaeast)
  (Asia Pacific) Central India (centralindia)
> (US) East US 2 (eastus2)
  (US) West US 2 (westus2)

What happens when we run azd up?

azd up

This is when actual Azure resources get created:

Resources created automatically:

1. Resource Group: rg-mind-or-machine-dev

   • Container for all resources
   • Named automatically based on project + environment

2. Container Apps Environment: cae-mind-or-machine-dev

   • Hosts your .NET Aspire API containers
   • Includes networking and scaling configuration

3. Azure Container Registry: acrmindormachinedev

   • Stores your container images
   • Configured with managed identity access

4. Cosmos DB Account: cosmos-mind-or-machine-dev

   • NoSQL database for your game data
   • Configured with proper security settings

5. Static Web App: swa-mind-or-machine-dev

   • Hosts your Vite React frontend
   • Integrated with Container Apps for API calls

6. Application Insights: ai-mind-or-machine-dev

   • Monitoring and telemetry
   • Connected to all services

7. Managed Identities:

   • For secure service-to-service communication
   • No passwords or connection strings needed

8. Networking Configuration:

   • Internal service discovery
   • Proper CORS settings
   • HTTPS endpoints

Environment management commands

Basic commands:

# Create new environment
azd env new <environment-name>

# List all environments
azd env list

# Switch between environments
azd env select <environment-name>

# Show current environment details
azd env get-values

# Set environment variables
azd env set <KEY> <VALUE>

Environment examples:

Development environment

azd env new dev
azd env set ASPNETCORE_ENVIRONMENT Development
azd env set GAME_MAX_PLAYERS 10
azd env set LOG_LEVEL Debug

Production environment

azd env new prod
azd env set ASPNETCORE_ENVIRONMENT Production
azd env set GAME_MAX_PLAYERS 100
azd env set JWT_ACCESS_TOKEN_EXPIRY_MINUTES 60
azd env set LOG_LEVEL Information

Resource naming convention

azd automatically generates resource names using this pattern:

Resource Type	Naming Pattern	Example
Resource Group	rg-{project-name}-{env}	rg-mind-or-machine-dev
Container Apps Environment	cae-{project-name}-{env}	cae-mind-or-machine-dev
Container Registry	acr{project-name}{env}	acrmindormachinedev
Cosmos DB	cosmos-{project-name}-{env}	cosmos-mind-or-machine-dev
Static Web App	swa-{project-name}-{env}	swa-mind-or-machine-dev
Application Insights	ai-{project-name}-{env}	ai-mind-or-machine-dev

Why this approach is better for MindOrMachine

For multiplayer game development:

✅ Rapid Iteration: Quick deployments for testing multiplayer features ✅ Multiple Environments: Separate dev/staging/prod for different testing phases ✅ Consistent Cosmos DB: Same database setup across environments ✅ SignalR Ready: Container Apps properly configured for WebSocket connections ✅ Easy Cleanup: Perfect for demo environments that need to be torn down

For Azure learning:

✅ Infrastructure as Code: Learn proper cloud architecture patterns ✅ Best Practices: azd follows Azure Well-Architected Framework ✅ Security by Default: Managed identities, HTTPS, proper networking ✅ Cost Management: Easy to tear down entire environments

Next steps

After understanding environments, the deployment process becomes:

1. Create Environment: azd env new dev (configuration only)
2. Deploy Everything: azd up (creates all Azure resources)
3. Make Changes: Edit code locally
4. Update Deployment: azd deploy (updates only the application)
5. Clean Up: azd down (removes all resources)

This approach gives you Infrastructure as Code without writing any infrastructure code yourself!

---

Key Takeaway: azd env creates local configuration profiles, while azd up creates the actual Azure resources. This separation allows for consistent, repeatable deployments across multiple environments.