Docker Compose Operations
Relevant source files
The following files were used as context for generating this wiki page:
Docker Compose Operations provide the mechanism for the infrahub-ops-cli toolset to interact with Infrahub deployments running in Docker environments. The system uses a shell-out architecture to execute docker compose commands directly through a CommandExecutor, ensuring consistency with standard Docker CLI behavior without requiring heavy SDK dependencies. Sources: AGENTS.md, specs/archive/003-collect-tool/plan.md, dev/README.md
These operations support three primary utilities: infrahub-backup for data protection, infrahub-taskmanager for maintenance, and infrahub-collect for troubleshooting. The logic targets specific service names defined in the Infrahub deployment contract, including the core database and infrastructure services. Sources: AGENTS.md, specs/archive/003-collect-tool/research.md
Core Architecture and Execution
The project utilizes a CommandExecutor to shell out to the docker CLI. This architectural choice avoids the complexity of Go-native Docker SDKs while maintaining support for remote Docker contexts and standard authentication methods. Sources: specs/archive/003-collect-tool/plan.md, specs/archive/003-collect-tool/research.md, dev/README.md
Docker Backend Implementation
The DockerBackend struct implements environment-specific logic for Docker Compose deployments. It provides primitives for project discovery, service identification, and container interaction. Sources: specs/archive/003-collect-tool/plan.md, specs/archive/003-collect-tool/tasks.md
The diagram above shows the flow from a CLI command through the shared application logic to the specific Docker backend execution. Sources: AGENTS.md, specs/archive/003-collect-tool/research.md
Service Discovery and Project Handling
The system targets Infrahub services using a project-based approach. Users can specify a target project using the --project flag or let the tool discover the environment automatically. Sources: AGENTS.md, specs/archive/003-collect-tool/plan.md, specs/archive/003-collect-tool/tasks.md
Canonical Service Names
All Docker operations assume Infrahub is deployed with these specific service names:
| Service Name | Description |
|---|---|
database | Neo4j database container |
task-manager-db | PostgreSQL database container |
infrahub-server | Core application server |
task-worker | Prefect task worker |
task-manager | Prefect task manager |
cache | Redis infrastructure service |
message-queue | RabbitMQ infrastructure service |
Sources: AGENTS.md, specs/archive/003-collect-tool/tasks.md
Replica Enumeration
For troubleshooting and log collection, the DockerBackend implements ServiceReplicas. It executes docker compose -p <project> ps <service> to identify all active containers. The system identifies containers by their name rather than opaque IDs to ensure human-readable output in support bundles. Sources: specs/archive/003-collect-tool/tasks.md, specs/archive/003-collect-tool/research.md, specs/archive/003-collect-tool/opsmill-implement-report.md
Data Collection and Diagnostics
Docker Compose operations include read-only diagnostic collection for troubleshooting. These operations use time-bounded execution to prevent hangs on degraded containers. Sources: specs/archive/003-collect-tool/plan.md, specs/archive/003-collect-tool/research.md, dev/README.md
Log Streaming
The system fetches logs using docker logs --tail <n> <container>. Because Infrahub services often log to stderr, the DockerBackend uses a combined stdout and stderr pipe primitive to capture complete log streams. Sources: specs/archive/003-collect-tool/tasks.md, specs/archive/003-collect-tool/research.md, specs/archive/003-collect-tool/opsmill-implement-report.md
Resource Metrics
Container resource usage is gathered via docker stats --no-stream. This command targets all containers associated with the Infrahub project to provide a snapshot of CPU and memory utilization. Sources: specs/archive/003-collect-tool/tasks.md, specs/archive/003-collect-tool/research.md
Parity Diagnostics
The tool executes specific commands inside containers to gather service-specific state:
- RabbitMQ: Runs
rabbitmqctlcommands for queue and exchange lists. - Redis: Runs
redis-clifor info and configuration dumps. - Neo4j: Copies specific log files like
neo4j.loganddebug.log.
Sources: specs/archive/003-collect-tool/tasks.md, specs/archive/003-collect-tool/research.md
Safety and Operational Constraints
Docker operations are categorized by their impact on the workload lifecycle. Sources: specs/archive/003-collect-tool/plan.md, dev/README.md
The sequence above distinguishes between non-destructive troubleshooting and backup operations that may require container restarts. Sources: specs/archive/003-collect-tool/plan.md, specs/archive/003-collect-tool/research.md, dev/README.md
- Read-Only Guarantee: Collection operations (
infrahub-collect) never stop, start, or scale containers. Sources: specs/archive/003-collect-tool/plan.md, dev/README.md - Timeout Enforcement: Collector commands are bounded (typically 60s for status, 5m for transfers) using
exec.CommandContextto ensure a wedged container does not stall the CLI. Sources: specs/archive/003-collect-tool/tasks.md, specs/archive/003-collect-tool/research.md, specs/archive/003-collect-tool/opsmill-implement-report.md - Secret Masking: Outputs from
envorconfigcommands are passed through a masking filter that redacts values for keys containingpassword,secret,token, orkey. Sources: specs/archive/003-collect-tool/tasks.md, specs/archive/003-collect-tool/research.md, dev/README.md
Docker Compose Operations enable robust management and diagnostics of Infrahub instances by leveraging standard Docker CLI tools through a safe, timeout-bounded execution framework. This ensures that operators can perform backups and gather troubleshooting data reliably across different host environments. Sources: AGENTS.md, specs/archive/003-collect-tool/plan.md, specs/archive/003-collect-tool/opsmill-implement-report.md