Hosting Python dla Django, Flaska i FastAPI

W katalogu ~/apps/<nazwa> gotowe środowisko venv z zainstalowanym serwerem: gunicorn dla Django i Flask, uvicorn dla FastAPI i reszty ASGI. Obiekt aplikacji ma nazywać się app i leżeć w pliku app.py. Wyjątkiem jest Django, gdzie projekt musi nazywać się tak samo jak aplikacja. Jeśli czegoś zabraknie, panel odmawia dodania i pokazuje, czego dokładnie.

Tak, wszystkie. Obsługuje je jedna pozycja „ASGI” przy wyborze frameworka: FastAPI, Starlette, Litestar, Quart. Uruchamiamy je serwerem uvicorn. Wybór ma znaczenie, bo aplikacja ASGI podniesiona serwerem WSGI wstaje, melduje „działa” i zwraca błąd na każde żądanie. Dlatego framework jest osobnym polem, a nie domysłem.

Tak. Aplikacji ASGI podajemy wtedy jej prefiks, bo serwer WWW zdejmuje go przed przekazaniem żądania. Bez tego interaktywna dokumentacja szukałaby swojego pliku w korzeniu domeny, a przekierowania gubiłyby przedrostek. Przy Flasku prefiks ustawiasz po swojej stronie, w aplikacji.

Numeru nie wybierasz: przydzielamy go z puli 3001–3099 na Twoim kontenerze i wstawiamy do polecenia startowego. Aplikacja nasłuchuje lokalnie, a ruch z Twojej domeny kieruje na nią serwer WWW, razem z certyfikatem Let’s Encrypt.

Gunicorna albo Uvicorna podnosi systemd, z rosnącym odstępem między próbami: najpierw po 2 sekundach, potem coraz rzadziej, najwyżej co minutę. Krótka przerwa, na przykład restart wspólnej bazy, mija więc bez Twojego udziału. Po 12 nieudanych startach w ciągu 15 minut aplikacja dostaje stan „nie działa”, w naszym pomiarze 8 minut od pierwszego upadku. Wtedy w panelu widzisz ogon logu z tracebackiem i restartujesz ją po poprawce.

Tak, silnik wybierasz przy zakładaniu bazy w panelu. W pakiecie Standard masz 25 baz i to wspólna pula dla obu silników, więc nie płacisz osobno za PostgreSQL. Sterowniki kompilują się bez przeszkód, bo nagłówki obu silników są w obrazie.

Nie z internetu: bazy nie mają publicznego adresu. Z przeglądarki wchodzisz w nie przez panel: phpMyAdmin dla MariaDB, Adminer dla PostgreSQL, jednorazowym podpisanym odnośnikiem. Zrzut bazy pobierzesz z panelu, a z poziomu swojego serwera łączysz się normalnie.

Nie. To baza dla Twojej aplikacji na tym koncie: bez osobnej usługi z replikacją, bez dostępu z zewnątrz i bez wyboru wersji. Jeśli szukasz bazy zarządzanej niezależnie od hostingu, to nie jest ta oferta i lepiej wiedzieć o tym teraz.

Venv trzeba założyć poleceniem na serwerze, a Start ma tylko SFTP, czyli kopiowanie plików bez powłoki. Panel nie włączy w nim powłoki, bo pakiet jej nie zawiera. Środowiska wirtualnego nie zakłada za Ciebie ani panel, ani my: komendę python3 -m venv venv i instalację zależności wykonujesz sam, a do tego potrzebna jest powłoka. Dlatego Python zaczyna się u nas od pakietu Standard.

Interpreter jest jeden, systemowy, i nie instalujemy menedżerów wersji Pythona na koncie. Jeśli Twój projekt jest przywiązany do innej wersji, powiedz o tym przed zamówieniem, bo po zakupie tego nie obejdziemy.

Nie. Proces startuje z ustalonego wzorca: serwer WSGI albo ASGI wskazujący na obiekt aplikacji. Nie ma pola „wpisz własne polecenie”, więc proces spoza tego schematu nie wstanie jako usługa. Zadania cykliczne odpalisz harmonogramem z panelu.

Broker masz: Redis w Twoim kontenerze przyjmuje kolejkę Celery przez gniazdo uniksowe. Sam worker to proces spoza wzorca WSGI/ASGI, więc panel nie postawi go jako usługi. Uruchamiasz go sam przez SSH, a zadania cykliczne odpalasz harmonogramem z panelu.

Nie. Venv zakładasz i wypełniasz sam, przez SSH. Panel tego nie robi i wprost odmawia dodania aplikacji, dla której środowiska nie ma, a w komunikacie podaje gotową komendę do wklejenia.

Bezpłatnie przeniesiemy wszystkie Twoje strony na standardowym WordPressie albo PHP razem z pocztą ich domen. Dotyczy to każdego pakietu, także pocztowego. Projekt w Pythonie do niego nie wchodzi: venv i aplikację zakładasz sam, jak w krokach wyżej. Bezpłatnie przeniesiemy natomiast stronę firmową na WordPressie albo PHP i pocztę, które działają obok projektu.