Container Deployment Guide

Welcome to the CLI App Platform deployment documentation. This guide covers the complete process of deploying and managing containerized applications using our platform.

Guide Overview

This documentation is organized into the following sections:

Getting Started - Prerequisites and accessing the deployment wizard
Deployment Steps - Complete 7-step deployment process
Container Management - Post-deployment management and monitoring
Best Practices - Production-ready recommendations
Troubleshooting - Common issues and solutions

Platform Features

The CLI App Platform provides a streamlined container deployment experience with comprehensive configuration options for:

Basic Configuration - Container identity and image settings
Resources - CPU and memory allocation with preset templates
Networking - Port configuration and exposure settings
Environment - Environment variables and application configuration
Storage - Persistent volumes, secrets, and configuration management
Advanced - Node tolerations and specialized scheduling
Review & Deploy - Final validation and deployment execution

Navigate to the sub-pages below for detailed step-by-step instructions.

Getting Started

Step 1: Basic Configuration

Step 7: Review & Deploy

Container Management

Troubleshooting

Best Practices

Getting Started

Overview

The CLI App Platform provides a streamlined container deployment experience with comprehensive configuration options for production-ready applications.

Prerequisites

Before deploying your container, ensure you have:

Access to the CLI App Platform dashboard
A container image available in a registry (Docker Hub, private registry, etc.)
Basic understanding of your application's resource requirements
Knowledge of required ports and environment variables

Accessing the Deployment Wizard

Navigate to your CLI App Dashboard
From the Deployments section, click the Deploy button
The 7-step deployment wizard will open

Platform Capabilities

The platform supports:

Container Sources

Docker Hub public images
Private container registries
Custom images with authentication
Pre-configured application templates

Resource Management

Intelligent resource allocation presets
Custom CPU and memory configurations
Real-time cluster capacity monitoring
Automatic resource optimization recommendations

Networking Features

Quick port selection for common services
Custom port configuration
Load balancer integration
Service discovery and DNS

Storage Options

Persistent volume claims
Temporary storage volumes
Secret management for sensitive data
ConfigMap support for configuration files

Advanced Features

Node scheduling and tolerations
Health checks and probes
Security contexts and policies
Horizontal pod autoscaling

Next Steps

Once you've confirmed your prerequisites, proceed to the deployment wizard where you'll configure your container through 7 comprehensive steps.

Continue to Step 1: Basic Configuration to begin the deployment process.

Step 1: Basic Configuration

The first step establishes your container's fundamental identity and image source.

Container Identity

Container Name: Enter a unique identifier for your container

Use lowercase letters, numbers, and hyphens only
Example: my-awesome-app
This name will be used to identify your container in the dashboard

Container Image

Choose how to specify your container image:

Option 1: Custom Image

Enter the full image reference manually:

Format: registry/image:tag
Examples:
- nginx:1.21
- node:18-alpine
- myregistry.com/myapp:latest

Option 2: Choose from Presets

Select from commonly used base images and configurations optimized for different use cases.

Advanced Configuration

The Advanced Configuration section (collapsed by default) provides additional container settings that can be configured later in the wizard.

Best Practices

Container Naming

Use descriptive names that identify the application purpose
Include environment indicators if deploying multiple versions (e.g., myapp-staging)
Avoid special characters and spaces
Keep names concise but meaningful

Image Selection

Use specific version tags rather than latest for production deployments
Choose official images when available for better security and support
Consider image size for faster deployment times
Verify image compatibility with your target architecture

Security Considerations

Use images from trusted registries
Regularly update base images for security patches
Scan images for vulnerabilities before deployment
Consider using minimal base images (e.g., Alpine Linux)

Common Image Examples

Web Applications

Node.js: node:18-alpine, node:20-slim
Python: python:3.11-alpine, python:3.12-slim
Nginx: nginx:1.25-alpine, nginx:stable
Apache: httpd:2.4-alpine

Databases

PostgreSQL: postgres:15-alpine, postgres:16
MySQL: mysql:8.0, mysql:8.1
Redis: redis:7-alpine, redis:latest
MongoDB: mongo:7.0, mongo:latest

Development Tools

Ubuntu: ubuntu:22.04, ubuntu:latest
Alpine: alpine:3.18, alpine:latest
Busybox: busybox:1.36, busybox:latest

Next: Proceed to Step 2 to configure your container's resource allocation.

Step 2: Resources

Configure CPU and memory allocation for your container with intelligent presets and real-time usage monitoring.

Quick Presets

Choose a preset based on your workload type:

Development/Testing

CPU: 250m (0.25 cores)
Memory: 256Mi
Use Case: Minimal resources for testing and development
Cluster Usage: 12.5% CPU, 6.3% memory

Small Web App

CPU: 500m (0.5 cores)
Memory: 512Mi
Use Case: Light web applications and APIs
Best For: Simple websites, microservices

Medium Application

CPU: 1000m (1 core)
Memory: 1Gi
Use Case: Standard production workloads
Best For: Most web applications, API servers

High Performance

CPU: 2000m (2 cores)
Memory: 4Gi
Use Case: Resource-intensive applications
Best For: Data processing, heavy computation

Custom Configuration

CPU Configuration

CPU Limit: Set in millicores (500m = 0.5 CPU cores)
Usage Indicator: Shows percentage of cluster capacity
Recommendation: Start conservative and scale up based on monitoring

Memory Configuration

Memory Limit: Set in Mi (Mebibytes) or Gi (Gibibytes)
Conversion: 1Gi = 1024Mi
Usage Indicator: Shows percentage of cluster capacity
Recommendation: Allow 20-30% overhead for your application

Resource Summary

The Current Allocation section displays:

CPU Allocation: Your selected CPU limit
Memory Allocation: Your selected memory limit
Cluster Impact: Real-time view of resource consumption

Understanding Resource Units

CPU Units

Millicores (m): 1000m = 1 CPU core
Examples:
- 100m = 0.1 cores (10% of one core)
- 500m = 0.5 cores (50% of one core)
- 1500m = 1.5 cores (1.5 full cores)

Memory Units

Mebibytes (Mi): Binary measurement (1Mi = 1,048,576 bytes)
Gibibytes (Gi): 1Gi = 1024Mi
Examples:
- 128Mi = 134MB
- 512Mi = 537MB
- 1Gi = 1.07GB
- 4Gi = 4.29GB

Resource Planning Guidelines

Application Sizing

Static Websites: 100m CPU, 128-256Mi memory
API Services: 200-500m CPU, 256-512Mi memory
Web Applications: 500m-1 CPU, 512Mi-1Gi memory
Microservices: 100-300m CPU, 256-512Mi memory
Background Jobs: 200-500m CPU, 512Mi-2Gi memory
Databases: 1-2 CPU, 2-8Gi memory

Monitoring and Optimization

Use the "Low Usage" indicators to optimize resource allocation
Monitor actual usage after deployment through the metrics dashboard
Scale resources based on performance patterns
Consider peak vs average usage when setting limits

Best Practices

Resource Allocation

Start Conservative: Begin with lower allocations and scale up
Monitor Usage: Use platform metrics to optimize over time
Plan for Peaks: Consider traffic spikes and processing bursts
Cluster Capacity: Be mindful of total cluster resource availability

Performance Optimization

CPU-bound Applications: Prioritize CPU allocation
Memory-intensive Applications: Focus on memory limits
I/O-heavy Applications: Balance CPU and memory appropriately
Microservices: Use smaller, focused resource allocations

Cost Optimization

Right-sizing: Avoid over-provisioning resources
Utilization Monitoring: Regular review of actual vs allocated resources
Scaling Strategies: Consider horizontal vs vertical scaling
Development vs Production: Use different resource profiles per environment

Next: Proceed to Step 3 to configure network ports and access settings.

Step 3: Networking

Configure how your container exposes services and handles network traffic.

Quick Port Selection

Choose from commonly used ports for rapid setup:

Web Services

HTTP (80/TCP): Standard web traffic
HTTPS (443/TCP): Secure web traffic
Alt HTTP (8080/TCP): Alternative HTTP port

Development Frameworks

React/Node (3000/TCP): Development servers
Flask/API (5000/TCP): Python Flask applications
Django/API (8000/TCP): Django development server

Databases & Services

Admin/Mgmt (9000/TCP): Management interfaces
Redis (6379/TCP): Redis database
PostgreSQL (5432/TCP): PostgreSQL database
MySQL (3306/TCP): MySQL database

Custom Port Configuration

For applications requiring specific ports:

Add Custom Port: Click "Add custom ports for your specific requirements"
Port Number: Enter port (1-65535)
Protocol: Select TCP or UDP
Purpose: Document the port's function

Configured Ports

The Configured Ports section shows all ports that will be exposed:

Port mapping: Internal container port to external access
Protocol: TCP/UDP specification
Status: Configuration validation

Network Information & Security

Port Configuration Tips

Ports 1-1023: Reserved for system services
Ports 8000+: Recommended for custom applications
TCP: Use for reliable connections (HTTP, databases)
UDP: Use for fast, connectionless protocols

Security Considerations

Only expose ports that your application actively uses
Use HTTPS (443) for production web applications
Consider using non-standard ports for additional security

Common Port Configurations

Web Applications

HTTP: 80/TCP (public web traffic)
HTTPS: 443/TCP (secure web traffic)
Admin: 9000/TCP (management interface)

API Services

API: 8000/TCP (REST API endpoint)
Health: 8080/TCP (health check endpoint)
Metrics: 9090/TCP (monitoring metrics)

Database Services

PostgreSQL: 5432/TCP
Redis: 6379/TCP
MySQL: 3306/TCP
MongoDB: 27017/TCP

Development Services

React Dev: 3000/TCP
Node.js: 3000/TCP
Flask: 5000/TCP
Django: 8000/TCP
Rails: 3000/TCP

Protocol Selection

TCP (Transmission Control Protocol)

Use Cases:

Web servers (HTTP/HTTPS)
Database connections
API endpoints
File transfers
Any service requiring reliable data delivery

Characteristics:

Reliable, ordered data delivery
Connection-oriented
Error checking and recovery
Flow control

UDP (User Datagram Protocol)

Use Cases:

Real-time applications (gaming, video streaming)
DNS queries
DHCP
Simple network protocols
Applications prioritizing speed over reliability

Characteristics:

Fast, connectionless
No guaranteed delivery
No error recovery
Minimal overhead

Network Security Best Practices

Minimal Exposure

Principle of Least Privilege: Only expose necessary ports
Service Segmentation: Separate public and internal services
Port Documentation: Document the purpose of each exposed port

Production Considerations

TLS/SSL: Use encrypted connections for sensitive data
Load Balancing: Distribute traffic across multiple instances
Rate Limiting: Implement traffic controls to prevent abuse
Monitoring: Track network traffic and connection patterns

Development vs Production

Development: May expose debug ports and development servers
Staging: Mirror production configuration closely
Production: Minimal, security-focused port exposure

Troubleshooting Network Issues

Common Problems

Port Conflicts: Multiple services trying to use the same port
Firewall Rules: Network policies blocking traffic
Service Discovery: Containers unable to find each other
Load Balancer: Incorrect routing configuration

Diagnostic Steps

Verify port configuration matches application expectations
Check container logs for binding errors
Test connectivity from within the cluster
Validate external access through load balancers

Next: Proceed to Step 4 to configure environment variables and application settings.

Step 4: Environment

Set up environment variables and application configuration for your container.

Quick Templates

Pre-configured environment variable templates for common frameworks:

Node.js Applications

NODE_ENV: Environment mode (development/production)
PORT: Application port
NPMCONFIGPRODUCTION: Skip dev dependencies in production

Database Configuration

DATABASE_URL 🔒: Database connection string (encrypted)
REDIS_URL 🔒: Redis connection string (encrypted)
DB_HOST: Database hostname
DB_PORT: Database port
ENCRYPTION_KEY 🔒: Data encryption key (encrypted)

Application Settings

DEBUG: Enable debug mode
LOG_LEVEL: Logging verbosity level
MAX_CONNECTIONS: Maximum concurrent connections
TIMEOUT: Request timeout (milliseconds)

Custom Environment Variables

Add application-specific configuration:

Variable Name: Use UPPERCASE with underscores
Variable Value: Enter the configuration value
Security: Sensitive values are automatically detected and encrypted

Example:

API_KEY=your-secret-api-key
MAX_WORKERS=4
CACHE_TTL=3600
DATABASE_URL=postgresql://user:pass@host:5432/db

Bulk Import

For applications with many environment variables:

Click Show Bulk Import
Paste variables in KEY=value format
Variables are automatically parsed and added

Bulk Import Format:

API_KEY=abc123
DB_HOST=localhost
DB_PORT=5432
MAX_WORKERS=4
LOG_LEVEL=info

Common Environment Variable Patterns

Database Connections

DATABASE_URL=postgresql://user:password@host:port/database
DB_HOST=localhost
DB_PORT=5432
DB_NAME=myapp
DB_USER=appuser
DB_PASSWORD=securepassword

Redis Configuration

REDIS_URL=redis://localhost:6379/0
REDIS_HOST=localhost
REDIS_PORT=6379
REDIS_PASSWORD=redispassword

Application Settings

APP_ENV=production
APP_DEBUG=false
APP_URL=https://myapp.com
APP_NAME="My Application"
APP_VERSION=1.0.0

API Configuration

API_KEY=your-api-key
API_SECRET=your-api-secret
API_TIMEOUT=30000
API_RATE_LIMIT=1000

Security Settings

JWT_SECRET=your-jwt-secret
ENCRYPTION_KEY=your-encryption-key
SSL_ENABLED=true
CORS_ORIGIN=https://frontend.com

Framework-Specific Examples

Django Applications

DJANGO_SETTINGS_MODULE=myapp.settings.production
SECRET_KEY=django-secret-key
DEBUG=False
ALLOWED_HOSTS=myapp.com,www.myapp.com
DATABASE_URL=postgres://user:pass@host:5432/db

Flask Applications

FLASK_ENV=production
FLASK_APP=app.py
SECRET_KEY=flask-secret-key
DATABASE_URL=postgresql://user:pass@host:5432/db

Express.js Applications

NODE_ENV=production
PORT=3000
SESSION_SECRET=session-secret
DATABASE_URL=mongodb://user:pass@host:27017/db

Spring Boot Applications

SPRING_PROFILES_ACTIVE=production
SERVER_PORT=8080
SPRING_DATASOURCE_URL=jdbc:postgresql://host:5432/db
SPRING_DATASOURCE_USERNAME=user
SPRING_DATASOURCE_PASSWORD=password

Environment Variable Best Practices

Naming Conventions

Use UPPERCASE: Standard convention for environment variables
Use Underscores: Separate words with underscores (DATABASE_URL)
Avoid Spaces: No spaces or special characters in variable names
Descriptive Names: Use names that clearly indicate purpose

Security Guidelines

Sensitive Data: Store passwords, API keys, and secrets securely
No Hardcoding: Never hardcode secrets in container images
Encryption: Platform automatically encrypts sensitive values
Access Control: Limit who can view/modify sensitive variables

Configuration Management

Environment Separation: Use different values per environment (dev/staging/prod)
Validation: Validate required variables at application startup
Documentation: Document the purpose and format of each variable
Defaults: Provide sensible defaults where appropriate

Common Patterns

Database URLs: Use connection strings for database configuration
Feature Flags: Use boolean values for feature toggles
Resource Limits: Configure timeouts, limits, and thresholds
External Services: Store API endpoints and credentials

Security Considerations

Sensitive Data Handling

Platform automatically detects and encrypts sensitive values
Variables containing "password", "secret", "key", "token" are encrypted
Encrypted values are not visible in logs or exports
Use descriptive names that indicate the variable's purpose

Best Practices for Secrets

Rotation: Regularly rotate sensitive credentials
Minimal Scope: Use service-specific credentials with limited permissions
Monitoring: Monitor access to sensitive configuration
Backup: Ensure secure backup of critical configuration

Troubleshooting Environment Issues

Common Problems

Missing Variables: Application fails due to undefined required variables
Incorrect Format: Variables not in expected format (URLs, JSON, etc.)
Encoding Issues: Special characters in variable values
Case Sensitivity: Mismatched variable name casing

Debugging Steps

Check application logs for environment variable errors
Verify variable names match application expectations
Validate variable values and formats
Test with minimal configuration first
Use container console to inspect environment

Next: Proceed to Step 5 to configure persistent storage and data management.

Step 5: Storage

Configure persistent storage, secrets, and configuration data for your container.

Persistent Volume Claims (PVCs)

Create persistent storage that survives container restarts:

Automatic Volume Creation

When enabled, volumes are automatically created and mounted:

PVC Name: Descriptive identifier (e.g., data-storage)
Storage Size: Disk space allocation (e.g., 1GB)
Access Mode: ReadWriteOnce (RWO) for single-pod access
Storage Class: Performance tier (e.g., fast-ssd)

Volumes

Define storage volumes for your container:

Volume Configuration

Volume Name: Internal identifier (e.g., data-volume)
Volume Type: Empty Directory for temporary storage
Size Limit: Optional storage constraint

Volume Mounts

Connect volumes to container filesystem paths:

Volume Name: Reference to defined volume
Mount Path: Container filesystem location (e.g., /data or /config)
Read Only: Checkbox for write protection
Purpose: Mount volumes before creating mounts

Secrets

Store sensitive configuration data securely:

Secret Configuration

Secret Name: Identifier (e.g., db-credentials)
Secret Type: Opaque (Generic) for key-value pairs
Key: Configuration key (e.g., password, token)
Value: Sensitive data (automatically encrypted)

Example Secrets:

db-credentials:
  username: myapp
  password: [encrypted]
  
api-tokens:
  github_token: [encrypted]
  stripe_key: [encrypted]

ConfigMaps

Store non-sensitive configuration data:

ConfigMap Configuration

ConfigMap Name: Identifier (e.g., app-config)
Key: Configuration parameter (e.g., config.yaml, database_url)
Value: Configuration content or file data

Example ConfigMaps:

app-config:
  database_url: postgresql://localhost:5432/myapp
  redis_url: redis://localhost:6379/0
  
nginx-config:
  nginx.conf: |
    server {
      listen 80;
      server_name localhost;
      ...
    }

Storage Types and Use Cases

Persistent Volumes

When to Use:

Database data that must survive pod restarts
User-uploaded files and media
Application logs that need retention
Cache data that should persist

Configuration Examples:

# Database storage
name: postgres-data
size: 20Gi
mount: /var/lib/postgresql/data

# Application uploads
name: app-uploads
size: 50Gi
mount: /app/uploads

Temporary Volumes

When to Use:

Temporary processing files
Cache that can be rebuilt
Inter-container communication
Scratch space for computations

Configuration Examples:

# Temporary cache
name: cache-volume
type: EmptyDir
mount: /tmp/cache

# Processing workspace
name: workspace
type: EmptyDir
mount: /workspace

Secrets

When to Use:

Database passwords
API keys and tokens
TLS certificates
OAuth credentials

Configuration Examples:

# Database credentials
name: db-secret
keys:
  username: dbuser
  password: securepassword
  
# API keys
name: api-keys
keys:
  stripe_key: sk_live_...
  github_token: ghp_...

ConfigMaps

When to Use:

Application configuration files
Environment-specific settings
Non-sensitive configuration data
Feature flags and toggles

Configuration Examples:

# Application config
name: app-config
data:
  config.json: |
    {
      "debug": false,
      "timeout": 30000
    }
    
# Nginx configuration
name: nginx-config
data:
  nginx.conf: |
    server {
      listen 80;
      root /var/www/html;
    }

Storage Classes and Performance

Available Storage Classes

Standard: General-purpose SSD storage
Fast-SSD: High-performance SSD for databases
Bulk: Cost-effective for large data sets
NFS: Network file system for shared access

Performance Considerations

IOPS: Input/output operations per second
Throughput: Data transfer rates
Latency: Response time for storage operations
Durability: Data protection and backup capabilities

Common Storage Patterns

Database Applications

# PostgreSQL storage
name: postgres-data
size: 20Gi
storageClass: fast-ssd
mount: /var/lib/postgresql/data

# Database backups
name: postgres-backup
size: 50Gi
storageClass: standard
mount: /backups

Web Applications

# Static assets
name: static-files
size: 5Gi
storageClass: standard
mount: /app/static

# User uploads
name: user-uploads
size: 100Gi
storageClass: standard
mount: /app/uploads

Logging and Analytics

# Application logs
name: app-logs
size: 10Gi
storageClass: bulk
mount: /var/log/app

# Analytics data
name: analytics
size: 200Gi
storageClass: bulk
mount: /data/analytics

Storage Best Practices

Persistent Storage

Size Planning: Estimate growth and plan for 2-3x current needs
Backup Strategy: Implement regular backup procedures
Monitoring: Track storage usage and performance
Cleanup: Regular cleanup of temporary and log files

Secrets Management

Rotation: Regularly rotate sensitive credentials
Access Control: Limit access to secrets on a need-to-know basis
Auditing: Monitor access to sensitive configuration
Separation: Keep secrets separate from application code

Configuration Organization

Environment Separation: Use different ConfigMaps per environment
Versioning: Version your configuration for rollback capabilities
Validation: Validate configuration syntax and values
Documentation: Document configuration parameters and their purposes

Performance Optimization

Storage Class Selection: Choose appropriate performance tiers
Volume Sizing: Right-size volumes to avoid waste
Mount Optimization: Use read-only mounts where appropriate
Caching: Implement appropriate caching strategies

Troubleshooting Storage Issues

Common Problems

Volume Mount Failures: Incorrect paths or permissions
Storage Full: Volumes reaching capacity limits
Performance Issues: Slow I/O or high latency
Secret Access: Unable to read mounted secrets

Diagnostic Steps

Check container logs for mount errors
Verify volume and mount path configurations
Check storage capacity and usage
Validate secret and ConfigMap syntax
Test file system permissions

Security Considerations

Data Protection

Encryption at Rest: Use encrypted storage classes when available
Access Controls: Implement proper file system permissions
Network Security: Secure data in transit
Backup Encryption: Ensure backups are encrypted

Compliance

Data Residency: Understand where data is stored geographically
Retention Policies: Implement appropriate data retention
Audit Trails: Maintain logs of data access and modifications
Regulatory Requirements: Ensure compliance with applicable regulations

Next: Proceed to Step 6 to configure advanced scheduling and node placement options.

Step 6: Advanced

Configure advanced scheduling options and node placement tolerations for specialized deployment requirements.

Quick Toleration Presets

Pre-configured tolerations for common node scheduling scenarios:

Control Plane Access

Taint: control-plane
Effect: NoSchedule
Use Case: Allow scheduling on control plane nodes
When to Use: System services, monitoring tools

Master Node Access (Legacy)

Taint: master
Effect: NoSchedule
Use Case: Legacy master node scheduling
When to Use: Older Kubernetes clusters

GPU Node Access

Taint: gpu
Effect: NoSchedule
Use Case: Schedule on GPU-enabled nodes
When to Use: Machine learning, graphics processing

Spot Instance Access

Taint: arch
Effect: NoSchedule
Use Case: Schedule on spot/preemptible instances
When to Use: Cost-optimized, fault-tolerant workloads

High Memory Nodes

Taint: memory-pressure
Effect: NoSchedule
Use Case: Schedule on high-memory nodes
When to Use: Memory-intensive applications

Dedicated Workload

Taint: dedicated
Effect: NoSchedule
Use Case: Schedule on dedicated nodes
When to Use: Isolated, high-performance workloads

Custom Tolerations

Create specific tolerations for your deployment requirements:

Toleration Configuration

Taint Key: Node taint identifier (e.g., node-role.kubernetes.io/control-plane)
Taint Value: Optional taint value (e.g., true, dedicated)
Operator: Matching logic (Exists ignores value, Equal requires exact match)
Effect: Scheduling behavior (NoSchedule, NoExecute, PreferNoSchedule)

Understanding Tolerations

How Tolerations Work

Tolerations allow pods to be scheduled on nodes with matching taints
Exists operator ignores the value, Equal requires exact match
NoSchedule prevents new pods, NoExecute evicts existing pods
PreferNoSchedule tries to avoid but allows if necessary

Taint Effects Explained

NoSchedule

Prevents new pods from being scheduled on the node
Existing pods continue running
Most common effect for resource isolation

NoExecute

Prevents new pods AND evicts existing pods
Use for immediate node isolation
Can cause service disruption

PreferNoSchedule

Soft constraint - tries to avoid scheduling
Will schedule if no other options available
Good for preferences rather than requirements

Common Use Cases

GPU Workloads

# Allow scheduling on GPU nodes
taint_key: nvidia.com/gpu
operator: Exists
effect: NoSchedule

High Memory Applications

# Schedule on high-memory nodes
taint_key: node.kubernetes.io/memory-pressure
operator: Exists
effect: NoSchedule

Cost Optimization

# Use spot instances
taint_key: node.kubernetes.io/spot
value: "true"
operator: Equal
effect: NoSchedule

Dedicated Infrastructure

# Dedicated application nodes
taint_key: dedicated
value: myapp
operator: Equal
effect: NoSchedule

Node Selection Strategies

Resource-Based Selection

CPU-Intensive: Target high-CPU nodes
Memory-Intensive: Target high-memory nodes
Storage-Intensive: Target nodes with fast storage
Network-Intensive: Target nodes with high bandwidth

Infrastructure-Based Selection

Bare Metal: For performance-critical applications
Virtual Machines: For standard workloads
Spot Instances: For cost-sensitive, fault-tolerant workloads
Reserved Instances: For predictable, long-running workloads

Geographic Selection

Region-Specific: Comply with data residency requirements
Zone-Specific: Control availability zone placement
Edge Locations: Minimize latency for users

Toleration Best Practices

When to Use Tolerations

Your application requires specific hardware (GPU, high memory)
You need guaranteed node resources for critical workloads
Cost optimization with spot/preemptible instances
Compliance requirements for data isolation

Best Practices

Use Specific Tolerations: Only when necessary for your workload
Avoid Control Plane: Regular applications shouldn't use control plane tolerations
Consider Resource Requirements: Target nodes that match your resource needs
Test in Development: Validate tolerations work before production deployment

Performance Considerations

Specialized nodes may have different performance characteristics
Monitor resource usage on tainted nodes
Plan for node availability when using dedicated infrastructure
Consider failover strategies for specialized workloads

Troubleshooting Tolerations

Common Issues

Pod Stuck Pending: No nodes match toleration requirements
Unexpected Scheduling: Tolerations too broad or permissive
Resource Conflicts: Multiple applications competing for specialized nodes
Node Unavailability: Tainted nodes offline or at capacity

Diagnostic Steps

Check pod events for scheduling failures
Verify node taints match toleration configuration
Confirm target nodes have available resources
Review cluster autoscaling configuration
Validate toleration syntax and values

Next: Proceed to Step 7 for final validation and deployment.

Step 7: Review & Deploy

Final validation and deployment of your configured container.

Deployment Readiness

Before deployment, the platform validates your configuration:

Configuration Validation

The system checks for required settings and potential issues:

Common Validation Items:

✅ Container name is required: Ensure you've provided a valid container name
✅ Container image is required: Verify your image reference is complete
⚠️ Resource allocation: Check CPU and memory settings are appropriate
⚠️ Network configuration: Validate port configurations and conflicts
⚠️ Storage setup: Verify volume mounts and persistent storage

Configuration Summary

Review all your deployment settings:

Basic Container Settings

Container Name: Your application identifier
Container Image: Source image and tag
Resource Allocation: CPU and memory limits

CPU and Memory Allocation

CPU Allocation: Millicores allocated (e.g., 500m = 0.5 cores)
Memory Allocation: Memory limit (e.g., 512Mi)
Cluster Usage: Percentage of total cluster resources

Network Configuration

Configured Ports: All exposed ports and protocols
Access Methods: How your application will be accessible
Security Settings: Port exposure and protocol configuration

Application Configuration

Environment Variables: All configured environment settings
Secrets: Secure configuration (values hidden)
ConfigMaps: Non-sensitive configuration files

Storage & Configuration

Persistent Volume Claims: Long-term storage configuration
Volume Mounts: Filesystem mount points
Secrets: Secure data storage
ConfigMaps: Configuration file management
Tolerations: Node scheduling preferences

Pre-Deployment Checklist

Required Configuration

Container name is unique and descriptive
Container image is accessible and valid
Resource allocation matches application needs
Required ports are configured and documented
Environment variables are complete

Security Review

Sensitive data is stored in Secrets, not environment variables
Only necessary ports are exposed
Container runs with appropriate security context
Access controls are properly configured

Performance Validation

CPU and memory limits are appropriate for workload
Storage allocation meets application requirements
Network configuration supports expected traffic
Health checks are configured if needed

Operational Readiness

Monitoring and logging strategy is in place
Backup procedures are defined for persistent data
Rollback plan is available
Documentation is updated

Deployment Process

Once validation passes:

Deployment Steps

Final Review: Verify all settings match your requirements
Deploy: Click the deploy button to start the deployment process
Monitoring: Track deployment progress in real-time

Deployment Phases

Image Pull: Download container image to cluster nodes
Resource Allocation: Reserve CPU, memory, and storage
Volume Creation: Set up persistent volumes and mounts
Secret Injection: Mount secrets and ConfigMaps
Container Start: Launch container with configuration
Health Checks: Verify container health and readiness
Service Registration: Register with service discovery

Post-Deployment

After successful deployment:

Immediate Actions

Verify Status: Check container status shows "Running"
Test Connectivity: Validate network access and ports
Check Logs: Review startup logs for errors
Monitor Resources: Confirm resource usage is within limits

Dashboard Monitoring

Container Status: Running, pending, stopped, or failed states
Resource Usage: Real-time CPU and memory consumption
Network Activity: Port accessibility and traffic patterns
Logs: Application output and error messages

Management Operations

Scaling: Adjust CPU and memory allocations
Updates: Deploy new container versions
Configuration: Modify environment variables and settings
Troubleshooting: Access logs and diagnostic information

Validation Errors and Solutions

Common Validation Errors

Missing Required Fields

Error: "Container name is required"

Solution: Provide a unique, descriptive container name

Error: "Container image is required"

Solution: Specify a valid container image reference

Resource Conflicts

Error: "Insufficient cluster resources"

Solution: Reduce resource requests or wait for capacity

Error: "Port already in use"

Solution: Choose different ports or remove conflicting services

Configuration Issues

Error: "Invalid environment variable format"

Solution: Check variable names and values for syntax errors

Error: "Volume mount conflict"

Solution: Ensure mount paths don't overlap

Resolution Steps

Review Error Messages: Read validation feedback carefully
Check Dependencies: Verify external dependencies are available
Validate Configuration: Double-check all configuration values
Test Incrementally: Start with minimal configuration
Consult Documentation: Reference platform guides and examples

Rollback and Recovery

Rollback Scenarios

Deployment Failure: Automatic rollback to previous stable state
Configuration Error: Manual revert to known good configuration
Performance Issues: Scale back resources or revert changes
Security Concerns: Immediate isolation and configuration review

Recovery Procedures

Identify Issue: Determine root cause of failure
Stop Deployment: Halt problematic deployment if needed
Restore Configuration: Revert to last known good state
Validate Fix: Test resolution before re-deployment
Monitor Closely: Ensure stability after recovery

Best Practices for Deployment

Preparation

Start Small: Begin with minimal configuration and iterate
Test Thoroughly: Validate in development before production
Document Changes: Maintain clear deployment notes
Plan Rollback: Always have a rollback strategy

Deployment

Monitor Progress: Watch deployment status and logs
Validate Quickly: Test core functionality immediately
Check Dependencies: Ensure external services are accessible
Review Metrics: Confirm resource usage patterns

Post-Deployment

Continuous Monitoring: Set up alerts and dashboards
Performance Tuning: Optimize based on actual usage
Security Review: Regular security and compliance checks
Documentation Updates: Keep deployment docs current

Next: Your container is now deployed! Proceed to Container Management for ongoing operations and monitoring.

Container Management

Troubleshooting

Common issues and solutions for container deployment and management on the CLI App Platform.

Deployment Issues

Image Pull Errors

Symptoms: Container stuck in "Pending" or "ImagePullBackOff" state

Common Causes:

Incorrect image name or tag
Image doesn't exist in the specified registry
Private registry authentication issues
Network connectivity problems

Solutions:

Verify Image Name: Check image name and tag spelling
Test Image Access: Verify image exists and is accessible
Check Registry Credentials: Ensure authentication is properly configured
Network Connectivity: Verify cluster can reach the registry

Example Debug Commands:

# Test image pull locally
docker pull your-image:tag

# Check image exists
docker search your-image

Resource Constraint Errors

Symptoms: Pod stuck in "Pending" state with scheduling failures

Common Causes:

Insufficient CPU or memory in the cluster
Resource requests exceed node capacity
Node taints preventing scheduling
Storage provisioning failures

Solutions:

Check Cluster Capacity: Review available resources in dashboard
Reduce Resource Requests: Lower CPU/memory requirements
Review Node Taints: Ensure tolerations match node taints
Scale Cluster: Add more nodes if consistently resource-constrained

Diagnostic Steps:

Check pod events in the Overview section
Review cluster resource utilization
Verify node availability and capacity
Check for node taints and scheduling constraints

Configuration Errors

Symptoms: Container fails to start or crashes immediately

Common Causes:

Invalid environment variables
Missing required configuration
Incorrect volume mount paths
Application configuration errors

Solutions:

Review Container Logs: Check startup logs for error messages
Validate Configuration: Verify all environment variables and mounts
Test Locally: Test configuration with local container runtime
Minimal Configuration: Start with minimal config and add incrementally

Runtime Issues

Container Crashes and Restarts

Symptoms: High restart count, container status cycling

Common Causes:

Application bugs or exceptions
Memory limits exceeded (OOMKilled)
Health check failures
External dependency failures

Solutions:

Analyze Logs: Review container logs for error patterns
Check Resource Usage: Monitor CPU and memory consumption
Review Health Checks: Ensure health check endpoints are responsive
Test Dependencies: Verify external services are accessible

Memory Issues Specific:

Symptoms: OOMKilled events in container logs
Solutions: Increase memory limits or optimize application memory usage

Performance Issues

Symptoms: Slow response times, high resource utilization

Common Causes:

Insufficient resource allocation
Inefficient application code
Database or external service bottlenecks
Network latency issues

Solutions:

Monitor Metrics: Use performance metrics to identify bottlenecks
Scale Resources: Increase CPU/memory allocation as needed
Profile Application: Use application profiling tools
Optimize Queries: Review and optimize database queries

Network Connectivity Issues

Symptoms: Unable to access application, connection timeouts

Common Causes:

Incorrect port configuration
Network policy restrictions
Load balancer configuration issues
DNS resolution problems

Solutions:

Verify Port Configuration: Check exposed ports match application
Test Internal Connectivity: Use console to test from within cluster
Check Network Policies: Review network security policies
Validate DNS: Ensure service discovery is working correctly

Storage Issues

Volume Mount Failures

Symptoms: Container fails to start with mount errors

Common Causes:

Invalid mount paths
Volume doesn't exist
Permission issues
Storage class problems

Solutions:

Check Mount Paths: Verify mount paths are valid and don't conflict
Verify Volumes: Ensure referenced volumes exist
Review Permissions: Check file system permissions
Storage Class: Verify storage class is available and accessible

Persistent Volume Issues

Symptoms: Data loss, volume not available

Common Causes:

Volume not properly configured as persistent
Storage backend failures
Incorrect volume size
Backup/restore issues

Solutions:

Verify PVC Configuration: Check persistent volume claim settings
Monitor Storage Usage: Check available storage space
Test Backup/Restore: Verify backup procedures work correctly
Check Storage Backend: Ensure storage infrastructure is healthy

Security Issues

Secret Access Problems

Symptoms: Application can't access required secrets

Common Causes:

Secret doesn't exist
Incorrect secret name or key
Permission issues
Secret not mounted correctly

Solutions:

Verify Secret Exists: Check secret is created and accessible
Check Mount Configuration: Verify secret mount configuration
Review Permissions: Ensure service account has access
Test Secret Access: Use console to verify secret is available

Permission Denied Errors

Symptoms: Application fails with permission errors

Common Causes:

Security context restrictions
File system permissions
Service account permissions
Network policy restrictions

Solutions:

Review Security Context: Check security context configuration
Check File Permissions: Verify file and directory permissions
Service Account: Ensure service account has required permissions
Network Policies: Review network access policies

Monitoring and Logging Issues

Missing Logs

Symptoms: No logs appearing in dashboard

Common Causes:

Application not writing to stdout/stderr
Log level configuration issues
Logging system problems
Container not running

Solutions:

Check Application Logging: Ensure app writes to stdout/stderr
Verify Log Levels: Check log level configuration
Container Status: Ensure container is running
Test Log Output: Use console to verify log generation

Metrics Not Available

Symptoms: Performance metrics not showing

Common Causes:

Metrics collection not enabled
Application not exposing metrics
Network connectivity issues
Monitoring system problems

Solutions:

Enable Metrics Collection: Ensure metrics are enabled
Check Metrics Endpoints: Verify application exposes metrics
Network Connectivity: Test connectivity to metrics endpoints
Refresh Dashboard: Use refresh button to update metrics

Platform-Specific Issues

Dashboard Access Problems

Symptoms: Cannot access container management interface

Common Causes:

Authentication issues
Browser compatibility
Network connectivity
Platform maintenance

Solutions:

Refresh Session: Log out and log back in
Clear Browser Cache: Clear browser cache and cookies
Try Different Browser: Test with different web browser
Check Platform Status: Verify platform is operational

Console Connection Issues

Symptoms: Cannot connect to container console

Common Causes:

Container not running
Shell not available in container
Network connectivity issues
Browser WebSocket support

Solutions:

Check Container Status: Ensure container is running
Verify Shell: Ensure bash/sh is available in container
Browser Compatibility: Check WebSocket support
Network Configuration: Review firewall and proxy settings

Diagnostic Tools and Commands

Container Inspection

# Check container processes
ps aux

# Check disk usage
df -h

# Check memory usage
free -h

# Check network configuration
ip addr show

# Test network connectivity
ping google.com
nslookup service-name

Application Debugging

# Check application configuration
env | grep APP_

# Test application endpoints
curl http://localhost:8080/health

# Check application logs
tail -f /var/log/app.log

# Check file permissions
ls -la /app/

Resource Monitoring

# Monitor CPU usage
top

# Monitor memory usage
watch -n 1 free -h

# Monitor disk I/O
iostat 1

# Monitor network traffic
netstat -i

When to Contact Support

Contact platform support when:

Platform Issues: Dashboard or platform functionality problems
Persistent Problems: Issues that persist despite troubleshooting
Security Concerns: Suspected security issues or breaches
Performance Degradation: Unexplained performance problems
Data Loss: Issues with data persistence or backups

Information to Provide

When contacting support, include:

Container Details: Name, ID, and deployment configuration
Error Messages: Exact error messages and logs
Timeline: When the issue started and any recent changes
Steps Taken: Troubleshooting steps already attempted
Environment: Details about your deployment environment

Emergency Procedures

For critical issues:

Immediate Response: Stop affected containers if necessary
Isolate Impact: Prevent issue from spreading
Document Everything: Capture logs and system state
Contact Support: Escalate to platform support immediately
Communication: Notify stakeholders of impact and status

Best Practices

Comprehensive guidelines for deploying and managing production-ready containers on the CLI App Platform.

Resource Management

Right-Sizing Resources

Monitor Usage: Regularly review actual vs. allocated resources
Scale Appropriately: Adjust limits based on actual application needs
Plan Capacity: Ensure cluster resources meet application demands
Cost Optimization: Avoid over-provisioning to reduce costs

Resource Allocation Strategies

Start Conservative: Begin with lower allocations and scale up
Peak Planning: Account for traffic spikes and processing bursts
Environment Differentiation: Use different profiles for dev/staging/prod
Horizontal vs Vertical: Consider scaling strategies for your workload

Performance Monitoring

Baseline Establishment: Measure normal operating parameters
Trend Analysis: Track resource usage patterns over time
Alert Configuration: Set up notifications for resource constraints
Regular Review: Schedule periodic resource optimization reviews

Security Practices

Container Security

Base Image Security: Use official, minimal, and regularly updated images
Vulnerability Scanning: Scan images for security vulnerabilities
Non-Root Users: Run containers with non-privileged users when possible
Read-Only Filesystems: Use read-only root filesystems where applicable

Secrets Management

Never Hardcode: Never embed secrets in container images
Use Platform Secrets: Store sensitive data in Kubernetes Secrets
Regular Rotation: Implement credential rotation policies
Least Privilege: Grant minimal required permissions

Network Security

Minimal Exposure: Only expose necessary ports and services
TLS/SSL: Use encrypted connections for all external traffic
Network Policies: Implement traffic segmentation and access controls
Regular Audits: Review and audit network configurations

Access Controls

RBAC Implementation: Use role-based access control
Service Accounts: Use dedicated service accounts for applications
Audit Logging: Enable and monitor access logs
Regular Reviews: Periodically review access permissions

Operational Excellence

Health Checks and Monitoring

Liveness Probes: Implement container health checks
Readiness Probes: Configure readiness indicators
Startup Probes: Handle slow-starting applications
Custom Metrics: Expose application-specific metrics

Logging Strategy

Structured Logging: Use consistent, parseable log formats
Log Levels: Implement appropriate log level filtering
Centralized Logging: Aggregate logs for analysis
Log Retention: Define appropriate log retention policies

Backup and Recovery

Data Backup: Implement regular backup procedures for persistent data
Configuration Backup: Version and backup deployment configurations
Disaster Recovery: Plan for complete environment recovery
Testing: Regularly test backup and recovery procedures

Deployment Strategies

Blue-Green Deployments: Use parallel environments for safe deployments
Rolling Updates: Implement gradual rollout strategies
Canary Releases: Test new versions with limited traffic
Rollback Plans: Always have a rollback strategy ready

Configuration Management

Environment Variables

Consistent Naming: Use standard naming conventions
Environment Separation: Different values per environment
Validation: Validate required variables at startup
Documentation: Document all configuration options

ConfigMaps and Secrets

Separation of Concerns: Keep sensitive and non-sensitive data separate
Versioning: Version your configuration for rollback capability
Validation: Validate configuration syntax and values
Organization: Group related configuration logically

Storage Configuration

Persistent Data: Use appropriate storage classes for different needs
Backup Strategy: Implement automated backup procedures
Monitoring: Track storage usage and performance
Cleanup: Regular cleanup of temporary and log files

Scalability and Performance

Horizontal Scaling

Stateless Design: Design applications to be stateless where possible
Load Distribution: Implement effective load balancing
Auto-scaling: Configure horizontal pod autoscaling
Resource Requests: Set appropriate resource requests for scaling decisions

Vertical Scaling

Resource Monitoring: Track CPU and memory usage patterns
Gradual Increases: Scale resources incrementally
Performance Testing: Test performance impact of resource changes
Cost Consideration: Balance performance with cost implications

Caching Strategies

Application Caching: Implement appropriate caching layers
Database Caching: Use database query caching
CDN Usage: Leverage content delivery networks for static assets
Cache Invalidation: Implement proper cache invalidation strategies

Development and Testing

Environment Parity

Consistent Environments: Maintain similarity across dev/staging/prod
Configuration Management: Use same configuration management across environments
Dependency Management: Lock dependency versions for consistency
Testing: Test in production-like environments