- Publishing and running your ASP.NET Core project on Linux
- Setting up a Linux host
- Configuring Apache as a reverse proxy
- Publishing from Visual Studio Code
- Общие сведения о публикации приложений .NET
- Создание исполняемого файла
- Создание кроссплатформенного двоичного файла
- Публикация зависящих от среды приложений
- Преимущества
- Недостатки
- Примеры
- Публикация автономных приложений
- Преимущества
- Недостатки
- Примеры
- Публикация с использованием образов ReadyToRun
- Преимущества
- Недостатки
- Примеры
Publishing and running your ASP.NET Core project on Linux
Given that .NET Core, as a runtime, is a both open source and multiplatform it’s easy to understand the desire to run your ASP.NET Core project on a Linux host. Practically always you can find a Linux webhost cheaper than a Windows webserver. So .NET Core gives us developers the opportunity to build a web application in the language with probably the widest reach (yes, that’s C#) and host that on virtually any server platform.
For the purpose of this article, we are creating a ASP.NET Core website with Visual Studio Code, setting up a Linux host with Apache webserver, and deploying the site with Deploy, a VS Code Extension for deploying files in a workspace to a multitude of destinations.
Setting up a Linux host
There are many service providing offering a cheap Linux based VPS (virtual private server). Amazon offers a free tier, where you can run a single core, 1GB RAM instance for up to 12 months for free. After that, it’s about 9 USD/month. The instance we select is an Ubuntu Server 16.04 LTS (HVM) with 8GB of storage (SSD). Note that we connect to this instance through SSH, and the AWS console allows you to create a public/private key pair to connect securely to the instance. On a Windows machine, you can use mRemoteNG to connect to a Linux machine. However, connecting to Linux instances that run on AWS requires a bit more than just SSH client. Linux EC2 instances have password authentication disabled by default to prevent brute-force attacks and want you to supply your private key instead. But there is no such field in mRemoteNG configuration pane! Here is a detailed instruction on setting up your connection using mRemoteNG.
To install .NET Core on linux, we are using the same steps as described in this article.
We can install .NET Core using Ubuntu’s package manager, apt. The instruction can be found here, but make sure you are using the commands for Ubuntu 16.04 / Linux Mint 18.
We use the following command to list the available releases of .NET Core.
At the time of writing the last entry in the list is this one.
We can install it using this command.
Since we are using a sudo command, these operations get executed with root privileges. It will ask you for your regular user’s password to verify your intentions.
Configuring Apache as a reverse proxy
Kestrel is the web server that is included by default in ASP.NET Core new project templates. It is a cross-platform web server for ASP.NET Core based on libuv, a cross-platform asynchronous I/O library. If your application accepts requests only from an internal network, you can use Kestrel by itself.
However, if you expose your application to the Internet, you must use IIS, Nginx, or Apache as a reverse proxy server. A reverse proxy server receives HTTP requests from the Internet and forwards them to Kestrel after some preliminary handling.
In our example, we are going to setup and configure Apache to handle the requests and forward them to Kestrel.
To install Apache on Ubuntu, use the following command.
By default, your AWS instance has a network security setting to prohibit inbound traffic on port 80. You need to configure the security group in AWS. To do this, navigate to your instance in the AWS console, scroll to the right and click on the name of the security group. This way, you are sure to edit the security group for the instance, and not some other security group.
On the inbound tab, click Edit.
You can now add a rule for HTTP traffic. This will actually create two rules, one for IPv4 and one for IPv6.
If you now navigate to the IP address of your host, you should see the default Apache page.
Now, we need enable the modproxy modules to in Apache server to make it work as a reverse proxy. modproxy is the Apache module for redirecting connections (i.e. a gateway, passing them through). It is enabled for use just like any other module and configuration is pretty basic (or standard), in line with others. modproxy is not just a single module but a collection of them, with each bringing a new set of functionality. You enable the modules with this command.
Configuration files for Apache are located within the /etc/apache2/conf-enabled/ directory. Any file with the .conf extension will be processed in alphabetical order in addition to the module configuration files in /etc/apache2/mods-enabled/, which contains any configuration files necessary to load modules.
To create a configuration file, use the following command
This is content of the the configuration file.
The VirtualHost node, of which there can be multiple in a file or on a server in many files, is set to listen on any IP address using port 80. The next two lines are set to pass all requests received at the root to the machine 127.0.0.1 port 5000 and in reverse. For there to be bi-directional communication, both settings ProxyPass and ProxyPassReverse are required.
Logging can be configured per VirtualHost using ErrorLog and CustomLog directives. ErrorLog is the location where the server will log errors and CustomLog sets the filename and format of log file. In our case this is where request information will be logged. There will be one line for each request.
Press CTRL-X and Y to save and exit the editor.
Now restart Apache using this command.
If you want to check logging on the startup sequence, type the following command.
Apache is now configured to forward requests made to http://localhost:80 on to the ASP.NET Core application running on Kestrel at http://127.0.0.1:5000. If you want to try it out, and see that it is working, we first need to have a ASP.NET Core website. There are several options here. You can deploy one from your local machine, if you have one available. Or you can create a basic website with the dotnet new command. Since we will deploying a locally developed site later in this article, and we want to know if our configuration is ready to accept and run that site, we are going forward with a boilerplate website. First, make sure that you are still in your home folder. You can always navigate to your home folder with the command cd
. In this folder, we are creating a site using the following commands.
When the last command is finished, you will have a basic MVC website. We are not going to run this website from your home folder, but rather deploy it to a subfolder of /var. This is not a requirement, but more of a convention. Ubuntu uses the folder /var/www/html as the default root for Apache. Publishing the MVC website is done like this.
While, Apache is not set up to manage the Kestrel process. We will use systemd and create a service file to start and monitor the underlying web app. systemd is an init system that provides many powerful features for starting, stopping and managing processes.
We can create a configuration file using the following command
The content of the .sevice file is as follows.
The various locations configured in this file obviously matter, and if the site fails to run, it’s very likely related to these settings. It seems that the location of the dotnet command differs between Linux-distributions, so use the whereis dotnet command to find out where it is on your machine.
If you completed the configuration and save the .service file, you need to enable it, and start it.
If all went well, you should be able to navigate to the IP address of your host and see the default start page of an ASP.NET Core MVC project.
Publishing from Visual Studio Code
There are many options for publishing your locally developed web application to a webserver. While professional development teams rely on continuous deployment tools like Octopus Deploy, Electric Flow, or Jenkins it’s still valid to simply deploy an application from your own machine using (s)FTP or copy. Deploy is an extension for Visual Studio Code that provides commands to deploy files of a workspace to a destination. Install this extension in VS Code by pressing CTRL-Shift-P and the Extensions: Install Extensions command. Since we have set up our webserver to run ASP.NET Core 2.0 Preview, it makes sense to create a .NET Core 2.0 project in Visual Studio Code. If you have not done so already, download and install the preview from https://www.microsoft.com/net/core/preview#windowscmd. This is assuming you are running VS Code on a Windows machine, but you can use Linux or MacOS as well.
Once installed, create a new ASP.NET MVC project through these commands in the terminal window of VS Code.
The deployment configuration is Workspace dependent (usually, since you probably have more than one project on your development machine). To create a workspace specific setting, press CTRL-, and go to the Workspace Settings tab. Here, you can enter the following deployment settings.
Since we are already using SSH to connect to our webserver at Amazon, it’s quite convenient to use SFTP (SSH FTP) for deployment. Make sure you know where your SSH private key file is located.
When you are ready to deploy, run the dotnet publish command first. Then, press CTRL-Shift-P and type Deploy:. Choose Deploy Workspace from the list of commands.
If all went well, you should see
Use a browser to navigate to your webhost, and you should see the site based on your local version.
It’s possible that the site is no longer running. This can be due to several issues:
You may have a .NET Core 2.0 Preview 2 version running locally, whereas the server still runs Preview 1. To update the version on the server, run these commands.
Источник
Общие сведения о публикации приложений .NET
Приложения .NET можно публиковать в двух разных режимах. Режим влияет на то, как пользователь запускает приложение.
При публикации автономного приложения в состав включается среда выполнения и библиотеки .NET, а также приложение и его зависимости. Пользователи приложения могут запустить его на компьютере, на котором не установлена среда выполнения .NET.
При публикации приложения в качестве зависимого от среды создается приложение, которое включает только само приложение и его зависимости. Пользователям приложения необходимо отдельно установить среду выполнения .NET.
Оба режима публикации по умолчанию создают исполняемый файл, зависящий от платформы. Приложения, зависящие от среды, могут создаваться без исполняемого файла, и эти приложения являются кросс-платформенными.
При создании исполняемого файла можно указать целевую платформу с идентификатором среды выполнения (RID). Дополнительные сведения об идентификаторах среды выполнения см. в этом каталоге для .NET.
В следующей таблице приведены команды, используемые для публикации автономных и зависящих от среды для каждой версии пакета SDK:
| Type | SDK 2.1 | SDK 3.1 | SDK 5.0 | Команда |
|---|---|---|---|---|
| зависящий от среды исполняемый файл для текущей платформы. | ✔️ | ✔️ | dotnet publish | |
| зависящий от среды исполняемый файл для определенной платформы. | ✔️ | ✔️ | dotnet publish -r —self-contained false | |
| зависящий от среды кросс-платформенный двоичный файл. | ✔️ | ✔️ | ✔️ | dotnet publish |
| автономный исполняемый файл. | ✔️ | ✔️ | ✔️ | dotnet publish -r |
Дополнительные сведения см. в статье о команде dotnet publish для .NET.
Создание исполняемого файла
Исполняемые файлы не являются кроссплатформенными. Они относятся к операционной системе и архитектуре ЦП. При публикации приложения и создании исполняемого файла можно опубликовать приложение как автономное или зависящее от среды. При публикации автономного приложения в пакет включается среда выполнения .NET, поэтому пользователям не нужно беспокоиться об установке .NET перед запуском приложения. Приложения, опубликованные как зависимые от среды, не предусматривают среду выполнения и библиотеки .NET. В пакет входят только приложение и сторонние зависимости.
Следующие команды создают исполняемый файл:
| Type | SDK 2.1 | SDK 3.1 | SDK 5.0 | Команда |
|---|---|---|---|---|
| зависящий от среды исполняемый файл для текущей платформы. | ✔️ | ✔️ | dotnet publish | |
| зависящий от среды исполняемый файл для определенной платформы. | ✔️ | ✔️ | dotnet publish -r —self-contained false | |
| автономный исполняемый файл. | ✔️ | ✔️ | ✔️ | dotnet publish -r |
Создание кроссплатформенного двоичного файла
Кросс-платформенные двоичные файлы создаются при публикации приложения, зависящего от среды, в виде файла DLL. Файл DLL называется по имени вашего проекта. Например, если ваше приложение называется word_reader, создается файл с именем word_reader.dll. Приложения, опубликованные таким образом, выполняются с помощью команды dotnet на любой платформе.
Кроссплатформенные двоичные файлы могут работать в любой операционной системе, если целевая среда выполнения .NET уже установлена. Если же она не установлена, приложение может использовать для работы более новую среду выполнения, если настроено соответствующим образом. Дополнительные сведения см. в разделе Накат зависящих от среды приложений.
Следующая команда создает кроссплатформенный двоичный файл:
| Type | SDK 2.1 | SDK 3.x | SDK 5.0 | Команда |
|---|---|---|---|---|
| зависящий от среды кросс-платформенный двоичный файл. | ✔️ | ✔️ | ✔️ | dotnet publish |
Публикация зависящих от среды приложений
Приложения, опубликованные как зависящие от среды, являются кроссплатформенными и не включают среду выполнения .NET. Пользователю нужно будет установить среду выполнения .NET.
При публикации приложения, зависящего от среды, создается кросс-платформенный двоичный файл с расширением DLL и исполняемый файл, зависящий от платформы, предназначенный для текущей платформы. Файл DLL является кроссплатформенным, а исполняемый файл — нет. Например, при публикации приложения с именем word_reader для Windows создается исполняемый файл word_reader.exe и файл word_reader.dll. Для Linux или macOS создается исполняемый файл word_reader, а также word_reader.dll. Дополнительные сведения об идентификаторах среды выполнения см. в этом каталоге для .NET.
Пакет SDK для .NET 2.1 не создает исполняемые файлы, зависящие от платформы, при публикации приложения, зависящего от среды.
Кроссплатформенный двоичный файл приложения можно запустить с помощью команды dotnet и выполнять на любой платформе. Если приложение использует пакет NuGet с реализациями, зависящими от платформы, все зависимости платформ копируются в папку публикации вместе с приложением.
Вы можете создать исполняемый файл для конкретной платформы, передав параметры -r —self-contained false в команде dotnet publish . Если параметр -r опущен, для текущей платформы создается исполняемый файл. Все пакеты NuGet, имеющие зависящие от платформы зависимости для целевой платформы, копируются в папку публикации. Если вам не нужен связанный с платформой исполняемый файл, можно указать False в файле проекта. Дополнительные сведения см. в статье Справочник по MSBuild для проектов пакета SDK для .NET.
Преимущества
Небольшое развертывание
Распределяются только приложение и его зависимости. Среду выполнения и библиотеки .NET устанавливает пользователь, и все приложения совместно используют среду выполнения.
Кроссплатформенные приложения
Ваше приложение и библиотеки на основе .NET работают в других операционных системах. Для приложения не нужно определять целевую платформу. Дополнительные сведения о формате файлов .NET см. в разделе Формат файла сборки .NET.
Использует последнюю исправленную версию среды выполнения
Приложение использует самую новую среду выполнения (в рамках целевого основного и дополнительного семейства .NET), установленную в целевой системе. Это означает, что приложение будет автоматически использовать последнюю исправленную версию среды выполнения .NET. Поведение по умолчанию можно переопределить. Дополнительные сведения см. в разделе Накат зависящих от среды приложений.
Недостатки
Требует предварительной установки среды выполнения
Приложение может выполняться, только если в системе, в которой оно размещено, уже установлена целевая версия .NET. Вы можете настроить поведение наката для приложения, чтобы либо требовать определенную версию .NET, либо разрешить более новую версию. Дополнительные сведения см. в разделе Накат зависящих от среды приложений.
.NET может измениться
Среду выполнения и библиотеки .NET можно обновлять на компьютере, где выполняется приложение. В редких случаях это может изменить поведение приложения, если используются библиотеки .NET, что характерно для большинства приложений. Вы можете настроить, как приложение будет использовать более новые версии .NET. Дополнительные сведения см. в разделе Накат зависящих от среды приложений.
Приведенные ниже недостатки применимы только к пакету SDK для .NET Core 2.1.
- Используйте команду dotnet , чтобы запустить приложение
Для запуска приложения пользователи должны выполнить команду dotnet . Пакет SDK для .NET Core 2.1 не создает исполняемые файлы, зависящие от платформы, при публикации приложения, зависящего от среды.
Примеры
Публикация кросс-платформенного приложения, зависящего от среды. Исполняемый файл, предназначенный для текущей платформы, создается вместе с DLL-файлом.
Публикация кросс-платформенного приложения, зависящего от среды. Вместе с DLL-файлом создается 64-разрядный исполняемый файл Linux. Эта команда не работает с пакетом SDK для .NET Core 2.1.
Публикация автономных приложений
При публикации автономного приложения создается исполняемый файл, зависящий от платформы. Выходная папка публикации содержит все компоненты приложения, в том числе библиотеки .NET и целевую среду выполнения. Приложение изолировано от других приложений .NET и не использует локально установленную общую среду выполнения. Пользователю приложения не требуется скачивать и устанавливать .NET.
Исполняемый двоичный файл создается для указанной целевой платформы. Например, если у вас есть приложение с именем word_reader и вы публикуете автономный исполняемый файл для Windows, создается файл word_reader.exe. При публикации для Linux или macOS создается файл word_reader. Целевая платформа и архитектура указываются с помощью параметра -r для команды dotnet publish . Дополнительные сведения об идентификаторах среды выполнения см. в этом каталоге для .NET.
Если приложение имеет зависимости для определенной платформы, например пакет NuGet, содержащий зависимости для определенной платформы, они копируются в папку публикации вместе с приложением.
Преимущества
Управление версией .NET
Вы управляете тем, какая версия .NET развертывается вместе с приложением.
Нацеливание на конкретные платформы
Поскольку необходимо опубликовать приложение для каждой платформы, вы знаете, где будет выполняться приложение. Если в .NET появляется новая платформа, пользователи не смогут запустить приложение на ней до выпуска версии, предназначенной для этой платформы. Вы можете протестировать приложение на наличие проблем совместимости перед тем, как пользователи запустят приложение на новой платформе.
Недостатки
Более крупные развертывания
Так как приложение включает среду выполнения .NET и все зависимости приложения, размер скачиваемого файла и требуемого пространства на жестком диске будет больше, чем для версии, зависящей от среды.
Вы можете уменьшить размер развертывания в системах Linux примерно на 28 МБ с помощью инвариантного режима глобализации .NET. С его помощью приложение будет обрабатывать все языки и региональные параметры как инвариантные языки и региональные параметры.
Существует предварительная версия функция усечения позволяющая еще больше уменьшить размер развертывания.
Усложненное обновление версии .NET
Среду выполнения .NET (распространяемую с вашим приложением) можно обновить только путем выпуска новой версии приложения. Но при необходимости.NET обновит критически важные обновления системы безопасности для библиотеки платформы на компьютере, на котором выполняется приложение. Ответственность за полную проверку этого сценария обновления системы безопасности лежит на вас.
Примеры
Публикация автономного приложения. Создается 64-разрядный исполняемый файл macOS.
Публикация автономного приложения. Создается 64-разрядный исполняемый файл Windows.
Публикация с использованием образов ReadyToRun
Публикация с использованием образов ReadyToRun помогает оптимизировать время запуска приложения, хотя размер приложения при этом будет увеличен. Дополнительные сведения о публикации с использованием ReadyToRun см. здесь.
Преимущества
- Оптимизированное времени запуска
Приложение будет тратить меньше времени на выполнение JIT.
Недостатки
- Больший размер
Приложение будет занимать больше места на диске.
Примеры
Опубликуйте автономное приложение с помощью ReadyToRun. Создается 64-разрядный исполняемый файл macOS.
Опубликуйте автономное приложение с помощью ReadyToRun. Создается 64-разрядный исполняемый файл Windows.
Источник
