Erstellen einer SIFYBOX aus mehreren Diensten

Wie man versionierte Images in die Dienste kompiliert, die ein bestimmter Prozess benötigt, und wie man jeden dieser Dienste lokal oder remote ausführt.

Publikum: Implementierer, Infrastrukturmanager, Lösungsarchitekt, DERS L2/L3
Ergebnis: Eine lesbare Konfiguration legt die aktivierten Dienste, ihre genauen Versionen und Adressen fest; die Compose-Datei des Anbieters wird vom Kunden nicht manuell überschrieben.

1. Drei Lieferebenen

DERS wird eine unveränderliche Basis-Compose.yaml-Datei und ein Release-Manifest mit vollständigen Image-Namen und Digests veröffentlichen.
Die Installation fügt der Datei site.env nicht-geheime Werte hinzu: öffentliche URL, Dienstadressen, Zeitzone und ausgewählter Betriebsmodus.
Passwörter, Tokens und Zertifikate werden separat als Docker-Secrets-Dateien oder über Vault übergeben; sie gehören nicht in die Release-Datei oder in Git.
Die Kundenänderung wird in einer unterstützten Überschreibungsdatei oder über Variablen vorgenommen, nicht durch Änderung der Lieferantenbasis.

2. Bild- und Freigabeparameter

Der Registry-Host ist üblich, aber die vollständigen Pfade, Namen und Digests müssen aus einem Release-unterstützten Manifest stammen. Die folgende Notation stellt ein angestrebtes Designmuster dar, kein fertiges Release-Runbook.

ArbeitsbeispielErsetzen Sie die Werte <…> durch Angaben aus dem Release

# .env.release — spravuje DERS spolu s konkrétním releasem
# Úplné názvy image a digesty se přebírají z release manifestu.
OOD_IMAGE=registry.ders.cz/<PROJECT>/<OOD_IMAGE>@sha256:<DIGEST>
DOG_IMAGE=registry.ders.cz/<PROJECT>/<DOG_IMAGE>@sha256:<DIGEST>
FS_IMAGE=registry.ders.cz/<PROJECT>/<FS_IMAGE>@sha256:<DIGEST>
ZST_IMAGE=registry.ders.cz/<PROJECT>/<ZST_IMAGE>@sha256:<DIGEST>
EPK_IMAGE=registry.ders.cz/<PROJECT>/<EPK_IMAGE>@sha256:<DIGEST>
WSCS_IMAGE=registry.ders.cz/<PROJECT>/<WSCS_IMAGE>@sha256:<DIGEST>
CUL_IMAGE=registry.ders.cz/<PROJECT>/<CUL_IMAGE>@sha256:<DIGEST>
CULWS_IMAGE=registry.ders.cz/<PROJECT>/<CULWS_IMAGE>@sha256:<DIGEST>
POSTGRES_IMAGE=<SUPPORTED_POSTGRES_IMAGE>@sha256:<DIGEST>

# .env.site — nesekretní parametry konkrétní instalace
PUBLIC_BASE_URL=https://<SIFYBOX_FQDN>
TZ=Europe/Prague
DOG_BASE_URL=http://dog:<PORT_FROM_RELEASE>
FS_BASE_URL=http://fs:<PORT_FROM_RELEASE>
ZST_BASE_URL=http://zst:<PORT_FROM_RELEASE>
EPK_BASE_URL=http://epk:<PORT_FROM_RELEASE>
WSCS_BASE_URL=http://wscs:<PORT_FROM_RELEASE>
CUL_BASE_URL=http://cul:<PORT_FROM_RELEASE>
CULWS_BASE_URL=http://culws:<PORT_FROM_RELEASE>

3. Lokale Dienste aktivieren

Ziel-Designmuster: Jeder optionale Dienst verfügt über ein eigenes Compose-Profil. Wenn das Profil nicht aktiviert ist, muss die BASE_URL auf eine verifizierte Remote-Instanz verweisen. Bestimmte Profile und Variablen müssen vom Anwendungs-Repository übernommen werden.

ArbeitsbeispielErsetzen Sie die Werte <…> durch Angaben aus dem Release

name: sifybox

services:
  ood:
    image: ${OOD_IMAGE:?OOD_IMAGE is required}
    env_file:
      - /etc/sifybox/env/site.env
    environment:
      DOG_BASE_URL: ${DOG_BASE_URL:?DOG_BASE_URL is required}
      FS_BASE_URL: ${FS_BASE_URL:?FS_BASE_URL is required}
      ZST_BASE_URL: ${ZST_BASE_URL:?ZST_BASE_URL is required}
      EPK_BASE_URL: ${EPK_BASE_URL:?EPK_BASE_URL is required}
      CUL_BASE_URL: ${CUL_BASE_URL:?CUL_BASE_URL is required}
      CULWS_BASE_URL: ${CULWS_BASE_URL:?CULWS_BASE_URL is required}
    secrets:
      - db_password

  dog:
    image: ${DOG_IMAGE:?DOG_IMAGE is required}
    profiles: [dog-local]
    networks: [sifybox-backend]

  fs:
    image: ${FS_IMAGE:?FS_IMAGE is required}
    profiles: [fs-local]
    networks: [sifybox-backend]

  zst:
    image: ${ZST_IMAGE:?ZST_IMAGE is required}
    profiles: [zst-local]
    networks: [sifybox-backend]

  epk:
    image: ${EPK_IMAGE:?EPK_IMAGE is required}
    profiles: [epk-local]
    networks: [sifybox-backend]

  wscs:
    image: ${WSCS_IMAGE:?WSCS_IMAGE is required}
    profiles: [wscs-local]
    networks: [sifybox-backend]

  cul:
    image: ${CUL_IMAGE:?CUL_IMAGE is required}
    profiles: [cul-local]
    networks: [sifybox-backend]

  culws:
    image: ${CULWS_IMAGE:?CULWS_IMAGE is required}
    profiles: [culws-local]
    networks: [sifybox-backend]

networks:
  sifybox-backend:
    internal: true

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

4. Lokaler und Fernmodus

ArbeitsbeispielErsetzen Sie die Werte <…> durch Angaben aus dem Release

# Lokální sestava: služby běží jako kontejnery stejného Compose projektu
docker compose   --env-file /etc/sifybox/env/release.env   --env-file /etc/sifybox/env/site.env   config --quiet

# Vzdálená služba: její profil se nezapne a BASE_URL vede na řízený endpoint.
# Příklad: WSCS_BASE_URL=https://<REMOTE_WSCS_FQDN>
docker compose   --env-file /etc/sifybox/env/release.env   --env-file /etc/sifybox/env/site.env   config --quiet

Hinweis: Das einfache Deaktivieren des Profils reicht nicht aus. Vor dem Start muss die Validierung die Verfügbarkeit des Remote-Dienstes, TLS, Authentifizierung, kompatible API-Version und das Verbot von Zirkelbezügen oder unerwünschten öffentlichen Netzwerkrouten überprüfen.

5. Regeln für jeden optionalen Service

Nur ein aktives Ziel: lokaler Container oder Remote-Endpunkt.
In beiden Modi gilt derselbe versionierte API-Vertrag.
Separater Gesundheits-/Bereitschaftstest und klares erwartetes Ergebnis.
TLS und technische Identität auch innerhalb eines vertrauenswürdigen Netzwerks, wenn das Sicherheitsmodell dies erfordert.
Timeout, Wiederholungsversuch, Schutzschalter und Korrelations-ID sind im Integrationsprofil beschrieben.
Der Moduswechsel ist ein kontrollierter Vorgang mit Test und Return, keine Live-Bearbeitung.

6. Beispiel für eine Aufstellungsentscheidung

Lokales OOD: der Kern einer spezifischen Installation und ihre Prozessdefinition.
DOG lokal oder gemeinsam genutzt: abhängig von der Sensibilität der Eingabedaten, der Leistung und der Verantwortlichkeit für die Vorlage.
FS und ZST lokal oder als verwalteter interner Dienst: nur bei bestätigter Trennung von Mandanten und Berechtigungen.
EPK und WSCS lokal oder remote: abhängig von der Signaturarchitektur, dem HSM und der Verfügbarkeit des Signaturanbieters.
CUL/CULWS nach Dokumentenstandort, Aufbewahrung, Leistung und eSSL-Bindung.
Jede Entscheidung wird im Installationsprotokoll aufgezeichnet, einschließlich des Eigentümers, des Datenstroms und der Wiederherstellungsmethode.

Nächste Anleitung

Die Runbooks arbeiten zusammen.

Was muss das Installationspaket enthalten?→Installation aus Docker-Images und Docker Compose→Konfiguration, Passwörter und Vault→