Migrieren von Linux- und PostgreSQL-Workloads

  • 45 Minuten

In diesem Modul werden Sie durch die Migration einer vorhandenen Workload von einer lokalen oder Cloudumgebung zu Azure geführt. Es umfasst die Migration der Computeressourcen zu einer Azure-VM und von Daten zu Azure Database for PostgreSQL. Bei der Anwendung handelt es sich um ein cloudunabhängiges Beispiel, das für jede reale Anwendung stehen könnte, die für die Migration zur Cloud vorbereitet wurde.

In dieser Lerneinheit erfahren Sie, wie wichtig es ist, die folgenden Übergänge mit dem Vorteil einer vollständigen Suite von Sicherheits- und Identitätssteuerung durchzuführen, die Azure bereitstellt:

  • Umstieg von einer selbst gehosteten Umgebung (z. B. einer selbst verwalteten Datenbank) zu einem vollständig verwalteten Datenbankangebot
  • Umstieg von Bare-Metal-Computeressourcen auf in der Cloud gehostete VMs

Sie erkunden außerdem die Vorteile der Verwaltung von Ressourcen in der Cloud in Hinblick auf Kosten und Leistung. Und Sie erfahren, wie Sie die Kosten vor und nach der Bereitstellung genau berechnen und verwalten, und wie Sie die Leistung aus Compute- und Datenperspektive optimieren.

Workload und Daten

Die Workload ist eine Anwendung, die in Go geschrieben wurde und mit Daten in PostgreSQL arbeitet. Bei den Daten handelt es sich um ein offenes Dataset, mit dem Sie die Leistungsfähigkeit der Postgres-Plattform und der zugehörigen Erweiterungen erkunden können.

Diese Anwendung könnte zwar auch problemlos in einem Container ausgeführt werden, aber die Projektbeteiligten haben sich in dieser Phase nicht für diese Vorgehensweise entschieden. Das Erstellen eines Containers, die Bereitstellung auf einer Containerplattform oder die Verwendung der Containerorchestrierung werden in diesem Modul nicht behandelt. Die Migration zu Containern kann jedoch ein logischer zukünftiger Schritt sein.

Das GitHub-Repository, das diesem Modul zugeordnet ist, stellt eine Anwendung und die zugehörigen Daten für Sie bereit. Sie erfahren, wie Sie Ihre Anwendung vorbereiten und Ihre Daten exportieren, um einen ähnlichen Zustand wie diese Beispielanwendung zu erreichen. Sie können die Beispielanwendung auch als Vorlage für eine vollständig neue Bereitstellung verwenden.

Welchen Wert hat die Migration dieser Workload?

Sie fragen sich vielleicht, welche Vorteile die Migration dieser Workload zur Cloud bietet. Im Folgenden finden Sie einige der Wertversprechen.

Sicherheit und Konformität

Wenn Sie Compute- und Datenworkloads in die Cloud transferieren, profitieren sie von strengeren Sicherheitsfunktionen.

VMs in Azure profitieren von einer Vielzahl von Sicherheits- und Compliancefeatures, einschließlich Firewalls, virtuellen Netzwerken, Just-In-Time-Zugriff auf VMs, Verschlüsselung, RBAC (rollenbasierte Zugriffssteuerung) und Confidential Computing. Azure Database for PostgreSQL unterstützt viele ähnliche Features, z. B. Verschlüsselung mit kundenseitig verwalteten Schlüsseln, Compliancezertifizierungen und Unterstützung für Microsoft Defender for Cloud.

Sichere Verbindungen zwischen Ihren VMs und Datenbanken

Da Sie eine VM mit Azure Database for PostgreSQL integrieren, ist es wichtig, dass sie auf sichere Weise miteinander verbunden werden können, um das Risiko von Datenverlusten zu reduzieren.

Mit der Microsoft Entra-Authentifizierung können Sie eine Verbindung mit Azure Database for PostgreSQL ohne herkömmliche Kennwörter herstellen. Stattdessen verwenden Sie Microsoft Entra-Identitäten für Ihre Anwendungsworkloads (d. h. verwaltete Identitäten), Benutzer und Administratoren über deren Microsoft Entra-Benutzerkonten. Mit diesem Ansatz verringern Sie das Risiko, dass langlebige Anmeldeinformationen kompromittiert werden und böswillige Akteure auf Ihre Daten zugreifen können.

Microsoft Entra ID, verwaltete Identitäten und eine differenzierte rollenbasierte Zugriffssteuerung (RBAC) können Ihren Anwendungsworkloads den Zugriff auf Daten und die sichere Verwaltung von Ressourcen in Azure ermöglichen, und zwar nach dem Prinzip der geringsten Berechtigungen.

Zugriff auf leistungsstarke und kostengünstige Computeressourcen in mehreren Regionen

Unabhängig davon, ob Sie kostengünstige Computeressourcen für Dev/Test oder die neuesten, leistungsstärksten oder größten Computetypen benötigen, die in der Cloud verfügbar sind, bietet Azure eine breite Auswahl an Computeoptionen sowohl für VMs als auch für Azure Database for PostgreSQL. Sie können diese Optionen nach Bedarf hoch- oder herunterskalieren, und sie sind in mehr als 60 Regionen in Azure verfügbar.

Sie können Computeressourcen sowohl vertikal als auch horizontal skalieren, dies schließt auch Datenbankreplikate und verteilte Optionen wie Azure Cosmos DB for PostgreSQL ein. Azure Cosmos DB for PostgreSQL ist ein verwalteter Dienst für PostgreSQL, der mit der praktischen Citus-Open-Source-Funktion für „verteilte Tabellen“ erweitert wurde. Diese Computeressourcen werden mit einigen der schnellsten Cloudspeicheroptionen kombiniert, um die Compute- und Speicher-E/A-Anforderungen an Ihre Workload anzupassen.

Kostenverwaltung und Kosteneffizienz

Sie können die Kostenverwaltung und die Kosteneffizienz sowohl auf der Linux- als auch der PostgreSQL-Seite optimieren. Im Vergleich zu lokalen Lösungen können die Kosten oftmals präziser an Ihre Situation angepasst werden. Sie können die Computeressourcen im Vergleich zu einer lokalen Lösung optimal in der Größe anpassen. Sie können Ihre gesamte Flotte auch ganz einfach verwalten, um sie nur hinsichtlich der benötigten Compute- und Speicherressourcen zu optimieren. Sie bezahlen dann nur für das, was Sie nach einem Abrechnungsmodell verbrauchen.

Die nutzungsbasierte Abrechnung ermöglicht Kunden, Zeiträume mit hoher Nachfrage zu bewältigen, ohne die Kosten für die Überbereitstellung zu bezahlen. Sie ermöglicht auch die Migration zu schnelleren und effizienteren Computegenerationen, sobald diese verfügbar werden.

Kunden können auch den Azure-Hybridvorteil nutzen, um Lizenzkosten für bestimmte Linux-Distributionen zu sparen. Weitere Informationen finden Sie unter Azure-Hybridvorteil für Red Hat Enterprise Linux- (RHEL) und SUSE Linux Enterprise Server-VMs (SLES).

Außerdem können die Kunden ihre Kosten mit ein- oder dreijährigen Laufzeiten für VMs und Azure Reserved Virtual Machine Instances reduzieren – um bis zu 72 % im Vergleich zur nutzungsbasierten Bezahlung. Weitere Informationen finden Sie unter Anwenden des Azure-Reservierungsrabatts auf VMs. Die Azure-Preise sind transparent und vorhersagbar, und Sie können den Azure-Preisrechner verwenden, um Ihre Kosten schon vor der Bereitstellung zu schätzen.

Betriebsvorgänge am 2. Tag

Betriebsvorgänge am 2. Tag für bereitgestellte Anwendungen (z. B. Triage, Überwachung, Sicherheitspatching, Sicherungen und Notfallwiederherstellung) werden durch Automatisierung und die Möglichkeit zum Upgrade mit potenziell keiner Downtime noch effizienter. Darüber hinaus können Sie Ihre Infrastruktur vollständig mit branchenüblichen Standardtools verwalten.

Voraussetzungen

Dieses Modul soll Ihnen helfen, eine vorhandene Linux- und PostgreSQL-Workload zu Azure zu migrieren. Es geht allerdings nicht so sehr darum, wie die Daten aus der Quelldatenbank exportiert werden oder wie die Anwendung für die Migration vorbereitet wird. Ein Grund für diesen Ansatz ist, dass es viele verschiedene Typen von Quelldatenbanken und Anwendungen gibt, die migriert werden können, und dass der Prozess für jeden Typ anders ist.

Sie erhalten in diesem Modul eine Beispielanwendung, Postgres-Daten, Binärdateien und Infrastruktur als Code, mit denen Sie den Migrationsprozess simulieren können. Nachdem Sie die simulierte Migration abgeschlossen haben, können Sie die erlernten Prinzipien auf Ihre eigene Workload anwenden.

Sie verwenden die Beispielanwendung Azure-Samples/tailwind-traders-go als Anwendungscode für die Migration. Die Bicep-Infrastruktur als Code, die Postgres- und Binärbeispieldaten und andere Ressourcen zur Unterstützung des Praxisteils dieses Moduls finden Sie im GitHub-Repository Azure-Samples/linux-postgres-migration.

Um diesen Ansatz auf Ihre eigene Workload anzuwenden, müssen Sie Ihre Quellanwendung und -daten in die folgende Struktur bringen.

Anwendungscode

Ihr Anwendungscode sollte in einer Quellcodeverwaltung gespeichert sein, vorzugsweise in einem Repository auf GitHub.

Diese Migration in diesem Modul veranschaulicht das einfachste Szenario, in dem Sie das Repository direkt auf Ihre Azure-VM klonen. In einem realen Szenario würden Sie wahrscheinlich eine komplexere Bereitstellungspipeline wie GitHub Actions nutzen, die Ihren Anwendungscode für Ihre Computeressourcen erstellt und bereitstellt.

Postgres-Daten

Ihre Postgres-Daten sollten in einer .sql-Datei gespeichert werden, mit der Sie das Datenbankschema erstellen und die Daten einfügen können. In dieser simulierten Migration verwenden Sie die Beispieldatendatei tailwind.sql aus dem Repository Azure-Samples/linux-postgres-migration. Sie kopieren die Datei nach Azure Blob Storage und importieren sie dann in Azure Database for PostgreSQL.

Wenn Sie Ihre eigenen Daten migrieren, exportieren Sie diese aus Ihrer Quelldatenbank und speichern sie in einer .sql-Datei. Anschließend kopieren Sie die Datei nach Blob Storage, wie in diesem Modul beschrieben.

Binärdateien

Die meisten Anwendungen verfügen über andere Binärdateien, z. B. Mediendateien, die migriert werden müssen. Bei dieser Beispielanwendung erfahren Sie, wie Sie Bilder migrieren, indem Sie sie aus Azure-Samples/linux-postgres-migration nach Blob Storage kopieren.

Auf dieselbe Weise müssen Sie Ihre Binärdateien beim Migrieren Ihrer eigenen Workload nach Blob Storage kopieren. In diesem Fall ist das Computing statusfrei, und die Anwendung verfügt über die Berechtigung, direkt in Blob Storage auf die Binärdaten zuzugreifen.

Infrastruktur als Code (Bicep)

Die Infrastruktur als Code für dieses Modul wird ebenfalls in Azure-Samples/linux-postgres-migration gespeichert. Sie ist so konzipiert, dass sie eine Referenzarchitektur darstellt, die Sie direkt mit minimalen Änderungen verwenden können, sofern Ihre Quelldaten und die Anwendung der zuvor beschriebenen Struktur entsprechen.

Sicherheit ist ein wichtiges Thema bei dieser Migration, sodass bestimmte Sicherheitseinstellungen ausgewählt wurden, um den praktischen Teil dieses Moduls zu vereinfachen. Blob Storage verwendet z. B. eine sicherere, schlüssellose Authentifizierungsmethode, aber hier werden Netzwerkverbindungen von jeder IP-Adresse aus zugelassen. In einer Produktionsumgebung sollten Sie den Netzwerkzugriff nur für die IP-Adressen zulassen, die Zugriff auf das Speicherkonto benötigen.

Ebenso wird hier nicht die Möglichkeit genutzt, dem PostgreSQL-Server eine Firewallregel hinzuzufügen, um eine bestimmte IP-Adresse zuzulassen. In einer Produktionsumgebung können Sie aber den gesamten öffentlichen Zugriff auf den Server vollständig deaktivieren.

Unterschiede zwischen Quellumgebungen und Azure

Einer der wichtigsten Unterschiede, den Sie bei der Migration von einer anderen Umgebung zu Azure feststellen werden, besteht darin, dass die von Azure bereitgestellten Sicherheits- und Identitätskontrollen vollständig genutzt werden:

  • Sie verwenden verwaltete Identitäten für VMs und Azure Database for PostgreSQL.
  • Sie verwenden Microsoft Entra ID für die Authentifizierung bei der Datenbank.
  • Sie verwenden Microsoft Entra ID anstelle von SSH-Schlüsseln (Secure Shell), um auf VMs zuzugreifen.

Anstelle einer Migration per Lift & Shift nutzen Sie die Gelegenheit, die Anwendung zu modernisieren, um die von Azure bereitgestellten Sicherheits- und Compliancefeatures vollständig zu nutzen.

Lokal können Sie einen Benutzernamen und ein Kennwort verwenden, um sich bei Ihrer Datenbank zu authentifizieren. Hier wird gezeigt, wie Sie in Azure die verwaltete Identität der VM verwenden, um sich bei der Datenbank zu authentifizieren. Diese Methode der Authentifizierung ist sicherer und reduziert das Risiko, dass langlebige Anmeldeinformationen kompromittiert werden.

Die Verwendung einer verwalteten Identität für die Authentifizierung erfordert häufig Codeänderungen in Ihrer Anwendung. In diesem Modul wird gezeigt, wie Sie die azidentity-Bibliothek in Go verwenden, um ein Token für die verwaltete Identität abzurufen. Dieselbe Bibliothek ist für alle Microsoft-SDKs verfügbar.

Erstellen eines Azure-Kontos und Installieren der Azure-Befehlszeilenschnittstelle

Falls Sie noch kein Azure-Konto besitzen, können Sie sofort ein kostenloses Konto erstellen. Sie erhalten ein Guthaben, mit dem Sie andere kostenpflichtige Azure-Dienste ausprobieren können. Auch nachdem Sie das Guthaben aufgebraucht haben, können Sie das Konto behalten und kostenlose Azure-Dienste verwenden.

Um die Befehle in den folgenden Lerneinheiten auszuführen, benötigen Sie Zugriff auf eine Bash-Shell. Diese Shell kann in einem der folgenden Bereiche sein:

  • Auf einem lokalen Computer: Verwenden Sie beispielsweise macOS, Linux, das Windows-Subsystem für Linux (WSL) oder Docker.
  • Auf einer VM. Verwenden Sie beispielsweise Multipass oder Azure.
  • In der Cloud Verwenden Sie beispielsweise Azure Cloud Shell oder GitHub Codespaces.

Um dieses Modul abzuschließen, benötigen Sie die Azure-Befehlszeilenschnittstelle. Sie können die Azure-Befehlszeilenschnittstelle auf Ihrem lokalen Computer installieren, indem Sie die Anweisungen im Artikel Installieren der Azure-Befehlszeilenschnittstelle befolgen. Sie müssen außerdem Git installieren.

Ressourcen