bob
dc4ade7ed1
Prefer API token over username/password — scoped to least-privilege TerraformRole, reduces blast radius if credentials leak.
36 lines
1.4 KiB
Markdown
36 lines
1.4 KiB
Markdown
# Project: ProxmoxInfra
|
|
|
|
Terraform infrastructure-as-code for a homelab Proxmox environment.
|
|
|
|
## Context
|
|
|
|
This repo was started *after* the Proxmox server was already set up manually.
|
|
Existing infrastructure was provisioned by hand and must not be touched by
|
|
Terraform. Only new resources going forward are managed here.
|
|
|
|
## Key rules for this project
|
|
|
|
- **Never import or manage existing Proxmox resources** unless the junior
|
|
explicitly decides to and understands the risk of state drift.
|
|
- **Credentials never go in version control.** `.tfvars` files are gitignored.
|
|
Always use `terraform.tfvars.example` as the template pattern.
|
|
- **No resources in root module.** As the repo grows, push toward a
|
|
`environments/` layout with reusable modules under `modules/`.
|
|
- **State is not yet remote.** When a backend is introduced, make it a
|
|
deliberate decision with a knowledge transfer on why remote state matters
|
|
(locking, team access, DR).
|
|
|
|
## Stack
|
|
|
|
- Provider: `bpg/proxmox` (not the deprecated Telmate provider)
|
|
- Terraform >= 1.0
|
|
- Target: single-node Proxmox VE homelab
|
|
|
|
## Learning goals for this project
|
|
|
|
- Understand Terraform's core workflow (init / plan / apply / destroy)
|
|
- Understand provider authentication and least-privilege API tokens
|
|
- Understand state — what it is, why it matters, what happens when it drifts
|
|
- Build intuition for when to use a VM vs an LXC container in Proxmox
|
|
- Learn to structure a Terraform repo that can scale without becoming a mess
|