Why Pair HashiCorp Nomad with Terraform Cloud

Practitioners running modern application schedulers often find themselves juggling separate toolchains for provisioning, scheduling, and configuration management. HashiCorp Nomad and Terraform Cloud address different layers of that stack, yet they share a common declarative philosophy that makes them a natural fit when stitched together correctly. By treating your scheduler nodes, clients, and supporting infrastructure as code, you gain reproducibility across development, testing, and production environments without relying on hand-built golden images.

Australian engineering teams regularly cite the local skills shortage as a driver toward automation that scales beyond a single engineer’s laptop. Distributing infrastructure provisioning through a shared SaaS control plane means a graduate in Brisbane, a senior engineer in Perth, and a contractor in Adelaide can all consume the same approved modules without copying credentials. This consistency matters even more as organisations chase the Australian Signals Directorate’s Essential Eight maturity targets, where repeatable, auditable deployment patterns are essential artefacts.

Architectural Benefits of a Unified Workflow

Terraform Cloud provides remote state locking, a private module registry, and policy enforcement through Sentinel or OPA, which removes a large class of drift issues that plague Nomad deployments. Instead of running terraform apply from a workstation, every change flows through the same Git repository, picking up code review, branch policies, and run triggers automatically. Nomad itself remains responsible for bin packing containers, Java virtual machines, and standalone binaries, while Terraform handles the operating system patching, the Consul agent lifecycle, and the underlying compute footprint.

This separation keeps the cognitive load reasonable. Teams already comfortable with HCL can extend existing modules to manage server nodes, client nodes, and gossip encryption keys without learning a brand new domain-specific language for orchestration. The trade-off is that you must design your modules around lifecycle boundaries, separating long-lived server components from ephemeral clients and autoscaling groups.

Planning Topology for Australian Workloads

Latency between control plane regions influences where you place Nomad servers. Most Australian workloads benefit from anchoring servers in the AWS Sydney region (ap-southeast-2) while keeping a small failover presence in Melbourne (ap-southeast-4) for organisations that need geographic diversity. If you serve customers across both Melbourne and Perth, consider deploying regional client pools and letting Nomad’s affinity rules steer workloads to the closest data source.

Bandwidth costs inside the continent remain reasonable, yet egress to offshore cloud regions can be eye-watering for chatty workloads. Keeping stateful components such as databases close to consumers reduces reliance on trans-Tasman or trans-Pacific links. For hybrid scenarios where on-premises hardware in a Canberra datacentre talks back to public cloud control planes, make sure your Terraform plan accounts for IPsec tunnels and the public IP allocations your provider assigns.

Configuring the Workspace and VCS Link

Begin by creating a dedicated Terraform Cloud organisation and a workspace per environment, mapping each to a branch in your version control repository. Enable the “VCS-driven” run trigger so that pull requests produce speculative plans before reviewers even ask, and let merged changes trigger an apply after the required checks pass. Switching execution mode to “Remote” ensures that the agent running the plan has fresh credentials and respects your provider’s API quotas.

Inject sensitive values through workspace variables rather than committing them to the repository. Keep terraform variables such as region, nomad_datacenter, and consul_datacenter as workspace-level overrides so that the same module serves development workloads in ap-southeast-2 and disaster recovery drills in ap-southeast-4. Pair the workspace with a notification webhook pointing at your incident chat tool; the quick feedback loop helps engineers catch a misconfigured ACL bootstrap before it cascades.

Authoring the Nomad Cluster Module

A resilient module separates server, client, and common inputs. Servers should sit across three availability zones with automatic leader election, while clients scale behind an autoscaling group sized to the workload catalogue. Define the Nomad gossip encryption key as a sensitive output and store it in HashiCorp Vault, letting servers fetch it on boot through the Consul Template integration or a simple user-data script.

Consul agents, whether colocated or split, require their own ACL token bootstrap and a snapshot restore plan. Terraform can render Nomad and Consul configuration files from templates using the templatefile function, ensuring that each environment receives the right gossip port, advertised IP, and telemetry collector endpoint. Make the module small enough that an engineer can read it top to bottom; complexity in HCL grows linearly with regret during incident response.

Hardening Communication with ACLs and mTLS

Nomad and Consul both rely on mutual TLS to authenticate gossip and RPC traffic. Provision the certificate authority with Terraform and distribute the leaf certificates via cloud-init, rotating them through an automated pipeline rather than manual renewals. Default-deny ACL policies should govern everything from job submission to volume mounting, with roles granted only to specific workload identities.

The Notifiable Data Breaches scheme under the Privacy Act raises the stakes for any telemetry that touches customer information. Encrypt gossip with AES-GCM, lock down the HTTP API behind an authenticating proxy, and restrict the UI exposure to operators who already cleared a privileged access review. Where APRA CPS 234 applies, capture the configuration hash of each server in your change management records so auditors can trace a deployed cluster back to its commit.

Rolling Out Across Sydney and Melbourne Regions

Multi-region deployments multiply the moving parts, but Terraform Cloud’s run triggers keep the choreographed effort manageable. Promote an ap-southeast-2 apply through manual approval, then trigger a downstream workspace that targets ap-southeast-4 once the primary run finishes. Use terraform_remote_state to share between workspaces, and version your outputs so a Melbourne client knows which Sydney server endpoint to register against.

Validate each rollout with a synthetic job that schedules across both regions and reports a heartbeat to your monitoring stack. If latency crosses a threshold, the job fails and the alerting pipeline pages the on-call engineer. Performance under real load tells you whether the planned capacity matches the actual demand profile, especially when Australian customers access services during evening peak hours that stretch the working day of distributed teams.

Practical Recommendations for a Smooth Rollout

• Pin provider versions and the Nomad version in your module’s required_providers block to avoid silent upgrades.
• Use a private module registry in Terraform Cloud so teams consume approved code without cloning individual repositories.
• Enable Sentinel or OPA policies to prevent untagged resources, accidental public IP allocation, or missing encryption flags.
• Run terraform plan against production data sources in a read-only mode weekly to detect drift before it causes an incident.
• Store gossip encryption keys and ACL bootstrap tokens in Vault, never in workspace variables or repository files.
• Treat server configuration files as rendered artefacts, comparing them to a checked-in baseline during peer review.
• Schedule a quarterly game day where the team tears down a region to validate the rebuild procedure end to end.