Deployment Evolution¶
The lab now supports three deployment tiers conceptually, but only one of them is the default.
Current Support Model¶
- Bash deploy — canonical, simplest, and the primary documented path
- Ansible deploy — optional orchestration wrapper over the same Bash role scripts
- Enterprise Proxmox — separate
ent-*topology managed by Bash scripts and optional Ansible wrappers - Terraform — AWS-only cloud mirror path
- Ludus — future integration target after the role and inventory model stabilises
The goal is to keep the lab approachable for people who want to read the scripts and understand exactly what happens on each VM, while still creating a cleaner long-term automation path.
Why Bash Stays Default¶
- Lowest barrier to entry
- Easy to debug one host at a time
- Matches the lab’s “real shadow AI sprawl” philosophy
- Keeps the source of truth obvious for contributors
The canonical deployment path remains:
bash lab-scripts/proxmox-setup.sh
bash lab-scripts/attack-box/setup.sh
bash lab-scripts/deploy-all.sh
The current 5-VM ailab-* deployment is the Mini tier. It should stay stable for demos, scoring, and conference workflows.
Enterprise Track¶
The enterprise track lives beside the mini lab. It uses ent-* hostnames, multiple routed Proxmox bridges, and an enterprise inventory:
Preview the topology:
Create the Proxmox substrate:
Provision, seed, and verify the native enterprise services:
bash lab-scripts/enterprise-deploy.sh --phase base --profile team
bash lab-scripts/enterprise-deploy.sh --phase provision --profile team
bash lab-scripts/enterprise-deploy.sh --phase seed --profile team
bash lab-scripts/enterprise-verify.sh --layer all --profile team
The same Enterprise host/service phases can be orchestrated through Ansible after infrastructure exists:
Terraform is intentionally not part of the Proxmox enterprise path. It remains AWS-only.
Shared Inventory First¶
Before introducing more orchestration layers, the repo now centralises lab topology in:
This is the shared source of truth for:
- hostnames
- IPs
- VM IDs
- role directories
- expected service counts
- scan ports
- verification totals
The Bash scripts use this inventory today, and the optional Ansible wrapper derives its runtime inventory from the same file.
Enterprise uses its own inventory so the mini lab can remain unchanged.
Optional Ansible Path¶
The optional wrapper is:
It does not replace the Bash scripts. Instead, it:
- reads the same shared inventory
- copies the existing
lab-scripts/tree to targets - invokes the existing
provision.shand seed scripts - runs verification from the attack box
Use it when you want a more structured orchestration path, inventory-driven execution, or easier future migration into more formal automation.
Where Packer Fits¶
Packer is intentionally deferred.
Only add it if cloud-image/template drift becomes painful enough that prebuilding base Ubuntu and Debian templates saves real maintenance time. If introduced later, Packer should handle:
- base image customisation
- common package preinstalls
- template-level consistency
It should not absorb service provisioning or seeded data.
Ludus Later¶
Ludus remains the long-term integration target, but not the immediate primary path. The intended order is:
- Shared inventory and role cleanup in Bash
- Optional Ansible wrapper using the same role boundaries
- Optional Packer template work if needed
- Ludus integration using the stabilised role/inventory model
That keeps the migration incremental and preserves the current attack workflow regardless of how the VMs were provisioned.