Configuration auto-hébergée

Le fournisseur fonctionne avec votre propre Status200 comme avec Status200 Cloud : les mêmes ressources, les mêmes attributs et les mêmes clés API de projet. Ce qu'il vous revient de définir : l'adresse de votre Status200, la version du fournisseur qui lui correspond et, là où vous en avez besoin, un miroir pour les machines sans accès à internet et la confiance envers une autorité de certification privée.

Pointer le fournisseur vers votre Status200#

Définissez status200_url avec l'adresse à laquelle vous ouvrez le tableau de bord : le schéma et l'hôte, sans chemin. Le fournisseur ajoute https:// quand l'adresse n'a pas de schéma, et /api à la fin, si bien que https://status200.example.com envoie chaque requête à https://status200.example.com/api.

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

L'adresse peut venir plutôt de la variable d'environnement STATUS200_URL, de sorte qu'une configuration peut pointer vers plusieurs installations :

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

L'adresse est l'hôte sur lequel votre installation est servie : HOST et HTTP_PROTOCOL dans config.env avec Docker Compose, et host et httpProtocol dans les valeurs du chart Helm.

La clé est une clé API du projet que vous gérez, créée dans le tableau de bord de votre Status200 sous Paramètres du projet → Avancé → Clés API, comme sur Status200 Cloud. La clé API maîtresse d'un Status200 auto-hébergé n'appartient à aucun projet, donc une création faite avec elle échoue sur ProjectId required.

Choisir la version du fournisseur#

Utilisez le fournisseur publié le plus récent qui n'est pas plus récent que votre Status200. Les versions du fournisseur suivent celles de Status200 : une version de Status200 qui modifie le fournisseur le publie sous son propre numéro de version, et un fournisseur plus récent que votre Status200 peut envoyer des paramètres que votre Status200 n'a pas encore.

Écrivez donc une plage qui se termine à la version de votre Status200, comme le fait le tableau de bord. Le bloc ci-dessus prend >= 14.0, <= 14.0.88, la plage pour le Status200 d'où vient cette documentation : quand vous la lisez sur votre propre Status200, cette plage est la vôtre. Sinon, écrivez votre propre version :

1. Trouver la version de votre Status200#

   Demandez-la à votre Status200 :

   Bash

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

   La réponse est du JSON, comme {"version":"14.0.40","commit":"..."}. En tant qu'administrateur principal, vous pouvez aussi ouvrir l'étiquette d'édition dans l'en-tête du tableau de bord d'administration : voir Trouver votre version actuelle.

2. L'écrire dans la plage#

   La plage commence à la version majeure et se termine à la vôtre. Pour un Status200 14.0.40 :

   main.tfHCL

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

   Terraform prend le fournisseur le plus récent de la plage. Une version de Status200 qui n'a pas modifié le fournisseur n'en publie aucun, et la plage saute les versions qui n'existent pas.

3. Télécharger le fournisseur#

   Exécutez terraform init. Il affiche la version qu'il a installée et l'enregistre dans .terraform.lock.hcl.

Lors d'une mise à jour, mettez d'abord à jour Status200. Montez ensuite la fin de la plage à sa nouvelle version, et exécutez terraform init -upgrade.

Sans accès à internet#

Quand les machines qui exécutent Terraform ne peuvent pas joindre le registre, copiez une fois le fournisseur dans votre réseau, et pointez Terraform vers la copie.

1. Faire un miroir du fournisseur#

   Sur une machine avec accès à internet, dans un dossier contenant votre configuration, téléchargez le fournisseur pour chaque plateforme que font tourner vos machines. Sans -platform, la commande ne télécharge le fournisseur que pour sa propre plateforme :

   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

   Le dossier contient le fournisseur sous l'adresse du registre, comme registry.terraform.io/status200/status200/. Copiez-le dans votre réseau.

2. Pointer Terraform vers le miroir#

   Écrivez un fichier de configuration de la CLI qui installe le fournisseur Status200 depuis le dossier, et tout le reste comme d'habitude :

   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"]
     }
   }

   Nommez-le dans TF_CLI_CONFIG_FILE, que lisent à la fois Terraform et OpenTofu : export TF_CLI_CONFIG_FILE=/etc/terraform/mirror.tfrc.

3. Initialiser#

   Exécutez terraform init : il installe le fournisseur depuis le miroir. Il avertit que le fichier de verrouillage n'a maintenant de sommes de contrôle que pour cette plateforme. Pour les enregistrer pour chaque plateforme, exécutez terraform providers lock avec les mêmes options -platform sur la machine qui a accès à internet, et commitez .terraform.lock.hcl avec votre configuration.

Refaites le miroir chaque fois que vous montez la plage de versions.

TLS et certificats#

Le fournisseur vérifie le certificat de votre Status200 auprès du magasin de confiance de la machine qui exécute Terraform, et aucun paramètre ne permet de sauter la vérification. Quand le certificat vient d'une autorité de certification privée, ajoutez cette autorité au magasin de confiance de chaque machine et de chaque runner de CI qui exécute Terraform :

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

Sous Linux, là où vous ne pouvez pas modifier le magasin de confiance, comme dans un conteneur de CI, définissez SSL_CERT_FILE avec un fichier qui contient votre autorité et les autorités publiques. Sous macOS et Windows, ajoutez l'autorité au magasin de certificats du système.

• Proxys. Le fournisseur envoie ses requêtes par le proxy de HTTPS_PROXY, sauf vers les hôtes de NO_PROXY. Un proxy inverse devant Status200 doit laisser passer sans modification chaque chemin /api et l'en-tête APIKey.
• HTTP simple. Une adresse http:// fonctionne, pour une installation de test. La clé API voyage avec chaque requête, utilisez donc HTTPS pour tout le reste.

Dépannage#

Dépannage contient les autres erreurs, et ce que signifie chacune.

Étapes suivantes#