Terraform integration for DigitalOcean VPS and Block Storage

[altanoruc]

Context

This repository currently deploys deCDN nodes with Ansible only: ansible/playbooks/site.yml applies the hardened baseline and decdn_node roles to hosts supplied through inventory. It has no cloud provisioning layer. Add a separate Terraform layer for DigitalOcean so infrastructure provisioning feeds the existing Ansible deployment instead of duplicating node configuration or host hardening.

Scope

Create a versioned Terraform root/module for DigitalOcean that provisions a deCDN node host and its persistent cache storage.

Infrastructure

• Create a DigitalOcean Droplet with configurable region, size, image, tags, SSH key IDs, and optional monitoring/backups.
• Create a DigitalOcean Block Storage volume with configurable name, size, region, filesystem, and mount point.
• Attach the volume to the Droplet. The implementation must account for first-use formatting and idempotent mounting without putting cloud credentials or node secrets in tracked files.
• Keep the network model compatible with the existing Ansible baseline: SSH remains the management path; public node traffic is UDP/4433; metrics (9090) and admin RPC (9191) must remain loopback-only. Do not add broad public firewall rules.

Ansible hand-off

• Produce a documented hand-off to the existing ansible/ project, preferably a generated inventory or explicit Terraform outputs containing the Droplet public IP and SSH connection details.
• Do not move decdn_node settings, RPC URLs, keystores, contract addresses, or other node secrets into Terraform. Those remain in the current Ansible inventory / target-host secret flow.
• Document the order of operations: Terraform provision -> populate/use Ansible inventory -> make check -> make deploy -> operator-led on-chain onboarding.

Configuration and state

• Pin the DigitalOcean provider and Terraform versions.
• Use variables and a checked-in non-secret example tfvars file; ignore real tfvars, state, and any generated secret material.
• Document remote-state/back-end expectations, naming/tag conventions, and safe plan, apply, and destroy commands.
• Expose outputs needed by operators, including Droplet ID, public IPv4, volume ID, and the Ansible inventory/connection data.

Acceptance criteria

• terraform init and terraform validate pass for the new root/module.
• A plan with example non-secret inputs creates one Droplet, one same-region volume, and their attachment without hard-coded credentials.
• A fresh host can be handed to the existing Ansible playbook without changing the roles' security model or duplicating their responsibilities.
• Volume persistence and remount behavior are documented and exercised or covered by an automated check where practical.
• Repository documentation explains provisioning, deployment, and teardown, including the distinction between destroying cloud resources and any separate operator/on-chain cleanup.

[thiras]

Cross-reference from #72 / #73: the cloud-init path can serve as the Droplet's user_data. Terraform provisions the Droplet and volume, and cloud-init/user-data.yaml bootstraps the node on the host. It runs site.yml against localhost with the same baseline and decdn_node roles, so there is no separate Ansible hand-off. Walkthrough: cloud-init/README.md.

Things the Terraform side needs to respect:

• The user-data must stay secret-free. No RPC URL, tokens or keystores, because DigitalOcean exposes user_data through its metadata service and API. The operator writes /etc/decdn/decdn.env over SSH afterwards. make lint-cloud-init CLOUD_INIT_FILE=… checks a filled-in copy.
• An admin account with a key goes in baseline_sudo_users. DigitalOcean injects the SSH key for root only, and baseline disables root login.
• The static write_files set is fixed. The lint allows only the bootstrap's own four files, so volume formatting and mounting would need their own handling. disk_setup/fs_setup/mounts are separate cloud-init modules and aren't restricted, or Terraform can handle it.