Services Debian systemctl
Suite à mon dernier article, j’ai été confronté à un problème que j’ai mis longtemps à identifier.
Lorsque je mets à jour mon site web, mettons celui du staging avec une nouvelle publication, je modifie les fichiers à la racine du projet, c’est à dire var/etc/www/staging.blazordemo.reactor.fr/ dans mon cas.
Pour ma part j’applique une politique du « j’effface tout » et « j’upload tout ». Pas de remplacement de fichier. C’est plus long mais je suis certain qu’il y a pas un mauvais fichier en ligne.
Hormis des pb de cache ou de rafraichissement, mon site web est bien à jour.
Mais pas mon service Kernel. En tout cas sur linux Nginx, lorsque je rajoute par exemple un controler « api/plateform » coté serveur, si je ne relance pas mon service avec les commandes suivantes :
sudo systemctl stop kestrel-staging.blazordemo.reactor.fr.service
sudo systemctl start kestrel-staging.blazordemo.reactor.fr.service
sudo systemctl status kestrel-staging.blazordemo.reactor.fr.servicemon api « plateform » ne sera pas accessible. En tapant ces commandes, l’api est accessible. Il serait bon d’inclure cela dans la pipeline, histoire qu’on est rien à faire à la main à chaque run de pipeline si le code c# est modifié coté serveur.
Pour cela, il suffit de rajouter ces lignes :
- task: SSH@0
displayName: 'Restart Kestrel Service'
inputs:
sshEndpoint: 'SSH to Ikoula'
runOptions: 'commands'
commands: |
sudo systemctl stop kestrel-staging.blazordemo.reactor.fr.service
sudo systemctl start kestrel-staging.blazordemo.reactor.fr.service
sudo systemctl status kestrel-staging.blazordemo.reactor.fr.service
readyTimeout: '20000'Ca donne ça dans les ‘logs’ des jobs de l’execution du pipeline :
