Blogs

Janvāra beigās manā e-pastā iekrita kārtējais rēķins no DigitalOcean. Summa – $48.85.

Pats par sevi tas nav nepanesams skaitlis uzņēmumam, bet individuālam izstrādātājam vai mazam projektam tas lika aizdomāties. Ielūkojoties rēķina detaļās, aina kļuva skaidra un nedaudz skumja: es maksāju par “gaisu”. Manā rīcībā bija seši dažādi “Dropleti” (virtuālie serveri). Viens automatizācijai, viens blogam, trīs dažādiem WordPress klientu projektiem un vēl viens eksperimentiem.

Tā bija klasiska serveru sadrumstalotība. Kopā es īrēju aptuveni 7 GB operatīvās atmiņas (RAM) un 6 procesora kodolus, bet tie bija izkaisīti pa mazām, izolētām saliņām. Kamēr viens serveris smaka nost no atmiņas trūkuma, citi stāvēja dīkstāvē ar 5% noslodzi. Es maksāju par sešām dažādām operētājsistēmām, sešām IP adresēm un sešiem uzturēšanas punktiem.

Bija pienācis laiks optimizācijai. Bija pienācis laiks “Lielajai Migrācijai”.

Stratēģija: Konsolidācija

Mans mērķis bija vienkāršs: pārcelt visu uz vienu, jaudīgu serveri, kas atrodas Eiropā un maksā eiro, nevis dolāros. Pēc tirgus izpētes izvēle krita uz Hostinger KVM 2 VPS plānu.

Matemātika bija pārliecinoša:

• DigitalOcean: 6 serveri, kopā ~7GB RAM = ~$45/mēn.
• Hostinger: 1 serveris, 8GB RAM, NVMe disks = ~12€/mēn.

Bet dzelži ir tikai viena vienādojuma puse. Lai uz viena servera droši un ērti darbinātu tik dažādas tehnoloģijas – PHP (WordPress, Laravel) un Node.js (Ghost, n8n, Next.js) – man vajadzēja spēcīgu vadības paneli. Es izvēlējos HestiaCP. Tas ir viegls, atvērta koda panelis, kas lieliski tiek galā ar standarta Web lietām un ļauj man kā inženierim “pabāzt apakšā” arī sarežģītākas Docker konfigurācijas.

Pirmais cēliens: Mānīgais vieglums

Migrāciju es sāku ar WordPress vietni okunevs.pro. Tā bija kā iesildīšanās pirms maratona. HestiaCP panelī izveidoju domēnu, uzinstalēju “tukšu” WordPress, un ar spraudņa All-in-One WP Migration palīdzību pārcēlu saturu. DNS nomaiņa, SSL sertifikāta ģenerēšana – viss noritēja gludi 15 minūšu laikā.

Šajā brīdī radās mānīga sajūta: “Tas taču ir vienkārši! Kāpēc es to nedarīju agrāk?”

Taču WordPress ir “standarta” gadījums. Īstie piedzīvojumi sākās, kad nonācām pie Docker konteineriem.

Otrais cēliens: Docker un Nginx “dejas”

Nākamais rindā bija mans n8n automatizācijas serveris un Ghost blogs (apatija.blog). Šie rīki nedarbojas uz PHP; tie ir Node.js aplikācijas, kuras vislabāk izolēt Docker konteineros.

Šeit saskāros ar pirmo arhitektūras izaicinājumu. HestiaCP (un tās izmantotais Nginx serveris) pēc noklusējuma meklē failus mapē public_html. Bet mani Docker konteineri “dzīvo” uz portiem.

Lai tos savienotu, nācās iedziļināties Nginx konfigurācijā un izveidot speciālas “Proxy” veidnes. Tas nozīmē, ka Nginx vairs nekalpo kā failu serveris, bet kā satiksmes regulētājs, kas pārsūta apmeklētāju uz pareizo Docker portu.

Īpaši dramatiska bija Ghost bloga glābšana. Vecais DigitalOcean serveris bija tik pārslogots (“Out of Memory”), ka es vairs nevarēju piekļūt administratora panelim, lai veiktu eksportu. Jutos kā ķirurgs, kurš veic operāciju lauka apstākļos: caur termināli (SSH) ar mysqldump komandām “izgriezu” datubāzes saturu, ar tar sapakoju attēlus un ar scp (Secure Copy) aizšāvu datus uz jauno serveri, apejot nestrādājošo Web interfeisu. Kad jaunajā serverī blogs atdzīvojās ar visiem rakstiem – tā bija uzvaras garša.

Trešais cēliens: Iekšējā tīkla labirinti

Vislielāko “galvas lauzīšanu” sagādāja projekts kazocina.pro – citātu krātuve, kas būvēta uz Next.js (Frontend) un Strapi (Backend).

Te mēs saskārāmies ar “olas un vistas” problēmu tīkla drošībā. Next.js serveris (kurš ģenerē lapu) mēģināja sazināties ar Strapi API caur publisko domēnu https://api.kazocina.pro. Taču, tā kā abi atradās vienā serverī aiz Docker tīkla, SSL sertifikāta pārbaude neizdevās (ERR_TLS_CERT_ALTNAME_INVALID). Serveris “neuzticējās” pats savam publiskajam sertifikātam iekšējā tīklā.

Risinājums nebija elegants, bet efektīvs – mēs likām Next.js konteineram ignorēt SSL kļūdas iekšējā saziņā (NODE_TLS_REJECT_UNAUTHORIZED: "0"). Produkcijas vidē tas parasti nav ieteicams, bet šādā noslēgtā, viena servera arhitektūrā tas bija nepieciešamais kompromiss, lai sistēma sāktu strādāt.

Ceturtais cēliens: Laravel un “Open Basedir” cietoksnis

Kad šķita, ka viss jau ir galā, pēdējais projekts – grāmatvedības sistēma uz Laravel 11 – sagādāja visilgāko cīņu.

Laravel tika migrēts “Native” režīmā (bez Docker), izmantojot Hestia iebūvēto PHP. Un te mēs atdūrāmies pret drošības sienu, ko sauc par open_basedir. HestiaCP drošības apsvērumu dēļ neļauj PHP procesam piekļūt nevienam failam, kas atrodas ārpus konkrētās vietnes public_html mapes. Taču Laravel arhitektūra pieprasa, lai kods atrastos līmeni augstāk, drošībā no publiskās piekļuves.

Mēs cīnījāmies ar “Error 500” paziņojumiem vairāku stundu garumā. Mainījām konfigurācijas caur paneli – nepalīdzēja. Mainījām failus ar roku – Hestia tos pārrakstīja atpakaļ pie katra restarta.

Izrādījās, ka vainīgs bija HestiaCP mainīgais %home%, kuru sistēma dažās konfigurācijās nepareizi interpretēja. Risinājums bija izveidot pielāgotu PHP veidni (laravel.tpl), kurā ar “cieto” ceļu (hardcoded path) tika atļauta piekļuve projekta saknes mapei. Tas bija brīdis, kad saproti – automātiskie rīki ir lieliski, līdz brīdim, kad tie nav, un tad tev ir jāzina, kā darbojas Linux “zem kapota”.

Epilogs: Nginx pret Apache

Visas migrācijas laikā mūs vajāja kāds spoks. Ik pa laikam, restartējot serveri, visas lapas rādīja “Under Construction”. Log faili kliedza: bind() to 0.0.0.0:8080 failed (98: Address already in use).

Izrādījās, ka konfigurējot Docker veidnes, es nejauši biju licis Nginx serverim klausīties uz 8080. porta. HestiaCP ekosistēmā 8080. ports pieder Apache serverim. Rezultātā abi tīmekļa serveri “kāvās” par vienu portu, un, protams, neviens nestrādāja.

Tā bija vērtīga mācība par HestiaCP arhitektūru: Nginx ir priekšā (ports 80/443), Apache ir aizmugurē (ports 8080). Sajaucot šo kārtību, sabrūk viss kāršu namiņš.

Rezultāts

Vai tas bija tā vērts?

• Izmaksas: No ~$45 uz ~12€ mēnesī. Ietaupījums gadā: ~400€.
• Veiktspēja: Visi projekti tagad darbojas uz 8GB RAM un NVMe diskiem, kas padara tos ievērojami ātrākus par vecajiem 1GB dropletiem.
• Pārvaldība: Tā vietā, lai lēkātu starp 6 dažādām konsolēm, man ir viens centralizēts panelis visam.

Jā, migrācija prasīja laiku, pacietību un pamatīgu rakņāšanos log failos. Bet rezultātā es ieguvu ne tikai lētāku rēķinu, bet arī pilnīgu kontroli pār savu infrastruktūru un, kas svarīgākais, – zināšanas, kuras nevar nopirkt, tikai iegūt praksē.