# Bereitstellung Ihrer Sisk-Anwendung Source: https://docs.sisk-framework.org/de/docs/deploying.html Der Prozess der Bereitstellung einer Sisk-Anwendung besteht darin, Ihr Projekt für die Produktion zu veröffentlichen. Obwohl der Vorgang relativ einfach ist, lohnt es sich, Details zu beachten, die für die Sicherheit und Stabilität der Infrastruktur der Bereitstellung tödlich sein können. Idealerweise sollten Sie bereit sein, Ihre Anwendung in die Cloud zu deployen, nachdem Sie alle möglichen Tests durchgeführt haben, um Ihre Anwendung fertig zu stellen. ## Veröffentlichen Ihrer Anwendung Das Veröffentlichen Ihrer Sisk-Anwendung oder Ihres Dienstes bedeutet, Binärdateien zu erzeugen, die für die Produktion bereit und optimiert sind. In diesem Beispiel werden wir die Binärdateien für die Produktion kompilieren, um sie auf einer Maschine auszuführen, auf der die .NET Runtime installiert ist. Sie benötigen das .NET SDK auf Ihrem Rechner, um Ihre Anwendung zu bauen, und die .NET Runtime auf dem Zielserver, um Ihre Anwendung auszuführen. Sie können erfahren, wie Sie die .NET Runtime auf Ihrem Linux‑Server [hier](https://learn.microsoft.com/en-us/dotnet/core/install/linux), [Windows](https://learn.microsoft.com/en-us/dotnet/core/install/windows?tabs=net70) und [Mac OS](https://learn.microsoft.com/en-us/dotnet/core/install/macos) installieren. Im Ordner, in dem sich Ihr Projekt befindet, öffnen Sie ein Terminal und verwenden Sie den .NET‑Publish‑Befehl: ```shell $ dotnet publish -r linux-x64 -c Release ``` Damit werden Ihre Binärdateien im Verzeichnis `bin/Release/publish/linux-x64` erzeugt. > [!NOTE] > Wenn Ihre Anwendung eine [portable Konfigurationsdatei](https://docs.sisk-framework.org/de/docs/extensions/service-providers.md) verwendet, sollten Sie Ihre `service-config.json` zusammen mit allen von `dotnet publish` erzeugten Binärdateien auf Ihren Host‑Server kopieren. > Sie können die Datei vorkonfiguriert lassen, mit Umgebungsvariablen, Listening‑Ports und Hosts sowie zusätzlichen Serverkonfigurationen. Der nächste Schritt besteht darin, diese Dateien auf den Server zu übertragen, auf dem Ihre Anwendung gehostet wird. Danach geben Sie der Binärdatei Ausführungsrechte. In diesem Fall nehmen wir an, dass unser Projektname „my-app“ lautet: ```shell $ cd /home/htdocs $ chmod +x my-app $ ./my-app ``` Nachdem Sie Ihre Anwendung gestartet haben, prüfen Sie, ob Fehlermeldungen ausgegeben werden. Wenn keine erscheinen, läuft Ihre Anwendung. Zu diesem Zeitpunkt wird es wahrscheinlich nicht möglich sein, von außerhalb Ihres Servers auf Ihre Anwendung zuzugreifen, da Zugriffsregeln wie eine Firewall noch nicht konfiguriert sind. Wir werden dies in den nächsten Schritten berücksichtigen. Sie sollten die Adresse des virtuellen Hosts haben, an dem Ihre Anwendung lauscht. Diese wird manuell in der Anwendung festgelegt und hängt davon ab, wie Sie Ihren Sisk‑Dienst instanziieren. Wenn Sie **keine** portable Konfigurationsdatei verwenden, finden Sie sie dort, wo Sie Ihre HttpServer‑Instanz definiert haben: ```cs HttpServer server = HttpServer.Emit(5000, out HttpServerConfiguration config, out var host, out var router); // sisk sollte auf http://localhost:5000/ lauschen ``` Manuelles Zuordnen eines ListeningHost: ```cs config.ListeningHosts.Add(new ListeningHost("https://localhost:5000/", router)); ``` Oder wenn Sie eine portable Konfigurationsdatei verwenden, in Ihrer service-config.json: ```json { "Server": { }, "ListeningHost": { "Ports": [ "http://localhost:5000/" ] } } ``` Daraus können wir einen Reverse‑Proxy erstellen, der Ihren Dienst abhört und den Datenverkehr über das offene Netzwerk verfügbar macht. ## Proxy Ihrer Anwendung Das Proxying Ihres Dienstes bedeutet, dass Sie Ihren Sisk‑Dienst nicht direkt einem externen Netzwerk aussetzen. Diese Praxis ist bei Server‑Deployments sehr verbreitet, weil: - Ermöglicht es Ihnen, ein SSL‑Zertifikat in Ihrer Anwendung zu verknüpfen; - Erstellen Sie Zugriffsregeln, bevor Sie den Dienst nutzen, und vermeiden Sie Überlastungen; - Steuern Sie Bandbreite und Anforderungsgrenzen; - Separate Load‑Balancer für Ihre Anwendung; - Verhindern Sie Sicherheitsbeschädigungen einer fehlerhaften Infrastruktur. Sie können Ihre Anwendung über einen Reverse‑Proxy wie [Nginx](https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-7.0&tabs=linux-ubuntu#install-nginx) oder [Apache](https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/linux-apache?view=aspnetcore-7.0) bereitstellen, oder Sie können einen http‑over‑dns‑Tunnel wie [Cloudflared](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/install-and-setup/tunnel-guide/) verwenden. Denken Sie außerdem daran, die Weiterleitungs‑Header Ihres Proxys korrekt aufzulösen, um die Informationen Ihrer Clients, wie IP‑Adresse und Host, über [Forwarding‑Resolver](https://docs.sisk-framework.org/de/docs/advanced/forwarding-resolvers.md) zu erhalten. Der nächste Schritt nach dem Erstellen Ihres Tunnels, der Firewall‑Konfiguration und dem Betrieb Ihrer Anwendung besteht darin, einen Dienst für Ihre Anwendung zu erstellen. > [!NOTE] > Die direkte Verwendung von SSL‑Zertifikaten im Sisk‑Dienst auf Nicht‑Windows‑Systemen ist nicht möglich. Dies liegt an der Implementierung von HttpListener, dem zentralen Modul für die HTTP‑Queue‑Verwaltung in Sisk, und diese Implementierung variiert von Betriebssystem zu Betriebssystem. Sie können SSL in Ihrem Sisk‑Dienst verwenden, wenn Sie ein Zertifikat mit dem virtuellen Host über IIS [verknüpfen](https://learn.microsoft.com/en-us/iis/manage/configuring-security/how-to-set-up-ssl-on-iis). Für andere Systeme wird dringend empfohlen, einen Reverse‑Proxy zu nutzen. ## Erstellen eines Dienstes Das Erstellen eines Dienstes sorgt dafür, dass Ihre Anwendung stets verfügbar ist, selbst nach einem Neustart Ihrer Serverinstanz oder einem nicht wiederherstellbaren Absturz. In diesem einfachen Tutorial verwenden wir den Inhalt des vorherigen Tutorials als Beispiel, um Ihren Dienst dauerhaft aktiv zu halten. 1. Greifen Sie auf den Ordner zu, in dem sich die Service‑Konfigurationsdateien befinden: ```sh cd /etc/systemd/system ``` 2. Erstellen Sie Ihre Datei `my-app.service` und fügen Sie den Inhalt ein: ```ini {title="my-app.service"} [Unit] Description= [Service] # legt den Benutzer fest, der den Dienst startet User= # Der ExecStart-Pfad ist nicht relativ zum WorkingDirectory. # setze ihn als vollständigen Pfad zur ausführbaren Datei WorkingDirectory=/home/htdocs ExecStart=/home/htdocs/my-app # legt fest, dass der Dienst bei einem Absturz immer neu gestartet wird Restart=always RestartSec=3 [Install] WantedBy=multi-user.target ``` 3. Starten Sie Ihr Service‑Manager‑Modul neu: ```sh $ sudo systemctl daemon-reload ``` 4. Starten Sie den neu erstellten Dienst anhand des Dateinamens und prüfen Sie, ob er läuft: ```sh $ sudo systemctl start my-app $ sudo systemctl status my-app ``` 5. Wenn Ihre Anwendung jetzt läuft („Active: active“), aktivieren Sie Ihren Dienst, damit er nach einem Systemneustart weiterläuft: ```sh $ sudo systemctl enable my-app ``` Jetzt sind Sie bereit, Ihre Sisk‑Anwendung allen zu präsentieren.