1.Infrastructure as Code

Ein einzigerTerraform-Root orchestriert vier Komponenten: Credentials,Cloud-init-Payloads, VM-Start und User-Provisionierung. Ihr Hub lebt vollständig in Ihrem Cloud-Account. Wir veröffentlichen alle Module in der Terraform Registry, mit provider-spezifischen Varianten für Ihre bevorzugte Cloud.

module "flexpair" {
  source        = "Flexpair/flexpair/<ihre-cloud>"
  region        = "eu-central-1"
  desktop_count = 5
  admin_email   = "sie@example.com"
}

2.Persistent, nicht ephemer, und so viele Sie möchten

Desktop-VMs laufen durch. Ihre Jupyter-Kernel, langlaufende Trainings, SSH-Tunnel, sogar der Scrollback Ihres Terminals: alles morgen und nächste Woche noch da. Wenn ein Teammitglied die Sitzung öffnet, wurde nichts zurückgesetzt. Ziehen Sie einen Desktop pro Projekt hoch, einen pro Engineer oder einen pro Training-Run; der Hub skaliert auf das, was Ihr Team braucht.

Die durchgängige Uptime eines Hubs ist durch das TLS-Zertifikat begrenzt, mit dem er provisioniert wurde. Wir beziehen 90-Tage-Wildcard-Zertifikate von Let's Encrypt über DNSimple, das 30 Tage vor Ablauf automatisch erneuert. Ein Hub wird also mitzwischen 30 und 90 Tagen TLS-Gültigkeit ausgerollt, abhängig davon, wo im Erneuerungszyklus Sie terraform apply ausführen. Vor Ablauf des aktuellen Zertifikats rollt die Pipeline einen frischen Hub mit dem erneuerten Zertifikat aus; persistente Daten-Volumes tragen den Sitzungszustand hinüber.

3. Geteilter Cursor pro Desktop, ein Sprachkanal über den ganzen Hub

Aufgesetzt auf Apache Guacamole mit einem Shared-Cursor-Protokoll. Auf einem beliebigen Desktop steuern alle Anwesenden dieselbe Maus und Tastatur. Mumble läuft als durchgehenderSprachkanal über den gesamten Hub. Kein „Unmute zum Beitreten“, kein Video-Rauschen. Einfach in einen Desktop einsteigen und loslegen.

4. Ihre Daten, Ihr Perimeter

Keine Daten laufen durch Flexpair-Infrastruktur. Authentifizierung läuft über Ihren IdP. Traffic ist Ende-zu-Ende mit Wildcard-TLS verschlüsselt. Weil Sie die VMs besitzen, bleiben Compliance-Bereiche (DSGVO, SOC 2, ISO 27001) innerhalb der Grenzen, die Sie schon geprüft haben.

5. Deploy-Zeit, auf die Sie sich verlassen können

Über die letzten 17 Produktions-Applies auf Terraform 1.14 hinweg dauerte ein kompletter Hub-Rollout im Mittel 967 s (≈ 16 Minuten) mit einer Standardabweichung von 64 s (≈ 1 Minute). Das 95 %-Prognose Intervall für Ihren nächsten terraform apply liegt bei 14,0 bis 18,2 Minuten. Das ist die gesamte Pipeline: Credentials, Cloud-init-Rendering, VM-Start auf AWS und Guacamole-User-Provisionierung, Ende zu Ende.

Historischer Kontext: Frühere Terraform-Versionen (1.5.7, 1.9.8) brauchten im Schnitt 24 bis 28 Minuten mit Ausschlägen von mehreren Minuten pro Run. Die 1.13- und 1.14-Reihe halbierte das und machte das Ergebnis so vorhersagbar, dass ein Deploy-Fenster in eine einzige Kaffeepause passt.