Building Repeatable and Compliant Private Clouds: Terraform with OpenMetal

Infrastructure as Code (IaC) has transformed how organizations manage their cloud resources, moving from manual configurations to declarative, version-controlled infrastructure definitions. Whether you’re working with OpenStack Heat templates, Ansible playbooks, or Terraform configurations, IaC brings consistency and repeatability to your infrastructure deployments. This article explores how Terraform specifically integrates with OpenMetal’s Hosted Private Cloud architecture, built on OpenStack and Ceph, to deliver compliant and repeatable infrastructure solutions.

What Infrastructure as Code Solves

Modern infrastructure demands go far beyond simply spinning up virtual machines. You need environments that can be recreated identically, audited completely, and recovered quickly when disasters strike.

Repeatability Across Environments

Consider a typical development-to-production pipeline. Without IaC, your development team manually configures test environments, operations teams build staging differently, and production deployments introduce subtle variations. Each environment becomes a unique snowflake with its own quirks and potential failure points.

With IaC, you define your infrastructure once and deploy it consistently across all environments. A Terraform configuration that creates your Kubernetes cluster with specific network segments, storage volumes, and security groups will produce identical results whether you’re deploying to development, staging, or production.

Auditability and Change Control

Financial services, healthcare, and government organizations face strict regulatory requirements around infrastructure changes. Traditional approaches leave audit trails scattered across ticketing systems, email approvals, and manual documentation.

IaC transforms every infrastructure change into a code commit with clear authorship, timestamps, and approval workflows. When auditors ask “Who changed the database security group on March 15th?”, you can point to a specific Git commit with a pull request showing exactly what changed and who approved it.

Disaster Recovery at Scale

Natural disasters, security incidents, and hardware failures don’t announce themselves in advance. Traditional disaster recovery plans rely on lengthy runbooks, manual procedures, and crossing fingers that backups are complete and current.

When your infrastructure exists as code, disaster recovery becomes a deployment operation. Your Terraform configurations can recreate your entire environment—complete with networking, storage, and security configurations—in minutes rather than days.

Tools in the OpenStack IaC Ecosystem

OpenStack provides multiple paths for implementing Infrastructure as Code, each with distinct strengths and appropriate use cases.

OpenStack Heat: The Native Choice

Heat serves as OpenStack’s native orchestration service, designed specifically for the OpenStack API ecosystem (OpenStack Heat User Guide). Heat templates use YAML syntax to define resources and their dependencies, with built-in understanding of OpenStack services like Nova, Neutron, and Cinder. Heat excels when your infrastructure lives entirely within OpenStack boundaries and you want tight integration with OpenStack-specific features.

Ansible: Configuration and Orchestration

Ansible brings procedural automation to OpenStack environments through its comprehensive collection of OpenStack modules (Ansible OpenStack Collection). Ansible shines in scenarios where you need to combine infrastructure provisioning with application configuration, package installation, and service management. Its agentless architecture and readable YAML playbooks make it accessible to teams transitioning from manual processes.

Terraform: Multi-Cloud Infrastructure Management

Terraform takes a different approach, treating infrastructure as immutable resources managed through a declarative state model. Terraform’s strength lies in its provider ecosystem, allowing you to manage OpenStack resources alongside AWS, Azure, Kubernetes, and hundreds of other services through a consistent workflow (HashiCorp Infrastructure as Code Guide).

While all three tools can manage OpenStack infrastructure, this article focuses on Terraform’s specific advantages when working with OpenMetal’s Hosted Private Cloud architecture.

Terraform with OpenMetal’s Architecture

OpenMetal’s Hosted Private Cloud provides a foundation that maps naturally to Terraform’s resource model. Understanding how Terraform interacts with each component of OpenMetal’s stack reveals why this combination delivers such powerful results.

Cloud Core: Your Infrastructure Foundation

OpenMetal’s Cloud Core represents your entry point into Hosted Private Cloud—a three-node hyperconverged OpenStack environment that provisions in under a minute. This cluster integrates compute through Nova, networking via Neutron, and block storage through Cinder backed by Ceph.

From a Terraform perspective, Cloud Core provides the stable API endpoints and resource pools that your configurations will consume. Your Terraform OpenStack provider connects to Cloud Core’s APIs, treating the entire cluster as a single, consistent resource pool.

Compute Resources Through Nova

Terraform’s openstack_compute_instance_v2 resource maps directly to Nova instances running on your Cloud Core nodes. You define your virtual machine specifications—CPU, memory, disk—and Terraform handles the provisioning through Nova’s API.

resource "openstack_compute_instance_v2" "web_server" {
  name            = "web-server-01"
  flavor_name     = "m1.medium"
  image_name      = "ubuntu-20.04"
  key_pair        = "production-keypair"
  security_groups = ["web-sg"]
  
  network {
    name = "private-web-network"
  }
}

This simple configuration leverages Cloud Core’s compute resources while maintaining full control over instance specifications and placement.

Networking with Neutron Integration

OpenMetal provides dual 10 Gbps NICs per server, totaling 20 Gbps of network capacity. Customer-specific VLANs support VXLAN overlays, while generous egress limits use 95th percentile billing. Private networking between nodes incurs no additional charges.

Terraform’s networking resources map to these capabilities through Neutron integration:

resource "openstack_networking_network_v2" "private_network" {
  name           = "app-private-network"
  admin_state_up = "true"
}

resource "openstack_networking_subnet_v2" "private_subnet" {
  name       = "app-private-subnet"
  network_id = openstack_networking_network_v2.private_network.id
  cidr       = "10.1.0.0/24"
  ip_version = 4
}

These configurations create isolated network segments that take advantage of OpenMetal’s VXLAN overlay capabilities, ensuring your applications have dedicated network resources.

Storage Through Ceph Integration

Ceph provides the storage foundation for OpenMetal’s architecture, delivering block, object, and file storage capabilities. Block volumes flow through Cinder, while object storage uses S3-compatible interfaces through Ceph RGW. Ceph pools support performance tuning across NVMe and HDD tiers with configurable replication and erasure coding.

Terraform manages these storage resources through multiple approaches:

resource "openstack_blockstorage_volume_v3" "app_data" {
  name = "application-data-volume"
  size = 100
  volume_type = "ceph-nvme"
}

resource "openstack_compute_volume_attach_v2" "attach_app_data" {
  instance_id = openstack_compute_instance_v2.web_server.id
  volume_id   = openstack_blockstorage_volume_v3.app_data.id
}

For object storage, Terraform’s S3 provider integrates directly with Ceph RGW endpoints, allowing you to manage buckets and objects alongside your infrastructure resources.

Practical Example: Kubernetes-Ready Environment

Consider deploying a production Kubernetes environment that demonstrates OpenMetal’s architectural integration:

# Master nodes with dedicated networking
resource "openstack_compute_instance_v2" "k8s_masters" {
  count       = 3
  name        = "k8s-master-${count.index + 1}"
  flavor_name = "k8s.master"
  image_name  = "ubuntu-20.04-k8s"
  
  network {
    name = openstack_networking_network_v2.k8s_cluster_network.name
  }
  
  # etcd storage on Ceph NVMe
  block_device {
    uuid                  = openstack_blockstorage_volume_v3.etcd_storage[count.index].id
    source_type          = "volume"
    destination_type     = "volume"
    boot_index           = 1
    delete_on_termination = false
  }
}

# Ceph volumes for persistent etcd storage
resource "openstack_blockstorage_volume_v3" "etcd_storage" {
  count       = 3
  name        = "etcd-storage-${count.index + 1}"
  size        = 50
  volume_type = "ceph-nvme"
}

This configuration creates a three-master Kubernetes cluster with persistent etcd storage on Ceph NVMe volumes, taking advantage of OpenMetal’s high-performance storage tier while ensuring data persistence across node failures.

Compliance and Governance Through Code

Regulated industries require infrastructure changes to follow strict approval processes, maintain complete audit trails, and enforce security policies consistently. Terraform’s integration with Git workflows transforms these compliance requirements from administrative overhead into automated safeguards.

Pull Request-Based Infrastructure Changes

Traditional infrastructure changes rely on change management systems, email approvals, and manual verification steps. These processes create delay, introduce human error, and scatter audit information across multiple systems.

Terraform enables Git-based infrastructure workflows where every change flows through pull requests:

1. Proposed Changes: Infrastructure modifications appear as Terraform configuration updates in feature branches
2. Impact Preview: terraform plan outputs show exactly what resources will change, providing reviewers with concrete change details
3. Peer Review: Team members review both the code changes and the planned infrastructure impact
4. Automated Validation: CI/CD pipelines run automated tests, policy checks, and security scans
5. Approved Deployment: Merged pull requests trigger controlled deployments through terraform apply

Audit Trails Through Version Control

Every infrastructure change becomes a permanent record in your Git repository. Compliance auditors can trace any resource back to:

• The specific commit that created or modified it
• The author who proposed the change
• The reviewers who approved it
• The timestamp when it was deployed
• The business justification in the pull request description

This level of traceability satisfies audit requirements for SOX, HIPAA, PCI DSS, and other compliance frameworks without requiring separate documentation systems.

Policy Enforcement Through Automation

OpenMetal’s infrastructure operates from Tier III facilities with HIPAA compliance, SOC 2, and ISO certifications. Terraform extends these baseline protections through automated policy enforcement:

# Enforce encryption for all Ceph volumes
resource "openstack_blockstorage_volume_v3" "encrypted_volume" {
  name        = var.volume_name
  size        = var.volume_size
  volume_type = "ceph-nvme-encrypted"
  
  lifecycle {
    precondition {
      condition     = contains(["ceph-nvme-encrypted", "ceph-hdd-encrypted"], var.volume_type)
      error_message = "All volumes must use encrypted storage types."
    }
  }
}

CI/CD pipelines can enforce additional policies around resource tagging, cost controls, network security groups, and access controls, preventing non-compliant infrastructure from reaching production.

Integration with Security Frameworks

Terraform configurations integrate with security scanning tools, policy engines like Open Policy Agent, and compliance frameworks. Your infrastructure code becomes the single source of truth for security audits, vulnerability assessments, and compliance reporting.

Why This Matters for Your Business

The combination of Terraform and OpenMetal’s Hosted Private Cloud addresses real business challenges that extend beyond technical implementation details.

Consistency Eliminates Configuration Drift

Every organization struggles with environment drift—the gradual divergence between environments that should remain identical. Development works differently than staging, staging differs from production, and disaster recovery environments become stale and untested.

Terraform’s state management ensures your environments remain consistent across their entire lifecycle. When you deploy the same Terraform configuration to multiple environments, you get identical infrastructure configurations backed by OpenMetal’s consistent hardware and software stack.

Disaster Recovery Becomes Operational

Traditional disaster recovery plans collect dust until emergencies arise, at which point teams discover outdated procedures, missing dependencies, and incomplete backups. Business continuity becomes a hope rather than a guarantee.

With Terraform managing your OpenMetal infrastructure, disaster recovery transforms into a standard deployment operation. Your infrastructure definitions, stored in version control, can recreate your entire environment on new OpenMetal Cloud Core clusters within minutes of a disaster declaration.

Compliance Shifts from Overhead to Automation

Compliance requirements often feel like obstacles to business agility, requiring lengthy approval processes, manual documentation, and extensive audit preparation. Teams delay changes to avoid compliance overhead, reducing their ability to respond to market demands.

Terraform workflows embed compliance controls directly into your development process. Pull request approvals satisfy change management requirements, automated policy checks prevent security violations, and Git history provides complete audit trails. Compliance becomes a natural byproduct of your standard development workflow rather than additional overhead.

Hybrid Infrastructure Flexibility

Many organizations want the control of private infrastructure with the flexibility to integrate public cloud services for specific use cases. Traditional approaches require managing multiple toolsets, learning different APIs, and maintaining separate processes for each environment.

Terraform’s multi-provider architecture allows you to manage OpenMetal private infrastructure alongside AWS, Azure, or Google Cloud resources through consistent workflows. Your team learns one tool and applies it across your entire hybrid infrastructure portfolio.

Conclusion

Terraform serves as a control layer that transforms OpenMetal’s Hosted Private Cloud from infrastructure into code. While OpenStack Heat provides native orchestration and Ansible offers configuration management capabilities, Terraform’s declarative model and multi-provider ecosystem align particularly well with modern infrastructure requirements.

The combination delivers measurable business value: consistent environments that eliminate configuration drift, disaster recovery procedures that work when needed, compliance processes that accelerate rather than hinder development, and hybrid infrastructure management through unified tooling.

OpenMetal’s Cloud Core provides the stable foundation—hyperconverged OpenStack and Ceph delivering compute, networking, and storage in 45 seconds. Terraform provides the control layer that turns this foundation into repeatable, auditable, and compliant infrastructure solutions.

Schedule a Meeting

Works Cited

1. HashiCorp. “What is Infrastructure as Code.” HashiCorp Resources, https://www.hashicorp.com/resources/what-is-infrastructure-as-code. Accessed 3 Sept. 2025.
2. OpenStack Foundation. “Heat Documentation.” OpenStack Documentation, https://docs.openstack.org/heat/latest/. Accessed 3 Sept. 2025.
3. Red Hat. “Ansible OpenStack Collection.” Ansible Documentation, https://docs.ansible.com/ansible/latest/collections/openstack/cloud/index.html. Accessed 3 Sept. 2025.
4. Terraform. “OpenStack Provider Documentation.” Terraform Registry, https://registry.terraform.io/providers/terraform-provider-openstack/openstack/latest. Accessed 3 Sept. 2025.

Explore More on Our Blog