DERS
Contact
FR
Menu
← Tous les manuels d'exploitation
En cours de rédaction · Le projet de travail nécessite un manifeste de libération

Manuel technique

Création d'une SIFYBOX à partir de plusieurs services

Comment compiler des images versionnées en services adaptés aux besoins d'un processus donné, et exécuter chacune d'elles localement ou à distance.

Public
Développeur, gestionnaire d'infrastructure, architecte de solutions, DERS L2/L3
Résultat
Une seule configuration lisible spécifie les services activés, leurs versions exactes et leurs adresses ; le fichier Compose du fournisseur n’est pas écrasé manuellement par le client.

01

1. Trois niveaux de livraison

  1. DERS publiera un fichier compose.yaml de base immuable et un manifeste de publication contenant les noms complets des images et leurs condensés.
  2. L'installation ajoutera des valeurs non secrètes au fichier site.env : l'URL publique, les adresses des services, le fuseau horaire et le mode de fonctionnement sélectionné.
  3. Les mots de passe, les jetons et les certificats sont transmis séparément sous forme de fichiers secrets Docker ou via Vault ; ils n'ont pas leur place dans la version ni dans Git.
  4. La modification du client est effectuée dans un fichier de remplacement pris en charge ou via des variables, et non en modifiant la base de fournisseurs.

02

2. Paramètres d'image et de diffusion

L'hôte du registre est commun, mais les chemins d'accès complets, les noms et les condensés doivent provenir d'un manifeste pris en charge par la version. La notation suivante correspond à un modèle de conception cible et non à un manuel de déploiement final.

Exemple de travailRemplacez les valeurs <…> par celles de la version
# .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. Activation des services locaux

Modèle de conception cible : chaque service optionnel possède son propre profil Compose. Lorsqu’un profil est désactivé, l’URL de base doit pointer vers une instance distante vérifiée. Les profils et variables spécifiques doivent être validés par le dépôt de l’application.

Exemple de travailRemplacez les valeurs <…> par celles de la version
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. Mode local et distant

Exemple de travailRemplacez les valeurs <…> par celles de la version
# 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

Remarque : La simple désactivation du profil ne suffit pas. Avant de commencer, la validation doit vérifier la disponibilité du service distant, le protocole TLS, l'authentification, la compatibilité de la version de l'API et l'absence de toute redirection de flux réseau non souhaitée ou publiquement.

05

5. Règles pour chaque service optionnel

  • Une seule cible active : conteneur local ou point de terminaison distant.
  • Même contrat d'API versionné dans les deux modes.
  • Test de santé/préparation distinct et résultat attendu clair.
  • TLS et identité technique même au sein d'un réseau de confiance si le modèle de sécurité l'exige.
  • Délai d'attente, nouvelle tentative, disjoncteur et ID de corrélation décrits dans le profil d'intégration.
  • Le changement de mode est une modification contrôlée avec test et retour, et non une modification en direct.

06

6. Exemple de décision concernant la composition de l'équipe

  • OOD localement : le cœur d’une installation spécifique et sa définition de processus.
  • DOG en local ou partagé : selon la sensibilité des données d’entrée, les performances et la responsabilité du modèle.
  • FS et ZST en local ou en tant que service interne géré : uniquement avec une séparation confirmée des locataires et des autorisations.
  • EPK et WSCS en local ou à distance : selon l’architecture de signature, la disponibilité du HSM et du fournisseur de signature.
  • CUL/CULWS par emplacement du document, conservation, performance et liaison eSSL.
  • Chaque décision est consignée dans le journal d'installation, y compris le propriétaire, le flux de données et la méthode de récupération.

Guide suivant

Les manuels d'exploitation fonctionnent ensemble.

Que doit contenir le package d'installation ?→Installation à partir d'images Docker et de Docker Compose→Configuration, mots de passe et Vault→