Die 12-Faktoren-App: Moderne Praktiken & Leapcell-Anleitung
Die Zwölf-Faktoren-App ist eine Methodik zum Erstellen robuster, skalierbarer und wartbarer moderner Webanwendungen, die ursprünglich von Entwicklern bei Heroku formuliert wurde. Sie bietet einen institutionellen Rahmen für die Lösung häufiger Probleme in der Anwendungsentwicklung und im Betrieb, insbesondere im Cloud-Native-Zeitalter.
Das Befolgen dieser zwölf Faktoren hilft Entwicklern, Anwendungen zu erstellen, die für kontinuierliche Bereitstellung, hohe Portabilität und reibungslose Skalierung optimiert sind.
Leapcell ist als 12-Faktoren-App-Plattform konzipiert. Indem Sie die Zwölf-Faktoren-Methodik befolgen, können Sie die Funktionen von Leapcell nutzen, um Ihre Anwendungen effizienter zu erstellen und bereitzustellen.
Dieses Dokument baut auf den klassischen zwölf Faktoren auf und ergänzt sie mit modernen Interpretationen und Best Practices auf der Leapcell-Plattform.
Die 12 Faktoren - Moderne Interpretation & Leapcell-Praktiken
I. Codebasis für einen Dienst
Eine Codebasis, die in der Revisionskontrolle verfolgt wird, viele Bereitstellungen.
Der gesamte Code für eine Anwendung sollte in einem einzigen Repository unter Verwendung eines Versionskontrollsystems wie Git gespeichert werden. Obwohl mehrere Bereitstellungsumgebungen (z. B. Entwicklung, Produktion) existieren können, müssen sie alle aus derselben Codebasis stammen.
Das Bereitstellungsmodell von Leapcell basiert grundlegend auf diesem Prinzip. Wir befürworten die Best Practice von „einem Dienst pro Repository“, was die Klarheit des Git-Commit-Verlaufs verbessert und das Projektmanagement und das Verständnis erheblich vereinfacht.
II. Abhängigkeiten in einer Manifestdatei deklarieren
Abhängigkeiten explizit in einer Manifestdatei deklarieren.
Alle Abhängigkeiten sollten explizit über eine Manifestdatei (z. B. package.json
, requirements.txt
) deklariert und mit einem geeigneten Isolationstool verwaltet werden.
Eine präzise Abhängigkeitsverwaltung ist entscheidend, um die Portabilität des Dienstes sicherzustellen. Wenn Ihr Build-Prozess komplex ist (z. B. sowohl Systempakete über
apt-get
als auch sprachspezifische Bibliotheken überpip
erfordert), empfehlen wir dringend, einbuild.sh
-Skript zu erstellen, um die Build-Schritte zu vereinheitlichen und eine konsistente Umgebung zu gewährleisten.
III. Umgebung als Konfiguration
Konfiguration in der Umgebung speichern.
Trennen Sie die Konfiguration (z. B. Datenbank-URLs, API-Schlüssel) strikt vom Code und injizieren Sie sie über Umgebungsvariablen.
Eine moderne Best Practice ist die Verwendung einer
.env
-Datei für die lokale Entwicklung. Auf der Leapcell-Plattform werden Ihre konfigurierten Umgebungsvariablen automatisch in die Laufzeitumgebung injiziert, sodass Ihre Anwendung nahtlos darauf zugreifen kann und ein reibungsloser Übergang von der lokalen Umgebung zur Produktion gewährleistet wird.
IV. Backing Services
Backing Services als angehängte Ressourcen behandeln.
Jeder Dienst, den die App über das Netzwerk nutzt (wie z. B. Datenbanken oder Caches), sollte als steckbare Ressource behandelt werden, die über eine URL oder Anmeldeinformationen, die in der Konfiguration gespeichert sind, angehängt wird.
Die Serverless-Dienste von Leapcell verkörpern diese Philosophie und verfügen über ein schreibgeschütztes Dateisystem mit Ausnahme des Verzeichnisses
/tmp
. Dieses Design erzwingt die Externalisierung des Zustands, ermöglicht eine dynamische Hochgeschwindigkeit-Planung unserer Infrastruktur und stellt sicher, dass Ihnen Rechenressourcen mit maximaler Geschwindigkeit bereitgestellt werden. Darüber hinaus bietet Leapcell hochverfügbare PostgreSQL-, Redis- und Object Storage-Dienste, um die Last der Zustandspersistenz effektiv auszulagern.
V. Bauen, Freigeben, Ausführen
Bauen-, Freigabe- und Ausführungsphasen strikt trennen.
Diese Trennung stellt sicher, dass Releases unveränderlich sind und problemlos zurückgesetzt werden können. Moderne CI/CD-Pipelines automatisieren diesen Prozess und ermöglichen so schnelle und zuverlässige Bereitstellungen.
Leapcell fördert eine klare Unterscheidung zwischen Ihrem Produktionszweig (z. B.
main
) und Entwicklungszweigen. Für jeden neuen Commit im Produktionszweig löst Leapcell automatisch einen neuen Build und Release aus und stellt Ihren neuesten Code in der Produktion bereit, wodurch der CI/CD-Workflow vollständig genutzt wird.
VI. Zustandslose Prozesse
Die App als einen oder mehrere zustandslose Prozesse ausführen.
Die Anwendung sollte als „Share-Nothing“-Zustandslosprozess ausgeführt werden. Alle Daten, die persistent gespeichert werden müssen, müssen in einem zustandsbehafteten Backing Service gespeichert werden.
Dieses Prinzip ist entscheidend, um eine schnelle horizontale Skalierung zu erreichen und sicherzustellen, dass Prozesse jederzeit gestartet oder gestoppt werden können, ohne den Zustand zu verlieren. Die Serverless-Dienste von Leapcell sind auf diese Weise konzipiert und ermöglichen eine nahtlose Skalierung und Verwaltung zustandsloser Prozesse.
VII. Portbindung
Dienste über Portbindung exportieren.
Die Anwendung sollte in sich geschlossen sein und auf Anfragen warten, indem sie sich an einen Port bindet.
Die Plattform verwendet den von Ihrer Anwendungskonfiguration angegebenen Port, um das Routing des externen Datenverkehrs zu verwalten.
VIII. Gleichzeitigkeit
Über das Prozessmodell skalieren.
Erhöhte Last durch horizontale Skalierung (Hinzufügen weiterer Prozesse) anstelle von vertikaler Skalierung (einzelnen Prozesse leistungsfähiger machen) bewältigen.
Der Serverless-Modus von Leapcell skaliert Instanzen automatisch basierend auf dem eingehenden Datenverkehr und gewährleistet so eine optimale Ressourcenauslastung und Reaktionsfähigkeit, wobei die Vorteile eines zustandslosen Prozessmodells genutzt werden.
IX. Entbehrlichkeit
Maximale Robustheit mit schnellem Start und ordnungsgemäßem Herunterfahren.
Prozesse sollten entbehrlich sein, d. h. sie können jederzeit gestartet oder gestoppt werden.
Leapcell würde ein SIGKILL-Signal senden, um nicht reagierende Prozesse zu beenden. Sie können Ihre Anwendung so konfigurieren, dass sie dieses Signal verarbeitet und alle erforderlichen Bereinigungen vor dem Beenden durchführt.
X. Dev/Prod-Parität
Entwicklung, Staging und Produktion so ähnlich wie möglich halten.
Das Schließen der Lücke zwischen den Umgebungen reduziert Fehler, die nur in der Produktion auftreten.
Wir empfehlen, dieselbe Codebasis mit separaten Zweigen für Entwicklung und Produktion und
env.local
-Dateien zur Verwaltung umgebungsspezifischer Konfigurationen zu verwenden.
XI. Protokolle
Protokolle als Ereignisströme behandeln.
Eine Anwendung sollte sich nicht um das Routing oder die Speicherung ihrer Protokolldateien kümmern. Stattdessen sollte sie ihren Ereignisstrom ungepuffert an die Standardausgabe (stdout
) schreiben.
Leapcell verwendet eine moderne Protokollierungsinfrastruktur: Alle Protokolle werden zur Analyse und Überwachung an einen zentralen Dienst gesendet, sodass Sie Begriffe suchen oder Protokolle basierend auf verschiedenen Kriterien filtern können.
XII. Admin-Prozesse
Admin-/Verwaltungsaufgaben als einmalige Prozesse ausführen.
Alle administrativen Aufgaben, wie z. B. Datenbankmigrationen, sollten als einmalige Prozesse ausgeführt werden.
Leapcell bietet derzeit keinen Pre-Start-Befehl, der vor dem Start der Anwendung ausgeführt wird. Sie können solche Aufgaben während der Build-Phase ausführen oder sie manuell auf Ihrem Rechner ausführen.