DevOps Docker CLI Toolkit

A lightweight, modular DevOps automation CLI built with PowerShell + Docker Compose.

Manages any Docker Compose environment from the command line - container lifecycle, real-time monitoring with self-healing recovery, service-level backups, centralized logging, and health inspection.

MongoDB, Redis, and RabbitMQ are included as example services. The CLI works with any services defined in your docker-compose.yml - swap them out or add your own with no changes to the core tool.

---

📋 Table of Contents

• Features
• Architecture
• Prerequisites
• Getting Started
• Commands
• JSON Output Mode
• Self-Healing Monitor
• Backup System
• Project Structure
• Design Decisions

---

🚀 Features

Feature	Description
Container Lifecycle	Start, stop, reset your full Docker environment
Self-Healing Monitor	Detects stopped containers and auto-restarts them
Health Inspection	Per-service Docker healthcheck status
Service Backups	Timestamped backups — MongoDB, Redis, RabbitMQ included as examples
Real-Time Logs	Tail logs for any running container
JSON Output Mode	Machine-readable output for CI/CD pipelines and automation tools
Centralized Logging	All operations written to ./logs/devtool.log
Safe Execution	Every command wrapped in error handling — no silent failures
Modular Architecture	kubectl-style CLI — extend with new commands by adding one .ps1 file

---

🧱 Architecture

.\devtool.ps1 <command> [options]
│
▼
devtool_init.ps1 ← dot-sources config + logger globally
│
├── config.ps1 ← $global:ComposeFile, $global:LogFile
└── logger.ps1 ← Write-Log function (timestamp + level + file)
│
▼
safe-run.ps1 ← Invoke-SafeRun: try/catch wrapper for all commands
│
▼
/commands/
├── up.ps1 ← docker compose up
├── down.ps1 ← docker compose down
├── reset.ps1 ← down -v + up (full rebuild)
├── status.ps1 ← per-service status dashboard (+ JSON mode)
├── health.ps1 ← Docker healthcheck inspection (+ JSON mode)
├── logs.ps1 ← docker logs -f <service>
├── monitor.ps1 ← continuous monitoring + self-healing (+ JSON mode)
├── backup.ps1 ← routes to service-specific backup script
├── clean.ps1 ← docker system prune (with confirmation)
└── /backups/
├── mongo-db-backup.ps1
├── redis-cache-backup.ps1
└── rabbitmq-broker-backup.ps1

---

📦 Prerequisites

• Docker Desktop (or Docker Engine)
• PowerShell 7+ (Windows / macOS / Linux)
• Docker Compose v2

# Verify your setup
docker --version
docker compose version
pwsh --version
# Allow PowerShell scripts to run (run once)Set-ExecutionPolicy-Scope CurrentUser -ExecutionPolicy RemoteSigned

---

⚡ Getting Started

# 1. Clone the repo
git clone https://github.com/morel-source/DevOpsCLIToolkit
cd devops-docker-cli-toolkit
# 2. (Optional) Replace example services in docker/docker-compose.yml with your own# 3. Start the environment
.\devtool.ps1 up
# 4. Check everything is running
.\devtool.ps1 status
# 5. See all available commands
.\devtool.ps1 help

---

🧪 Commands

Container Lifecycle

.\devtool.ps1 up # Start all services
.\devtool.ps1 down # Stop all services
.\devtool.ps1 reset # Full teardown + rebuild (removes volumes)
.\devtool.ps1 status # Show running/stopped status per service

Observability

.\devtool.ps1 health # Healthcheck status per container
.\devtool.ps1 logs mongo-db # Tail logs for a specific service
.\devtool.ps1 logs redis-cache
.\devtool.ps1 logs rabbitmq-broker

Monitoring

.\devtool.ps1 monitor # Continuous monitor (10s interval)
.\devtool.ps1 monitor -intervalSeconds 5# Custom interval
.\devtool.ps1 monitor -selfHeal # Auto-restart stopped containers
.\devtool.ps1 monitor -json # JSON output for automation

Backup

.\devtool.ps1 backup mongo-db # MongoDB dump (mongodump)
.\devtool.ps1 backup redis-cache # Redis snapshot (dump.rdb)
.\devtool.ps1 backup rabbitmq-broker # RabbitMQ definitions (JSON)

Backups saved to ./backups/<service>-<timestamp>/.

Utilities

.\devtool.ps1 clean# Remove unused/stopped resources only — running containers are safe (asks confirmation)
.\devtool.ps1 help # Show all commands

---

📊 JSON Output Mode

Commands that support -json return structured machine-readable output instead of colored text. Useful for CI/CD pipelines, monitoring dashboards, or scripting on top of the toolkit.

Supported commands:status, health, monitor

status -json

.\devtool.ps1 status -json

Output:

[
{
"service": "mongo-db",
"status": "running",
"running": true
},
{
"service": "redis-cache",
"status": "running",
"running": true
},
{
"service": "rabbitmq-broker",
"status": "exited",
"running": false
}
]

health -json

.\devtool.ps1 health -json

Output:

[
{
"service": "mongo-db",
"health": "healthy"
},
{
"service": "redis-cache",
"health": "healthy"
},
{
"service": "rabbitmq-broker",
"health": "no_healthcheck"
}
]

monitor -json

.\devtool.ps1 monitor -json -intervalSeconds 10

Output (one block per interval):

{
"timestamp": "14:22:05",
"services": [
{
"service": "mongo-db",
"status": "running",
"healed": false
},
{
"service": "redis-cache",
"status": "running",
"healed": false
},
{
"service": "rabbitmq-broker",
"status": "running",
"healed": false
}
]
}

Using JSON output in scripts

# Check if all services are running$status= .\devtool.ps1 status -json |ConvertFrom-Json$allRunning= ($status|Where-Object { -not$_.running }).Count -eq0# Get only unhealthy containers$health= .\devtool.ps1 health -json |ConvertFrom-Json$unhealthy=$health|Where-Object { $_.health-eq"unhealthy" }

---

🔁 Self-Healing Monitor

.\devtool.ps1 monitor -selfHeal

Detects stopped or crashed containers and automatically restarts them via docker compose up -d <service>.

Example output:

============================== [14:22:05]
[OK] mongo-db
[WARNING] redis-cache = exited
[HEALING] Restarting redis-cache...
[OK] rabbitmq-broker

Every heal event is written to ./logs/devtool.log with level WARN.

---

💾 Backup System

Each service has its own backup strategy. MongoDB, Redis, and RabbitMQ are included as examples - adding support for a new service takes one file:

# To add backup for a new service (e.g. postgres):# 1. Create commands/backups/postgres-backup.ps1# 2. Done — .\devtool.ps1 backup postgres finds and runs it automatically

Service	Method	Output
mongo-db(example)	mongodump	BSON dump folder
redis-cache(example)	redis-cli SAVE + dump.rdb	RDB snapshot
rabbitmq-broker(example)	rabbitmqctl export_definitions	definitions.json
your-service	Add your own .ps1	Any format

All backups verify the container is running, validate output is not empty, and log to ./logs/devtool.log.

---

📁 Project Structure

devops-docker-cli-toolkit/
├── devtool.ps1 # CLI entry point
├── devtool.init.ps1 # Global loader
├── config.ps1 # $global:ComposeFile, $global:LogFile
├── docker/
│ └── docker-compose.yml # Example services (replace with your own)
├── commands/
│ ├── safe-run.ps1 # Invoke-SafeRun — centralized error handling
│ ├── logger.ps1 # Write-Log — timestamp + level + file output
│ ├── up.ps1
│ ├── down.ps1
│ ├── reset.ps1
│ ├── status.ps1 # supports -json
│ ├── health.ps1 # supports -json
│ ├── logs.ps1
│ ├── monitor.ps1 # supports -selfHeal, -json
│ ├── backup.ps1
│ ├── clean.ps1
│ ├── help.ps1
│ └── backups/
│ ├── mongo-db-backup.ps1
│ ├── redis-cache-backup.ps1
│ └── rabbitmq-broker-backup.ps1
├── logs/ # Auto-created on first run
└── backups/ # Auto-created on first backup

---

🎯 Design Decisions

Why PowerShell? Cross-platform (Windows/macOS/Linux via pwsh 7+), native Docker CLI integration, strong scripting for DevOps automation - no extra runtime needed.

Why modular command structure? Inspired by kubectl - each command is a self-contained script. Adding a new command = one .ps1 file + one line in devtool.ps1.

Why Invoke-SafeRun? Centralizes error handling and logging. Every command gets try/catch and log entries automatically - no duplicated boilerplate.

Why JSON output mode? Human-readable colored output is great for developers but useless for scripts, CI/CD pipelines, or monitoring systems. The -json flag makes the toolkit composable - output can be piped into other tools, parsed, or fed into dashboards.

Why named Docker volumes? Data persists across docker compose down. Without named volumes, every restart destroys data — not acceptable even in a dev environment.

---

📌 Potential Improvements

• Restore commands (paired with each backup type)
• Parallel container startup with progress indicators
• Plugin system - drop a .ps1 in /commands/ and it auto-registers
• Web UI for monitoring dashboard
• Metrics collection (CPU / memory per container)