Serwer VPS dla bota Telegram

Znacznie mniej, niż zwykle się sprzedaje. Bot to długotrwały proces, który niemal cały czas czeka: bezstanowy bot poleceń zajmuje około 60 MB, a bot z ORM, harmonogramem i cache bliżej 150 MB. Po odjęciu mniej więcej 300 MB na system operacyjny maszyna z 1 GB wciąż mieści 4 ciężkich botów lub 12 lekkich. Liczba UŻYTKOWNIKÓW prawie nie ma znaczenia, ponieważ Telegram dostarcza aktualizacje do procesu po jednej, a nie przez osobne połączenie na użytkownika. Odpowiedź zmienia natomiast stan, który sami Państwo trzymają w pamięci: duży cache, baza danych w procesie, model.

Na start long polling, webhooki wtedy, gdy ma to znaczenie. Przy long pollingu bot otwiera połączenie wychodzące do Telegrama i czeka: nie potrzebuje domeny, certyfikatu ani otwartego portu, więc działa za NAT i jest najszybszym sposobem na uruchomienie czegokolwiek. Przy webhooku to Telegram łączy się z PAŃSTWEM, więc potrzebny jest publiczny adres, ważny certyfikat TLS i port otwarty do internetu; w zamian znika całkowicie pętla odpytywania, a rozwiązanie lepiej się skaluje, gdy bot jest naprawdę obciążony. Oba sposoby działają bez problemu na najmniejszej maszynie z tej strony. Uczciwym powodem do zmiany jest obciążenie lub opóźnienie, a nie moda.

Limity Telegrama, nie nasze: bot korzystający z publicznego Bot API może pobierać pliki do 20 MB i wysyłać do 50 MB. Własny serwer Bot API podnosi ten limit do 2 GB i, co ważniejsze, sprawia, że pliki trafiają na dysk Państwa serwera, zamiast przechodzić przez serwery Telegrama. To jedyna zmiana, która naprawdę wpływa na wybór maszyny: nagle liczą się dysk i transfer, dlatego tabela powyżej przypisuje BD-8 do tego wiersza, a nie do pozostałych.

Bot tekstowy: nigdy. Bot multimedialny: być może, i warto poświęcić trzydzieści sekund na rachunek: średni rozmiar pliku × wiadomości dziennie × 30. Pięćdziesiąt tysięcy wiadomości głosowych dziennie po 3 MB to około 4.3 TB miesięcznie, czyli więcej niż limit większości tanich planów, a zarazem daleko od 32 TB w BD-8 (albo od linii bez liczenia transferu, gdzie to pytanie nie istnieje). Liczą się oba kierunki: plik odebrany przez bota i plik przez niego wysłany to w obu przypadkach transfer.

Jednostka systemd, nie sesja screen. Wystarczy napisać mały plik usługi z Restart=always i go włączyć, a bot wróci po awarii i po restarcie bez Państwa udziału. To najczęstszy powód, dla którego bot „pada” na VPS, i nie jest to problem hostingu: proces uruchomiony ręcznie kończy się razem z sesją SSH, która go uruchomiła. Docker z polityką restartu wykonuje to samo zadanie, jeśli wolą Państwo takie opakowanie.

Tak, i większość osób powinna tak robić. Każdy bot to osobny proces z własną jednostką systemd i własnym tokenem; dzielą maszynę, w razie potrzeby bazę danych i nic więcej. Rachunek w tabeli odpowiada dokładnie na to pytanie: maszyna z 4 GB mieści 25 ciężkich botów, zanim pamięć stanie się ograniczeniem. Jeśli boty są dla różnych osób, proszę uruchamiać je na osobnych portach i osobnych użytkownikach.

W dowolnym miejscu, do którego mają dostęp Państwa użytkownicy i z którego opóźnienie do Telegrama jest rozsądne. Bot komunikuje się z infrastrukturą Telegrama, a nie bezpośrednio z użytkownikami, więc zwykła zasada „blisko odbiorców” ma tu mniejsze znaczenie niż w przypadku strony internetowej. Jeśli bot udostępnia też tym samym użytkownikom panel webowy lub API, region należy dobrać pod to. W razie wątpliwości proszę wdrożyć serwery na godziny w dwóch regionach, zmierzyć i usunąć ten, który wypadnie gorzej: przy $0.0113 za godzinę to tani eksperyment.