عملی رہنمائی / Ubuntu ورژن اور آرکیٹیکچر

Ubuntu ورژن اور آرکیٹیکچر کی تصدیق کریں

Order سے پہلے Ubuntu image کو ایپ کے supported release اور architecture سے ملائیں۔ Instance ملنے کے بعد installed system، provisioning اور package candidates کی تصدیق کریں۔ Software install ہونا پورے ایپ کی مطابقت ثابت نہیں کرتا۔

· تازہ کاری · تقریباً 5 منٹ

اس مضمون میں

Image کا فیصلہ پورے stack سے کریں

ایپ، runtime، database، extensions، container images، monitoring اور backup agents کی supported versions لکھیں۔ Vendor support اور صرف اپنی ٹیم کے test کو الگ درج کریں۔ Maintenance window اور provider کے region/image انتخاب کو بھی دیکھیں۔

Ubuntu 24.04 کی release مثال میں default Python 3.12، PHP 8.3 اور PostgreSQL 16 شامل تھے۔ Patch versions updates سے بدلتے ہیں۔ پرانے major version کے لیے بنا software نئے version پر لازماً نہیں چلتا۔ LTS مدت کے ساتھ compatibility طے کریں۔

موصولہ system کی شناخت

VPS کے اندر یہ read-only commands distribution، چلتا kernel اور package/machine architecture بتاتی ہیں۔ مزید software سے پہلے نتیجہ deployment record میں محفوظ کریں۔

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

چھوٹی اسکرین پر باقی کالم دیکھنے کے لیے جدول کو پہلو میں اسکرول کریں۔

Outputمطلب
/etc/os-release کا VERSION_IDInstalled Ubuntu release، مثلاً 24.04
uname -rاس وقت چلنے والا kernel
dpkg میں amd64، uname میں x86_6464-bit x86 کے عام package اور machine نام
dpkg میں arm64، uname میں aarch6464-bit Arm کے عام نام

Kernel string اکیلی Ubuntu release یا support coverage نہیں بتاتی۔ Cloud-specific kernel ممکن ہے۔ amd64-only binary کو arm64 پر native طور پر چلتا فرض نہ کریں؛ supported build یا واضح alternative چاہیے۔

Provisioning کا نتیجہ دیکھیں

بہت سی images، keys، accounts اور networking کے لیے cloud-init استعمال کرتی ہیں۔ پہلے دیکھیں کہ وہ موجود ہے یا نہیں؛ غیر موجود ہونا اکیلا خرابی نہیں، 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.'
fi

Running کا مطلب setup جاری ہے۔ 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 logs میں حساس values آ سکتی ہیں؛ share کرنے سے پہلے redact کریں۔ Error چھپانے کے لیے cloud-init clean یا network files کی تبدیلی نہ کریں۔ Provisioning complete ہونا application، database یا backup job کی صحت کا ثبوت نہیں۔

Install سے پہلے package candidates جانچیں

Metadata تازہ کرکے مطلوبہ components کے candidate versions اور repositories دیکھیں۔ apt update index کو تازہ کرتا ہے؛ یہ نیچے listed application packages خود install نہیں کرتا۔

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

Installed: (none) package کی عدم موجودگی ہے؛ Candidate: (none) کا مطلب موجودہ sources میں candidate نہیں۔ نام، architecture اور Ubuntu components پہلے دیکھیں؛ فوراً نامعلوم repository نہ شامل کریں۔

php/postgresql جیسے metapackages default implementation چنتے ہیں۔ Versioned package اور actual executable/service بھی جانچیں۔ Client tool کی version، database server سے مختلف ہو سکتی ہے۔

مطابقت کی ایک مثال حل کریں

فرض کریں ایپ صرف Python 3.10 اور amd64 native extension support کرتا ہے؛ یہ کسی خاص product کا دعویٰ نہیں۔ Default Ubuntu 24.04 arm64 دو checks میں نہیں بیٹھتا: Python 3.12 اور مختلف architecture۔

amd64 لینے سے architecture درست ہوتا ہے، Python نہیں۔ Virtual environment اسی interpreter کے packages الگ کرتا ہے؛ 3.12 کو 3.10 نہیں بناتا۔ ایپ کی خاطر Ubuntu کا system Python replace نہ کریں۔

ایپ upgrade، الگ maintained runtime/container یا مناسب supported release دیکھیں۔ پرانا Ubuntu خودکار حل نہیں؛ اس کی باقی maintenance بھی دیکھیں۔ Staging میں extension code path، database operation، background job اور backup/restore آزمائیں۔ صرف installation یا homepage response کافی نہیں۔

Containers اور package support کا الگ حساب

Container dependencies الگ رکھتا ہے مگر host kernel، storage اور networking استعمال کرتا ہے۔ اپنی platform کا supported image build دیکھیں۔ Emulation کے performance/support فرق کو خاموشی سے native build کا بدل نہ سمجھیں۔

Data کو documented volumes یا external storage میں رکھیں اور disposable containers سے الگ restore کریں۔ Releases/digests pin کرنے کے ساتھ updates schedule کریں؛ پرانا vulnerable image مستقل pin رکھنا maintenance نہیں۔

Ubuntu release support، ہر package کی coverage نہیں۔ Standard security maintenance، Ubuntu Pro، third-party repositories، binaries اور containers کے maintainers الگ ہو سکتے ہیں۔ ہر layer کا update ذمہ دار لکھیں۔

معمول کی updates اور release upgrade الگ رکھیں

پہلے metadata تازہ کریں، pending packages اور failed services پڑھیں۔ یہ commands معلومات دیتی ہیں؛ distribution upgrade نہیں چلاتیں۔

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

مناسب maintenance window میں updates پڑھ کر apply کریں اور ایپ دوبارہ جانچیں؛ services restart ہو سکتی ہیں۔ Reboot marker موجود ہو تو مفید ہے، غیر موجود ہونا مکمل تازگی کا ثبوت نہیں۔

Release upgrade پہلے copy یا نئی machine پر آزمائیں۔ Runtime، repositories، database migration اور extensions پھر جانچیں۔ Final sync اور واپسی کا طریقہ بعد کی writes بھی سنبھالے؛ پہلے snapshot میں بعد کے customer orders شامل نہیں ہوتے۔

دوبارہ بنایا جا سکنے والا record چھوڑیں

چھوٹی اسکرین پر باقی کالم دیکھنے کے لیے جدول کو پہلو میں اسکرول کریں۔

حصہکیا محفوظ کریں
Operating systemRelease، architecture، kernel، image identifier
ApplicationBuild، runtime، lockfiles، repositories
Provisioningنتیجہ اور غیر حساس configuration
AcceptanceTested workflows، نتائج، باقی failures
MaintenanceUpdate owner، window، alert recipient
RecoveryBackup location، procedure، آخری verified restore

Secrets اس record سے باہر رکھیں۔ غیر حساس configuration version control میں رکھیں۔ اہم dependencies بدلیں تو الگ rebuild کریں۔ Public experiment کے لیے Oracle Ubuntu setup، اور compatible image پر پہلی site کے لیے deployment طریقہ استعمال کریں۔

سوال جواب

کیا Ubuntu 24.04 ہمیشہ بہترین انتخاب ہے؟

یہ یہاں عملی مثال ہے۔ وہ maintained release چنیں جسے پورا stack اور provider support کرتے ہوں، اور باقی support مدت لکھیں۔ نئی اور پرانی دونوں releases میں app changes درکار ہو سکتی ہیں۔

کیا image بدلنے سے data محفوظ رہتا ہے؟

Provider reinstall عموماً disk بدل سکتا ہے۔ پہلے procedure، export اور verified recovery دیکھیں۔ Reinstall اور in-place release upgrade الگ کام ہیں۔

Ubuntu package families documented مثالیں ہیں۔ Target image کے موجودہ candidates اور اپنے application کی مطابقت الگ جانچیں؛ یہاں compatibility test کرنے کا دعویٰ نہیں۔

اصل تکنیکی دستاویزات

متعلقہ رہنما مضامین