Vasjen 25 апр в 18:21

Деплой .NET приложений для самых маленьких. Часть 0

Средний

11 мин

9.8K

.NET*C#*DevOps*

Туториал

+26

Комментарии 31

ColdPhoenix 25 апр в 19:09

их основное преимущество – автоматизация развертывания ваших приложений после изменения кода, которое можно настроить путем использования различных инструментов, таких как Jenkins в более сложных задачах, или средствами Github / Gitlab в более простых случаях. Опять же, если интересно подробнее – гуглим CI/CD и все, что с ним связано.

А на VPS нельзя?

ИМХО странно писать про nginx и доступ извне когда приложение будет работать пока есть ssh-сессия.

Vasjen 25 апр в 19:14

А на VPS нельзя?

Я неправильно сформулировал мысль, спасибо что указали – подправлю. Имелось ввиду, что именно на VPS с помощью Jenkins и других инструментов можно сделать тоже самое.

ИМХО странно писать про nginx и доступ извне когда приложение будет работать пока есть ssh-сессия.

В следующей частей мы все это дело уже запустим нормально в контейнере и оно будет крутиться 24/7, как и полагается. И доступ из вне лишним не будет.

nronnie 25 апр в 19:17

К сожалению, по умолчанию извне наше приложение не будет доступно.

У вас оно доступно, только на порту 5555 (судя по скриншоту). Вообще, если у вас отдельный VPS, то не лучше ли уж сразу поставить туда докер и развертывать приложение в докере - несколько лишних движений в начале, зато потом постоянное упрощение жизни. Зачем вы копируете на сервер весь проект, потом еще водружаете туда SDK и на месте его собираете? Чтобы его заранее собрать и "выбрать" из него только то что надо для запуска есть специальная команда dotnet publish.

Vasjen 25 апр в 20:10

У вас оно доступно, только на порту 5555 (судя по скриншоту).

На 5555 порту висит другое приложение на этом же VPS. То, которое мы делаем в рамках примера запускается на 5144, что и отражено в логах.

Вообще, если у вас отдельный VPS, то не лучше ли уж сразу поставить туда докер и развертывать приложение в докере - несколько лишних движений в начале, зато потом постоянное упрощение жизни.

Из реальных практических соображений – конечно лучше. Но данную статью составлял для начинающих и не хотел переусложнять такими вещами, как докер, хотя он и правда простой и является чуть ли не стандартом развертывания приложений. Но для полноты картины дополнил этим статью, спасибо Вам за указание на это.

Зачем вы копируете на сервер весь проект, потом еще водружаете туда SDK и на месте его собираете?

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

nronnie 25 апр в 20:55

Опять же, для демонстрации, что так можно.

Устанавливать средства разработки на (по сути боевой) сервер? Так нельзя.

nronnie 25 апр в 21:11

То, которое мы делаем в рамках примера запускается на 5144, что и отражено в логах.

Ну так настройте просто launchSettings.json чтобы оно у вас слушало не только localhost, а либо все адреса, либо те которые доступны "снаружи". Либо в appsettings.json в разделе Kestrel это пропишите.

Free_ze 25 апр в 23:50

Далее идет работа с Git, что уже является правильным и нормальным вариантом.

А как между собой связаны dotnet run и Git? И в статье, и в комментарии указываете на некую взаимосвязь между ними.

mvv-rus 27 апр в 02:59

не лучше ли уж сразу поставить туда докер

А там докер точно нужен? Основная функция докера, AFAIK - изоляция разных приложений чтобы не было конфликта между их зависимостями. А тут мы имеем сервер ровно для одного приложения. Что от чего изолировать? Или я что-то в докере не понимаю?

nronnie 27 апр в 04:08

Основная функция докера, AFAIK - изоляция разных приложений

Это да. Но докер сильно упрощает также установку, развертывание и управление софтом. У меня сейчас на десктопе в докере стоят для работы: MSSQL, Postgres, Pgadmin4, Mongo DB, Redis, RabbitMQ, Smtp4Dev (по-моему ничего не забыл). Все в любой момент очень легко парой команд удалить, переставить, заменить на другую версию (или поставить другую версию параллельно). Все прописано в общий файл compose.yaml, который лежит в гите - если надо, то вся конфигурация одним движением восстанавливается или переносится на другую машину. Я ко всем этим удобствам настолько привык, что ставить и поддерживать все это прямо в самой (хостовой) операционке - я такое себе уже даже и не представляю.

kozlov_de 25 апр в 20:29

.net проект имеет некоторые проблемы сборки под докер

с локальными (не с сайта) nuget packages - не помню как решать
с typescript - нужно включать node и npm в докер

Сборка под докер это тоже публикация исходников и сборка в среде Linux, в самом докере. Почему не собирать npm в Винде не знаю.

Зато разработка и тестирование в windows + visual studio одно удовольствие. Linux как страшный сон

-3

nronnie 26 апр в 02:45

с локальными (не с сайта) nuget packages - не помню как решать

Точно так же как решается локально - копировать пакеты внутрь контейнера и конфигурировать Nuget (тоже внутри контейнера). Первое - инструкция CP в Dockerfile, второе - инструкция RUN dotnet nuget add source ... там же. Node/npm точно так же ставится через RUN apt install .... А в крайнем .NET SDK появилась возможность собирать образы совсем без Dockerfile, когда при сборке отдельный контейнер для неё не используется вообще, вот, совсем недавняя статья про это: https://devblogs.microsoft.com/dotnet/streamline-container-build-dotnet-8/

Drazd 25 апр в 20:58

Чтобы наше приложение было доступно извне по доменному имени или IP адресу, нужно использовать обратный прокси.

На самом деле уже нет. Могу путать версию, но толи с 6, толи с 7 версии ASP.NET появилась возможность настраивать HTTPS протокол с сертификатом непосредственно в Kestrel (через appsetting.json). Пример такой настройки:

"Kestrel": {
	"Endpoints": {
		"Http": {
			"Url": "http://0.0.0.0:80"
		},
		"Https": {
			"Url": "https://0.0.0.0:443"
		}
	},
	"Certificates": {
		"Default": {
			"Path": "cert.pem",
			"KeyPath": "cert.key"
		}
	}
}

Но, конечно, Kestrel не дает всего разнообразия настроек веб-серверов как Apache2/httpd и Nginx, тем не менее, для стартовых небольших проектов вполне себе рабочая история

Kano 25 апр в 21:05

Kestrel предназначен для внутреннего использования. Для внешки надо смотреть на специализированные средства, например nginx

nronnie 25 апр в 21:13

В данном случае вполне и Kestrel пойдет.

ColdPhoenix 26 апр в 12:04

Уже нет, MS считает Kestrel довольно самостоятельным. см YARP.

nginx более полезен когда нужно несколько приложений на одной VPS.

nronnie 27 апр в 04:17

Nginx вообще для этих целей устарел. Есть ведь, например, "Envoy", "Krakend", или "Ocelot", т.е. более специализированные решения, в отличии от Nginx, который просто веб-сервер общего назначения.

Откуда пошла установка, что с ASP.NET обязательно использовать Nginx (или другой) реверс-прокси это вообще непонятно, потому что в конечном итоге этот реверс-прокси все равно тот самый Kestrel и вызывает - если он при этом не делает ничего типа балансировки, кеширования, переписывания URL, или чего-нибудь подобного, а просто прокидывает запросы "как есть", то какая тогда разница.

gogolevsergey 30 апр в 13:28

Разница в том как запросы обрабатывает сервер, в kestrel постоянно находят уязвимости, можно подготовить такой запрос который вернёт лишние данные из буфера или просто положит приложение. В этом плане nginx прошел больший путь и большинство уязвимостей получено.

Shvedov 9 мая в 01:33

И как nginx защитит от этого? И ничего, что kestrel быстрее nginx?

swingaroo 7 мая в 18:02

Во времена первых версий Core майки специально оговаривали, что Kestrel нельзя пускать сразу в сеть, только через обратный прокси. Хорошо запомнилось.

Breathe_the_pressure 25 апр в 22:01

А почему нет хостингов для .NET? Если в поисковике набрать "Windows хостинг", неужели ничего не выпадает?

UranusExplorer 25 апр в 23:34

.net уже давно не windows-only, можно и с Linux :)

shai_hulud 25 апр в 23:38

тем более что там даже Windows не надо, .NET [Core] можно хостить хоть под линуксом, хоть под макОС.

nronnie 27 апр в 04:21

Да есть (по крайней мере были) даже и просто "shared" хостинги для ASP.NET - я такие видел, точно. Насколько они сейчас актуальны, когда кругом облака с хостингом контейнеров или VPS - этого я в душе не знаю.

sekoles 25 апр в 23:12

А зачем тащить весь dotnet sdk, ведь наверняка можно только что-то из runtime установить?

nronnie 26 апр в 00:23

.NET SDK автору нужен, чтобы проект прямо на сервере зачем-то собирать.

Vitimbo 26 апр в 13:10

CICD, когда у тебя один сервер на всё

nronnie 26 апр в 14:49

Если проект на GitHub, то есть готовые "GitHub Actions". Можно прямо там сразу же собирать docker-образ, там же его размещать в их registry и на хостинге прямо оттуда в docker-е запускать. У GitLab и "Azure DevOps Services" все это тоже есть.