-
Notifications
You must be signed in to change notification settings - Fork 76
Container Operations
DockMon provides comprehensive container management capabilities, from basic lifecycle operations to advanced batch actions and detailed inspection.
Container operations in DockMon allow you to:
- Control container lifecycle (start, stop, restart)
- View real-time logs from running containers
- Inspect configurations and environment variables
- Monitor resource usage (CPU, memory, network I/O)
- Manage container tags for organization
- Configure policies (auto-restart, desired state, auto-update)
- Perform bulk operations on multiple containers simultaneously
The container table is your primary interface for viewing and managing containers.
| Column | Description |
|---|---|
| Select | Checkbox for bulk operations |
| Status | Visual indicator of container state (running, stopped, etc.) |
| Name | Container name with clickable tags |
| Policy | Auto-restart, desired state, and auto-update icons |
| Alerts | Active alert count by severity (critical/error/warning/info) |
| Updates | Update availability indicator |
| Host | Docker host where container runs |
| Uptime | Time since container creation |
| CPU% | Current CPU usage percentage |
| RAM | Current memory usage |
| Actions | Start, stop, restart, logs, view details buttons |
Containers display color-coded status icons:
| Status | Color | Icon | Description |
|---|---|---|---|
| Running | Green | Filled circle | Container is actively running |
| Stopped/Exited | Red | Filled circle | Container has exited |
| Created | Gray | Filled circle | Container created but never started |
| Paused | Yellow | Filled circle | Container is paused (frozen) |
| Restarting | Blue | Spinning circle | Container is currently restarting |
| Dead | Red | Filled circle | Container is in dead state (unrecoverable) |
Three icons indicate container automation policies:
Auto-Restart Icon:
- Blue refresh icon: Auto-restart enabled
- Gray crossed-out refresh: Auto-restart disabled
- Hover for tooltip with current status
Desired State Icon:
- Green filled play: Should be running (and currently running)
- Black play: Should be running (but currently stopped)
- Yellow warning triangle: Should be running but is exited (attention needed!)
- Gray clock: On-demand (no desired state)
Auto-Update Icon:
- Amber package icon: Auto-update enabled
- No icon: Auto-update disabled
- Hover for tooltip with current status
Requirements: Container must be in stopped/exited/created state
Methods:
- Quick action: Click green Play icon in Actions column
- Details modal: Open container → Actions tab → Start button
- Bulk action: Select multiple containers → Bulk Actions bar → Start
Behavior:
- Starts container using Docker API
- Updates status in real-time via WebSocket
- Shows success/error toast notification
- If auto-restart enabled, monitoring begins immediately
Requirements: Container must be running
Methods:
- Quick action: Click red Stop icon in Actions column
- Details modal: Open container → Actions tab → Stop button
- Bulk action: Select multiple containers → Bulk Actions bar → Stop
Behavior:
- Sends SIGTERM signal (graceful shutdown)
- Waits 10 seconds for graceful exit
- Forces stop (SIGKILL) if container doesn't exit
- Updates status in real-time via WebSocket
Note: Stopping a container with desired_state: should_run will trigger a warning icon, as the container will likely be auto-restarted if auto-restart is enabled.
Requirements: Container must be running
Methods:
- Quick action: Click blue Restart icon in Actions column
- Details modal: Open container → Actions tab → Restart button
- Bulk action: Select multiple containers → Bulk Actions bar → Restart
Behavior:
- Stops container gracefully (SIGTERM + 10s timeout)
- Starts container with same configuration
- Useful for applying environment changes or clearing memory leaks
- Resets uptime counter
Use cases:
- Apply configuration changes that require restart
- Clear memory leaks in long-running containers
- Recover from hung state
- Force reload of application code
Default behavior (Simplified Workflow enabled):
- Click container card to open full-screen details view with all tabs
Alternative behavior (Simplified Workflow disabled):
- Click container card to open drawer (quick view from the side)
- The drawer provides quick access to container information
Toggle workflow: Settings → Dashboard → Simplified Workflow
Displays comprehensive container information:
Container Metadata:
- Container ID (12-character short ID)
- Image name and tag
- Created timestamp
- Host assignment
Configuration:
- Environment variables (with masking for sensitive values)
- Volumes and mounts
- Network settings
- Port mappings
- Labels
Runtime State:
- Current status
- Exit code (if stopped)
- PID (process ID)
- Restart count
Stats Charts:
- CPU Usage, Memory Usage, and Network I/O charts for this container
- By default, charts show live data (real-time WebSocket stream, last few minutes only)
- When historical stats persistence is enabled (Settings → System), a time-range selector appears above the charts (5m / 1h / 24h / 7d / 30d / 60d / 90d). The charts can then render historical data at any of those depths, with older data downsampled into cascade tiers
- For containers on agent-based hosts, historical charts require agent v1.0.8 or newer. Older agents continue to deliver live stats but won't contribute to history
Real-time container log viewer:
Features:
- Live streaming: Logs update in real-time via WebSocket
- Tail options: Last 100, 500, 1000 lines, or all
- Search/filter: Find specific log entries
- Copy to clipboard: Export logs for analysis
- Auto-scroll: Toggle automatic scrolling to latest entries
- Timestamps: Show/hide log timestamps
- Color coding: ANSI color support for formatted logs
Best practices:
- Start with 100 lines for quick debugging
- Use search to find error patterns
- Disable auto-scroll when analyzing historical logs
- Copy logs before container restart (logs are ephemeral)
Container event history:
Displays:
- All events for this specific container
- Event type (start, stop, die, restart, etc.)
- Timestamp with millisecond precision
- Exit codes (for stop/die events)
- Context information
Useful for:
- Diagnosing crash loops
- Understanding restart patterns
- Audit trail for container lifecycle
Container tag management:
Features:
- View all tags (derived + custom)
- Add custom tags
- Remove custom tags
- Tag autocomplete (suggests existing tags)
Tag types:
-
Derived tags (automatic, cannot be removed):
- Docker Compose project tags (from
com.docker.compose.projectlabel) - Docker Swarm service tags (from
com.docker.swarm.service.namelabel)
- Docker Compose project tags (from
-
Custom tags (user-defined, can be removed):
- Any user-added tags via UI or bulk operations
Use cases:
- Organize containers by environment (production, staging, dev)
- Group by purpose (web, database, cache)
- Mark for specific alert rules
- Enable tag-based filtering in dashboard
Configure HTTP/HTTPS health checks:
Configuration:
- Endpoint URL (e.g.,
http://localhost:8080/health) - Check interval (seconds)
- Timeout (seconds)
- Failure threshold (consecutive failures before action)
- Auto-restart on failure (toggle)
Status:
- Last check time
- Last check result (success/failure)
- Failure count
- Next check time (countdown)
Use cases:
- Monitor web application availability
- Auto-restart services that hang but don't crash
- Detect and recover from deadlocks
- Ensure critical services remain responsive
Configure automatic restart behavior:
Settings:
- Enable/Disable: Toggle auto-restart for this container
- Max retries: Maximum restart attempts before giving up (0-10)
- Retry delay: Seconds to wait between restart attempts (5-300)
- Backoff strategy: Linear or exponential delay increase
Status:
- Current restart attempt count
- Last restart time
- Next retry time (if in retry loop)
Best practices:
- Always-on services: Enable with 5+ retries
- One-shot tasks: Disable auto-restart
- Flaky services: Use exponential backoff with longer delays
- Critical infrastructure: Enable with alerts on failures
Container image update management:
Displays:
- Current image tag
- Available image tag (if update exists)
- Last update check time
- Update history
Actions:
- Check for updates now
- Update to latest version
- View update changelog (if available)
- Configure auto-update settings
Auto-update configuration:
- Enable auto-update: Automatically update when new version available
-
Floating tag mode: How to handle version tags
-
allow: Allow updates for floating tags (e.g.,latest,stable) -
prevent: Skip updates for floating tags (only update pinned versions)
-
- Update schedule: When to check and apply updates
Select multiple containers to perform batch actions efficiently.
Methods:
- Individual: Click checkbox next to each container
- All visible: Click checkbox in table header
- Filter + select all: Apply search/filter → Select all visible
Selection count: Displayed in floating bulk action bar
When containers are selected, a bar appears at the bottom with:
Actions:
- Start: Start all selected stopped containers
- Stop: Stop all selected running containers
- Restart: Restart all selected running containers
- Clear selection: Deselect all containers
Tag management:
- Add tags: Apply tags to all selected containers
- Remove tags: Remove tags from all selected containers
Policy management:
- Enable auto-restart: Turn on auto-restart for all selected
- Disable auto-restart: Turn off auto-restart for all selected
- Set desired state: Set to "Should Run" or "On-Demand"
- Configure auto-update: Enable/disable for all selected
Bulk operations run as background jobs with progress tracking:
Progress panel displays:
- Overall progress percentage
- Succeeded container count
- Failed container count
- Per-container status (pending, running, success, failed)
- Error messages for failures
Features:
- Real-time progress updates
- Cancellable operations
- Detailed error reporting
- Success/failure summary
Best practices:
- Start with small batches (5-10 containers) to verify behavior
- Monitor first batch job before scheduling larger operations
- Review failed containers and retry manually if needed
- Don't close browser during batch operations (job continues server-side)
The search box filters containers by:
- Container name
- Image name
- Host name
- Tags
Examples:
-
nginx- Find all nginx containers -
production- Find all containers tagged "production" -
web-server- Find containers on host named "web-server"
Filter by status:
- Click column header → Sort by status
- Groups running/stopped containers together
Filter by host:
- Click host name in container row
- Shows only containers on that host
- URL updates to include
?hostId=<id>for shareable links
Filter by tag:
- Click tag chip on container
- Shows only containers with that tag
- Useful for environment-based views
-
Identify the problem:
- Check status column for exit code
- Look for red "exited" status
- Check alerts for error notifications
-
Review logs:
- Open container details → Logs tab
- Search for "error", "exception", "fatal"
- Note timestamp of last successful operation
-
Inspect configuration:
- Info tab → Check environment variables
- Verify volume mounts are correct
- Check port conflicts
-
Review events:
- Events tab → Look for restart loops
- Check frequency of crashes
- Note exit codes
-
Fix and restart:
- Address root cause (config, resources, dependencies)
- Click Restart to test fix
- Monitor logs for successful startup
When config changes require restart without downtime:
-
Tag containers by instance role (e.g., "web-1", "web-2", "web-3")
-
Restart in batches:
- Select containers with tag "web-1"
- Bulk Actions → Restart
- Wait for completion and health check success
- Repeat for "web-2", "web-3", etc.
-
Monitor:
- Watch for successful startup in logs
- Verify health checks pass
- Check error rates in application metrics
Prepare for scheduled maintenance:
-
Enable blackout window (Settings → Alerts → Blackout Windows)
-
Stop non-critical services:
- Filter by tag "non-critical"
- Select all
- Bulk Actions → Stop
-
Perform maintenance (database migration, host updates, etc.)
-
Restart services:
- Select all stopped containers
- Bulk Actions → Start
- Verify all containers started successfully
-
Disable blackout window when complete
DO:
- Use descriptive container names (include purpose and instance number)
- Tag containers by environment, purpose, and team
- Set desired state for always-on services
- Enable auto-restart for critical services
- Monitor logs during first 5 minutes after start
DON'T:
- Restart containers without checking logs first
- Stop containers without understanding impact on dependent services
- Enable auto-restart for one-shot jobs or migration tasks
- Ignore yellow warning icons (desired state mismatch)
DO:
- Use structured logging (JSON) in applications for easy parsing
- Implement log rotation in containers (prevent disk fill)
- Copy important logs before container restart
- Search logs before requesting full output (performance)
DON'T:
- Stream all logs for high-traffic containers (resource intensive)
- Store sensitive data in logs (passwords, tokens, PII)
- Rely on logs as persistent storage (use external logging service)
DO:
- Use consistent tag naming (lowercase, hyphen-separated)
- Create tag hierarchy (environment → purpose → instance)
- Document tag meanings in team wiki
- Remove obsolete tags to keep system clean
DON'T:
- Create too many tags (hard to manage)
- Use special characters in tags (can break filtering)
- Tag every container with every category (loses meaning)
Possible causes:
- Port conflict: Another container using same port
- Volume conflict: Volume mounted by another container
- Missing dependency: Database or service not ready
- Resource limits: Insufficient CPU/RAM on host
- Image missing: Image pulled incorrectly or deleted
Solutions:
- Check logs for specific error message
- Review Info tab → Port mappings for conflicts
- Verify host resource availability
- Check Events tab for repeated crash pattern
Possible causes:
- Crash loop: Application crashes immediately after start
- Auto-restart loop: Auto-restart enabled with low retry delay
- Health check failure: Container stops due to failed health checks
Solutions:
- Disable auto-restart temporarily
- Check logs for error during startup
- Review health check configuration (URL, timeout, threshold)
- Increase retry delay to allow debugging time
Possible causes:
- WebSocket disconnected: Connection lost to backend
- Container stopped: Can't stream logs from stopped container
- Browser tab inactive: Browser throttles inactive tabs
- Log buffer full: Too many logs, reaching rate limit
Solutions:
- Check WebSocket connection indicator (green dot in header)
- Verify container is running
- Refresh browser tab
- Reduce log tail size (100 instead of 1000)
- Dashboard - Dashboard overview and customization
- Auto-Restart - Detailed auto-restart configuration
- Blackout Windows - Schedule maintenance periods
- Alerts - Alert rules and notifications
Getting Started
User Guide
- Dashboard
- Managing Hosts
- Container Operations
- Container Tagging
- Bulk Operations
- Stacks
- Auto-Restart
- Event Viewer
- Container Logs
Configuration
- Alert Rules
- Notifications
- Blackout Windows
- Automatic Updates
- Private Registry Credentials
- Health Checks
- Settings
Remote Monitoring
Access Control
Advanced
Development
Help