В этом материале будет рассмотрено, как запускать приложение .NET Core / .NET 5 в качестве сервиса под Linux. Мы воспользуемся Systemd, чтобы интегрировать наше приложение с операционной системой, научимся запускать и останавливать наш сервис, а также получать от него логи.

Чтобы организовать атаку на цепочку поставок при помощи .NET, мне потребовалось настроить DNS-сервер, который перехватывал бы те хост-имена, которые ко мне направляются. Давайте возьмём этот кейс для примера.

❯ Создание .NET-приложения, которое будет работать как сервис

.NET-сервису потребуется использовать модель хостинга Microsoft.Extensions.Hosting, применяемую в Microsoft. Так мы обеспечим работоспособность любого приложения ASP.NET Core, а также проектов, выполняемых с применением шаблона Worker Service (dotnet new worker). Здесь будем работать с Rider.



Далее потребуется установить пакет NuGet: Microsoft.Extensions.Hosting.Systemd. Этот пакет предоставляет хостинговую инфраструктуру .NET для сервисов Systemd. Иными словами, в нём содержится инфраструктура, необходимая для работы с демоном Systemd под Linux.

Осталось сделать ещё одну вещь: зарегистрировать в нашем приложении хостинговые расширения Systemd. В Program.cs понадобится добавить .UseSystemd() к сборщику хоста:

public class Program
{
	// ...
 
	public static IHostBuilder CreateHostBuilder(string[] args) =>
    	Host.CreateDefaultBuilder(args)
        	.UseSystemd() // add this
        	.ConfigureServices((hostContext, services) =>
        	{
            	services.AddHostedService<Worker>();
        	});
}

Когда всё это настроено, наше приложение может работать как сервис Systemd под Linux! Ну, почти… Осталось сделать ещё две вещи:

• Написать приложение
• Зарегистрировать его для работы с Systemd

Начнём с первого пункта и реализуем DNS-сервер, который будем использовать в качестве сервиса.

❯ Реализуем сервер .NET DNS в качестве сервиса

DNS-сервер, рассмотренный здесь, пишется на .NET с применением отличного DNS-пакета от Мирзы Капетановича, а далее при помощи Systemd размещается на Linux как сервис.

Давайте соберём простой DNS-сервис, возвращающий актуальное время как запись в формате TXT.

Примечание: можете пропустить этот раздел, если просто хотите изучить, как регистрировать приложения .NET в качестве сервисов Systemd.

Сперва установим пакет DNS. В нём содержится почти готовый DNS-сервер, так что нам понадобится всего лишь записать его код и реализовать серверную логику.

Класс Worker, созданный на основе шаблона worker service (сервис-исполнитель) – хорошая отправная точка. В нём можно применить инъекцию конструктора, чтобы получить доступ ко всем сервисам, имеющимся в вашем приложении. Мы воспользуемся интерфейсом ILogger (уже имеющимся в шаблоне) и IConfiguration, чтобы получить доступ к appsettings.json/переменным окружения/аргументам командной строки. Здесь мы наследуем BackgroundService, в котором есть метод ExecuteAsync, именно этот метод и отвечает за выполнение нашего сервиса. Вот так выглядит костяк Worker:

public class Worker : BackgroundService
{
	private readonly ILogger<Worker> _logger;
	private readonly IConfiguration _configuration;
 
	public Worker(ILogger<Worker> logger, IConfiguration configuration)
	{
    	_logger = logger;
    	_configuration = configuration;
	}
 
	protected override async Task ExecuteAsync(CancellationToken stoppingToken)
	{
    	// ... здесь идёт вся логика ...
	}
}

Теперь давайте напишем сам DNS-сервер. В методе ExecuteAsync добавим следующий код:

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
	var server = new DnsServer(new SampleRequestResolver());
	server.Listening += (_, _) => _logger.LogInformation("DNS server is listening...");
	server.Requested += (_, e) => _logger.LogInformation("Request: {Domain}", e.Request.Questions.First().Name);
	server.Errored += (_, e) =>
	{
    	_logger.LogError(e.Exception, "An error occurred");
    	if (e.Exception is ResponseException responseError)
    	{
        	_logger.LogError("Response: {Response}", responseError.Response);
    	}
	};
 
	await Task.WhenAny(new[]
	{
    	server.Listen(
        	port: int.TryParse(_configuration["Port"], out var port) ? port : 53531,
        	ip: IPAddress.Any),
 
    	Task.Delay(-1, stoppingToken)
	});
}

А теперь объясню развёрнуто:

• Мы настраиваем DnsServer, который будет разрешать записи при помощи SampleRequestResolver (его нам ещё потребуется собрать).
• Мы подписываемся на некоторые события, предоставляемые DnsServer, так что сможем просматривать логи входящих запросов и сразу замечать, не пошло ли что-нибудь не так.
• Наконец, начинаем слушать входящие запросы.

Для ExecuteAsync мы передаём CancellationToken, который задействуется, когда Systemd прикажет нашему сервису завершиться. Поскольку сама библиотека DNS не поддерживает CancellationToken, я воспользуюсь здесь Task.WhenAny, чтобы запустить DNS-сервер. Так мы сможем завершить наш сервис, как только будет затребован его сброс.

Сам сервер будет слушать порт, указанный в конфигурации. Когда этот порт прямо не указан, по умолчанию задаётся 53531.

И ещё: тот самый класс SampleRequestResolver. Он должен реализовывать интерфейс IRequestResolver и собирать ответы на входящие DNS-запросы. Поскольку эта тема выходит за рамки данного поста, просто покажу быструю реализацию, которая возвращает текущие значения даты и времени для любой запрошенной TXT-записи. Для всех прочих запросов возвращается ошибка:

public class SampleRequestResolver : IRequestResolver
{
	public Task<IResponse> Resolve(IRequest request, CancellationToken cancellationToken = new CancellationToken())
	{
    	IResponse response = Response.FromRequest(request);
 
    	foreach (var question in response.Questions)
    	{
        	if (question.Type == RecordType.TXT)
        	{
            	response.AnswerRecords.Add(new TextResourceRecord(
                	question.Name, CharacterString.FromString(DateTime.UtcNow.ToString("O"))));
        	}
        	else
        	{
            	response.ResponseCode = ResponseCode.Refused;
        	}
    	}
 
    	return Task.FromResult(response);
	}
}

Попробуйте выполнить сервис на локальной машине и убедитесь – он работает! Его удобно протестировать при помощи таких инструментов как nslookup и dig.



Посмотрите README.md проекта DNS – там есть и другие примеры. Будьте осторожны, чтобы случайно не собрать открытый DNS-преобразователь, если исследуете, как обрабатывать вашу собственную DNS.

❯ Пишем конфигурацию сервисного блока

Давайте развернём наш сервис на Linux! Systemd использует файлы конфигурации сервисного блока, в которых определяется, что делает сервис, должен ли он перезапускаться, и всё подобное.

Вам потребуется создать файл .service на той машине с Linux, на которой вы собираетесь зарегистрировать и запускать сервис. В простейшей форме данный сервисный файл выглядит так:

[Unit]
Description=DNS Server
 
[Service]
Type=notify
ExecStart=/usr/sbin/DnsServer --port=53
 
[Install]
WantedBy=multi-user.target

В разделе [Unit] содержится самая общая информация о нашем приложении. Systemd может выполнять не только сервисы, и [Unit] – это общий раздел для всех типов приложений, которые можно так запускать. Я добавил только описание (Description), но здесь доступны и многие другие опции.

В разделе [Service] определяются детали, касающиеся нашего приложения. Для приложений .NET тип Type будет notify, так, что мы сможем уведомлять Systemd, когда хост начинает или завершает работу. За всё это отвечает пакет Microsoft.Extensions.Hosting.Systemd. В ExecStart определяется путь к двоичному файлу, используемому для запуска нашего сервиса. В показанном далее примере я воспользуюсь самодостаточным .NET-приложением и через аргумент командной строки сообщу ему, какой порт слушать.

Наконец, в разделе [Install] определяется, в каких операционных системах можно будет запускать наш сервис. В данном случае выставлено значение multi-user.target, при котором мы можем запускать сервис всякий раз, когда находимся в многопользовательской среде (то есть, почти всегда). Здесь также можно было бы задать graphical.target, и тогда для запуска этого сервиса у вас должна быть загружена графическая среда.

❯ Создаём самодостаточное .NET-приложение

Сам наш сервис должен быть доступен на машине с Linux, выбранной в качестве платформы, и на ней мы определим, где Systemd может найти его (это делается при помощи ExecStart): /usr/sbin/DnsServer.

Последнее, что нам остаётся сделать – развернуть .NET на целевой машине. Поэтому я решил собрать самодостаточное приложение, представляющее собой единый исполняемый файл – в нём содержится и среда выполнения .NET, и все необходимые зависимости. Для сборки приложения воспользуюсь следующей командой:

dotnet publish -c Release -r linux-x64 --self-contained=true -p:PublishSingleFile=true -p:GenerateRuntimeConfigurationFiles=true -o artifacts

Так создаётся исполняемый файл DnsServer размером примерно 62 МБ (внём содержится всё, что нам нужно от среды выполнения .NET). Скопируйте его в /usr/sbin/DnsServer на машине с Linux и убедитесь, что он поддаётся выполнению (sudo chmod 0755 /usr/sbin/DnsServer).

❯ Установка и запуск сервиса под Linux

Созданный нами файл .service (я назвал его dnsserver.service) должен находиться в каталоге /etc/systemd/system/ на той машине Linux, на которой мы собираемся разворачивать сервис.

Далее выполните следующую команду, чтобы Systemd загрузил этот новый конфигурационный файл:

sudo systemctl daemon-reload

На данном этапе мы уже должны быть в состоянии посмотреть статус нашего DNS-сервера, работающего как сервис:

sudo systemctl status dnsserver.service

Упомяну и несколько других команд, которые могут вам пригодиться:

• Для запуска и остановки сервиса:

sudo systemctl start dnsserver.service
sudo systemctl stop dnsserver.service
sudo systemctl restart dnsserver.service

• Чтобы убедиться, что сервис запускается одновременно с той машиной, на которой стоит Linux:

sudo systemctl enable dnsserver.service

Поздравляю, теперь у нас есть приложение .NET, работающее как сервис на Linux!

❯ Что происходит в моём сервисе?

Итак, сервис работает, но ведь ещё и интересно узнать, что он делает. Можно просмотреть самые свежие записи логов, которые выдаёт наше приложение. Для этого воспользуемся следующей командой:

sudo systemctl status dnsserver.service

Итак, мы видим, что сервис работает, можем узнать детали о процессе с заданным id, а также изучить последние записи логов.



Если логи вас очень интересуют, то при помощи journalctl можно вывести все логи для блока (-u) – это и есть наш DNS-сервер:

sudo journalctl -u dnsserver.service

В данном случае круто, что благодаря пакету Microsoft.Extensions.Hosting.Systemd мы также получаем здесь цветовые коды, а также данные об уровне серьёзности по каждой записи в логах:

❯ Заключение

В этом посте было рассмотрено, как использовать приложение .NET в качестве сервиса Systemd под Linux. Для этого мы воспользовались пакетом Microsoft.Extensions.Hosting.Systemd. Правда, мы только минимально познакомились с темой. Есть ещё множество опций, которые можно сообщить Systemd, ещё можно фильтровать уровни логов при помощи journalctl, и делать многое другое. Рекомендую посмотреть статью Нильса Свимберге, если хотите подробнее изучить эту тему.