Terraform – Översikt

Status200s Terraform-provider hanterar ditt Status200-projekt som kod. Beskriv monitorer, statussidor, jourpolicyer, team, etiketter och projektets övriga poster i .tf-filer, se med terraform plan vad som kommer att ändras och genomför ändringen med terraform apply. Den fungerar med Status200 Cloud och med ett självhostat Status200, och med OpenTofu lika väl som med Terraform.

Så fungerar providern#

Providern är ett insticksprogram som Terraform hämtar från ett registry. Vid terraform apply gör den om varje ändring i planen till en begäran till Status200s REST API, gjord med en API-nyckel till ditt projekt. Terraform sparar det den har skapat i sin state, så att nästa plan bara visar det som har ändrats sedan dess.

En API-nyckel hör till ett projekt och avgör vad Terraform får läsa och ändra i det, så en konfiguration hanterar ett projekt. För att hantera flera ger du providern ett alias för varje projekt.

Innan du börjar#

• Terraform 1.5 eller senare, eller OpenTofu 1.6 eller senare. De import-block som instrumentpanelen skriver kräver de här versionerna.
• En API-nyckel till ditt projekt. Snabbstart visar hur du skapar en under Projektinställningar → Avancerad → API-nycklar.
• På Status200 Cloud abonnemanget Growth eller högre. Ett projekts API-nycklar fungerar bara på det.

Installera providern#

Lägg till providern i en .tf-fil. terraform init hämtar den från Terraform Registry, och tofu init från 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"
}

Håll nyckeln utanför dina filer: exportera den innan du kör Terraform, eller skicka in den i en variabel som är markerad sensitive. Komplett guide visar alla sätt att ge providern dess nyckel och adress.

Välj en version#

Providerns versioner följer Status200s: provider 14.x byggs från Status200 14.x. Begränsningen ovan, ~> 14.0, tar den senaste 14.x-versionen, och det är rätt för Status200 Cloud. På ett självhostat Status200 använder du den senaste providern som inte är nyare än ditt Status200: Självhostad konfiguration visar hur du låser den.

Låt instrumentpanelen skriva den#

Du behöver inte skriva en resurs som du redan har för hand. Varje resurs i Status200s instrumentpanel (en monitor, en statussida, ett arbetsflöde, en jourpolicy och de andra) har en sektion Utvecklare i sidomenyn, hopfälld tills du öppnar den. Dess sida Terraform skriver konfigurationen åt dig, ifylld från ditt eget projekt.

1. Öppna resursen#

   Öppna monitorn, statussidan eller den andra resurs som du vill att Terraform ska hantera.

2. Öppna dess Terraform-sida#

   Öppna Utvecklare och sedan Terraform i sidomenyn.

3. Kopiera konfigurationen#

   Sidan skriver resursens konfiguration utifrån dess nuvarande inställningar, med ett import-block. En kommentar efter varje ID namnger posten som det pekar på (incident_severity_id = "..." # Critical Incident).

4. Planera och tillämpa#

   Kör terraform plan: den visar att resursen importeras och att inget ska ändras. Tillämpa den, så hanterar Terraform resursen från och med då.

Under konfigurationen har Bygg vidare på den det som folk ofta lägger till bredvid resursen, med en hänvisning till dess adress: ett ägarteam för en incident, en grupp monitorer för en statussida, en eskaleringsregel för en jourpolicy.

Listsidorna (till exempel Incidenter eller Monitorer) har samma sektion. Där skriver sidan Terraform en ny resurs med de fält som de flesta fyller i, utifrån projektets egna poster: en incident med en av dina allvarlighetsgrader, en monitor med de kriterier som en ny monitor får i instrumentpanelen, kopplad till dina statusar. Den ger färdiga Vanliga konfigurationer (en statussida med en grupp och en monitor, en jourpolicy som larmar ett team, ett veckovis jourschema) och ett import-block för varje resurs som du redan har (de första 100), redo för terraform plan -generate-config-out. Båda sidorna ger också provider-blocket för ditt Status200: rätt status200_url och en versionsbegränsning som passar ditt Status200.

Hemligheter visas aldrig på de här sidorna. När konfigurationen behöver en (till exempel en monitors Authorization-header) läser den den från en Terraform-variabel som är markerad sensitive. Hemligheter som den inte behöver utelämnas, och Terraform låter dem vara som de är i Status200.

Samma sektion har en sida API med curl-kommandon för resursen, och en sida AI-assistenter, som ansluter Claude, GitHub Copilot eller Cursor till MCP-servern.

Vad du kan hantera#

Providern har en resurs för varje slags post som du kan skapa via Status200s API, med namnet status200_<name>. De här är de som de flesta konfigurationer börjar med:

Terraform Registry visar varje resurs med alla dess attribut.

Läs det som redan finns#

Varje resurs har en datakälla med samma namn, till exempel data "status200_label". En datakälla läser en post som den här konfigurationen inte hanterar, till exempel en som har skapats i instrumentpanelen. Slå upp den med dess id, eller med dess andra enkla argument: varje argument som du anger måste stämma, och exakt en post får stämma med alla.

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
}

Ingen träff, eller fler än en, är ett fel och inte ett tomt eller godtyckligt svar. Komplett guide har reglerna.

Omdöpta resurser#

Resursnamn håller ihop ord som IoT och vCenter: status200_iot_fleet och status200_vcenter, där äldre providrar hade status200_io_t_fleet och status200_v_center (och detsamma för deras etikettregler, ägare och flöden). De gamla namnen fungerar fortfarande som föråldrade alias, och en plan som använder ett av dem säger det. För att byta döper du om resursen i din konfiguration och lägger till ett moved-block, så behåller Terraform den befintliga resursen i stället för att ersätta den:

# 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
}

Att flytta en resurs till en annan typ kräver Terraform 1.8 eller senare. På en äldre motor behåller du det gamla namnet så länge: det fortsätter att fungera.

Så skrivs attribut#

Attributen följer Status200s API, i snake_case:

Två slags värden tillhör servern, och dem utelämnar du:

• ID:n inuti en resurs. En monitors steg och kriterier, och deras mallar för incidenter och larm, har ID:n som servern ger och behåller vid varje apply, så att incidenter fortsätter att peka på de kriterier som utlöste dem.
• Det som servern håller uppdaterat. En monitors nuvarande status, eller när den senast tog emot ett heartbeat, kan ändras mellan terraform plan och slutet av terraform apply. Providern behåller det planerade värdet för allt som du inte har angett, och nästa refresh läser serverns, så det här får aldrig en apply att misslyckas eller visas som en ändring.

Få hjälp#

• Buggar och önskemål om funktioner: git.wilix.dev/status200/status200/issues.
• Providern genereras från Status200s OpenAPI-specifikation i Status200s huvudrepository. Det publicerade provider-repositoryt är skrivskyddat, så rapportera problem i huvudrepositoryt.

Nästa steg#