Best Practices für die Verwendung von Deployment Manager

Auf dieser Seite werden die Best Practices für das Erstellen von Deployments mit 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 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 mit der Bereitstellung verknüpft und Sie können die Ressource mit der Cloud Console oder gcloud ändern.
❑  
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.

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 für die skalierte Verwendung 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 nur ein Typ verwendet wird, und nutzen Sie eine übergeordnete Vorlage für diesen Typ, um alle anderen Vorlagen aufzurufen. 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, den Anwendungsstatus (Test, Produktion, Staging) an Ihre Vorlagen übergeben und Ausgabewerte wie die IP-Adresse und den selfLink zu einer VM-Instanz abrufen. Attribute und Ausgaben gestalten Ihre Vorlagen flexibel, sodass sie ohne Änderung der zugrunde liegenden Vorlage wiederverwendet 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 Front-End-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 Ihrem Deployment 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 eins Deployment 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 Bereitstellungen 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.

Permissions

Standardmäßig verwendet Deployment Manager die Anmeldedaten des Google API-Dienstkontos zur Authentifizierung bei anderen APIs. Das Google API-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 zum direkten Deployment von Ressourcen gewähren.
❑  
Wenn Sie einem Mitglied die Rolle Inhaber zuweisen, kann es die IAM-Richtlinie ändern. Erteilen Sie daher die Inhaberrolle nur, wenn das Mitglied 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 Bereitstellungen. Durch die Möglichkeit, Ressourcen als Teil einer CI-/CD-Pipeline zu integrieren, können Sie Ihre Projektkonfiguration in Deployment Manager wie Code behandeln. Diesen können Sie ganz einfach reproduzieren und konsistente Kopien der aktuellen Produktionsumgebung erstellen. Zum Beispiel können Sie der aktuellen Umgebung Änderungen zuweisen und diese problemlos testen.
❑  
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