Konfigurieren von Speicher und Datenbanken

  • 5 Minuten

Häufig erfordert ein Teil Ihres Bereitstellungsprozesses, dass Sie eine Verbindung mit Datenbanken oder Speicherdiensten herstellen. Diese Verbindung kann erforderlich sein, um ein Datenbankschema anzuwenden, einer Datenbanktabelle Verweisdaten hinzuzufügen oder einige Blobs hochzuladen. In dieser Lerneinheit erfahren Sie, wie Sie Ihre Pipeline erweitern können, um mit Daten- und Speicherdiensten zu arbeiten.

Konfigurieren Ihrer Datenbanken über eine Pipeline

Viele Datenbanken verfügen über Schemas, die die Struktur der in der Datenbank enthaltenen Daten darstellen. Es ist häufig eine bewährte Methode, ein Schema aus Ihrer Bereitstellungspipeline auf Ihre Datenbank anzuwenden. Dadurch wird sichergestellt, dass alles, was Ihre Lösung benötigt, zusammen bereitgestellt wird. Außerdem wird sichergestellt, dass bei einem Problem bei der Anwendung des Schemas in Ihrer Pipeline ein Fehler angezeigt wird. Der Fehler ermöglicht es Ihnen, das Problem zu beheben und erneut bereitzustellen.

Wenn Sie mit Azure SQL arbeiten, müssen Sie Datenbankschemas anwenden, indem Sie eine Verbindung mit dem Datenbankserver herstellen und Befehle mithilfe von SQL-Skripts ausführen. Bei diesen Befehlen handelt es sich um Vorgänge auf Datenebene. Ihre Pipeline muss sich beim Datenbankserver authentifizieren und dann die Skripts ausführen. Azure Pipelines stellt die Aufgabe SqlAzureDacpacDeployment zur Verfügung, die eine Verbindung mit einem Azure SQL-Datenbankserver herstellen und Befehle ausführen kann.

Einige andere Daten- und Speicherdienste müssen nicht mithilfe einer Datenebenen-API konfiguriert werden. Wenn Sie beispielsweise mit Azure Cosmos DB arbeiten, speichern Sie Ihre Daten in einem Container. Sie können Ihre Container mithilfe der Steuerungsebene direkt in Ihrer Bicep-Datei konfigurieren. Ebenso können Sie die meisten Aspekte von Azure Storage-Blobcontainern in Bicep bereitstellen und verwalten. In der nächsten Übung sehen Sie ein Beispiel zum Erstellen eines Blobcontainers aus Bicep.

Hinzufügen von Daten

Viele Lösungen erfordern, dass Verweisdaten zu ihren Datenbanken oder Speicherkonten hinzugefügt werden, bevor sie funktionieren. Pipelines können ein guter Ort zum Hinzufügen dieser Daten sein. Ihre Umgebung ist nach der Pipelineausführung vollständig konfiguriert und einsatzbereit.

Es ist auch hilfreich, Beispieldaten in Ihren Datenbanken zu verwenden, insbesondere für Nicht-Produktionsumgebungen. Mit Beispieldaten können Tester*innen und andere Personen, die diese Umgebungen verwenden, Ihre Lösung sofort testen. Diese Daten können Beispielprodukte oder Dinge wie gefälschte Benutzerkonten umfassen. Im Allgemeinen möchten Sie diese Daten nicht zu Ihrer Produktionsumgebung hinzufügen.

Der Ansatz, den Sie zum Hinzufügen von Daten verwenden, hängt vom von Ihnen verwendeten Dienst ab. Beispiel:

  • Zum Hinzufügen von Daten zu einer Azure SQL-Datenbank müssen Sie ein Skript ausführen, ähnlich wie beim Konfigurieren eines Schemas.
  • Um die Daten in Azure Cosmos DB einzufügen, müssen Sie auf die Datenebenen-API zugreifen. Daher müssen Sie möglicherweise benutzerdefinierten Skriptcode schreiben.
  • Zum Hochladen von Blobs in einen Azure Storage-Blobcontainer können Sie verschiedene Tools aus Pipelineskripts verwenden, einschließlich der AzCopy-Befehlszeilenanwendung, Azure PowerShell oder der Azure CLI. Jedes dieser Tools versteht, wie es sich bei Azure Storage in Ihrem Namen authentifiziert und eine Verbindung mit der Datenebenen-API herstellt, um Blobs hochzuladen.

Idempotenz

Eines der Merkmale von Bereitstellungspipelines und Infrastructure-as-Code ist, dass Sie in der Lage sein sollten, die Bereitstellung wiederholt ohne negative Nebeneffekte noch mal bereitzustellen. Wenn Sie beispielsweise eine bereits bereitgestellte Bicep-Datei noch mal bereitstellen, vergleicht der Azure Resource Manager die von Ihnen übermittelte Datei mit dem vorhandenen Status Ihrer Azure-Ressourcen. Wenn es keine Änderungen gibt, wird nichts ausgeführt. Die Fähigkeit, einen Vorgang wiederholt noch mal auszuführen, wird als Idempotenz bezeichnet. Es ist eine bewährte Methode, sicherzustellen, dass Ihre Skripts und anderen Pipelineschritte idempotent sind.

Idempotenz ist besonders wichtig, wenn Sie mit Datendiensten interagieren, da sie den Zustand behalten. Angenommen, Sie fügen einen Beispielbenutzer aus Ihrer Pipeline in eine Datenbanktabelle ein. Wenn Sie nicht vorsichtig sind, wird jedes Mal, wenn Sie Ihre Pipeline ausführen, ein neuer Beispielbenutzer erstellt. Dies ist wahrscheinlich nicht das, was Sie möchten.

Wenn Sie Schemas auf eine Azure SQL-Datenbank anwenden, können Sie ein Datenpaket verwenden, das auch als DACPAC-Datei bezeichnet wird, um Ihr Schema bereitzustellen. Ihre Pipeline erstellt eine DACPAC-Datei aus dem Quellcode und ein Pipelineartefakt, genau wie bei einer Anwendung. Anschließend veröffentlicht die Bereitstellungsphase in Ihrer Pipeline die DACPAC-Datei in der Datenbank:

Diagram that shows a pipeline publishing and then referring to an artifact named database.

Wenn eine DACPAC-Datei bereitgestellt wird, verhält sie sich auf eine idempotente Weise. Sie vergleicht den Zielstatus Ihrer Datenbank mit dem im Paket definierten Status. In vielen Situationen bedeutet dies, dass Sie keine Skripts schreiben müssen, die dem Idempotenzprinzip folgen, da die Tools die Verarbeitung für Sie übernehmen. Einige der Tools für Azure Cosmos DB und Azure Storage verhalten sich ebenfalls ordnungsgemäß.

Wenn Sie Beispieldaten in einer Azure SQL-Datenbank oder einem anderen Speicherdienst erstellen, der nicht automatisch auf idempotente Weise funktioniert. Es empfiehlt sich, Ihr Skript so zu schreiben, dass die Daten nur erstellt werden, wenn sie noch nicht vorhanden sind.

Es ist auch wichtig zu berücksichtigen, ob Sie möglicherweise einen Rollback für Bereitstellungen ausführen müssen (z. B. durch erneutes Ausführen einer älteren Version einer Bereitstellungspipeline). Der Rollback von Änderungen an Ihren Daten kann kompliziert werden. Überlegen Sie daher sorgfältig, wie Ihre Lösung funktioniert, wenn Sie Rollbacks ausführen müssen.

Netzwerksicherheit

Manchmal können Sie Netzwerkeinschränkungen auf einige Ihrer Azure-Ressourcen anwenden. Diese Einschränkungen können Regeln für Anforderungen erzwingen, die an die Datenebene einer Ressource gestellt werden, z. B.:

  • Auf diesen Datenbankserver kann nur über eine angegebene Liste von IP-Adressen zugegriffen werden.
  • Auf dieses Speicherkonto kann nur von Ressourcen zugegriffen werden, die in einem bestimmten virtuellen Netzwerk bereitgestellt werden.

Netzwerkeinschränkungen gibt es häufig bei Datenbanken, da es so aussieht, als ob im Internet keine Verbindung mit einem Datenbankserver erforderlich wäre.

Netzwerkeinschränkungen können jedoch die Arbeit Ihrer Bereitstellungspipelines mit den Datenebenen Ihrer Ressourcen erschweren. Wenn Sie einen von Microsoft gehosteten Pipeline-Agent verwenden, kann seine IP-Adresse nicht einfach im Voraus bekannt sein und kann aus einem großen Pool von IP-Adressen zugewiesen werden. Darüber hinaus können von Microsoft gehostete Pipeline-Agents nicht mit Ihren eigenen virtuellen Netzwerken verbunden werden.

Einige der Azure Pipelines-Aufgaben, die Ihnen beim Ausführen von Vorgängen auf Datenebene helfen, können diese Probleme beheben. Ein Beispiel hierfür ist die SqlAzureDacpacDeployment-Aufgabe:

Diagram that shows the firewall update process.

Wenn Sie die Aufgabe SqlAzureDacpacDeployment verwenden, um mit einem logischen Azure SQL-Server oder einer logischen Datenbank zu arbeiten, wird der Dienstprinzipal Ihrer Pipeline verwendet, um eine Verbindung mit der Steuerungsebene für den logischen Azure SQL-Server herzustellen. Die Firewall wird aktualisiert, damit der Pipeline-Agent über seine IP-Adresse auf den Server zugreifen kann . Anschließend kann die DACPAC-Datei oder das Skript erfolgreich zur Ausführung übermittelt werden . Die Aufgabe entfernt dann automatisch die Firewallregel, wenn sie abgeschlossen ist.

In anderen Situationen ist es nicht möglich, diese Arten von Ausnahmen zu erstellen. Erwägen Sie unter diesen Umständen die Verwendung eines selbstgehosteten Pipeline-Agents, der auf einer VM oder einer anderen Computeressource ausgeführt wird, die Sie steuern. Sie können diesen Agent dann nach Bedarf konfigurieren. Er kann eine bekannte IP-Adresse verwenden oder mit Ihrem eigenen virtuellen Netzwerk verbunden werden. In diesem Modul werden keine selbstgehosteten Agents besprochen, aber wir stellen Links zu anderen Informationen auf der Seite „Zusammenfassung“ am Ende des Moduls zur Verfügung.

Ihre Bereitstellungspipeline

In der nächsten Übung aktualisieren Sie Ihre Bereitstellungspipeline, um neue Aufträge zum Erstellen der Datenbankkomponenten Ihrer Website, zur Bereitstellung der Datenbank und zum Hinzufügen von Seedingdaten einzufügen:

Diagram showing the revised pipeline. Including, a new database build step, a database deployment step, and data seeding steps in the test environment.