Installation from Docker images and Docker Compose

01

1. Takeover and inspection

1. Download the release manifest, Compose file, configuration template, secrets checklist, and runbook.
2. Verify checksums and registry permissions. Do not use the latest tag.
3. Download images via controlled pull from the customer environment; installation should not require incoming service access just to distribute a new version.
4. Compare the supported Docker Engine, Compose plugin, OS, database, and CPU with the target environment. Use of PostgreSQL, Oracle Database, or Microsoft SQL Server must be confirmed by the release-specific matrices.
5. Write down the installation owner, service window, return point and L1/L2/L3 contacts.

02

2. Service topology

SIFYBOX does not consist of one universal container. Compose only enables the services needed for a specific solution.

• OOD manages case, form, status, and roles.
• DOG creates documents from templates and data.
• FS applies financial rules and, according to the integration contract, verifies the source or maintains a decisive snapshot; accounting remains in the economic system.
• ZST hands over the selected role for a limited period.
• EPK manages approval and signing tasks; WSCS technically performs signing according to configuration.
• CUL stores documents, metadata, and versions; CULWS provides integration services.
• Keycloak/IdP, eSSL, economic system, SMTP, Vault and monitoring can be external customer services.

03

3. Configuration file

Target design pattern, not a validated release runbook. Values, _FILE support, healthchecks, migrations, and variable names must be confirmed by the manifest and repository of the specific release.

# /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 as a service stack

The target design pattern explains the principle of full image references, internal networks, and secrets. The actual names, healthchecks, volumes, and commands are taken from the specific 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. First start-up

# 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

Note: Never run a migration by guesswork. It must be idempotent or have a precisely described return procedure in the release runbook.

06

6. Acceptance smoke test

1. Log in the test user through the target IdP and verify the role assignments.
2. Create a test case, attach a document, and perform one workflow transition.
3. Generate a document if DOG is part of the stack.
4. Verify the submission and the exact status returned by the economic system or eSSL; do not confuse technical acceptance with posting.
5. Verify the audit: identity, time, action, original and resulting state, and correlation ID.
6. Restart one application service and verify that the case or document is not lost.
7. Record versions and digests, test results, exceptions, and acceptance approvals.