Skip to content
QuantCDN

Understanding and Configuring Container Settings

Each container defined within an environment represents a service in your application stack. Quant Cloud provides comprehensive configuration options for each container, allowing you to control everything from resource allocation to security settings. You can configure these settings through the environment’s “Edit Config” page by expanding a container’s accordion section, or through dedicated container editing interfaces.

Accessing Container Configuration

From Environment Edit Config Page: Navigate to your environment’s “Edit Config” page and expand the “Containers” accordion. Click on any container’s header to reveal its configuration fields.

From Container Management: Some interfaces provide direct access to container configuration through dedicated editing pages, which present the same configuration options in a focused view.

Core Container Settings

Basic Configuration

Container Name (name) A unique identifier for the container within the environment (e.g., web-server, api-service, redis-cache). This name is used for service discovery, logging, dependency definitions, and internal networking between containers.

  • Must be unique within the environment
  • Typically lowercase, alphanumeric characters, and hyphens only
  • Used in container-to-container communication and dependency chains

Image Source and Identifier Defines where your container image comes from and how to identify it:

  • Internal Images: For images stored in your organization’s private Quant Cloud Registry (ECR)

    • Select “Internal” as the image source type
    • Enter only the image tag in the identifier field (e.g., latest, v1.2.3, feature-branch)
    • The repository name is automatically inferred from your application context
    • Provides better security and faster pulls within the Quant Cloud infrastructure

  • External Images: For images from public registries (Docker Hub) or other private registries

    • Select “External” as the image source type
    • Enter the full image name including registry if not Docker Hub
    • Examples: nginx:latest, postgres:13-alpine, your-registry.example.com/path/to/image:tag

Network Configuration

Exposed Ports (exposedPorts) Defines which network ports your container makes available for communication. These are the ports inside the container that your application listens on.

  • Specify as numbers (e.g., 80, 443, 8000)
  • Can include protocol specification if needed (e.g., "8000/tcp")
  • The platform handles mapping these to external access points based on your environment configuration
  • Multiple ports can be exposed for containers serving different protocols or interfaces

Storage Integration

Mount Points (mountPoints) Connects Persistent Storage volumes to your container’s filesystem, enabling data persistence across deployments and container restarts.

Each mount point configuration includes:

  • Source Volume: Select from available Persistent Storage volumes defined in your environment
  • Container Path: The absolute path inside the container where the volume appears (e.g., /var/www/html, /data/db, /app/uploads)
  • Read-Only Access: Optional checkbox to mount the volume as read-only for security or data protection

Mount points are essential for:

  • Database data persistence
  • User-uploaded content storage
  • Configuration files that persist across deployments
  • Shared storage between multiple containers

Advanced Configuration Options

Most container forms include an “Advanced Options” section that can be expanded to reveal additional configuration capabilities.

Resource Management

CPU Allocation (cpu) Container-specific CPU units allocation. If left blank or set to 0, the container shares the overall task CPU allocation proportionally with other containers.

  • Specified in CPU units (platform-dependent, typically representing CPU core fractions)
  • Allows fine-tuned resource allocation for performance-critical containers
  • Consider your application’s CPU requirements and concurrent user load

Memory Configuration Two types of memory limits provide different levels of resource guarantees:

  • Memory Reservation (Soft Limit) (memoryReservation): Guaranteed memory allocation in MiB

    • The container is guaranteed this amount of memory
    • Can use more if available system resources permit
    • Useful for ensuring minimum performance levels

  • Memory Limit (Hard Limit) (memory): Maximum memory allocation in MiB

    • Absolute ceiling for memory usage
    • Container may be terminated if it exceeds this limit
    • Essential for preventing runaway processes from affecting other containers

Container Behavior

Essential Container (essential) Determines whether this container’s failure affects the entire environment instance:

  • Checked (Essential): If this container fails or stops, all other containers in the same task are stopped
  • Unchecked (Non-Essential): The task continues running even if this container stops
  • Typically enabled for primary application containers, disabled for auxiliary services

Read-Only Root Filesystem (readonlyRootFilesystem) Security enhancement that mounts the container’s root filesystem as read-only:

  • Prevents modification of system files and directories
  • Enhances security by limiting attack surface
  • Requires applications to write only to mounted volumes or designated writable areas
  • May require application architecture adjustments

Execution Context

User (user) Specifies the user context for running container processes:

  • Can be a username (e.g., appuser) or numeric UID (e.g., 1001)
  • Can include group specification (e.g., 1001:1001)
  • Important for security and file permission management
  • Should align with your image’s user configuration

Working Directory (workingDirectory) Sets the default directory for command execution within the container:

  • Absolute path (e.g., /app, /var/www/html)
  • Affects where relative paths resolve
  • Should match your application’s expected runtime directory

Environment Configuration

Environment Variables (environment) Key-value pairs that provide runtime configuration to your application:

  • Each entry has a name and value
  • Common examples: DATABASE_URL, API_KEY, DEBUG_MODE
  • Values are visible in container logs and process lists
  • Use for non-sensitive configuration data

Secrets Integration (secrets) Securely injects sensitive data from your environment’s Secret Store as environment variables:

  • Maps secret store keys to environment variable names within the container
  • Each entry specifies:
    • Name: Environment variable name inside the container
    • Value From: Key name in the environment’s secret store
  • Provides secure handling of passwords, API keys, and certificates
  • Values are encrypted at rest and in transit

Container Dependencies

Startup Dependencies (dependsOn) Controls the order in which containers start within your environment:

Each dependency specifies:

  • Container Name: Which container this one depends on
  • Condition: What state the dependency must reach
    • START: Dependency container has started
    • HEALTHY: Dependency container passes health checks
    • COMPLETE: Dependency container has completed execution
    • SUCCESS: Dependency container completed successfully

Useful for ensuring databases start before applications, or that initialization containers complete before main services begin.

Health Monitoring

Health Check Configuration (healthCheck) Defines how the platform determines if your container is operating correctly:

  • Command: Shell command to execute for health verification

    • Example: CMD-SHELL, curl -f http://localhost/health || exit 1
    • Zero exit code indicates healthy, non-zero indicates unhealthy

  • Interval: Time between health check executions (seconds)

  • Timeout: Maximum time to wait for health check completion (seconds)

  • Retries: Number of consecutive failures before marking container unhealthy

  • Start Period: Grace period after container start before health checks count toward retry limit (seconds)

Health checks enable:

  • Automatic container restart on failure
  • Load balancer traffic management
  • Monitoring and alerting integration

Command Overrides

Custom Command (command) Overrides the default CMD instruction from your Docker image:

  • Specify each argument on a separate line
  • Completely replaces the image’s default command
  • Example for a Python application: 
    python
    manage.py
    runserver
    0.0.0.0:8000

Custom Entrypoint (entryPoint) Overrides the default ENTRYPOINT instruction from your Docker image:

  • Specify each argument on a separate line
  • Changes how the container’s main process is executed
  • Use when you need different initialization or process management

Configuration Best Practices

Resource Planning: Start with conservative resource allocations and monitor actual usage to optimize costs and performance.

Security: Use read-only root filesystems and non-root users when possible. Store sensitive data in the Secret Store rather than environment variables.

Dependencies: Design dependency chains carefully to avoid circular dependencies and ensure proper startup order.

Health Checks: Implement meaningful health checks that verify your application’s actual functionality, not just process existence.

Twelve-Factor Methodology: Follow twelve-factor app principles by using environment variables for configuration and maintaining stateless containers with persistent data in mounted volumes.

Saving Configuration Changes

Configuration changes are applied differently depending on your access method:

  • From Environment Edit Config: Changes are part of the overall environment configuration. Use the main “Save Changes” button to apply all modifications.
  • From Dedicated Container Edit Page: Use the container-specific “Save Changes” button to apply changes immediately.

All configuration changes trigger environment redeployment to ensure consistency across your application stack.