Auf einen Blick: Die 12-Faktor-App-Methodik bietet Richtlinien für den Aufbau skalierbarer Cloud-Anwendungen und legt den Schwerpunkt auf Bereitstellung und Wartung. Wichtige Prinzipien umfassen Abhängigkeitsisolation, Konfigurationsmanagement und Entwegbarkeit von Prozessen, die die Anwendungsrobustheit und Anpassungsfähigkeit verbessern.
- Konzentrieren Sie sich auf eigenständige Anwendungen mit isolierten Abhängigkeiten.
- Fördern Sie schnellen Start und eine reibungslose Abschaltung von Prozessen.
Das Schreiben von Anwendungscode ist älter als die meisten Cloud-Lösungen – Lösungen, für die die meisten Anwendungsprogrammierer heutzutage speziell schreiben.
Um mit dieser Dissonanz umzugehen, hat sich die 12-Faktor-App-Methodik entwickelt. Die 12 Faktoren sind ein Ansatz, der Programmierern hilft, moderne Apps deklarativ zu schreiben, indem sie klare Verträge verwenden, die in der Cloud bereitgestellt werden.
In diesem Artikel stelle ich die 12-Faktor-App-Methodik vor und biete eine übergeordnete Zusammenfassung ihrer Prinzipien an.
Was ist die 12-Faktor-App-Methodik?
Im Jahr 2012 führten Programmierer bei Heroku die 12-Faktor-App-Methodik ein. Diese Programmierer haben Hunderte von Apps entwickelt und eingesetzt, diese Methodik entwickelt, basierend auf ihrer Erfahrung, SaaS-Apps "in freier Wildbahn" gesehen zu haben.
Diese Gruppe betrachtet die Methodik als eine Triangulation von:
- Ideale Praktiken zur Unterstützung der App-Entwicklung
- Die Dynamiken, die entstehen, wenn eine App organisch wächst,
- Die Beziehung und Zusammenarbeit zwischen Codebase-Entwicklern
[Helix-Video]
Ihre Ziele sind zweifach:
- Um Kosten für Softwareerosion zu vermeiden
- Das Bewusstsein für systemische Probleme zu schärfen, die sie in der modernen App-Entwicklung beobachtet haben,
Die Gruppe verweist auf zwei inspirierende Quellen: Patterns of Enterprise Application Architecture und Refactoring, beide vom professionellen Entwickler Martin Fowler.
Und nun werde ich jeden der 12 Faktoren vorstellen.
Prinzip I. Codebasis
"Eine Codebasis wird in der Versionskontrolle verfolgt, viele Deployments"
Deine Codebasis sollte ein logisches Versionskontrollsystem haben, das leicht zu verstehen ist.
Jede Bereitstellung sollte ein eigenes Code-Repository haben, das in mehreren Umgebungen bereitgestellt werden kann. Vermeiden Sie es, mehrere Anwendungen im selben Repository zu speichern. Dadurch ist Versionskontrolle nahezu unverständlich und Versionen werden verheddert, was zu nicht wertschöpfenden Arbeiten führt.
Prinzip II. Abhängigkeiten
"Erklärt und isoliert ausdrücklich Abhängigkeiten"
Dieses Prinzip besagt, dass man sich niemals auf die implizite Existenz systemweiter Pakete verlassen sollte. Stattdessen"
- Stellen Sie sicher, dass app-spezifische Bibliotheken verfügbar sind
- Überprüfe, dass du an das Betriebssystem gezahlt hast
- Überprüfen Sie, ob benötigte Systembibliotheken wie curl oder ImageMagick verfügbar sind. (Es gibt keine Garantie, dass diese auf jedem System existieren, auf dem die App in Zukunft laufen könnte.)
Insgesamt muss eine 12-Faktor-App eigenständig sein. Die Anwendung sollte ausreichend isoliert sein, um Interaktionen mit widersprüchlichen Bibliotheken, die auf dem Hostrechner installiert sind, zu vermeiden.
Schauen wir uns ein Beispiel an. In Python kann man Deklaration und Isolation erreichen, indem man Pip bzw. Virtualenv verwendet. Um dieses Prinzip zu erfüllen, muss man immer sowohl die Deklaration der Abhängigkeit als auch die Isolation verwenden. Verwalte Abhängigkeiten innerhalb der Anwendung, nicht von einer externen Quelle. Abhängigkeiten sollten in einem Repository innerhalb der App gehostet werden
Prinzip III. Konfiguration
"Konfiguration in der Umgebung speichern"
Eine Anwendung und ihre Konfiguration sollten völlig unabhängig sein. Außerdem sollte das ständige Speichern von Konfigurationen im Code vollständig vermieden werden.
Deine Konfigurationen sollten eine separate Datei haben und nicht im Code-Repository gehostet werden. Eine separate Konfigurationsdatei erleichtert das Aktualisieren der Konfigurationswerte, ohne die eigentliche Codebasis zu berühren, wodurch die Notwendigkeit einer erneuten Bereitstellung deiner Anwendungen entfällt, wenn du bestimmte Konfigurationswerte änderst.
Wenn Konfigurationen in der Umgebung und nicht in der App als Variablen liegen, kannst du sie problemlos in eine andere Umgebung verschieben, ohne den Quellcode zu berühren. Zwölf-Faktor-Apps speichern Konfigurationen als Variablen, sodass sie "versehentlich nicht ins Repository eingecheckt werden". Ein weiterer Vorteil: Dann sind deine Konfigurationen unabhängig von Sprache und Betriebssystem.
Prinzip IV. Unterstützungsdienste
"Unterstützende Dienste als angeschlossene Ressourcen behandeln"
In einer 12-Faktor-App müssen alle Dienste, die die Kern-App nicht unterstützen, als Dienst abgerufen werden. Diese nicht-zentralen Essential-Dienste könnten gehören:
- Datenbanken
- Externer Speicher
- Nachrichtenwarteschlangen
- Und so weiter.
Diese können als Ressource behandelt werden. Diese sollten als Service über HTTP oder eine ähnliche Anfrage genutzt und dann in der Konfiguration angegeben werden. So kann die Quelle des Dienstes geändert werden, ohne den Kerncode der App zu beeinflussen.
Zum Beispiel ist eine App, die ein Nachrichtenwarteschlangensystem verwendet, am besten, wenn sie einfach von RabbitMQ zu ZeroMQ zu ActiveMQ wechseln kann, indem sie nur die Konfigurationsinformationen ändert.
Prinzip V. Bauen, loslassen, laufen
"Streng getrennte Bau- und Laufphasen"
Eine 12-Faktor-App trennt die drei Phasen – Bau, Release und Betrieb – strikt.
Starte den Build-Prozess, indem du die App in der Quellcode-Kontrolle speicherst, und baue dann ihre Abhängigkeiten aus. Das Trennen der Konfigurationsinformationen bedeutet, dass du sie mit dem Build für die Release-Phase kombinieren kannst – und dann ist sie bereit für die Laufzeit. Es ist außerdem wichtig, dass jede Veröffentlichung eine eindeutige ID hat.
Prinzip VI. Prozesse
"Führe die App als einen oder mehrere zustandslose Prozesse aus"
Speichere alle Daten, die in einem zustandsvollen Sicherungsdienst, wie Datenbanken, gespeichert werden müssen. Die Idee ist, dass der Prozess stateless ist und absolut nichts teilt.
Während viele Entwickler an "angeplebte Sitzungen" gewöhnt sind, widerspricht das Speichern von Informationen in der Sitzung in der Erwartung, dass die nächste Anfrage vom selben Dienst stammt, dieser Methodik.
Prinzip VII. Portbindendes Prinzip
"Exportdienste über Portbindung"
12-Faktor-Apps müssen immer unabhängig von weiteren Anwendungen sein. Jede Funktion sollte ein eigener Prozess sein – in vollständiger Isolation.
In einer traditionellen Umgebung gehen wir davon aus, dass verschiedene Prozesse unterschiedliche Funktionen verwalten. Daher ist es leicht anzunehmen, dass diese Funktionen über ein Webprotokoll wie HTTP verfügbar sind, was es wahrscheinlich macht, dass Apps hinter Webservern wie Apache oder Tomcat laufen. Dies widerspricht jedoch der 12-Faktor-Methodik.
Füge stattdessen eine Webserver-Bibliothek oder Ähnliches zur Kern-App hinzu. Das bedeutet, dass die App Anfragen auf einem definierten Port warten kann, egal ob HTTP oder ein anderes Protokoll.
Prinzip VIII. Nebenläufigkeit
"Skalieren Sie über das Prozessmodell"
Eine echte 12-Faktor-App ist für Skalierung konzipiert. Bauen Sie Ihre Anwendungen so, dass die Skalierung in der Cloud nahtlos ist. Wenn Sie die App parallel entwickeln, können Sie mühelos neue Instanzen in die Cloud starten.
Um mehr Kapazität hinzuzufügen (zusätzliche Prozesse auf weiteren Maschinen zu starten), sollte deine App in der Lage sein, mehr Instanzen statt mehr Speicher oder CPU auf der lokalen Maschine hinzuzufügen.
Prinzip IX. Wegwerfbarkeit
"Maximale Robustheit mit schnellem Start und elegantem Abschalten"
Das Konzept der Wegwerfprozesse bedeutet, dass eine Anwendung jederzeit sterben kann, aber das betrifft den Nutzer nicht – die App kann durch andere Apps ersetzt werden oder direkt wieder starten. Die Integration von Wegwerfbarkeit in Ihre App stellt sicher, dass die App elegant herunterfährt: Sie sollte alle genutzten Ressourcen bereinigen und sich reibungslos abschalten.
So gestaltet, startet die App schnell wieder. Ebenso sollten Prozesse, wenn sie enden, ihre aktuelle Anfrage beenden, jede eingehende Anfrage ablehnen und dann beenden.
Prinzip X. Entwicklungs-/Produktionsparität
"Haltet Entwicklung, Inszenierung und Produktion so ähnlich wie möglich"
Anwendungen, die in Entwicklung und Produktion bereitgestellt werden, sollten Parität aufweisen. Im Grunde sollte es nur den geringsten Unterschied zwischen beiden Deployments geben.
Ein großer Unterschied kann zu unbeabsichtigten Kompatibilitätsproblemen zwischen Entwicklungs- und Produktionscode führen. Beim Bau einer 12-Faktor-App müssen die Backing-Services zwischen Entwicklung und Produktion gleich sein; ein Unterschied hier könnte später erhebliche Probleme verursachen.
Prinzip XI. Logs
"Protokolle als Ereignisströme behandeln"
Im Gegensatz zu monolithischen und traditionellen Apps , die Loginformationen in einer Datei speichern, besagt dieses Prinzip, dass man Logs an einen gewählten Ort streamen sollte – und sie nicht einfach in eine Logdatei ablegen.
Typischerweise befinden sich Logs nach jedem Brennen nicht am selben Ort in cloudbasierten Umgebungen. Wenn neue Prozesse starten oder Ihre App abstürzt, werden die Logs auf mehrere Cloud-Rechner verteilt; sie liegen nicht auf einem einzelnen Rechner oder Host.
Lösen Sie dieses Problem, indem Sie einen gemeinsamen Ort für das Streamen der Logs benennen. In manchen Fällen können Sie Stdout einfach auf eine Datei umleiten. Wahrscheinlicher ist jedoch, dass Sie einen Log-Router wie Fluentd bereitstellen und die Logs bei Hadoop oder einem bestimmten Dienst wie Splunk speichern.
Prinzip XII. Verwaltungsprozesse
"Admin-/Managementaufgaben als einmalige Prozesse ausführen"
Das abschließende Prinzip der 12-Faktor-App sieht vor, administrative Aufgaben vom Rest Ihrer Anwendung zu trennen. Diese Aufgaben können die Migration einer Datenbank oder die Überprüfung von Datensätzen umfassen.
Obwohl die Admin-Prozesse getrennt sind, musst du sie weiterhin in derselben Umgebung und gegen den Basiscode und die Konfiguration der App selbst ausführen. Das Ausliefern des Admin-Aufgaben-Codes zusammen mit der Anwendung verhindert Drift.
Verwandte Literatur
Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.