Kuidas majutada mitut veebisaiti õigesti
Avaldatud 17. juulil 2026
Kui peate majutama mitut veebisaiti, on kõige puhtam lahendus tavaliselt üks majutuskonto või üks server, kus iga sait on eraldatud oma domeeni, dokumendijuure, SSL-sertifikaadi ja varunduspoliitikaga. See on praktiline vastus küsimusele, kuidas majutada mitut veebisaiti nii, et te ei looks endale järgmiseks kuuks uut kasutajatoe piletit. Detailid sõltuvad liiklusest, riskitaluvusest ja sellest, kui palju serveritööd soovite ise teha.
Väikeettevõtte, agentuuri või SaaS-tiimi jaoks on selleks kolm levinud viisi. Võite paigutada mitu saiti ühele jagatud majutuse kontole, kui teenusepakkuja lubab lisadomeene. Saate neid käitada juhtpaneeliga VPS-is. Või saate need jagada eraldi serverite või konteinerite vahel, kui eraldatus on mugavusest olulisem. Kõik kolm toimivad. Need ei ole võrdsed.
Kuidas majutada mitut veebisaiti ilma segadust tekitamata
Kõige kiirem viis hätta sattuda on käsitleda viit veebisaiti nagu üht suurt kausta, millele on lihtsalt paar lisadomeeni suunatud. See võib hetkeks toimida, kuid logid räägivad hiljem kurva loo. Igal veebisaidil peaks olema oma veebijuur, vajaduse korral oma andmebaas, oma SSL ja ideaaljuhul ka oma juurutusprotsess.
Kui kasutate juhtpaneeli, looge iga sait eraldi virtuaalhostina. See tähendab, et example-one.com osutab ühele kataloogile, example-two.com teisele, ning veebiserver teab täpselt, milline konfiguratsioon millise domeeni juurde kuulub. See aitab turvalisuse, veaotsingu ja tulevaste migratsioonide puhul. See tähendab ka seda, et katkine plugin ühel WordPressi saidil ei muutu kohe kõigi probleemiks.
Selle all olev serveripinu on tavaliselt Apache, Nginx või mõlemad koos töötamas. Hallatud VPS-is on see sageli juba teie jaoks ette valmistatud. Haldamata serveris peate seadistama virtuaalhostid, PHP versioonid, tulemüürireeglid, vajaduse korral e-posti käsitlemise ja ajastatud varukoopiad. Siin avastavad paljud, et nad tahtsid majutust, mitte üllatuslikku osalise tööajaga operatsioonide karjääri.
Valige kõigepealt majutusmudel
Kui teie saidid on väikesed tutvustavad saidid või vähese liiklusega kliendiprojektid, võib piisata ühest korralikust jagatud või edasimüüja paketist. See hoiab kulud madalal ja halduspaneeli lihtsana. Kompromissiks on piiratud kontroll. Te ei pruugi saada serveri käitumist peenhäälestada, eripakette installida või mürarikkaid saite eriti hästi eraldada.
VPS on kesktee, kuhu enamik kasvavaid ettevõtteid jõuab. Saate pühendatud ressursid, vajaduse korral root-taseme paindlikkuse ja ruumi mitme domeeni korrektseks korraldamiseks. Hallatud VPS on sageli kõige rahulikum valik, eriti kui töökindlus on oluline ja te ei soovi veidrates kellaaegades plaastreid, teenuste taaskäivitusi või seirehäireid valvata.
Pühendatud serverid on mõistlikud siis, kui liiklus on suurem, vastavusnõuded rangemad või üks töökoormus võib teisi mõjutada. Need maksavad muidugi rohkem, kuid annavad tugevama jõudluse eraldatuse ja palju rohkem varuruumi. Kui majutate koos e-kaubandust, kliendipoode, staging-keskkondi ja sisemisi tööriistu, hakkab pühendatud taristu paistma vähem luksuse ja rohkem ennetusena.
Domeeni ja DNS-i seadistus
Kui majutusmudel on valitud, tuleb iga veebisaidi domeen suunata õigesse kohta. Tavaliselt tähendab see A-kirjet serveri IP-le ja mõnikord CNAME-kirjet www jaoks. Kui e-posti käsitletakse mujal, ärge kirjutage seadistamise käigus hooletult MX-kirjeid üle. See on klassikaline käik. Veebisait tuleb üles ja postkast kukub vaikselt kuristikku.
DNS-i levik on parem kui vanasti, kuid nõuab ikka kannatlikkust. TTL-i vähendamine enne migratsiooni aitab. Samuti aitab see, kui hoiate enne muudatuste tegemist alles kirjaliku kaardi praegustest kirjetest. See ei ole mõnikord just kõige kaunim DNS-i olukord, kuid dokumenteerituna on see kontrolli all.
Kui plaanite alamdomeene majutada eraldi rakendustena, käsitlege neid sama distsipliiniga. staging.example.com, shop.example.com ja api.example.com peaksid kõik omama oma eesmärki, konfiguratsiooni ja SSL-katvust. Ärge suunake kõike igale poole lootuses, et paneel teie kavatsused ise välja mõtleb.
SSL iga saidi jaoks, eranditeta
Igal domeenil peaks olema oma kehtiv SSL-sertifikaat. Mitte ainult põhisaidil. Mitte poe jaoks hiljem. Kõigil neil.
Enamik juhtpaneele suudab sertifikaate automaatselt väljastada ja uuendada Let's Encrypti või kommertsteenuse pakkuja kaudu. Väikeste saitide jaoks piisab tavaliselt automatiseeritud tasuta SSL-ist. E-kaubanduse, ettevõttekasutuse või teatud usaldus- ja garantiinõuete puhul võib tasuline sertifikaat siiski olla mõistlik. Võtmeküsimus on järjepidevus. Ühest aegunud sertifikaadist kümne domeeni seas piisab, et tekitada klientides paanikat ja tarbetut kasutajatoe müra.
Kontrollige ka, kuidas ümbersuunamisi käsitletakse. Sundige HTTP saidipõhiselt HTTPS-ile ja veenduge, et sertifikaat katab nii juurdomeeni kui ka www, kui mõlemat kasutatakse. Segasisu hoiatused on vähem dramaatilised kui tööseisak, kuid jätavad saidi siiski lõpetamata mulje.
Ressursside planeerimine on olulisem, kui inimesed arvavad
Mitme veebisaidi majutamine ühes serveris ei käi peamiselt kettaruumi ümber. CPU, RAM, PHP worker'id, andmebaasikoormus ja varundusaknad muutuvad tavaliselt tegelikeks piiranguteks.
Viis staatilist saiti võivad väikeses VPS-is õnnelikult elada. Viis hõivatud WordPressi paigaldust koos leheehitajate, otsingupluginate, ajastatud importide ja rõõmsa turundusskriptide kogumikuga võivad tarbida palju rohkem, kui oodata oskaksite. Lisage WooCommerce ja server hakkab tegema mõtlikke hääli.
Enne saitide koondamist kontrollige keskmist liiklust, tippkoormust, cron-tegevust ja rakenduse tüüpi. Kui üks sait käsitleb veebitellimusi ja teine on lihtsalt portfoolio, ei tohiks neid käsitleda võrdsete töökoormustena. Mõnel juhul on targem eraldada hõivatud rakendus kõigest muust, isegi kui server suudaks tehniliselt neid kõiki majutada.
Varukoopiad ja taastamine on osa plaanist
Siin muutuvad paljud majutusjuhendid liiga optimistlikuks. Varukoopiad ei ole märkeruut. Need on vahe rutiinse paranduse ja halva nädala vahel.
Iga saiti tuleks varundada ajakava järgi, mis vastab sellele, kui sageli see muutub. Tutvustav sait võib vajada igapäevaseid või isegi harvemaid varukoopiaid. Aktiivne pood või SaaS-rakendus võib vajada palju rangemaid taastepunkte. Ideaaljuhul hoitakse varukoopiaid serveriväliselt ja neid testitakse taastamiseks. Testimata varukoopiad on natuke nagu dekoratiivsete aukudega vihmavarjud.
Kui majutate kliendisaitideid, hoidke taastamised saidipõhisena. Te ei taha kogu serverit tagasi kerida sellepärast, et ühe saidi plugina uuendus viltu läks. Detailne varundus- ja taastamisvõimalus säästab aega ja vähendab kõrvalkahju.
Turvalisus ja eraldatus
Mida rohkem veebisaite ühte keskkonda paigutate, seda hoolikam peaks olema failide õiguste ja kontode eraldamisega. Kui kõik saidid töötavad sama kasutaja all laialt avatud kirjutusõigustega, võib üks kompromiteeritud rakendus muutuda väga kiiresti kogu serveri probleemiks.
Parem lahendus kasutab võimaluse korral eraldi süsteemikasutajaid, rangeid õigusi, tulemüüri, pahavara skannimist ja jälgitud uuendusi. Hallatud taristu aitab siin, sest paikamine ja teenuste seisundit hallatakse operatiivse rutiinina, mitte unustatud nädalavahetuse ülesandena.
Samuti tasub mõelda administraatori juurdepääsule. Kõik ei vaja root-õigusi. Iga vabakutseline ei vaja juurdepääsu igale domeenile. Andke minimaalne vajalik juurdepääs ja pidage logisid. Rahulikud süsteemid on tavaliselt need, milles on vähem tarbetuid käsi sees.
Juhtpaneel või käsitsi seadistamine?
Kui tunnete end terminalis mugavalt ja soovite täielikku kontrolli, toimib käsitsi Nginxi või Apache seadistamine hästi. See on paindlik, skriptitav ja tõhus. See eeldab ka, et olete valmis omama iga detaili alates PHP-FPM poolidest kuni logirotatsioonini.
Enamiku ettevõtete jaoks on hea juhtpaneel parem vastus. See vähendab seadistusaega, teeb domeeni- ja SSL-halduse palju lihtsamaks ning vähendab lihtsate valeseadistuste tõenäosust. See on eriti kasulik siis, kui mitmel inimesel on vaja nähtavust, kuid mitte täielikku vastutust serveriinseneeria eest.
Selline teenusepakkuja nagu kodu.cloud sobib siia tavaliselt siis, kui soovite seda tasakaalu – päris taristut taustal, kuid vähem operatiivset stressi teie poolel. See on sageli vahe kasvu ja haldusliku laialivalgumise vahel.
Levinud vead, mida vältida
Tavalised probleemid on etteaimatavad. Inimesed panevad kõik saidid ühte kataloogipuusse, unustavad eraldi varukoopiad, jätavad ühe domeeni SSL-ita või alahindavad seda, kui palju üks hõivatud rakendus võib kõike muud mõjutada.
Veel üks levinud viga on seire eiramine. Kui majutate mitut veebisaiti, peaksite teadma, millal ketas täitub, millal mälusurve kasvab, millal HTTP kontrollid ebaõnnestuvad ja millal SSL hakkab aeguma. Oodata, kuni klient tööseisakust teatab, ei ole tegelikult seirestrateegia. See on ülestunnistus.
Samuti planeerige migratsioonid hoolikalt. Kui võimalik, liigutage üht saiti korraga, kinnitage DNS, testige vorme, kontrollige e-posti suunamist ja veenduge ümbersuunamistes. Massilised üleviimised on tõhusad ainult seni, kuni üks peidetud sõltuvus katki läheb ja iga sakk teie brauseris muutub punaseks.
Milline on siis parim lahendus?
Kui soovite lühikest tehnikute kinnitatud vastust, siis siin see on: majutage mitut väikese kuni keskmise liiklusega veebisaiti hallatud VPS-is koos juhtpaneeliga, hoidke iga sait domeeni ja kataloogi järgi eraldatuna, kasutage eraldi SSL-sertifikaate, jälgige serverit ja hoidke serveriväliseid varukoopiaid. See lahendus on agentuuride ja kasvavate ettevõtete jaoks piisavalt paindlik, ilma et see muutuks liiga hapraks või liiga kalliks.
Kui üks sait on äri seisukohalt kriitiline, ressursimahukas või rangemate turbenõuetega, eraldage see pigem varem kui hiljem. Mugavus on hea. Eraldatus on mõnikord parem.
Rahulik majutuskeskkond ei teki õnne läbi. See tuleb väikestest õigetest otsustest, mis tehakse varakult, enne liikluse piike, enne plugina uuenduse ebaõnnestumist ja enne kui keegi küsib, miks kolm veebisaiti korraga maas olid. Ehitage see seda silmas pidades ja teie tulevane mina magab paremini.
Andres Saar klienditeeninduse insener