Verwaltung von Analysen auf Cloudebene
DevOps hat die Kultur verändert, wie Menschen denken und arbeiten. Dadurch beschleunigt sich auch die Wertschöpfung in den Unternehmen. Diese unterstützen Einzelpersonen und Organisationen dabei, nachhaltige Arbeitsmethoden zu entwickeln und beizubehalten. DevOps kombiniert Entwicklung und Betrieb, und arbeitet oft zusammen mit Softwareentwicklungstools, die Methoden der fortlaufenden Integration (CI) und der fortlaufenden Lieferung (CD) unterstützen. Zu diesen Tools und Methoden gehören Quellcode-Manager (z. B. Git, Apache Subversion oder Team Foundation-Versionskontrolle) und automatische Build- und Übermittlungs-Manager (z. B. Azure Pipelines oder GitHub Actions).
DevOps in Verbindung mit Beobachtungsfähigkeit ist der Schlüssel zur Bereitstellung einer agilen und skalierbaren Plattform. DevOps gibt Teams die Möglichkeit, Quellcodekontrolle, CI/CD-Pipelines, Infrastruktur als Code, Workflows und Automatisierung zu implementieren. Die Beobachtbarkeit ermöglicht es Geschäftsinhabern, DevOps-Ingenieuren, Datenarchitekten, Datentechnikern und Standortsicherheitstechnikern, Probleme auf automatisierte Weise zu erkennen, vorherzusagen, zu verhindern und zu beheben und so Ausfallzeiten zu vermeiden, die andernfalls die Produktionsanalytik und KI beeinträchtigen würden.
Quellcodeverwaltung
Die Quellcodeverwaltung stellt sicher, dass Code und Konfigurationen beibehalten und Änderungen nachverfolgt und in Versionen festgehalten werden. Die meisten Quellcodeverwaltungssysteme verfügen auch über integrierte Prozesse zum Überprüfen und Arbeiten in verschiedenen Verzweigungen eines Code-Repository. Derzeit ist Git der gängigste Quellcodeverwaltungstyp. Dabei handelt es sich um ein verteiltes Versionskontrollsystem, mit dem Einzelpersonen offline arbeiten und mit zentralen Repositorys synchronisieren können. Git-Anbieter verwenden in der Regel auch Verzweigungen und befolgen die Pull Request-Anleitung, um den Änderungs- und Überprüfungsablauf zu unterstützen.
Verzweigungen isolieren Änderungen oder Entwicklungen von Merkmalen, ohne dass sich dies auf andere gleichzeitige Vorgänge auswirkt. Die Verwendung von Verzweigungen sollte gefördert werden, um Merkmale zu entwickeln, Fehler zu beheben und gefahrlos mit neuen Ideen zu experimentieren. Pull Requests führen die von einer Verzweigung vorgenommenen Änderungen mit der Standardverzweigung zusammen und unterstützen einen kontrollierten Überprüfungsprozess. Aus Sicherheitsgründen sollte der Hauptzweig Pull Requests verwenden, um Codeüberprüfungen sicherzustellen.
Wichtig
Befolgen Sie diese Richtlinien für Cloud-Skalierungsanalysen Repositorys:
- Sichern Sie den Hauptzweig des Repository, indem Sie Verzweigungen und Pull Requests erzwingen, um einen kontrollierten Überprüfungsprozess zu schaffen.
- Azure DevOps oder GitHub Repositorys sollten für die Quellcodeverwaltung verwendet werden, um Änderungen am Quellcode nachzuverfolgen und mehreren Teammitgliedern das gleichzeitige Entwickeln von Code zu ermöglichen.
- Anwendungscode und Infrastrukturkonfigurationen sollten in ein Repository eingecheckt werden.
CI/CD-Pipelines
CI ermöglicht Teams, Quellcode automatisch zu testen und zu erstellen, und erlaubt auch schnelle Iterationen und Feedbackschleifen, um eine hohe Codequalität in CD sicherzustellen. Pipelines sind Wege, um die CI von Änderungen (Softwarecode oder Infrastrukturcode) und CD der gepackten/kompilierten Änderungen zu konfigurieren. Dies wird auch als Build and Release bezeichnet. CD beschreibt die automatische Bereitstellung von Anwendungen in einer oder mehreren Umgebungen. CD folgt in der Regel einem CI-Prozess und verwendet Integrationstests, um die gesamte Anwendung zu überprüfen.
Pipelines können mehrere Phasen mit verschiedenen Aufgaben enthalten und einfache bis komplexe Genehmigungsabläufe aufweisen, um Konformität und Validierung sicherzustellen. Je nach Präferenz können Pipelines auch mit verschiedenen automatischen Triggern konfiguriert werden. Für die unternehmensweite und KI-Bereitstellung sollte den Produktionsschritten immer eine richtige Person zugestimmt haben, und dies ist in das Betriebsmodell integriert. CI/CD-Pipelines sollten mit GitHub Actions oder Azure Pipelines erstellt werden, und sie sollten automatisierte Trigger sein.
Infrastructure-as-Code
Der Begriff Code in IaC löst bei IT-Mitarbeitern ohne Entwicklerhintergrund oft Bedenken aus, aber IaC bezieht sich nicht auf das Schreiben von Code in der Art und Weise, wie es typische Softwareentwickler tun. Es übernimmt jedoch viele der gleichen Tools und Prinzipien aus den Softwareentwicklungsprozessen, um Infrastruktur in einem vorhersagbaren Format bereitzustellen.
IaC unterstützt die Bereitstellung, Konfiguration und Verwaltung der Infrastruktur als Teil einer DevOps-Pipeline mit vollständigen Änderungssteuerungen, Überwachungsverlauf, Tests, Überprüfungen und Genehmigungsprozessen, um sicherzustellen, dass Aufgaben an die entsprechenden Rollen für das Projekt delegiert werden können, ohne die Sicherheit und Konformität zu beeinträchtigen.
Die beiden Ansätze für IaC sind deklarativ und imperativ:
Deklarativ bezieht sich auf das Angeben des gewünschten Zustands der Infrastruktur und das Ausführen der erforderlichen Aktionen durch einen Orchestrierungs-Engine, um den gewünschten Zustand zu erreichen. In Azure macht man dies mit Vorlagen von Azure Resource Manager. Für diesen Ansatz sind auch Abstraktionsebenen von Drittanbietern wie Terraform verfügbar.
Der imperative Ansatz bezieht sich auf das Ausführen bestimmter Befehle in einer definierten Reihenfolge. Für Azure kann dies mit der Befehlszeilenschnittstelle oder PowerShell erreicht werden, aber Software-Entwicklungskits in nativer Programmiersprache, z. B. .NET, Python und Java, sind auch verfügbar, wenn integrierte Lösungen erforderlich sind.
In Azure Resource Manager Vorlagen befindet sich die Kernbereitstellung im Abschnitt Ressourcen, und die Konfiguration der einzelnen Ressourcen wird in einem Abschnitt Eigenschaften definiert. Für eine Azure Data Lake Storage Gen2 sieht die Konfiguration wie folgt aus:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources": [
{
"type": "Microsoft.MachineLearningServices/workspaces/datastores",
"name": "[concat(parameters('workspaceName'), '/', parameters('datastoreName'))]",
"apiVersion": "2020-05-01-preview",
"location": "[parameters('location')]",
"properties": {
"DataStoreType": "adls-gen2",
"SkipValidation": "[parameters('skipValidation')]",
"ClientId": "[parameters('clientId')]",
"ClientSecret": "[parameters('clientSecret')]",
"FileSystem": "[parameters('fileSystem')]",
"AccountName": "[parameters('accountName')]",
"TenantId": "[parameters('tenantId')]",
"ResourceUrl": "[parameters('resourceUrl')]",
"AuthorityUrl": "[parameters('authorityUrl')]"
}
}
]
}
Wichtig
Jede Ebene der Cloud-Skalierungsanalyse, wie z. B. die Datenverwaltungs-Zielzonen, die Datenzielzonen oder die Datenanwendungen (die Datenprodukte erstellen), sollte mit einer deklarativen Sprache wie Azure Resource Manager oder Terraform definiert, in ein Repository eingecheckt und über CI/CD-Pipelines bereitgestellt werden. Dadurch können Teams Änderungen an Infrastruktur an der Konfiguration des Azure-Bereichs nachverfolgen und versionieren und gleichzeitig verschiedene Architekturebenen unterstützen, die agil automatisiert werden sollen. Diese Anleitung führt Teams dazu, Git-Repositorys zu verwenden, um stets Einblick in den Status bestimmter Azure-Bereiche zu haben.
Workflows und Automatisierung
Teams sollten CI/CD-Pipelines in mehreren Phasen verwenden, um sicherzustellen, dass entwickelter Code fehlerfrei und produktionsbereit ist. Einige bewährte Methoden sind, dass man eine Entwicklungsumgebung, eine Testumgebung und eine Produktionsumgebung besitzt. Diese Phasen sollten auch in Azure erscheinen, indem man für jede Umgebung separate Dienste verwendet.
Das Plattformteam ist für die Bereitstellung und Verwaltung von Bereitstellungsvorlagen verantwortlich, um eine schnelle Skalierung innerhalb einer Organisation zu erzielen und Bereitstellungen für Teams zu vereinfachen, die mit IaC nicht vertraut sind. Diese Vorlagen dienen als Baseline für neue Artefakte innerhalb des Szenarios und müssen im Laufe der Zeit beibehalten werden, um bewährte Methoden und allgemeine Standards innerhalb des Unternehmens darzustellen.
Bereitstellungen zu Test- und Produktionszwecken sollten nur über eine CI/CD-Pipeline und eine Dienstverbindung mit erhöhten Berechtigungen verwaltet werden, um gängige bewährte Methoden durchzusetzen (z. B. Azure Resource Manager-Vorlagen).
Achtung
Datenanwendungsteams sollten nur Lesezugriff auf Test- und Produktionsumgebungen besitzen, und Bereitstellungen in diesen Umgebungen sollten nur über CI/CD-Pipelines und Dienstverbindungen mit erhöhten Berechtigungen ausgeführt werden. Um den Beginn der Produktion zu beschleunigen, sollten Datenanwendungsteams Schreibzugriff auf die Entwicklungsumgebung haben.