Ubuntu ဗားရှင်းနှင့် architecture ကို စစ်ဆေးပါ
Ubuntu Linux VPS image ကို မမှာမီ application လိုအပ်ချက်နှင့် release၊ architecture ကို တိုက်စစ်ပါ။ ဖန်တီးပြီးနောက် တကယ်ရရှိသော OS၊ package candidate နှင့် application လုပ်ဆောင်ပုံကို ပြန်အတည်ပြုပါ။ ရွေးချယ်ထားသော image နှင့် လက်တွေ့စနစ် ကိုက်ညီကြောင်း သိနိုင်မည်။
VPSuntu · ပြင်ဆင်ရက် · ဖတ်ရန် 8 မိနစ်ခန့်
စာမျက်နှာအကြောင်းအရာ
Instance မဖန်တီးမီ image ကို ရွေးပါ
Application နှင့် extensions က ပံ့ပိုးသော OS၊ runtime၊ database နှင့် architecture ကို စာရင်းလုပ်ပါ။ Backup/monitoring agent ကိုပါ ထည့်ပါ။ ဝက်ဘ်ဆိုက်တက်နေသော်လည်း recovery tool မအလုပ်လုပ်နိုင်ပါ။ Vendor က ပံ့ပိုးကြောင်းနှင့် မိမိအဖွဲ့စမ်းဖူးရုံသာဖြစ်ကြောင်းကို ခွဲမှတ်ပါ။
- Application ပံ့ပိုးသော Ubuntu၊ runtime နှင့် database ဗားရှင်းများကို စာရင်းလုပ်ပါ။
- Native extension၊ container image နှင့် backup agent တိုင်း၏ architecture ကို စစ်ပါ။
- ကိုက်ညီသော release များ၏ လက်ကျန် maintenance အချိန်ကို နှိုင်းယှဉ်ပါ။
- လိုအပ်သော region တွင် provider က image နှင့် architecture ပေးနိုင်ကြောင်း အတည်ပြုပါ။
- ဖန်တီးပြီးနောက် အောက်မှ command များဖြင့် စစ်ကာ data/traffic မရွှေ့မီ application ကို စမ်းပါ။
Ubuntu 24.04 LTS ၏ မူလ major ဗားရှင်းဥပမာများမှာ Python 3.12၊ PHP 8.3 နှင့် PostgreSQL 16 ဖြစ်သည်။ Patch ဗားရှင်းများ ပြောင်းနိုင်သည်။ Major ဗားရှင်းဟောင်းတွင် အလုပ်လုပ်ခြင်းက ဗားရှင်းသစ်နှင့် ကိုက်ညီကြောင်း မပြပါ။ LTS maintenance ဇယား ကို ဖတ်ပြီး မိမိ stack နှင့် ကိုက်ညီမှုကို ဆုံးဖြတ်ပါ။
ရရှိသော image ကို အတည်ပြုပါ
VPS ထဲတွင် အောက်ပါ read-only command များဖြင့် distribution၊ လက်ရှိ kernel၊ package architecture နှင့် machine architecture ကို စစ်ပါ။ Software ထပ်မတပ်မီ deployment မှတ်တမ်းတွင် သိမ်းပါ။
cat /etc/os-release
uname -r
dpkg --print-architecture
uname -mမျက်နှာပြင်ငယ်တွင် ကော်လံအားလုံးကြည့်ရန် ဇယားကို ဘေးတိုက်ရွှေ့ပါ။
| ရလဒ် | အဓိပ္ပာယ် |
|---|---|
| /etc/os-release မှ VERSION_ID | တပ်ဆင်ထားသော Ubuntu release၊ ဥပမာ 24.04 |
| uname -r မှ kernel | လက်ရှိအသုံးပြုသော kernel၊ update/reboot နောက်တွင် ပြောင်းနိုင် |
| dpkg amd64 / uname x86_64 | 64-bit x86 အတွက် package/machine နာမည် |
| dpkg arm64 / uname aarch64 | 64-bit Arm အတွက် နာမည် |
Kernel စာသားတစ်ခုတည်းဖြင့် Ubuntu release သို့မဟုတ် support coverage မသိနိုင်ပါ။ Provider က cloud kernel သုံးနိုင်သည်။ amd64-only binary ကို arm64 တွင် native အဖြစ် ရမည်ဟု မယူဆပါနှင့်။ Arm build သို့မဟုတ် အတိအလင်းပံ့ပိုးသော အခြားနည်းရှိကြောင်း စစ်ပါ။
Image ကို ဘယ်လိုပြင်ဆင်ထားသလဲ စစ်ပါ
Image အများအပြားတွင် key၊ account နှင့် network ကို cloud-init ဖြင့် ပြင်သည်။ Status မမေးမီ တပ်ဆင်ထားသလား စစ်ပါ။ မရှိခြင်းတစ်ခုတည်းသည် fault မဟုတ်ပါ။ Provider ၏ provisioning နည်းကို ရှာပါ။
if command -v cloud-init >/dev/null 2>&1; then
cloud-init status --long
else
printf '%s\n' 'cloud-init is not installed; check the provider provisioning method.'
fiRunning ဆိုလျှင် ပြင်ဆင်ဆဲဖြစ်သည်။ SSH ဝင်ရသော်လည်း error/degraded ကို စုံစမ်းရမည်။ cloud-init ရှိပါက သက်ဆိုင်ရာ log များကို ကြည့်ပါ။
sudo tail -n 50 /var/log/cloud-init.log
sudo tail -n 50 /var/log/cloud-init-output.logInitialization script က လျှို့ဝှက်တန်ဖိုးများ ရိုက်ထုတ်နိုင်သဖြင့် log မမျှဝေမီ ဖယ်ရှားပါ။ Error ဖုံးရန် cloud-init clean မလုပ်ပါနှင့်၊ network files ကို မအစားထိုးပါနှင့်။ Provisioning ပြီးခြင်းသည် app၊ database သို့မဟုတ် backup အောင်မြင်ကြောင်း မပြပါ။ သီးခြားစစ်ပါ။
မတပ်ဆင်မီ package candidate ကို ကြည့်ပါ
Metadata refresh လုပ်ပြီး သုံးမည့် package candidate နှင့် repository ကို မှတ်ပါ။ Update command သည် package index ကိုသာ ပြန်ယူပြီး ဒီ application packages ကို မတပ်ဆင်ပါ။
sudo apt update
apt-cache policy python3 php postgresql
apt-cache policy python3.12 php8.3 postgresql-16Installed: (none) သည် package မရှိသေးကြောင်းဖြစ်သည်။ Candidate: (none) သည် လက်ရှိ source များက မပေးနိုင်ကြောင်းဖြစ်သည်။ အကြောင်းမသိ repository မထည့်မီ နာမည်၊ architecture နှင့် Ubuntu components ကို စစ်ပါ။
php နှင့် postgresql ကဲ့သို့ metapackage များသည် default implementation ကို ရွေးပေးသည်။ Version ပါသည့် package ကိုလည်း စစ်ပါ။ တပ်ဆင်ပြီး software အတွက် တကယ် run သော executable/service ကို စစ်ပါ။ python3 --version နှင့် php --version က executable ဗားရှင်းကို ပြသည်။ Database server နှင့် client tool ဗားရှင်း မတူနိုင်ပါ။
Compatibility ဆုံးဖြတ်ချက်တစ်ခုကို လက်တွေ့ကြည့်ပါ
Application တစ်ခုက Python 3.10 သာ ပံ့ပိုးပြီး native extension ကို amd64 အတွက်သာ ပေးသည်ဟု ယူဆပါ။ ထုတ်ကုန်တစ်ခု၏ တကယ့်လိုအပ်ချက်မဟုတ်ပါ။ Default Ubuntu 24.04 arm64 တွင် Python 3.12 ဖြစ်ပြီး extension architecture လည်း မတူသဖြင့် နှစ်ချက်မကိုက်ပါ။
amd64 ပြောင်းခြင်းက architecture ကိုသာ ဖြေရှင်းပြီး default Python ကို မပြောင်းပါ။ Virtual environment သည် ဖန်တီးပေးသော interpreter ဖြင့် package များကို သီးခြားထားခြင်းဖြစ်ပြီး Python 3.12 ကို 3.10 အဖြစ် မပြောင်းပေးပါ။ Application အတွက် Ubuntu system Python ကို မအစားထိုးပါနှင့်။
Application upgrade သို့မဟုတ် support plan ရှိသော သီးခြား runtime/container ကို စဉ်းစားပါ။ Native components အားလုံး platform ကို ပံ့ပိုးရမည်။ Ubuntu release ဟောင်းတွင် maintenance အချိန်လက်ကျန်ရှိသဖြင့် အလိုအလျောက်ဖြေရှင်းချက် မဟုတ်ပါ။
လက်ခံမီ staging တွင် extension code path၊ database operation၊ background job နှင့် backup/restore ကို စမ်းပါ။ Application build နှင့် ဗားရှင်းများကို မှတ်ပါ။ Install အောင်မြင်ခြင်း သို့မဟုတ် homepage တက်ခြင်းတစ်ခုတည်း မလုံလောက်ပါ။
Container နှင့် package support ကိုပါ စီစဉ်ပါ
Container သည် app dependencies ကို Ubuntu default packages မှ ခွဲထားသော်လည်း host kernel၊ storage နှင့် network ကို သုံးနေဆဲဖြစ်သည်။ မိမိ platform အတွက် supported image build ရှိကြောင်း စစ်ပါ။ Emulation သည် performance နှင့် support ယူဆချက်ကို ပြောင်းသဖြင့် native build အစား မသိမသာ မသုံးပါနှင့်။
Data ကို မှတ်တမ်းတင်ထားသော volume သို့မဟုတ် external storage တွင် သိမ်းပြီး disposable container မရှိဘဲ restore စမ်းပါ။ Release/digest ကို pin လုပ်ကာ update အချိန်စီစဉ်ပါ။ အားနည်းချက်ရှိသော image ကို အမြဲ pin ထားခြင်းသည် ပြန်ထုတ်လုပ်ရလွယ်သော်လည်း ထိန်းသိမ်းမှုမကောင်းပါ။
Ubuntu release support နှင့် package တစ်ခုချင်း coverage ကို ခွဲပါ။ Standard security maintenance နှင့် Ubuntu Pro မတူပါ။ Third-party repositories၊ downloaded binaries နှင့် container images တွင် သီးခြား maintainer ရှိသည်။ Layer တစ်ခုချင်းကို ဘယ်သူ update လုပ်မည် မှတ်ပါ။
ပုံမှန် update နှင့် release upgrade ကို ခွဲပါ
Package metadata ကို refresh လုပ်ပြီး pending packages နှင့် failed services ကို စစ်ပါ။ အောက်ပါ command များသည် အချက်အလက်စာရင်းသာ ပြပြီး distribution upgrade မလုပ်ပါ။
apt list --upgradable
systemctl --failed
if [ -f /var/run/reboot-required ]; then cat /var/run/reboot-required; fiသင့်လျော်သော maintenance window တွင် update ကို စိစစ်တပ်ဆင်ပြီး app စစ်ဆေးချက် ထပ်လုပ်ပါ။ Services ပြန်စနိုင်သည်။ Reboot marker ရှိလျှင် အသုံးဝင်သော်လည်း မရှိခြင်းက အားလုံးနောက်ဆုံးဗားရှင်းဖြစ်ကြောင်း မသက်သေပြပါ။
Release upgrade ကို copy သို့မဟုတ် instance အသစ်တွင် စမ်းပါ။ Runtime၊ repositories၊ database upgrade နှင့် extensions ကို ထပ်စစ်ပါ။ နောက်ဆုံး data sync နှင့် ပြောင်းပြီးနောက် write များကို ထည့်တွက်သော rollback လမ်းကြောင်း စီစဉ်ပါ။ Upgrade မတိုင်မီ snapshot တွင် နောက်ပိုင်း customer order မပါနိုင်ပါ။
ပြန်လုပ်နိုင်သော image မှတ်တမ်း ချန်ထားပါ
မျက်နှာပြင်ငယ်တွင် ကော်လံအားလုံးကြည့်ရန် ဇယားကို ဘေးတိုက်ရွှေ့ပါ။
| မှတ်တမ်း | သိမ်းရန် |
|---|---|
| Operating system | Release၊ architecture၊ kernel နှင့် image ID |
| Application | Build၊ runtime၊ lockfiles နှင့် repository origins |
| Provisioning | Result နှင့် လျှို့ဝှက်ချက်မပါသော config |
| Acceptance | စမ်းသည့် workflow၊ ရလဒ်နှင့် မဖြေရှင်းရသေးသော error |
| Maintenance | Package တာဝန်ရှိသူ၊ update window၊ alert လက်ခံသူ |
| Recovery | Backup တည်နေရာ၊ နည်းလမ်းနှင့် နောက်ဆုံး restore စမ်းသပ်ချိန် |
လျှို့ဝှက်ချက်များကို မှတ်တမ်းပြင်ပတွင် ထားပြီး non-secret configuration ကို version control သုံးပါ။ အဓိက dependency ပြောင်းလျှင် သီးခြား rebuild စမ်းပါ။ Public cloud စမ်းသပ်လိုလျှင် အခမဲ့ Ubuntu VPS ဖန်တီးနည်း၊ site တင်ရန် အဆင်သင့်ဖြစ်လျှင် deployment လမ်းညွှန် ကို ဆက်ပါ။
အမေးအဖြေ
Ubuntu 24.04 သည် အမြဲအကောင်းဆုံး image လား။
ဒီနေရာတွင် တိကျသောဥပမာအဖြစ် သုံးထားခြင်းဖြစ်သည်။ မိမိ stack နှင့် provider က ပံ့ပိုးသော supported release ကို ရွေးပြီး maintenance အချိန်ကို မှတ်ပါ။ ပိုသစ်သော သို့မဟုတ် ပိုဟောင်းသော release နှစ်မျိုးစလုံး app ပြင်ရန် လိုနိုင်သည်။
Data မပျောက်ဘဲ image ပြန်တင်နိုင်သလား။
Provider reinstall သည် ဆာဗာ disk ကို အများအားဖြင့် အစားထိုးသည်။ လုပ်ငန်းစဉ်ကို စစ်၊ data/config ကို export လုပ်ပြီး recovery အရင်စမ်းပါ။ Reinstall နှင့် in-place release upgrade မတူပါ။