Terraform – Overzicht

De Terraform-provider van Status200 beheert je Status200-project als code. Beschrijf monitoren, statuspagina's, bereikbaarheidsbeleid, teams, labels en de andere records van je project in .tf-bestanden, zie met terraform plan wat er verandert en voer de wijziging door met terraform apply. Hij werkt met Status200 Cloud en met een zelf gehoste Status200, en met OpenTofu net zo goed als met Terraform.

Hoe de provider werkt#

De provider is een plug-in die Terraform uit een registry downloadt. Bij terraform apply zet hij elke wijziging in het plan om in een verzoek aan de REST API van Status200, gedaan met een API-sleutel van je project. Terraform houdt in zijn state bij wat het heeft gemaakt, zodat het volgende plan alleen toont wat er sindsdien is veranderd.

Een API-sleutel hoort bij één project en bepaalt wat Terraform daarin mag lezen en wijzigen, dus één configuratie beheert één project. Om er meerdere te beheren, geef je de provider voor elk project een alias.

Voordat je begint#

• Terraform 1.5 of hoger, of OpenTofu 1.6 of hoger. De import-blokken die het dashboard schrijft, hebben deze versies nodig.
• Een API-sleutel van je project. De Snelle start laat zien hoe je er een aanmaakt in Projectinstellingen → Geavanceerd → API-sleutels.
• Op Status200 Cloud het Growth-abonnement of hoger. De API-sleutels van een project werken alleen daarmee.

De provider installeren#

Voeg de provider toe aan een .tf-bestand. terraform init downloadt hem uit de Terraform Registry, en tofu init uit de 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"
}

Houd de sleutel uit je bestanden: exporteer hem voordat je Terraform uitvoert, of geef hem door in een variabele die als sensitive is gemarkeerd. De Volledige handleiding noemt elke manier om de provider zijn sleutel en adres te geven.

Een versie kiezen#

Providerversies volgen die van Status200: provider 14.x wordt gemaakt uit Status200 14.x. De beperking hierboven, ~> 14.0, neemt de nieuwste 14.x-release, en dat is de juiste voor Status200 Cloud. Gebruik op een zelf gehoste Status200 de nieuwste provider die niet nieuwer is dan je Status200: Zelf gehoste installatie laat zien hoe je hem vastzet.

Laat het dashboard het schrijven#

Een resource die je al hebt, hoef je niet met de hand te schrijven. Elke resource in het Status200-dashboard (een monitor, een statuspagina, een workflow, een bereikbaarheidsbeleid en de andere) heeft een sectie Ontwikkelaars in het zijmenu, ingeklapt totdat je hem opent. De pagina Terraform daarin schrijft de configuratie voor je, ingevuld vanuit je eigen project.

1. De resource openen#

   Open de monitor, de statuspagina of de andere resource die je door Terraform wilt laten beheren.

2. De Terraform-pagina openen#

   Open in het zijmenu Ontwikkelaars en daarna Terraform.

3. De configuratie kopiëren#

   De pagina schrijft de configuratie van de resource uit de huidige instellingen, met een import-blok. Een opmerking na elke ID noemt het record waarnaar die verwijst (incident_severity_id = "..." # Critical Incident).

4. Plannen en toepassen#

   Voer terraform plan uit: het toont dat de resource wordt geïmporteerd en dat er niets te wijzigen is. Pas het toe, en vanaf dan beheert Terraform de resource.

Onder de configuratie staat bij Verder bouwen wat mensen vaak naast de resource toevoegen, met een verwijzing naar het adres ervan: een eigenaarsteam voor een incident, een groep monitoren voor een statuspagina, een escalatieregel voor een bereikbaarheidsbeleid.

De lijstpagina's (bijvoorbeeld Incidenten of Monitoren) hebben dezelfde sectie. Daar schrijft de pagina Terraform een nieuwe resource met de velden die de meeste mensen invullen, met de eigen records van je project: een incident met een van je ernstniveaus, een monitor met de criteria die een nieuwe monitor in het dashboard krijgt, gekoppeld aan je statussen. Ze geeft kant-en-klare Veelgebruikte configuraties (een statuspagina met een groep en een monitor, een bereikbaarheidsbeleid dat een team oproept, een wekelijks bereikbaarheidsrooster) en een import-blok voor elke resource die je al hebt (de eerste 100), klaar voor terraform plan -generate-config-out. Beide pagina's geven ook het provider-blok voor je Status200: de juiste status200_url en een versiebeperking die bij je Status200 past.

Geheimen worden nooit op deze pagina's getoond. Als de configuratie er een nodig heeft (bijvoorbeeld de Authorization-header van een monitor), leest ze die uit een Terraform-variabele die als sensitive is gemarkeerd. Geheimen die ze niet nodig heeft, blijven weg, en Terraform laat ze zoals ze in Status200 zijn.

Dezelfde sectie heeft een pagina API, met curl-opdrachten voor de resource, en een pagina AI-assistenten, die Claude, GitHub Copilot of Cursor met de MCP-server verbindt.

Wat je kunt beheren#

De provider heeft een resource voor elk soort record dat je via de Status200-API kunt aanmaken, met de naam status200_<name>. Met deze beginnen de meeste configuraties:

De Terraform Registry toont elke resource met al zijn attributen.

Lezen wat al bestaat#

Elke resource heeft een data source met dezelfde naam, zoals data "status200_label". Een data source leest een record dat deze configuratie niet beheert, bijvoorbeeld een dat in het dashboard is gemaakt. Zoek het op met zijn id, of met zijn andere eenvoudige argumenten: elk argument dat je instelt moet overeenkomen, en precies één record mag met allemaal overeenkomen.

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
}

Geen overeenkomst, of meer dan één, is een fout en geen leeg of willekeurig antwoord. De Volledige handleiding geeft de regels.

Hernoemde resources#

Resourcenamen houden woorden als IoT en vCenter heel: status200_iot_fleet en status200_vcenter, waar oudere providers status200_io_t_fleet en status200_v_center hadden (en hetzelfde voor hun labelregels, eigenaren en feeds). De oude namen werken nog als verouderde aliassen, en een plan dat er een gebruikt, meldt dat. Om over te stappen hernoem je de resource in je configuratie en voeg je een moved-blok toe, waarna Terraform de bestaande resource behoudt in plaats van hem te vervangen:

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

Een resource naar een ander type verplaatsen vereist Terraform 1.8 of hoger. Houd op een oudere engine voorlopig de oude naam: die blijft werken.

Hoe je attributen schrijft#

Attributen volgen de Status200-API, in snake_case:

Twee soorten waarden zijn van de server, en die laat je weg:

• ID's binnen een resource. De stappen en criteria van een monitor, en hun sjablonen voor incidenten en waarschuwingen, hebben ID's die de server geeft en bij elke apply behoudt, zodat incidenten blijven verwijzen naar de criteria die ze hebben geopend.
• Wat de server actueel houdt. De huidige status van een monitor, of wanneer hij voor het laatst een heartbeat ontving, kan veranderen tussen terraform plan en het einde van terraform apply. De provider houdt de geplande waarde aan voor alles wat je niet hebt ingesteld, en de volgende refresh leest die van de server, zodat dit nooit een apply laat mislukken of als wijziging verschijnt.

Hulp krijgen#

• Bugs en functieverzoeken: git.wilix.dev/status200/status200/issues.
• De provider wordt gegenereerd uit de OpenAPI-specificatie van Status200 in de hoofdrepository van Status200. De gepubliceerde providerrepository is alleen-lezen, dus meld problemen in de hoofdrepository.

Volgende stappen#