Ubuntu वर्जन और आर्किटेक्चर की जाँच करें
Ubuntu image चुनने से पहले release और architecture को ऐप की requirements से मिलाएँ। Provisioning के बाद जाँचें कि वास्तव में कौन-सा system और package versions मिले हैं। सफल installation पूरे ऐप की compatibility का प्रमाण नहीं है।
VPSuntu · अपडेट · लगभग 5 मिनट में पढ़ें
इस गाइड में
Order से पहले पूरी compatibility सूची बनाएँ
ऐप के साथ runtime, database, native extensions, backup और monitoring agents भी देखें। Vendor-supported और केवल आपकी टीम द्वारा tested configurations में फर्क लिखें। Provider को चुनी image और architecture उसी region में उपलब्ध करानी चाहिए।
Ubuntu 24.04 का documented उदाहरण Python 3.12 default, PHP 8.3 और PostgreSQL 16 families है; patch versions updates से बदलती हैं। पुराने major version के लिए बना software अपने आप compatible नहीं होता। LTS maintenance की तालिका देखकर समर्थित releases सीमित करें, फिर ऐप जाँचें।
मिला हुआ image पहचानें
ये read-only commands VPS के भीतर distribution, running kernel और package/machine architecture बताती हैं। Installation से पहले इन्हें deployment record में रखें।
cat /etc/os-release
uname -r
dpkg --print-architecture
uname -mछोटी स्क्रीन पर सभी कॉलम देखने के लिए तालिका को बगल में स्क्रॉल करें।
| Output | अर्थ |
|---|---|
| /etc/os-release का VERSION_ID | Installed Ubuntu release, जैसे 24.04 |
| uname -r | अभी चल रहा kernel |
| dpkg में amd64 / uname में x86_64 | 64-bit x86 के package और machine नाम |
| dpkg में arm64 / uname में aarch64 | 64-bit Arm के सामान्य नाम |
Kernel string से अकेले Ubuntu release या support coverage तय नहीं होती। Cloud-specific kernel हो सकता है। amd64-only binary के लिए Arm build या स्पष्ट supported alternative चाहिए।
cloud-init की स्थिति और logs देखें
कई images key, user और networking के लिए cloud-init इस्तेमाल करती हैं। पहले देखें कि यह मौजूद है या नहीं। अनुपस्थित होना अकेले error नहीं; 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 का अर्थ initialization जारी है। Error/degraded को SSH चलने पर भी जाँचें। उपलब्ध होने पर संबंधित logs देखें।
sudo tail -n 50 /var/log/cloud-init.log
sudo tail -n 50 /var/log/cloud-init-output.logInitialization logs में secrets आ सकते हैं; साझा करने से पहले हटाएँ। Error छिपाने के लिए cloud-init clean या network files बदलना उचित नहीं। Completed provisioning के बाद भी app, database और backup job की अपनी जाँच चाहिए।
Install करने से पहले package candidates देखें
Metadata refresh करें, फिर आवश्यक components के candidates और repository origins पढ़ें। apt update index refresh करता है; नीचे listed application packages अपने आप install नहीं करता।
sudo apt update
apt-cache policy python3 php postgresql
apt-cache policy python3.12 php8.3 postgresql-16Installed: (none) का मतलब package installed नहीं है। Candidate: (none) का मतलब वर्तमान sources में candidate नहीं मिल रहा। पहले package नाम, architecture और Ubuntu components देखें; अनजाना repository तुरंत न जोड़ें।
php/postgresql जैसे metapackages default implementation चुनते हैं। Versioned package और असली executable/service भी देखें। Client version database server के version से अलग हो सकता है।
Compatibility का एक निर्णय लें
मानें कि hypothetical ऐप केवल Python 3.10 और amd64 extension support करता है। Ubuntu 24.04 arm64 default image में Python और architecture दोनों mismatches होंगे। amd64 चुनना केवल दूसरे mismatch को हल करता है।
Virtual environment उसी interpreter से बनता है जिसे आप चलाते हैं; Python 3.12 को 3.10 नहीं बनाता। Ubuntu का system Python replace न करें। ऐप upgrade या अलग maintained runtime/container चुनें और हर native dependency का समर्थन देखें। पुराने Ubuntu की बाकी support अवधि भी जाँचें।
Staging में extension का असली code path, database operation, background job और backup/restore चलाएँ। App build और versions दर्ज करें; केवल home page खुलना पर्याप्त नहीं।
Containers और maintenance को साथ सोचें
Container application dependencies अलग रखता है, लेकिन host kernel, storage और network साझा हैं। अपनी architecture का supported image चुनें। Emulation performance/support बदलती है; इसे native build का चुपचाप विकल्प न मानें।
Data को documented volumes या external storage में रखें और disposable container से अलग restore जाँचें। Version/digest pinning के साथ updates भी निर्धारित करें। Ubuntu release का support हर third-party package, binary या image को अपने आप cover नहीं करता।
Routine update और release upgrade अलग करें
Refresh के बाद pending packages और failed services पढ़ें। यह block distribution upgrade नहीं चलाता।
apt list --upgradable
systemctl --failed
if [ -f /var/run/reboot-required ]; then cat /var/run/reboot-required; fiMaintenance window में updates लागू करके app checks दोहराएँ; services restart हो सकती हैं। Reboot marker न होना सभी components current होने का प्रमाण नहीं।
Release upgrade पहले copy या नई machine पर जाँचें। Runtime, repositories, extensions और database migration देखें। Final data sync और वापसी का रास्ता बाद में आने वाले writes को भी संभाले; पुराने snapshot में बाद के orders नहीं होते।
दोहराने योग्य deployment record रखें
OS release, architecture, kernel, image identifier, app build, runtime, lockfiles, repositories और acceptance results लिखें। Secrets record से बाहर रखें। किस layer को कौन update करेगा और आखिरी सफल restore कब हुआ, यह भी दर्ज करें।
Image सही हो तो पहली HTTPS वेबसाइट तैयार करें। नया cloud experiment करना हो तो Oracle Ubuntu setup पढ़ें।
सवाल-जवाब
क्या 24.04 ही हमेशा सही release है?
यहाँ वह concrete example है। वही supported release चुनें जिसे पूरा stack और provider support करते हों। नया या पुराना release, दोनों ऐप में बदलाव माँग सकते हैं।
क्या image बदलने पर डेटा बचता है?
Provider reinstall अक्सर server disk बदल देता है। पहले procedure, export और verified restore देखें। Reinstall और in-place release upgrade अलग operations हैं।