web-dev-qa-db-ja.com

.NET Coreのクロスプラットフォームバックグラウンドサービス（Windowsサービス/ Unixデーモンについて）

そのため、RabbitMQを使用してイベントを継続的にリッスンし、データをオンデマンドで処理するAPIとWindowsサービス（Topshelfでラップ）で構成されるアプリがあります。

教育と楽しみのために、これを.NET Coreとunix（AWSのdockerコンテナなど）で実行される同等のセットアップに書き直そうとしています。

クロスプラットフォームを維持したい場合、.NET Coreを使用して、そのようなWindowsサービス（永久に実行されるバックグラウンドプロセス）と同等のものを実装する最良の方法は何ですか？

unixcross-platform.net-coredaemon
28
valorl

Windowsサービス自体は、Windowsサービスコントロールマネージャーのインターフェイスルールとプロトコルに準拠するコンソールアプリケーションです。ホストとして.netコアコンソールアプリケーションを使用して、両方のプラットフォームで同じことを実現できます。実際のサービス/デーモンのように動作するには、追加の構成が必要になります。

Linux

例えば。 Linuxの場合、 SystemD を使用できます。最初に次のようなものでSystemD構成ファイルを作成する必要があります。

[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

そして、SystemDを構成して、サービス構成を認識させます

# 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

ウィンドウズ

Windowsの場合は、ほとんど同じですが、異なるツールセットを使用する必要があります。 Windowsの緊密なバインドを回避するには、サードパーティのサービスマネージャーを使用する必要があります。例えば。 [〜＃〜] nssm [〜＃〜] を使用できます。そして、それについての例が記載されたニースの記事- Windowsサービスとしての.Net Coreコンソールアプリケーション 。

ただし、Windowsの場合は、通常のWindowsサービスセットアップをホストとして使用できます。 Unix環境用に別のホストを作成します（コンソールアプリホスト）。どちらもビジネスロジックを共有できますが、システムイベントに対する反応のみが異なります。

それが役に立てば幸い。

16
n.yakovenko