Serveru un hostinga iestatīšana
Iestatām VPS hostingu uz Hetzner, Contabo vai DigitalOcean ar Ubuntu LTS, Nginx, PHP-FPM un PostgreSQL vai MySQL. Zero-downtime deploys ar rsync vai Deployer, Let's Encrypt uz cron, UFW firewalls un dienas offsite rezerves kopijas. Standarta projekta piemērs: pārceļam tirgotāju no shared hostinga uz 20 EUR/mēnesī Hetzner kasti un noskatāmies, kā lapas ātrums uz pusi samazinās, jo šaurums vienmēr bija dalītais CPU kredīts.
Kas patiešām atšķir mūsu pieeju
Mēs ar nodomu izvēlamies garlaicīgu infrastruktūru. Hetzner CX22 (4 GB RAM, ~6 EUR/mēnesī) vai CX42 (16 GB RAM, ~20 EUR/mēnesī) ar Ubuntu 24.04 LTS apkalpo lielāko daļu mazu līdz vidēju web slodžu labāk nekā managed PaaS par piecas reizes lielāku cenu, un mēs labāk ietaupīto budžetu tērējam patiesai steka noregulēšanai, nevis skaistākam panelim. Lielākajai daļai mūsu klientu pareizā atbilde ir viens VPS, nevis trīs, un to pasakām, kad jums nevajag arhitektūru, ar kādu atnācāt prasīt.
Steks, ko parasti uzstādām, gandrīz vienmēr izskatās tāpat: Nginx kā web serveris, PHP-FPM ar OPcache un validate_timestamps=0 produkcijā, PostgreSQL 16 vai MySQL 8 atkarībā no lietotnes, plus ufw un fail2ban firewall slānim. Web līmenim uz VPS neizmantojam Docker, jo viena VPS uzstādījumā tas pievieno sarežģītību bez liela ieguvuma, un deploy stāsts kļūst sliktāks, ne labāks. Konteineri ir lieliski dažām slodzēm. Lielākoties tie nav pareizā atbilde 5000 apmeklējumu dienā Laravel vietnei.
Deploy notiek ar Deployer vai mazu pielāgotu rsync skriptu, ar simlinkētu current/ direktoriju, lai deploy ir atomisks un rollback ir viens simlink swap. SSL ir Let's Encrypt ar cron-balstītu atjaunošanu, nevis Cloudflare flexible mode. Rezerves kopijas iet uz Backblaze B2 katru nakti ar 30 dienu glabāšanu, plus iknedēļas verifikācijas skripts, kas atjauno pēdējo dump'u throwaway PostgreSQL konteinerā un palaiž rindu skaitīšanu. Rezerves kopija, ko nekad neesat atjaunojuši, ir rezerves kopija, kuras jums nav.
Kas var iet greizi (un ko mēs ar to darām)
Visbiežākā kļūme, ko redzam, ir migrācija, kas pirmajā dienā noiet labi, bet trešajā dienā kaut ko salauž konfigurācijas detaļas dēļ, kas nebija runbook. PHP upload_max_filesize, post_max_size, Nginx client_max_body_size, WordPress admin augšupielādes ierobežojums. Katrai ir cits noklusējums un cits konfigurācijas fails, un tirgotājam, kas otrdienas rītā mēģina augšupielādēt 12 MB produkta foto, nebūs nozīmes, kurš slānis ir nepareizs. Pirms nododam serveri, izpildām rakstītu sarakstu ar aptuveni 40 iestatījumiem, ko savākuši no iepriekšējiem incidentiem, ieskaitot augšupielādes ķēdi.
Otrais ir DNS. Esam noskatījušies, kā nevainojama migrācija tiek uzspridzināta ar zonas failu, ko neviens nav atjaunojis, vai ar trešās puses pakalpojumu (maksājumu vārteju, ESP, webmail sniedzēju), kuram ir vecā IP cache pāri TTL. Pārslēgšanos plānojam svētdienas agrā rītā ar 7-dienu TTL nomešanu divas dienas iepriekš, un veco VPS turam darbībā vēl vismaz 10 dienas pēc pārcelšanas. Ja kaut kas salūst astotajā dienā, gribam, lai rollback ir tūlītējs, nevis let me re-provision the box.
Trešais ir monitoringa aklie punkti. Jauns VPS bez monitoringa ir serveris, par kuru dzirdat tikai tad, kad tas nokrīt. Pirms nododam, uzstādām Netdata vai mazu Prometheus + Grafana iekārtojumu, ar paziņojumiem uz e-pastu un (ja klients grib) Slack. Disks piepildās pirms CPU lielākajai daļai slodžu, tāpēc disk-usage paziņojumu noregulējam visrūpīgāk. 80% sūta brīdinājumu, 90% sūta paging.
Ir projekts, ko vajag sakārtot?
Pastāstiet, kas nestrādā, un mēs pateiksim, vai varam palīdzēt.