Gdje i kako smjestiti web-stranice?

Kada razvijate web stranicu, jedno od prvih pitanja je gdje će biti smještena. Danas postoje tri najčešće opcije: shared hosting, VPS i cloud platforme. Tijekom godina isprobao sam većinu tih pristupa, a što ja koristim za male i srednje projekte možete pročitati u nastavku teksta.

Najčešći odabir za smještanje malih i srednjih web stranica je shared hosting (dijeljeni smještaj) koji je obično najpovoljniji, ali on nosi i svoje negativne strane - pružatelji usluga često prodaju više od onoga što je stvarni kapacitet poslužitelja (overselling), a na performanse vaše stranice utječu i vaši digitalni susjedi na tom poslužitelju.

Odabirom Djanga za razvoj web aplikacija vrlo rano sam se diskvalificirao kao korisnik shared hostinga jer dugo vremena oni nisu podržavali način pokretanja Django aplikacija, koji se razlikuje od posluživanja klasičnih PHP aplikacija.

S obzirom na poznavanje Linuxa tada mi je bilo najjednostavnije zakupiti jeftini poslužitelj na Hetzneru i onda ga uz pomoć OpenVZ, a kasnije i KVM-a podijeliti na kontejnere od kojih je svaki posluživao posebnu web stranicu. Održavanje fizičkog servera je ipak bilo složenije pa sam kasnije odustao od takvog načina i počeo s korištenjem VPS-ova (u početku DigitalOcean i Vultr, a kasnije su razni europski pružatelji usluga imali povoljnije i bolje ponude pa sam se postupno prebacio na njih). Dugo vremena koristio sam Scaleway (nekadašnji Online.net) zbog povoljne ponude. Međutim, s vremenom je podrška postala sve lošija, poslužitelji su bili češće nedostupni, a znalo se dogoditi da potpuno izgube sve podatke s VPS-a.

Danas za VPS-ove koristim usluge pružatelja Hetzner i Netcup, dok Contabo koristim za manje važne stvari. Na raznim poslovima sam radio na velikim projektima koji su koristili više vlastitih poslužitelja ili pružatelje cloud usluga, ali za male i srednje projekte preporučujem VPS. Oni su za njih dovoljni, jasno uz dobro optimizirane aplikacije, a njihova glavna prednost u odnosu na cloud servise je fiksni mjesečni trošak.

Za korištenje VPS-ova morate imati znanje Linux administracije. Neki korisnici traže cPanel ili druga slična rješenja za jednostavniju administraciju, ali to izbjegavam jer onda se javlja potreba za jačim i skupljim poslužiteljem, a i povećavate attack surface - površinu za napad. cPanel sam troši 1-1,5 GB RAM-a, a kako radi s najvećim mogućim ovlastima na poslužitelju, sigurnosni propust u njemu dalo bi napadaču slobodne ruke da napravi što god želi.

Moj pristup održavanju Linux poslužitelja uvijek se svodio na to da instaliram samo ono što je potrebno za obavljanje konkretne zadaće i ništa više od toga.

Jedna od opravdanih zamjerki za korištenje VPS-a je da se sve ručno instalira, no i tu se mogu koristiti Infrastructure as Code alati koji su se najviše razvili zahvaljujući cloud uslugama, ali koriste se i klasični alati kao što Ansible ili PyInfra.

Što danas koristim na novim poslužiteljima?

Nadogradnja aplikacije na VPS-u često je bila kritičan dio procesa, bez obzira je li ručno ili automatizirano jer ako se nešto potrga to obično znači downtime - web je nedostupan, mora se raditi povratak na prethodnu verziju.

Preduvjet za rješavanje tog problema je bila kontejnerizacija (Docker) aplikacija i korištenje alata za upravljanje kontejnerima. Nakon isprobavanja različitih rješenja (Coolify, Dokploy, Dokku) odlučio sam se za Kamal. Za Kamal je zaslužan David Heinemeier Hansson i 37signals ekipa. Kamal sam odabrao jer ima najnižu potrošnju resursa, ali i dobru podršku za upravljanje mrežom poslužitelja. Instalacija nove verzije aplikacije sada ide bez sekunde nedostupnosti, a povratak na staru verziju je jednostavan.

Kamal koristi svoj Kamal Proxy umjesto Traefika, koji je u prijašnjih verzijama bio proxy, a odustali su od njega jer je bio složeniji za konfiguraciju i trošio previše resursa.

Kamal Proxy omogućava zero-downtime deploy (nadogradnja bez prekida), ima ugrađenu podršku za Let's Encrypt, provjeru zdravlja aplikacije (health checks), podršku za http/2 i WebSockete.

Zbog jednostavnosti Nginx i Django aplikacija koju pokreće Gunicorn nalaze se u istom kontejneru što jako olakšava posluživanje statičkih datoteka. PostgreSQL se vrti u svojem kontejneru i u slučaju da ima više web aplikacija na poslužitelju obično sve koriste taj jedan - naravno svaka aplikacija ima svoju posebnu bazu podataka. Redis se koristi za cache, on je u svojem kontejneru i najčešće sve aplikacije koriste isti poslužitelj i opet različite baze. Kod aplikacija u kontejnerima se treba pobrinuti da logovi ostaju nakon što se kontejner sruši - za to koristim Vector.

Nijedna kritičnija aplikacija ne može bez praćenja grešaka (Error Tracking) i performansi (APM - Performance monitoring). Već dugi niz godina koristim Sentry, ali za self-hosting je već postao prezahtjevan pa sam koristio njihov servis. Sentry backtrace, tj. prikaz koda u kojem se dogodila greška je zadnjih godina postajao sve gori i sve manje koristan. Zbog toga sam potražio alternativu i sada na novim projektima koristim Honeybadger. Jednostavniji je i ima puno razumljiviji backtrace.

Bez backupa nema ništa, ne vjerujem pružateljima usluga i uvijek nastojim da imam kopiju podataka negdje u drugom podatkovnom centru i kod drugog pružatelja. Ono što mi je kod backupa važno jest da troši što manje prostora, da je brz i da imam jednostavan uvid u njega. Sve to mi je omogućio Rdiff-backup. On ne sprema svaki put kompletan backup već sprema samo razlike. Tako da mi nije problem da za neke projekte imam i povijest više od godinu dana unatrag. Da koristim neko rješenje koje za svaki backup sprema cijelu arhivu to ne bi bilo moguće. Dodatna prednost je da ne trebam posebno raspakirati backup arhivu - sve je dostupno na datotečnom sustavu. Zbog toga morate paziti tko ima pristup tom poslužitelju. Obično koristim poseban poslužitelj samo za backup.

Cloudflare koristim uglavnom za DNS. Koristim ga kao zaštitu za neke web stranice, ali tu sam otkrio da Cloudflare u besplatnom planu ima dosta ograničenja, ponekad sam nailazio na situacije u kojima je Cloudflare vraćao grešku, a zahtjev uopće nije stigao do izvornog poslužitelja. Dijagnostika takvih problema bila je ograničena. Ako vam je potrebna Cloudflare zaštita, a takvi ispadi vam nisu prihvatljivi, bolje je da se odlučite na pretplatu.

Ne smatram da su opisane tehnologije najbolji mogući način rada za svaki projekt, ali meni ta kombinacija pruža odličan omjer cijene, performansi i jednostavnosti održavanja.