Selbst gehostete Einrichtung

Der Provider funktioniert mit Ihrer eigenen Status200-Instanz so, wie er mit Status200 Cloud funktioniert: dieselben Ressourcen, dieselben Attribute und dieselben API-Schlüssel des Projekts. Was Sie selbst festlegen: die Adresse Ihrer Status200-Instanz, die passende Provider-Version und, wo Sie sie brauchen, einen Spiegel für Rechner ohne Internetzugang und das Vertrauen in eine private Zertifizierungsstelle.

Den Provider auf Ihre Status200-Instanz richten#

Setzen Sie status200_url auf die Adresse, unter der Sie das Dashboard öffnen: das Schema und den Host, ohne Pfad. Der Provider ergänzt https://, wenn die Adresse kein Schema hat, und /api am Ende, sodass https://status200.example.com jede Anfrage an https://status200.example.com/api schickt.

terraform {
  required_providers {
    oneuptime = {
      source  = "oneuptime/status200"
      version = ">= 14.0, <= 14.0.88"
    }
  }
}

provider "oneuptime" {
  status200_url = "https://status200.example.com"
  # The API key comes from the STATUS200_API_KEY environment variable.
}

Die Adresse kann stattdessen aus der Umgebungsvariablen STATUS200_URL kommen, sodass eine Konfiguration auf mehrere Installationen zeigen kann:

export STATUS200_URL="https://status200.example.com"
export STATUS200_API_KEY="<your-api-key>"

Die Adresse ist der Host, unter dem Ihre Installation ausgeliefert wird: HOST und HTTP_PROTOCOL in config.env bei Docker Compose, und host und httpProtocol in den Werten des Helm-Charts.

Der Schlüssel ist ein API-Schlüssel des Projekts, das Sie verwalten, angelegt im Dashboard Ihrer Status200-Instanz unter Projekteinstellungen → Erweitert → API-Schlüssel, wie in Status200 Cloud. Der Master-API-Schlüssel einer selbst gehosteten Status200-Instanz gehört zu keinem Projekt, daher scheitert ein Anlegen mit ihm an ProjectId required.

Die Provider-Version wählen#

Verwenden Sie den neuesten veröffentlichten Provider, der nicht neuer ist als Ihre Status200-Instanz. Die Versionen des Providers folgen denen von Status200: Ein Status200-Release, das den Provider ändert, veröffentlicht ihn unter der eigenen Versionsnummer des Releases, und ein Provider, der neuer ist als Ihre Status200-Instanz, kann Einstellungen senden, die Ihre Instanz noch nicht hat.

Schreiben Sie also einen Bereich, der bei der Version Ihrer Status200-Instanz endet, wie es das Dashboard tut. Der Block oben nimmt >= 14.0, <= 14.0.88, den Bereich für die Status200-Instanz, von der diese Dokumentation kommt: Lesen Sie sie auf Ihrer eigenen Status200-Instanz, ist dieser Bereich Ihrer. Andernfalls tragen Sie Ihre eigene Version ein:

1. Die Version Ihrer Status200-Instanz ermitteln#

   Fragen Sie Ihre Status200-Instanz danach:

   Bash

   curl https://status200.example.com/version

   Die Antwort ist JSON, etwa {"version":"14.0.40","commit":"..."}. Als Master-Administrator können Sie auch die Editionsbezeichnung im Kopf des Admin-Dashboards öffnen: siehe Ihre aktuelle Version ermitteln.

2. Sie in den Bereich eintragen#

   Der Bereich beginnt bei der Hauptversion und endet bei Ihrer. Für eine Status200-Instanz 14.0.40:

   main.tfHCL

   terraform {
     required_providers {
       oneuptime = {
         source  = "oneuptime/status200"
         version = ">= 14.0, <= 14.0.40"
       }
     }
   }

   Terraform nimmt den neuesten Provider im Bereich. Ein Status200-Release, das den Provider nicht geändert hat, veröffentlicht keinen, und der Bereich überspringt die Versionen, die es nicht gibt.

3. Den Provider herunterladen#

   Führen Sie terraform init aus. Es gibt die installierte Version aus und hält sie in .terraform.lock.hcl fest.

Bei einem Upgrade aktualisieren Sie zuerst Status200. Dann heben Sie das Ende des Bereichs auf die neue Version an und führen terraform init -upgrade aus.

Ohne Internetzugang#

Wenn die Rechner, auf denen Terraform läuft, die Registry nicht erreichen, kopieren Sie den Provider einmal in Ihr Netzwerk und richten Terraform auf die Kopie.

1. Den Provider spiegeln#

   Laden Sie auf einem Rechner mit Internetzugang, in einem Ordner mit Ihrer Konfiguration, den Provider für jede Plattform herunter, auf der Ihre Rechner laufen. Ohne -platform lädt der Befehl den Provider nur für seine eigene Plattform herunter:

   TerraformOpenTofu

   Terraform

   Bash

   terraform providers mirror -platform=linux_amd64 -platform=darwin_arm64 /srv/terraform-mirror

   OpenTofu

   Bash

   tofu providers mirror -platform=linux_amd64 -platform=darwin_arm64 /srv/terraform-mirror

   Der Ordner enthält den Provider unter der Adresse der Registry, etwa registry.terraform.io/status200/status200/. Kopieren Sie ihn in Ihr Netzwerk.

2. Terraform auf den Spiegel richten#

   Schreiben Sie eine CLI-Konfigurationsdatei, die den Status200-Provider aus dem Ordner installiert, und alles andere wie gewohnt:

   TerraformOpenTofu

   Terraform

   mirror.tfrcHCL

   provider_installation {
     filesystem_mirror {
       path    = "/srv/terraform-mirror"
       include = ["registry.terraform.io/status200/status200"]
     }
     direct {
       exclude = ["registry.terraform.io/status200/status200"]
     }
   }

   OpenTofu

   mirror.tfrcHCL

   provider_installation {
     filesystem_mirror {
       path    = "/srv/terraform-mirror"
       include = ["registry.opentofu.org/status200/status200"]
     }
     direct {
       exclude = ["registry.opentofu.org/status200/status200"]
     }
   }

   Nennen Sie sie in TF_CLI_CONFIG_FILE, das sowohl Terraform als auch OpenTofu lesen: export TF_CLI_CONFIG_FILE=/etc/terraform/mirror.tfrc.

3. Initialisieren#

   Führen Sie terraform init aus: Es installiert den Provider aus dem Spiegel. Es warnt, dass die Lock-Datei nun nur Prüfsummen für diese Plattform hat. Um sie für jede Plattform festzuhalten, führen Sie terraform providers lock mit denselben -platform-Optionen auf dem Rechner mit Internetzugang aus, und committen Sie .terraform.lock.hcl mit Ihrer Konfiguration.

Spiegeln Sie erneut, wann immer Sie den Versionsbereich anheben.

TLS und Zertifikate#

Der Provider prüft das Zertifikat Ihrer Status200-Instanz gegen den Zertifikatsspeicher des Rechners, auf dem Terraform läuft, und es gibt keine Einstellung, die die Prüfung überspringt. Stammt das Zertifikat von einer privaten Zertifizierungsstelle, fügen Sie diese Stelle dem Zertifikatsspeicher jedes Rechners und CI-Runners hinzu, der Terraform ausführt:

sudo cp my-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

sudo cp my-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Unter Linux, wo Sie den Zertifikatsspeicher nicht ändern können, etwa in einem CI-Container, setzen Sie SSL_CERT_FILE auf eine Datei, die Ihre Zertifizierungsstelle und die öffentlichen enthält. Unter macOS und Windows fügen Sie die Stelle dem Zertifikatsspeicher des Systems hinzu.

• Proxys. Der Provider schickt seine Anfragen über den Proxy in HTTPS_PROXY, außer an die Hosts in NO_PROXY. Ein Reverse-Proxy vor Status200 muss jeden /api-Pfad und den Header APIKey unverändert durchlassen.
• Einfaches HTTP. Eine http://-Adresse funktioniert, für eine Testinstallation. Der API-Schlüssel reist mit jeder Anfrage, verwenden Sie also für alles andere HTTPS.

Fehlerbehebung#

Fehlerbehebung nennt die anderen Fehler, und was jeder bedeutet.

Nächste Schritte#