Todos los manuales de operaciones
En construcción · El borrador requiere un manifiesto de lanzamiento

Manual de procedimientos técnicos

Construyendo un SIFYBOX a partir de múltiples servicios

Cómo compilar imágenes versionadas en los servicios que necesita un proceso determinado y ejecutar cada uno de ellos localmente o de forma remota.

Audiencia
Implementador, gestor de infraestructuras, arquitecto de soluciones, DERS L2/L3
Resultado
Un único archivo de configuración legible especifica los servicios habilitados, sus versiones exactas y sus direcciones; el cliente no sobrescribe manualmente el archivo Compose del proveedor.

01

1. Tres niveles de entrega

  1. DERS publicará un archivo compose.yaml base inmutable y un manifiesto de lanzamiento con los nombres completos de las imágenes y sus resúmenes.
  2. La instalación añadirá valores no secretos a site.env: URL pública, direcciones de servicio, zona horaria y modo de funcionamiento seleccionado.
  3. Las contraseñas, los tokens y los certificados se pasan por separado como archivos de secretos de Docker o a través de Vault; no deben incluirse en la versión ni en Git.
  4. El cambio de cliente se realiza en un archivo de anulación compatible o mediante variables, no modificando la base de datos de proveedores.

02

2. Parámetros de imagen y lanzamiento

El host del registro es común, pero las rutas completas, los nombres y los resúmenes deben provenir de un manifiesto compatible con la versión. La siguiente notación es un patrón de diseño objetivo, no un manual de lanzamiento definitivo.

Ejemplo de trabajoSustituya los valores <…> por los de la versión
# .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. Activación de los servicios locales

Patrón de diseño objetivo: cada servicio opcional tiene su propio perfil de Compose. Cuando el perfil no está habilitado, la URL base debe apuntar a una instancia remota verificada. El repositorio de la aplicación debe confirmar los perfiles y variables específicos.

Ejemplo de trabajoSustituya los valores <…> por los de la versión
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. Modo local y remoto

Ejemplo de trabajoSustituya los valores <…> por los de la versión
# 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

Nota: Deshabilitar el perfil no es suficiente. Antes de comenzar, se debe validar la disponibilidad del servicio remoto, TLS, la autenticación, la versión compatible de la API y la prohibición de enrutamiento de red circular o no deseado públicamente.

05

5. Normas para cada servicio opcional

  • Solo un objetivo activo: contenedor local o punto final remoto.
  • El mismo contrato de API versionado en ambos modos.
  • Prueba de salud/preparación independiente y resultado esperado claro.
  • TLS e identidad técnica incluso dentro de una red de confianza si el modelo de seguridad lo requiere.
  • Tiempo de espera, reintento, disyuntor e ID de correlación descritos en el perfil de integración.
  • El cambio de modo es una modificación controlada mediante prueba y retorno, no una edición en tiempo real.

06

6. Ejemplo de decisión de alineación

  • OOD localmente: el núcleo de una instalación específica y la definición de su proceso.
  • DOG local o compartido: dependiendo de la sensibilidad de los datos de entrada, el rendimiento y la responsabilidad de la plantilla.
  • FS y ZST de forma local o como un servicio interno gestionado: solo con separación confirmada de inquilinos y permisos.
  • EPK y WSCS de forma local o remota: dependiendo de la arquitectura de firma, el HSM y la disponibilidad del proveedor de firma.
  • CUL/CULWS por ubicación del documento, retención, rendimiento y enlace eSSL.
  • Cada decisión queda registrada en el registro de instalación, incluyendo el propietario, el flujo de datos y el método de recuperación.