Der Betrieb einer Entwicklerplattform und von Containeranwendungen erfordert eine Reihe verschiedener Verwaltungsaufgaben, die fortlaufend ausgeführt werden müssen. Zu diesen Aufgaben gehören beispielsweise das Erstellen neuer Anwendungen aus einer Vorlage, das Autorisieren neuer Entwicklergruppen für die Verwendung der Entwicklerplattform, die Planung der Kapazitätsanforderungen und das Debugging von Laufzeitproblemen.
Vorgänge können automatisiert oder manuell ausgeführt werden.
Gängige automatisierte Vorgänge
Der Blueprint bietet eine Automatisierung für einige der gängigsten Aufgaben in Form von Webhook-Triggern, bei denen es sich um einen einfachen API-Typ handelt. Trigger werden automatisch mit Webhook-Ereignissen verbunden, die aus einem der Quellkontroll-Repositories stammen. Entwickler von Entwicklerplattformen können die anderen Trigger verbinden. Entwickler schreiben Entwickler in der Regel ein Entwicklerportal. Dies kann ein einfaches Webformular sein, das beim Senden eines Formulars einen Webhook-Trigger aufruft.
In der folgenden Tabelle werden die allgemeinen Aufgaben beschrieben, die der Blueprint mithilfe von Webhook-Triggern automatisiert. Die Aufgabenhäufigkeit soll illustrativ sein, da die Häufigkeit einer Aufgabe von vielen Faktoren abhängt. Aufgaben werden nicht unbedingt in genauen Intervallen wiederholt.
| Task | Nutzer | Beschreibung | Aufgabenhäufigkeit |
|---|---|---|---|
Mandant hinzufügen. |
Entwicklerplattform-Administrator |
Der Administrator sendet ein Formular an das Entwicklerportal. Die neuen Formularfelder für Mandanten enthalten den Namen des Mandanten und die Teammitglieder. Ein automatisierter Trigger erstellt die Ressourcen für den neuen Mandanten. |
Einige Male pro Jahr |
Eine Anwendung auf Basis einer vorhandenen Anwendungsvorlage hinzufügen. |
Symbol: Anwendungsentwickler |
Der Entwickler sendet ein Formular an das Entwicklerportal. Die neuen Formularfelder der Anwendung enthalten den Mandantennamen, den Anwendungsnamen und die Basisanwendungsvorlage. Ein automatisierter Trigger erstellt Ressourcen für eine neue Anwendung. |
Einige Male pro Jahr |
Quellcodeänderungen für eine Anwendung in der Entwicklungsumgebung erstellen und bereitstellen |
Symbol: Anwendungsentwickler |
Der Entwickler bearbeitet den Quellcode, führt ihn aus und führt ihn lokal aus und führt einen Commit durch. Der Blueprint ist nicht an lokalen Entwickler-Workflows beteiligt, aber das Skaffold-Tool unterstützt einen lokalen Build-Schritt. |
Mehrmals täglich für jede Anwendung |
YAML-Konfigurationsänderungen für eine Anwendung in der Entwicklungsumgebung bereitstellen. Ein Beispiel für die Änderung der YAML-Konfiguration ist die Erhöhung der CPU einer Bereitstellungsressource. |
Symbol: Anwendungsentwickler |
Der Entwickler bearbeitet die Anwendungskonfiguration und übernimmt die Änderung. |
Einige Male pro Woche für jede Anwendung |
Änderungen der Anwendungsinfrastruktur in der Entwicklungsumgebung bereitstellen. Die Anwendungsinfrastruktur sind die Cloud-Ressourcen im Projekt einer Anwendung. Eine Beispieländerung ist eine Erhöhung der CPU-Anzahl für eine AlloyDB for PostgreSQL-Instanz. |
Symbol: Anwendungsentwickler |
Der Entwickler bearbeitet das Terraform-Projekt der Anwendungsressource und übernimmt die Änderung. Der Entwickler sendet ein Formular an das Entwicklerportal. Ein automatisierter Trigger startet den Plan und wendet die Pipeline an. |
Mehrmals pro Jahr |
Anwendungsänderungen von der Entwicklung zur Nicht-Produktion (oder von der Nicht-Produktion in die Produktion) übertragen. Anwendungsänderungen können neue Anwendungs-Images oder Änderungen an der YAML-Konfiguration der Anwendung umfassen. |
Anwendungsoperator |
Der Operator führt Änderungen vom Entwicklungszweig zum Nicht-Produktionszweig oder vom Nicht-Produktionszweig zum Produktionszweig zusammen. Der Operator überwacht den Rollout. |
Mehrmals pro Woche für jede Anwendung |
Änderungen der Anwendungsinfrastruktur von der Entwicklung zur Nicht-Produktion (oder von der Nicht-Produktion zur Produktion) hoch. |
Anwendungsoperator |
Der Operator führt ausgewählte Änderungen vom Entwicklungszweig zum Nicht-Produktionszweig zusammen oder vom Nicht-Produktionszweig zum Produktionszweig. Der Operator überwacht den Rollout. |
Mehrmals pro Quartal für jede Anwendung |
Häufige manuelle Vorgänge
Einige Vorgänge der Entwicklerplattform sind weniger strukturiert und verwenden keine Automatisierung mit einer Entwicklerplattform. Sie können anhand dieses Blueprints eigene Playbooks entwickeln und diese Aufgaben in der Google Cloud Console ausführen.
In der folgenden Tabelle werden diese nicht automatisierten Aufgaben beschrieben. Die Aufgabenhäufigkeit soll illustrativ sein, da die Häufigkeit einer Aufgabe von vielen Faktoren abhängt. Aufgaben werden nicht unbedingt in genauen Intervallen wiederholt.
| Task | Nutzer | Beschreibung | Aufgabenhäufigkeit |
|---|---|---|---|
Definieren Sie eine neue Anwendungsvorlage. |
Entwicklerplattformentwickler |
Der Entwickler ändert eine Anwendungsvorlage, die auf einer Blueprint-Vorlage basiert, oder portiert eine Vorlage in eine neue Sprache. |
Einige Male pro Jahr |
Fehler bei der Dienstlaufzeit in der Entwicklungsumgebung untersuchen |
Symbol: Anwendungsentwickler |
Der Entwickler verwendet den Log-Explorer und den Metrics Explorer in der Google Cloud Console, um die Fehlerlogs, Monitoring-Messwerte und Zeitachsendaten für Mandanten und Anwendungen zu prüfen. |
Mehrmals pro Monat |
Fehler bei der Dienstlaufzeit in Produktions- oder Nicht-Produktionsumgebungen untersuchen. |
Anwendungsoperator |
Der Operator verwendet den Log-Explorer und den Metrics Explorer in der Google Cloud Console, um die Fehlerlogs, Monitoring-Messwerte und Zeitachsendaten für Mandanten und Anwendungen zu prüfen. |
Mehrmals pro Monat |
Build-Fehler untersuchen. |
Anwendungsentwickler |
Der Entwickler ruft den Cloud Build-Verlauf auf, einschließlich des Build-Status und der Logs in der Google Cloud Console. |
Mehrmals pro Woche |
Bereitstellungsfehler in der Entwicklungsumgebung untersuchen |
Anwendungsentwickler |
Der Entwickler zeigt den Cloud Deploy-Release- und Rollout-Verlauf in der Google Cloud Console auf den Erfolgsstatus und die Logs eines Bereitstellungsversuchs an, einschließlich etwaiger Fehler. |
Mehrmals pro Monat |
Bereitstellungsfehler in Nicht-Produktionsumgebungen und Produktionsumgebungen untersuchen |
Anwendungsoperatoren |
Der Operator zeigt den Cloud Deploy-Release- und Rollout-Verlauf in der Google Cloud Console für den Erfolgsstatus und Logs aus einem Bereitstellungsversuch an, einschließlich Fehlerlogs. |
Mehrmals pro Monat |
Stellen Sie eine Verbindung zu Clustern her, um GKE-Probleme zu beheben. |
Entwicklerplattform-Administrator |
Der Administrator verwendet das Connect-Gateway, um eine Verbindung zu privaten Clustern herzustellen. Bei häufigen Problemen wie nicht geplanten Pods kann der Administrator Informationen zu häufigen Problemen (z. B. nicht geplante Pods) in der Google Cloud Console prüfen. |
Mehrmals pro Monat |
Kapazität planen und Kosten optimieren. |
Entwicklerplattform-Administrator |
Der Administrator prüft die GKE-Ressourcennutzung, aggregiert nach Bereich oder Namespace in der Google Cloud Console. |
Wird als monatlich wiederkehrende Aufgabe geplant. |
Größe von Knotenpools ändern, hinzufügen oder entfernen |
Entwicklerplattform-Administrator |
Der Administrator bearbeitet den IaC nach Bedarf und stellt die Anwendungen noch einmal bereit. |
Dies erfolgt in Reaktion auf die Kapazitätsplanung. |
Sicherheitsstatus prüfen |
Entwicklerplattform-Administrator |
Der Administrator prüft mithilfe des GKE-Sicherheitsstatus-Dashboards auf Sicherheitslücken und die Einhaltung von Standards. |
Wird als monatlich wiederkehrende Aufgabe geplant. |
Upgrade der Clustersystem-Softwareversionen (z. B. die Kubernetes-Version). |
Entwicklerplattform-Administrator |
Der Administrator verwendet die GKE-Wartungsfenster und -ausschlüsse, um Upgrades nur zu geplanten Zeiten zuzulassen. Der Administrator verwendet zuerst das Fenster mit dem offenen Upgrade in der Entwicklungsumgebung. Nach der Bewertung des Status des Upgrades aktualisiert der Administrator die Nicht-Produktionsumgebung und dann die Produktionsumgebung. |
Als vierteljährliche wiederkehrende Aufgabe geplant. |
Installieren Sie kritische Clustersicherheitsupdates. |
Keine |
Automatisch, von GKE ausgeführt. |
Einige Male pro Jahr |
Regionales Failover testen |
Administrator der Entwicklerplattform und Anwendungsadministrator |
Die Administratoren planen und initialisieren bei Bedarf einen regionalen Failover der Umgebung. |
Jährlich im Rahmen von Notfallwiederherstellungsübungen |
Region hinzufügen. |
Entwicklerplattformadministrator, Entwicklerplattformentwickler und Anwendungsadministrator |
Der Administrator der Entwicklerplattform stellt zusätzliche GKE-Cluster in der neuen Region bereit. Der Administrator aktualisiert die Anwendungsvorlage, um den neuen Bereitstellungsschritt für relevante Umgebungen hinzuzufügen. Der Anwendungsoperator integriert dann die Änderung und fügt eine Bereitstellungssequenz hinzu, um die neue Region einzubeziehen. |
Sehr selten |
Verschieben Sie sie in eine neue Region. |
Entwicklerplattformadministrator, Entwicklerplattformentwickler und Anwendungsadministrator |
Die Nutzer fügen die neue Region hinzu, wie unter Region hinzufügen beschrieben. Nach dem Testen der neuen Konfiguration entfernen die Nutzer die alte Region. |
Sehr selten |
Wie geht es weiter?
- Informieren Sie sich über das Verwalten von Kosten und Attributionen für die Entwicklerplattform (nächstes Dokument in dieser Reihe).