In diesem Dokument wird die beliebte Methode der Zwölf-Faktoren-Anwendungen beschrieben und wie Sie sie bei der Anwendungsentwicklung in Google Cloud umsetzen. Mit dieser Methode können Sie skalierbare und robuste Anwendungen erstellen, die kontinuierlich und mit maximaler Flexibilität bereitgestellt werden können.
Dieses Dokument richtet sich an Entwickler, die mit Google Cloud, Versionsverwaltung, Continuous Integration und Containertechnologie vertraut sind.
Einführung
Entwickler verschieben Anwendungen in die Cloud. Dadurch werden sie erfahrener beim Erstellen und Bereitstellen cloudnativer Anwendungen. Daraus haben sich einige Best Practices entwickelt, die als zwölf Faktoren bezeichnet werden. Wenn Sie eine Anwendung unter Berücksichtigung dieser Faktoren entwickeln, können Sie Anwendungen in der Cloud bereitstellen, die im Vergleich zu Anwendungen in lokalen Umgebungen, in denen die Bereitstellung neuer Ressourcen länger dauert, portabler und stabiler sind.
Das Entwerfen moderner, cloudnativer Anwendungen erfordert jedoch ein Umdenken bei Softwareengineering, Konfiguration und Deployment im Vergleich zur Entwicklung von Anwendungen für lokale Umgebungen. In diesem Dokument erfahren Sie, wie Sie die zwölf Faktoren auf Ihr Anwendungsdesign anwenden.
Vorteile von Zwölf-Faktoren-Anwendungen
Mit dem 12-Faktoren-Design können Sie auch Komponenten der Anwendung entkoppeln, sodass jede Komponente einfach ersetzt oder nahtlos skaliert werden kann. Da die Faktoren unabhängig von einer Programmiersprache oder einem Softwarestack sind, kann das 12-Faktoren-Design auf eine Vielzahl von Anwendungen angewendet werden.
Die zwölf Faktoren
1 Codebasis
Sie sollten den Code für Ihre Anwendung in einem Versionsverwaltungsystem wie Git oder Mercurial verfolgen. Sie arbeiten an der Anwendung, indem Sie den Code in Ihrer lokalen Entwicklungsumgebung auschecken. Das Speichern des Codes in einem Versionsverwaltungssystem ermöglicht Ihrem Team eine bessere Zusammenarbeit. Dadurch wird ein Audit-Trail mit Änderungen am Code und eine systematische Methode zum Lösen von Zusammenführungskonflikten bereitgestellt sowie ermöglicht, dass der Code auf eine frühere Version zurückgesetzt werden kann. Außerdem bietet sie Platz für Continuous Integration (CI) und die Continuous Deployment (CD).
Auch wenn Entwickler in ihren Entwicklungsumgebungen möglicherweise an verschiedenen Versionen des Codes arbeiten, ist die "Source of Truth" immer der Code im Versionsverwaltungssystem. Der Code im Repository wird erstellt, getestet und bereitgestellt. Die Anzahl der Repositories ist unabhängig von der Anzahl der Umgebungen. Der Code im Repository wird verwendet, um einen einzelnen Build zu erstellen, der mit einer umgebungsspezifischen Konfiguration kombiniert wird, um einen unveränderlichen Release zu erstellen. An diesem können keine Änderungen vorgenommen werden, einschließlich der Konfiguration, und er kann dann in einer Umgebung bereitgestellt werden. Für den Release erforderliche Änderungen sollten zu einem neuen Release führen.
2. Abhängigkeiten
Bei Abhängigkeiten für Zwölf-Faktoren-Anwendungen gibt es zwei Überlegungen: Abhängigkeitsdeklaration und Abhängigkeitsisolation.
Zwölf-Faktoren-Anwendungen sollten niemals implizite Abhängigkeiten haben. Sie sollten alle Abhängigkeiten explizit deklarieren und in die Versionsverwaltung einchecken. Auf diese Weise können Sie schnell und wiederholbar mit dem Code beginnen und Änderungen an Abhängigkeiten einfach nachvollziehen. Viele Programmiersprachen bieten eine Möglichkeit, Abhängigkeiten explizit zu deklarieren, z. B. Pip für Python und Bundler für Ruby.
Sie sollten auch eine Anwendung und ihre Abhängigkeiten isolieren, indem Sie sie in einen Container verpacken. Mit Containern können Sie eine Anwendung und ihre Abhängigkeiten von ihrer Umgebung isolieren und dafür sorgen, dass die Anwendung trotz aller Unterschiede zwischen Entwicklungs- und Staging-Umgebungen einheitlich funktioniert.
Artifact Registry ist ein vollständig verwalteter privater Artefaktverwaltungsdienst, der verschiedene Arten von Artefakten wie Container-Images, Sprachpakete (wie Maven und npm) und Betriebssystempakete unterstützt (wie RPM). Sie können Cloud IAM mit Artifact Registry mit detaillierter Zugriffssteuerung verwenden, um die Ergebnisse Ihrer CI/CD-Builds und deren Abhängigkeiten zu verwalten. Mit Artifact Analysis werden Sicherheitslücken in Container-Images erkannt, die in Artifact Registry hochgeladen werden. So können Sie dafür sorgen, dass Ihre Container-Images sicher bereitgestellt werden können.
Bei bestehenden CI/CD-Integrationen können Sie auch vollautomatische Pipelines einrichten, um schnelles Feedback zu erhalten. Sie können Images in ihre Registry schieben und dann über einen HTTP-Endpunkt von jedem Computer ziehen, egal ob es sich um eine Compute Engine-Instanz oder Ihre eigene Hardware handelt.
3. Konfiguration
Jede moderne Anwendung erfordert eine Konfiguration. Normalerweise haben Sie für jede Umgebung, z. B. Entwicklung, Test und Produktion, unterschiedliche Konfigurationen. Diese Konfigurationen umfassen normalerweise Anmeldedaten für Dienstkonten und Ressourcen-Handles für Sicherungsdienste wie Datenbanken.
Die Konfigurationen für jede Umgebung sollten sich außerhalb des Codes befinden und nicht in die Versionsverwaltung eingecheckt werden. Jeder arbeitet nur an einer Version des Codes, aber Sie haben mehrere Konfigurationen. Die zu verwendende Konfiguration wird von der Depoloyment-Umgebung bestimmt. Dadurch kann in jeder Umgebung eine Version der Binärdatei bereitgestellt werden, wobei der einzige Unterschied die Laufzeitkonfiguration ist. Eine einfache Möglichkeit, um zu prüfen, ob die Konfiguration ordnungsgemäß externalisiert wurde, besteht darin, zu prüfen, ob der Code ohne Offenlegung von Anmeldedaten veröffentlicht werden kann.
Eine Möglichkeit zum Externalisieren der Konfiguration ist das Erstellen von Konfigurationsdateien. Konfigurationsdateien sind jedoch normalerweise spezifisch für eine Sprache oder ein Entwicklungs-Framework.
Ein besserer Ansatz besteht darin, die Konfiguration in Umgebungsvariablen zu speichern. Diese können zur Laufzeit einfach für jede Umgebung geändert werden, werden wahrscheinlich nicht in die Versionsverwaltung eingecheckt und sind unabhängig von der Programmiersprache und dem Entwicklungs-Framework. In Google Kubernetes Engine (GKE) können Sie ConfigMaps verwenden. Auf diese Weise können Sie Umgebungsvariablen, Portnummern, Konfigurationsdateien, Befehlszeilenargumente und andere Konfigurationsartefakte zur Laufzeit an die Container und Systemkomponenten Ihrer Pods binden.
Cloud Functions und Cloud Run unterstützen die Verwendung von Umgebungsvariablen. Sie können Konfigurationen externalisieren und über die Google Cloud Console oder mit dem Google Cloud SDK ändern.
4. Sicherungsdienste
Jeder Dienst, den die Anwendung im Rahmen des normalen Betriebs nutzt, z. B. Dateisysteme, Datenbanken, Caching-Systeme und Nachrichtenwarteschlangen, sollte als Dienst aufgerufen und in der Konfiguration externalisiert werden. Sie sollten sich diese Sicherungsdienste als Abstraktionen für die zugrunde liegende Ressource vorstellen. Wenn die Anwendung beispielsweise Daten in den Speicher schreibt und den Speicher als Sicherungsdienst behandelt, können Sie den zugrunde liegenden Speichertyp nahtlos ändern, da er von der Anwendung entkoppelt ist. Sie können dann eine Änderung vornehmen, z. B. von einer lokalen PostgreSQL-Datenbank zu Cloud SQL for PostgreSQL wechseln, ohne den Anwendungscode zu ändern.
5. Build, Release, Ausführung
Es ist wichtig, den Prozess des Software-Deployments in drei Phasen zu unterteilen: Build, Release und Ausführung. Jede Phase sollte zu einem Artefakt führen, das eindeutig identifizierbar ist. Jedes Deployment sollte mit einem bestimmten Release verknüpft werden, der sich aus der Kombination einer Umgebungskonfiguration mit einem Build ergibt. Dies ermöglicht einfache Rollbacks und einen sichtbaren Audit-Trail des Verlaufs jedes Produktions-Deployments.
Sie können die Build-Phase manuell auslösen. Normalerweise wird sie jedoch automatisch ausgelöst, wenn Sie Code mit einem Commit übertragen, der alle erforderlichen Tests bestanden hat. Die Build-Phase nimmt den Code, ruft die erforderlichen Bibliotheken und Assets ab und verpackt sie in eine eigenständige Binärdatei oder einen Container. Das Ergebnis der Build-Phase ist ein Build-Artefakt.
Wenn die Build-Phase abgeschlossen ist, kombiniert die Release-Phase das Build-Artefakt mit der Konfiguration einer bestimmten Umgebung. Dadurch wird ein Release erstellt. Der Release kann von einer Continuous Deployment-Anwendung automatisch in der Umgebung bereitgestellt werden. Sie können den Release auch über dieselbe Continuous Deployment-Anwendung auslösen.
Schließlich startet die Ausführungsphase den Release. Wenn Sie beispielsweise ein Deployment in GKE ausführen, kann Cloud Build den Build-Schritt gke-deploy für das Deployment in Ihrem GKE-Cluster aufrufen. Cloud Build kann Build-, Release- und Ausführungsphasen in mehreren Sprachen und Umgebungen mithilfe von Build-Konfigurationsdateien im YAML- oder JSON-Format verwalten und automatisieren.
Darüber hinaus können Sie Cloud Deploy verwenden, den vollständig verwalteten Dienst für Continuous Delivery an GKE, Cloud Run und GKE Enterprise. Mit Cloud Deploy können Sie eine Lieferpipeline erstellen, die Genehmigungsschritte und nahtlose Hochstufung in mehrere Umgebungen enthält. Darüber hinaus unterstützt Cloud Deploy ein Rollback in einem Schritt für eine bereitgestellte Anwendung in einem beliebigen Ziel.
6. Verfahren
Sie führen Zwölf-Faktoren-Anwendungen in der Umgebung als einen oder mehrere Prozesse aus. Diese Prozesse sollten zustandslos sein und dürfen keine Daten miteinander teilen. Dadurch können die Anwendungen durch Replikation ihrer Prozesse vertikal skaliert werden. Durch das Erstellen zustandsloser Anwendungen werden auch Prozesse in der gesamten Computing-Infrastruktur portierbar.
Wenn Sie an das Konzept von fixierten Sitzungen gewöhnt sind, müssen Sie Ihre Meinung über den Umgang mit und die Speicherung von Daten ändern. Da Prozesse jederzeit gelöscht werden können, können Sie sich nicht darauf verlassen, dass der Inhalt des lokalen Speichers verfügbar ist oder dass nachfolgende Anfragen von demselben Prozess verarbeitet werden. Daher müssen Sie alle Daten, die in einem externen Sicherungsdienst wie einer Datenbank wiederverwendet werden müssen, explizit speichern.
Wenn Sie Daten speichern möchten, können Sie Memorystore und Filestore als Sicherungsdienst verwenden, um den Status für Ihre Anwendungen im Cache zu speichern und gemeinsame Daten zwischen Prozessen zu teilen, um eine lose Kopplung zu fördern.
7. Portbindung
In Nicht-Cloud-Umgebungen werden Webanwendungen häufig zur Ausführung in Anwendungscontainern wie GlassFish, Apache Tomcat und Apache HTTP Server geschrieben. Im Gegensatz dazu sind Zwölf-Faktoren-Anwendungen nicht auf externe Anwendungscontainer angewiesen. Stattdessen wird die Webserverbibliothek als Teil der Anwendung selbst gebündelt.
Es ist eine Best Practices für die Architektur, dass Dienste eine durch die Umgebungsvariable PORT angegebene Portnummer verfügbar machen.
Anwendungen, die Portbindungen exportieren, können Portbindungsinformationen extern (als Umgebungsvariablen) nutzen, wenn sie das PaaS-Modell verwenden. In Google Cloud können Sie Anwendungen auf Plattformdiensten wie Compute Engine, GKE, App Engine oder Cloud Run bereitstellen.
In diesen Diensten leitet eine Routingebene Anfragen von einem öffentlichen Hostnamen an Ihre portgebundenen Webprozesse weiter. Wenn Sie beispielsweise Ihre Anwendungen in App Engine bereitstellen, deklarieren Sie Abhängigkeiten, um der Anwendung eine Webserverbibliothek hinzuzufügen, z. B. Express (für Node.js), Flask und Gunicorn (für Python) oder Jetty (für Java).
Sie sollten Portnummern in Ihrem Code nicht hartcodieren. Stattdessen sollten Sie die Portnummern in der Umgebung angeben, z. B. in einer Umgebungsvariablen. Dadurch werden Ihre Anwendungen portierbar, wenn Sie sie in Google Cloud ausführen.
Da Kubernetes eine integrierte Diensterkennung hat, können Sie in Kubernetes Portbindungen abstrahieren, indem Sie Dienstports Containern zuordnen. Die Diensterkennung erfolgt über interne DNS-Namen.
Anstatt den Port, den der Webserver überwacht, hartzucodieren, verwendet die Konfiguration eine Umgebungsvariable. Das folgende Code-Snippet einer App Engine-Anwendung zeigt, wie ein Portwert akzeptiert wird, der in einer Umgebungsvariablen übergeben wird.
const express = require('express')
const request = require('got')
const app = express()
app.enable('trust proxy')
const PORT = process.env.PORT || 8080
app.listen(PORT, () => {
console.log('App listening on port ${PORT}')
console.log('Press Ctrl+C to quit.')
})
8. Gleichzeitigkeit
Sie sollten Ihre Anwendung anhand von Prozesstypen wie Hintergrund-, Web- und Worker-Prozessen in unabhängige Prozesse aufteilen. So kann Ihre Anwendung je nach Arbeitslastanforderungen skaliert werden. Die meisten cloudnativen Anwendungen können bei Bedarf skaliert werden. Sie sollten die Anwendung als mehrere verteilte Prozesse entwerfen, die Arbeitsblöcke unabhängig ausführen und durch Hinzufügen weiterer Prozesse skalieren können.
In den folgenden Abschnitten werden einige Konstrukte beschrieben, mit denen Anwendungen skaliert werden können. Anwendungen, die auf den Grundsätzen der Verfügbarkeit und Zustandslosigkeit basieren, sind gut positioniert, um von diesen Konstrukten horizontaler Skalierung zu profitieren.
Cloud Run verwenden
Cloud Run ist eine Computing-Plattform, mit der Sie Container direkt auf der von Google verwalteten Infrastruktur ausführen können. Cloud Run unterstützt zwei Möglichkeiten zum Ausführen des Codes. Cloud Run services wird kontinuierlich als Dienst ausgeführt. Die Dienste werden in der Regel verwendet, um auf Webanfragen oder Ereignisse zu reagieren. Cloud Run jobs führt Code aus, der bestimmte Jobaufgaben ausführt, und der Vorgang wird beendet, wenn die Arbeit abgeschlossen ist. Cloud Run bietet auch Cloud Scheduler zum Ausführen von Batchjobs. Diese Struktur eignet sich gut zur Implementierung von Gleichzeitigkeit und zur Skalierung möglicher Dienstarchitekturen.
Weitere Informationen zu Cloud Run.
Cloud Functions verwenden
Cloud Functions sind zustandslose, zweckgebundene Funktionen, die in Google Cloud ausgeführt werden, wobei die zugrunde liegende Architektur für Sie von Google verwaltet wird. Cloud Functions reagiert auf Ereignistrigger wie einen Upload in einen Cloud Storage-Bucket oder eine Pub/Sub-Nachricht. Jeder Funktionsaufruf antwortet auf ein einzelnes Ereignis oder eine Anfrage.
Cloud Functions verarbeitet eingehende Anfragen, indem diese Instanzen Ihrer Funktion zugewiesen werden. Wenn das Volumen der eingehenden Anfragen die Anzahl der vorhandenen Instanzen überschreitet, startet Cloud Functions möglicherweise neue Instanzen, um Anfragen zu verarbeiten. Dieses automatische, vollständig verwaltete Skalierungsverhalten ermöglicht es Cloud Functions, viele Anfragen parallel zu verarbeiten, wobei jede Anfrage eine andere Instanz Ihrer Funktion verwendet.
App Engine verwenden
Mit App Engine können Sie Ihre Anwendungen in der verwalteten Infrastruktur von Google Cloud hosten. Instanzen sind die Recheneinheiten, mit denen App Engine Ihre Anwendung automatisch skaliert. Ihre Anwendung kann jederzeit auf einer Instanz oder auf vielen Instanzen ausgeführt werden, wobei Anfragen über alle Instanzen verteilt werden.
Der App Engine-Planer entscheidet, wie jede neue Anfrage beantwortet wird. Der Planer kann eine vorhandene Instanz verwenden, das heißt, entweder eine inaktive Instanz oder eine Instanz, die gleichzeitige Anfragen akzeptiert. Er kann auch die Anfrage in eine Warteschlange für ausstehende Anfragen stellen oder eine neue Instanz für diese Anfrage starten. Bei der Entscheidung werden die Anzahl der verfügbaren Instanzen, die Geschwindigkeit, mit der Ihre Anwendung Anfragen beantwortet (ihre Latenz), und die Zeit, die zum Starten einer neuen Instanz erforderlich ist, berücksichtigt.
Wenn Sie die automatische Skalierung verwenden, können Sie einen Ausgleich zwischen Leistung und Kosten schaffen, indem Sie die Ziel-CPU-Auslastung, den Zieldurchsatz und die maximale Anzahl gleichzeitiger Anfragen festlegen.
Sie können den Skalierungstyp in der Datei app.yaml angeben, die Sie für Ihre Dienstversion hochladen. Anhand dieser Konfigurationseingabe verwendet die App Engine-Infrastruktur dynamische oder residente Instanzen. Weitere Informationen zu Skalierungstypen finden Sie in der App Engine-Dokumentation.
GKE-Autoscaling verwenden
Es gibt einige wichtige Kubernetes-Konstrukte, die für Skalierungsprozesse gelten:
Horizontales Pod-Autoscaling (HPA). Kubernetes kann so konfiguriert werden, dass die Anzahl der im Cluster ausgeführten Pods anhand von Standard- oder benutzerdefinierten Messwerten skaliert wird. Dies ist praktisch, wenn Sie auf eine variable Auslastung in Ihrem GKE-Cluster reagieren müssen.
Autoscaling für Knoten. Bei größerer Nachfrage müssen Sie Ihren Cluster möglicherweise skalieren, um mehr Pods aufzunehmen. Mit GKE können Sie Ihren Cluster deklarativ für die Skalierung konfigurieren. Wenn Autoscaling aktiviert ist, skaliert GKE Knoten automatisch, wenn zusätzliche Pods geplant werden müssen und vorhandene Knoten diese nicht unterstützen können. GKE skaliert Knoten entsprechend den von Ihnen konfigurierten Schwellenwerten auch herunter, wenn die Clusterlast geringer wird.
Jobs. GKE unterstützt Kubernetes-Jobs. Ein Job kann allgemein als eine Aufgabe definiert werden, die einen oder mehrere Pods benötigt, um die Aufgabe auszuführen. Der Job kann einmal oder nach einem Zeitplan ausgeführt werden. Die Pods, in denen der Job ausgeführt wird, werden nach Abschluss des Jobs entfernt. Die YAML-Datei, die den Job konfiguriert, gibt Details zur Fehlerbehandlung, zur Parallelität, zur Vorgehensweise bei Neustarts usw. an.
Compute Engine verwenden
Alternativ können Sie Ihre Anwendungen in Compute Engine bereitstellen und verwalten. In diesem Fall können Sie Ihre Anwendung so skalieren, dass sie auf verschiedene Ladevorgänge mit verwalteten Instanzgruppen (MIG) anhand der CPU-Auslastung, den bearbeiteten Anfragen oder anderen Telemetriesignalen Ihrer Anwendung reagiert.
Die folgende Abbildung zeigt die wichtigsten Features verwalteter Instanzgruppen.
Durch die Verwendung von verwalteten Instanzgruppen kann Ihre Anwendung auf den eingehenden Bedarf skaliert und hochverfügbar sein. Dieses Konzept eignet sich gut für zustandslose Anwendungen wie Web-Front-Ends und für Batch-basierte Hochleistungsarbeitslasten.
9. Verfügbarkeit
Anwendungen, die in der Cloud-Infrastruktur ausgeführt werden, sollten Sie zusammen mit der zugrunde liegenden Infrastruktur als verfügbare Ressourcen behandeln. Ihre Anwendungen sollten den vorübergehenden Verlust der zugrunde liegenden Infrastruktur bewältigen und ordnungsgemäß heruntergefahren und neu gestartet werden können.
Folgende Grundprinzipien sind zu berücksichtigen:
- Entkoppeln Sie Funktionen wie die Statusverwaltung und die Speicherung von Transaktionsdaten mithilfe von Sicherungsdiensten. Weitere Informationen finden Sie weiter oben in diesem Dokument unter Sicherungsdienste.
- Verwalten Sie Umgebungsvariablen außerhalb der Anwendung, damit sie zur Laufzeit verwendet werden können.
- Achten Sie darauf, dass die Startzeit möglichst kurz ist. Dies bedeutet, dass Sie entscheiden müssen, wie viele Ebenen in Images eingebunden werden sollen, wenn Sie virtuelle Maschinen verwenden, z. B. öffentliche oder benutzerdefinierte Images. Diese Entscheidung ist für jede Anwendung spezifisch und sollte auf den Aufgaben basieren, die von Startskripts ausgeführt werden. Wenn Sie beispielsweise mehrere Pakete oder Binärdateien herunterladen und während des Starts initialisieren, wird ein größerer Teil Ihrer Startzeit für die Ausführung dieser Aufgaben verwendet.
- Nutzen Sie native Features von Google Cloud, um Infrastrukturaufgaben auszuführen. Sie können beispielsweise Rolling Updates in GKE verwenden und Ihre Sicherheitsschlüssel mit dem Cloud Key Management Service (Cloud KMS) verwalten.
Verwenden Sie das SIGTERM-Signal (sofern verfügbar), um ein ordnungsgemäßes Herunterfahren zu starten. Wenn App Engine Flex beispielsweise eine Instanz herunterfährt, sendet es normalerweise ein STOP-Signal (SIGTERM) an den Anwendungscontainer. Ihre Anwendung kann dieses Signal verwenden, um Bereinigungsaktionen durchzuführen, bevor der Container heruntergefahren wird. Ihre Anwendung muss nicht auf das SIGTERM-Ereignis reagieren. Unter normalen Bedingungen wartet das System bis zu 30 Sekunden, bis die Anwendung beendet wird, und sendet dann ein KILL-Signal (SIGKILL).
Das folgende Snippet in einer App Engine-Anwendung zeigt, wie Sie das SIGTERM-Signal abfangen können, um offene Datenbankverbindungen zu schließen.
const express = require('express') const dbConnection = require('./db') // Other business logic related code app.listen(PORT, () => { console.log('App listening on port ${PORT}') console.log('Press Ctrl+C to quit.') }) process.on('SIGTERM', () => { console.log('App Shutting down') dbConnection.close() // Other closing of database connection })
10. Umgebungsparität
Unternehmensanwendungen bewegen sich während ihres Entwicklungszyklus in verschiedenen Umgebungen. In der Regel handelt es sich dabei um Entwicklungs-, Test- und Staging- sowie um Produktionsumgebungen. Es empfiehlt sich, diese Umgebungen so ähnlich wie möglich zu halten.
Die Umgebungsparität ist ein Feature, das die meisten Entwickler als selbstverständlich betrachten. Jedoch wird es immer schwieriger, die Umgebung zu erhalten, wenn Unternehmen wachsen und sich ihre IT-Systeme weiterentwickeln.
Die Erhaltung der Umgebungsparität ist in den letzten Jahren einfacher geworden, da Entwickler die Versionsverwaltung, die Konfigurationsverwaltung und Vorlagenkonfigurationsdateien genutzt haben. Dies vereinfacht die konsistente Bereitstellung einer Anwendung in mehreren Umgebungen. Mit Docker und Docker Compose können Sie beispielsweise dafür sorgen, dass die Form und Instrumentierung des Anwendungs-Stacks umgebungsübergreifend beibehalten werden.
In der folgenden Tabelle sind die Google Cloud-Dienste und -Tools aufgeführt, die Sie beim Entwerfen von Anwendungen für die Ausführung in Google Cloud verwenden können. Diese Komponenten dienen verschiedenen Zwecken und helfen Ihnen beim Erstellen von Workflows, die Ihre Umgebungen einheitlicher machen.
| Google Cloud-Komponente | Purpose |
|---|---|
| Artifact Registry | Ein universeller Paketmanager für alle Ihre Build-Artefakte und Abhängigkeiten. |
| Cloud Build | Ein vollständig verwalteter Dienst, der Ihre Builds in der Google Cloud-Infrastruktur ausführt. |
| Cloud KMS | Speichern Ihrer kryptografischen Schlüssel in einem zentralen Cloud-Dienst zur direkten Verwendung durch andere Cloud-Ressourcen und -Anwendungen. |
| Cloud Storage | Speichern von benutzerdefinierten Images, die Sie aus Quelllaufwerken, Images, Snapshots oder Images erstellen, die in Cloud Storage gespeichert sind. Sie können diese Images verwenden, um VM-Instanzen für Ihre Anwendungen zu erstellen. |
| Cloud Deploy | Bieten Sie die automatisierte Bereitstellung Ihrer Anwendungen in einer Reihe mehrerer Zielumgebungen in einer definierten Reihenfolge. |
11. Logs
Logs informieren Sie über den Zustand Ihrer Anwendungen. Es ist wichtig, die Erfassung, Verarbeitung und Analyse von Logs von der Kernlogik Ihrer Anwendungen zu entkoppeln. Das Entkoppeln von Logging ist besonders nützlich, wenn Ihre Anwendungen eine dynamische Skalierung erfordern und in öffentlichen Clouds ausgeführt werden. Das liegt daran, dass die Verwaltung des Speicherorts für Logs und die Aggregation von verteilten und häufig sitzungsspezifischen VMs entfällt.
Google Cloud bietet eine Reihe von Tools, die Sie bei der Erfassung, Verarbeitung und strukturierten Analyse von Logs unterstützen. Es empfiehlt sich, den Cloud Logging-Agent in Ihren Compute Engine-VMs zu installieren. Der Agent ist standardmäßig in App Engine- und GKE-VM-Images vorinstalliert. Der Agent überwacht einen vorkonfigurierten Satz von Logging-Speicherorten. Die Logs, die von Ihren in der VM ausgeführten Anwendungen erstellt werden, werden erfasst und an Cloud Logging gestreamt.
Wenn das Logging für einen GKE-Cluster aktiviert ist, wird auf jedem Knoten, der Teil des Clusters ist, ein Logging-Agent bereitgestellt. Der Agent sammelt Logs, reichert sie mit relevanten Metadaten an und speichert sie in einem Datenspeicher. Diese Logs können mit Cloud Logging geprüft werden. Wenn Sie mehr Kontrolle darüber haben möchten, was protokolliert wird, können Sie Fluentd-DaemonSets verwenden.
Weitere Informationen finden Sie unter Logging-Agent konfigurieren.
12. Verwaltungsprozesse
Verwaltungsprozesse bestehen in der Regel aus einmaligen oder zeitlich wiederkehrenden Aufgaben wie dem Erstellen von Berichten, dem Ausführen von Batch-Skripts, dem Starten von Datenbanksicherungen und der Migration von Schemas. Der Verwaltungsprozessfaktor im Leitfaden zu Zwölf-Faktoren-Anwendungen wurde im Hinblick auf einmalige Aufgaben geschrieben. Für cloudnative Anwendungen wird dieser Faktor beim Erstellen wiederkehrenden Aufgaben relevanter. Die Anleitung in diesem Abschnitt ist auf Aufgaben wie diese ausgerichtet.
Planmäßige Trigger werden oft als Cronjobs erstellt und von den Anwendungen selbst verarbeitet. Dieses Modell funktioniert. Es führt jedoch eine Logik ein, die eng mit der Anwendung verbunden ist und Wartung und Koordinierung erfordert, insbesondere wenn Ihre Anwendungen über Zeitzonen verteilt sind.
Daher sollten Sie bei der Entwicklung für Verwaltungsprozesse die Verwaltung dieser Aufgaben von der Anwendung selbst entkoppeln. Verwenden Sie je nach den Tools und der Infrastruktur, auf der Ihre Anwendung ausgeführt wird, die folgenden Vorschläge:
- Wenn Sie Anwendungen in GKE ausführen möchten, starten Sie separate Container für Verwaltungsaufgaben. Sie können die Vorteile von CronJobs in GKE nutzen. CronJobs werden in sitzungsspezifischen Containern ausgeführt und ermöglichen Ihnen die Steuerung des Zeitdauer, der Ausführungshäufigkeit und der Wiederholungsversuche, wenn Jobs fehlschlagen oder zu lange dauern.
- Zum Hosten von Anwendungen in App Engine oder Compute Engine können Sie den Triggermechanismus auslagern und einen Endpunkt erstellen, der vom Trigger aufgerufen wird. Dieser Ansatz hilft dabei, eine Grenze zu definieren, wofür die Anwendungen zuständig sind, im Gegensatz zum einzelnen Zweck des Endpunkts. Cloud Tasks ist ein vollständig verwalteter, asynchroner Dienst zur Aufgabenausführung, mit dem Sie dieses Muster mit App Engine implementieren können. Sie können auch Cloud Scheduler verwenden, einen vollständig verwalteten Planer für Unternehmen in Google Cloud, um planmäßige Vorgänge auszulösen.
Über die zwölf Faktoren hinaus
Die in diesem Dokument beschriebenen zwölf Faktoren bieten eine Anleitung zur Erstellung cloudnativer Anwendungen. Diese Anwendungen sind die grundlegenden Bausteine eines Unternehmens.
In einem typischen Unternehmen gibt es viele dieser Anwendungen, die oft von mehreren Teams gemeinsam entwickelt werden, um Geschäftsfunktionen bereitzustellen. Es ist wichtig, einige zusätzliche Prinzipien während des Lebenszyklus der Anwendungsentwicklung festzulegen und nicht im Nachhinein darauf zu achten, wie Anwendungen miteinander kommunizieren und wie sie gesichert und der Zugriff gesteuert wird.
In den folgenden Abschnitten werden einige dieser zusätzlichen Überlegungen beschrieben, die Sie beim Entwerfen und Entwickeln von Anwendungen berücksichtigen sollten.
API-orientiert denken
Anwendungen kommunizieren über APIs. Überlegen Sie beim Erstellen von Anwendungen, wie die Anwendung in ihrer Umgebung genutzt wird, und beginnen Sie mit dem Entwerfen einer API-Strategie. Ein gutes API-Design erleichtert die Nutzung der API durch Anwendungsentwickler und externe Stakeholder. Es empfiehlt sich, die API mit der OpenAPI-Spezifikation zu dokumentieren, bevor Sie Code implementieren.
APIs extrahieren die zugrunde liegende Anwendungsfunktionalität. Ein gut durchdachter API-Endpunkt sollte die verarbeitenden Anwendungen von der Anwendungsinfrastruktur isolieren und entkoppeln, die den Dienst bereitstellt. Durch diese Entkopplung können Sie den zugrunde liegenden Dienst und seine Infrastruktur unabhängig ändern, ohne die Nutzer der Anwendung zu beeinträchtigen.
Es ist wichtig, die von Ihnen entwickelten APIs zu katalogisieren, zu dokumentieren und zu veröffentlichen, damit die Nutzer der APIs die APIs erkennen und verwenden können. Im Idealfall sollten die API-Nutzer eigenständig arbeiten können. Richten Sie dazu ein Entwicklerportal ein. Ein Entwicklerportal dient als Einstiegspunkt für alle API-Nutzer: intern für das Unternehmen oder extern für Nutzer wie Entwickler aus Ihrem Partnernetzwerk.
Mit Apigee, der API-Verwaltungssuite von Google, können Sie den gesamten Lebenszyklus Ihrer APIs vom Design über den Build bis zur Veröffentlichung verwalten.
Sicherheit
Der Sicherheitsbereich ist weit gefasst und schließt Betriebssysteme, Netzwerke und Firewalls, Daten- und Datenbanksicherheit, Anwendungssicherheit sowie Identitäts- und Zugriffsverwaltung ein. Es ist von entscheidender Bedeutung, alle Dimensionen der Sicherheit im Netzwerk eines Unternehmens zu berücksichtigen.
Aus Sicht der Anwendung bieten APIs Zugriff auf die Anwendungen in Ihrem Unternehmen. Sie sollten daher darauf achten, dass diese Bausteine Sicherheitsaspekte beim Anwendungsdesign und beim Build-Prozess berücksichtigen. Überlegungen, wie Sie den Zugriff auf Ihre Anwendung schützen können:
- Transport Layer Security (TLS). Verwenden Sie TLS, um Daten bei der Übertragung zu schützen. Sie können für Ihre Unternehmensanwendungen gegenseitiges TLS verwenden. Dies ist einfacher, wenn Sie Service Meshes wie Istio in Google Kubernetes Engine verwenden. In einigen Anwendungsfällen werden auch zulässige und abgelehnte Listen anhand von IP-Adressen als zusätzliche Sicherheitsebene erstellt. Die Transportsicherheit umfasst auch den Schutz Ihrer Dienste vor DDoS- und Bot-Angriffen.
- Sicherheit von Anwendungen und Endnutzern Die Transportsicherheit sorgt für Sicherheit von Daten bei der Übertragung und stellt Vertrauen her. Es empfiehlt sich jedoch, Sicherheit auf Anwendungsebene hinzuzufügen, um den Zugriff auf Ihre Anwendung je nach Nutzer der Anwendung zu steuern. Die Nutzer können andere Anwendungen, Mitarbeiter, Partner oder die Endkunden Ihres Unternehmens sein. Sie können die Sicherheit mithilfe von API-Schlüsseln zur Nutzung von Apps, zertifizierungsbasierter Authentifizierung und Autorisierung, JSON Web Tokens-Austausch (JWTs) oder Security Assertion Markup Language (SAML) durchsetzen.
Die Sicherheitslandschaft entwickelt sich innerhalb eines Unternehmens ständig weiter, was das Codieren von Sicherheitskonstrukten in Ihren Anwendungen erschwert. API-Verwaltungsprodukte wie Apigee schützen APIs auf allen in diesem Abschnitt genannten Ebenen.
Die Sicherheit der Softwarelieferkette ist ein schwieriges Problem. Es ist wichtig, Vorkehrungen zu treffen. Software Delivery Shield ist eine vollständig verwaltete End-to-End-Lösung, die die Sicherheit der Softwarelieferkette während des gesamten Lebenszyklus der Softwareentwicklung verbessert. Es bietet unter anderen die folgenden Dienste:
Cloud Build. Unterstützt SLSA-Level 3-Builds für Container-Images und generiert eine authentifizierte und fälschungssichere Build-Herkunft für containerisierte Anwendungen.
Assured Open-Source-Software. Es reduziert das Risiko für Ihre Softwarelieferkette mit denselben OSS-Paketen, die Google verwendet.
Darüber hinaus stehen verschiedene Dienste und Funktionen zur Verfügung, um die Sicherheit Ihrer Softwarelieferkette zu verbessern.
Weitere Informationen zur Sicherheit der Softwarelieferkette. Übersicht zu Software Delivery Shield.
Nächste Schritte
- Sehen Sie sich die Demoanwendung für Mikrodienste an, die auf Prinzipien zu Zwölf-Faktoren-Anwendungen basiert und mit Google Cloud-Produkten und -Diensten erstellt ist.
- Im Cloud Architecture Center finden Sie Referenzarchitekturen, Anleitungen und Best Practices zum Erstellen oder Migrieren von Arbeitslasten in Google Cloud.
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center