Terraform provider reference / guides / lifecycle

A project end to end

The same run as the API guide A server from start to finish, written as one configuration. Read it before you let a pipeline create and destroy servers on its own: the interesting part is not the creation, it is what stays behind after destroy.

The configuration

resource "fiberax_network" "backend" {
  name = "backend"
  cidr = "10.42.0.0/24"
}

resource "fiberax_server" "app" {
  name           = "app-01"
  server_type_id = 4
  image          = data.fiberax_images.os.images[0].id

  cores     = 2
  memory_mb = 4096
  disk_gb   = 40

  public_ipv4 = { reuse = true }
  ssh_keys    = [fiberax_ssh_key.laptop.id]
}

# The private card is its own resource: a server may have several, and each one
# is managed separately.
resource "fiberax_network_interface" "app_backend" {
  server_id  = fiberax_server.app.id
  network_id = fiberax_network.backend.id
}

resource "fiberax_server_firewall" "app" {
  server_id = fiberax_server.app.id
  enabled   = true

  policy_in  = "drop"   # anything not allowed below is dropped
  policy_out = "accept" # outbound traffic is not restricted

  # The rule set is ONE field, replaced as a whole, and the order in it is the
  # order the platform checks: the first matching rule wins.
  rules = [
    {
      direction        = "in"
      action           = "accept"
      protocol         = "tcp"
      destination_port = "22"
      description      = "ssh"
    },
    {
      direction        = "in"
      action           = "accept"
      protocol         = "tcp"
      destination_port = "80,443"
      description      = "web"
    },
  ]
}

resource "fiberax_server_backup_policy" "app" {
  server_id = fiberax_server.app.id
  enabled   = true
  days      = ["mon", "wed", "fri"]
  hour      = 2
  minute    = 0

  # `keep` is read-only here: how many backups are kept comes from the product,
  # and writing it is refused as an unknown field.
}

What the order looks like

Terraform works out the order from the references, and there is nothing to arrange by hand: the card waits for both the network and the server, the firewall and the policy wait for the server. A private network takes about a minute to appear on the platform, and the provider waits for it, so the first apply of a new network is the slowest step of the run.

What destroy does not remove

This is the part worth reading twice.

• A public address outlives the server. If the address was taken with reuse = true or new = true inside fiberax_server, destroying the server releases the card but not the address: it stays in the project and stays billed. Manage addresses as their own resource (fiberax_ip) when you want destroy to take them with it.
• Backups outlive the server too. A backup policy is a schedule, not the archives it produced; removing the policy stops future backups and keeps the ones already taken.
• A network with servers still on it refuses to go. Terraform destroys the cards first because they depend on it, so this only bites when something outside the configuration is still attached.

Reading the plan

Two habits save time:

• terraform plan reads the data sources, so it also proves the token and the mirror work. Run it before you write the rest of the configuration, not after.
• A change that the platform cannot make in place shows up as replacement. Server type, image and the set of GPU cards are like that: they are chosen once, and a different value means a different server.
• The firewall rule set is a single field. Writing rules = [] is not the same as leaving the field out - an empty list means "remove every rule", and the field is required precisely so that a forgotten one cannot mean that by accident.

Generated from the provider schema for version 0.3.0. How to install the provider: Terraform provider.