Všechny postupy
Ve výstavbě · pracovní verze vyžaduje release manifest

Technický postup

Sestavení SIFYBOXU z více služeb

Jak z verzovaných images složit právě ty služby, které daný proces potřebuje, a každou z nich provozovat lokálně nebo vzdáleně.

Pro koho
Implementátor, správce infrastruktury, architekt řešení, DERS L2/L3
Výsledek
Jedna čitelná konfigurace určuje zapnuté služby, jejich přesné verze a adresy; dodavatelský Compose soubor se u zákazníka ručně nepřepisuje.

01

1. Tři vrstvy dodávky

  1. DERS vydá neměnný základ compose.yaml a release manifest s úplnými názvy images a digesty.
  2. Instalace doplní nesekretní hodnoty do site.env: veřejné URL, adresy služeb, časovou zónu a zvolený provozní režim.
  3. Hesla, tokeny a certifikáty se předají zvlášť jako soubory Docker secrets nebo přes Vault; nepatří do release ani do Gitu.
  4. Zákaznická změna se provádí v podporovaném override souboru nebo přes proměnné, nikoli úpravou dodavatelského základu.

02

2. Image a parametry release

Registry host je společný, ale úplné cesty, názvy a digesty musí pocházet z manifestu podporovaného release. Následující zápis je cílový návrhový vzor, ne hotový release runbook.

Pracovní vzorHodnoty <…> doplňte z 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>

03

3. Zapínání lokálních služeb

Cílový návrhový vzor: každá volitelná služba má vlastní Compose profil. Když se profil nezapne, BASE_URL musí vést na ověřenou vzdálenou instanci. Konkrétní profily a proměnné musí potvrdit aplikační repozitář.

Pracovní vzorHodnoty <…> doplňte z 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

04

4. Lokální a vzdálený režim

Pracovní vzorHodnoty <…> doplňte z 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

Pozor: Pouhé vypnutí profilu nestačí. Před startem musí validace ověřit dostupnost vzdálené služby, TLS, autentizaci, kompatibilní verzi API a zákaz kruhového nebo veřejně nechtěného síťového směru.

05

5. Pravidla pro každou volitelnou službu

  • Právě jeden aktivní cíl: lokální kontejner nebo vzdálený endpoint.
  • Stejný verzovaný kontrakt API v obou režimech.
  • Samostatný health/readiness test a jednoznačný očekávaný výsledek.
  • TLS a technická identita i uvnitř důvěryhodné sítě, pokud to vyžaduje bezpečnostní model.
  • Timeout, retry, circuit breaker a korelační ID popsané v integračním profilu.
  • Přepnutí režimu je řízená změna s testem a návratem, nikoli editace za provozu.

06

6. Příklad rozhodnutí o sestavě

  • OOD lokálně: jádro konkrétní instalace a její procesní definice.
  • DOG lokálně nebo sdíleně: podle citlivosti vstupních dat, výkonu a odpovědnosti za šablony.
  • FS a ZST lokálně nebo jako řízená interní služba: jen při potvrzeném oddělení tenantů a oprávnění.
  • EPK a WSCS lokálně nebo vzdáleně: podle podpisové architektury, HSM a dostupnosti poskytovatele podpisu.
  • CUL/CULWS podle umístění dokumentů, retence, výkonu a vazby na eSSL.
  • Každé rozhodnutí se zapíše do instalačního protokolu včetně vlastníka, datového toku a způsobu obnovy.