Charles N Wyble
c5a504f9c8
- Add MENTALMODEL.md documenting architecture and tool responsibilities - Clarify Salt is for ongoing configuration management and automation - Clarify Ansible is for ComplianceAsCode deployment from github.com/ComplianceAsCode/content - Update README.md to reflect correct understanding of tool purposes - Update decision matrix for when to use each tool - Document migration path and future service plans (Beszel, Netbird via Salt) Establishes clear separation of concerns across the configuration management ecosystem. 💘 Generated with Crush Assisted-by: GLM-4.6 via Crush <crush@charm.land>
55 lines
2.2 KiB
Markdown
55 lines
2.2 KiB
Markdown
# KNEL Configuration Management Mental Model
|
|
|
|
## Architecture Overview
|
|
|
|
### FetchApply - One-Time Provisioning
|
|
- **Purpose:** Initial server setup and basic configuration
|
|
- **When:** Runs once at first boot of newly provisioned system
|
|
- **What:** System detection, package installation, security hardening, basic monitoring setup
|
|
|
|
### Salt - Ongoing Configuration Management & Automation
|
|
- **Purpose:** Day-to-day system configuration, automation, and orchestration
|
|
- **When:** Continuously via Salt master/minion relationship
|
|
- **What:**
|
|
- Configuration management (file distribution, service management)
|
|
- Ad-hoc automation tasks
|
|
- System orchestration
|
|
- Application deployment
|
|
- Beszel client configuration and management
|
|
- Netbird client configuration and management (future)
|
|
|
|
### Ansible - ComplianceAsCode Deployment
|
|
- **Purpose:** Deploy and manage compliance as code content
|
|
- **When:** Periodically or on-demand compliance deployment
|
|
- **What:**
|
|
- Deploy https://github.com/ComplianceAsCode/content
|
|
- Apply compliance frameworks (CIS, STIG, etc.)
|
|
- Compliance validation and remediation
|
|
- Documentation generation
|
|
|
|
### Network Services
|
|
- **Tailscale:** Currently active VPN overlay network
|
|
- **Netbird:** Future replacement (to be deployed via Salt)
|
|
- **Beszel:** Future monitoring replacement (to be deployed via Salt)
|
|
|
|
## Migration Path
|
|
|
|
1. **Current State:** FetchApply + Manual Management
|
|
2. **Transition State:** FetchApply + Salt + Ansible
|
|
3. **Future State:** Salt + Ansible (FetchApply deprecated)
|
|
|
|
## Tool Responsibilities
|
|
|
|
| Tool | Primary Responsibility | Secondary Responsibilities |
|
|
|-------|-------------------|------------------------|
|
|
| FetchApply | Initial provisioning | Foundation setup |
|
|
| Salt | Ongoing configuration | Automation, orchestration, client deployment |
|
|
| Ansible | Compliance deployment | Documentation, validation |
|
|
|
|
## Decision Matrix
|
|
|
|
- **Use Salt for:** System configuration, automation, deployment, ongoing management
|
|
- **Use Ansible for:** Compliance as code, security frameworks, documentation
|
|
- **Use FetchApply for:** Initial server setup (temporary, to be replaced)
|
|
|
|
This model ensures clear separation of concerns while providing comprehensive coverage of system lifecycle management. |