Discord Bot (NodeJS) nur erreichbar nach Website Aufruf

  • Hallo liebe Community,


    ich entwickle seit einiger Zeit an einem Discord Bot, bzw. auch anderen NodeJS Anwendungen. Nun bin ich endlich soweit das ich mich dazu entschieden habe hier eine Webhosting Paket zu buchen um meine Apps online bereit zu stellen.


    Zuerst war ich super begeistert wie einfach alles ging und das ich ohne Configänderungen alles zu laufen gebracht habe, jetzt aber ist das Problem das der Bot immer wieder aus geht, sobald ich auf die zugehörige Domain gehe ist er zwar wieder online, aber so ganz ist das ja nicht der Sinn dahinter.

    Gibt es eine Möglichkeit zu sagen das er einfach online bleibt?


    Ich hoffe ihr könnt mir helfen,

    viel Erfolg noch und Grüße ^^

  • Für Dinge, die permanent laufen sollen, brauchst Du einen (v)Server – egal ob Unmanaged oder Managed.


    Shared Webhosting Pakete sind dafür aufgrund der geteilten Ressourcen absolut nicht geeignet.


    Auf Webspace hat man normalerweise nur Sachen, die einmalig je Aufruf für einen Besucher etwas ausgeben.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Okay, ein bzw. in dem Fall meine Apps machen das genauso, nur das diese eben im Normalfall nicht direkt im Web angesprochen werden, wenn ich also den Request an den Bot auf die Website "leiten" würde und wieder zurück wäre es möglich?
    Ich möchte ja niemandem seinen Speicher oder seine Leistung nehmen, das ganze sollte sich auf nicht mehr als 100 Requests am Tag beschränken, aber es ist (für mich) ärgerlich da (auch wenn es ein "Webhosting" Paket ist) nunmal da stand "NodeJS" und ich es zum größten Teil auch so nutzen wollte. Das impliziert für mich nicht gleichzeitig das ich keine dauerhafte, ohne Frontend habende Applikation laufen lassen kann.


    Wäre dann am Ende mit Ruby das gleiche, ja?

  • Die Anwendung bleibt eine Weile noch aktiv, bevor sie sterben geschickt wird (um Resourcen frei zu geben). Wenn neue Netzwerkverbindungen eintreffen, dann bleibt die Anwendung aktiv; es sei denn der Server braucht Platz für andere, dann könnte ich mir vorstellen, dass die Anwendungen auch mal vor dem Timeout gekillt werden. (Scheduling is a bitch!)

    Meines Wissens nach nicht.

    Der nodeJs Support bei Plesk bezieht sich auf Webanwendungen nicht auf serverseitig dauerhaft laufende Anwendungen.


    Die App wird meines Wissens nach beim Request gespawnt und nach Ende wieder beendet.


    Ich habe auch mal hier gesammelt was ich weiß/zu wissen glaube... Es sind viele Fragezeichen, aber vllt kann man die ein oder andere Antwort hier mal sammeln.

    Vllt kann netcup.de dann auch einen Wikieintrag draus basteln?


    Davon habe ich auch schon gehört. Das installierte Node.js läuft scheinbar in sowas hier: Passenger - Fundamental Concepts

    Als Kunde hat man leider keinen Einfluss auf die Rahmenparameter. Manche Sachen sind ein wenig unintuitiv. Scheinbar wird auch der Shutdown anders als Standard gehandhabt: Node.js - beforeExit, Node.js - exit werden durch den Passenger Loader hier anders initialisiert und getriggered. Das hat dann Implikationen auf das Ausführungsverhalten und ich habe bisher keine Dokumentation über bestimmte Themen wie:

    • Application State: Wie viel Zeit hat eine Anwendung, um State zu persistieren? Soweit ich das verstanden habe, muss das dann alles synchron passieren (z.B. fs.writeFileSync())
    • Wie viele Instanzen startet Plesk maximal parallel? Sieht man das im Plesk?
    • Was passiert, wenn der Prozess im "Shutdown" ist und es kommt eine neue Verbindung rein? Soweit ich das verstanden habe, startet dann "magisch" eine neue Instanz. Was aber passiert mit dem "State"? Wie ist da gedacht zu synchronisieren? Theoretisch muss man das dann durch FileLocks und Datenbank garantieren und kann es nicht über Nodejs selbst (weil man kein "Event" oder so zwischen den Instanzen bekommt)
    • Kann man wirklich sagen, dass "hart Abschießen" die beste Möglichkeit zum "Sparen" ist? Meiner Einschätzung nach sollte lange Inaktivität zum ausswappen (also Rausschreiben auf einen Festspeicher; oder in-memory-compression, etc.) führen. Eigentlich ist der Charme einer Node.js Anwendung ja, dass man den State (anders als bei "klassischem" Php) nicht ständig zwischen den Anfragen "rekonstruieren" muss und in JS direkt cachen kann, mehrere ClientConnections in einem Kontext halten kann (Stichwort: websockets und server initierte Replies). WENN also der Startup der Anwendung komplex und lange dauert, weil vllt bestimmte Resourcen geladen werden müssen (die vllt in der Anfrage gar nicht gebraucht werden!), aber die Anfrage selbst nicht teuer ist, dann ist es fatal für die Einsparung einen Shutdown und Restart zu erzwingen. Zudem stiege dann auch die Latenz für den Client.
    • Was passiert, wenn ein "Cleanupjob", z.B. getriggered durch einen Cronjob mal länger braucht?
    • Wie viele der Passenger Optionen siehst du in Plesk?

    Bei meiner Ausführung könnte man sich jetzt wundern, warum Netcup auf solch ein System für node.js setzt, wo es doch scheinbar nicht allzu sehr dem "realen" node.js Gedanken folgt. Man muss aber hier auch ein paar Dinge berücksichtigen:

    • Es ist noch "recht neu"
    • Plesk ist etabliert und war hier früher schon im Einsatz; es ist einfacher eine neue Technologie durch ein Plugin nachzurüsten, als sich in risikoreiche ungewisse Gewässer zu wagen
    • Es muss wirtschaftlich für den Hoster Netcup sein: Man kann nicht einfach mal eben ein eigenes Managementsystem für eine noch junge Webtechnologie aus dem Boden stampfen und erwarten, dass das schnell und vor allem sicher funktioniert.
    • Auch wenn netcup im Angebot nicht direkt die Hosen runterlässt, dass node.js auf Sparflamme brennt: Man muss hier im Forum nur mal nach Fragen wie dieser suchen und stellt fest, dass das (noch) nicht viele sind. Das heißt: falls jmd wirklich node.js benutzt, dann ist es bisher wenigen aufgefallen, dass ihre Anwendungen in solchen Fällen hops gehen und dann ist das aus rein wirtschaftlichen Gründen auch okay.
    • Ich bin sicher, dass sich da nochwas bei Plesk und somit auch bei netcup tun wird.
    • Es ist "nur" Webhosting. Klar, wegen einem Bot, der vmtl die meiste Zeit schläft einen vServer zu bezahlen klingt echt ein bisschen overkill (wenn man es nicht selbst macht), aber vllt ist das jetzt auch grade der Präzendenzfall, der den Stein ins Rollen bringt?


    Okay, ein bzw. in dem Fall meine Apps machen das genauso, nur das diese eben im Normalfall nicht direkt im Web angesprochen werden, wenn ich also den Request an den Bot auf die Website "leiten" würde und wieder zurück wäre es möglich?
    Ich möchte ja niemandem seinen Speicher oder seine Leistung nehmen, das ganze sollte sich auf nicht mehr als 100 Requests am Tag beschränken, aber es ist (für mich) ärgerlich da (auch wenn es ein "Webhosting" Paket ist) nunmal da stand "NodeJS" und ich es zum größten Teil auch so nutzen wollte. Das impliziert für mich nicht gleichzeitig das ich keine dauerhafte, ohne Frontend habende Applikation laufen lassen kann.


    Wäre dann am Ende mit Ruby das gleiche, ja?

    Ja, das wäre bei Ruby das Gleiche: das läuft auch über eine Passenger Instanz (afaik).


    Gruß, Chili

  • Wow was für eine ausführliche Antwort, sehr gut zusammengefasst, eine genauere Beschreibung dessen würde ich mir auch wünschen, ich bleibe zwar dabei, weil ein vServer overkill ist, aber Webhosting nicht wirklich (für mich) funktioniert, was natürlich ärgerlich ist.

    Könnte es evtl sein das die Anwendung durch einen Fehler (glaub müsste im apache error log zu finden sein) abbricht und deshalb erst beim öffnen der Domain neu gestartet wird?

    Also hab noch kein derartiges Verhalten auf meinem PC festgestellt, dementsprechend glaube ich nicht das es daran liegt und die Antwort der vorherigen schon Sinn ergeben.


    Grüße,

    Shrumpf

  • Also hab noch kein derartiges Verhalten auf meinem PC festgestellt, dementsprechend glaube ich nicht das es daran liegt und die Antwort der vorherigen schon Sinn ergeben.


    Wie hast du es geschafft den Setup von netcup bei dir zuhause 1:1 nachzubauen? Zum Debuggen und Testen wäre das für viele Personen hier hilfreich zu wissen.

    "Security is like an onion - the more you dig in the more you want to cry"


  • Nutze Plesk auch auf einem Server daher:

    Das installierte Node.js läuft scheinbar in sowas hier: Passenger - Fundamental Concepts

    Ja unter Plesk läuft Node mit Passenger, dabei dient dieser als Processmanager wie z.b auch PM2.


    Wie viele Instanzen startet Plesk maximal parallel? Sieht man das im Plesk?

    Eine und ja man sieht in Plesk ob Nodejs aktiv ist und gestartet auch als Kunde. Dabei läuft die Anwendung solange bis man diese selber beendet, sollte die Anwendung durch einen Fehler abgebrochen werden startet Passenger sie wieder neu solange wie im rootverzeichnis der APP eine restart.txt vorhanden ist.



    Wie viele der Passenger Optionen siehst du in Plesk?

    Keine, auch als Admin gibt es über die Oberfläche nichts einzustellen, nur über die cli.


    Meines Wissens nach nicht.

    Der nodeJs Support bei Plesk bezieht sich auf Webanwendungen nicht auf serverseitig dauerhaft laufende Anwendungen.


    Die App wird meines Wissens nach beim Request gespawnt und nach Ende wieder beendet.

    Hab seit gestern Abend ein kleines Testscript am laufen das per setInterval den Timestamp ohne Probleme in eine Datei schreibt ohne nur einmal die APP Datei im Browser aufgerufen zu haben.

    Code
    var fs = require('fs');
    
    var myInt = setInterval(function () {
        fs.appendFile('mydata.txt',Date.now()+ '\n', function (err) {
            if (err) throw err;
            console.log('Updated!');
        });
    }, 5000);