Hetzner Cloud Terraform Provider

repository·main·Indexed 20 days ago

https://github.com/hetznercloud/terraform-provider-hcloud

The Hetzner Cloud Terraform Provider allows users to manage Hetzner Cloud resources using Terraform or OpenTofu HCL configuration. It supports resources and data sources for managing certificates, datacenters, and server actions such as power-off, power-on, reboot, and reset.

Tokens
56K
Snippets
173
Records
274
Agent score
69%

What's inside terraform-provider-hcloud

  1. Manage Hetzner Cloud servers with hcloud_server

    main

    The hcloud_server resource allows you to create, modify, and delete Hetzner Cloud servers. It supports provisioning via Cloud-Init and managing network attachments, primary IPs, and disk settings.

    resource "hcloud_server" "node1" {
      name        = "node1"
      image       = "debian-12"
      server_type = "cx23"
      public_net {
        ipv4_enabled = true
        ipv6_enabled = true
      }
    }
  2. Configure Primary IPs for hcloud_server

    main

    By default, if no public_net block is defined, Hetzner Cloud automatically creates and assigns two primary IPs (one IPv4 and one IPv6) to the server.

    You can use the public_net block to customize this behavior:

    • Enable/Disable IPs: Use ipv4_enabled and ipv6_enabled.
    • Link existing IPs: Use the ipv4 or ipv6 keys to link a specific hcloud_primary_ip ID.

    Examples:

    Assign existing IPv4 only:

    public_net {
      ipv4_enabled = true
      ipv4         = hcloud_primary_ip.primary_ip_1.id
      ipv6_enabled = false
    }

    Link managed IPv4 but autogenerate IPv6:

    public_net {
      ipv4_enabled = true
      ipv4         = hcloud_primary_ip.primary_ip_1.id
      ipv6_enabled = true
    }

    Assign & create auto-generated IPv4 & IPv6:

    public_net {
      ipv4_enabled = true
      ipv6_enabled = true
    }
  3. Handle SOA records in hcloud_zone_rrset

    main

    SOA (Start of Authority) records are managed automatically by the Hetzner Cloud API when a parent Zone is created or deleted. Because of this, the hcloud_zone_rrset resource behaves differently for SOA types:

    • Importing: It will import the RRSet into the state instead of creating it.
    • Deleting: It will remove the RRSet from the state instead of deleting it.
    • Serial Value: You must set the SOA record SERIAL value to 0 in your configuration. The API automatically increments this value, and using a non-zero value can cause inconsistent state errors.
    resource "hcloud_zone_rrset" "example_soa" {
      zone = hcloud_zone.example.name
      name = "@"
      type = "SOA"
      records = [
        # Ensure the SERIAL value (the 4th number) is 0
        { value = "hydrogen.ns.hetzner.com. dns.hetzner.com. 0 86400 10800 3600000 3600" }
      ]
    }
  4. How to implement TLS termination vs TLS passthrough

    main

    In Hetzner Cloud, TLS behavior is determined by the service protocol rather than a dedicated toggle:

    TLS Termination

    Use this when you want the Load Balancer to decrypt traffic. This allows the Load Balancer to inspect traffic for features like sticky sessions, HTTP-to-HTTPS redirects, and HTTP health checks.

    • Set protocol = "https".
    • Attach certificates using the certificates field within the http block.

    TLS Passthrough

    Use this when you want the Load Balancer to forward raw encrypted traffic directly to your targets. The targets must handle TLS decryption themselves.

    • Set protocol = "tcp".
    • Forward the standard TLS port (usually 443).
    • Note: HTTP-level features (like cookie-based sticky sessions) are unavailable because the traffic remains encrypted.
    # TLS Termination Example
    resource "hcloud_load_balancer_service" "tls_termination" {
      load_balancer_id = hcloud_load_balancer.load_balancer.id
      protocol         = "https"
      listen_port      = 443
      destination_port = 80
    
      http {
        certificates = [hcloud_managed_certificate.cert.id]
      }
    }
    
    # TLS Passthrough Example
    resource "hcloud_load_balancer_service" "tls_passthrough" {
      load_balancer_id = hcloud_load_balancer.load_balancer.id
      protocol         = "tcp"
      listen_port      = 443
      destination_port = 443
    }
  5. Configure Health Checks for Load Balancer services

    main

    Health checks ensure targets are responsive. A health_check configuration includes:

    • protocol (string): Protocol used for the check (http, https, or tcp).
    • port (int): Port to connect to (1-65535).
    • interval (int): Interval between checks in seconds.
    • timeout (int): Timeout for the check in seconds.
    • retries (int): Number of failed tries before a target is marked unhealthy.
    • http (list): HTTP-specific configurations (required if protocol is http or https).

    HTTP Health Check specific fields:

    • domain (string): Domain to access during the check.
    • path (string): Path to access during the check.
    • response (string): Expected string in the target response.
    • tls (bool): Enable TLS certificate checking.
    • status_codes (list[int]): List of expected HTTP status codes. If the target returns anything else, it is marked unhealthy.
  6. Fetch details about a Hetzner Cloud volume using hcloud_volume

    main

    The hcloud_volume data source allows you to retrieve information about an existing Hetzner Cloud volume. This is particularly useful when you need to reference a volume that was created outside of your current Terraform configuration (e.g., manually via the Hetzner Cloud Console or via a different automation tool).

    data "hcloud_volume" "volume_1" {
      id = "1234"
    }
    
    data "hcloud_volume" "volume_2" {
      name = "my-volume"
    }
    
    data "hcloud_volume" "volume_3" {
      with_selector = "key=value"
    }
  7. Understand Load Balancer service configurations

    main

    The service attribute defines the protocols and ports the Load Balancer listens on. Each service supports:

    • protocol (string): Protocol of the service. Supported values are http, https, or tcp.
    • listen_port (int): Port the service listens on (1-65535). Must be unique per Load Balancer.
    • destination_port (int): Port the service connects to on the targets (1-65535).
    • proxyprotocol (bool): Whether to enable proxyprotocol.
    • http (list): List of HTTP configurations (required if protocol is http or https).
    • health_check (list): List of health check configurations (required if protocol is http or https).
  8. Manage Hetzner Cloud Floating IPs with hcloud_floating_ip

    main

    The hcloud_floating_ip resource allows you to provision a publicly-accessible static IP address. This IP can be mapped to a specific server or assigned to a home location to optimize routing. You can choose between ipv4 and ipv6 types.

    resource "hcloud_server" "node1" {
      name        = "node1"
      image       = "debian-12"
      server_type = "cx23"
    }
    
    resource "hcloud_floating_ip" "master" {
      type      = "ipv4"
      server_id = hcloud_server.node1.id
    }
  9. Access volume details from hcloud_volumes

    main

    The hcloud_volumes data source returns a volumes attribute, which is a list of all matching volume objects. Each object in the list follows the schema defined in the hcloud_volume (singular) data source.

    # Example of accessing an attribute from the returned list
    data "hcloud_volumes" "example" {
      with_selector = "environment=production"
    }
    
    output "first_volume_id" {
      value = data.hcloud_volumes.example.volumes[0].id
    }
  10. How delete protection works in Hetzner Cloud

    main

    The Hetzner Cloud API supports resource locking to prevent accidental deletion. For resources that support it, you can use the delete_protection argument in Terraform.

    Important Limitations:

    • delete_protection does not protect a resource from being deleted by Terraform itself. The provider will automatically lift the lock when performing a Terraform destruction.
    • To prevent Terraform from destroying a resource, use the standard Terraform prevent_destroy lifecycle attribute.
  11. Understanding experimental features

    main

    Experimental features (e.g., products in public beta) are included in regular provider releases.

    Key characteristics:

    • Breaking Changes: Breaking changes may occur within minor releases.
    • Stability: The stability of these features is independent of the upstream Hetzner Cloud API stability.
    • Maturity Levels: Features are categorized by maturity (e.g., experimental, alpha, beta) based on the upstream API.
    • Identification: You can identify experimental features by looking for a specific notice in the resource documentation, such as: Experimental: $PRODUCT is $MATURITY, breaking changes may occur within minor releases.