En VPS til en Telegram-bot

Langt mindre, end der normalt sælges. En bot er en langlivet proces, der bruger næsten al sin tid på at vente: en tilstandsløs kommandobot ligger omkring 60 MB, og en med ORM, scheduler og cache er nærmere 150 MB. Når operativsystemet har taget sine cirka 300 MB, har en maskine med 1 GB stadig plads til 4 tunge bots eller 12 lette. Antallet af BRUGERE spiller næsten ingen rolle, fordi Telegram leverer opdateringer én ad gangen til din proces, ikke en forbindelse pr. bruger. Det, der ændrer svaret, er tilstand, du selv holder i hukommelsen: en stor cache, en database i processen, en model.

Long polling til at starte med, webhooks når det betyder noget. Med long polling åbner din bot en udgående forbindelse til Telegram og venter: den kræver hverken domæne, certifikat eller åben port, så den virker bag NAT og er den hurtigste måde at få noget op at køre på. Med en webhook forbinder Telegram sig til DIG, så den kræver en offentlig adresse, et gyldigt TLS-certifikat og en port åben mod internettet, og til gengæld fjerner den polling-løkken helt og skalerer bedre, når botten virkelig har travlt. Begge kører fint på den mindste maskine her. Den ærlige grund til at skifte er belastning eller latens, ikke mode.

Telegrams egne grænser, ikke vores: en bot, der bruger den offentlige Bot API, kan downloade filer på op til 20 MB og uploade op til 50 MB. Kører du din egen Bot API-server, løftes grænsen til 2 GB, og vigtigere: filerne havner på din servers disk i stedet for at passere gennem Telegrams. Det er den ene ændring, der reelt ændrer, hvilken maskine du har brug for. Pludselig betyder disk og trafik noget, og derfor sætter tabellen ovenfor BD-8 ud for den række og ikke ud for de andre.

En tekstbot, aldrig. En mediebot, muligvis, og det er værd at bruge tredive sekunder på regnestykket: gennemsnitlig filstørrelse × beskeder pr. dag × 30. Halvtreds tusind talebeskeder om dagen à 3 MB er omkring 4.3 TB om måneden, hvilket overstiger kvoten på de fleste billige planer og er langt fra de 32 TB på BD-8, eller linjen uden trafikmåling, hvor spørgsmålet slet ikke opstår. Begge retninger tæller: en fil, som din bot modtager, og en fil, den sender, er begge trafik.

En systemd-unit, ikke en screen-session. Skriv en lille servicefil med Restart=always, aktivér den, og botten kommer igen efter et nedbrud og efter en genstart, uden at du skal være vågen. Det er den hyppigste enkeltårsag til, at en bot "går ned" på en VPS, og det er ikke et hostingproblem: en proces, der er startet manuelt, dør med den SSH-session, der startede den. Docker med en restart-politik gør det samme, hvis du hellere vil pakke det sådan.

Ja, og det bør de fleste. Hver er en separat proces med sin egen systemd-unit og sit eget token; de deler maskinen, databasen hvis du vil, og intet andet. Regnestykket i tabellen er præcis dette spørgsmål: en maskine med 4 GB rummer 25 tunge bots, før hukommelsen bliver begrænsningen. Hold dem på separate porte og separate brugere, hvis de er til forskellige personer.

Hvor som helst dine brugere kan nå, og hvor din latens til Telegram er rimelig: botten taler med Telegrams infrastruktur, ikke direkte med dine brugere, så den sædvanlige regel om "tæt på dit publikum" betyder mindre her end for et website. Hvis botten også leverer et webdashboard eller et API til de samme brugere, så vælg regionen ud fra det i stedet. Er du i tvivl, så udrul pr. time i to regioner, mål, og slet den, der taber: $0.0113 i timen gør det til et billigt eksperiment.