Как запустить приложение net core в Linux

Обновлено: 21.11.2024

Поддерживаемая платформа: Windows® (авторская разработка), Linux® (выполнение) и macOS (выполнение).

Предпосылки

Создайте новую рабочую папку, видимую для пути поиска MATLAB®. В этом примере в качестве новой рабочей папки используется C:\Work.

Для платформ Linux и macOS после установки MATLAB Runtime необходимо установить переменные среды LD_LIBRARY_PATH и DYLD_LIBRARY_PATH соответственно. Дополнительные сведения см. в разделе «Установка пути выполнения MATLAB для развертывания».

Создайте новый файл MATLAB с именем mymagic.m со следующим кодом в рабочей папке:

Введите libraryCompiler в командной строке MATLAB, чтобы запустить приложение Library Compiler.

В разделе Информация о библиотеке назовите библиотеку MyMatrixFunctions .

Дважды щелкните класс Class1 и переименуйте его в MyMagic .

Сохраните проект развертывания под именем MyMatrixFunctions .

Откройте командную строку в Windows и перейдите в папку C:\Work .

В командной строке введите:

При этом создается папка MyDotNetCoreApp со следующим содержимым:

Файл проекта MyDotNetCoreApp.csproj

Откройте файл проекта в текстовом редакторе.

Добавьте в проект следующие ссылки с помощью тега:

MWArray.dll , который находится в \toolbox\dotnetbuilder\bin\win64\

После добавления ссылок файл проекта должен выглядеть следующим образом:

В командной строке запустите приложение, введя:

Приложение отображает магический квадрат 3x3.

Опубликуйте проект как автономное развертывание, чтобы запустить приложение в Linux или macOS.

Чтобы опубликовать в Linux, введите следующую команду в одну строку:

Чтобы опубликовать в macOS, введите следующую команду в одну строку:

Скопируйте папку Release из C:\Work\MyDotNetCoreApp\bin в Windows в ~/Work на компьютере с Linux или macOS.

На компьютере с Linux убедитесь, что вы установили MATLAB Runtime и настроили переменную среды пути к библиотеке. Дополнительные сведения см. в разделе Предварительные требования.

Среда выполнения NET Core позволяет запускать в Linux приложения, созданные с помощью . NET Core, но не включает среду выполнения. С помощью SDK вы можете запускать, а также разрабатывать и создавать .

Опубликуйте свое приложение как автономное приложение: dotnet publish -c release -r ubuntu.16.04-x64 – self-contained.
Скопируйте папку публикации на компьютер с Ubuntu.
Откройте машинный терминал Ubuntu (CLI) и перейдите в каталог проекта.
Предоставить разрешения на выполнение: chmod 777 ./appname.

Его можно запустить из консоли, вызвав dotnet run из папки, содержащей проект. json-файл. На локальном компьютере вы можете подготовить приложение к развертыванию, запустив «dotnet publish». При этом создаются артефакты приложения, выполняется минимизация и т. д.

NET Core в Linux работает быстрее, чем тот же .

Как открыть командную строку dotnet core?

NET Core CLI устанавливается вместе с . NET Core SDK для выбранных платформ. Поэтому нам не нужно устанавливать его отдельно на машине разработки. Мы можем проверить правильность установки CLI, открыв командную строку в Windows, написав dotnet и нажав Enter.

Может ли приложение VB NET работать в Linux?

Как часть . NET Core 2 разработчики VB теперь могут писать консольные приложения и библиотеки классов, предназначенные для . NET Standard 2.0, и все они совместимы с несколькими платформами. Это означает, что тот же исполняемый файл или библиотека, которые работают в Windows, могут работать в macOS и Linux.

Что такое net core для начинающих?

Как запустить консольное приложение?

Создайте и запустите свой код в Visual Studio

Чтобы создать проект, выберите "Создать решение" в меню "Сборка". Окно вывода показывает результаты процесса сборки.
Чтобы запустить код, в строке меню выберите "Отладка", "Запустить без отладки". Откроется окно консоли, после чего запустится ваше приложение.

<р>. NET Core во всех моих тестах работал намного быстрее, чем полный . NET — иногда в 7, а то и в 13 раз быстрее. Выбор правильной архитектуры ЦП может кардинально изменить поведение вашего приложения, поэтому результаты, полученные для одной архитектуры, могут оказаться недействительными для другой, и наоборот.

NET Core 3.1 — версия с долгосрочной поддержкой (LTS), выпущенная три месяца назад и которая будет «жить» (поддерживаться) не менее трех лет. «Конец жизни» выпуска означает, что он не будет включен в будущем. NET Core исправления. Хотя он «прожил» всего около пяти месяцев, .

NET Framework предназначен только для Windows. NET, которая включает API для доступа к реестру Windows.

Чтобы научиться запускать ASP.NET Core (веб-материалы) в Linux, ознакомьтесь с разделом «Как запустить ASP.NET Core как службу в Linux без обратного прокси-сервера, без NGINX или Apache».

Начнем с создания нового консольного приложения с помощью интерфейса командной строки dotnet:

Убедитесь, что консольное приложение работает, запустив dotnet run . Вывод должен быть "Hello World!".
Если приложение работает, мы можем опубликовать его где-нибудь логически, например, /srv/HelloWorld:

Опубликованный результат содержит исполняемый файл HelloWorld, который запускает приложение. Давайте проверим, что мы также можем запустить опубликованное приложение:

Чтобы запускать сервисы в Linux, Systemd использует файлы конфигурации сервисного модуля для настройки сервисов.
Давайте создадим файл «HelloWorld.service» внутри нашего проекта, чтобы мы могли хранить его в системе управления версиями вместе с нашим кодом. Добавьте в файл следующее содержимое:

Обязательно обновите поле «Пользователь» до своего имени пользователя. Обратитесь к комментариям в файле для основного объяснения. Более подробную информацию можно найти на странице руководства freedesktop или в документации Red Hat.

Systemd ожидает, что все файлы конфигурации будут помещены в каталог '/etc/systemd/system/'. Скопируйте файл конфигурации службы в «/etc/systemd/system/HelloWorld.service». Затем скажите systemd перезагрузить файлы конфигурации и запустить службу.

С помощью команды `systemctl status` мы можем просмотреть статус службы:

В дополнение к команде состояния мы можем использовать команду journalctl для чтения всего, что наша служба выводит на консоль. Используя флаг модуля (-u), мы можем отфильтровать нашу службу HelloWorld.

Консольное приложение регистрирует только "Hello world!" в консоль, а затем выходит. При запросе статуса systemd сообщает, что служба неактивна (мертва). Это потому, что консольное приложение запускается, работает и сразу же закрывается. Это не очень полезно, поэтому давайте добавим код, который позволит приложению работать, пока не будет остановлено. Обновите Program.cs следующим содержимым:

Давайте снова опубликуем приложение:

Теперь у нас есть минимальное приложение, которое постоянно работает, пока не будет остановлено.
Если приложение останавливается из-за сбоя, systemd не будет автоматически перезапускать службу, если мы не настроим это. Добавьте параметры «Restart» и «RestartSec» в HelloWorld.service:

Скопируйте файл службы, перезагрузите и перезапустите службу:

Теперь служба будет автоматически перезапускаться в случае сбоя. Но при перезагрузке ОС приложение автоматически не запустится. Чтобы включить автоматический запуск службы при загрузке, выполните следующую команду:

Это консольное приложение работает нормально, но Microsoft предоставила рабочий шаблон, который является более надежным решением для долго работающих служб/демонов. Далее давайте перейдем к использованию рабочего шаблона.

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

Убедитесь, что рабочая роль работает, используя команду dotnet run .
Если приложение работает, опубликуйте его где-нибудь логически, например, /srv/WorkerApp:

Давайте проверим, что мы также можем запустить опубликованное приложение:

Создайте файл конфигурации сервисного модуля с именем "WorkerApp.service" внутри нашего проекта:

Скопируйте файл конфигурации службы в /etc/systemd/system/WorkerApp.service и скажите systemd перезагрузить файлы конфигурации:

Используя journalctl, мы можем убедиться, что приложение работает успешно. Следующая команда journalctl последует за выводом приложения. Используйте Ctrl-C, чтобы выйти из команды.

С помощью интерфейса командной строки dotnet добавьте пакет Microsoft.Extensions.Hosting.Systemd ( nuget ):

Наконец, нам нужно обновить файл конфигурации нашего сервисного модуля, указав 'type=Notify':

Давайте опубликуем, перезагрузим и перезапустим сервис:

Благодаря интеграции с Systemd мы теперь можем использовать флаг приоритета (-p) в параметре journalctl для фильтрации вывода в соответствии с уровнями журнала, указанными ниже:

< td style="height: 18px;">Уровень системного журнала

LogLevel	имя systemd
Трассировка/Отладка	7	отладка
Информация	6	информация
Предупреждение	4	предупреждение
Ошибка	3	ошибка
Критический	2	критический

Например, следующая команда будет печатать выходные данные только с уровнем журнала 4 и ниже:

Мы не увидим многого, потому что ничего не зарегистрировано как предупреждение, ошибка или критическая ситуация.
Обновите файл «WorkerApp.cs», включив в него «LogWarning», «LogError», «LogCritical», и опубликуйте его повторно. :

Повторно опубликуйте и перезапустите службу:

Когда мы запускаем ту же команду journalctl, теперь мы можем видеть выходные данные предупреждения в виде полужирного белого текста, а ошибки и критические выходные данные — в виде красного полужирного текста.

Функция 'UseSystemd' ничего не делает, если выполняется вне службы systemd.
Реализация проверяет, является ли ОС системой Unix и является ли родительский процесс systemd.
Если нет, интеграция systemd пропущена.

Чтобы узнать, как запускать службы .NET Core (не связанные с Интернетом) в Linux, ознакомьтесь со статьей "Как запустить .NET Core как службу с помощью Systemd в Linux"

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

Если приложение работает, вернитесь к первой оболочке и остановите приложение, нажав `ctrl + c`.
Теперь опубликуйте проект в каком-нибудь логичном месте, например /srv/AspNetSite. :

Опубликованный результат содержит исполняемый файл с именем AspNetSite, который будет запускать приложение. Давайте проверим, что мы также можем запустить опубликованное приложение:

Для запуска служб в Linux Systemd использует файлы «конфигурации служебных модулей», чтобы описать, как запускать службы. Давайте создадим файл AspNetSite.service внутри нашего проекта, чтобы мы могли сохранить его в системе управления версиями вместе с нашим кодом. Добавьте следующее содержимое в AspNetSite.service:

Обязательно обновите поле «Пользователь» до своего имени пользователя. Обратитесь к комментариям за объяснением указанных опций. Для получения дополнительной информации о файле конфигурации модуля обслуживания прочитайте страницу руководства freedesktop или документацию Red Hat.

Systemd ожидает, что все файлы конфигурации будут помещены в папку /etc/systemd/system/. Скопируйте файл конфигурации службы в /etc/systemd/system/AspNetSite.service и скажите systemd перезагрузить файлы конфигурации.

Теперь systemd знает о новой службе AspNetSite. Используя `systemctl start AspNetSite`, мы можем запустить службу.
Используя `systemctl status AspNetSite`, мы можем запросить статус службы. Запустим сервис и проверим его статус:

Из-за параметра Restart=always systemd перезапустит наш сервис в случае сбоя. Но он не запустит службу автоматически при перезагрузке машины. Чтобы включить автоматический запуск, используйте следующую команду:

Если все работает правильно, мы сможем свернуть приложение через localhost:5000:

Веб-сайт теперь работает как служба systemd. Существует пакет systemd, предоставленный Microsoft для улучшения интеграции с systemd. Давайте настроим это дальше.

Microsoft недавно добавила пакет для лучшей интеграции с systemd. Когда интеграция будет установлена, приложение уведомит systemd, когда оно будет готово и когда оно остановится. Кроме того, systemd понимает различные уровни журналов, которые регистрирует приложение.

С помощью интерфейса командной строки dotnet добавьте пакет Microsoft.Extensions.Hosting.Systemd (nuget):

Для демонстрации интеграции ведения журналов обновите файл Program.cs, добавив следующий код:

Наконец, нам нужно обновить файл AspNetSite.service, указав 'type=Notify':

Журналы приложений перехватываются systemd. Мы можем запросить журналы, используя journalctl, вот несколько примеров:

< td>информация

LogLevel	Уровень системного журнала	имя systemd
Трассировка/Отладка	7	отладка
Информация	6
Предупреждение	4	предупреждение
Ошибка< /td>	3	ошибка
Критический	2	крит

Например, следующая команда будет печатать выходные данные только с уровнем журнала 4 и ниже, что означает предупреждение, ошибку и критическое состояние:

Команда journalctl теперь должна возвращать различные операторы журнала, которые мы написали 3 раза.

Функция 'UseSystemd' ничего не делает, если выполняется вне службы systemd. Реализация проверяет, является ли ОС системой Unix и является ли родительский процесс systemd.
Если нет, интеграция systemd пропускается.

Теперь наша системная интеграция готова, но приложение по-прежнему недоступно за пределами машины. Давайте сделаем приложение доступным извне.

Как показано ниже, приложение доступно только через локальный хост на машине, а не через IP-адрес машины.

Вместо указания локального хоста или IP-адреса звездочка (*) будет действовать как подстановочный знак. Теперь приложение будет прослушивать локальный хост и все IP-адреса, назначенные машине.

Давайте скопируем обновленный файл конфигурации и перезагрузим/перезапустим службу systemd:

Означает ли это, что веб-сайт теперь доступен снаружи компьютера?
Почти Red Hat поставляется со встроенным брандмауэром, который блокирует трафик. Используя утилиту firewall-cmd, мы можем обновить конфигурацию брандмауэра, чтобы разрешить TCP-трафик через порты 5000 и 5001:

Теперь веб-сайт будет доступен с других компьютеров в сети.
Если вы используете этот компьютер RHEL в облаке, вам также необходимо убедиться, что безопасность, обеспечиваемая облаком, также разрешает TCP через порты 5000 и 5001.
После этого веб-сайт должен быть доступным в Интернете.

По умолчанию машины Linux не разрешают процессам использовать общеизвестные порты (порты ниже 1024).
Если мы попытаемся запустить приложение, используя порт 80 и/или 443, мы получим разрешение ошибка:

Есть много способов обойти это ограничение.

Это отличный вариант по многим причинам, но мы не будем этого делать, так как наша цель в этом пошаговом руководстве — использовать исключительно встроенный сервер Kestrel.

С помощью следующей команды мы можем предоставить исполняемому файлу AspNetSite возможность CAP_NET_BIND_SERVICE. Эта возможность позволит процессу привязываться к хорошо известным портам.

Каждый раз при обновлении исполняемого файла возможность CAP_NET_BIND_SERVICE будет потеряна. Мы могли бы сделать эту команду как часть сценария развертывания, но в файлах конфигурации сервисного модуля systemd есть параметр AmbientCapabilities.
При настройке этого параметра на «CAP_NET_BIND_SERVICE» systemd предоставит возможность службе для нас. . Давайте обновим файл AspNetSite.service, чтобы обновить порты и добавить возможность привязки к хорошо известным портам.

В последний раз скопируйте файл AspNetSite.service и перезагрузите/перезапустите службу AspNetSite.

Теперь веб-приложение прослушивает порты 80 и 443, но встроенный брандмауэр по-прежнему будет блокировать входящий трафик через эти порты. Обновите встроенный брандмауэр и любые другие сетевые средства безопасности, чтобы разрешить трафик через порты 80 и 443:

Посещение веб-сайта через порт 80 с помощью браузера теперь должно возвращать "Hello World!".

Читайте также: