Best Practices für die Verwendung von Deployment Manager

Auf dieser Seite werden die Best Practices für das Erstellen von Bereitstellungen mit Google Cloud Deployment Manager beschrieben. Diese Seite ist für Nutzer ausgelegt, die mit Deployment Manager vertraut sind. Auf dieser Seite erhalten Sie keine einführenden Anleitungen zur Verwendung von Deployment Manager.

Wenn Sie Deployment Manager noch nicht kennen, sollten Sie mit der Kurzanleitung beginnen.

Ressourcen verwalten

❑  
Wenn eine Ressource als Teil eines Deployments erstellt wurde, können Sie dieses mit Deployment Manager bei Bedarf ändern. Wenn Sie eine Ressource ändern, ohne Deployment Manager zu verwenden, z. B. mit der Google Cloud Console oder gcloud, werden möglicherweise Fehler angezeigt, wenn Sie versuchen, die Ressource in der ursprünglichen Bereitstellung zu ändern.

Wenn Sie eine Ressource aus einem Deployment entfernen möchten, ohne die Ressource zu löschen, führen Sie die folgenden Schritte aus:

  1. Löschen Sie in Ihrer Deployment-Konfiguration die Definition dieser Ressource.
  2. Aktualisieren Sie das Deployment und fügen Sie in Ihrem gcloud-Befehl --delete-policy ABANDON hinzu. Die Ressource ist nicht mehr die mit der Bereitstellung verknüpft sind, und Sie können Ressource mit der Google Cloud Console oder gcloud.
❑  
Wenn Sie in Ihrem Deployment Compute Engine-Instanzen verwenden und diesen Instanzen nichtflüchtige Speicher hinzufügen möchten, definieren Sie die Speicher separat von der Instanz, damit Sie sie problemlos verwalten können. Im folgenden Deployment ist beispielsweise der Speicher example-disk von der Instanz example-instance getrennt definiert. Zum Hinzufügen des Speichers verweist die Konfiguration auf diesen: 
    resources:
    # instance
    - name: example-instance
      type: compute.v1.instance
      properties:
        disks:
          - type: PERSISTENT
            source:$(ref.example-disk.selfLink)
   # disk
   - name: example-disk
     type: compute.v1.disk
     properties:
       zone: us-central1-a
       sizeGb: 10
       type: ...
❑  

Wenn Sie private GKE-Cluster (Google Kubernetes Engine) mit Deployment Manager erstellen und verwalten möchten, legen Sie die folgenden Optionen für privateClusterConfig und ipAllocationPolicy in Ihrem Deployment fest.

     privateClusterConfig:
        enablePrivateNodes: true
        enablePrivateEndpoint: true
        #  Configure the IP range for the hosted master network
        masterIpv4CidrBlock: IP_RANGE
      ipAllocationPolicy:
        useIpAliases: true
        createSubnetwork: true

Unter Private Cluster einrichten finden Sie Informationen zu Anforderungen und weiteren Überlegungen, die Sie beim Erstellen eines privaten Clusters mit GKE beachten sollten.

Anmeldedaten in Ihr Deployment einbinden

❑  
Deployment Manager entfernt einige Felder, die sich auf Anmeldedaten von Attributen in Ihren YAML-Konfigurationen beziehen. Dieser Vorgang erfolgt basierend auf dem Schlüssel des Attributs. Im folgenden Beispiel wird ein solches Entfernen gezeigt: 
    # Config provided to Deployment Manager
    resources:
    - name: example-resource
      type: gcp-types/service-v1:sample-type-with-password
      properties:
        zone: us-central1-a
        username: test-user
        password: hunter2

   # Config as surfaced by Deployment Manager
   resources:
    - name: example-resource
      type: gcp-types/service-v1:sample-type-with-password
      properties:
        zone: us-central1-a
        username: test-user
        password: (redacted)
❑  
Wenn Sie die Anmeldedaten in eine Jinja- oder Python-Vorlage für Ihre Bereitstellung aufnehmen, werden die Anmeldedaten aus den resultierenden erweiterten Konfigurations- und Layoutdateien entfernt, sind jedoch in der ursprünglichen Importdatei weiterhin sichtbar. Aus diesem Grund empfehlen wir dringend, alle Anmeldedaten in Ihrer YAML-Konfigurationsdatei auf oberster Ebene zu speichern. Sie können von dort aus mithilfe von Vorlagenattributen darauf verweisen.
❑  
Alle Anmeldedaten, die in einem Schlüssel/Wert-Paar in einer YAML-Datei oder in einer Elementliste enthalten sind, werden nicht entfernt, wie im folgenden Beispiel gezeigt. Es wird dringend empfohlen, keine Anmeldedaten für Deployment Manager als Schlüssel/Wert-Paare in YAML-Dateien oder Listen von Elementen aus diesem Grund anzugeben. 
    # Not a valid instance configuration, used solely for demonstration
    resources:
    - name: example-resource
      type: gcp-types/compute-v1:instances
      properties:
        zone: us-central1-a
        disks:
        - autoDelete: true
          boot: true
    # Will not be redacted
          password: hunter2

Vorlagen erstellen

❑  
Um die Definition Ihrer Vorlagen zu beschleunigen, sollten Sie mit den produktionsfertigen Beispielvorlagen aus dem Cloud Foundation Toolkit-Projekt beginnen.
❑  
In der Anleitung und den Beispielen für die Verwendung von Deployment Manager im großen Maßstab erfahren Sie, wie Sie vorgehen, wenn Sie komplexe Infrastrukturanforderungen haben, z. B. mehrere Umgebungen erstellen müssen.
❑  
Verwenden Sie Python, um Ihre Vorlagen zu erstellen. Sie können Python oder Jinja2 verwenden, um Vorlagen zu erstellen. Jinja ist einfacher, aber Python ist flexibler für komplexe Deployments, bei denen viele Ressourcen in mehreren Umgebungen aufgeteilt werden können.
❑  
Strukturieren Sie Ihre Konfigurationsdatei (die YAML-Datei) so, dass sie nur einen Typ verwendet und nutzen Sie eine übergeordnete Vorlage dieses Typs zum Aufruf aller anderen Vorlagen. Wenn Sie so vorgehen, wird es einfacher, einen Satz von Vorlagen in einen zusammengesetzten Typ zu ändern.
❑  
Verwenden Sie eine Schemadatei. Schemas definieren eine Reihe von Regeln, denen eine Konfigurationsdatei entsprechen muss, um eine bestimmte Vorlage verwenden zu können. Wenn Sie ein Schema definieren, sollten Sie die darin definierten Anforderungen von anderen Nutzern prüfen lassen. So können Ihre Nutzer gut verstehen, welche Attribute für die jeweilige Vorlage festlegbar oder erforderlich sind. Nutzer können die Konfiguration dann verwenden, ohne die Details der Vorlagen zu kennen. Definieren Sie mindestens eine Schemadatei für die übergeordnete Vorlage.
❑  
Verwenden Sie Vorlagenattribute und Ausgaben. Mithilfe von Attributen und Ausgaben können Sie Variablen wie die Zone, die Maschinengröße, die Anzahl der Maschinen oder den Anwendungsstatus (Test, Produktion, Staging) an Ihre Vorlagen übergeben und Ausgabewerte wie die IP-Adresse und den selfLink zu einer VM-Instanz abzurufen. Attribute und Ausgaben gestalten Ihre Vorlagen flexibel, sodass sie ohne Änderung der zugrunde liegenden Vorlage wieder verwendet werden können.
❑  
Verwenden Sie einzelne Vorlagendateien, die Sie in die Hauptkonfigurationsdatei importieren. So erhalten Sie überschaubare Konfigurationen.
❑  
Unterteilen Sie Ihre Konfigurationen in logische Einheiten. Erstellen Sie zum Beispiel einzelne Konfigurationen für zustandsorientierte Dienste, wie Datenbanken und Buckets, und Konfigurationen für zustandslose Dienste, wie Frontend-Instanzen.
❑  
Verwenden Sie Verweise. Verweise sollten für Werte verwendet werden, die erst bei Erstellung einer Ressource definiert werden, z. B. der selfLink, die IP-Adresse oder die vom System generierte ID einer Ressource. Ohne Verweise erstellt Deployment Manager alle Ressourcen parallel. Es gibt also keine Garantie, dass abhängige Ressourcen in der richtigen Reihenfolge erstellt werden. Durch Verweise wird die Erstellungsreihenfolge von Ressourcen erzwungen.
❑  
Erstellen Sie eine Vorschau für Ihre Deployments. So können Sie überprüfen, wie sich eine Aktualisierung auf Ihr Deployment auswirkt. Deployment Manager instanziiert keine tatsächlichen Ressourcen, wenn Sie eine Vorschau auf eine Konfiguration anzeigen. Stattdessen wird die vollständige Konfiguration erweitert und es werden "Shell"-Ressourcen erstellt. So können Sie die Änderungen an Ihrer Bereitstellung vor der Freigabe prüfen.
❑  
Überprüfen Sie die API-Methoden für eine bestimmte Ressource, um die Auswirkungen von Aktualisierungen zu verstehen. Legen Sie Aktualisierungsrichtlinien fest, wenn Sie eine Bereitstellung aktualisieren. So können Sie steuern, wie Deployment Manager die Aktualisierungen anwendet.
❑  
Verwenden Sie Labels für Ihre Ressourcen. Wenn die von Ihnen definierten Ressourcen Labels unterstützen, sollten Sie diese verwenden. Labels können bei der Kategorisierung von Ressourcen helfen, die zu verschiedenen Deployments gehören. Mit Labels kann auch unterschieden werden, in welcher Phase sich eine Ressource befindet, beispielsweise ob die Ressource eine Produktions- oder Testumgebung unterstützt.

Größe Ihrer Deployments verwalten

Deployment Manager kann mit einer großen Anzahl von Ressourcen arbeiten, die Kontingentlimits unterliegen. Wenn Sie die für das Erstellen, Aktualisieren oder Löschen Ihrer Deployments erforderliche Zeit reduzieren möchten, können Sie die Anzahl der Ressourcen pro Deployment reduzieren.

❑  
Wenn eine Gruppe von Ressourcen nicht von Ressourcen außerhalb dieser Gruppe abhängig ist, können Sie diese Gruppe von Ressourcen in ein separates Deployment verschieben. Wenn Ihr Deployment beispielsweise mehrere Vorlagen enthält, können Sie möglicherweise jede Vorlage als separates Deployment verpacken.
❑  
Entfernen Sie unnötige Ressourcen aus Ihrer Konfiguration. Wenn Sie später weitere Ressourcen benötigen, können Sie Ihrem Deployment jederzeit weitere Ressourcen hinzufügen.
❑  
Optional können Sie Ihr Deployment auf bis zu 1.000 Ressourcen beschränken.

Berechtigungen

Standardmäßig verwendet Deployment Manager die Anmeldedaten des Google APIs-Dienstkontos zur Authentifizierung bei anderen APIs. Das Google APIs-Dienstkonto ist speziell zur Ausführung interner Google-Prozesse in Ihrem Namen ausgelegt.

Wenn Sie anderen Nutzern Zugriff auf Ihr Deployment Manager-Projekt gewähren möchten, müssen Sie diesen eine IAM-Rolle zuweisen, in der die entsprechenden Berechtigungen zur Verwendung von Deployment Manager enthalten sind. Es gibt verschiedene vordefinierte IAM-Rollen mit unterschiedlichen Zugriffsberechtigungen auf Deployment Manager.

❑  
Mit IAM-Rollen beschränken Sie die Zugriffsberechtigungen der Nutzer und damit deren Möglichkeit zur Nutzung von Deployment Manager.
❑  
Wenn Sie Nutzern den Zugriff auf Ressourcen gewähren möchten, die von Deployment Manager erstellt wurden, gewähren Sie ihnen Rollen, die eine Nutzung der Ressourcen erlauben, aber nicht die Berechtigung zur direkten Bereitstellung von Ressourcen gewähren.
❑  
Wenn Sie einem Hauptkonto die Rolle Inhaber zuweisen, kann es die IAM-Richtlinie ändern. Erteilen Sie daher die Inhaberrolle nur, wenn das Hauptkonto einen berechtigten Grund zum Verwalten der IAM-Richtlinie hat, da Ihre Richtlinie sensible Zugriffssteuerungsdaten enthält. Die Verwaltung möglichst weniger Nutzer vereinfacht alle Prüfungen, die Sie vornehmen müssen.
❑  
Deployment Manager verwendet das Google APIs-Dienstkonto zum Erstellen und Verwalten Ihrer Ressourcen. Wenn Sie Deployment Manager für die Verwaltung wichtiger Ressourcen, wie z. B. benutzerdefinierter IAM-Rollen, verwenden, müssen Sie dem standardmäßigen Google APIs-Dienstkonto zusätzliche IAM-Rollen zuweisen. Wenn Sie beispielsweise mithilfe von Deployment Manager benutzerdefinierte IAM-Rollen erstellen und verwalten möchten, müssen Sie dem Google APIs-Dienstkonto die Administratorrolle hinzufügen.

Eine Übersicht über das Google APIs-Dienstkonto finden Sie unter Von Google verwaltete Dienstkonten.

Schritte zum Zuweisen von Rollen zu einem Dienstkonto finden Sie unter Dienstkonten Rollen zuweisen.

Automatisierung

Sie sollten die Automatisierung der Projekterstellung und der Ressourcenerstellung innerhalb des Projekts in Erwägung ziehen. Dadurch lassen sich Projekte mit dem Infrastruktur-als-Code-Ansatz bereitstellen. Dieser Ansatz bietet folgende Vorteile:

  • Durchsetzung der Unternehmensanforderungen beim Deployment von Projekten für die Teams, die Zugriff auf Google Cloud-Ressourcen benötigen.
  • Deployment von vordefinierten Projektumgebungen, die schnell und einfach zur Verfügung gestellt werden können
  • Versionskontrolle zur Verwaltung der Basisprojektkonfiguration
  • Deployment reproduzierbarer und konsistenter Projektkonfigurationen
  • Einbindung der Projekterstellung in einen automatisierten Deployment-Vorgang
❑  
Sie können die Projekterstellung mit den auf GitHub verfügbaren Vorlagen automatisieren, um in dieses Thema einzusteigen.

Kontinuierliche Integration (CI) und kontinuierliche Bereitstellung (CD)

Verwenden Sie Deployment Manager als Teil Ihrer Pipeline für Continuous Integration und Continuous Deployment.

❑  
Verwenden Sie keine CI-/CD-Pipeline, um ganze Test- und QA-Projekte zu erstellen und zu löschen.
  • Sie können VM-Instanzen oder Ressourcen löschen, wenn diese zusätzliche Kosten verursachen. Aber Sie sollten wiederverwendbare Assets beibehalten, deren erneute Erstellung viel Zeit in Anspruch nehmen könnte. Das Löschen solcher Ressourcen kann für das Erstellen Ihrer Pipelines nachteilig sein und viel Zeit beanspruchen. Es entstehen keine Kosten für die Einrichtung von Netzwerken, Subnetzen und Firewallregeln.
  • Beachten Sie: Auch wenn Sie ein Projekt löschen, bleibt es noch ein paar Tage Teil Ihres Projektkontingents, bis es vollständig entfernt ist. Das bedeutet auch, dass Sie den Projektnamen nicht sofort wiederverwenden können.
  • Mithilfe von Deployment Manager können Sie ganz einfach Ressourcen aus einem Projekt löschen, sodass Sie Ihre Ressourcenkontingente nicht damit belasten.
❑  
Mit Deployment Manager erstellen Sie die zustandsorientierten Projektteile und Netzwerkkonfigurationen. Anschließend stellen Sie diese außerhalb des CI-/CD-Prozesses im Rahmen der anfänglichen Einrichtung bereit. Nachdem die Tests abgeschlossen sind, können Sie die Deployments löschen, die nur zustandslose Ressourcen enthalten und als Teil der Pipeline bereitgestellt wurden.
❑  
Als Teil des CI-/CD-Prozesses verwenden Sie eine separate Konfiguration für das Deployment von Ressourcen für Ihre Test- und QA-Projekte. Nachdem Sie die Tests abgeschlossen haben, können Sie die Ressourcen mit Deployment Manager aus Ihren Test- und QA-Projekten löschen.
Testen Sie die Deployments. Durch die Möglichkeit, Ressourcen als Teil einer CI-/CD-Pipeline zu einzubinden, können Sie Ihre Projektkonfiguration in Deployment Manager wie Code behandeln. Diesen können Sie leicht testen und konsistente Kopien der aktuellen Produktionsumgebung oder der aktuellen Umgebung mit Änderungen, die vertraulich auf den Test angewendet werden, zu reproduzieren.
❑  
Nutzen Sie die Versionsverwaltung. Der Einsatz eines Versionsverwaltungssystems im Rahmen des Entwicklungsprozesses Ihrer Deployments ermöglicht Folgendes:
  • Rückgriff auf frühere, fehlerfreie Konfigurationen
  • Bereitstellung eines Audit-Trails für Änderungen
  • Verwendung der Konfiguration als Teil eines Continuous Deployment-Systems