Die Twelve-Factor App Teil 1: Codebase, Dependencies, Config Backing Services

Die Zwölf-Faktoren-App ist eine Methodik zur Erstellung einer Software-as-a-Service-App. Die Hauptmerkmale müssen deklarative Formate für die Setup-Automatisierung, die Option der Portabilität, die Option der modernen Implementierung auf Cloud-Plattformen, die Systemadministration, freien Raum für die kontinuierliche Bereitstellung und Skalierungsmöglichkeiten enthalten.

Die Zwölf-Faktoren-Methodik kann auf Apps angewendet werden, die in einer beliebigen Programmiersprache geschrieben sind und eine beliebige Kombination von unterstützenden Diensten (Datenbank, Warteschlange, Speicher-Cache usw.) verwenden. (Quelle)

Im ersten Teil unserer „Twelve-Factor App“-Blogreihe schauen wir auf die ersten vier Faktoren.

Faktor 1: Codebase

Eine Zwölf-Faktoren-App wird immer in einem Versionsmanagementsystem verwaltet. Diese wird wie folgt beschrieben: „Eine Codebasis, die in der Versionskontrolle verfolgt wird, viele Deploys." (Quelle)

Bei diesem Faktor wird die Zwölf-Faktoren-Methodik durch mehrere Codebases und mehrere Anwendungen mit demselben Code durchbrochen, und jede von ihnen hat eine Lösung zur Vermeidung dieses Szenarios.

Es gibt nur eine Codebasis pro Anwendung, aber es wird viele Deployments der Anwendung geben. Ein Deploy ist eine laufende Instanz der Anwendung. Dabei handelt es sich in der Regel um eine Produktionsumgebung und eine oder mehrere Stagingumgebungen. Alle teilen dieselbe Codebase, was sie als verschiedene Deploys derselben App auszeichnet. (Quelle)

Faktor 2: Abhängigkeiten

Eine Zwölf-Faktor-App verlässt sich nie auf die Existenz von systemweiten Paketen. Sie deklariert alle Abhängigkeiten vollständig und genau über ein Abhängigkeitsdeklaration.

Darüber hinaus verwendet sie während der Ausführung ein Tool zur Isolierung von Abhängigkeiten, um sicherzustellen, dass keine impliziten Abhängigkeiten aus dem umgebenden System „durchsickern". Die vollständige und explizite Spezifikation von Abhängigkeiten wird sowohl in der Produktion als auch in der Entwicklung einheitlich angewendet. (Quelle)

Faktor 3: Konfiguration

Der sicherste Ansatz, die Konfiguration einer Anwendung zu speichern und zu pflegen, ist die Verwendung von env vars (Environment variable). Was bedeutet, dass die Konfiguration externalisiert und in der Umgebung gespeichert wird. Nicht veränderbare Komponenten gehören nicht in die Konfiguration, da sie aus Komponenten besteht, die während verschiedener Deployments variabel sind.

Interne Informationen, die Teil der Anwendung sind, dürfen nicht in die Konfiguration aufgenommen werden.

Zur Verdeutlichung: Wenn ein Wert über alle Deployments hinweg konsistent ist, handelt es sich nicht um eine Konfiguration. Nach den Zwölf-Faktoren-Regeln sollte die Konfiguration vom Code getrennt werden, da sich der Code nicht über verschiedene Deployments hinweg ändert, die Konfiguration jedoch häufig. Durch diese Trennung ist es einfacher, Umgebungsvariablen zu ändern, da kein Code davon betroffen ist.

Es ist äußerst wichtig, bei der Aufbewahrung von Sicherheitsanmeldeinformationen vorsichtig zu sein – sie sollten niemals in der Codebasis aufbewahrt werden. Gebündelte Assets bleiben Teil der Codebase, auch wenn die Sicherheitsdaten in einigen Eigenschaftsdateien gespeichert oder aus dem Quellcode abgerufen werden. Da die Umgebungsvariablen für jeden Einsatz einzeln gepflegt werden, lässt sich das Anwendungskonzept, das sie enthält, effizient skalieren. (Quelle)

Faktor 4: Unterstützende Dienste

Ein unterstützender Dienst (im englischen Backing Service) ist jeder Dienst, den die Anwendung im Rahmen ihres normalen Betriebs über das Netzwerk in Anspruch nimmt.

Dazu gehören beispielsweise: ‍

• Datenspeicher
• Messaging- oder Warteschlangensysteme
• SMTP-Dienste für ausgehende E-Mails
• Caching-Systeme

Sowohl lokale Dienste als auch welche von Drittanbietern werden als gleichwertig betrachtet, da sie mit der Anwendung verbunden sind und der Zugriff über eine URL oder andere Konfigurationsdaten erfolgt.

Jeder unterstützende Dienst wird als Ressource betrachtet, die zu einem bestimmten Zeitpunkt in Deployments integriert oder aus ihnen ausgeschlossen werden kann. Ressourcen können nach Belieben zu Deployments hinzugefügt und von ihnen getrennt werden. Wenn z. B. die Datenbank der Anwendung aufgrund eines Hardware-Problems nicht funktioniert, kann der Administrator der Anwendung einen neuen Datenbankserver aufsetzen, der aus einem aktuellen Backup wiederhergestellt wird. Die aktuelle Produktionsdatenbank könnte abgetrennt und die neue Datenbank angeschlossen werden – und das alles ohne jegliche Codeänderung.

Sie arbeiten in der IT oder interessieren sich für Themen rund um die IT? Dann besuchen Sie gerne unseren Blog für weitere Themen und folgen Sie uns auf Facebook und LinkedIn.