Installation aus Docker-Images und Docker Compose

01

1. Übernahme und Inspektion

1. Laden Sie das Release-Manifest, die Compose-Datei, die Konfigurationsvorlage, die Checkliste für Geheimnisse und das Runbook herunter.
2. Überprüfen Sie die Prüfsummen und Registrierungsberechtigungen. Verwenden Sie nicht das neueste Tag.
3. Images werden per kontrolliertem Pull aus der Kundenumgebung heruntergeladen; die Installation sollte keinen eingehenden Servicezugriff erfordern, nur um eine neue Version zu verteilen.
4. Vergleichen Sie die unterstützte Docker Engine, das Compose-Plugin, das Betriebssystem, die Datenbank und die CPU mit der Zielumgebung. Die Verwendung von PostgreSQL, Oracle Database oder Microsoft SQL Server muss anhand der versionsspezifischen Matrizen bestätigt werden.
5. Notieren Sie den Anlagenbesitzer, das Servicefenster, den Rücksendepunkt und die L1/L2/L3-Kontakte.

02

2. Diensttopologie

SIFYBOX besteht nicht aus einem einzigen universellen Container. Compose aktiviert lediglich die für eine spezifische Lösung benötigten Dienste.

• OOD verwaltet Fälle, Formulare, Status und Rollen.
• DOG erstellt Dokumente aus Vorlagen und Daten.
• FS wendet Finanzregeln an und überprüft gemäß dem Integrationsvertrag die Quelle oder erstellt eine aussagekräftige Momentaufnahme; die Buchhaltung verbleibt im Wirtschaftssystem.
• ZST übergibt die ausgewählte Rolle für einen begrenzten Zeitraum.
• EPK verwaltet Genehmigungs- und Signaturvorgänge; WSCS führt die Signatur technisch gemäß der Konfiguration durch.
• CUL speichert Dokumente, Metadaten und Versionen; CULWS bietet Integrationsdienste.
• Keycloak/IdP, eSSL, Wirtschaftssystem, SMTP, Vault und Monitoring können externe Kundendienste sein.

03

3. Konfigurationsdatei

Ziel-Designmuster, kein validiertes Release-Runbook. Werte, _FILE-Unterstützung, Healthchecks, Migrationen und Variablennamen müssen anhand des Manifests und des Repositorys des jeweiligen Releases bestätigt werden.

# /etc/sifybox/env/release.env — úplné image reference z manifestu
OOD_IMAGE=registry.ders.cz/<PROJECT>/<OOD_IMAGE>@sha256:<DIGEST>
POSTGRES_IMAGE=<SUPPORTED_POSTGRES_IMAGE>@sha256:<DIGEST>

# /etc/sifybox/env/site.env — nesekretní parametry instalace
COMPOSE_PROFILES=dog-local,fs-local,zst-local,epk-local,wscs-local,cul-local,culws-local
PUBLIC_BASE_URL=https://<FQDN>
DB_NAME=<DATABASE_NAME>
DB_USER=<DATABASE_USER>
OIDC_ISSUER=https://<KEYCLOAK_OR_IDP>/realms/<REALM>
OIDC_CLIENT_ID=<CLIENT_ID>
TZ=Europe/Prague

04

4. Compose als Service-Stack

Das Ziel-Designmuster erläutert das Prinzip vollständiger Image-Referenzen, interner Netzwerke und Geheimnisse. Die tatsächlichen Namen, Integritätsprüfungen, Volumes und Befehle stammen aus dem jeweiligen Release-Repository.

# Cílový návrhový vzor — názvy parametrů, healthchecky a příkazy
# musí potvrdit manifest a runbook konkrétního release.
name: sifybox

services:
  ood:
    image: ${OOD_IMAGE:?OOD_IMAGE is required}
    env_file:
      - /etc/sifybox/env/site.env
    networks: [sifybox-backend]
    secrets: [db_password, oidc_client_secret]

  database:
    image: ${POSTGRES_IMAGE:?POSTGRES_IMAGE is required}
    networks: [sifybox-backend]
    environment:
      POSTGRES_DB: ${DB_NAME:?DB_NAME is required}
      POSTGRES_USER: ${DB_USER:?DB_USER is required}
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets: [db_password]
    volumes:
      - postgres_data:/var/lib/postgresql/data

networks:
  sifybox-backend:
    internal: true

volumes:
  postgres_data:

secrets:
  db_password:
    file: /etc/sifybox/secrets/db_password
  oidc_client_secret:
    file: /etc/sifybox/secrets/oidc_client_secret

05

5. Erste Inbetriebnahme

# Cílový návrhový vzor. Před použitím ověřte release runbook.
COMPOSE=(docker compose --env-file /etc/sifybox/env/release.env --env-file /etc/sifybox/env/site.env)

# 1. Kontrola výsledné konfigurace bez spuštění
"${COMPOSE[@]}" config --quiet

# 2. Stažení přesně určených images
"${COMPOSE[@]}" pull

# 3. Kontrola použitých digestů
"${COMPOSE[@]}" images --format json

# 4. Spuštění databáze a ověření jejího health stavu
"${COMPOSE[@]}" up -d database
"${COMPOSE[@]}" ps

# 5. Migrace – použijte pouze příkaz z release runbooku
"${COMPOSE[@]}" run --rm ood <MIGRATION_COMMAND_FROM_RELEASE>

# 6. Spuštění aplikačních služeb
"${COMPOSE[@]}" up -d

# 7. Kontrola stavu a posledních logů
"${COMPOSE[@]}" ps
"${COMPOSE[@]}" logs --since=10m --no-color

Hinweis: Eine Migration darf niemals auf gut Glück durchgeführt werden. Sie muss idempotent sein oder eine präzise beschriebene Rückgabeprozedur im Release-Runbook aufweisen.

06

6. Abnahme-Rauchtest

1. Melden Sie den Testbenutzer über den Ziel-IdP an und überprüfen Sie die Rollenzuweisungen.
2. Erstellen Sie einen Testfall, hängen Sie ein Dokument an und führen Sie einen Workflow-Übergang durch.
3. Erzeugen Sie ein Dokument, wenn DOG zum Stack gehört.
4. Überprüfen Sie die Übermittlung und den genauen Status, der vom Wirtschaftssystem oder eSSL zurückgegeben wird; verwechseln Sie nicht die technische Annahme mit der Veröffentlichung.
5. Überprüfen Sie das Audit: Identität, Zeit, Aktion, ursprünglicher und resultierender Zustand sowie Korrelations-ID.
6. Starten Sie einen Anwendungsdienst neu und überprüfen Sie, ob der Fall oder das Dokument nicht verloren gegangen ist.
7. Protokollversionen und Zusammenfassungen, Testergebnisse, Ausnahmen und Abnahmegenehmigungen.