Настройка asp net ubuntu

Обновлено: 02.07.2024

Для Ubuntu 14.04 в качестве решения для мониторинга процесса Kestrel рекомендуется использовать supervisord . Решение systemd в Ubuntu 14.04 недоступно. Инструкции для Ubuntu 14.04 см. в предыдущей версии этого раздела.

В этом руководстве рассматривается

Предварительные требования

Публикация и копирование приложения

Выполните команду dotnet publish в среде разработки, чтобы упаковать приложение в каталог (например, bin/Release//publish , где заполнитель является моникером целевой платформы или TFM), который может выполняться на сервере:

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

Проверьте работу приложения:

Настройка обратного прокси-сервера

Использование обратного прокси-сервера

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

Вызовите UseForwardedHeaders метод наверху Startup.Configure , прежде чем вызывать другое ПО промежуточного слоя. В ПО промежуточного слоя настройте перенаправление заголовков X-Forwarded-For и X-Forwarded-Proto :

Если параметр ForwardedHeadersOptions не задан для ПО промежуточного слоя, по умолчанию перенаправляются заголовки None .

Прокси-серверы под управлением адресов замыкания на себя ( 127.0.0.0/8 , [::1] ), включая стандартные адреса localhost ( 127.0.0.1 ), считаются доверенными по умолчанию. Если запросы между Интернетом и веб-сервером обрабатывают другие прокси-серверы или сети организации, добавьте их в список KnownProxies или KnownNetworks с помощью ForwardedHeadersOptions. Следующий пример добавляет доверенный прокси-сервер с IP-адресом 10.0.0.100 в ПО промежуточного слоя для перенаправления заголовков KnownProxies в Startup.ConfigureServices :

Установка Nginx

Установите Nginx с помощью команды apt-get . Программа установки создает сценарий инициализации systemd , который запускает Nginx как управляющую программу при запуске системы. Следуйте инструкциям по установке для Ubuntu в разделе Nginx: официальные пакеты Debian и Ubuntu.

Если необходимы дополнительные модули Nginx, может потребоваться создание Nginx из источника.

Так как Nginx устанавливается впервые, запустите его напрямую, выполнив следующую команду.

Настройка Nginx

Если отсутствуют совпадения для server_name , Nginx использует сервер по умолчанию. Если сервер по умолчанию не определен, первый сервер в файле конфигурации является сервером по умолчанию. Рекомендуется добавить в качестве сервера по умолчанию определенный сервер, который возвращает код состояния 444 в файле конфигурации. Ниже приведен пример конфигурации сервера по умолчанию:

Установив конфигурацию Nginx, выполните команду sudo nginx -t , чтобы проверить синтаксис файлов конфигурации. Если проверка файла конфигурации прошла успешно, заставьте Nginx принять изменения, выполнив команду sudo nginx -s reload .

Для непосредственного запуска приложений на сервере:

Перейдите в каталог приложения.
Запустите приложение: dotnet <app_assembly.dll> , где app_assembly.dll — имя файла сборки приложения.

Если приложение выполняется на сервере, но не отвечает по Интернету, проверьте брандмауэр сервера и убедитесь, что порт 80 открыт. При использовании виртуальной машины Ubuntu Azure добавьте правило группы безопасности сети (NSG), которое разрешает входящий трафик через порт 80. Не нужно включать правило исходящего трафика на порте 80, так как исходящий трафик предоставляется автоматически при включении правила для входящего трафика.

Когда закончите тестировать приложение, завершите его работу с помощью клавиш CTRL + C в командной строке.

Мониторинг приложения

Создание файла службы

Создайте файл определения службы.

Далее представлен пример файла службы для нашего приложения:

В предыдущем примере управляющий службой пользователь задается с помощью параметра User . Этот пользователь ( www-data ) должен существовать и иметь права владельца в отношении файлов приложения.

Используйте TimeoutStopSec , чтобы настроить время ожидания до завершения работы приложения после начального сигнала прерывания. Если приложение не завершит работу в течение этого периода, оно прерывается сигналом SIGKILL. Укажите значение в секундах без единиц измерения (например, 150 ), значение интервала (например, 2min 30s ) или значение infinity , которое отключает время ожидания. TimeoutStopSec по умолчанию использует значение DefaultTimeoutStopSec в файле конфигурации диспетчера ( systemd-system.conf , system.conf.d , systemd-user.conf , user.conf.d ). В большинстве дистрибутивов по умолчанию устанавливается время ожидания 90 секунд.

Linux имеет файловую систему, в которой учитывается регистр символов. Задание ASPNETCORE_ENVIRONMENT для Production приведет к поиску файла конфигурации appsettings.Production.json , а не appsettings.production.json .

Некоторые значения (например, строки подключения SQL) необходимо экранировать, чтобы поставщики конфигурации могли читать переменные среды. Используйте следующую команду, чтобы создать правильно экранированное значение для файла конфигурации:

Разделители-двоеточия ( : ) не поддерживаются в именах переменных среды. Следует использовать двойной знак подчеркивания ( __ ) вместо двоеточия. Поставщик конфигурации переменных среды преобразует двойные символы подчеркивания в двоеточия, когда переменные среды считываются в конфигурации. В следующем примере ключ строки подключения ConnectionStrings:DefaultConnection задается в файле определения службы как ConnectionStrings__DefaultConnection .

Сохраните файл и включите службу.

Запустите службу и убедитесь, что она работает.

Просмотр журналов

Так как веб-приложение, использующее Kestrel, управляется через systemd , все события и процессы регистрируются в централизованном журнале. При этом журнал содержит все записи обо всех службах и процессах, управляемых systemd . Чтобы просмотреть элементы, связанные с kestrel-helloapp.service , используйте следующую команду.

Кроме того, количество возвращаемых записей можно уменьшить, указав параметры времени, например --since today , --until 1 hour ago или их комбинацию.

Защита данных

Если набор ключей хранится в памяти, при перезапуске приложения происходит следующее:

Сведения о настройке защиты данных для хранения и шифрования набора ключей см. в приведенных ниже статьях.

Длинные поля заголовка запроса

Параметры прокси-сервера по умолчанию обычно ограничивают длину полей заголовка запроса значением 4 КБ или 8 КБ (в зависимости от платформы). Приложению могут потребоваться более длинные поля (например, приложениям, использующим Azure Active Directory). В этом случае требуется скорректировать параметры по умолчанию для прокси-сервера. Применяемые значения зависят от конкретного сценария. Дополнительные сведения см. в документации сервера.

Не увеличивайте значение буферов прокси-сервера по умолчанию, если это не требуется. Увеличение этих значений повышает риск переполнения буфера и атак типа "отказ в обслуживании" (DoS) со стороны злоумышленников.

Защита приложения

Включение AppArmor

Начиная с версии 2.6 ядро Linux включает платформу модулей безопасности Linux (LSM). LSM поддерживают различные реализации модулей безопасности. AppArmor — это LSM, который реализует систему обязательного контроля доступа, позволяющую ограничивать программу определенным набором ресурсов. Убедитесь, что AppArmor включен и правильно настроен.

Настройка брандмауэра

Закройте все внешние порты, которые не используются. Простой брандмауэр (ufw) позволяет взаимодействовать с iptables . Для настройки брандмауэра предоставляется CLI.

Неправильно настроенный брандмауэр предотвратит доступ ко всей системе. Если задать неправильный порт SSH, то при использовании SSH для подключения к системе произойдет ее блокировка. Порт по умолчанию — 22. Дополнительные сведения см. в вводной статье по ufw и в этом руководстве.

Установите ufw и настройте его для разрешения прохождения трафика через все необходимые порты.

Защита Nginx

Изменение имени ответа Nginx

Настройка параметров

Настройте дополнительные обязательные модули на сервере. Для дополнительной защиты приложения можно использовать межсетевой экран для веб-приложений, например ModSecurity.

Настройте приложение, чтобы оно использовало при разработке сертификат для команды dotnet run или среды разработки ( F5 или CTRL + F5 в Visual Studio Code), используя один из следующих подходов:

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

Обеспечьте дополнительную защиту, применив некоторые методы, показанные в представленном ниже файле /etc/nginx/nginx.conf.

Не добавляйте заголовок HSTS.
Выберите короткое значение max-age .

Добавьте файл конфигурации /etc/nginx/proxy.conf:

ssl_stapling
ssl_stapling_file
ssl_stapling_responder
ssl_stapling_verify

Защита Nginx от кликджекинга

Кликджекинг (или атака с подменой пользовательского интерфейса) является вредоносной атакой, при которой посетителя сайта обманным путем вынуждают щелкнуть ссылку или нажать кнопку не той страницы, на которой он находится. Используйте X-FRAME-OPTIONS для защиты сайта.

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

Измените файл nginx.conf.

Добавьте строку: add_header X-Frame-Options "SAMEORIGIN";

Сканирование типа MIME

В рамках данной статьи я буду использовать облачный сервис Azure Virtual Machines, но проблем с повторением ниже описанного «на земле» возникать не должно.

Где достать Azure бесплатно?

— Доступ ко всему ПО, которое когда-либо создавал MS + ключи активации. Например, клиентская Windows в MSDN начинается с версии 3.11 и заканчивается Windows 10 всех редакций. Та же история с Windows Server, SQL Server, SharePoint и прочее.

Ниже пример страничка выбора софта:

— Бесплатный Azure на сумму от $50 до $150;
— Бесплатный аккаунт для разработчика в Office365;
— Бесплатный доступ к курсам Plularsight;
— Бесплатный доступ для публикации приложений в Windows Store;
— Новые версии ПО в подписке появляются раньше, чем официальный релиз. Это сделано для того, чтоб разработчики могли адаптировать свои решения до официального выхода релиза.

Все ПО предоставляется для тестирования приложений, которые вы разрабатываете. Иными словами, MSDN — это целая экосистема для разработчика.

Так же вам понадобится Visual Studio 2015 любой редакции. На всякий случай — вот ссылка на бесплатную редакцию Visual Studio Community

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

Так, ну вроде предполетную подготовку мы сделали, теперь давайте публиковаться.

Публикация на Linux VM

Разворачиваем в Azure новую виртуалку под Ubuntu 15.04 (можно и Ubuntu 14.04). Виртуалку можно взять ExtraSmall, ее вполне достаточно для теста.

На портале Azure нажимаем «New»:

Далее COMPUTE -> VIRTUAL MACHINE -> FROM GALLERY:

Выбираем Ubuntu 15.04 и жмем кнопку «далее»:

На следующей странице:
— Задаем имя винтуалки в поле «Virtual machine name»;
— Tier выбираем Basic;
— Size выбираем A0 (shared core, 768 MB memory);
— New user name оставляем «azureuser»;
— Убираем галочку «Upload compatible SSH key for authentication»;
— Задаем пароль для нашего «azureuser» в поле «New password» и «Confirm» (эти параметры будут использоваться для доступа к машине через ssh);
— Жмем далее.

На след. странице:
— Меняем Region/Affinity group/Virtual network на «West Europe» (это ближайший к нам дата центр. Локация — Амстердам, Нидерланды);
— Жмем далее.

И тут жмем «done»:

Сейчас пошел процесс создания виртуалки. После ее создания качаем ssh клиент (я использую Putty) и коннектимся к нашей виртуалке. Хост или IP виртуалки можно взять на портале Azure, в разделе «Dashboard». Логин и пароль мы задавали при создании VM.

После соединения первое, что нам нужно сделать, это заменить файл Sources.list. Это делается только на виртуалках, поднятых в Azure. В файле Sources.list прописывается список URL к репозиториям, откуда Ubuntu качает обновления или дополнительные модули.

Зачем нужно менять? Sources.list в Azure смотрит на какие-то Azure-овые репозитории, в которых нет половины модулей, которые нам нужны.

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

Далее, обновляем apt-get (утилита для установки дополнительных модулей и обновлений Ubuntu) командой «sudo apt-get update», дабы подтянулся новый Sources.list:

Устанавливаем unzip командой «sudo apt-get install unzip»:

Далее необходимо поставить DNX. Но перед этим нужно доустановить компоненты, которые он использует. Для этого выполняем «sudo apt-get install libunwind8 gettext libssl-dev libcurl3-dev zlib1g» (На вопрос «Do you want to continue? [Y/n]» вводим «Y»):

Ну и, собственно, сам DNX устанавливаем командой «dnvm upgrade -r coreclr»:

Приступим к установке компонентов для веб сервера Kestrel командой «sudo apt-get install make automake libtool curl» (На вопрос «Do you want to continue? [Y/n]» вводим «Y»):

Теперь нам необходимо как-то передать наши исходники вебсайта на Ubuntu сервер в облаке.

Для этих целей я предпочитаю клиент «WinSCP». Это файловый менеджер, который, в том числе, работает по протоколу SFTP. Коннектимся к нашей машине:

Теперь открываем наш созданный в предыдущей статье проект в Visual Studio и публикуем его в файл:

В итоге Project.json должен выглядеть так:

На Ubuntu сервере мы создадим нашу собственную директорию для вебсайта «DemoWEB».

Теперь берем WinSCP и заходим в папку «PublishOut\approot\src\[Имя вашего проекта]» в левой части приложения. В правой части экрана, на удаленном сервере, создаем новую директорию, например «DemoWEB»:

Ну и, собственно, заходим в новосозданную директорию и копируем файлы на сервер:

Возвращаемся в Putty и командой «cd ./DemoWEB/» переходим в директорию с нашим веб сайтом (посмотреть содержимое директории можно командой «ll»):

Далее, нам необходимо восстановить библиотеки нашего проекта, согласно файла «Project.json». Выполняем «dnu restore». Дожидаемся окончания восстановления и стартуем Kestrel командой «dnx web».

Важно: «web» я выделил не зря. Если кто внимательно читал предыдущую статью, то знает, что «web» — это указатель на команду, которую запустит DNX. Это один из параметров в Project.json:

Если у вас не так, то команда для запуска веб сервера соответственно будет: «dnx [Ваш вариант]». В общем случае успешный старт выглядит так:

Как видим, сервер стартовал по порту «5000». Для того, чтоб убедится, что наше веб приложение работает, необходимо на портале Azure зайти в панель управления виртуальной машины, перейти в раздел «Endpoints» и открыть порт 5000, а за одно и

В итоге настройка портов будет выглядеть так:

Собственно, если мы сейчас в браузере откроем наш веб сайт по порту 5000, мы его увидим:

Для того, чтобы наше веб приложение стало доступно по порту 80, необходимо поставить проксю (Linux злой и не разрешает не привилегированным пользователям цепляться к порту всякими сервисами, типа dnx:). Мы будем использовать nginx для этих целей, к установке которого мы сейчас и приступим:

Для профилактики запускаем «sudo apt-get update». Теперь, собственно, команда для установки nginx: «sudo apt-get install nginx -y».

Далее конфигурируем nginx для запуска при старте виртуалки командой «sudo update-rc.d nginx defaults».

После выполнения команды откроется редактирование:

Вставляем (вставка в Putty осуществляется кликом правой кнопкой мышки. Тут Ctrl+V для вставки не используется! Это же Linux :)

Для выхода из режима редактирования жмем ESC. Для сохранения изменений и выхода из редактора жмем ZZ (Shift + Z + Z).

Создаем кэш директорию для Nignx веб-сервера командами:
«sudo mkdir /var/cache/nginx»
«sudo chown www-data:www-data /var/cache/nginx»

Стартуем nginx командой: «sudo service nginx start» (команда для остановки: «sudo service nginx stop», для перезапуска: «sudo service nginx restart»).

Стартуем Kestrel командой: «dnx web».

Теперь вебсайт доступен по порту 80.

С этим разобрались. Как видите, всё очень просто и нет почти никакой ручной работы:).

Docker

Теперь приступим к Docker. Это еще один способ опубликовать приложение на Linux. Я не буду вдаваться в суть, что такое Docker, об этом достаточно написано на их сайте. Итак, для начала необходимо скачать Visual Studio 2015 Tools for Docker. После установки этого аддона у вас при публикации появится еще один способ «Docker Container»:

Выбираем его и в открывшемся окне нужно выбрать, на какой хост вы будете публиковать ваш сайт — на существующий или на новый. Я собираюсь сделать новый, а вы уж как знаете. Если новый, то это новая Azure VM с установленным Docker:

Сейчас Visual Studio поднимает новую виртуалку с Docker-ом. После того, как мы в Visual Studio увидели «Successfully deployed template. », нажимаем еще раз кнопку Publish, открывается уже другое окно:

Закрываем визард публикации и добавим наш Dockerfile в проект:

Еще раз нажимаем Publish, и, о чудо :), он тут:

Жмем Publish и дожидаемся окончания публикации. Это займет минут 10, при этом в output консоли творится реально какой-то ад. Microsoft долго шел к красивым прогресбарам, и тут на тебе, опять куча текста:) Но это всё Linux виноват:)

После публикации Visual Studio попробует открыть вебсайт в браузере, который пошлет вас на все 404 стороны (пробовал все варианты: и порты переставлять, и разные Dockerfile, и давал Visual Studio самой сгенерить Dockerfile, никак).

Эхх. Опять все делать руками:(. Вообще полезно такие статьи готовить — этот процесс помогает познать то, с чем на самом деле сталкиваются разработчики.

Собственно, создаем новую Ubuntu виртуалку (рекомендую размер A1 или A2, так как от нехватки оперативной памяти A0 захлебывается), открываем на Azure портале порты: 80, 5000 (хотя последний мы использовать не будем) и обновляем Sources.list аналогично тому, как мы делали в начале статьи.

Раз уж мы руками будем все устанавливать, есть смысл сразу ставить последнюю версию Docker, посему мы будем сетапить все так, как указано на официальном сайте Docker.

Итак, добавляем новый GPG ключ командой «sudo apt-key adv —keyserver hkp://pgp.mit.edu:80 —recv-keys 58118E89F3A912897C070ADBF76221572C52609D»:

Нажимаем кнопку «Esc» для выхода из режима редактирования и «ZZ» (Shift + Z + Z) для сохранения изменений (рекомендую потренироваться с редактором vi, это полезный навык при работе с Linux).

В итоге файл выглядит так:

Обновляем apt-get командой «sudo apt-get update».

Убеждаемся, что apt-get сморит в правильный репозиторий командой «sudo apt-cache policy docker-engine»:

Устанавливаем Docker командой «sudo apt-get install docker-engine»:

Запускаем демон (на виндовом языке — служба) Docker командой «sudo service docker start».

Дабы убедится, что Docker работает, попробуем запустить стандартный HelloWorld командой «sudo docker run hello-world»:

Наш HelloWorld должен появится в списке Docker образов. Это можно проверить командой «sudo docker images»:

Давайте добавим нашего пользователя в группу Docker, дабы избавится от постоянного «sudo» в каждой команде «sudo usermod -aG docker azureuser»:

Теперь нужно перелогинится в терминале (закрыть и открыть Putty).

После этого зальем наш проект на сервер. Это можно сделать используя WinSCP, как мы делали ранее. Создаем директорию «DemoWEB», копируем в нее файлы нашего проекта.

COPY . /app
WORKDIR /app
RUN ["dnu", "restore"]

EXPOSE 5000
ENTRYPOINT ["dnx", "web"]

Результат будет выглядеть так:

Соответственно, копируем этот файл в нашу директорию «DemoWEB». Итог должен быть такой:

Возвращаемся в Putty, идем в нашу папку «DemoWEB» командой «cd ./DemoWEB». Запускаем сборку среды командой «docker build -t demo .» (demo — это название нашего образа. Можете свое указать). Точка в конце команды обязательна! Теперь можно минут 10 пойти погулять.

Нагулялись? Если вы в итоге увидели это:

Значит, процесс сборки закончился. Запускаем наш Docker image командой «docker run -t -d -p 80:5000 demo» (порт 5000 прописан в нашем Project.json, если кто забыл):

Заключение

В заключении хочу сказать, что готовить статью было не просто. Нужно было самому все проделать и убедиться, что все работает. Проблема в том, что куча примеров, которые опубликованы на разных источниках, может когда-то и работали, но теперь нет. Более того, мне, как человеку, привыкшему к Windows Server, ковыряться в Linux было вдвойне сложно. Зато я теперь умею пользоваться редактором vi, управлять процессами, работать с git, работать с файлами, да что там, nginx и docker поднимать! В общем, могу претендовать на начинающего админа Linux :)

Для особо интересующихся этой тематикой — попробуйте запустить контейнер «1.0.0-beta8» (мы сейчас запустили coreclr, но есть еще mono).

На всякий случай, вот ссылка на исходники, включая Dockerfile, которые я заливал на сервер.

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

Для начала, нам понадобятся такой софт:

Чтобы работать от имени Root пользователя, вводим команду:

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

Если вы вошли под root, тогда введите эти две команды, чтобы обновить систему и список доступных пакетов. Если же вы не хотите работать под root, тогда перед каждой командой вводите sudo и подтверждайте действие вводом пароля. Я же дальше буду работать с root правами.

Итак, для нормального доступа к нашему приложению из вне, нам потребуется установить и настроить NGIX сервер. Установка производится такими командами:

И приступаем к установке самого дотнета:

Чтобы убедиться, что все установилось, введите команду, которая покажет версию установленного SDK

Теперь проверим работу нашего NGIX. Для начала запустим сервис:

Теперь, если у вас настроен доступ в вашу сеть с виртуальной машины (смотри в инструкции установки сервера), вы можете на своей основной ОС запустить браузер и ввести в адресную строку IP вашего сервера:

Отлично! Все работает. Но теперь нужно настроить наш NGIX, чтобы он мог показывать наш будущий сайт. Для этого заходим в папку /etc/nginx/sites-available/

Команда ls покажет нам список всех файлов. Где мы видим один единственный файл default. Вот его содержимое без комментариев.

Открываем его на редактирование (вы можете предварительно удалить файл командой rm default, команда ниже создаст пустой файл с таким же именем ):

и заменяем такими значениями:

чтобы сохранить файл ctrl+x

Проверяем правильность синтаксиса конфигурационного файта командой:

И перезагружаем NGIX сервер:

СОЗДАЕМ ТЕСТОВЫЙ WEB ПРОЕКТ

Теперь попробуем создать наше тестовое приложение и запаблишить его.
Вводим команду:

Которая нас возвращает в каталог user. Где мы создадим папку для нашего проекта webapp и войдем в нее.

Теперь приступим к созданию приложения MVC. Для этого достаточно ввести команду создания, а затем просмотреть список файтов:

Вот как это выглядит:

Отлично, теперь запустим наше приложение, чтобы проверить его работу:

И сразу же проверяем, обратившись по IP к нашему серверу из браузера:

Супер! Все работает! Но, мы еще не запаблишили наш проект. Это тоже делается довольно легко.

ПУБЛИКАЦИЯ ПРОЕКТА
Находясь в папке проекта вводим команду:

И получаем результат:

Теперь наш скомпилированный проект лежит по адресу /bin/Debug/netcoreapp2.1/publish относительно папки проекта. Перейдем туда и посмотрим, что там:

И вот результат:

Теперь перенесем эти файлы в отдельный каталог для сайтов по адресу /var/www/, где создадим для него папку webapp. Итак, создаем папку и копируем:

Чтобы проверить, работает ли наш сайт, перейдем в его новую папку и запустим на выполнение:

Если мы снова обратимся по IP нашему серверу через браузер, то увидим, что сайт работает.

СОЗДАНИЕ СЕРВИСА ДЛЯ АВТОЗАПУСКА ПРИЛОЖЕНИЯ

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

создадим файл настройки сервиса mywebapp.service, который будет лежать в папке /etc/systemd/system/ :

И добавим туда следующие настройки:

Теперь мы можем активировать наш сервис, запустить и посмотреть его статус:

То нужно поменять настройки NGIX (почему он так себя ведет еще не понял)

И рестартнуть все сервисы и NGIX

И ребутим сервер

502 Bad Gateway
nginx/1.14.0 (Ubuntu)
на стадии
Отлично, теперь запустим наше приложение, чтобы проверить его работу:

welcom to nginx открывался, что делать?

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Установка и запуск mono

Установку выполняем командой:

Разрешаем автозапуск и стартуем сервис:

systemctl enable mono-xsp4

systemctl start mono-xsp4

Если мы используем брандмауэр, добавим правило:

iptables -I INPUT 1 -p tcp -m tcp --dport 8084 -j ACCEPT

* где 8084 — порт, по умолчанию для mono-xsp4.

Сохраняем правила iptables любым способом, например:

* если данная команда вернет ошибку, устанавливаем iptables-persistent командой apt-get install iptables-persistent.

* не обращаем внимания на некрасивый вид страницы и отсутствующее изображение — это происходит по причине того, что демо верстка немного не коррелирует с настройкой веб-приложения.

Совместное использование с веб-сервером

Рассмотрим процесс настройки mono с веб-серверами NGINX и Apache2 путем проксирования запросов.

NGINX

Открываем файл настройки виртуального домена по умолчанию:

Находим опцию location / и приводим ее к виду:

* где proxy_pass перенаправляет все запросы на внутренний сервер mono-xsp4.

Проверяем корректность настроек:

. и перезапускаем nginx:

systemctl restart nginx

Apache

Включаем модули для проксирования:

Настраиваем виртуальный домен с сайтом — в данном примере для сайта по умолчанию:

Добавляем строки внутри VirtualHost:

Проверяем корректность настроек:

. и перезапускаем веб-сервер:

systemctl restart apache2

Дополнительные настройки

Разберем некоторые настройки, которые могут пригодится при конфигурировании сервера.

Добавить веб-приложение

Открываем файл webapp:

web-application — секция с настройками приложения.
name — имя приложения.
vpath — путь URL, при обращении по которому приложение доступно.
path — путь на сервере, где находятся скрипты приложения.

. также можно использовать дополнительные опции:

vhost — имя виртуального хоста, если будем его применять.
vport — номер сетевого порта, на котором слушает приложение.
enabled — принимает значение true или false. Позволяет включить или отключить приложение.

systemctl restart mono-xsp4

Смена порта сервера

Открываем настройки mono-xsp4:

Ищем опцию port= и меняем ее значение на порт, на котором должен работать сервис:

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