Wie bereits in den Blogposts zu unserem Cloud-Plattform-Team erwähnt, sehen wir uns mit unseren gebündelten Services (Cloud Services, K8S, Source Control System & CI/CD) als zentraler Dienstleister für unsere EntwicklerInnen. Ein zentrales Thema ist dabei die grundsätzliche Heranführung unserer EntwicklerInnen an unsere angebotenen Cloud-Lösungen. Neben der reinen Wissensvermittlung zur Azure Cloud in Form von Schulungen und Tutorials sollte man in unseren Augen manche Lösungen und Produkte einfach mal anschauen und ausprobieren können, um festzustellen, welche Cloud-Komponenten für die Umsetzung in einem Projekt geeignet sind. Darüber hinaus liefert Microsoft, wie alle Cloud-Anbieter, sehr regelmäßig neue Komponenten, die auch wir im Team erst einmal genau untersuchen möchten, um Konfigurationseinstellungen und Ablauffolgen durchzu"spielen", ohne den laufenden Betrieb zu stören.

Wir halten eine solche Sandbox für unverzichtbar, um uns und unseren EntwicklerInnen ein ungezwungenes Ausprobieren der Azure-Komponenten und -Lösungen zu ermöglichen. Im Folgenden wollen wir die grundlegenden Überlegungen darstellen und erklären, wie wir diese dedizierte Sandbox aufgebaut haben.

Ein paar Regeln zuerst

Im ersten Schritt haben wir einige einfache grundlegende Regeln, im Sinne eines “common sense” festgelegt, um den Benutzer im Übrigen viele Freiräume einzuräumen.

• Jeder kann Zugang zur Sandbox bekommen.
• Es existieren keinerlei produktive Daten oder Anbindungen an produktive Systeme.
• Jede Komponente kostet Geld, geht vernünftig mit den Ressourcengrößen um!
• Jeder sieht die Ressourcen von jedem und kann alles verändern.
• Jeden Freitagabend wird alles gelöscht.

Technische Umsetzung

Technisch haben wir die Sandbox in Azure in einer eigenen Subscription untergebracht, sodass Rechte und Kosten gut zu separieren sind.

Subscriptions habe alle eine eigene Rechnung und sind Teil der von Azure vorgegebenen Struktur. In der Subscription müssen erst Ressourcegruppen angelegt werden, was jeder Benutzer in der Sandbox selbst machen kann. Sie sind ähnlich wie im Filesystem ein Verzeichnis, eine Klammer um mehrere Ressourcen, die einen gemeinsamen Kontext haben.

Ressourcen verstehen wir in diesem Kontext als Überbegriff für alle Arten von Komponenten, die der Marketplace von Microsoft zur Verfügung stellt, wie z.B. Storage, Datenbanken, VMs, Cluster, Netze usw. Auf der Sandbox haben alle die gleichen Rechte (“Contributor”) und können nicht selbst Berechtigungen vergeben. Das reduziert die Komplexität und ist für den Test von Komponenten auch gar nicht nötig.

Housekeeping - Freitagabend ist alles weg

Um manuelle Aufwände zu vermeiden, werden alle Inhalte auf der Sandbox ohne weitere Ankündigung am Freitagabend vollständig löscht. Damit sollen vergessene Ressourcen bereinigt und entsprechende Kosten auf ein Minimum reduziert werden. Unsere Erfahrungen haben gezeigt, dass allzu leicht eine Komponente erstellt und auf der Sandbox vergessen wird, während die Kostenuhr ansonsten weiter tickt.

Diese Logik ist mit einer trivialen Azure-Function umgesetzt, die man mit einem Schedule laufen lässt. Dabei könnte man sogar Ausnahmen von den Grundregeln (Ressourcengruppen, die längerfristig benötigt werden) unterbringen.

Clean-up.ps1

$subscription = "3caf-xxxxxxx" # Sandbox
$exceptionList = "rg-dvag-long-running-test-tmp", ""

Set-AzContext -Subscription $subscription

$resourceGroups = Get-AzResourceGroup
Write-Host $resourceGroups
Foreach ($resourceGroup in $resourceGroups) {
    if ($exceptionList -match $resourceGroup.ResourceGroupName) {
        Write-output "Keep" $resourceGroup.ResourceGroupName
    } else {
        Write-output "Deleting" $resourceGroup.ResourceGroupName
        Remove-AzResourceGroup $resourceGroup.ResourceGroupName -asjob -force
    }
}

Vertrauen ist gut…

Natürlich haben wir großes Vertrauen zu unseren Entwickerlnnen, aber ein bisschen technische Kontrolle hilft uns dabei, die Sandbox mit minimalem Aufwand nachhaltig sauber zu halten.

Locations einschränken

Für eine Sandbox ist es nicht notwendig, Ressourcen in allen Regionen, die Azure unterstützt, zu deployen. Wir empfehlen daher ein bis zwei sehr große Regionen auszuwählen und nur diese freizugeben. Das kann man sehr einfach über die built-in Policy “Allowed locations” erreichen. Diese lässt sich beim Assignment auf unsere Subscription mit einer Liste von Regionen füttern, die wir erlauben wollen. Aus Transparenzgründen sollte auch ein Fehlertext mit Hinweis auf den Regelverstoß mitgegeben werden.

VM-Größen limitieren

In unseren Augen ist Compute in der Cloud ein größerer Kostentreiber als reiner Speicher. Damit sind z.b. VMs ein Kostenfaktor, der Aufmerksamkeit verdient. Die Skalierungsmöglichkeiten reichen hier von 2 bis 64 vCPUs, was auch mit den entsprechend steigenden Kosten einhergeht. Wir empfehlen daher auch hier, die Anzahl der vCPUs zu limitieren, ohne Erfahrungseinbußen für den Sandboxbetrieb in Kauf nehmen zu müssen. Die Limitierung kann auch hier einfach über die built-in Policy von Microsoft “Allowed virtual machine size SKUs” erfolgen, indem man mit Parametern alle erlaubten CPU-Typen auswählt.

SKUs bei anderen Typen limitieren

Für die Limitierung anderer häufig genutzter Resourcentypen in der Ausbaustufe (SKU) liefert Microsoft nur teilweise Vorgefertigtes, wie z.B für Storage-Accounts. Für andere Fälle besteht die Möglichkeit, sich selbst zu helfen. Azure Policies generell sind dafür sehr mächtig und erlauben bei allen Resourcetypen die Größe der ausgerollten Resource(SKU) einzuschränken.

Resourcetypen limitieren

Last, but not least ist es möglich, generell die erlaubten Resourcentypen zu limitieren. Auf den ersten Blick scheint das dem Zweck einer Sandbox zu widersprechen, aber es gibt Ressourcentypen, die in unseren Augen für einen Benutzer zum “Spielen” tabu sind, wie z.B. das Deployment eines VPN Gateways oder eines Virtual WAN Hubs.

Auch dafür gibt es eine Policy “Allowed resource types”, mit der bestimmte Resourcentypen generell ausgeschlossen werden können.

Wie man hier sieht, verbleiben selbst mit diesen Einschränkungen noch sehr viele Resourcentypen für die Vertestung auf der Sandbox. Diese Policy dient hierbei als Hilfsmittel zur Erstellung individueller Limits. Bei der Umsetzung besteht die grundsätzliche Wahl zwischen einem “White-Listing” (alles, was nicht erlaubt ist, ist verboten) oder einem, hier gezeigten, “Black-Listing” (alles, was nicht verboten, ist erlaubt).

Willkommen auf der Sandbox!

Damit ist es geschafft! Wir haben für unsere EntwicklerInnen eine Umgebung geschaffen, in der sie sich ausgiebig an der Azure-Cloud und ihrem Lösungsportfolio ausprobieren können, ohne Auswirkungen auf den laufenden Betrieb (im gleichen Tenant). Die Sandbox ersetzt dabei nicht die Entwicklung, sondern kann in der Vorphase genutzt werden, um erworbenes Azure-Wissen greifbar zu machen und Ideen auszuprobieren. Gleichzeitig haben wir mit geringem Aufwand ein für alle Beteiligten vorteilhaftes Sicherheitsnetz geschaffen. Tatsächlich haben wir nicht alle der hier vorgestellten möglichen Limitierungen umgesetzt, weil diese weitgehende Kontrolle durch unseren vertrauensvollen Austausch mit unseren EntwicklerInnen auch nicht erforderlich ist.

Die Sandbox hat uns nicht nur durch eine hohe Akzeptanz unserer EntwicklerInnen überzeugt, sondern auch durch einen sehr überschaubaren Kostenrahmen. Die EntwicklerInnen schätzen einfach die Freiheit und Dynamik, schnell etwas anlegen und testen zu können, die sie so in der Welt vor der Cloud nicht hatten.

Unterhaltet Ihr eine solche Sandbox, und wenn ja, was sind Eure Erfahrungen?