កំណែនិងស្ថាបត្យកម្ម Ubuntu សម្រាប់ VPS

ផ្គូផ្គង image ជាមួយតម្រូវការកម្មវិធី

រាយប្រព័ន្ធប្រតិបត្តិការ runtimes, databases និង architectures ដែលកម្មវិធីនិង extensions គាំទ្រ។ រាប់ backup និង monitoring agents ផង៖ គេហទំព័រអាចដំណើរការ តែឧបករណ៍សង្គ្រោះចាំបាច់អាចមិនដំណើរការ។ បែងចែកការគាំទ្រផ្លូវការពីអ្វីដែលក្រុមអ្នកបានសាកល្បងប៉ុណ្ណោះ។

1. កត់ Ubuntu release, runtime និង database versions ដែលកម្មវិធីគាំទ្រ។
2. ពិនិត្យ architecture របស់ native extensions, container images និង backup agents ។
3. ជ្រើសកំណែដែលត្រូវគ្នា ហើយមានពេល maintenance នៅសល់សមស្រប។
4. បញ្ជាក់ថាអ្នកផ្ដល់សេវាមាន image និង architecture នោះក្នុងតំបន់ដែលត្រូវការ។
5. ក្រោយបង្កើត ផ្ទៀងផ្ទាត់តាមពាក្យបញ្ជា ហើយសាកល្បងកម្មវិធីមុនផ្ទេរទិន្នន័យ។

Ubuntu 24.04 LTS ជាឧទាហរណ៍៖ ពេលចេញមាន Python 3.12 ជាលំនាំដើម, PHP 8.3 និង PostgreSQL 16។ Patch versions ប្រែប្រួលតាម updates ។ កម្មវិធីដែលគាំទ្រ major version ចាស់មិនស្មើថាគាំទ្រថ្មីទេ។ មើលតារាងរយៈពេល LTS; នៅទីនេះត្រូវសម្រេចថា stack ត្រូវគ្នាឬអត់។

កំណត់អត្តសញ្ញាណ image ដែលទទួលបាន

រត់ពាក្យបញ្ជាអានតែប៉ុណ្ណោះខាងក្រោមក្នុង VPS ។ វាបង្ហាញ distribution, kernel ដែលកំពុងរត់, package architecture និង machine architecture ។ រក្សាលទ្ធផលជាមួយកំណត់ត្រាដំឡើងមុនបន្ថែមកម្មវិធី។

cat /etc/os-release
uname -r
dpkg --print-architecture
uname -m

លើអេក្រង់តូច អូសតារាងទៅចំហៀងដើម្បីមើលគ្រប់ជួរឈរ។

Kernel string តែឯងមិនប្រាប់ Ubuntu release ឬ support coverage ទេ។ អ្នកផ្ដល់សេវាអាចប្រើ cloud kernel ។ កុំសន្មតថា binary សម្រាប់ amd64 អាចរត់ native លើ arm64; បញ្ជាក់ Arm build ឬជម្រើសដែលគាំទ្រជាក់លាក់សិន។

ពិនិត្យការរៀបចំ image ដំបូង

Images ជាច្រើនប្រើ cloud-init ដើម្បីដាក់ keys បង្កើតគណនី និងកំណត់បណ្តាញ។ ពិនិត្យថាមាន cloud-init មុនសួរ status ។ អវត្តមានវាមិនមែនជាកំហុសដោយខ្លួនឯងទេ; ត្រូវដឹងវិធី 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.'
fi

Running មានន័យថាកំពុងរៀបចំ។ Error ឬ degraded ត្រូវស៊ើបអង្កេត ទោះ SSH ប្រើបានក៏ដោយ។ បើមាន cloud-init ពិនិត្យ logs ៖

sudo tail -n 50 /var/log/cloud-init.log
sudo tail -n 50 /var/log/cloud-init-output.log

Initialization scripts អាចបោះពុម្ពទិន្នន័យសម្ងាត់; លាក់វាមុនចែករំលែក logs ។ កុំរត់ cloud-init clean ឬជំនួស network files ដើម្បីលាក់កំហុស។ Provisioning ចប់ក៏មិនធានាថា app, database ឬ backup job មានសុខភាពល្អទេ; ពិនិត្យដាច់ដោយឡែក។

ពិនិត្យ package candidates មុនដំឡើង

Refresh metadata រួចមើល candidates សម្រាប់ components ដែលត្រូវប្រើ។ Update នៅទីនេះធ្វើបច្ចុប្បន្នភាព index ដោយមិនដំឡើង application packages ទាំងនេះ។ កត់កំណែនិង repositories ប្រភព។

sudo apt update
apt-cache policy python3 php postgresql
apt-cache policy python3.12 php8.3 postgresql-16

Installed: (none) មានន័យថាមិនទាន់ដំឡើង។ Candidate (none) មានន័យថាប្រភព packages បច្ចុប្បន្នមិនផ្ដល់វា។ ពិនិត្យឈ្មោះ architecture និង Ubuntu components មុនបន្ថែម repository មិនស្គាល់។

Metapackages ដូចជា php និង postgresql ជ្រើស implementation លំនាំដើម; មើល versioned package ផង។ សម្រាប់ software ដែលមានរួច ពិនិត្យ executable ឬ service ពិត។ python3 --version និង php --version ប្រាប់កំណែ executable; database server អាចខុសពី client tools ។

សាកល្បងសេចក្ដីសម្រេចអំពីភាពត្រូវគ្នា

ឧទាហរណ៍សន្មត៖ app គាំទ្រតែ Python 3.10 ហើយ native extension មានតែ amd64។ នេះមិនមែនអះអាងអំពីផលិតផលណាមួយទេ។ Ubuntu 24.04 arm64 លំនាំដើមខុសពីតម្រូវការពីរ៖ Python 3.12 និង architecture មិនត្រូវ។

ប្ដូរទៅ amd64 ដោះស្រាយតែ architecture ។ Virtual environment ប្រើ interpreter ដែលបង្កើតវា; វាមិនបម្លែង Python 3.12 ទៅ 3.10 ទេ។ កុំជំនួស system Python របស់ Ubuntu ដើម្បីបំពេញ app ។

អាច upgrade app ឬជ្រើស runtime/container ដែលថែទាំដាច់ដោយឡែកនិងមានផែនការគាំទ្រ។ បញ្ជាក់ native components ទាំងអស់លើ platform គោលដៅ។ Ubuntu ចាស់មាន maintenance window ផ្ទាល់ ហើយមិនមែនជាដំណោះស្រាយស្វ័យប្រវត្តិ។

ក្នុង staging សាកល្បង code path របស់ extension, database operation, background job និង backup/restore cycle ។ កត់ versions និង build ។ ដំឡើងបានឬបើកទំព័រដើមបានមួយដងមិនគ្រប់គ្រាន់ទេ។

រាប់ containers និងការគាំទ្រ packages ក្នុងផែនការ

Containers បំបែក app dependencies ពី default packages របស់ Ubuntu ប៉ុន្តែពឹង host kernel, storage និង network ។ ពិនិត្យ image build ដែលគាំទ្រ platform របស់អ្នក។ Emulation ផ្លាស់ប្ដូរសន្មត performance និង support; កុំប្រើជំនួស native build ដោយមិនបានវាយតម្លៃ។

រក្សាទិន្នន័យក្នុង volumes តាមឯកសារ ឬ storage ខាងក្រៅ ហើយហាត់ស្ដារដោយមិនពឹង container បណ្ដោះអាសន្ន។ Pin release ឬ image digest ដើម្បីបង្កើតឡើងវិញបាន តែត្រូវរៀបចំ updates ផង។ Image ចាស់មានភាពងាយរងគ្រោះដែល pin ជារៀងរហូតមិនមែន maintenance ល្អទេ។

បែងចែក Ubuntu release support ពី coverage របស់ package នីមួយៗ។ Standard security maintenance និង Ubuntu Pro មាន coverage ខុសគ្នា។ Third-party repositories, downloaded binaries និង container images មានអ្នកថែទាំផ្ទាល់។ កត់អ្នកទទួលខុសត្រូវរាល់ layer ។

បែងចែក package updates ពី release upgrade

Refresh metadata ហើយពិនិត្យ packages កំពុងរង់ចាំ និង services បរាជ័យ។ ពាក្យបញ្ជាទាំងនេះរាយព័ត៌មាន មិនធ្វើ distribution upgrade ទេ។

apt list --upgradable
systemctl --failed
if [ -f /var/run/reboot-required ]; then cat /var/run/reboot-required; fi

ពិនិត្យនិងអនុវត្ត updates ក្នុង maintenance window សមស្រប រួចសាកល្បង app ម្ដងទៀត។ Services អាច restart ។ Reboot marker មានប្រយោជន៍ពេលមាន; បើគ្មានវា ក៏មិនបញ្ជាក់ថាគ្រប់ component ថ្មីរួចទេ។

សាកល្បង release upgrade លើច្បាប់ចម្លងឬម៉ាស៊ីនថ្មី។ ពិនិត្យ runtimes, repositories, database upgrade និង extensions ឡើងវិញ។ រៀបចំ final sync និងផ្លូវត្រឡប់ដែលគិតដល់ writes ក្រោយប្ដូរ។ Snapshot មុន upgrade មិនអាចមាន orders ដែលមកក្រោយទេ។

រក្សាកំណត់ត្រាដែលអ្នកផ្សេងអាចអនុវត្តឡើងវិញ

លើអេក្រង់តូច អូសតារាងទៅចំហៀងដើម្បីមើលគ្រប់ជួរឈរ។

រក្សា secrets នៅក្រៅកំណត់ត្រា ហើយ version-control តែ config មិនសម្ងាត់។ បង្កើតឡើងវិញលើម៉ាស៊ីនផ្សេងពេល dependencies សំខាន់ប្ដូរ។ សម្រាប់ cloud experiment មើលការបង្កើត Oracle Ubuntu VPS។ ពេល image ត្រូវគ្នា ប្រើមគ្គុទ្ទេសក៍ដាក់គេហទំព័រ។

សំណួរនិងចម្លើយ

ឯកសារយោងផ្លូវការ

1. ឯកសារ 1៖ discourse.ubuntu.com
2. ឯកសារ 2៖ ubuntu.com
3. ឯកសារ 3៖ docs.cloud-init.io
4. ឯកសារ 4៖ manpages.ubuntu.com
5. ឯកសារ 5៖ docs.python.org
6. ឯកសារ 6៖ ubuntu.com