Nouvelle version de Sentinel API¶

Thomas a développé une nouvelle version de Sentinel API qui ne nécessite plus de déployer NiFi. Elle se trouve dans la repo https://github.com/computablefacts/cf-sentinel-api-rq.

A terme, cette version va remplacer la Sentinel API actuelle.

L'objectif est de déployer cette nouvelle version avec Towerify CLI.

2025-05-12 - Point Pierre et Thomas¶

Décisions :

je vais ajouter le déploiement dans la nouvelle repo
nous archiverons l'ancienne repo quand elle ne sera plus utilisée

Il y a 4 interfaces web à exposer :

la nouvelle API
RQ Dashboard
Open Observe
Mongo Express (optionnel)

Il y a 3 images Docker à exposer :

la nouvelle API (fastapi.Dockerfile)
RQ Dashboard (dashboard-rq.Dockerfile)
Le worker (wrq.Dockerfile)

Réflexions¶

Avec towerify deploy, je ne peux builder qu'une seule image Docker. Cette image est utilisée dans une stack Docker Swarm qui peut contenir d'autres services. Mais un seul de ces services peut être exposé sur l'URL de l'application YunoHost déployée.

C'était déjà le cas avec la version actuelle de Sentinel API que j'avais "découpée" en 3 stacks (nifi, sentinel-api et worker) pour builder 3 containers et exposer 3 services sur les 3 URLs externes. Mais cette technique a un inconvénient majeur : le code partagé entre les différents containers doit être dupliqué dans les différents sous-dossiers des 3 apps déployées par Towerify CLI.

Une solution pour le build pourrait être une instruction Docker Compose qui est capable de builder les images décrites dans le fichier stack.yaml comme le suggère un post de StackOverflow :

docker-compose build
docker-compose push
docker stack deploy

Réf : https://stackoverflow.com/a/54448433/2510409

Une solution pour exposer plusieurs services derrière la même URL d'une seule application YunoHost pourrait être d'ajouter un service nginx qui reverrait le flux vers le bon service interne en fonction du chemin de l'URL. Par exemple :

/oo/ -> Open Observe
/rq/ -> RQ Dashboard
/me/ -> Mongo Express
sinon -> Sentinel API

Idéalement, il faudrait que le fichier compose.yaml de la racine de la repo soit celui utilisé pour la stack de Docker Swarm lors du déploiement. Donc que ce fichier permette également de lancer l'application en local pour le développement.

Actions¶

Les volumes Docker en sous-dossiers¶

Towerify CLI impose d'avoir les volumes de la stack créés relativement au fichier stack.yaml (dans un sous-dossier).

Je fais donc ce changement : - suppression des volumes Docker classiques - changement pour un chemin relatif pour chaque volume

Mais j'ai un problème sur mon poste car ma repo se trouve dans une partition NTFS Windows qui, donc, ne gère pas les droits Linux. Cela empêche MongoDB de démarrer avec les messages d'erreur suivants :

mongodb-1  | {"t":{"$date":"2025-05-16T10:31:23.479+00:00"},"s":"F",  "c":"STORAGE",  "id":28595,   "ctx":"initandlisten","msg":"Terminating.","attr":{"reason":"1: Operation not permitted"}}
mongodb-1  | {"t":{"$date":"2025-05-16T10:31:23.479+00:00"},"s":"F",  "c":"ASSERT",   "id":23091,   "ctx":"initandlisten","msg":"Fatal assertion","attr":{"msgid":28595,"file":"src/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp","line":760}}
mongodb-1  | {"t":{"$date":"2025-05-16T10:31:23.479+00:00"},"s":"F",  "c":"ASSERT",   "id":23092,   "ctx":"initandlisten","msg":"\n\n***aborting after fassert() failure\n\n"}

Pour résoudre ce problème sur mon poste, j'ai créé un dossier :

mkdir -p ~/.tmp/sentinel-api-volumes

Puis j'ai fait un lien dans la repo vers ce dossier :

cd /mnt/data/dev/computablefacts/cf-sentinel-api-rq
ln -s ~/.tmp/sentinel-api-volumes/ ./volumes

Une seule URL avec plusieurs services¶

Je commence par ajouter un service nginx qui va me servir de proxy pour accéder aux autres services.

Pour RQ Dashboard, je l'expose sur /rq/ et il a une option pour que les liens qu'il génère ajouter ce chemin (RQ_DASHBOARD_URL_PREFIX=/rq/).

La conf nginx :

server {
    listen 80;

    # RQ Dashboard
    location /rq/ {
        proxy_pass http://rq-dashboard:9181/rq/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Port $server_port;
        proxy_set_header X-Forwarded-Prefix /rq/;
        proxy_redirect default;
    }

    # Sentinel API
    location / {
        proxy_pass http://fastapi:80/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Port $server_port;
    }
}

NOTA : je ne suis pas sûr d'avoir besoin de transmettre toutes les entêtes mais je les ai laissées tout de même.

J'ai fait la même chose pour OpenObserve en ajoutant cette conf à nginx :

    # OpenObserve
    location /oo/ {
        proxy_pass http://openobserve:5080/oo/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Port $server_port;
        proxy_set_header X-Forwarded-Prefix /oo/;
        proxy_redirect default;
    }

Puis en ajoutant l'option ZO_BASE_URI: "/oo/". J'ai également ajouté ZO_WEB_URL: "http://localhost:8043/oo/" pour que les liens des alertes soient corrects.

Voir la doc sur les options disponibles.