Best Practices für die Verwendung von Deployment Manager

Auf dieser Seite werden die Best Practices für das Erstellen von Bereitstellungen 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 zuerst mit der Schnellstartanleitung beginnen.

Vorlagen erstellen

❑  
Verwenden Sie Python, um Ihre Vorlagen zu erstellen. Sie können Python oder Jinja2 verwenden, um Vorlagen zu erstellen. Jinja ist für den Einstieg einfacher, aber Python ist flexibler und effizienter und ist die bevorzugte Methode für das Schreiben von Vorlagen.
❑  
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 diese Vorgehensweise einhalten:
  • Wird es einfacher, einen Satz von Vorlagen in einen zusammengesetzten Typ umzuwandeln.
  • Vereinfacht es das Erstellen des Skripts der API für das gcloud-Tool, in dem Sie die übergeordnete Vorlage mithilfe des Parameters --config übergeben. Anschließend legen Sie die Vorlageneigenschaften mit dem Flag --properties fest.
❑  
Verwenden Sie eine Schemadatei. Definieren Sie mindestens eine Schemadatei für die übergeordnete Vorlage. Schemas definieren eine Reihe von Regeln, denen eine Konfigurationsdatei entsprechen muss, wenn sie eine bestimmten Vorlage verwenden soll. Wenn Sie ein Schema definieren, sollten Sie die darin definierten Anforderungen von anderen Nutzern prüfen lassen. So können Ihre Nutzer dann gut verstehen, welche Eigenschaften für die jeweilige Vorlage einstellbar oder erforderlich sind. Nutzer können die Konfiguration dann einfach verwenden, ohne die Details der Vorlagen kennen zu müssen.
❑  
Verwenden Sie Vorlageneigenschaften und Ausgaben. Mit den Eigenschaften und Ausgaben können Sie Variablen wie Zonen, Computergrößen, die Anzahl von Maschinen, den Anwendungsstatus (Test, Produktion, Staging) in Ihre Vorlagen übergeben. Sie erhalten dann Ausgabewerte wie IP-Adresse und selfLink zu einer VM-Instanz zurück. Eigenschaften und Ausgaben gestalten Ihre Vorlagen flexibel, sodass sie ohne Änderung der zugrunde liegenden Vorlage wieder verwendet werden können.
❑  
Erstellen Sie zusammensetzbare Konfigurationen. Erstellen Sie keine eigene einzelne Konfigurationsdatei, sondern importieren Sie verschiedenee Vorlagendateien in die Konfigurationsdatei. So erhalten Sie überschaubare Konfigurationen.
❑  
Unterteilen Sie Ihre Konfigurationen in logische Einheiten. Erstellen Sie zum Beispiel einzelne Konfigurationen für zustandsbehaftete Dienste, wie Datenbanken und Buckets, und Konfigurationen für vorübergehende Dienste, wie Front-End-Instanzen.
❑  
Verwenden Sie Referenzen. Referenzen sollten für Werte, die nicht definiert sind bis eine Ressource erstellt wurde, verwendet werden, zum Beispiel für den selfLink einer Ressource, die IP-Adresse oder eine vom System generierte ID. Ohne Referenzen erstellt Deployment Manager alle Ressourcen parallel. Es ist dann nicht mehr garantiert, dass abhängige Ressourcen in der richtigen Reihenfolge erstellt werden. Durch die Verwendung von Referenzen wird die Reihenfolge, in der Ressourcen erstellt werden, erzwungen.
❑  
Erstellen Sie eine Vorschau für Ihre Bereitstellungen. So können Sie überprüfen, wie sich eine Aktualisierung auf Ihre Bereitstellung 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 Richtlinien aktualisieren 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 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.

Berechtigungen

Standardmäßig verwendet Deployment Manager die Anmeldedaten des Google API-Dienstkontos zur Authentifizierung anderer 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 die IAM-Rolle zuweisen. Darin sind die entsprechenden Berechtigungen zur Verwendung von Deployment Manager enthalten. 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 Verwendungstiefe von Deployment Manager.
❑  
Wenn Sie Nutzern den Zugriff auf Ressourcen gewähren möchten, die von Deployment Manager erstellt wurden, gewähren Sie ihnen die Rollen, die eine Ressourcenbearbeitung erlauben, aber nicht die Berechtigung zur direkten Bereitstellung von Ressourcen.
❑  
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 zum Verwalten kritischer Ressourcen wie Projekte oder benutzerdefinierte 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 Ressourenerstellung für die Ressourcen in Ihrem Projekt in Erwägung ziehen. Die Projektbereitstellung lässt sich dadurch in Form einer Infrastruktur auf Codebasis ausführen. Dieser Ansatz bietet folgende Vorteile:

  • Durchsetzung von Unternehmensanforderungen bei der Bereitstellung von Projekten für die Teams, die Zugriff auf Google Cloud Platform-Ressourcen benötigen.
  • Bereitstellung von vordefinierten Projektumgebungen, die schnell und einfach bereitgestellt werden können.
  • Versionskontrolle zur Verwaltung der Basisprojektkonfiguration.
  • Bereitstellung reproduzierbarer und konsistenter Projektkonfigurationen.
  • Integration der Projekterstellung als Teil eines automatisierten Bereitstellungsprozesses.
❑  
Zum Einstieg in dieses Thema automatisieren Sie die Projekterstellung mit den Deployment Manager-Vorlagen, die auf GitHub verfügbar sind.

Fortlaufende Integration und fortlaufende Bereitstellung

Verwenden Sie Deployment Manager als Teil Ihrer Pipeline für fortlaufende Integration (Continous Integration = CI) und fortlaufende Bereitstellung (Continuous Deployment = CD).

❑  
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 belassen, 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 einige Wochen lang nicht 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 zustandsbehafteten 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 Bereitstellungen 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 die Bereitstellung 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 als Code behandeln. Diesen können Sie ganz einfach reproduzieren und konsistente Kopien der aktuellen Produktionsumgebung erstellen. Zum Beispiel weisen Sie der aktuellen Umgebung Änderungen zu und testen diese problemlos.
❑  
Nutzen Sie die Versionskontrolle. Der Einsatz eines Versionsverwaltungssystems während des Entwicklungsprozesses einer Bereitstellung ermöglicht:
  • Rückgriff auf frühere, fehlerfreie Konfigurationen.
  • Bereitstellung eines Audit-Trails für Änderungen.
  • Verwendung der Konfiguration als Teil eines kontinuierlichen Bereitstellungssystems.
Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Cloud Deployment Manager-Dokumentation