Wissenscheck - Infrastructure as Code
Eine Entwicklerin führt ein ionoscloud_autoscaling_group unter anhaltender Last aus und erhöht die Werte für cores und ram in der Replikationskonfiguration, in der Erwartung, dass die vorhandenen Replikate wachsen. Die laufenden Replikate bleiben gleich groß. Welche Aussage erklärt dieses Verhalten am besten?
VM Auto Scaling skaliert horizontal: Es fügt ganze Serverreplikate hinzu und entfernt sie, anstatt deren Größe anzupassen. Änderungen an der Replikationskonfiguration wirken sich auf neu erstellte Replikate aus, sodass bereits laufende Replikate ihre ursprüngliche Beibehaltung der Größe beibehalten. Um mehr Last zu bewältigen, lässt man die Gruppe durch Hinzufügen von Replikaten skalieren oder ersetzt bestehende Replikate, damit die neue Größenanpassung greift.
Die Anwendungsserver von TaskBoard befinden sich in einem privaten LAN, dem keine öffentliche IP zugewiesen wurde. Sie müssen das Internet erreichen, um Paketaktualisierungen zu installieren und externe APIs aufzurufen, dürfen aber nicht vom Internet aus erreichbar sein. Welche Terraform-Ressource stellt diese nur ausgehende Konnektivität bereit?
Ein NAT-Gateway stellt eine nur ausgehende Internetverbindung bereit. Dadurch können private Server Verbindungen für Aktualisierungen und externe Aufrufe initiieren, bleiben aber vom Internet aus unerreichbar. Die Zuweisung einer ionoscloud_ipblock an jeden Server würde ihnen öffentlichen Eingangsbereich verschaffen, was dem Isolationsanforderung widerspricht, und ein Load Balancer verarbeitet eingehenden Datenverkehr, nicht ausgehenden Datenverkehr aus dem privaten Netz.
Eine Entwicklerin provisioniert einen Managed Kubernetes Node Pool und ein ionoscloud_application_loadbalancer, schreibt anschließend ionoscloud_firewall (NSG)-Regeln und erwartet, dass diese sowohl die Worker Nodes als auch den ALB schützen. Die Regeln scheinen auf NICs von Einzelservern wirksam zu werden, jedoch nicht auf den MKS Nodes oder dem ALB. Warum?
NSGs werden auf VM- oder NIC-Ebene angehängt, und Nodes in Managed Kubernetes Node Pools sind von der NSG-Durchsetzung ausgenommen, ebenso wie der Managed ALB. Um den Datenverkehr zu diesen Ressourcen zu steuern, müssen Sie deren eigene Mechanismen verwenden (zum Beispiel Listener- und Weiterleitungsregeln am ALB), anstatt sich auf NSG-Regeln zu verlassen, die an diese Ressourcen gebunden werden.
Der API-Server von TaskBoard liest Datei-Attachments aus einem ionoscloud_s3_bucket. Die Entwicklerin konfiguriert den S3-Client der Anwendung mit dem Bearer-Token der IONOS CLOUD API, das für den Rest ihrer Terraform-Automatisierung verwendet wird, aber jede Anfrage liefert einen Authentifizierungsfehler. Was ist die korrekte Lösung?
IONOS CLOUD Object Storage bietet eine S3-kompatible API und wird mit einem Access Key und Secret Key Paar authentifiziert, nicht mit dem Bearer-Token, das für die IONOS CLOUD API verwendet wird. Die Entwicklerin sollte ein ionoscloud_s3_key bereitstellen und den resultierenden Access Key und Secret Key dem S3-Client bereitstellen; Bearer-Tokens und Basic Auth funktionieren nicht mit dem S3-Endpunkt.
Eine Entwicklerin provisioniert eine ionoscloud_kafka_cluster und gibt die Bootstrap-Server sowie das Client-Zertifikat aus Terraform aus, damit die Anwendung sich verbinden kann. Welche zwei Praktiken behandeln diese Ausgabe korrekt für eine Produktionsumgebung?
Die Daten-Ebene von IONOS CLOUD Kafka wird mit mTLS authentifiziert, sodass die Anwendung sich mit dem Client-Zertifikat verbindet, nicht mit einem Bearer-Token, Access Key oder Basic Auth. Verbindungszeichenketten, Zugangsdaten und Zertifikate, die aus dem Terraform-Zustand extrahiert werden, sollten als sensibel markiert werden, damit sie nicht in der Plan- oder Apply-Ausgabe offengelegt werden, und dürfen niemals in einem Repository committet werden.