Produits Entr'ouvert » Publik Installation Développeur

Emmanuel Cazenave a écrit :

On pourrait conserver ce pattern mais en changeant supervisord par systemd.

C'était juste une suggestion. Perso je pensais que uwsgi pouvait suffire mais je dois rater un truc.

J'ai entendu dire "supervisord n'est plus maintenu",

j'étais resté sur le "trou" de 4 ans entre 3.0 fournie dans Debian, qui datait de 2013, et la release suivante 3.0.1 de 2017, année de la renaissance, apparemment.

Je voulais pointer #16805 (qui est le ticket qui passerait hobo-agent à systemd dans nos déploiements) mais pour la situation locale, que ça soit supervisor ou systemd, je ne trouverais pas ça pratique et donc j'expose dans ce ticket ce que j'ai déjà écrit ailleurs : le plus efficace que j'ai trouvé c'est avoir un screen configuré en local, un écran par application,

screen -t authentic sh -c "(cd src/eo/authentic; bash)" 
screen -t hobo sh -c "(cd src/eo/hobo; bash)" 
screen -t hobo-agent sh -c "(cd src/eo/hobo; bash)" 
screen -t welco sh -c "(cd src/eo/welco; bash)" 
screen -t combo sh -c "(cd src/eo/combo; bash)" 
screen -t corbo sh -c "(cd src/eo/corbo; bash)" 
screen -t chrono sh -c "(cd src/eo/chrono; bash)" 
screen -t fargo sh -c "(cd src/eo/fargo; bash)" 
screen -t passerelle sh -c "(cd src/eo/passerelle; bash)" 
screen -t auquo sh -c "(cd src/eo/wcs; bash)" 
screen -t bijoe sh -c "(cd src/eo/bijoe; bash)" 

Initialement j'avais un ./run.sh plutôt que les appels à bash mais dans la pratique j'ai trouvé plus utile d'avoir juste un shell (plutôt qu'avoir l'écran de screen disparaitre si jamais runserver plantait pour une raison ou une autre).

(je ne dis pas qu'il faut faire ça comme ça dans publik-devinst).

Thomas Noël a écrit :

C'était juste une suggestion. Perso je pensais que uwsgi pouvait suffire mais je dois rater un truc.

Ce qui m'embête avec uwsgi c'est qu'on ne pourra pas arrêter simplement un unique app-server pour basculer en debug, on les arrêtera tous d'un coup avec

sudo systemctl stop uwsgi

Frédéric Péters a écrit :

que ça soit supervisor ou systemd, je ne trouverais pas ça pratique

Pourquoi pas pratique ?

En compromis je pourrais exposer une option de configuration pour que les services (systemd ou supervisord) ne soient pas en autostart pour qui le désire, ce qui permettrait à chacun de faire sa vie avec ses screen, tmux whatever.

Pourquoi pas pratique ?

Parce qu'il n'y a pas de terminal associé avec l'application, poser un pdb est compliqué. (et aussi mais ça doit aller mieux maintenant la configuration côté logging n'a pas toujours été terrible, alors qu'un terminal un print c'est l'amour toujours).

Parce qu'il n'y a pas de terminal associé avec l'application, poser un pdb est compliqué. (et aussi mais ça doit aller mieux maintenant la configuration côté logging n'a pas toujours été terrible, alors qu'un terminal un print c'est l'amour toujours).

D'accord avec tout, c'est pour ça que j'avais prévu les commandes app-server et hobo-agent dans le virtualenv. Personnellement j'aime bien le pattern que je propose : par défaut supervisord qui gère et facile pour basculer en terminal/debug. Enfin bref chacun ses goûts.