Von AWS zu Google Cloud migrieren: Von Amazon EC2 zu Compute Engine migrieren

Google Cloud bietet Tools, Produkte, Anleitungen und professionelle Dienstleistungen für die Migration virtueller Maschinen (VMs) mit ihren Daten von Amazon Elastic Compute Cloud (Amazon EC2) zu Compute Engine. In diesem Dokument wird beschrieben, wie Sie einen Plan für die Migration von Amazon EC2 zu Compute Engine entwerfen, implementieren und validieren.

Die Diskussion in diesem Dokument richtet sich an Cloud-Administratoren, die Details zum Planen und Implementieren eines Migrationsprozesses wünschen. Sie richtet sich auch an Entscheidungsträger, die eine Möglichkeit zur Migration in Betracht ziehen und sich ansehen möchten, wie die Migration aussehen könnte.

Dieses Dokument ist Teil einer mehrteiligen Reihe zur Migration von AWS zuGoogle Cloud , die die folgenden Dokumente umfasst:

Für diese Migration zu Google Cloudempfehlen wir Ihnen, dem Migrations-Framework zu folgen, das unter Migration zu Google Cloud: Erste Schritte beschrieben wird.

Diese Grafik veranschaulicht den Migrationsprozess:

Migrationspfad mit vier Phasen

Sie können in einer Reihe von Iterationen von der Quellumgebung zu Google Cloud migrieren. Beispielsweise können Sie einige Arbeitslasten zuerst und andere später migrieren. Für jede separate Migrationsiteration folgen Sie den Phasen des allgemeinen Migrations-Frameworks:

  1. Arbeitslasten und Daten bewerten und erkennen.
  2. Plane und baue eine Grundlage auf Google Cloud.
  3. Migrieren Sie Ihre Arbeitslasten und Daten zu Google Cloud.
  4. Optimieren Sie Ihre Google Cloud Umgebung.

Weitere Informationen zu den Phasen dieses Frameworks finden Sie unter Migration zu Google Cloud: Erste Schritte.

Um einen effektiven Migrationsplan zu entwerfen, empfehlen wir, jeden Schritt des Plans zu validieren und sicherzustellen, dass Sie eine Rollback-Strategie haben. Informationen zur Validierung des Migrationsplans finden Sie unter Migration zu Google Cloud: Best Practices zum Validieren eines Migrationsplans.

Quellumgebung bewerten

In der Bewertungsphase legen Sie die Anforderungen und Abhängigkeiten für die Migration der Quellumgebung zu Google Cloudfest.

Die Bewertungsphase ist für den Erfolg der Migration entscheidend. Sie benötigen umfassende Kenntnisse über die zu migrierenden Arbeitslasten, deren Anforderungen, Abhängigkeiten und über Ihre aktuelle Umgebung. Sie müssen Ihren Ausgangspunkt kennen, um eine Google Cloud-Migration erfolgreich planen und ausführen zu können.

Die Bewertungsphase umfasst die folgenden Aufgaben:

  1. Ein umfassendes Inventar Ihrer Arbeitslasten erstellen.
  2. Arbeitslasten nach ihren Attributen und Abhängigkeiten katalogisieren.
  3. Schulen und schulen Sie Ihre Teams zu Google Cloud.
  4. Erstellen Sie Tests und Proofs of Concept für Google Cloud.
  5. Die Gesamtbetriebskosten (TCO) der Zielumgebung berechnen.
  6. Migrationsstrategie für Ihre Arbeitslasten auswählen.
  7. Tools für die Migration auswählen.
  8. Migrationsplan und Zeitplan definieren.
  9. Migrationsplan validieren.

Weitere Informationen zur Bewertungsphase und zu diesen Aufgaben finden Sie unter Migration zu Google Cloud: Arbeitslasten bewerten und erkennen. Die folgenden Abschnitte basieren auf Informationen in jenem Dokument.

Inventar Ihrer Amazon EC2-Instanzen erstellen

Zur Bestimmung des Umfangs der Migration erstellen Sie ein Inventar Ihrer Amazon EC2-Instanzen. Anschließend können Sie das Inventar verwenden, um Ihre Bereitstellungs- und operativen Prozesse für die Bereitstellung von Arbeitslasten auf diesen Instanzen zu bewerten.

Zum Erstellen des Inventars Ihrer Amazon EC2-Instanzen empfehlen wir die Verwendung von Migration Center, der einheitlichen Plattform vonGoogle Cloud, mit der Sie den gesamten Weg in die Cloud von Ihrer aktuellen Umgebung zu Google Cloudbeschleunigen können. Mit dem Migrationscenter können Sie eine Inventarerkennung in AWS ausführen.

Die von Migration Center und der Discovery-Client-Befehlszeile des Migration Center bereitgestellten Daten erfassen die für Sie interessanten Dimensionen möglicherweise nicht vollständig. In diesem Fall können Sie die Daten in die Ergebnisse anderer Mechanismen zur Datenerfassung einbinden, die auf AWS APIs, AWS-Entwicklertools und der AWS-Befehlszeile basieren.

Zusätzlich zu den Daten, die Sie vom Migration Center und der Discovery-Client-Befehlszeile des Migration Centers erhalten, sollten Sie die folgenden Datenpunkte für jede Amazon EC2-Instanz berücksichtigen, die Sie migrieren möchten:

  • Region und Zone der Bereitstellung.
  • Instanztyp und -größe.
  • Das Amazon Machine Image (AMI), von dem die Instanz gestartet wird.
  • Den Hostnamen der Instanz sowie die Art und Weise, wie andere Instanzen und Arbeitslasten diesen Hostnamen für die Kommunikation mit der Instanz verwenden.
  • Die Instanz-Tags sowie Metadaten und Nutzerdaten.
  • Den Typ der Instanzvirtualisierung.
  • Die Kaufoption der Instanz, z. B. On-Demand-Kauf oder Spot-Kauf.
  • Wie die Instanz Daten speichert, z. B. mit Instanzspeichern und Amazon EBS-Volumes.
  • Die Mandantenkonfiguration der Instanz.
  • Ob sich die Instanz in einer bestimmten Placement-Gruppe befindet.
  • Ob sich die Instanz in einer bestimmten Autoscaling-Gruppe befindet.
  • Die Sicherheitsgruppen, zu denen die Instanz gehört.
  • Jede AWS Network Firewall-Konfiguration, die die Instanz umfasst.
  • Ob die auf der Instanz ausgeführten Arbeitslasten durch AWS Shield und AWS WAF geschützt sind.
  • Ob Sie den Prozessorstatus Ihrer Instanz steuern und wie die auf der Instanz ausgeführten Arbeitslasten vom Prozessorstatus abhängen.
  • Die Konfiguration des Instanz-E/A-Planers.
  • Art der Bereitstellung von Arbeitslasten, die auf der Instanz ausgeführt werden, für Clients, die in Ihrer AWS-Umgebung ausgeführt werden (z. B. andere Arbeitslasten) und für externe Clients.

Bereitstellungs- und operative Prozesse bewerten

Es ist wichtig, ein klares Verständnis von der Funktionsweise Ihrer Bereitstellungs- und Betriebsprozesse zu haben. Diese Prozesse sind ein grundlegender Teil der Praktiken, die die Produktionsumgebung und die dort ausgeführten Arbeitslasten vorbereiten und verwalten.

Die Bereitstellungs- und Betriebsprozesse können die Artefakte erstellen, die Ihre Arbeitslasten benötigen. Daher sollten Sie Informationen zu jedem Artefakttyp erfassen. Ein Artefakt kann beispielsweise ein Betriebssystempaket, ein Bereitstellungspaket für Anwendungen, ein Betriebssystem-Image, ein Container-Image oder etwas anderes sein.

Berücksichtigen Sie zusätzlich zum Artefakttyp, wie Sie die folgenden Aufgaben ausführen:

  • Entwickeln Sie Ihre Arbeitslasten: Bewerten Sie die Prozesse, die Entwicklungsteams zum Erstellen Ihrer Arbeitslasten eingerichtet haben. Wie entwerfen, codieren und testen Ihre Entwicklungsteams beispielsweise Ihre Arbeitslasten?
  • Generieren Sie Artefakte, die Sie in Ihrer Quellumgebung bereitstellen. Zum Bereitstellen Ihrer Arbeitslasten in der Quellumgebung generieren Sie möglicherweise bereitstellbare Artefakte wie Container-Images oder Betriebssystem-Images oder passen vorhandene Artefakte an, z. B. Betriebssystemimages von Drittanbietern durch Installieren und Konfigurieren von Software. Wenn Sie Informationen darüber erfassen, wie Sie diese Artefakte generieren, können Sie prüfen, ob die generierten Artefakte für die Bereitstellung inGoogle Cloudgeeignet sind.

  • Artefakte speichern: Wenn Sie Artefakte erstellen, die Sie in einer Artefakt-Registry in Ihrer Quellumgebung speichern, müssen Sie die Artefakte in der Google Cloud -Umgebung verfügbar machen. Verwenden Sie dazu Strategien wie die folgenden:

    • Kommunikationskanal zwischen den Umgebungen einrichten: Sorgen Sie dafür, dass die Artefakte in Ihrer Quellumgebung über dieGoogle Cloud -Zielumgebung erreichbar sind.
    • Refaktorieren Sie den Artefakt-Build-Prozess: Führen Sie eine geringfügige Refaktorierung Ihrer Quellumgebung durch, damit Sie Artefakte sowohl in der Quell- als auch in der Zielumgebung speichern können. Dieser Ansatz unterstützt die Migration, indem Sie eine Infrastruktur wie ein Artefakt-Repository erstellen, bevor Sie Artefakt-Build-Prozesse in der Zielumgebung Google Cloudimplementieren müssen. Sie können diesen Ansatz direkt implementieren oder auf dem vorherigen Ansatz aufbauen, der zuerst einen Kommunikationskanal einrichtet.

    Wenn Artefakte sowohl in der Quell- als auch in der Zielumgebung verfügbar sind, können Sie sich auf die Migration konzentrieren, ohne im Rahmen der Migration Artefakt-Build-Prozesse in der Zielumgebung Google Cloud implementieren zu müssen.

  • Scannen und signieren Sie Code . Im Rahmen Ihrer Artefakterstellungsprozesse verwenden Sie möglicherweise Codescans, um sich vor allgemeinen Sicherheitslücken und unbeabsichtigten Netzwerken zu schützen, sowie Codesignaturen, die dafür sorgen, dass nur vertrauenswürdiger Code in Ihren Umgebungen ausgeführt wird.

  • Stellen Sie Artefakte in der Quellumgebung bereit. Nachdem Sie bereitstellbare Artefakte generiert haben, stellen Sie diese möglicherweise in Ihrer Quellumgebung bereit. Wir empfehlen, jeden Bereitstellungsprozess zu bewerten. Mithilfe der Bewertung können Sie prüfen, ob Ihre Bereitstellungsprozesse mit Google Cloudkompatibel sind. Außerdem können Sie damit den Aufwand ermitteln, der für eine eventuelle Refaktorierung der Prozesse erforderlich ist. Wenn Ihre Bereitstellungsprozesse beispielsweise nur mit Ihrer Quellumgebung funktionieren, müssen Sie sie möglicherweise so refaktorieren, dass sie auf Ihre Google Cloud -Umgebung ausgerichtet sind.

  • Laufzeitkonfiguration einfügen. Sie können die Laufzeitkonfiguration für bestimmte Cluster, Laufzeitumgebungen oder Arbeitslastbereitstellungen einfügen. Die Konfiguration kann Umgebungsvariablen und andere Konfigurationswerte wie Secrets, Anmeldedaten und Schlüssel initialisieren. Damit Ihre Injektionsprozesse für die Laufzeitkonfiguration mit Google Cloudfunktionieren, sollten Sie prüfen, wie Sie die Arbeitslasten konfigurieren, die in Ihrer Quellumgebung ausgeführt werden.

  • Logging, Monitoring und Profilerstellung: Bewerten Sie die Logging-, Monitoring- und Profilerstellungsprozesse, die Sie eingerichtet haben, um den Zustand Ihrer Quellumgebung, die relevanten Messwerte und die Verwendung der Daten zu überwachen, die von diesen Prozessen bereitgestellt werden.

  • Authentifizierung. Prüfen Sie, wie Sie sich in Ihrer Quellumgebung authentifizieren.

  • Ressourcen bereitstellen und konfigurieren Zur Vorbereitung Ihrer Quellumgebung haben Sie möglicherweise Prozesse entwickelt und implementiert, die Ressourcen bereitstellen und konfigurieren. Beispielsweise verwenden Sie Terraform zusammen mit Konfigurationsverwaltungstools, um Ressourcen in der Quellumgebung bereitzustellen und zu konfigurieren.

Grundlage planen und aufbauen

In der Planungs- und Erstellungsphase stellen Sie die Infrastruktur bereit und konfigurieren sie für Folgendes:

  • Unterstützen Sie Ihre Arbeitslasten in Ihrer Google Cloud Umgebung.
  • Verbinden Sie Ihre Quellumgebung und Ihre Google Cloud -Umgebung, um die Migration abzuschließen.

Die Planungs- und Erstellungsphase besteht aus den folgenden Aufgaben:

  1. Erstellen Sie eine Ressourcenhierarchie.
  2. Konfigurieren Sie die Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) von Google Cloud.
  3. Richten Sie die Abrechnung ein.
  4. Richten Sie die Netzwerkverbindung ein.
  5. Erhöhen Sie die Sicherheit.
  6. Logging, Monitoring und Benachrichtigungen einrichten

Weitere Informationen zu den einzelnen Aufgaben finden Sie unter Migrieren zu Google Cloud: Grundlagen planen und aufbauen.

Arbeitslasten migrieren

So migrieren Sie Ihre Arbeitslasten von Amazon EC2 zu Compute Engine:

  1. Migrieren Sie VMs von Amazon EC2 zu Compute Engine.
  2. Migrieren Sie Ihre VM-Laufwerke zu einem nichtflüchtigen Speicher.
  3. Machen Sie Arbeitslasten, die in Compute Engine ausgeführt werden, für Clients verfügbar.
  4. Refaktorieren Sie die Bereitstellungs- und Betriebsprozesse aufGoogle Cloud anstatt auf Amazon EC2.

Die folgenden Abschnitte enthalten Details zu den einzelnen Aufgaben.

VMs zu Compute Engine migrieren

Zum Migrieren von VMs von Amazon EC2 zu Compute Engine empfehlen wir die Verwendung des vollständig verwalteten Dienstes Migrate to Virtual Machines. Weitere Informationen finden Sie unter Migration mit Migrate to VMs.

Im Rahmen der Migration migriert Migrate for VMs Amazon EC2-Instanzen in ihrem aktuellen Status, mit Ausnahme der erforderlichen Konfigurationsänderungen. Wenn Ihre Amazon EC2-Instanzen benutzerdefinierte Amazon EC2-AMIs ausführen, migriert Migrate for VMs diese Anpassungen zu Compute Engine-Instanzen. Wenn Sie Ihre Infrastruktur jedoch reproduzierbar machen möchten, müssen Sie möglicherweise äquivalente Anpassungen vornehmen. Dazu erstellen Sie im Rahmen Ihrer Bereitstellungs- und Betriebsprozesse Compute Engine-Betriebssystem-Images, wie weiter unten in diesem Dokument erläutert. Sie können auch Ihre Amazon EC2-AMIs in Compute Engine importieren.

VM-Laufwerke zu Persistent Disk migrieren

Sie können mit Migrate to VMs auch Laufwerke von Ihren Amazon EC2-Quell-VMs zu einem nichtflüchtigen Speicher migrieren, mit minimalen Unterbrechungen der Arbeitslasten, die auf den Amazon EC2-VMs ausgeführt werden. Weitere Informationen finden Sie unter VM-Laufwerke migrieren und an eine neue VM anhängen.

Sie können beispielsweise ein Datenlaufwerk, das an eine Amazon EC2-VM angehängt ist, zu einem nichtflüchtigen Speicher migrieren und an eine neue Compute Engine-VM anhängen.

Arbeitslasten bereitstellen, die in Compute Engine ausgeführt werden

Nachdem Sie Ihre Amazon EC2-Instanzen zu Compute Engine-Instanzen migriert haben, müssen Sie möglicherweise Ihre Google Cloud-Umgebung bereitstellen und konfigurieren, um die Arbeitslasten für Clients verfügbar zu machen.

Google Cloud bietet sichere und zuverlässige Dienste und Produkte, um Ihre Arbeitslasten für Clients verfügbar zu machen. Für Arbeitslasten, die auf Ihren Compute Engine-Instanzen ausgeführt werden, konfigurieren Sie Ressourcen für die folgenden Kategorien:

  • Firewalls
  • Traffic-Load-Balancing
  • DNS-Namen, -Zonen und -Einträge
  • DDoS-Schutz und Webanwendungs-Firewalls

Für jede dieser Kategorien können Sie zuerst eine Referenzkonfiguration implementieren, die der Konfiguration der AWS-Dienste und -Ressourcen in der entsprechenden Kategorie ähnelt. Anschließend können Sie die Konfiguration iterieren und zusätzliche Features von Google Cloud -Diensten verwenden.

In den folgenden Abschnitten wird erläutert, wie SieGoogle Cloud -Ressourcen in diesen Kategorien bereitstellen und konfigurieren und wie sie AWS-Ressourcen in ähnlichen Kategorien zugeordnet werden.

Firewalls

Wenn Sie AWS-Sicherheitsgruppen und AWS Network Firewall-Richtlinien und -Regeln konfiguriert haben, können Sie Cloud Next Generation Firewall-Richtlinien und -Regeln konfigurieren. Sie können auch VPC Service Controls-Regeln bereitstellen, um den Netzwerktraffic in Ihrer VPC zu regulieren. Mit VPC Service Controls können Sie den ausgehenden Traffic von Ihren Compute Engine-Instanzen steuern und das Risiko der Daten-Exfiltration minimieren.

Wenn Sie beispielsweise AWS-Sicherheitsgruppen verwenden, um Verbindungen zu Ihren Amazon EC2-Instanzen zuzulassen oder abzulehnen, können Sie ähnliche VPC-Firewallregeln (Virtual Private Cloud) konfigurieren, die für Ihre Compute Engine-Instanzen gelten.

Wenn Sie Remote-Zugriffsprotokolle wie SSH oder RDP verwenden, um eine Verbindung zu Ihren Amazon EC2-VMs herzustellen, können Sie die öffentliche IP-Adresse der VM entfernen und über Identity-Aware Proxy (IAP) eine Remote-Verbindung zur VM herstellen. Mit der IAP-TCP-Weiterleitung können Sie einen verschlüsselten Tunnel einrichten. Sie können den Tunnel verwenden, um SSH-, RDP- und anderen Internettraffic an VMs weiterzuleiten, ohne Ihren VMs öffentliche IP-Adressen zuzuweisen. Da Verbindungen vom IAP-Dienst aus einem reservierten öffentlichen IP-Adressbereich stammen, müssen Sie entsprechende VPC-Firewallregeln erstellen. Wenn Sie Windows-basierte VMs haben und die Windows-Firewall aktiviert ist, achten Sie darauf, dass die Windows-Firewall nicht so konfiguriert ist, dass RDP-Verbindungen von IAP blockiert werden. Weitere Informationen finden Sie unter Fehlerbehebung bei RDP.

Traffic-Load-Balancing

Wenn Sie Elastic Load Balancing (ELB) in Ihrer AWS-Umgebung konfiguriert haben, können Sie Cloud Load Balancing konfigurieren, um den Netzwerktraffic zu verteilen und die Skalierbarkeit Ihrer Arbeitslasten in Google Cloudzu verbessern. Cloud Load Balancing unterstützt mehrere globale und regionale Load-Balancing-Produkte, die auf verschiedenen Ebenen des OSI-Modells eingesetzt werden, z. B. auf der Transport- und auf Anwendungsebene. Sie können ein Load-Balancing-Produkt auswählen, das den Anforderungen Ihrer Arbeitslasten entspricht.

Cloud Load Balancing unterstützt auch die Konfiguration von Transport Layer Security (TLS) zum Verschlüsseln des Netzwerk-Traffics. Wenn Sie TLS für Cloud Load Balancing konfigurieren, können Sie je nach Ihren Anforderungen selbstverwaltete oder von Google verwaltete TLS-Zertifikate verwenden.

DNS-Namen, -Zonen und -Einträge

Wenn Sie Amazon Route 53 in Ihrer AWS-Umgebung verwenden, können Sie Folgendes in Google Cloudverwenden:

Wenn Sie beispielsweise eine Domain mit Amazon Route 53 registriert haben, können Sie die Domainregistrierung an Cloud Domains übertragen. Wenn Sie öffentliche und private DNS-Zonen mit Amazon Route 53 konfiguriert haben, können Sie diese Konfiguration zu Cloud DNS migrieren.

DDoS-Schutz und Webanwendungs-Firewalls

Wenn Sie in Ihrer AWS-Umgebung AWS Shield und AWS WAF konfiguriert haben, können Sie Ihre Google Cloud Arbeitslasten mit Google Cloud Armor vor DDoS-Angriffen und häufigen Exploits schützen.

Bereitstellungs- und operative Prozesse refaktorieren

Nachdem Sie Ihre Arbeitslasten refaktoriert haben, refaktorieren Sie Ihre Bereitstellungs- und Betriebsprozesse so, dass sie Folgendes tun:

  • Stellen Sie Ressourcen in der Google Cloud -Umgebung bereit und konfigurieren Sie sie statt in der Quellumgebung.
  • Erstellen und konfigurieren Sie Arbeitslasten und stellen Sie sie in der Google Cloudbereit, anstatt sie in der Quellumgebung bereitzustellen.

Sie haben zuvor in der Bewertungsphase Informationen zu diesen Prozessen erfasst.

Welche Art der Refaktorierung für diese Prozesse berücksichtigt werden muss, hängt davon ab, wie Sie sie entwickelt und implementiert haben. Die Refaktorierung hängt auch davon ab, was der Endstatus für jeden Prozess sein soll. Sie könnten beispielsweise Folgendes versuchen:

  • Möglicherweise haben Sie diese Prozesse in Ihrer Quellumgebung implementiert und möchten ähnliche Prozesse in Google Cloudentwerfen und implementieren. Beispielsweise können Sie diese Prozesse refaktorieren, um Cloud Build, Cloud Deploy und Infrastructure Manager zu verwenden.
  • Sie haben diese Prozesse möglicherweise in einer Drittanbieterumgebung außerhalb Ihrer Quellumgebung implementiert. In diesem Fall müssen Sie diese Prozesse so refaktorieren, dass sie auf Ihre Google Cloud -Umgebung und nicht auf Ihre Quellumgebung ausgerichtet sind.
  • Eine Kombination der beiden Ansätze.

Die Refaktorierung von Bereitstellungs- und operativen Prozessen kann komplex sein und einen erheblichen Aufwand erfordern. Wenn Sie versuchen, diese Aufgaben im Rahmen Ihrer Arbeitslastmigration auszuführen, kann die Arbeitslastmigration komplexer werden und Risiken aussetzen. Nachdem Sie Ihre Bereitstellungs- und operativen Prozesse bewertet haben, haben Sie wahrscheinlich ein Verständnis für ihr Design und ihre Komplexität. Wenn Sie davon ausgehen, dass Sie viel Aufwand für die Refaktorierung Ihrer Bereitstellungs- und operativen Prozesse betreiben müssen, empfehlen wir, diese Prozesse als Teil eines separaten, dedizierten Projekts zu refaktorieren.

Weitere Informationen zum Entwerfen und Implementieren von Bereitstellungsprozessen in Google Cloudfinden Sie hier:

In diesem Dokument geht es um die Bereitstellungsprozesse, mit denen die bereitzustellenden Artefakte erzeugt und in der Ziellaufzeitumgebung bereitgestellt werden. Die Refaktorierungsstrategie hängt stark von der Komplexität dieser Prozesse ab. Die folgende Liste zeigt eine mögliche allgemeine Refaktorierungsstrategie:

  1. Stellen Sie Artefakt-Repositories in Google Cloudbereit. Sie können Artifact Registry beispielsweise verwenden, um Artefakte zu speichern und Abhängigkeiten zu erstellen.
  2. Refaktorieren Sie Ihre Build-Prozesse so, dass Artefakte sowohl in der Quellumgebung als auch in Artifact Registry gespeichert werden.
  3. Refaktorieren Sie die Bereitstellungsprozesse, um die Arbeitslasten in IhrerGoogle Cloud -Zielumgebung bereitzustellen. Sie können beispielsweise mit der Bereitstellung einer kleinen Teilmenge Ihrer Arbeitslasten in Google Cloudbeginnen und dazu Artefakte verwenden, die in Artifact Registry gespeichert sind. Anschließend erhöhen Sie die Anzahl der in Google Cloudbereitgestellten Arbeitslasten schrittweise, bis alle zu migrierenden Arbeitslasten aufGoogle Cloudausgeführt werden.
  4. Refaktorieren Sie Ihre Build-Prozesse so, dass Artefakte nur in Artifact Registry gespeichert werden.
  5. Migrieren Sie bei Bedarf frühere Versionen der Artefakte, um sie aus den Repositories in Ihrer Quellumgebung zu Artifact Registry bereitzustellen. Sie können beispielsweise Container-Images in Artifact Registry kopieren.
  6. Nehmen Sie die Repositories in der Quellumgebung außer Betrieb, wenn Sie sie nicht mehr benötigen.

Um etwaige Rollbacks aufgrund unerwarteter Probleme während der Migration zu erleichtern, können Sie Container-Images während der Migration zu Google Cloud in beiden aktuellen Artefakt-Repositories Google Cloud speichern. Im Rahmen der Außerbetriebnahme der Quellumgebung können Sie schließlich die Prozesse zum Erstellen von Container-Images so refaktorieren, dass Artefakte nur inGoogle Cloud gespeichert werden.

Auch wenn dies nicht unbedingt entscheidend für den Erfolg einer Migration ist, müssen Sie möglicherweise Ihre früheren Versionen Ihrer Artefakte aus Ihrer Quellumgebung in Ihre Artefakt-Repositories auf Google Cloudmigrieren. Wenn Sie beispielsweise ein Rollback Ihrer Arbeitslasten zu beliebigen Zeitpunkten unterstützen möchten, müssen Sie möglicherweise frühere Versionen Ihrer Artefakte zu Artifact Registry migrieren. Weitere Informationen finden Sie unter Images aus einer Drittanbieter-Registry migrieren.

Wenn Sie Artifact Registry zum Speichern Ihrer Artefakte verwenden, empfehlen wir Ihnen, Kontrollen zum Schutz Ihrer Artefakt-Repositories zu konfigurieren, z. B. Zugriffssteuerung, Schutz vor Daten-Exfiltration, Scannen auf Sicherheitslücken und Binärautorisierung. Weitere Informationen finden Sie unter Artefakte Zugriff steuern und Artefakte schützen.

Umgebung Google Cloud optimieren

Die Optimierung ist die letzte Phase Ihrer Migration. In dieser Phase iterieren Sie Optimierungsaufgaben, bis Ihre Zielumgebung Ihre Optimierungsanforderungen erfüllt. Die Iteration umfasst folgende Schritte:

  1. Bewerten Sie die aktuelle Umgebung, Teams und Optimierungsschleife.
  2. Optimierungsanforderungen und -ziele festlegen.
  3. Umgebung und Teams optimieren.
  4. Verbessern Sie die Optimierungsschleife.

Wiederholen Sie diese Sequenz, bis Sie Ihre Optimierungsziele erreicht haben.

Weitere Informationen zum Optimieren der Google Cloud -Umgebung finden Sie unter Migrieren zu Google Cloud: Umgebung optimieren und Google Cloud Well-Architected Framework: Leistungsoptimierung.

Nächste Schritte

Beitragende

Autor: Marco Ferrari | Cloud Solutions Architect