အင်္ဂါရပ်များ
app၊ shop၊ docs သို့မဟုတ် staging တို့ကို သင်နှစ်သက်ရာမည်သည့်နေရာမဆို ညွှန်းဆိုနိုင်ပြီး ၎င်း၏နောက်ကွယ်တွင် သီးခြားခွဲထုတ်ထားသော စစ်မှန်သည့် ဆိုက်တစ်ခုကို ရရှိပါမည်- ၎င်း၏ကိုယ်ပိုင် stack၊ ဒေတာဘေ့စ်၊ cache၊ လုံခြုံရေးမိတ္တူများနှင့် အရင်းအမြစ် ကန့်သတ်ဘောင် (resource cage) တို့ ပါဝင်သည်။ DNS မှတ်တမ်းကို အပြည့်အဝ ထိန်းချုပ်နိုင်ခြင်း၊ wildcard များအပါအဝင် အလိုအလျောက် SSL ရရှိခြင်းနှင့် ကလစ်တစ်ချက်နှိပ်ရုံဖြင့် staging ဒိုမိန်းခွဲများ ဖန်တီးနိုင်ခြင်းတို့ ပါဝင်သည်။ ရရှိနိုင်မှု- ဆိုက်တစ်ခုချင်းစီအလိုက် ဒေတာဘေ့စ် ထိန်းချုပ်မှု (database throttling) ကို တက်ကြွစွာ စာမေးပွဲထုတ်လုပ်နေဆဲဖြစ်ပြီး မရရှိနိုင်သေးပါ။ ဤနေရာတွင် ဖော်ပြထားသော အခြားအရာအားလုံးကို ယနေ့တွင် တိုက်ရိုက်အသုံးပြုနိုင်ပါပြီ။
ဟို့စ်အများစုတွင် ဆပ်ဒိုမိန်းဆိုသည်မှာ ရှေ့တွင် ရေးသားချက်အသစ်ပြုပြင်သည့် စည်းမျဉ်းပါရှိသော လမ်းညွှန်တစ်ခုဖြစ်သည်။ ဤနေရာတွင်မူ ၎င်းသည် ၎င်း၏ကိုယ်ပိုင် ပုံစံတူမူကြမ်းဗားရှင်း၊ ဖလက် (fleet) ပေါ်ရှိ ၎င်း၏ကိုယ်ပိုင်နေရာချထားမှုနှင့် ၎င်း၏ကိုယ်ပိုင် သီးသန့်ခွဲထုတ်မှုနယ်နိမိတ်တို့ပါရှိသည့် ပထမတန်းစား ဆိုက်မှတ်တမ်းတစ်ခု ဖြစ်သည်။ ပင်မဒိုမိန်းတစ်ခုကို သင်လုပ်ဆောင်နိုင်သမျှ မည်သည့်အရာကိုမဆို ဆပ်ဒိုမိန်းတစ်ခုအတွက်လည်း သင်လုပ်ဆောင်နိုင်သည်။
သီးခြားဒိုမိန်ခွဲတစ်ခုစီကို ဗားရှင်းသတ်မှတ်ထားသော ဘလူးပရင့်မှ တည်ဆောက်ထားပြီး ၎င်း၏ကိုယ်ပိုင် စတက်ခ်အမျိုးအစားနှင့် ရန်းတိုင်းမ်းများဖြင့် လည်ပတ်ပါသည်- အစီအစဉ်တကျ စီမံခန့်ခွဲပေးထားသော WordPress၊ WooCommerce၊ PHP၊ static HTML သို့မဟုတ် Node တို့ဖြစ်ကြသည်။ သင်၏ docs ဒိုမိန်ခွဲသည် static HTML ဖြစ်နိုင်ပြီး မိခင်ဒိုမိန် (root) ကိုမူ မည်သည့်ထိခိုက်မှုမှမရှိဘဲ WordPress ဖြင့် လည်ပတ်နိုင်သည်။
ဆိုက်တစ်ခုစီအတွက် MariaDB ဒေတာဘေ့စ်တစ်ခု၊ LiteSpeed LSCache စာမျက်နှာအပြည့် အမြန်သိမ်းဆည်းမှု (full-page caching) နှင့် ဆိုက်တစ်ခုစီအတွက် Redis သို့မဟုတ် Memcached အရာဝတ္ထု အမြန်သိမ်းဆည်းမှု (object cache) တို့ ပါဝင်ပါသည်။ ပင်မဆိုက်နှင့် မည်သည်မျှ မျှဝေသုံးစွဲမည် မဟုတ်သောကြောင့် ပမာဏကြီးမားသည့် ပင်မခွဲဒိုမိန်း (subdomain) တစ်ခုသည် ပင်မဆိုက်၏ အမြန်သိမ်းဆည်းမှုကို ဖယ်ရှားခြင်း သို့မဟုတ် ၎င်း၏ စုံစမ်းမေးမြန်းမှုများ (queries) ကို နှောင့်ယှက်ခြင်းများ ပြုလုပ်နိုင်မည် မဟုတ်ပါ။
CloudLinux LVE သည် ဆိုက်တစ်ခုချင်းစီအတွက် CPU၊ RAM၊ IO၊ IOPS နှင့် entry processes များကို ကန့်သတ်ပေးပြီး CageFS က ဆိုက်တစ်ခုချင်းစီကို ၎င်းတို့၏ကိုယ်ပိုင် ဖိုင်စနစ်မြင်ကွင်းကို ပေးစွမ်းကာ MySQL Governor က ဆိုက်အလိုက် ဒေတာဘေ့စ်ဝန်ထ်မှုကို ထိန်းညှိပေးပါသည်။ ထိန်းမနိုင်သိမ်းမရဖြစ်နေသော ဆပ်ဒိုမိန်းတစ်ခုကို ၎င်း၏ကိုယ်ပိုင်ကေဂျာအတွင်း၌သာ ကန့်သတ်ထားရှိမည် ဖြစ်ပါသည်။
ဝဘ်ဆိုက်တစ်ခုစီအတွက် သီးခြားစီ ၁-ကြိမ်နှိပ်ရုံဖြင့် မူလအတိုင်းပြန်ထားနိုင်သော နေ့စဉ် Backup များကို ရက်ပေါင်း ၃၀ စာ သိမ်းဆည်းပေးထားပါသည်။ ပင်မဝဘ်ဆိုက် သို့မဟုတ် ယင်း၏ အခြား Subdomain များကို ထိခိုက်မှုမရှိစေဘဲ Subdomain တစ်ခုကို မနေ့က အခြေအနေသို့ ပြန်လည်ပြောင်းလဲနိုင်ပါသည်။
Subdomain များသည် Hosting ပြဿနာမဖြစ်မီ DNS ပြဿနာတစ်ခုဖြစ်သောကြောင့် DNS Layer ကို ကွက်လပ်နှစ်ခုပါသည့် Form တစ်ခု၏ နောက်ကွယ်တွင် ဝှက်ထားခြင်းမပြုဘဲ သင့်လျော်စွာ ဖော်ပြပေးထားပါသည်။
သင် ပြုပြင်ဖန်တီးပေးသည့် မှတ်ပုံတင်နိုင်သော ဒိုမိန်းတိုင်းသည် ကျွန်ုပ်တို့၏ DNS ဒရိုက်ဘာစနစ်မှတစ်ဆင့် စီမံခန့်ခွဲသော DNS ဇုန်တစ်ခုစီ ရရှိပါသည်။ သင် မျှော်လင့်ထားသည့် မှတ်တမ်းအမျိုးအစားများအတိုင်း မှတ်တမ်း CRUD ပြုလုပ်နိုင်ခွင့် ရရှိမည်ဖြစ်ရာ app၊ shop၊ docs၊ mail သို့မဟုတ် wildcard ဟော့စ်တစ်ခု ထည့်သွင်းခြင်းသည် ပံ့ပိုးကူညီရေးထံ အကူအညီတောင်းခံစာ ပေးပို့ရန် မလိုဘဲ မှတ်တမ်းပြင်ဆင်မှုတစ်ခု ပြုလုပ်ရုံမျှသာ ဖြစ်ပါသည်။ ဇုန်အခြေအနေကို ဝန်ဆောင်မှုပေးသူနှင့် တူညီသောရလဒ်ထွက်ရှိအောင် ပုံမှန်ညှိနှိုင်းပေးသောကြောင့် ဝက်ဝက်ကွဲ ပြင်ဆင်ထားမှု သို့မဟုတ် ထပ်မံကြိုးပမ်းသည့် ပြင်ဆင်မှုသည် သင်၏ဇုန်ကို မရေမရာ အလယ်အလတ်အခြေအနေတွင် ကျန်ရစ်စေခြင်း မရှိဘဲ သင်တောင်းဆိုထားသည့် အခြေအနေသို့ ရောက်ရှိသွားမည် ဖြစ်ပါသည်။
ဒိုမိန်းမှတ်ပုံတင်အဖွဲ့အစည်း (Registrar) နှင့် DNS တို့ကို တမင်တကာ သီးခြားစီ ခွဲခြားထားပါသည်- သင်သည် ကျွန်ုပ်တို့ထံတွင် ဒိုမိန်းတစ်ခုကို မှတ်ပုံတင်ပြီး DNS ကို အခြားနေရာတွင် ထားရှိနိုင်သည် သို့မဟုတ် ဒိုမိန်းကို သင်၏ လက်ရှိမှတ်ပုံတင်အဖွဲ့အစည်းတွင်ပင် ထားရှိပြီး ဆပ်ဒိုမိန်း (subdomain) တစ်ခုကို ကျွန်ုပ်တို့ထံ သို့ ညွှန်ပြရုံမျှသာ ပြုလုပ်နိုင်ပါသည်။ ဒိုမိန်းတစ်ခုကို စတင်အသုံးပြုနိုင်ပြီဟု မသတ်မှတ်မီ နိမ်းဆာဗာ (nameserver) လွှဲအပ်ညွှန်ကြားမှုနှင့် စတင်လှုပ်ရှားမှုကို ကျွန်ုပ်တို့က အတည်ပြုစစ်ဆေးပါသည်၊ ထို့ကြောင့် မှတ်တမ်းအချက်အလက် မှားယွင်းနေပါက အသုံးပြသူထံမှ မဟုတ်ဘဲ ပလက်ဖောင်းထံမှသာ စတင်သိရှိနိုင်မည်ဖြစ်ပါသည်။
နှေးကွေးခြင်း သို့မဟုတ် လက်မှတ်သတိပေးချက်ပြသခြင်းရှိသော ဒိုမိန်းခွဲတစ်ခုသည် ဒိုမိန်းခွဲလုံးဝမရှိခြင်းထက် ပိုဆိုးသောကြောင့် ပို့ဆောင်ရေးလမ်းကြောင်းသည် ပင်မဒိုမိန်းရရှိသည့် လမ်းကြောင်းအတိုင်းပင် ဖြစ်ပါသည်။
Let's Encrypt လက်မှတ်များကို အလိုအလျောက် ထုတ်ပေးပြီး သက်တမ်းတိုးပေးပါသည်။ ဒိုမိန်းခွဲတိုင်းကို တစ်ပြိုင်နက်တည်း အကျုံးဝင်စေရန် ဝိုင်းကဒ် လက်မှတ်ကို သုံးပါ၊ သီးခြားစီ ခွဲခြားထားလိုပါက တစ်ခုချင်းစီအတွက် လက်မှတ်များကို သုံးပါ သို့မဟုတ် သင့်ကိုယ်ပိုင် စိတ်ကြိုက်လက်မှတ်ကို တင်ယူပါ။
ဆိုဒ်တိုင်းကို HTTP/3 ကို ဖွင့်ထားပေးသော LiteSpeed ဖြင့် ဝန်ဆောင်မှုပေးထားသဖြင့် ဒုတိယတန်းစား vhost တစ်ခုအနေနဲ့မဟုတ်ဘဲ ပင်မဒိုမိန်းကဲ့သို့ပင် ဆပ်ဒိုမိန်းသည်လည်း ချိတ်ဆက်မှုအဆင့် စွမ်းဆောင်ရည်ကို တူညီစွာ ရရှိမည်ဖြစ်သည်။
LSCache full-page caching အပြင် site တစ်ခုချင်းစီအတွက် Redis object cache ပါရှိပြီး၊ dashboard မှဖြစ်စေ WordPress အတွင်းမှဖြစ်စေ ညှိနှိုင်းပြီး ရှင်းလင်းနိုင်ပါသည်။ မိခင်ဆိုဒ်ကို ရှင်းလင်းခြင်းက သင်၏ subdomain ကက်ရှ်ကို မပျက်စေပါ။
ကျွန်ုပ်တို့၏ CDN နှင့် Cloudflare အကောင့်ပေါင်းစု (pool) မှတစ်ဆင့် တင်သွင်းပါ (သို့) သင့်ကိုယ်ပိုင်အကောင့်များကို ချိတ်ဆက်ပြီး သတ်မှတ်ထားသောဆိုက်တစ်ခုကို မည်သည့်အကောင့်သို့ တင်သွင်းမည်ကို ရွေးချယ်ပါ။ ပို့ဆောင်မှုဆိုသည်မှာ ကျွန်ုပ်တို့ဆုံးဖြတ်သည်မဟုတ်ဘဲ သင်ကိုယ်တိုင်ဆုံးဖြတ်ရသည့်အရာ ဖြစ်ပါသည်။
סubdomain တစ်ခု လိုချင်ရတဲ့ အဖြစ်များဆုံး အကြောင်းရင်းကတော့ အမှားအယွင်းလုပ်ပြီး စမ်းသပ်ဖို့ လုံခြုံတဲ့နေရာ တစ်ခု ရှိချင်လို့ပါပဲ။ Mainstream ပလန်များတွင် အဆိုပါလမ်းကြောင်းကို ကြိုတင်ထည့်သွင်းပေးထားပြီး ကန့်သတ်ချက်မရှိ အသုံးပြုနိုင်ပါသည်။
Clone to staging သည် တိုက်ရိုက်လွှင့်ထားသော ဆိုက်၏ ဖိုင်များနှင့် ဒေတာဘေ့စ်များကို မထိခိုက်စေဘဲ စတေဂျင်း ဆပ်ဒိုမိန်းပေါ်တွင် ထုတ်လုပ်မှု ပတ်ဝန်းကျင်၏ စတက်ခ်နှင့် ဘလူးပရင့် ဗားရှင်းအတိုင်း သီးခြားကော်ပီတစ်ခု ဖန်တီးပေးသည်။ သင်သည် ဤကော်ပီပေါ်တွင် သီးသန့် SSH နှင့် SFTP၊ wp-cli၊ ဘရောက်ဆာအခြေပြု VS Code တည်းဖြတ်သူ၊ phpMyAdmin သို့မဟုတ် Adminer၊ ဆိုက်တစ်ခုချင်းစီအလိုက် cron နှင့် ပတ်ဝန်းကျင် ဗေရီယေဘယ်လ်များ စသည့် ပစ္စည်းအစုံအလင်ဖြင့် လုပ်ဆောင်နိုင်သည်။
ပြောင်းလဲမှု အတည်ဖြစ်သွားသောအခါ live သို့ ပို့ဆောင်ခြင်းသည် production ထံသို့ ဒေတာဘေ့စ်ကို သိရှိနားလည်သော စင်းခ်လုပ်ဆောင်မှုကို ပြန်လည်ပြုလုပ်ပေးပါသည်။ သင်သည် ဖိုင်များ၊ ဒေတာဘေ့စ် သို့မဟုတ် နှစ်ခုလုံးကို ရွေးချယ်နိုင်ပြီး၊ သင့်အကြောင်းအရာထဲရှိ URL များသည် စတိတ်ဂျင်းဟို့စ်သို့ ပြန်ညွှန်းနေမည့်အစား ဆိုက်အတိုင်း လိုက်ပါသွားစေရန် ရှာဖွေ-အစားထိုးခြင်းကို သင့်အတွက် ဆောင်ရွက်ပေးပါသည်။ Provision လုပ်ခြင်း၊ clone လုပ်ခြင်းနှင့် deploy လုပ်ခြင်း အားလုံးသည် အဆင့်တစ်ခုချင်းစီအလိုက် ပြန်လည်ကြိုးပမ်းမှုများနှင့် လျှော်ကြေးပေးမှုများပါရှိသည့် ခိုင်မာသော Temporal လုပ်ငန်းစဉ်များအဖြစ် အလုပ်လုပ်သောကြောင့် အလယ်အလတ်တွင် ပျက်ကွက်မှုဖြစ်ပေါ်ပါက သင့်အား ဆိုက်တစ်ခုလုံး၏ တစ်ဝက်တစ်ပျက် clone လုပ်ထားသော အခြေအနေတွင် ကျန်ရစ်စေမည့်အစား မပြီးပြတ်သေးသော လုပ်ဆောင်ချက်များကို မူလအတိုင်း ပြန်လည်ရုပ်သိမ်းပေးပါသည်။
သင့်ရဲ့ လုပ်ဆောင်ချက်ကို ထိခိုက်စေမယ့် အရာတစ်ခုကို ရောင်းချမယ့်အစား ဒါကို သင့်ကို အစောတည်းက ရိုးရိုးသားသား ပြောပြချင်ပါတယ်။
ဆပ်ဒိုမိန်း (Subdomain) များသည် အမှတ်တံဆိပ်တစ်ခုတည်းကို တည်ဆောက်ပုံဖော်ရန်အတွက် မှန်ကန်သော အဖြေဖြစ်သည်- အက်ပ်တစ်ခု၊ စတိုးတစ်ခု၊ စာရွက်စာတမ်းဆိုင်ရာ ဝဘ်ဆိုက်တစ်ခု၊ သုံးစွဲသူ ပေါ်တယ်လ်တစ်ခု သို့မဟုတ် သုံးစွဲသူအလိုက် စမ်းသပ်ပတ်ဝန်းကျင် (staging environment) တစ်ခုတို့ဖြစ်ကြသည်။ ၎င်းတို့သည် သီးသန့် ဘလော့ဂ် ကွန်ရက် (private blog network) တစ်ခုအတွက်မူ မှားယွင်းသော အဖြေဖြစ်သည်။ ဆပ်ဒိုမိန်းတိုင်းသည် မှတ်ပုံတင်နိုင်သော ဒိုမိန်းတစ်ခုတည်းကို မျှဝေသုံးစွဲကြသဖြင့် ၎င်းတို့အနက် တစ်ခုခုကို လိပ်စာရှာဖွေစစ်ဆေးသူ မည်သူမဆို ကျန်ရှိသော ဒိုမိန်းများကို မည်သူပိုင်ဆိုင်ကြောင်း အတိအကျ သိရှိနိုင်ပါသည်။ Wildcard လက်မှတ်တစ်ခုအောက်တွင် ၎င်းတို့သည် TLS လက်မှတ်တစ်ခုကိုလည်း မျှဝေသုံးစွဲကြပြီး လက်မှတ်ထုတ်ပေးမှုများကို အများပြည်သူဆိုင်ရာ Certificate Transparency လော့ဂ်များသို့ ထုတ်ပြန်ထားသဖြင့် မျှဝေသုံးစွဲထားသော ဒိုမိန်းတစ်ခုအောက်ရှိ ဟို့စ် (host) များကို စိတ်ဝင်စား၍ ကြည့်ရှုသူ မည်သူမဆို စာရင်းထုတ်ကြည့်နိုင်ပါသည်။ ထိုအချက်သည် ကျွန်ုပ်တို့ပလက်ဖောင်း၏ လုပ်ဆောင်ချက်ကြောင့် မဟုတ်ဘဲ အများပြည်သူဆိုင်ရာ ဝဘ် PKI နှင့် DNS တို့၏ သဘာဝလက္ခဏာရပ်တစ်ခုသာဖြစ်ပြီး မည်သည့် ဟော့စတင်း ပြင်ဆင်သတ်မှတ်မှုကမျှ ၎င်းကို ပြောင်းလဲနိုင်မည် မဟုတ်ပါ။
ထို့ကြောင့် ၎င်းတို့၏ စပ်ကြားဒိုမိန်း (subdomains) များကို Footprint-Free ထုတ်ကုန်လိုင်းတွင် မဟုတ်ဘဲ ကျွန်ုပ်တို့၏ Mainstream နှင့် Agency လိုင်းများတွင်သာ ထားရှိပါသည်။ သင့်၏လိုအပ်ချက်မှာ ဆိုက်များသည် တစ်ခုနှင့်တစ်ခု ချိတ်ဆက်၍မရနိုင်ရန်ဖြစ်ပါက CDN နှင့် DNS အကောင့် ရန်ပုံငွေများ၊ footprint စီမံခန့်ခွဲမှုနှင့် static-HTML ပေးပို့မှုစနစ်တို့သည် ထိုပုံစံကို တိကျစွာဖြတ်တောက်ရန် တည်ရှိနေသည့် footprint-free ထုတ်ကုန်လိုင်းပေါ်ရှိ သီးခြားမှတ်ပုံတင်နိုင်သော ဒိုမိန်းများ လိုအပ်ပါသည်။ နှစ်ခုစလုံးသည် တူညီသော အင်ဂျင်နှင့် တူညီသော ဒက်ရှ်ဘုတ်ပေါ်တွင် တည်ရှိနေသောကြောင့် မှန်ကန်စွာရွေးချယ်ခြင်းက သင့်အတွက် အဆင်ပြေမှုကို မည်သို့မျှ ထိခိုက်စေမည် မဟုတ်ပါ။
အေဂျင်စီများနှင့် ပြန်လည်ရောင်းချသူများသည် အဓိက လက်ခံဆာဗာခွဲများကို အများအပြား အသုံးပြုကြသည်- ကလိုင်းယဲင့်တစ်ဦးလျှင် စတေ့ဂျင်းဟို့စ်တစ်ခု၊ ပရောဂျက်တစ်ခုလျှင် ကြိုတင်ကြည့်ရှုသည့်ဟို့စ်တစ်ခု၊ အကောင့်တစ်ခုလျှင် ပေါ်တယ်တစ်ခုစီဖြစ်သည်။ ပလက်ဖောင်းကို ဤကဲ့သို့သော လုပ်ငန်းပုံစံအတွက် တည်ဆောက်ထားခြင်း ဖြစ်သည်။
အဖွဲ့အစည်းများကို ပြန်လည်ရောင်းချသူမှသည် သုံးစွဲသူ၊ ထိုမှတစ်ဆင့် ဝဘ်ဆိုက်များအထိ သစ်ပင်ပုံစံ အဆင့်ဆင့်ဖွဲ့စည်းထားပြီး မှတ်တမ်းတိုင်းကို ဒေတာဘေ့စ်တွင် တန်းစီဇယားအဆင့် လုံခြုံရေးဖြင့် နယ်ပယ်သတ်မှတ်၍ စည်းကြပ်ထားသည်။ သုံးစွဲသူ၏ ဒိုမိန်းခွဲများသည် ထုံးစံအတိုင်း သင်ကိုယ်တိုင် ထိန်းကျောင်းနေရသည့် မျှဝေသုံး သိုလှောင်ကန်သို့ မဟုတ်ဘဲ ထိုသုံးစွဲသူ၏ အဖွဲ့အစည်းနှင့်သာ သက်ဆိုင်သည်။
ဆိုက်တစ်ခုချင်းစီအတွက် ထပ်ခါတလဲလဲလုပ်နေမည့်အစား လုပ်ဆောင်ချက်တစ်ခုတည်းဖြင့် ဆိုက်များစွာကို ဖြန့်ကျက်ခြင်း၊ အပ်ဒိတ်လုပ်ခြင်းနှင့် စီမံခန့်ခွဲခြင်းတို့ လုပ်ဆောင်ပါ။
Dashboard ထဲရှိ အရာအားလုံးသည် OpenAPI သတ်မှတ်ချက်မှ ထုတ်လုပ်ထားသော အများသုံး API ထဲတွင် ရှိပါသည်။ အဖွဲ့အစည်းအဆင့် API ကီး၊ CLI၊ Terraform သို့မဟုတ် ကျွန်ုပ်တို့၏ MCP ဆာဗာပေါ်ရှိ AI ကိရိယာမှတစ်ဆင့် စာဗ်ဒိုမိန်း ဖန်တီးမှုကို လုပ်ဆောင်ပါ။
အခွင့်ထူးခံနှင့် စီမံခန့်ခွဲရေးဆိုင်ရာ လုပ်ဆောင်ချက်များကို စာရင်းစစ်မှတ်တမ်းတင်ထားပြီး၊ သင့်အဖွဲ့ထဲမှ မည်သူက မည်သည့်အရာကို လုပ်ဆောင်နိုင်သည်ဆိုသည်ကို အခန်းကဏ္ဍအခြေခံ အသုံးပြုခွင့် ထိန်းချုပ်မှု (RBAC) ဖြင့် စီမံခန့်ခွဲပါသည်။ ဟော့စ် (host) တစ်ခုကို မည်သူက ဖန်တီးခဲ့သည်၊ ပြောင်းလဲခဲ့သည် သို့မဟုတ် ဖယ်ရှားခဲ့သည်ကို သင် ကြည့်ရှုနိုင်ပါသည်။
ဟုတ်ပါသည်၊၊ ဆပ်ဒိုမိန်းတစ်ခုစီသည် ၎င်း၏ ကိုယ်ပိုင် အစုအဝေး (stack)၊ ဒေတာဘေ့စ်၊ ကက်ရှ် (cache) နှင့် ဘက်ခ်အပ်များပါဝင်သော သီးခြားခွဲထုတ်ထားသည့် ဆိုက်အပြည့်အစုံအဖြစ် လည်ပတ်သောကြောင့် ပင်မဒိုမိန်းတစ်ခုကဲ့သို့ပင် သင့်ပလန်တွင် ဆိုက်နေရာတစ်ခုကို ယူပါသည်။ ပလန်များကို ၎င်းတို့အကျုံးဝင်သည့် ဆိုက်အရေအတွက်ဖြင့် ရောင်းချခြင်းဖြစ်သောကြောင့် ဆပ်ဒိုမိန်းဆိုက်တစ်ခု ထည့်သွင်းခြင်းသည် အခြားမည်သည့်ဆိုက်ကိုမဆို ထည့်သွင်းခြင်းကဲ့သို့ပင် စာရင်းတွက်ချက်မှု တူညီပါသည်။
ဟုတ်ပါတယ်၊ ၎င်းတို့သည် သီးခြားစီ သီးလွန်းစွာ ရပ်တည်နေကြခြင်း ဖြစ်ပါသည်။ စာဗ်ဒိုမိန်း (subdomain) တိုင်းသည် ၎င်း၏ ကိုယ်ပိုင် ဘလူးပရင့် (blueprint) ရှိသော သီးသန့် ဝဘ်ဆိုက် မှတ်တမ်းတစ်ခု ဖြစ်သောကြောင့် နည်းပညာစတက်ခ် (stack) များ တူညီနေရန် မလိုပါ - မူလ ဒိုမိန်းတွင် WordPress၊ shop တွင် WooCommerce၊ app တွင် Node.js အက်ပ်နှင့် docs တွင် static ဝဘ်ဆိုက်တစ်ခု ထားရှိခြင်းသည် အထူးကိစ္စရပ် မဟုတ်ဘဲ ဤနေရာတွင် ပုံမှန် တပ်ဆင်မှုမျိုးသာ ဖြစ်ပါသည်။ ၎င်းတို့ကို မတူညီသော စက်များတွင် ထားရှိနိုင်ပြီး၊ မတူညီသော မောင်းနှင်မှု ပတ်ဝန်းကျင်များ (runtimes) နှင့် မတူညီသော PHP သို့မဟုတ် Node ဗားရှင်းများကို မောင်းနှင်နိုင်ကာ၊ ၎င်းတို့၏ ကိုယ်ပိုင် အချိန်ဇယားများအတိုင်း လွှင့်တင်ခြင်း (deploy)၊ စမ်းသပ်ခြင်း (stage)၊ အရန်သိမ်းခြင်း (backup) နှင့် မူလအတိုင်း ပြန်လည်ပြင်ဆင်ခြင်း (rollback) တို့ကို လုပ်ဆောင်နိုင်ပါသည်။ ဒိုမိန်းအမည် တစ်ခုတည်းကို မျှဝေသုံးစွဲထားခြင်းမှလွဲ၍ တစ်ခု၏ သတ်မှတ်ချက်က အခြားတစ်ခုအပေါ် မည်သို့မျှ အကန့်အသတ် မဖြစ်စေပါ။
ဘယ်လိုပဲဖြစ်ဖြစ် ၎င်းတို့ကို အလိုအလျောက် အကာအကွယ်ပေးထားပါသည်။ ဒိုမိန်းအောက်ရှိ ဟို့စ်တိုင်းကို တစ်ပြိုင်နက်တည်း အကာအကွယ်ပေးသည့် ဝိုင်းလ်ကတ် (wildcard) လက်မှတ်ကို ထုတ်ပေးနိုင်သည် သို့မဟုတ် သီးခြားစီထားရှိလိုပါက ဟို့စ်တစ်ခုချင်းစီအလိုက် လက်မှတ်များကို ထုတ်ပေးနိုင်သည်။ Let's Encrypt လက်မှတ်များသည် အခမဲ့ဖြစ်ပြီး အလိုအလျောက် ထုတ်ပေးခြင်းနှင့် သက်တမ်းတိုးခြင်းတို့ကို ပြုလုပ်ပေးသည်၊ သင့်တွင် အခြားလက်မှတ်ရှိပါကလည်း ၎င်းအစား စိတ်ကြိုက်လက်မှတ်တစ်ခုကို တင်နိုင်သည်။
ကျွန်ုပ်တို့အနေဖြင့် ၎င်းကို အကြံမပြုပါ၊ ၎င်းအတိုင်းလည်း ရောင်းချမည်မဟုတ်ပါ။ ဆပ်ဒိုမိန်းတိုင်းသည် မှတ်ပုံတင်နိုင်သော ဒိုမိန်းတစ်ခုတည်းကို မျှဝေကြပြီး ဝိုင်းလ်ဒ်ကတ် လက်မှတ်အောက်တွင် လူသိရှင်ကြား Certificate Transparency မှတ်တမ်းများ၌ ထုတ်ပေးမှု ပေါ်လာသော မျှဝေထားသောလက်မှတ်ကို အသုံးပြုကြသောကြောင့် လက်ခံဆောင်ရွက်ပေးသူများကို ကြည့်ရှုသူတိုင်းက အချင်းချင်း ချိတ်ဆက်နိုင်ကြပါသည်။ ဆိုက်များကို ချိတ်ဆက်၍မရအောင် လုပ်ဆောင်ရမည့် အလုပ်များအတွက် CDN နှင့် DNS အကောင့်ပူးလ်များ၊ စီမံခန့်ခွဲထားသော ဖွတ်ပရင့်များနှင့် static-HTML ပို့ဆောင်မှုတို့ဖြင့် အထူးဒီဇိုင်းထုတ်ထားသည့် ကျွန်ုပ်တို့၏ Footprint-Free လိုင်းပေါ်ရှိ သီးခြားမှတ်ပုံတင်နိုင်သော ဒိုမိန်းများကို အသုံးပြုပါ။
ပလက်ဖောင်းသည် ပြဿနာကို ပျံ့နှံ့ခွင့်မပြုဘဲ ထိန်းချုပ်နိုင်ရန် တည်ဆောက်ထားသည်။ CloudLinux LVE သည် ဆိုက်တစ်ခုချင်းစီ၏ CPU၊ မတ်မိုရီနှင့် IO ကို ၎င်း၏ကိုယ်ပိုင်ကန့်သတ်ချက်အတွင်း ထိန်းချုပ်ထားပြီး CageFS က ဆိုက်တစ်ခုချင်းစီကို သီးခြားဖိုင်စနစ်မြင်ကွင်းဖြင့် ပံ့ပိုးပေးထားသဖြင့် ထိုးဖောက်ဝင်ရောက်မှုကို ထိန်းချုပ်နိုင်ကာ MySQL Governor က ဆိုက်အလိုက် ဒေတာဘေ့စ်ဝန်ကို ထိန်းညှိပေးသောကြောင့် ဆိုက်တစ်ခု၏ အလုပ်များသော မေးမြန်းချက်များကြောင့် ဆာဗာနှေးကွေးသွားခြင်း မရှိစေပါ။ မဲလ်ဝဲစကင်န်ဖတ်ခြင်း၊ တက်ကြွစွာကာကွယ်ပေးသော ဝက်ဘ်အပလီကေးရှင်း ဖိုင်းဝေါနှင့် ဆိုက်အလိုက် ပြောင်းလဲ၍မရသော ဘက်ခ်အပ်များက ၎င်းကို အပြည့်အဝ ပံ့ပိုးပေးထားသည်။ ထိန်းချုပ်ကန့်သတ်နိုင်ခြင်းသည် ဒီဇိုင်း၏ ရည်မှန်းချက်ဖြစ်ပြီး မည်သည့်ဟိုစ်ကမျှ လုံးဝ ထိုးဖောက်မခံရနိုင်ဟု အာမမခံနိုင်ပါ။
ဟုတ်ကဲ့။ ရန်ပုံသွင်းသူ (Registrar) နှင့် DNS တို့ကို သီးခြားစီ ခွဲထုတ်ထားပါသည်။ သင်၏ဒိုမိန်းကို လက်ရှိရန်ပုံသွင်းသူထံတွင်လည်းကောင်း၊ သင်၏ ဇုန် (zone) ကို လက်ရှိ DNS ပံ့ပိုးပေးသူထံတွင်လည်းကောင်း ဆက်လက်ထားရှိနိုင်ပြီး လက်အောက်ခံဒိုမိန်း (subdomain) ၏ မှတ်တမ်းကို ကျွန်ုပ်တို့ထံသို့ လွယ်ကူစွာ ညွှန်ပြနိုင်ပါသည်။ ဆိုက်ကို တိုက်ရိုက်အသုံးမပြုမီ ကိုယ်စားလှယ်လွှဲအပ်ခြင်းနှင့် လုပ်ဆောင်ချက်ကို ကျွန်ုပ်တို့က အတည်ပြုပေးသဖြင့် မှားယွင်းနေသော မှတ်တမ်းတစ်ခုသည် တိတ်တဆိတ်ပျက်ကွက်မသွားဘဲ ချက်ချင်းပေါ်လာမည်ဖြစ်သည်။ မိဘဒိုမိန်း၏ ဇုန်ကို ဤနေရာတွင် လက်ခံထားရှိပြီးဖြစ်ပါက လက်အောက်ခံဒိုမိန်း၏ မှတ်တမ်းကို သင့်အတွက် ၎င်းထဲသို့ ကျွန်ုပ်တို့ကိုယ်တိုင် ထည့်သွင်းပေးမည်ဖြစ်ရာ သင်ကိုယ်တိုင် ထပ်မံထည့်သွင်းရန် မလိုအပ်တော့ပါ။
ဖန်တီးထားသည့် ပုံစံတွင်သာ ကွာခြားမှု ရှိပါသည်။ တိုက်ရိုက်လွှင့်ထားသော ဝက်ဘ်ဆိုက်၏ ဖိုင်များနှင့် ဒေတာဘေ့စ် အပါအဝင် သီးခြားခွဲထုတ်ထားသည့် ကော်ပီတစ်ခုကို Staging သို့ ကလုန်းပွားခြင်း (Clone to staging) က ဖန်တီးပေးမည်ဖြစ်ပြီး ထိုသို့ပြုလုပ်ရာတွင် သက်ဆိုင်ရာ Staging ဒိုမိန်းခွဲသည် မူရင်းပတ်ဝန်းကျင်ကဲ့သို့ နည်းပညာစနစ်နှင့် ဘလူးပရင့် ဗားရှင်းအတိုင်း လုပ်ဆောင်မည် ဖြစ်သည်။ သင် စိတ်ကျေနပ်မှုရှိပါက တိုက်ရိုက်လွှင့်ခြင်းသို့ တွန်းပို့ခြင်း (push-to-live) က ဒေတာဘေ့စ်ကို ထည့်သွင်းစဉ်းစားပေးသည့် ရှာဖွေအစားထိုးမှုစနစ်ဖြင့် ပြန်လည် ချိတ်ဆက်ပေါင်းစည်းပေးမည် ဖြစ်သည်။ အခြားအရာအားလုံးဖြစ်သည့် သီးခြားခွဲထုတ်ထားမှု၊ SSL၊ ကက်ရှ်သိမ်းဆည်းမှု၊ ဘက်ခ်အပ်များနှင့် ဒေဗလော့ပါ ဝင်ရောက်သုံးစွဲခွင့်တို့သည် အခြား ဝက်ဘ်ဆိုက်များနည်းတူ ထပ်တူညီပါသည်။
ထိုအရာများကို သင်နှင့်အတူ ယူဆောင်သွားနိုင်ပါသည်။ ပလတ်ဖောင်း၏ မည်သည့်နေရာတွင်မျှ အကျအနွံချုပ်ဆိုထားခြင်း မရှိပါ - သင်သည် အတည်ပြုကုဒ်များကို ရယူခြင်း၊ ဒိုမိန်းများကို လော့ခ်ဖွင့်ပြီး အခြားသို့ လွှဲပြောင်းခြင်း၊ သင့်ကိုယ်ပိုင် CDN နှင့် DNS အကောင့်များကို အသုံးပြုခြင်းနှင့် သင့်ဝဘ်ဆိုက်များကို ထုတ်ယူခြင်းတို့ကို ပြုလုပ်နိုင်ပါသည်။ ကျွန်ုပ်တို့အသုံးပြုသော ပြင်ပဝန်ဆောင်မှုပေးသူ တိုင်းသည် လဲလှယ်အသုံးပြုနိုင်သည့် အဒက်ပတာနောက်ကွယ်တွင် ရှိနေပြီး၊ ဒါသည် ကျွန်ုပ်တို့အတွက်ရော သင့်အတွက်ပါ အတူတူပင်ဖြစ်ပါသည်။
သင်ထည့်သွင်းသည့် ဟို့စ်တိုင်းတစ်ခုချင်းစီတွင် အပြည့်အဝသီးသန့်ခွဲထုတ်မှု၊ ဝှိုင်းဒ်ကတ် SSL၊ တကယ့် DNS ထိန်းချုပ်မှုနှင့် တစ်ချက်နှိပ်ရုံဖြင့် စတေ့ဂျစ်တင်ခြင်းတို့ ပါဝင်ပါသည်။ ကတ်မလိုဘဲ ၁၄ ရက်ကြာ အခမဲ့စမ်းသပ်မှုကို စတင်ပြီး မဆုံးဖြတ်မီ မည်မျှအဆင်ပြေကြောင်း စစ်ဆေးကြည့်ပါ။
အခမဲ့ စတင်ပါ