Cloud Blaster: Google Cloud Projekte einfach aufräumen

Safe Scrub ist ein Projekt, das ich in Bash geschrieben habe. Es erfüllt im Grunde denselben Zweck. Mehr dazu in diesem Blogbeitrag.

Die Vorteile von Safe Scrub:

• Safe Scrub löscht erst einmal gar nichts. Es gibt lediglich ein Bash-Skript mit einer simplen Liste von delete-Anweisungen aus. Das können Sie dann in Ruhe prüfen und nach eigenem Ermessen ausführen.
• Da Safe Scrub reines Bash ist, sehen Sie den ausgeführten Code direkt – ohne Kompilierungsschritt – und das schafft zusätzliches Vertrauen.
• Safe Scrub unterstützt aktuell mehr Asset-Typen als Cloud Blaster.

Cloud Blaster bringt eigene Sicherheitsmechanismen mit, wie Sie weiter unten sehen werden. Es deckt die gängigsten Asset-Typen ab und lässt sich um weitere ergänzen.

Im Vergleich zu Safe Scrub kann Cloud Blaster mit deutlich mehr Komplexität umgehen, denn es ist in Kotlin statt in Bash geschrieben. Das macht es einfacher, neue Asset-Typen und Features zu ergänzen und Sonderfälle sauber abzufangen. Safe Scrub ist an der Komplexitätsgrenze angekommen, die sich in Bash sinnvoll abbilden lässt – viel weiter wird es daher voraussichtlich nicht gehen.

Der Use Case zielt auf Entwicklungs- und informelle Testprojekte, in denen Sie am Ende des Tages oder vor dem nächsten Testlauf wieder bei null anfangen wollen.

Für Produktiv- oder Staging-Umgebungen und auch für gemeinsame Team-Testprojekte ist es weniger geeignet. Dafür sollten Sie Terraform oder ein anderes Infrastructure-as-Code-Tool (IaC) einsetzen, das die erstellten Ressourcen sauber nachhält. Diese können Sie dann gezielt wieder löschen.

Damit alles sicher und kontrolliert abläuft, bringt Cloud Blaster folgende Funktionen mit:

1. Im ersten Schritt löscht der Lister keinerlei Ressourcen. Er trägt sie lediglich in einer Datei zusammen, die Sie prüfen können.
2. Der Lister verlangt die explizite Angabe eines Projekts. Er greift nicht stillschweigend auf Ihr gcloud-Standardprojekt zurück.
3. Der Lister lässt sich filtern. Pro Asset-Typ können Sie einen regulären Ausdruck angeben, sodass nur bestimmte Ressourcen gelistet oder übersprungen werden.
4. Nach dem Lauf des Listers prüfen Sie die Liste der zu löschenden Ressourcen und ergänzen oben die Kommentarzeile # Ready to delete. So stellen Sie sicher, dass der Review-Schritt nicht untergeht. (Wer es gern riskant mag, kann ein Skript schreiben, das diesen Kommentar zwischen Lister- und Deleter-Schritt automatisch einfügt.)
5. Zum Schluss starten Sie den Deleter, der genau die in der Datei gelisteten Ressourcen löscht.

Den Code holen Sie sich per git clone oder als ZIP-Download.

Details und Optionen finden Sie in der README. Kurz zusammengefasst:

• Bearbeiten Sie optional list-filter.yaml, um Ressourcen per Whitelist oder Blacklist in die Löschliste aufzunehmen oder davon auszuschließen.
• Starten Sie den Lister über die Kommandozeile.
• Prüfen Sie die Ausgabedatei asset-list.txt und ergänzen Sie den Kommentar # Ready to delete.
• Starten Sie den Deleter.

Weitere Optionen sehen Sie mit ./lister.sh -h oder ./deleter.sh -h.

Mehr dazu in der Cloud Blaster README

Cloud Blaster unterstützt inzwischen die wichtigsten Asset-Typen, die in Entwicklung und QA typischerweise auf- und wieder abgebaut werden. Dazu zählen:

• Google Compute Engine Instanzen, Disks, Firewalls und Addresses
• Google Cloud PubSub Topics und Subscriptions
• Google Kubernetes Engine regionale und zonale Cluster
• Google Cloud Operations Log Metrics
• Google App Engine Services und Versionen
• Google Cloud Functions
• Cloud Run Services
• Cloud SQL Instanzen
• Google Cloud Storage Buckets

Wenn Sie weitere Asset-Typen oder neue Features brauchen, eröffnen Sie gerne ein Issue auf GitHub – oder ergänzen Sie die Unterstützung selbst und reichen einen Pull Request ein.

Das geht ganz einfach!

Dank der prägnanten Kotlin-Syntax und einer Basis-Deleter-Klasse lässt sich ein Deleter für einen neuen Asset-Typ ohne großen Aufwand ergänzen. Der Rumpf des PubSub-Topic-Deleters umfasst zum Beispiel nur sieben Zeilen. Seit dem ersten Entwurf dieses Artikels habe ich einen für Cloud SQL ergänzt und getestet – in nur 15 Minuten und 13 Codezeilen.

So gehen Sie vor:

• Kommentieren Sie den Asset-Typ in asset-types.properties aus und geben Sie bei Bedarf die Deleter-Klasse an. Hinweise dazu stehen am Anfang der Datei.
• Tragen Sie den Asset-Typ in list-filter.yaml ein. (Wir nutzen zwei getrennte Konfigurationsdateien, da nur eine davon vom Anwender bearbeitet werden soll. Falls Sie diese Datei vergessen, weist Sie eine eindeutige Fehlermeldung darauf hin.) Optional können Sie einen Standardfilter ergänzen, wie im Firewall-Beispiel in der Datei.
• Implementieren Sie eine Unterklasse von BaseDeleter neben den bestehenden Deleter-Klassen. Diese eignen sich gut als Vorlage für den Aufruf der verschiedenen Google Cloud APIs.

• Safe Scrub ist ein älteres Bash-Projekt, das dieselbe Aufgabe übernimmt.
• Travis CI GCloud Cleanup und Bazooka löschen ebenfalls GCE-Ressourcen.
• Cloud Nuke übernimmt das für AWS.
• Sandbox Projects stehen Kunden von DoiT International kostenlos zur Verfügung.

Bleiben Sie mit uns in Kontakt – folgen Sie uns im DoiT Engineering Blog , auf dem DoiT LinkedIn-Kanal und auf dem DoiT Twitter-Kanal . Karrieremöglichkeiten finden Sie unter https://careers.doit-intl.com .