Warum das Ganze?
Eine serverseitigen Google Tag Manager (SGTM) zu deployen ist nicht kompliziert, oder? Prinzipiell ist das schnell gemacht, außer man möchte zusätzlich noch ein paar Dinge wie, Service Account anlegen, IAM Rechte vergeben, Logs filtern, Auto-Update Cloud Function deployen und ein paar Uptime-Checks inklusive Alert-Policy anlegen.
Damit wir das nicht immer von Hand machen müssen, wenn wir ein neues Setup aufbauen, können wir auf Terraform zurückgreifen. Terraform ermöglicht uns durch den „Infrastructure as Code“ Ansatz eine Art Rezept zuschreiben, welche Komponenten wir auf welche Weise an welchem Ort deployen wollen.
Da ich in der Praxis häufiger mal neue SGTMs aufsetze, habe ich ein Terraform Script geschrieben, um automatisch folgende Komponenten in der Google Cloud Platform (GCP) zu bereitzustellen:
- Notwendige APIs aktivieren: IAM, Run, Cloud Scheduler, Cloud Build, Cloud Functions, Monitoring
- Service Account mit notwendigen Rechten anlegen: run.invoker, cloudfunctions.invoker,cloudfunctions.serviceAgent
- 2 SGTM Cloud Run Services: Preview + Production
- Logs Exclusion: Ausschuss von Standard Logs für Cloud Run
- Uptime Checks & Alert Policy: Benachrichtungen per E-Mail, falls der Production SGTM nicht erreichbar ist
- Auto Updates: Meine SGTM Update Cloud Function mit Cloud Scheduler automatisiert (8:00 UTC jeden Tag)
Wie funktioniert das?
Als Erstes müsst ihr sicherstellen, dass ihr Terraform und die gcloud CLI installiert habt. Ist das der Fall, muss nur noch das GitHub Repository geklont werden.
Authentifizierung mit der GCP
Für das Deployment müssen wir eine Methode zur Authentifizierung mit der Google Cloud Platform aufsetzen. Häufig lese ich an dieser Stelle von Service Account Keys, die im JSON Format heruntergeladen werden. Hiervon würde ich abraten, denn wenn dieser durch Zufall in falsche Hände gerät, hat die Person Zugriff auf den Service Account und kann diesen dementsprechend nutzen.
Sicherer und aus meiner Sicht einfacher, ist die Nutzung der Application Default Credentials, kurz ADC. Hier wird euer persönlicher Google Account zur Authentifizierung verwendet.
gcloud auth application-default loginEs öffnet sich ein Google Login Fenster, womit ihr euch identifiziert. Voraussetzung für die Nutzung dieser Methode ist natürlich, dass ihr mit euerem Account bereits die notwendigen Rechte in dem GCP Projekt besitzt, in dem ihr die Ressourcen deployen möchtet.
Bei den Rechten gibt es verschiedene Ansätze. Google empfiehlt das „principle of least privelege“ also das Prinzip, nur so wenig Rechte wie nötig zu vergeben. Ich nutze für einmalige Setup Aufgaben häufige die primitiven Rollen, wie z.B. die Editor-Rolle oder in seltenen Fällen auch die Owner-Rolle.
Wie wende ich das Terraform Script an?
Deployment vorbereiten / Variablen anpassen
Das Setup meines Terraform Scripts ist relativ einfach. Ihr müsst als Erstes die Variablen in terraform.tfvars ausfüllen. Hier rüber wird kontrolliert, in welchem GCP Projekt und in welcher Region die Ressourcen deployed werden. Für ein Minimalsetup müssen die Variablen project_id, container_config und notfication_user sowie google_storage_bucket_name angepasst werden.
# Project ID where terraform will build the assests in
project_id = "YOUR_GCP_RPOJECT_ID"
# All resources will be built in this region
region = "europe-west3"
# Container Config string from GTM Webinterface
container_config = "SGTM_CONTAINER_CONFIG"
# The names for the SGTM Cloud Run services
service_name_preview = "sgtm-preview"
service_name_production = "sgtm-production"
# Controls the maximum and minimum instances for Cloud Run service running the production SGTM
min_instance_count = 0
max_instance_count = 1
cpu_boost = true
# DONT Change this - Log filter to trigger alerts when SGTM got updated
cloud_function_update_filter = "resource.type=\"cloud_function\" \nAND textPayload=~\"Versions are different: Deploying a new revision\""
# Update interval for the Cloud Function updating the SGTM Image in unix-cron job format - Default everyday at 8:00 am UTC
update_interval = "0 8 * * *"
# The filter to define which logs will be excluded
cloud_run_exclusion_filter = "resource.type=\"cloud_run_revision\" AND severity = \"INFO\" OR severity =\"DEFAULT\""
# Used for error notfication alerting
notification_user = {
name: "YOUR_NAME"
email: "YOUR_EMAIL"
}
# Used to name the google storage bucket
google_storage_bucket_name = "RANDOM_STRING"Die Variablen für den Cloud Run Exclusion Filter und den Log-Filter für die SGTM Update Benachrichtigung sollten nicht geändert werden.
Infrastruktur deployen
Nach der Vorbereitung müssen wir Terraform initialisieren. Dies machen wir einfach im Terminal unserer Wahl. Bei mir ist das meistens das integrierte Terminal in VS Studio Code.
terraform initDadurch werden die notwendigen Provider heruntergeladen, die für unser Script benötigt werden. In unserem Fall ist das der Provider google, welcher die notwendigen Ressourcen bereitstellt.
Als nächsten können wir unser Deployment planen. Das könnten wir dediziert mit terraform plan machen, aber auch beim Anwenden unseres Scripts werden wir vor der Durchführung nochmal über die geplanten Ressourcen informiert.
terraform applySo bekommen wir eine Übersicht aller Komponenten, die das Terraform Script deployen wird, sofern wir mit „yes“ zustimmen.
Nachdem wir zugestimmt haben, werden die Ressourcen in korrekten Reihenfolge aufgebaut. Dies wird unter anderem durch „depends_on“ in den unterschiedlichen Ressourcen sichergestellt.
Über das Terminal können wir den Fortschritt der verschiedenen Arbeitsschritte verfolgen. Wenn alles erfolgreich umgesetzt wurde, bekommen wir eine Bestätigung über die Anzahl der aufgesetzten Ressourcen.
Natürlich können wir nun auch manuelle Anpassungen an der Komponenten machen und so z.B. die Anzahl der maximalen Instanzen in Cloud Run anpassen, oder weitere Notification Channel wie Slack zu unserem Alert hinzufügen.
Abschließende Worte
Seitdem die GCP einen prominenteren Platz im Digital Analytics Kosmos bekommen hat, werden Ansätze aus der Softwareentwicklung und dem Cloud-Engineering immer wichtiger für unsere Arbeit. Neben den Google Analytics 4 Rohdaten in BigQuery, ist der serverseitige Google Tag Manager in der GCP zu Hause. Das eröffnet uns nicht nur neue Möglichkeiten, sondern zwingt aus auch mal wieder über den Tellerrand zu schauen.
Terraform in Kombination mit GitHub geben uns die Möglichkeit zuverlässig reproduzierbare Setups zu deployen. Gerade bei Arbeitsschritten, die häufig wiederholt werden, bietet sich ein Terraform Script an. Hiermit können wir sicherstellen, dass keine Komponenten vergessen, oder falsch aufgesetzt werden. Denn einmal definiert, ist der Output des Scripts vorhersehbar.
Ein weiterer Vorteil ist, dass sich Terraform merkt, welche Komponenten beim letzten Durchlauf deployed wurden. Dies passiert in der terraform.tfstate Datei, die lokal im Verzeichnis erstellt wird. Dadurch können wir bei der Weiterentwicklung des Scripts einfach die neuste Version von GitHub ziehen und nur die Änderungen bei unserem Projekt anwenden. Dies machen wir das ebenfalls über den terraform apply Befehl.
Anstatt das Terraform Script lokal zu nutzen, könnten wir es auch mit GitHub Actions automatisieren. So wäre eine Automation denkbar, bei der Projektressourcen automatisch bei neuem Commit in GitHub aktualisiert werden.
Nice 👍