J'ai donc une application composée d'une API et d'un service Windows (encapsulé par Topshelf) qui écoute en permanence les événements à l'aide de RabbitMQ et traite les données à la demande.
Pour l'éducation et le plaisir, j'essaie de réécrire cela dans une configuration équivalente qui fonctionnerait sur .NET Core et unix (par exemple dans un conteneur Docker sur AWS)
Quelle serait la meilleure façon d'implémenter quelque chose d'équivalent à un service Windows comme celui-ci (processus d'arrière-plan permanent) en utilisant .NET Core si je veux le garder multiplateforme?
Le service Windows en lui-même est une application console conforme aux règles et protocoles d'interface de Windows Service Control Manager. Vous pouvez obtenir la même chose sur les deux plates-formes en utilisant l'application de console de base .net en tant qu'hôte, ce qui nécessitera une configuration supplémentaire pour qu'elle se comporte davantage comme un véritable service/démon.
Par exemple. pour Linux, vous pouvez utiliser SystemD . Vous devez d'abord créer un fichier de configuration SystemD avec quelque chose comme ceci:
[Unit]
Description=daemon service
After=network.target
[Service]
ExecStart=/usr/bin/dotnet $(pwd)/bin/daemonsrv.dll 10000
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF
Et puis configurez SystemD pour le rendre conscient de la configuration de votre service
# Copy service file to a System location
Sudo cp daemonsrv.service /lib/systemd/system
# Reload SystemD and enable the service, so it will restart on reboots
Sudo systemctl daemon-reload
Sudo systemctl enable daemonsrv
# Start service
Sudo systemctl start daemonsrv
# View service status
systemctl status daemonsrv
Pour Windows, vous devriez faire la même chose, mais avec un ensemble d'outils différent. Vous devrez utiliser un gestionnaire de services tiers pour éviter une liaison Windows serrée. Par exemple. vous pouvez utiliser NSSM . Et voici l'article de Nice avec des exemples à ce sujet - . Application de console Net Core en tant que service Windows .
De plus, vous pouvez toujours utiliser une configuration de service Windows normale comme un hôte dans le cas d'un Windows. Et écrivez un autre hôte pour vos environnements Unix (hôte de l'application console). Les deux peuvent partager la logique métier et seule la façon dont ils réagiront aux événements du système sera différente.
J'espère que cela aide.