Fórum Root.cz
Hlavní témata => Server => Téma založeno: registrovany123 29. 12. 2024, 17:35:39
-
Potřebuju někdy udělat nějakou drobnou web aplikaci přístupnou z Internetu. Preferuju na backend Python. Momentálně mám 2 metody:
1. Dát to do AWS EC2 jako Flask
2. Dát to do AWS jako Serverless
Obě mají nevýhody:
Ad 1) Nejstandardnější řešení, ALE, musí člověk jednou za čas udělat SSH do kontejneru a vyřešit admin věci, plus platí paušálně penzíza každý měsíc
Ad 2) Jednou vyrobím, nasadím a pak už to běží furt (pokud tam není nějaký další poser) a platí se on-demand, jenže: Je to past vedle pasti, hotová katstrofa.
Takže jsem si vzpoměl na PHP, ve kterém jsem nikdy nedělal:
"Nebylo náááhodou to PHP celé o tom, že se na hosting server nahrál jednoduchý script, stálo to 30,- Kč měsíčně a bylo to hotovo, a já tu teď čaruju se Serverless?"
A tak si říkám, že by bylo fajn, kdyby něco takového existovlo pro Python. Prostě umístím někde svůj script a server hosting ho spustí pokaždé když je vyvolána url adresa. Plus umí to CRON pro nějaké background joby a má to přístup do nějaké DB. A bylo by fajn, kdyby se to nepřipo* z toho, že někdy použivám Pandas a Numpy.
Máte s tím někdo zkušenost?
-
No, moznosti je tuna, jde o to jestli:
- maji ty skripty vystavovat nejake API nebo webovy FE nebo byt ciste "headless"?
- kde bezi ta databaze a co je to zac?
- jak velke naroky maji ty skripty na diskovy prostor (zpracovavaji velka data a potrebuji si je mezi behy uchovavat nebo ne)?
- jestli to ma byt soucasti nejakeho ekosystemu (napr. preference AWS)?
Na AWS bych to resit bud jako Lambdu (pokud nevadi omezena doba behu) nebo jako ECS kontejner.
Pokud se clovek nechce moc patlat s infrastrukturou tak jsou tu aplikacni hostingy typu Replit, Fly.io, etc., ty jsou ale trochu drazsi
Pokud jsou to male veci a je jich vic, tak bych asi premyslel o tom vzit VPS (napr. u Hetznera zacinaji myslim od 5EUR/mesic, u AWS EC2), dal na to Coolify nebo podobnou vec a deployoval pres to.
-
To co popisuješ už dneska v PHP naštěstí ve většině případů neplatí.
-
A je vůbec Python dost bezpečný pro použití na veřejném internetu?
-
Python hosting nabízí třeba Roští.cz (https://rosti.cz).
-
Rosti.cz vůbec nevypadá špatně, za 80,- Kč měsíc a za 5 minut vč. registrace mám připravený jakýsi kontejner do kterého se můžu hned ssháčkovat a dokonce je pro mě hned připravená i url adresa:
https://mojeapp-7924.rostiapp.cz/
Kdyby tohle stejné chtěl někdo udělat v AWSku v EC2 a ještě s tím nedělal, tak má robotu na celý den i víc.
Ale nějak nepobírám tu jejich DB Postgre, proože v AWSku za základní RDS s Postgresem dá člověk tak 2000,- Kč / měsíc minimálně, tady jsem to jen naklikal a je to připravené - tak jakto, že se vlezu tak levně? To nechápu.
-
Rošťíčko je fajn. SSHčko v základu, to vám také kdejaký hosting nedá.
S adminem je dobrá domluva.
Veřejně prospěšné, nekomerční, projekty, které jsme dělali s PyLades nám hostuje zdarma.
-
Ale nějak nepobírám tu jejich DB Postgre, proože v AWSku za základní RDS s Postgresem dá člověk tak 2000,- Kč / měsíc minimálně, tady jsem to jen naklikal a je to připravené - tak jakto, že se vlezu tak levně? To nechápu.
Roští.cz neznám, ale nejspíš to bude fungovat podobně jako u ostatních levných hostingů - nedostáváš svoji vlastní databázi, ale jenom kousek prostoru v jejich databázi sdílené se všemi ostatními. Zatímco v AWS si platíš za celý svůj databázový server (Aurora DSQL to možná konečně bude umět jinak) a navíc AWS obecně je dost drahej.
-
Ale nějak nepobírám tu jejich DB Postgre, proože v AWSku za základní RDS s Postgresem dá člověk tak 2000,- Kč / měsíc minimálně, tady jsem to jen naklikal a je to připravené - tak jakto, že se vlezu tak levně? To nechápu.
Protože to je sdílený databázový server a máš jen 1 GB místa.
https://rosti.cz/cenik
-
To mi nevadí, že je sdílený, co by mi vadilo je, kdyby neměli dobře udělaný management distribuce CPU resources mezi jednotlivé usery. Nevím, jak s PGéčkem docílí to, že každý db user chvilku tahá pilku. Aneb když jeden User spustí náročný job v DB, tak co na to ti ostatní.
-
To mi nevadí, že je sdílený, co by mi vadilo je, kdyby neměli dobře udělaný management distribuce CPU resources mezi jednotlivé usery. Nevím, jak s PGéčkem docílí to, že každý db user chvilku tahá pilku. Aneb když jeden User spustí náročný job v DB, tak co na to ti ostatní.
Možná jim křivdím, ale čekal bych, že to bude stejný jako s vytěžováním CPU toho sdíleného serveru - budou mít nějaký monitoring a když jim bude připadat, že někdo žere moc, tak ho časem odstřihnou. A do té doby to ostatním holt pojede blbě. Za 80 korun měsíčně člověk nemůže čekat moc zázraky.
-
"Nebylo náááhodou to PHP celé o tom, že se na hosting server nahrál jednoduchý script, stálo to 30,- Kč měsíčně a bylo to hotovo, a já tu teď čaruju se Serverless?"
Podle mě tohle nemůže existovat, protože PHP má jakoby "sdílený runtime" a hostovat "tisíc stránek kde na každou přijdou tři lidi denně" je tak v pohodě.
Zatímco v Pythonu máš následující možnosti:
- rezidentní aplikace, trvale běží (a tedy žere paměť) a dělá HTTP server (a před ni se strká nějaký nginx/haproxy jako reverzní proxy)
- spouštět skript pokaždé znovu (CGI režim), což je ale pro takové nasazení nepoužitelné, protože inicializace interpretu a importy trvají desítky milisekund minimálně - a na rozdíl od PHP to buď nemá nebo se moc nepoužívají takové ty různé optimalizace jako opcache.
Proto také ten levný hosting co tu je napsaný (Roští za 90 Kč) stojí v podstatě stejně jako VPS stejných parametrů a má to nejspíš efektivně rezervovanou RAM atd.
Budu rád, když mi někdo ukáže, že to jde dělat i jinak (PHP způsobem, tj. že skripty leží na disku, webserver je spouští jen když jsou potřeba, a tohle spouštění má zanedbatelnou režii).
-
Proto také ten levný hosting co tu je napsaný (Roští za 90 Kč) stojí v podstatě stejně jako VPS stejných parametrů a má to nejspíš efektivně rezervovanou RAM atd.
A třeba na pozadí spouští VPS, tím by vyřešili problém utilizace PGSQL a ošetřili hodně bezpečnostních problémů.
Také se dá použít mód transparentního VHD = pauzneš stroj, disk si přimountuješ, přehraješ konfigy/binàrky, odpojíš VHD a odpauzuješ stroj.
Šetří to místo na zálohování atd, ale hlavně máš všechno schované uvnitř toho virtuálu. Uzívák o VPS na pozadí ani nemusí vědět.
-
Spoluvlastním Roští.cz, tak bych chtěl reagovat na diskusi o databázích.
Možná jim křivdím, ale čekal bych, že to bude stejný jako s vytěžováním CPU toho sdíleného serveru - budou mít nějaký monitoring a když jim bude připadat, že někdo žere moc, tak ho časem odstřihnou. A do té doby to ostatním holt pojede blbě. Za 80 korun měsíčně člověk nemůže čekat moc zázraky.
Databáze v administraci jsou sdílené, tzn. na jedné instanci PgSQL a MariaDB běží více uživatelských databází. Takovéhle databáze jsou omezené počtem dotazů za hodinu. Problémy s výkonem tam běžně nemáme. Prakticky vždy to náš monitoring chytí dřív než to způsobí nějaký problém. Pokud někdo používá databázi nad nějaký běžný průměr, tak se s ním snažíme domluvit. Většinou stačí přidat index nebo upravit nějaký neefektivní SQL dotaz.
-
Hmmmm, tak jsem asi zjistil, jakým problémem trpí Roští.cz. Protože je tam všechno sdílené.
Totiž, důvod toho, proč jsem to chtěl použít namísto AWSka je, že je to "jednodušší" než nastavovat EC2.
Jenže.
Já s dovolením ještě pořád dělám v Pythonu 3.9, mám v něm udělané všchno a nemíním přejít na novější, a Roští.cz už tam má Debian s 3.13, takže samozřejmě že se podělala moje netriviální Flask aplikace.
Ano, můžu rozjet ten nejstarší Runtime co tam mají, kde je pořád Python 3.9, ale mám takové zlé tušení, že to za chvíli odstřihnou a mě to přinuté přejít na novější Python.
Zároveň protože je to jakýsik sdílený linux tak já tam nemůžu instalovat věci z apt, furt to píše permission denied.
A odmítám kompilovat Python 3.9 ze zdrojáků, na to můžou apomenout.
Já prostě sakra chci něco vyvinout, nasadit to a nechci o tom slyšet a vědět dalších minimálně 5 let. Naprosto odmítám, abych kažý 1 rok něco fixoval, protože Roští.cz by přešlo na novější Runtime a staré by odstřihlo.
Takže smolík pacholík. To už se mi víc asi vyplatí to AWSko, nebo ten fujtajbl Serverless, protože jestli si tam nepřipravili nějakou podělávku v tom AWSku, tak tam v tom serverless to snad těch 5 let opravdu umí běžet. Asi.
-
Zlatý docker, k tomu, co tam mají na Roští, jsem nějaký skeptický. Zabalím si všechno i venv do dockeru a adios amigos, as far as tam nemám bugy, tak na to nemusím šahat.
-
? Upřímně těm stížnostem moc nerozumím..
Nejstarší verze, co inzerují, je 3.9. Tzn. runtime by měl jít přepnout.
Python 3.9 je aktuálně nejstarší verze s oficiální podporou (někdy do října příštího roku)
https://devguide.python.org/versions/
Přijde mi, že se k tomu chovají vcelku logicky, když jde o veřejný hosting a nechtějí si lajsnout, že tam bude třeba děravá verze s chybami ve standardní knihovně.
Podobně je to třeba například u AWSka (Lambda) nebo Google App Engine (byť tam dávají rok k dobru s tím, že je to bez podpory, než to označí jako úplně deprecated).
Kompilovat ani instalovat logicky nejde, není to virtuální server - VPSka, ale sdílený hosting.
Nejlogičtější mi přijde upravit tu vaší aplikaci na aktuální verzi runtime, což by mělo pokrýt zhruba těch +5 let.
Neměla by to přeci být taková změna, jako třeba přechod z Pythonu 2 na 3, nebo např. přepis na asyncio.
Neznám vaší aplikaci, ale ve většině svých (byť spíš ne-webových) programů jsou to spíš drobnosti při těchhle víceméně inkrementálních přechodech a spíš než, že by mi něco přestalo rovnou chodit (kód je zpětně kompatibilní), tak mi novější verze umožní udělat nějaké jiné konstrukce nebo optimalizace.
Další věc samozřejmě je, že pokud někdo nechá aplikaci několik let úplně vyhnít, až do momentu, kdy ho to donutí, tak s tím pak typicky stráví o násobně víc času, než kdyby dělal drobné inkrementální úpravy. To vidím kolikrát právě na web aplikacích, co mají kamarádi v PHP.
-
Měním požadavky. 5 let je málo, chci ať to běží 15 let. A nechci na to šáhnout.
Idální stav je:
1. Zabalím si to do kontejneru
2. Tady hezky máte ten kontejner, hezky mi ho rozjeďte
3. Tady chci tuhle doménu a přesměrujte mi traffic na ten můj kontejner na port 6666
4. Ne, opravdu mě neotravuje s SSL, to je váš problém - https ať na ten můh kontejner funguje automaticky.
5. Ne, nebudu řešit certifikáty.
6. Dalších 15 let mě s ničím neotravujte, jako by nestačilo, že mě už každý měsíc bilujete.
6. Ne, nezajímá mě nic dalšího, čus.
-
Měním požadavky. 5 let je málo, chci ať to běží 15 let. A nechci na to šáhnout.
:)
To je slovo do pranice - triple down. Tak pak jen nějakou VPSku, kam si můžete dát úplně co chcete - třeba Debian Woody s Pythonem 2.3 a vystavit to do světa jako honey pot ;)
Já mám jednu VPS třeba na hukot.net, nejlevnější tarif je za stovku měsíčně.
-
Měním požadavky. 5 let je málo, chci ať to běží 15 let. A nechci na to šáhnout.
Idální stav je:
1. Zabalím si to do kontejneru
2. Tady hezky máte ten kontejner, hezky mi ho rozjeďte
3. Tady chci tuhle doménu a přesměrujte mi traffic na ten můj kontejner na port 6666
4. Ne, opravdu mě neotravuje s SSL, to je váš problém - https ať na ten můh kontejner funguje automaticky.
5. Ne, nebudu řešit certifikáty.
6. Dalších 15 let mě s ničím neotravujte, jako by nestačilo, že mě už každý měsíc bilujete.
6. Ne, nezajímá mě nic dalšího, čus.
Porid si VPS a za 3-4 roky ocekavej ze ti to nekdo vyhackuje :D Tvoje pozadavky jsou zcela mimo misu.. a to ti rekne jakykoliv ajtak. Prepis to do COBOLu a pak se muzeme bavit o 15 rocni SLA.
-
Když se hosting toho dockeru postará o to, že je do dockeru otevřený jen 1 port, tak jak by mi to někdo vyhackoval?
Neříkám, že to není možné udělat přes webový server, který bude mít nějakou díru, a někdo to hackne přímo přes ten port 80, ale to je tak všechno, nemyslíte?
Nemluvě o tom, že i ten problém s hacknutím web serveru se dá vyřešit prostě jenom tím, že tam dám nějaký exostické web server co nikdo nezná a co se nijak a ničím nehlásí a nepřizná, kdo je.
A hacker udělá co? Nic. Protože zná jenom postupy pro Apache a Nginx.
Můžu tam dát klidně nějakou exostiku napsanou v Pythonu a to nechám naslouchat v tom dockeru - a adios amigos.
-
On ten 1 port často stačí... Vlastně si myslím že se to tak dělá většinou jasně roboti zkouší útoky na SSH ale tam už to dnes zabezpečit není až takový problém (pokud není člověk totální ignorant).
A tím exotickým webservem/ app to je prostě jen security by obscurity dlouhodobě to nefunguje jasně odstrihnes ty nejjednodušší boty ale on si tě časem někdo najde pokud si nenapíšeš úplně vlastní webservem a to neuděláš tak ono těch hotových co se dají v praxi opravdu použít zase tolik není...
Další věc vem si rozvoj AI.. teď útočí jednoduché skripty co zkouší věci z databáze zranitelnosti ale za 15 let? S tím jak brutálně to jde dopředu? Si ani netroufam hádat jaké tipy a druhý útoku budou aktuální jediné čím jsem si jistý že současné postupy stačit nebudou.
A poslední věc je GDPR / NIS2 a podobné... Nevím co máš za app pokud je to tvůj osobní blogisek je to všem sumak ale jestli je to app co řeší osobní údaje (pravděpodobně u každé aspoň trochu užitečné app) nebo se jí týká NIS2 (to asi ne tak velký hádám nejseš) tak máš dokonce povinnost tu app zabezpečit a kdyby ti osobní údaje utekli a někdo se po tobě povozil tak tvůj přístup úřady rozhodně nepotěší a smrdí to flastrem.. ale říkám vždy je to o rozsahu a analýze rizik. Nicméně ta app prostě za 15 let bezpečná nebude to je fakt. Otázka je jestli to vadí..
-
Příspěvek k tématu a do pranice, vzácný jev na Root.cz
Ano, je otázka jestli to vadí - mě to nevadí. Navíc, chci vidět, jak mi to někdo vyhackuje - přístup nehaš co tě nepálí a continuous improvement.
Je rozdíl, když si někdo něco dělá v práci a někdo něco doma. S náročností a každou blbinou o kterou se člověk musí postarat (Nesnáším řešit SSL, a AWSkové věci jsou ještě horší z hlediska času) roste složitost strmě, a s každým problémem navíc si člověk rozmyslí, jestli tu věc vyrobí nebo se na to vykašle.
Zrovna třeba dělám webovou aplikaci pro komunitu jedné online hry.
V Pythonu ve Flasku vím, že mám security hole jako hrom, přes kterou se dá v podstatě přečíst celý disk :D Ale nikdo na to nemá šanci přijít, když neuvidí zdroják, a i kdyby někdo zdroják měl, tak nevím proč by se to kvůli mé nabastlené aplikaci snažil luštit, a i kdyby se snažil, tak ať si ten disk přečte, stejně tam nic nenajde.
Od hostingu bych proto chtěl, ať mi udělají:
1. Přístup na 1 port od mé appky
2. Přístup přes SSH
3. Zařídí HTTPS
4. A vemte si, že i ona ta díra v neaktuálním SSH se dá vyřešit na straně hostingu tak, že by se dělal nějaký SSH forwarding, tzn. že SSH jde nejprve na server od webhostingu, a z něj teprve se udělá ssh na můj server. Technicky to možné jednoznačně je, jestli jsou k tomu technologie připravené, to nevím, nejsem sysadmin.
5. I ten můj port s nějakým web serverem se dá na straně hostingu volat přes nějaký aktuálizovaný apache, takže do mé appky už budou chodit jen čistě HTTP requesty.
Výše uvedeným mi může hosting udělat hradbu okolo mojí appky a tam mi potom můžou běžet klidně staré verze všeho, hostingu to může být ukradené a když výše uvedené hosting zařídí, tak je to hotovo.
Koneckonců to ani není žádné scifi, to co jsem pospal se dá přesně udělat v AWS EC2, requesty necháp přeposílat přes API Gateway nebo něco takového. To s tím SSH awsko ale asi neumí. Nicméně je s tím voprus a člověk se naštve a nakliká, a potom to ani pořádně nefunguje, všude je v něčem háček.
-
Já prostě sakra chci něco vyvinout, nasadit to a nechci o tom slyšet a vědět dalších minimálně 5 let.
A hodinky s vodotryskem k tomu v ceně. Za 80 měsíčně. ::) ;D
-
kazdy software je deravy a nechat to bezet bez zaplat je riziko. nekdo ti tam najde diru a v ten moment platis vps utocnikovi, co si tam spusti vlastni veci.
-
To si holt musíte orzmyslet, co chcete. Na začátku jste psal, že máte VPS a chtěl byste místo toho sdílený webhosting. Pak najednou píšete o provozu kontejneru. Existují všechny tři typy služeb, ale vy musíte vědět, co chcete. Kromě těch již zmíněných tří typů služeb (sdílený webhosting, kontejner, VPS) můžete mít ještě SaaS nebo fyzické železo. Tak třeba přijde řeč i na ně.
-
Tady je problém že na to koukáš hrozně jednostranně myslíš si že problém se dá vyřešit aktualizovaným apachem / nakou proxi.
Typický u těch HTTP requestu to fakt žádný proxi server nevyřeší (jediné bys implementoval naky WAF/IDS ale to hosting za pár korun fakt moc dělat nebude) ten "zlý" request je totiž request jako jakýkoli jiný jen například obsahuje znak přes který verzi X přeteče paměť. Ty tam dáš proxac kde ta paměť nepretece a pošle to dál na tvůj server no a ten udělá co? Přeteče...
Další věc je že nemusí být nutně díra ve webserveru ale v nake sdílené knihovně.. dal i nemusíš útočit na webserver ale až na tvůj Python ( který tranzitivne zase používá sdílenou knihovnu například libressl...) prostě to fakt takto nejde. Mysli na to že z definice je sdílený hosting pro více uživatelů a hosting musí zajistit bezpečí všem... Nemůže to nechat být jen tak. Navíc když už jim naboris server tak ses najednou ve vnitřní sítí a můžeš útočit na další služby..(jasně dá se to řešit ale prostě jedna úroveň obrany padla..)
Takže pokud chceš to co popisujete tak opravdu jen VPS nebo lépe kontejner..
-
Ano, je otázka jestli to vadí - mě to nevadí. Navíc, chci vidět, jak mi to někdo vyhackuje - přístup nehaš co tě nepálí a continuous improvement.
Si rypnu - ten continuous improvement se s pristupem "necham to tam 5 let a nesahnu na to" paruje jak? Jako ze zaplaty budu patchovat az kdyz to vyhackujou, protoze doma si zamek na dvere taky koupim az kdyz me vykradou?
Anyway - cim levnejsi hosting, tim vic veci bude sdilenych, a tim vetsi tlak na to aby se workloady pohybovaly v nejakych vymezenych mantinelech (napr. verze Pythonu).
Pokud je rosti.cz moc omezujici a VPS zase moc prace, hledej container hosting - napr. AWS ECS nebo DigitalOcean ma neco a takovych budou desitky.
-
...nemůžu instalovat věci z apt...
Různých use case je velmi mnoho.
Jestli potřebujete mít větší kontrolu nad prostředím pro své aplikace, tak na to jsou jiné možnosti než poskytuje standardní i lehce nadstandardní webhosting. Např. si to postavit na https://vpsfree.cz
Webhostingy jsou cenově dostupné také díky unifikaci prostředí a snížení nákladů na správu.
Mám i aplikace na které se 25 let nemuselo sáhnout, ale používám je buď jen já, nebo malá skupinka uživatelů a nejsou veřejně dostupné.
-
Mám i aplikace na které se 25 let nemuselo sáhnout, ale používám je buď jen já, nebo malá skupinka uživatelů a nejsou veřejně dostupné.
No vždyť, to je přesně to ono :D
-
Hmmmm, tak jsem asi zjistil, jakým problémem trpí Roští.cz. Protože je tam všechno sdílené.
...
Ano, můžu rozjet ten nejstarší Runtime co tam mají, kde je pořád Python 3.9, ale mám takové zlé tušení, že to za chvíli odstřihnou a mě to přinuté přejít na novější Python.
...
Zároveň protože je to jakýsik sdílený linux tak já tam nemůžu instalovat věci z apt, furt to píše permission denied.
Já prostě sakra chci něco vyvinout, nasadit to a nechci o tom slyšet a vědět dalších minimálně 5 let. Naprosto odmítám, abych kažý 1 rok něco fixoval, protože Roští.cz by přešlo na novější Runtime a staré by odstřihlo.
Databáze jsou sice sdílené, ale kód aplikací běží podobně sdíleně jako v tom AWSku. Roští ale není alternativa k AWS. Je to úplně jinak zacílená služba.
Runtime jsme nikdy neodstřihli. Sice časem zmizí z dialogu pro vytvoření nové aplikace, ale pokud už vytvoříte nějakou aplikaci, tak poběží dokud se ji nerozhodnete aktualizovat. Nedokážu si představit, jak by to odstřihnutí mělo fungovat. Máme tam spoustu aplikací, které už nikdo nikdy neaktualizuje a ty potřebují běžet.
Ten sdílený Linux je Debian, ale root nedáváme. Existuje možnost instalace extra balíčků z repositáře Debianu, ale Bookworm Python 3.9 nemá. Pokud potřebujete root, je VPS lepší volba se všemi výhodami a nevýhodami, které s tím jdou ruku v ruce.
-
Díky za informaci, no tak to je dobrý zpráva, takže já můžu tím pádem něco vyrobit a pojede to dokud to nějaký hacker nebo něco jiného nezničí.
-
Pokud je rosti.cz moc omezujici a VPS zase moc prace, hledej container hosting - napr. AWS ECS nebo DigitalOcean ma neco a takovych budou desitky.
A co kdyz nekdo hackne Dependency Chain toho build systemu pro container? Hehe
-
Zdravim,
mam Flask v kontejneru a bezi mi to na Google Cloud (Cloud Run). Mam to jako request based (CPU plne alokovane pouze behem requestu). V prumeru tak 2 requesty denne, ucet mi chodi mesicne cca 1.50 CZK.