# Развёртывание вашего приложения Sisk Source: https://docs.sisk-framework.org/ru/docs/deploying.html Процесс развёртывания приложения Sisk состоит в публикации вашего проекта в продакшн. Хотя процесс относительно прост, стоит обратить внимание на детали, которые могут быть критичными для безопасности и стабильности инфраструктуры развертывания. Идеально, если вы готовы развернуть приложение в облаке, после проведения всех возможных тестов, чтобы приложение было готово к работе. ## Публикация вашего приложения Публикация вашего приложения или сервиса Sisk — это генерация бинарных файлов, готовых и оптимизированных для продакшна. В этом примере мы скомпилируем бинарники для продакшна, чтобы запустить их на машине, где установлен .NET Runtime. Вам понадобится установленный .NET SDK на вашей машине для сборки приложения и .NET Runtime на целевом сервере для его запуска. Как установить .NET Runtime на ваш Linux‑сервер, вы можете узнать [здесь](https://learn.microsoft.com/en-us/dotnet/core/install/linux), [Windows](https://learn.microsoft.com/en-us/dotnet/core/install/windows?tabs=net70) и [Mac OS](https://learn.microsoft.com/en-us/dotnet/core/install/macos). В папке, где находится ваш проект, откройте терминал и выполните команду публикации .NET: ```shell $ dotnet publish -r linux-x64 -c Release ``` Это сгенерирует ваши бинарные файлы в `bin/Release/publish/linux-x64`. > [!NOTE] > Если ваше приложение использует [portable configuration file](https://docs.sisk-framework.org/ru/docs/extensions/service-providers.md), скопируйте `service-config.json` на сервер вместе со всеми бинарными файлами, сгенерированными `dotnet publish`. > Вы можете оставить файл предварительно сконфигурированным, с переменными окружения, портами прослушивания и хостами, а также дополнительными настройками сервера. Следующий шаг — перенести эти файлы на сервер, где будет размещено ваше приложение. После этого дайте исполняемые права вашему бинарному файлу. В данном случае предположим, что имя нашего проекта — «my-app»: ```shell $ cd /home/htdocs $ chmod +x my-app $ ./my-app ``` После запуска приложения проверьте, появляются ли сообщения об ошибках. Если их нет, значит приложение работает. На данном этапе, скорее всего, будет невозможно получить доступ к вашему приложению из внешней сети, так как правила доступа, такие как брандмауэр, ещё не настроены. Мы рассмотрим это в следующих шагах. У вас должен быть адрес виртуального хоста, на котором ваше приложение слушает запросы. Он задаётся вручную в приложении и зависит от того, как вы инстанцируете сервис Sisk. Если вы **не** используете portable configuration file, найдите его там, где вы определяете экземпляр `HttpServer`: ```cs HttpServer server = HttpServer.Emit(5000, out HttpServerConfiguration config, out var host, out var router); // sisk должен слушать http://localhost:5000/ ``` Ассоциация `ListeningHost` вручную: ```cs config.ListeningHosts.Add(new ListeningHost("https://localhost:5000/", router)); ``` Или, если вы используете portable configuration file, в вашем `service-config.json`: ```json { "Server": { }, "ListeningHost": { "Ports": [ "http://localhost:5000/" ] } } ``` Исходя из этого, мы можем создать обратный прокси, который будет слушать ваш сервис и делать трафик доступным в открытой сети. ## Прокси вашего приложения Проксирование вашего сервиса означает, что вы не будете напрямую выставлять сервис Sisk во внешнюю сеть. Эта практика очень распространена при развертывании серверов, потому что: - Позволяет привязать SSL‑сертификат к вашему приложению; - Создаёт правила доступа до обращения к сервису и предотвращает перегрузки; - Позволяет контролировать полосу пропускания и лимиты запросов; - Разделяет балансировщики нагрузки для вашего приложения; - Предотвращает повреждения безопасности в случае сбоя инфраструктуры. Вы можете обслуживать приложение через обратный прокси, такой как [Nginx](https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-7.0&tabs=linux-ubuntu#install-nginx) или [Apache](https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/linux-apache?view=aspnetcore-7.0), либо использовать туннель http‑over‑dns, например [Cloudflared](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/install-and-setup/tunnel-guide/). Также не забудьте правильно обрабатывать заголовки переадресации вашего прокси, чтобы получать информацию о клиенте, такую как IP‑адрес и хост, через [forwarding resolvers](https://docs.sisk-framework.org/ru/docs/advanced/forwarding-resolvers.md). Следующий шаг после создания туннеля, настройки брандмауэра и запуска приложения — создать сервис для вашего приложения. > [!NOTE] > Использовать SSL‑сертификаты напрямую в сервисе Sisk на системах, отличных от Windows, невозможно. Это связано с реализацией `HttpListener`, который является центральным модулем управления HTTP‑очередью в Sisk, а реализация различается от ОС к ОС. Вы можете использовать SSL в сервисе Sisk, если [привяжете сертификат к виртуальному хосту через IIS](https://learn.microsoft.com/en-us/iis/manage/configuring-security/how-to-set-up-ssl-on-iis). Для остальных систем настоятельно рекомендуется использовать обратный прокси. ## Создание службы Создание службы сделает ваше приложение всегда доступным, даже после перезапуска сервера или некорректного сбоя. В этом простом руководстве мы используем материал из предыдущего урока в качестве примера, чтобы ваш сервис всегда оставался активным. 1. Перейдите в папку, где находятся файлы конфигурации службы: ```sh cd /etc/systemd/system ``` 2. Создайте файл `my-app.service` и включите в него следующее содержимое: ```ini {title="my-app.service"} [Unit] Description= [Service] # установить пользователя, который будет запускать службу User= # путь ExecStart не относителен к WorkingDirectory. # указать полный путь к исполняемому файлу WorkingDirectory=/home/htdocs ExecStart=/home/htdocs/my-app # настроить службу на постоянный перезапуск при сбое Restart=always RestartSec=3 [Install] WantedBy=multi-user.target ``` 3. Перезапустите модуль менеджера служб: ```sh $ sudo systemctl daemon-reload ``` 4. Запустите только что созданную службу по имени файла и проверьте, работает ли она: ```sh $ sudo systemctl start my-app $ sudo systemctl status my-app ``` 5. Теперь, если ваше приложение запущено («Active: active»), включите службу, чтобы она запускалась после перезагрузки системы: ```sh $ sudo systemctl enable my-app ``` Теперь вы готовы представить ваше приложение Sisk всем.