Container Mental Model

In a Nutshell (🌰)

Containers in SSM represent isolated, portable application environments
SSM manages Docker containers across all your devices from a central interface
Container stacks (Docker Compose) allow multi-container application deployment
Container templates provide one-click deployment of common applications
SSM tracks container health, updates, and resource usage automatically

What is a Container in SSM?

In Squirrel Servers Manager, a container is a standardized, isolated package that includes an application and all its dependencies. SSM primarily works with Docker containers, providing a unified interface to manage containers across your entire infrastructure.

Figure 1: Container Services Management in SSM

Key Components of the Container Model

1. Container Instances

Individual containers running on your devices have several key attributes:

Image: The base container image (e.g., nginx:latest, postgres:14)
Name: A unique identifier for the container
Status: Current running state (running, stopped, restarting, etc.)
Ports: Network port mappings between host and container
Volumes: Persistent storage mappings
Environment Variables: Configuration settings
Labels: Metadata tags for organization and automation
Resource Limits: CPU, memory, and other resource constraints

🔍 Example

A web server container might use the nginx:latest image, expose port 80, mount a volume for website files, and have environment variables for configuration.

2. Container Stacks

Container stacks (based on Docker Compose) allow you to define and run multi-container applications:

Stack Definition: YAML configuration defining multiple containers
Services: Individual container definitions within a stack
Networks: Custom networks connecting containers
Dependencies: Relationships between containers (e.g., database → application → web server)
Volumes: Shared storage between containers

Figure 2: Container Stacks Management in SSM

3. Container Templates

SSM provides pre-configured templates for common applications:

Application Templates: Ready-to-deploy configurations for popular software
Custom Templates: User-created templates for frequently used configurations
Template Variables: Customizable parameters for flexible deployment

Figure 3: Container Templates Store in SSM

4. Container Registry Integration

SSM connects with container registries to access and manage images:

Public Registries: Docker Hub, GitHub Container Registry, etc.
Private Registries: Self-hosted or cloud-based private registries
Authentication: Secure access to protected registries
Image Pulling: Automatic or manual image retrieval

Figure 4: Container Registry Management in SSM

How the Container Model Works

Image Selection

Choose a container image from a registry or template that contains your desired application.

↓

Configuration

Configure container settings including ports, volumes, environment variables, and resource limits.

↓

Deployment

Deploy the container to one or more devices in your infrastructure.

↓

Monitoring

SSM automatically begins monitoring the container's health, resource usage, and status.

↓

Management

Perform ongoing management tasks like updates, backups, scaling, and configuration changes.

Container Lifecycle

Containers in SSM follow a defined lifecycle:

Creation: Container is defined but not yet deployed
Deployment: Container is deployed to a device
Running: Container is operational and executing its workload
Paused/Stopped: Container execution is temporarily halted
Updated: Container image or configuration is changed
Redeployed: Container is recreated with new settings
Removed: Container is deleted from the device

Real-World Examples

Scenario 1: Deploying a Web Application Stack

Problem:

You need to deploy a web application with a database backend and a reverse proxy.

Solution using the Container Model:

Create a container stack with three services:

yaml

# Example stack definition
version: '3'
services:
  db:
    image: postgres:14
    volumes:
      - db_data:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USER}
      POSTGRES_DB: ${DB_NAME}
    restart: unless-stopped
    
  app:
    image: myapp:latest
    depends_on:
      - db
    environment:
      DATABASE_URL: postgres://${DB_USER}:${DB_PASSWORD}@db:5432/${DB_NAME}
    restart: unless-stopped
    
  nginx:
    image: nginx:latest
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
    depends_on:
      - app
    restart: unless-stopped
    
volumes:
  db_data:

Deploy this stack to your target device, and SSM will:

Pull all required images
Create the defined volumes
Launch containers in the correct order
Configure networking between containers
Monitor the health and status of all containers

Scenario 2: Monitoring Stack with Resource Limits

Problem:

You need to deploy a monitoring solution with Prometheus and Grafana, but with strict resource limits to prevent overloading your server.

Solution using the Container Model:

Create a container stack with resource constraints:

yaml

# Example monitoring stack with resource limits
version: '3'
services:
  prometheus:
    image: prom/prometheus:v2.40.0
    volumes:
      - prometheus_data:/prometheus
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 500M
        reservations:
          cpus: '0.1'
          memory: 200M
    restart: unless-stopped
    
  grafana:
    image: grafana/grafana:9.3.0
    volumes:
      - grafana_data:/var/lib/grafana
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_PASSWORD}
      - GF_USERS_ALLOW_SIGN_UP=false
    depends_on:
      - prometheus
    deploy:
      resources:
        limits:
          cpus: '0.3'
          memory: 300M
        reservations:
          cpus: '0.1'
          memory: 100M
    restart: unless-stopped
    
volumes:
  prometheus_data:
  grafana_data:

Key features of this configuration:

CPU limits prevent containers from using more than their allocated CPU share
Memory limits protect the host from out-of-memory conditions
Resource reservations ensure minimum resources are always available
Persistent volumes ensure monitoring data survives container restarts
Environment variables configure Grafana security settings

Scenario 3: Microservices with Custom Networking

Problem:

You need to deploy a microservices application with isolated networks for frontend, backend, and database services.

Solution using the Container Model:

Create a container stack with custom networks:

yaml

# Example microservices stack with custom networking
version: '3'

services:
  frontend:
    image: my-frontend:1.0
    ports:
      - "80:80"
    networks:
      - frontend-network
    depends_on:
      - api
    restart: unless-stopped
    labels:
      com.example.description: "Frontend web interface"
      com.example.service: "frontend"
      
  api:
    image: my-backend-api:1.0
    networks:
      - frontend-network
      - backend-network
    environment:
      - DATABASE_URL=mongodb://db:27017/myapp
      - API_SECRET=${API_SECRET}
    restart: unless-stopped
    labels:
      com.example.description: "Backend API service"
      com.example.service: "api"
      
  worker:
    image: my-worker:1.0
    networks:
      - backend-network
    environment:
      - DATABASE_URL=mongodb://db:27017/myapp
      - REDIS_URL=redis://cache:6379
    restart: unless-stopped
    labels:
      com.example.description: "Background worker"
      com.example.service: "worker"
      
  db:
    image: mongo:5
    volumes:
      - db_data:/data/db
    networks:
      - backend-network
    restart: unless-stopped
    labels:
      com.example.description: "MongoDB database"
      com.example.service: "database"
      
  cache:
    image: redis:6
    volumes:
      - cache_data:/data
    networks:
      - backend-network
    restart: unless-stopped
    labels:
      com.example.description: "Redis cache"
      com.example.service: "cache"

networks:
  frontend-network:
    driver: bridge
  backend-network:
    driver: bridge
    internal: true  # No external connectivity
    
volumes:
  db_data:
  cache_data:

Key features of this configuration:

Custom networks isolate traffic between service groups
The backend network is marked as internal, preventing direct internet access
The API service bridges both networks, allowing controlled communication
Descriptive labels help with organization and automation
Environment variables pass configuration without hardcoding
Persistent volumes ensure data survives container restarts

Container Management Features

SSM provides several powerful features for container management:

1. Centralized Control

Manage containers across all your devices from a single interface:

Deploy to multiple devices simultaneously
View container status across your infrastructure
Apply consistent configurations

2. Update Management

Keep containers up-to-date with minimal effort:

Detect available image updates
Schedule automatic updates (Coming soon)
Roll back problematic updates (Coming soon)

3. Resource Monitoring

Track container performance and resource usage:

CPU and memory utilization
Network traffic (Coming soon)
Disk I/O (Coming soon)
Log monitoring

4. Health Checks

Ensure containers are functioning correctly:

Automatic health probes
Restart policies for failed containers
Notification alerts for issues

Best Practices

Container Security

💡 Security Best Practices

Use specific image tags instead of latest for production
Scan images for vulnerabilities before deployment
Run containers with the least privileges necessary
Use read-only file systems where possible
Implement network policies to restrict container communication
Keep host systems and Docker updated with security patches
Use secrets management for sensitive data instead of environment variables

Resource Management

💡 Resource Best Practices

Set appropriate CPU and memory limits for all containers
Use resource reservations for critical services
Monitor resource usage and adjust limits as needed
Implement health checks to detect and restart failed containers
Use rolling updates to avoid downtime during deployments
Configure appropriate restart policies based on service requirements

Data Management

💡 Data Best Practices

Use named volumes for persistent data instead of bind mounts
Implement regular backup strategies for container volumes
Document volume mappings and data locations
Use volume drivers appropriate for your storage needs
Consider using external storage services for critical data
Test data recovery procedures regularly

Container Organization

💡 Organization Best Practices

Apply consistent labeling to all containers and volumes
Group related services using Docker Compose
Use meaningful container names that reflect their purpose
Document container dependencies and communication patterns
Implement logging strategies for container output
Use environment-specific configuration files

⛔ Common Pitfalls to Avoid

Don't expose unnecessary ports to the internet
Don't store sensitive data in container images or environment variables
Don't run containers with root privileges when avoidable
Don't ignore container update notifications
Don't deploy without considering resource requirements
Don't use the same image tags for different versions
Don't neglect container logs for troubleshooting
Don't hardcode configuration values in container images

Common Misconceptions

Misconception 1: Containers are lightweight virtual machines

Reality: While containers provide isolation, they share the host's kernel and are much more lightweight than VMs. They're designed for application packaging, not full system virtualization.

Misconception 2: Containers automatically persist data

Reality: By default, data in containers is ephemeral and will be lost when the container is removed. Persistent data requires explicit volume configuration.

Misconception 3: Container images are always secure

Reality: Container images can contain vulnerabilities or malicious code. Always use trusted sources and implement proper scanning and security practices.

💻 Device Model

How devices host and run containers in SSM

🔄 Automation Model

How to automate container management tasks

📋 Playbooks Model

Using Ansible playbooks for advanced container orchestration

Device Configuration

What is a Container in SSM? ​

Key Components of the Container Model ​

1. Container Instances ​

2. Container Stacks ​

3. Container Templates ​

4. Container Registry Integration ​

How the Container Model Works ​

Image Selection

Configuration

Deployment

Monitoring

Management

Container Lifecycle ​

Real-World Examples ​

Scenario 1: Deploying a Web Application Stack ​

Problem:

Solution using the Container Model:

Scenario 2: Monitoring Stack with Resource Limits ​

Problem:

Solution using the Container Model:

Scenario 3: Microservices with Custom Networking ​

Problem:

Solution using the Container Model:

Container Management Features ​

1. Centralized Control ​

2. Update Management ​

3. Resource Monitoring ​

4. Health Checks ​

Best Practices ​

Container Security ​

Resource Management ​

Data Management ​

Container Organization ​

Common Misconceptions ​

Misconception 1: Containers are lightweight virtual machines ​

Misconception 2: Containers automatically persist data ​

Misconception 3: Container images are always secure ​

Related Concepts ​

Further Reading ​

What is a Container in SSM?

Key Components of the Container Model

1. Container Instances

2. Container Stacks

3. Container Templates

4. Container Registry Integration

How the Container Model Works

Container Lifecycle

Real-World Examples

Scenario 1: Deploying a Web Application Stack

Scenario 2: Monitoring Stack with Resource Limits

Scenario 3: Microservices with Custom Networking

Container Management Features

1. Centralized Control

2. Update Management

3. Resource Monitoring

4. Health Checks

Best Practices

Container Security

Resource Management

Data Management

Container Organization

Common Misconceptions

Misconception 1: Containers are lightweight virtual machines

Misconception 2: Containers automatically persist data

Misconception 3: Container images are always secure

Related Concepts

Further Reading