Implementieren eines Versionskontrollsystems für AWS QuickSight

Einführung

In der heutigen datengesteuerten Welt sind Business Intelligence-Tools für Unternehmen, die fundierte Entscheidungen treffen wollen, unverzichtbar. Unter den unzähligen verfügbaren BI-Tools sticht AWS QuickSight als skalierbare und kostengünstige Lösung hervor, mit der Benutzer Visualisierungen erstellen, Ad-hoc-Analysen durchführen und aus ihren Daten Geschäftseinblicke gewinnen können. Wie bei jeder Datenanalyseplattform ist jedoch die Verwaltung von Änderungen an Berichten, Dashboards und Datensätzen ein wichtiges Anliegen. Die Implementierung eines Versionskontrollsystems für AWS QuickSight kann die Zusammenarbeit erheblich verbessern, die Entwicklungsprozesse rationalisieren und die allgemeine Verwaltung von BI-Projekten verbessern.

Versionskontrollsysteme (VCS) sind in der modernen Softwareentwicklung unverzichtbar. Sie bieten eine strukturierte Möglichkeit, Änderungen zu verwalten, den Verlauf zu verfolgen und die Zusammenarbeit zwischen Teams zu erleichtern. Im Zusammenhang mit AWS QuickSight kann ein VCS dabei helfen, verschiedene Versionen von Analysen und Dashboards zu verwalten, Rollback-Funktionen im Falle von Fehlern bereitzustellen und einen klaren Prüfpfad für Änderungen im Laufe der Zeit zu bieten.

Überblick über die Lösung

Unsere Lösung für die Versionskontrolle von QuickSight-Ressourcen besteht aus zwei Hauptteilen:

1. Dashboard-Pipeline veröffentlichen

Diese Azure DevOps-Pipeline kann von Dashboard-Autoren ausgelöst werden. Wenn ein Autor mit seiner Arbeit zufrieden ist und ein Dashboard veröffentlichen möchte, muss er die Pipeline mit der Dashboard-ID als Parameter auslösen. Die Pipeline wird dann:

1. Verwendet die QuickSight-API, um die Dashboard-Definition einschließlich aller zugrunde liegenden Datensätze abzurufen, und speichert sie als JSON-Dateien.
2. Erstellt automatisch eine Pull-Anfrage an das Repository, die Dashboard- und Dataset-Definitionen enthält.

2. QuickSight Ressourcen Repository Pipeline

Mithilfe von benutzerdefinierten Terraform-Modulen verwaltet diese Pipeline alle Zustände (Erstellung, Aktualisierung und Löschung) von QuickSight-Ressourcen. Lassen Sie uns in die Details dieser Schritte eintauchen.

Detaillierte Implementierung

Dashboard-Definitionen abrufen

Um die Dashboard-Definition abzurufen, verwenden wir ein Python-Skript mit dem Boto3-Paket. Nachdem das Skript die Dashboard-Definition erhalten hat, durchläuft es die Liste der zugehörigen Datensätze und holt auch deren Definitionen ab. Die JSON-Dateien werden in zwei Verzeichnissen gespeichert: Dashboards und Datasets. Jede Ressource ist nach ihrem Anzeigenamen und ihrer Objekt-ID geordnet, um sicherzustellen, dass Namensduplikate nicht zu Überschreibungen führen. Das Skript sorgt auch dafür, dass die zugehörigen Berechtigungsdateien erstellt werden, damit sowohl die Ressourcendefinitionen als auch die Zugriffsrichtlinien im Repository erhalten bleiben.

def main(parameters): 
   boto3_session = authorize_dashboard_account(parameters) 
   dashboard_name_sanitized, dashboard_data = save_dashboard_definition(parameters, boto3_session) 
   datasets = get_datasets(dashboard_data) 

   for dataset_id in datasets: 
    save_dataset_definition(parameters, dataset_id, parameters["dashboardsDirectory"], boto3_session) 
    copy_permissions_file(parameters, dashboard_name_sanitized) 

   return dashboard_name_sanitized 

Pull Request erstellen

Der nächste Schritt in der Pipeline für die Veröffentlichung des Dashboards besteht darin, eine Pull-Anfrage mit den am Repository vorgenommenen Änderungen zu erstellen. Ein Bash-Skript verwendet Git-Befehle, um einen Zweig mit den Änderungen zu erstellen. Das Azure CLI (az-Befehlszeilentool) erstellt dann die Pull-Anfrage und stellt dem Benutzer einen Link zur Überprüfung zur Verfügung.

PR_CREATE_RESPONSE=$(az repos pr create  
 --project $(System.TeamProject)  
 --repository $(Build.Repository.Name)  
 --source-branch $BRANCH  
 --squash true  
 --delete-source-branch true  
 --merge-commit-message "$DESCRIPTION"  
 --detect true  
 --title "$DESCRIPTION"  
 --output json  
) 

echo "Pull request created successfully" 

Zusammenführen und bereitstellen

Nach der Erstellung der Pull-Anfrage kann der Benutzer die Änderungen überprüfen, die Zugriffsrichtlinien für das Dashboard ändern und die Pull-Anfrage genehmigen. Sobald die Änderungen zusammengeführt sind, führt Deploy Pipeline Terraform-Skripte aus und erstellt überarbeitete und produktionsreife Visualisierungen. Wir haben drei separate Module entwickelt: Dashboard, Dataset und role_custom_permission. Diese Module verwenden den ScottWinkler/shell-Anbieter, um Skripte auf der Grundlage des gewünschten Zustands des Objekts auszuführen.

resource "shell_script" "dashboard" { 
 lifecycle_commands { 
   create = "python ${path.module}/scripts/dashboard_create.py" 
   read   = "python ${path.module}/scripts/dashboard_read.py" 
   update = "python ${path.module}/scripts/dashboard_update.py" 
   delete = "python ${path.module}/scripts/dashboard_delete.py" 
 } 

 environment = { 
   AWS_ACCOUNT_ID = data.aws_caller_identity.current.account_id 
   DASHBOARD_MD5  = md5(file(var.dashboard_path)) 
   DASHBOARD_PATH = var.dashboard_path 
   DASHBOARD_ID   = jsondecode(file(var.dashboard_path)).DashboardId 
 } 
} 

Die Lösung durchsetzen

Um sicherzustellen, dass sich die Benutzer für unsere Lösung und nicht für die manuelle Veröffentlichung von Dashboards entscheiden, haben wir die manuelle Veröffentlichung von Dashboards blockiert, indem wir eine benutzerdefinierte Berechtigung mit dem Namen PreventDashboardSharing erstellt und diese auf die IAM-Rolle der Autoren angewendet haben.

Vorbehalte und Überlegungen

Bei der Umsetzung dieser Lösung sind wir auf einige Vorbehalte gestoßen:

• Dashboard-Miniaturansichten: Dashboards, die über die API erstellt werden, haben keine Miniaturansichten, was die Benutzer verwirren könnte. Dies sollten Sie bedenken, bevor Sie eine solche Lösung einsetzen.

• Nicht unterstützte Datasets: Für einige Datensätze, wie z.B. Jira-Datensätze, konnten wir die JSON-Definition nicht abrufen. AWS stellt keine umfassende Liste der unterstützten Dataset-Typen zur Verfügung.

• API-Einschränkungen: In manchen Fällen kann die von der API abgerufene Dashboard-Definition nicht als Nutzlast verwendet werden, um ihr Duplikat zu erstellen. Glücklicherweise erlaubt die QuickSight-API zum Erstellen von Dashboards die Einstellung von ValidationStrategy, um die Validierung zu lockern.

Fazit

Die Implementierung eines Versionskontrollsystems für AWS QuickSight-Dashboards gewährleistet deren Zuverlässigkeit und bietet eine unkomplizierte Möglichkeit, Änderungen rückgängig zu machen. Durch die Nutzung von Azure DevOps und Terraform haben wir die Lösung mit unseren bestehenden Arbeitsabläufen und unserer Infrastruktur abgestimmt. Trotz einiger Vorbehalte bietet dieser Ansatz einen robusten Mechanismus für die Verwaltung von QuickSight-Ressourcen und stellt sicher, dass versehentliche Löschungen und Änderungen einfach verwaltet und abgefedert werden können.