Развертывание вашего приложения Sisk

Эта страница переведена с английского автоматически. Читать оригинал

Процесс развертывания приложения Sisk состоит в том, чтобы опубликовать ваш проект в производстве. Хотя процесс относительно прост, стоит отметить детали, которые могут быть смертельными для безопасности и стабильности инфраструктуры развертывания.

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

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

Публикация вашего приложения Sisk или сервиса заключается в генерации бинарных файлов, готовых и оптимизированных для производства. В этом примере мы скомпилируем бинарные файлы для производства, чтобы они могли работать на машине, на которой установлен .NET Runtime.

Вам понадобится .NET SDK, установленный на вашей машине, чтобы построить ваше приложение, и .NET Runtime, установленный на целевом сервере, чтобы запустить ваше приложение. Вы можете узнать, как установить .NET Runtime на вашем Linux-сервере здесь, Windows и Mac OS.

В папке, где находится ваш проект, откройте терминал и используйте команду .NET publish:

Shell

$ dotnet publish -r linux-x64 -c Release

Это сгенерирует ваши бинарные файлы внутри bin/Release/publish/linux-x64.

Примечание

Если ваше приложение запускается с помощью пакета Sisk.ServiceProvider, вы должны скопировать ваш service-config.json на ваш сервер-хост вместе со всеми бинарными файлами, сгенерированными командой dotnet publish. Вы можете оставить файл предварительно настроенным, с переменными окружения, портами прослушивания и хостами, а также дополнительными настройками сервера.

Следующий шаг - перенести эти файлы на сервер, где будет размещено ваше приложение.

После этого, дайте права на выполнение вашему бинарному файлу. В этом случае давайте рассмотрим, что наш проект называется “my-app”:

Shell

$ cd /home/htdocs
$ chmod +x my-app
$ ./my-app

После запуска вашего приложения, проверьте, не выдает ли оно какие-либо сообщения об ошибках. Если оно не выдало, это означает, что ваше приложение работает.

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

У вас должен быть адрес виртуального хоста, на котором прослушивает ваше приложение. Это устанавливается вручную в приложении и зависит от того, как вы создаете экземпляр вашего сервиса Sisk.

Если вы не используете пакет Sisk.ServiceProvider, вы должны найти его там, где вы определили экземпляр вашего HttpServer:

HttpServer server = HttpServer.Emit(5000, out HttpServerConfiguration config, out var host, out var router);
// sisk должен прослушивать на http://localhost:5000/

Присвоение ListeningHost вручную:

config.ListeningHosts.Add(new ListeningHost("https://localhost:5000/", router));

Или если вы используете пакет Sisk.ServiceProvider, в вашем service-config.json:

JSON

{
  "Server": { },
  "ListeningHost": {
    "Ports": [
      "http://localhost:5000/"
    ]
  }
}

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

Проксирование вашего приложения #

Проксирование вашего сервиса означает, что вы не直接 подвергаете ваш сервис Sisk внешней сети. Эта практика очень распространена для серверных развертываний, потому что:

Позволяет присвоить сертификат SSL в вашем приложении;
Создать правила доступа перед доступом к сервису и избежать перегрузок;
Контролировать пропускную способность и ограничения запросов;
Отделять балансировщики нагрузки для вашего приложения;
Предотвратить повреждение безопасности из-за неисправной инфраструктуры.

Вы можете обслуживать ваше приложение через обратный прокси, такой как Nginx или Apache, или вы можете использовать туннель http-over-dns, такой как Cloudflared.

Также помните, что необходимо правильно разрешить заголовки прокси для получения информации о клиенте, такой как IP-адрес и хост, через forwarding resolvers.

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

Примечание

Использование сертификатов SSL напрямую в сервисе Sisk на не-Windows системах невозможно. Это является особенностью реализации HttpListener, который является центральным модулем для управления очередью HTTP в Sisk, и эта реализация варьируется от операционной системы к операционной системе. Вы можете использовать SSL в вашем сервисе Sisk, если присвоите сертификат виртуальному хосту с помощью IIS. Для других систем использование обратного прокси высоко рекомендуется.

Создание сервиса #

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

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

Доступите к папке, где находятся файлы конфигурации сервиса:
Shell
```
cd /etc/systemd/system
```

Создайте ваш файл my-app.service и включите содержимое:

my-app.serviceINI

[Unit]
Description=<описание вашего приложения>

[Service]
# задайте пользователя, который будет запускать сервис
User=<пользователь, который будет запускать сервис>

# путь к ExecStart не относителен к WorkingDirectory.
# задайте его как полный путь к файлу
WorkingDirectory=/home/htdocs
ExecStart=/home/htdocs/my-app

# задайте сервис для перезапуска после краха
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Перезапустите ваш модуль менеджера сервисов:
Shell
```
$ sudo systemctl daemon-reload
```
Запустите ваш созданный сервис с именем файла, который вы задали, и проверьте, запущен ли он:
Shell
```
$ sudo systemctl start my-app
$ sudo systemctl status my-app
```
Теперь, если ваше приложение запущено (“Active: active”), включите ваш сервис, чтобы сохранить его запущенным после перезапуска системы:
Shell
```
$ sudo systemctl enable my-app
```

Теперь вы готовы представить ваше приложение Sisk всем.