ფუნქციები
მიმართეთ app, shop, docs ან staging სასურველ ადგილას და მიიღეთ მის უკან ნამდვილი, სრულად იზოლირებული საიტი: საკუთარი stack-ით, მონაცემთა ბაზით, cache-ით, სარეზერვო ასლებითა და რესურსების იზოლაციით. DNS ჩანაწერების სრული კონტროლი, ავტომატური SSL wildcard-ების ჩათვლით და staging-ის ქვედომენები ერთი დაწკაპუნებით. ხელმისაწვდომობა: მონაცემთა ბაზის შეზღუდვა (throttling) თითოეული საიტისთვის აქტიური განვითარების ეტაპზეა და ჯერ არ არის ხელმისაწვდომი. ყველაფერი დანარჩენი, რაც აქ არის აღწერილი, უკვე მუშაობს.
ჰოსტინგების უმეტესობაზე ქვედომენი არის დირექტორია, რომელსაც წინ გადამისამართების წესი უდევს. აქ ის წარმოადგენს პირველი კლასის საიტის ჩანაწერს თავისი პროექტის ვერსიით, სერვერულ სისტემაში საკუთარი განთავსებითა და იზოლაციის საკუთარი საზღვრით. ყველაფერი, რისი გაკეთებაც ძირითად დომენზე შეგიძლიათ, ქვედომენზეც შეგიძლიათ გააკეთოთ.
თითოეული ქვედომენის საიტი შექმნილია ვერსიონირებული შაბლონიდან და უშვებს საკუთარი სტეკის ტიპსა და გარემოს: მართვადი WordPress, WooCommerce, PHP, სტატიკური HTML ან Node. თქვენი docs ქვედომენი შეიძლება იყოს სტატიკური HTML, სანამ ძირითადი დომენი უშვებს WordPress-ს, მათ შორის ყოველგვარი კომპრომისის გარეშე.
MariaDB-ის მონაცემთა ბაზა თითოეული საიტისთვის, LiteSpeed LSCache-ის სრული გვერდის ქეშირება და საიტზე მორგებული Redis-ის ან Memcached-ის ობიექტების ქეში. მშობელ საიტთან არაფერი ზიარდება, ამიტომ დატვირთული ქვედომენი ვერ წაშლის მშობელი საიტის ქეშს და ვერ გადატვირთავს მის მოთხოვნებს.
CloudLinux LVE ზღუდავს CPU-ს, RAM-ს, IO-ს, IOPS-სა და შესვლის პროცესებს თითოეული საიტისთვის, CageFS თითოეულ საიტს ანიჭებს საკუთარი ფაილური სისტემის ხედს, ხოლო MySQL Governor არეგულირებს მონაცემთა ბაზის დატვირთვას საიტის მიხედვით. კონტროლიდან გამოსული ქვედომენი იზოლირებულია საკუთარ გალიაში.
ყოველდღიური სარეზერვო ასლები ინახება 30 დღის განმავლობაში ერთი დაწკაპუნებით აღდგენის ფუნქციით, თითოეული საიტისთვის. თქვენ შეგიძლიათ დააბრუნოთ ქვედომენი გუშინდელ მდგომარეობაში ძირითად საიტზე ან მის მონათესავე სხვა გვერდებზე ზემოქმედების გარეშე.
ქვედომენები უფრო DNS-ის პრობლემაა, ვიდრე ჰოსტინგის, ამიტომ DNS-ის დონე სათანადოდაა წარმოდგენილი და არა ორი ველისგან შემდგარი ფორმის უკან დამალული.
თითოეული რეგისტრირებადი დომენი, რომელსაც ჰოსტინგს უწევთ, იღებს DNS ზონას, რომელიც იმართება ჩვენი DNS დრაივერის შუალედური ფენის მეშვეობით. თქვენ იღებთ ჩანაწერების CRUD ფუნქციონალს იმ ტიპის ჩანაწერებისთვის, რომლებსაც მოელით, ასე რომ app, shop, docs, mail ან wildcard ჰოსტის დამატება წარმოადგენს ჩანაწერის ჩვეულებრივ რედაქტირებას და არა მხარდაჭერის ბილეთის შექმნას. ზონის მდგომარეობა იდემპოტენტურად უთანხმდება პროვაიდერს, რაც ნიშნავს, რომ ნახევრად განხორციელებული ცვლილება ან ხელახლა ცდილი რედაქტირება მიგვიყვანს თქვენ მიერ მოთხოვნილ მდგომარეობამდე, ნაცვლად იმისა, რომ თქვენი ზონა დატოვოს გაურკვეველ შუალედურ ვითარებაში.
რეგისტრატორი და DNS შეგნებულად არის განცალკევებული: თქვენ შეგიძლიათ დაარეგისტრიროთ დომენი ჩვენთან და DNS დატოვოთ სხვაგან, ან შეინარჩუნოთ დომენი თქვენს არსებულ რეგისტრატორთან და უბრალოდ გადმოამისამართოთ ქვედომენი ჩვენკენ. ჩვენ ვამოწმებთ სახელთა სერვერის (nameserver) დელეგირებასა და აქტივაციას, სანამ დომენს აქტიურად (live) გამოვაცხადებთ, რათა ჩანაწერის შეცდომის შესახებ შეიტყოთ პლატფორმიდან და არა მომხმარებლისგან.
ქვედომენი, რომელიც ნელია ან აჩვენებს სერტიფიკატის გაფრთხილებას, უარესია, ვიდრე საერთოდ ქვედომენის არარსებობა, ამიტომ მიწოდების გზა იგივეა, რასაც იღებს პირველადი დომენი.
Let's Encrypt სერტიფიკატები გაიცემა და განახლდება ავტომატურად. გამოიყენეთ wildcard სერტიფიკატი ყველა ქვედომენის ერთდროულად დასაფარად, ცალკეული ჰოსტის სერტიფიკატები იქ, სადაც გსურთ მათი განცალკევება, ან ატვირთეთ თქვენი საკუთარი მორგებული სერტიფიკატი.
თითოეულ საიტს ემსახურება LiteSpeed გააქტიურებული HTTP/3-ით, ამიტომ ქვედომენი იღებს კავშირის დონის იგივე წარმადობას, რასაც ძირითადი დომენი, მეორეხარისხოვანი ვირტუალური ჰოსტის ნაცვლად.
LSCache-ის სრული გვერდის ქეშირება თითოეული საიტისთვის Redis-ის ობიექტების ქეშთან ერთად, მართვის პანელიდან ან WordPress-ის შიგნიდან კოორდინირებული გასუფთავებით. მშობელი საიტის გასუფთავება არ შლის თქვენი ქვედომენის ქეშს.
განათავსეთ ჩვენი CDN-ისა და Cloudflare-ის ანგარიშების აუზის მეშვეობით ან დააკავშირეთ თქვენი საკუთარი ანგარიშები და აირჩიეთ, რომელ ანგარიშზე განთავსდება კონკრეტული საიტი. მიწოდება არის გადაწყვეტილება, რომელსაც თქვენ იღებთ და არა ის, რომელსაც ჩვენ ვიღებთ თქვენთვის.
ქვედომენის შექმნის ყველაზე გავრცელებული მიზეზი ექსპერიმენტებისთვის უსაფრთხო გარემოს ქონაა. ეს შესაძლებლობა ჩაშენებულია და სრულიად შეუზღუდავია Mainstream პაკეტებში.
სატესტო გარემოში (staging) კლონირება ქმნის მოქმედი საიტის იზოლირებულ ასლს სატესტო ქვედომენზე, უცვლელი ფაილებითა და მონაცემთა ბაზით, იმავე სტეკსა და პროექტის ვერსიაზე, როგორც წარმოებაშია. თქვენ მუშაობთ ასლზე ხელსაწყოების სრული ნაკრებით: იზოლირებული SSH და SFTP, wp-cli, ბრაუზერზე დაფუძნებული VS Code რედაქტორი, phpMyAdmin ან Adminer, თითოეული საიტის cron და გარემოს ცვლადები.
როდესაც ცვლილება დადასტურდება, ცოცხალ რეჟიმში გაშვება ასრულებს მონაცემთა ბაზაზე მორგებულ სინქრონიზაციას პირდაპირ პროდუქციაში. თქვენ ირჩევთ ფაილებს, მონაცემთა ბაზას ან ორივეს, ხოლო ძიება-ჩანაცვლება სრულდება თქვენთვის ავტომატურად, რათა თქვენს შინაარსში არსებულმა URL-ებმა მიჰყვეს საიტს და არ დარჩეს მიმართული სატესტო ჰოსტისკენ. ვინაიდან რესურსების გამოყოფა, კლონირება და განთავსება სრულდება როგორც საიმედო Temporal სამუშაო პროცესები თითოეული ეტაპის განმეორების და კომპენსაციის მექანიზმით, პროცესის შუაში შეფერხება აუქმებს ნაწილობრივ შესრულებულ სამუშაოს და არ გტოვებთ ნახევრად დაკლონირებული საიტით.
გვირჩევნია ეს წინასწარ გითხრათ, ვიდრე მოგყიდოთ ისეთი რამ, რაც ხელს შეუშლის იმას, რის გაკეთებასაც ცდილობთ.
ქვედომენები სწორი გადაწყვეტილებაა ერთი ბრენდის სტრუქტურირებისთვის: აპი, მაღაზია, დოკუმენტაციის საიტი, მომხმარებელთა პორტალი, სატესტო გარემო თითოეული კლიენტისთვის. ისინი არასწორი გადაწყვეტილებაა ბლოგების პირადი ქსელისთვის. თითოეული ქვედომენი ერთ რეგისტრირებად დომენს იყენებს, ამიტომ ნებისმიერმა, ვინც ერთ-ერთ მათგანს განსაზღვრავს (resolve), ზუსტად იცის, ვის ეკუთვნის დანარჩენი. Wildcard სერტიფიკატის ფარგლებში ისინი ასევე იზიარებენ ერთ სერტიფიკატს, ხოლო სერტიფიკატის გაცემა ქვეყნდება Certificate Transparency-ის საჯარო ჟურნალებში, რის გამოც საერთო დომენის ქვეშ მყოფი ჰოსტების ჩამოთვლა შეუძლია ყველას, ვინც გადაამოწმებს. ეს არის საჯარო ვებ PKI-ისა და DNS-ის თვისება და არა ჩვენი პლატფორმის, და ჰოსტინგის ვერანაირი კონფიგურაცია მას ვერ შეცვლის.
ასე რომ, ქვედომენები განთავსებულია ჩვენს Mainstream და Agency ხაზებში და არა Footprint-Free-ში. თუ თქვენი მოთხოვნაა, რომ საიტები არ უნდა უკავშირდებოდეს ერთმანეთს, დაგჭირდებათ ცალკე რეგისტრაციადი დომენები footprint-ისგან თავისუფალ პროდუქტის ხაზზე, სადაც CDN და DNS ანგარიშების პულები, footprint-ის მართვა და სტატიკური HTML-ის მიწოდება სწორედ ამ შაბლონის დასარღვევად არსებობს. ორივე ფუნქციონირებს ერთსა და იმავე ძრავზე და ერთსა და იმავე მართვის პანელზე, ამიტომ სწორი არჩევანის გაკეთება მოხერხებულობის თვალსაზრისით არაფერს დაგაკარგვინებთ.
სააგენტოები და გადამყიდველები დიდი მოცულობით იყენებენ ქვედომენებს: სატესტო ჰოსტი თითოეულ კლიენტზე, წინასწარი გადახედვის ჰოსტი თითოეულ პროექტზე, პორტალი თითოეულ ანგარიშზე. პლატფორმა შექმნილია სწორედ ასეთი სამუშაო პროცესისთვის.
ორგანიზაციები ხისებრი იერარქიით ლაგდება — გადამყიდველიდან კლიენტამდე და შემდეგ საიტებამდე, ხოლო თითოეული ჩანაწერის არეალი განსაზღვრულია და უზრუნველყოფილია მონაცემთა ბაზაში სტრიქონის დონის უსაფრთხოებით. კლიენტის ქვედომენები ეკუთვნის ამავე კლიენტის ორგანიზაციას და არა საერთო საცავს, რომლის გაკონტროლებაც პირობითობის მიხედვით გიწევთ.
განათავსეთ, განაახლეთ და მართეთ მრავალი საიტი ერთი მოქმედებით, ნაცვლად იმისა, რომ გაიმეოროთ პროცესი თითოეული საიტისთვის ცალ-ცალკე.
ყველაფერი, რაც მართვის პანელშია, ხელმისაწვდომია საჯარო API-ში, რომელიც გენერირებულია OpenAPI-ს სპეციფიკაციიდან. მართეთ ქვედომენების შექმნა ორგანიზაციის დონის API გასაღებიდან, CLI-დან, Terraform-იდან ან AI ხელსაწყოდან ჩვენი MCP სერვერის მეშვეობით.
პრივილეგირებული და ადმინისტრაციული ქმედებები აღირიცხება აუდიტის ჟურნალში, ხოლო როლებზე დაფუძნებული წვდომის კონტროლი განსაზღვრავს, თუ ვის რა შეუძლია გააკეთოს თქვენს გუნდში. თქვენ შეგიძლიათ ნახოთ, ვინ შექმნა, შეცვალა ან წაშალა ჰოსტი.
დიახ. ვინაიდან თითოეული ქვედომენი ფუნქციონირებს როგორც სრულფასოვანი, ცალკე იზოლირებული საიტი საკუთარი სტეკით, მონაცემთა ბაზით, ქეშითა და სარეზერვო ასლებით, ის იკავებს საიტის ადგილს თქვენს ტარიფში ზუსტად ისევე, როგორც ძირითადი დომენი. ტარიფები იყიდება მათში შემავალი საიტების რაოდენობის მიხედვით, ამიტომ ქვედომენის საიტის დამატება აღირიცხება ზუსტად ისევე, როგორც ნებისმიერი სხვა საიტის დამატება.
დიახ, და ისინი ნამდვილად დამოუკიდებლები არიან. თითოეული ქვედომენი წარმოადგენს საკუთარი საიტის ჩანაწერს თავისი გეგმით (blueprint), ამიტომ სტეკები არ არის აუცილებელი ერთმანეთს ემთხვეოდეს: ძირითად დომენზე WordPress, shop-ზე WooCommerce, app-ზე Node.js აპლიკაცია და docs-ზე სტატიკური საიტი აქ ჩვეულებრივი კონფიგურაციაა და არა გამონაკლისი შემთხვევა. ისინი შეიძლება განთავსდეს სხვადასხვა მანქანაზე, გაუშვას განსხვავებული runtime გარემო და PHP-ის ან Node-ის განსხვავებული ვერსიები, ასევე დაინერგოს, გადავიდეს staging-ში, შეიქმნას მათი სარეზერვო ასლი და აღდგეს საკუთარი განრიგის მიხედვით. დომენის სახელის გაზიარების გარდა, ერთი მეორეს არაფრით ზღუდავს.
ნებისმიერ შემთხვევაში, ისინი ავტომატურად დაფარულია. შეგიძლიათ გასცეთ wildcard სერტიფიკატი, რომელიც ერთდროულად ფარავს დომენის ქვეშ არსებულ ყველა ჰოსტს, ან გასცეთ სერტიფიკატები ცალკეული ჰოსტებისთვის, თუ მათი განცალკევება გსურთ. Let's Encrypt-ის სერტიფიკატები უფასოა, გაიცემა და განახლდება ავტომატურად, ხოლო თუ გაქვთ საკუთარი სერტიფიკატი, შეგიძლიათ მის ნაცვლად ატვირთოთ იგი.
ჩვენ ამის წინააღმდეგი ვართ და ამ ფორმით არ გავყიდით. ყოველი ქვედომენი იზიარებს ერთ რეგისტრირებად დომენს, ხოლო wildcard სერტიფიკატის ქვეშ — საერთო სერტიფიკატს, რომლის გაცემაც Certificate Transparency-ის საჯარო ჟურნალებში ჩანს, ასე რომ, ნებისმიერ მსურველს შეუძლია ჰოსტების ერთმანეთთან დაკავშირება. იმ სამუშაოებისთვის, სადაც საიტები არ უნდა იყოს ერთმანეთთან დაკავშირებადი, გამოიყენეთ ცალკეული რეგისტრირებადი დომენები ჩვენს Footprint-Free ხაზზე, რომელიც შექმნილია სპეციალურად ამ მიზნისთვის CDN და DNS ანგარიშების პულებით, მართული კვალებით და სტატიკური HTML-ის მიწოდებით.
პლატფორმა შექმნილია იმისთვის, რომ ლოკალიზება გაუკეთოს საფრთხეს და არ დაუშვას მისი გავრცელება. CloudLinux LVE ზღუდავს თითოეული საიტის პროცესორის, მეხსიერების და IO რესურსებს მის პირად გარემოში, CageFS თითოეულ საიტს აძლევს იზოლირებულ ფაილური სისტემის ხედს, რათა შეღწევა ლოკალიზებული დარჩეს, ხოლო MySQL Governor არეგულირებს მონაცემთა ბაზის დატვირთვას თითოეული საიტისთვის, რათა ერთი საიტის მძიმე მოთხოვნებმა არ შეანელოს სერვერი. მავნე პროგრამების სკანირება, ვებ აპლიკაციების პროაქტიული ფაიერვოლი და საიტების უცვლელი სარეზერვო ასლები ამ ყველაფრის საიმედო გარანტიაა. ლოკალიზება წარმოადგენს დიზაინის მთავარ მიზანს; ვერცერთი ჰოსტინგი ვერ დადებს პირობას, რომ უსაფრთხოების დარღვევა შეუძლებელია.
დიახ. რეგისტრატორი და DNS შეგნებულად არის გამიჯნული. შეგიძლიათ შეინარჩუნოთ თქვენი დომენი მიმდინარე რეგისტრატორთან, ხოლო თქვენი ზონა — მიმდინარე DNS პროვაიდერთან და უბრალოდ გადმოამისამართოთ ქვედომენის ჩანაწერი ჩვენკენ. ჩვენ ვამოწმებთ დელეგირებასა და აქტივაციას მანამ, სანამ საიტს მოქმედად ჩავთვლით, ასე რომ, შეცდომით შეყვანილი ჩანაწერი უმალვე გამოვლინდება და არა ჩუმად გაუმართაობის სახით. როდესაც ძირითადი დომენის ზონა უკვე აქ არის განთავსებული, ჩვენ თავად ჩავწერთ ქვედომენის ჩანაწერს მასში თქვენს ნაცვლად, რათა ხელით აღარაფრის დამატება არ დაგჭირდეთ.
მხოლოდ იმით, თუ როგორ იქმნება იგი. Clone to staging ქმნის აქტიური საიტის იზოლირებულ ასლს, ფაილებისა და მონაცემთა ბაზის ჩათვლით, staging-ის ქვედომენზე, რომელიც მუშაობს იმავე სტეკითა და blueprint-ის ვერსიით, რითაც production. როდესაც კმაყოფილი იქნებით, push-to-live მას უკან ასინქრონებს მონაცემთა ბაზის გათვალისწინებით ძიებისა და ჩანაცვლების ფუნქციით. ყველაფერი დანარჩენი — იზოლაცია, SSL, ქეშირება, სარეზერვო ასლები და დეველოპერის წვდომა — ნებისმიერი სხვა საიტის იდენტურია.
თქვენ ისინი თან მიგაქვთ. პლატფორმაზე არსად არ არსებობს შეზღუდვა: შეგიძლიათ ამოიღოთ ავტორიზაციის კოდები, განბლოკოთ დომენები და გადაიტანოთ ისინი, გამოიყენოთ თქვენი საკუთარი CDN და DNS ანგარიშები და დააექსპორტოთ თქვენი საიტები. ყველა გარე პროვაიდერი, რომელსაც ვიყენებთ, ურთიერთჩანაცვლებადი ადაპტერის უკან დგას, რაც ჩვენთვისაც ისევე მართებულია, როგორც თქვენთვის.
სრული იზოლაცია, wildcard SSL, DNS-ის რეალური კონტროლი და ერთი დაწკაპუნებით სტეიჯინგი ყოველ მასპინძელზე, რომელსაც დაამატებთ. დაიწყეთ საბანკო ბარათის გარეშე 14-დღიანი საცდელი პერიოდით და დარწმუნდით მის შესაბამისობაში გადაწყვეტილების მიღებამდე.
დაიწყეთ უფასოდ