Panoramica di Terraform

Il provider Terraform di Status200 gestisce il tuo progetto Status200 come codice. Descrivi monitor, pagine di stato, politiche di reperibilità, team, etichette e gli altri record del progetto in file .tf, vedi cosa cambierà con terraform plan e applica la modifica con terraform apply. Funziona con Status200 Cloud e con un'istanza Status200 self-hosted, e con OpenTofu come con Terraform.

Come funziona il provider#

Il provider è un plugin che Terraform scarica da un registry. Con terraform apply trasforma ogni modifica del piano in una richiesta all'API REST di Status200, fatta con una chiave API del tuo progetto. Terraform conserva nel suo stato ciò che ha creato, così il piano successivo mostra solo ciò che è cambiato da allora.

Una chiave API appartiene a un progetto e decide cosa Terraform può leggere e modificare al suo interno, quindi una configurazione gestisce un progetto. Per gestirne diversi, dai al provider un alias per ciascuno.

Prima di iniziare#

• Terraform 1.5 o successivo, oppure OpenTofu 1.6 o successivo. I blocchi import che la dashboard scrive richiedono queste versioni.
• Una chiave API del tuo progetto. L'Avvio rapido mostra come crearne una in Impostazioni del progetto → Avanzato → Chiavi API.
• Su Status200 Cloud, il piano Growth o superiore. Le chiavi API di un progetto funzionano solo con quello.

Installare il provider#

Aggiungi il provider a un file .tf. terraform init lo scarica dal Terraform Registry, e tofu init dall'OpenTofu Registry:

terraform {
  required_providers {
    oneuptime = {
      source  = "oneuptime/status200"
      version = "~> 14.0"
    }
  }
}

provider "oneuptime" {
  # The API key comes from the STATUS200_API_KEY environment variable.
  # On a self-hosted Status200, add your Status200's address:
  # status200_url = "https://status200.example.com"
}

Tieni la chiave fuori dai tuoi file: esportala prima di eseguire Terraform, oppure passala in una variabile marcata sensitive. La Guida completa elenca tutti i modi per dare al provider la sua chiave e il suo indirizzo.

Scegliere una versione#

Le versioni del provider seguono quelle di Status200: il provider 14.x è generato da Status200 14.x. Il vincolo qui sopra, ~> 14.0, prende la release 14.x più recente, che è quella giusta per Status200 Cloud. Su un'istanza Status200 self-hosted, usa il provider più recente che non sia più nuovo della tua istanza: la Configurazione self-hosted mostra come fissarlo.

Lasciala scrivere alla dashboard#

Non devi scrivere a mano una risorsa che hai già. Ogni risorsa della dashboard Status200 (un monitor, una pagina di stato, un workflow, una politica di reperibilità e le altre) ha una sezione Sviluppatori nel menu laterale, chiusa finché non la apri. La sua pagina Terraform scrive la configurazione al posto tuo, compilata con il tuo progetto.

1. Aprire la risorsa#

   Apri il monitor, la pagina di stato o l'altra risorsa che vuoi far gestire a Terraform.

2. Aprire la sua pagina Terraform#

   Nel menu laterale, apri Sviluppatori e poi Terraform.

3. Copiare la configurazione#

   La pagina scrive la configurazione della risorsa dalle sue impostazioni attuali, con un blocco import. Un commento dopo ogni ID nomina il record a cui punta (incident_severity_id = "..." # Critical Incident).

4. Pianificare e applicare#

   Esegui terraform plan: il piano mostra la risorsa che viene importata e niente da modificare. Applicalo, e da quel momento Terraform gestisce la risorsa.

Sotto la configurazione, Per andare oltre propone ciò che spesso si aggiunge accanto alla risorsa, riferendosi a essa con il suo indirizzo: un team proprietario per un incidente, un gruppo di monitor per una pagina di stato, una regola di escalation per una politica di reperibilità.

Le pagine di elenco (per esempio Incidenti o Monitor) hanno la stessa sezione. Lì la pagina Terraform scrive una nuova risorsa con i campi che la maggior parte delle persone compila, usando i record del tuo progetto: un incidente con una delle tue gravità, un monitor con i criteri che un nuovo monitor riceve nella dashboard, collegato ai tuoi stati. Offre Configurazioni comuni già pronte (una pagina di stato con un gruppo e un monitor, una politica di reperibilità che avvisa un team, una rotazione di reperibilità settimanale) e un blocco import per ogni risorsa che hai già (le prime 100), pronto per terraform plan -generate-config-out. Entrambe le pagine danno anche il blocco del provider per la tua istanza Status200: la status200_url giusta e un vincolo di versione adatto alla tua istanza.

I segreti non vengono mai mostrati su queste pagine. Quando la configurazione ne ha bisogno (per esempio l'intestazione Authorization di un monitor), lo legge da una variabile Terraform marcata sensitive. I segreti che non le servono restano fuori, e Terraform li lascia come sono in Status200.

La stessa sezione ha una pagina API, con comandi curl per la risorsa, e una pagina Assistenti IA, che collega Claude, GitHub Copilot o Cursor al server MCP.

Cosa puoi gestire#

Il provider ha una risorsa per ogni tipo di record che puoi creare tramite l'API di Status200, chiamata status200_<name>. Queste sono quelle con cui inizia la maggior parte delle configurazioni:

Il Terraform Registry elenca ogni risorsa con ciascuno dei suoi attributi.

Leggere ciò che esiste già#

Ogni risorsa ha una sorgente dati con lo stesso nome, come data "status200_label". Una sorgente dati legge un record che questa configurazione non gestisce, per esempio uno creato nella dashboard. Cercalo con il suo id, oppure con i suoi altri argomenti semplici: ognuno che imposti deve corrispondere, ed esattamente un record può corrispondere a tutti.

data "status200_monitor_status" "offline" {
  name = "Offline"
}

# Any plain argument works. Set several, and all of them must match.
data "status200_monitor_status" "offline_state" {
  is_offline_state = true
}

Nessuna corrispondenza, o più di una, è un errore e non una risposta vuota o arbitraria. La Guida completa riporta le regole.

Risorse rinominate#

I nomi delle risorse tengono interi parole come IoT e vCenter: status200_iot_fleet e status200_vcenter, dove i provider più vecchi avevano status200_io_t_fleet e status200_v_center (e lo stesso per le loro regole delle etichette, i proprietari e i feed). I vecchi nomi funzionano ancora come alias deprecati, e un piano che ne usa uno lo segnala. Per cambiare, rinomina la risorsa nella tua configurazione e aggiungi un blocco moved: Terraform mantiene la risorsa esistente invece di sostituirla:

# Was: resource "status200_io_t_fleet" "factory"
resource "status200_iot_fleet" "factory" {
  name = "Factory floor"
}

moved {
  from = status200_io_t_fleet.factory
  to   = status200_iot_fleet.factory
}

Spostare una risorsa su un altro tipo richiede Terraform 1.8 o successivo. Con un motore più vecchio, tieni per ora il vecchio nome: continua a funzionare.

Come si scrivono gli attributi#

Gli attributi seguono l'API di Status200, in snake_case:

Due tipi di valori appartengono al server, e li lasci fuori:

• Gli ID dentro una risorsa. I passaggi e i criteri di un monitor, e i loro modelli di incidente e di avviso, hanno ID che il server assegna e conserva a ogni apply, così gli incidenti continuano a puntare ai criteri che li hanno generati.
• Ciò che il server tiene aggiornato. Lo stato attuale di un monitor, o quando ha ricevuto l'ultimo heartbeat, può cambiare tra terraform plan e la fine di terraform apply. Il provider mantiene il valore pianificato per tutto ciò che non hai impostato, e il refresh successivo legge quello del server, così questo non fa mai fallire un apply né compare come modifica.

Ottenere aiuto#

• Bug e richieste di funzionalità: git.wilix.dev/status200/status200/issues.
• Il provider è generato dalla specifica OpenAPI di Status200 nel repository principale di Status200. Il repository pubblicato del provider è in sola lettura, quindi segnala i problemi nel repository principale.

Prossimi passi#