Die 12 Faktoren App: Moderne Praktiken und Leapcell Guide
The Twelve-Factor App ist eine Methodik zum Erstellen robuster, skalierbarer und leicht wartbarer moderner Webanwendungen, die ursprünglich von Entwicklern bei Heroku vorgeschlagen wurde. Sie bietet einen systematischen Rahmen zur Lösung gemeinsamer Herausforderungen bei der App-Entwicklung und dem Betrieb im Cloud-nativen Zeitalter.
Durch die Befolgung der 12 Faktoren können Entwickler Anwendungen erstellen, die für kontinuierliche Bereitstellung, hohe Portabilität und reibungslose Skalierung optimiert sind.
Leapcell ist nach den Prinzipien der 12-Faktor-App aufgebaut. Durch die Befolgung dieser Prinzipien können Sie die Funktionen von Leapcell nutzen und Ihre Anwendungen effizienter erstellen und bereitstellen.
Dieses Dokument basiert auf den klassischen 12 Faktoren und ergänzt diese um moderne Interpretationen und Best Practices auf der Leapcell-Plattform.
Moderne Interpretation der 12 Faktoren und Leapcell-Praktiken
TL;DR
| # | Factor | Übersicht | Leapcell-Praktiken |
|---|---|---|---|
| I | Codebase for One Service | 1 Repository pro App, mehrere Bereitstellungen | 1 Repository pro Service; Git-Historie klarstellen |
| II | Declare Dependencies | Abhängigkeiten explizit deklarieren | Manifestdatei verwenden + ggf. build.sh für einheitliche Builds verwenden |
| III | Env as Config | Konfiguration von Code trennen und per Umgebungsvariable injizieren | Lokal .env verwenden; Plattform injiziert Umgebungsvariablen automatisch |
| IV | Backing Services | Externe Services als austauschbare Ressourcen behandeln | /tmp beschreibbarer, serverloser Service; PostgreSQL, Redis, Objektspeicher verfügbar |
| V | Build, Release, Run | Build, Release und Ausführung trennen | Build & Release automatisch durch Commit auf Haupt-Branch auslösen; CI/CD-Workflow |
| VI | Stateless Processes | Prozesse sollten zustandslos sein | Horizontale Skalierung durch zustandsloses Design möglich |
| VII | Port Binding | Service über Port bereitstellen | Externer Traffic wird an den konfigurierten Port weitergeleitet |
| VIII | Concurrency | Durch Hinzufügen von Prozessen skalieren | Automatische Skalierung von serverlosen Instanzen je nach Traffic |
| IX | Disposability | Schneller Start & elegantes Herunterfahren | Antwortlose Prozesse werden per SIGKILL beendet; App kann Bereinigung durchführen |
| X | Dev/prod Parity | Entwicklung/Staging/Produktion so ähnlich wie möglich halten | Gleiche Codebasis; Einstellungen nach Umgebung über Branch + env.local |
| XI | Logs | Logs als Event Stream behandeln | Zentrale Logverwaltung; Event Stream Ausgabe auf stdout |
| XII | Admin Processes | Administrative Aufgaben einmalig ausführen | Build-Zeit oder manuelle Ausführung; keine Pre-Start-Befehle verfügbar |
I. Codebase for One Service
Eine Codebasis, die per Revisionskontrolle verwaltet wird und mehrere Deployments ermöglicht.
Der Code einer Anwendung muss in einem einzigen Repository verwaltet werden. Auch wenn es mehrere Umgebungen gibt, müssen diese von derselben Codebasis abgeleitet sein.
Das Bereitstellungsmodell von Leapcell basiert auf diesem Prinzip. Wir empfehlen „1 Service pro Repository“, wodurch die Git-Historie klarer und das Projektmanagement einfacher wird.
II. Declare Dependencies in a Manifest File
Abhängigkeiten in einer Manifestdatei deklarieren.
Abhängigkeiten müssen explizit in einem Manifest (package.json, requirements.txt) deklariert und mit geeigneten Isolationstools verwaltet werden.
Das Abhängigkeitsmanagement ist wichtig für die Portabilität von Services. Für komplexe Builds empfiehlt es sich, ein
build.sh-Skript zu erstellen, um die Schritte zu vereinheitlichen.
III. Env as Config
Konfiguration in der Umgebung speichern.
Konfigurationen (DB-URL, API-Schlüssel usw.) werden vom Code getrennt und über Umgebungsvariablen injiziert.
Für die lokale Entwicklung wird
.envverwendet. In Leapcell werden konfigurierte Umgebungsvariablen automatisch zur Laufzeit injiziert, was den Übergang zwischen lokaler Umgebung und Produktion vereinfacht.
IV. Backing Services
Backend-Services als austauschbare Ressourcen behandeln.
Über das Netzwerk verwendete Services werden über URLs und Authentifizierungsdaten verbunden.
Leapcell Serverless hat ein Read-Only-FS, außer
/tmp. Die Externalisierung des Zustands ermöglicht eine schnelle dynamische Planung. PostgreSQL, Redis und Objektspeicher werden ebenfalls angeboten.
V. Build, Release, Run
Build, Release und Ausführung trennen.
Releases sind unveränderlich und können problemlos zurückgesetzt werden. Automatisierung durch CI/CD.
Commits auf den Haupt-Branch lösen automatisch Build und Release aus. Der neueste Code wird in der Produktion bereitgestellt.
VI. Stateless Processes
Apps in zustandslosen Prozessen ausführen.
Daten, die persistent gespeichert werden müssen, werden in einem Backend-Service gespeichert.
Zustandsloses Design ermöglicht eine einfache horizontale Skalierung. Leapcell Serverless unterstützt dies.
VII. Port Binding
Service über Portbindung bereitstellen.
Die Plattform leitet externen Traffic an den konfigurierten Port weiter.
VIII. Concurrency
Mit horizontaler Skalierung auf Last reagieren.
Automatische Skalierung von serverlosen Instanzen je nach Traffic.
IX. Disposability
Schneller Start und elegantes Beenden für Robustheit.
Antwortlose Prozesse werden per SIGKILL beendet. Die App kann die erforderliche Bereinigung durchführen.
X. Dev/prod Parity
Entwicklung, Staging und Produktion so weit wie möglich angleichen.
Gleiche Codebasis, Einstellungen nach Umgebung über Branch +
env.local.
XI. Logs
Logs als Event Stream behandeln.
Alle Logs werden zentral verwaltet und auf stdout ausgegeben, um analysiert werden zu können.
XII. Admin Processes
Administrative Aufgaben einmalig ausführen.
Leapcell bietet keine Pre-Start-Befehle. Ausführung während des Builds oder manuell möglich.