Zweck

Der Bootstrap beschreibt den vollständigen Erstinitialisierungsprozess einer ORLENE Platform Instance.

Zweck

Er stellt sicher, dass jede zukünftige Platform Instance nach denselben Regeln eingerichtet wird.

Zweck

Bootstrap ersetzt keine Betriebssysteminstallation.

Zweck

Bootstrap beginnt nach einer erfolgreichen Linux-Grundinstallation.

Zweck

Der Bootstrap ist die erste Handlung einer neuen ORLENE Platform Instance.

Zweck

Er verbindet eine frisch installierte Infrastruktur mit den Grundsätzen der ORLENE Platform und macht sie zu einem Bestandteil des Gesamtsystems.

Grundsatz

Eine ORLENE Platform Instance wird nicht manuell eingerichtet.

Grundsatz

Sie richtet sich anhand des Bootstrap-Prozesses selbst ein.

Grundsatz

Damit wird jede Platform Instance reproduzierbar.

Voraussetzungen

Vor Bootstrap müssen vorhanden sein:

Voraussetzungen

- Linux installiert - SSH-Zugang - Internetzugang - /opt/orlene vorhanden - Administratorzugriff

Voraussetzungen

Bootstrap installiert kein Betriebssystem.

Bootstrap-Version

Bootstrap besitzt eine eigene Version.

Bootstrap-Version

Mindestens dokumentiert werden:

Bootstrap-Version

- Bootstrap-Version - Platform-Version - Erstellungsdatum

Bootstrap-Version

Dadurch kann später nachvollzogen werden, mit welcher Bootstrap-Version eine Platform Instance eingerichtet wurde.

Bootstrap-ID

Jede Bootstrap-Ausführung erhält eine eindeutige Bootstrap-ID.

Bootstrap-ID

Beispiel:

Bootstrap-ID

`BOOT-20260727-0001`

Bootstrap-ID

Die Bootstrap-ID dient der Nachvollziehbarkeit.

Bootstrap-ID

Sie wird gespeichert:

Bootstrap-ID

- im Bootstrap Report - im Platform Register - im Audit - im Lebenslauf

Entscheidungsprinzip

Vor jeder Aktion prüft Bootstrap den aktuellen Zustand. Bootstrap arbeitet niemals blind. Jede Aktion basiert auf einer vorherigen Prüfung.

Entscheidungsprinzip

Jede Phase besitzt mindestens folgende Entscheidungslogik:

Entscheidungsprinzip

```text Prüfen ↓ Bereits vorhanden? ↓ Ja ↓ Validieren ↓ gültig? ↓ Ja ↓ nächste Phase ↓ Nein ↓ Aktualisieren oder korrigieren ↓ Dokumentieren ↓ Weiter ```

Entscheidungsprinzip

Falls eine Komponente vollständig fehlt:

Entscheidungsprinzip

```text Prüfen ↓ Nicht vorhanden ↓ Installieren ↓ Verifizieren ↓ Dokumentieren ↓ Weiter ```

Lebenszyklus

```text Neue Platform Instance ↓ Bootstrap starten ↓ System analysieren ↓ Platform Register aktualisieren ↓ Grundstruktur prüfen ↓ Benutzer einrichten ↓ Grundsystem absichern ↓ Docker ↓ PostgreSQL ↓ Platform-Dienste ↓ Dokumentation ↓ Verifizieren ↓ Platform Ready ```

Technologische Unabhängigkeit

Die Architektur beschreibt Fähigkeiten, nicht konkrete Programme.

Technologische Unabhängigkeit

Beispiele:

Technologische Unabhängigkeit

- Containerverwaltung statt einer Festlegung auf Docker - Relationale Datenhaltung statt einer Festlegung auf PostgreSQL - HTTP- und Reverse-Proxy-Dienst statt einer Festlegung auf Nginx

Technologische Unabhängigkeit

Docker, PostgreSQL und Nginx bleiben mögliche Technologiebeispiele und sind keine Architekturvorgabe. Bootstrap entscheidet anhand der jeweils gültigen Plattformvorgaben, welche konkrete Technologie verwendet wird. Dadurch bleibt die Architektur langfristig unabhängig von einzelnen Produkten.

Phase A

Systemanalyse

Phase A

Bootstrap dokumentiert:

Phase A

Hostname

Phase A

Betriebssystem

Phase A

Kernel

Phase A

CPU

Phase A

RAM

Phase A

Speicher

Phase A

Netzwerk

Phase A

Zeitzone

Phase A

Virtualisierung

Phase A

Linux-Version

Phase A

Alle Daten werden dokumentiert.

Phase B

Platform Register

Phase B

Bootstrap erzeugt oder aktualisiert automatisch den Eintrag einer Platform Instance mit:

Phase B

- Hostname - Standort - Rolle - Platform-Version - Bootstrap-Version - Bootstrap-ID - Systemstatus - Platform Ready - Erstellt - letzter Bootstrap - letztes Update

Phase B

Bootstrap aktualisiert diese Informationen automatisch.

Phase C

Verzeichnisstruktur

Phase C

Bootstrap prüft:

Phase C

/opt/orlene

Phase C

platform

Phase C

documentation

Phase C

products

Phase C

downloads

Phase C

releases

Phase C

backups

Phase C

logs

Phase C

scripts

Phase C

Fehlende Verzeichnisse werden erzeugt.

Phase C

Vorhandene bleiben erhalten.

Phase D

Benutzer

Phase D

Bootstrap legt an:

Phase D

orlene-admin

Phase D

SSH-Schlüssel werden übernommen.

Phase D

Root bleibt zunächst aktiv.

Phase D

Spätere Härtung erfolgt kontrolliert.

Phase E

Grundsystem

Phase E

Bootstrap:

Phase E

führt Updates durch

Phase E

prüft Zeitzone

Phase E

prüft Locale

Phase E

prüft Paketquellen

Phase E

prüft Uhrzeit

Phase E

prüft Speicher

Phase E

prüft Netzwerk

Phase E

Dokumentiert Ergebnisse.

Phase F

Docker

Phase F

Falls Docker fehlt:

Phase F

installieren

Phase F

Version dokumentieren

Phase F

Installation testen

Phase F

Dokumentieren

Phase G

PostgreSQL

Phase G

Falls PostgreSQL fehlt:

Phase G

installieren

Phase G

Version dokumentieren

Phase G

erste Platform-Datenbank vorbereiten

Phase H

Platform Services

Phase H

Bootstrap bereitet vor:

Phase H

Documentation Space

Phase H

Build

Phase H

Release

Phase H

Downloads

Phase H

weitere zukünftige Platform Services

Phase H

Noch keine ORLENE-Produkte installieren.

Phase I

Bootstrap-Bericht

Phase I

Nach Abschluss erzeugt Bootstrap automatisch einen Bootstrap Report mit:

Phase I

- Bootstrap-ID - Bootstrap-Version - Platform-Version - Startzeit - Endzeit - Gesamtdauer - Hostname - Platform Instance - installierte Komponenten - Prüfergebnisse - Warnings - Recovery durchgeführt - Rollback durchgeführt - Platform Ready: Ja / Nein - Entscheidungen je Phase: - Prüfung - Ergebnis - Aktion - Begründung

Phase J

Recovery

Phase J

Falls Bootstrap unterbrochen wurde:

Phase J

Bootstrap erkennt den vorhandenen Zustand.

Phase J

Bootstrap beginnt nicht erneut von vorne.

Phase J

Bootstrap setzt die Initialisierung kontrolliert fort.

Phase J

Alle Recovery-Schritte werden dokumentiert.

Rollback

Falls während Bootstrap ein kritischer Fehler entsteht:

Rollback

```text Bootstrap ↓ Fehler erkennen ↓ Rollback vorbereiten ↓ bereits ausgeführte Schritte dokumentieren ↓ System in sicheren Zustand bringen ↓ Audit erzeugen ↓ Administratorentscheidung abwarten ```

Rollback

Bootstrap darf niemals halb eingerichtete Platform Instanzen als erfolgreich markieren.

Kontrolliertes Abbruchrecht

Bootstrap besitzt jederzeit das Recht, die Initialisierung kontrolliert abzubrechen.

Kontrolliertes Abbruchrecht

Ein Abbruch erfolgt insbesondere, wenn:

Kontrolliertes Abbruchrecht

- Integrität nicht gewährleistet werden kann - Daten beschädigt würden - Voraussetzungen fehlen - eine Verifikation fehlschlägt - Sicherheitsanforderungen verletzt werden

Kontrolliertes Abbruchrecht

Bei einem Abbruch muss Bootstrap:

Kontrolliertes Abbruchrecht

- den Status speichern - ein Audit-Ereignis erzeugen - den Bootstrap Report ergänzen - das Platform Register aktualisieren - den Administrator informieren

Kontrolliertes Abbruchrecht

Keine Platform Instance darf nach einem Abbruch fälschlicherweise den Zustand `Platform Ready` erhalten.

Bootstrap-Zustände

Der offizielle Zustandsautomat umfasst:

Bootstrap-Zustände

```text Pending Running Recovery Rollback Failed Completed Platform Ready ```

Bootstrap-Zustände

Bootstrap darf jederzeit eindeutig angeben, in welchem Zustand sich eine Platform Instance befindet.

Platform Ready

`Platform Ready` ist nicht lediglich ein Status, sondern die verbindliche Bestätigung der Betriebsbereitschaft.

Platform Ready

Eine Platform Instance erhält diesen Zustand ausschließlich, wenn:

Platform Ready

- alle Pflichtphasen erfolgreich abgeschlossen wurden - alle Verifikationen erfolgreich waren - keine kritischen Fehler offen sind - kein Recovery notwendig ist - kein Rollback aktiv ist

Platform Ready

Erst danach gilt eine Platform Instance offiziell als betriebsbereit. Sobald eine dieser Bedingungen nicht erfüllt ist, darf Bootstrap `Platform Ready` nicht vergeben.

Architekturgrundsätze

1. Bootstrap richtet keine Produkte ein.

Architekturgrundsätze

Bootstrap richtet ausschließlich Platform Instanzen ein.

Architekturgrundsätze

2. Bootstrap verändert keine vorhandenen Daten ohne Sicherung.

Architekturgrundsätze

3. Bootstrap dokumentiert jede Änderung.

Architekturgrundsätze

4. Bootstrap erzeugt Audit-Ereignisse.

Architekturgrundsätze

5. Bootstrap aktualisiert das Platform Register.

Architekturgrundsätze

6. Bootstrap muss beliebig oft ausführbar sein.

Architekturgrundsätze

7. Bootstrap erkennt bereits eingerichtete Komponenten.

Architekturgrundsätze

8. Bootstrap installiert nur fehlende Komponenten.

Architekturgrundsätze

9. Bootstrap überschreibt niemals ungefragt bestehende Konfigurationen.

Architekturgrundsätze

10. Jede Platform Instance besitzt denselben Bootstrap-Prozess.

Architekturgrundsätze

11. Eine Platform Instance gilt erst dann als Bestandteil der ORLENE Platform, wenn sie den Bootstrap erfolgreich abgeschlossen hat und den Zustand 'Platform Ready' erreicht.

September-Ziel

Für September umfasst Bootstrap mindestens:

September-Ziel

Systemanalyse

September-Ziel

Platform Register

September-Ziel

Verzeichnisstruktur

September-Ziel

orlene-admin

September-Ziel

Docker

September-Ziel

PostgreSQL

September-Ziel

Bootstrap Report

September-Ziel

Weitere Funktionen werden später ergänzt.