Environments

An environment is an isolated instance of infrastructure created from a blueprint. Environments can exist within training sessions or as standalone resources.

Types of Environments

Session Environments

Created automatically for participants during training sessions:

# Session environments are created when a session starts
teactl session create 
  --name "kubernetes-workshop" 
  --blueprint k8s-basic 
  --start "2024-06-15 09:00" 
  --duration 4h

# Each participant gets an isolated environment
# kubernetes-workshop-alice-001
# kubernetes-workshop-bob-002
# kubernetes-workshop-charlie-003

Session environments:

• Are provisioned automatically when the session starts
• Are destroyed when the session ends
• Have configurable isolation (namespace, cluster, VM)
• Include activity tracking and checkpoints

Standalone Environments

Persistent environments outside of sessions for development, demos, or testing:

# Create a standalone environment
teactl env create 
  --name dev-sandbox 
  --blueprint k8s-basic 
  --org acme-training

# Standalone environments persist until explicitly destroyed
teactl env destroy dev-sandbox

Standalone environments:

• Persist until explicitly destroyed
• Are not tied to time limits
• Ideal for demos, development, or permanent labs
• Can be shared with team members

Environment Lifecycle

# View environment status
teactl env status dev-sandbox

# Watch for state changes
teactl env status dev-sandbox --watch

Environment Updates

When you need to modify a running environment, Teabar supports two update strategies.

Update Strategies

In-place Updates

Resources are modified directly in the existing environment:

# Update variable
teactl env update dev-sandbox --set replicas=5

# Update from modified blueprint
teactl env update dev-sandbox --blueprint updated-blueprint.yaml

Pros: Fast, no additional resources needed Cons: Brief disruption possible, harder to rollback

Blue-Green Updates

A new environment is created alongside the old one, then traffic is switched:

# Trigger blue-green update
teactl env update production --strategy blue-green

# The process:
# 1. New environment created (green)
# 2. Green validated and tested
# 3. Traffic switched to green
# 4. Old environment (blue) retained for rollback
# 5. Blue destroyed after confirmation

Pros: Zero-downtime, easy rollback Cons: Temporarily uses 2x resources

Configure Update Strategy

In your blueprint:

spec:
  environment:
    updateStrategy:
      type: in-place        # in-place | blue-green
      
      # For blue-green
      blueGreen:
        validateBefore: true
        retainOldFor: 1h    # Keep old env for rollback

Rollback

If an update fails or causes issues:

# Rollback to previous state
teactl env rollback dev-sandbox

# Rollback to specific checkpoint
teactl env rollback dev-sandbox --checkpoint cp-abc123

Environment Locking

Teabar uses pessimistic locking to prevent concurrent modifications:

# Manual lock (for maintenance)
teactl env lock dev-sandbox --reason "Performing maintenance"

# Unlock
teactl env unlock dev-sandbox

Creating Standalone Environments

# Basic creation
teactl env create --name my-lab --blueprint k8s-basic

# With custom variables
teactl env create 
  --name production-demo 
  --blueprint webapp-stack 
  --set replicas=3 
  --set domain=demo.example.com

# With tags for organization
teactl env create 
  --name dev-lab 
  --blueprint k8s-basic 
  --tag team=platform 
  --tag purpose=development

Participant Isolation

Within sessions, participants can be isolated at different levels:

┌─────────────────────────────────────────────────────────────────┐
│                    Namespace Isolation                           │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │              Shared Kubernetes Cluster                     │   │
│  │  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐     │   │
│  │  │ ns-alice│  │ ns-bob  │  │ns-charlie│ │ ns-dave │     │   │
│  │  └─────────┘  └─────────┘  └─────────┘  └─────────┘     │   │
│  └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│                     Cluster Isolation                            │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐             │
│  │  Cluster A  │  │  Cluster B  │  │  Cluster C  │   ...       │
│  │   (Alice)   │  │    (Bob)    │  │  (Charlie)  │             │
│  └─────────────┘  └─────────────┘  └─────────────┘             │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│                       VM Isolation                               │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐             │
│  │    VM A     │  │    VM B     │  │    VM C     │   ...       │
│  │   (Alice)   │  │    (Bob)    │  │  (Charlie)  │             │
│  └─────────────┘  └─────────────┘  └─────────────┘             │
└─────────────────────────────────────────────────────────────────┘

Accessing Environments

Web Terminal

Access environments directly in the browser:

# Get web terminal URL
teactl env access dev-sandbox --web

# Output:
# Web Terminal: https://teabar.dev/terminal/env-abc123

Kubeconfig (Kubernetes)

# Download kubeconfig
teactl env kubeconfig dev-sandbox > ~/.kube/config

# Or use inline
export KUBECONFIG=$(teactl env kubeconfig dev-sandbox)
kubectl get nodes

SSH Access

# Direct SSH (if configured in blueprint)
teactl env ssh dev-sandbox

# SSH to specific node
teactl env ssh dev-sandbox --node worker-1

Unique Access Links

Generate shareable links:

# Create access link (expires in 24h by default)
teactl env access-link dev-sandbox

# Create with custom expiration
teactl env access-link dev-sandbox --expires 7d

Environment Variables

Override blueprint defaults:

# Set at creation
teactl env create 
  --name production 
  --blueprint webapp 
  --set replicas=3 
  --set cpu_limit=2000m

# Update existing environment
teactl env update production --set replicas=5

# View current values
teactl env vars production

Checkpoints

Save and restore environment state:

# Create checkpoint
teactl env checkpoint create dev-sandbox --name "before-experiment"

# List checkpoints
teactl env checkpoint list dev-sandbox

# Restore to checkpoint
teactl env checkpoint restore dev-sandbox --name "before-experiment"

# Clone from checkpoint
teactl env checkpoint clone dev-sandbox 
  --checkpoint "before-experiment" 
  --name dev-sandbox-copy

Checkpoint Export

Export checkpoints for grading or sharing:

# Export checkpoint
teactl env checkpoint export dev-sandbox 
  --name "final-state" 
  --output checkpoint.tar.gz

# Share checkpoint across organization
teactl env checkpoint share dev-sandbox 
  --name "reference-setup" 
  --scope org

Activity Tracking

Monitor environment activity:

# View activity log
teactl env activity dev-sandbox

# Filter by type
teactl env activity dev-sandbox --type kubectl

# Real-time stream
teactl env activity dev-sandbox --follow

Tracked Activity Types

Cost Management

# View environment cost
teactl env cost dev-sandbox

# Output:
# Environment: dev-sandbox
# Running: 3d 4h
#
# Costs:
#   Compute: $12.40
#   Storage: $0.80
#   Network: $0.30
#   Total: $13.50

# Set cost alert
teactl env cost dev-sandbox --alert 50

Reducing Costs

# Stop environment (preserves data, stops compute)
teactl env stop dev-sandbox

# Resume when needed
teactl env start dev-sandbox

Environment Tags

Organize environments with tags:

# Add tags at creation
teactl env create 
  --name dev-lab 
  --blueprint k8s-basic 
  --tag team=platform 
  --tag env=development

# Add tags to existing
teactl env tag dev-lab --add project=demo

# List by tag
teactl env list --tag team=platform

# Remove tag
teactl env tag dev-lab --remove project

Resource Identifiers

Environments have both human-readable slugs and system UUIDs:

# View environment with both identifiers
teactl env info dev-sandbox

# Output:
# Name: dev-sandbox
# ID: env-7f3a2b1c-4d5e-6f7a-8b9c-0d1e2f3a4b5c
# ...

# Use either in commands
teactl env status dev-sandbox
teactl env status env-7f3a2b1c-4d5e-6f7a-8b9c-0d1e2f3a4b5c

Destroying Environments

# Destroy (with confirmation)
teactl env destroy dev-sandbox

# Force destroy
teactl env destroy dev-sandbox --force

# Destroy all environments with tag
teactl env destroy --tag cleanup=true --force

Best Practices

1. Use meaningful names: k8s-workshop-dev not env1
2. Tag consistently: Makes filtering and cost tracking easier
3. Stop when idle: Reduce costs for unused environments
4. Create checkpoints: Before experiments or breaking changes
5. Set cost alerts: Avoid surprise bills
6. Clean up: Destroy environments you no longer need

Next Steps

• Create your first environment
• Learn about sessions
• Understand blueprints
• CLI reference for environments