Ubuntu આવૃત્તિ અને architecture કેવી રીતે પસંદ કરશો?

Provisioning પહેલાં appની જરૂરિયાત લખો

Application કયા runtime, database, extension, control panel અને architectureને support કરે છે તે નોંધો. Build અને recovery પદ્ધતિ પણ તપાસો. Ubuntu 24.04 સાથે મૂળ Python 3.12, PHP 8.3 અને PostgreSQL 16 આવ્યા હતા; હાલના patch versions repository પ્રમાણે બદલાય છે.

પ્રદાતા કઈ image આપે છે અને તેનો support કેટલો બાકી છે તે જુઓ. માત્ર releaseનું નામ આખી image અથવા packagesની સ્થિતિ જણાવતું નથી. LTS સરખામણીમાં sourceમાં નોંધાયેલી maintenance dates છે.

મળેલી imageની ઓળખ કરો

Server પર આ read-only commandsથી release, kernel અને architecture તપાસો:

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

નાની સ્ક્રીન પર બધા કૉલમ જોવા કોષ્ટકને આડું સરકાવો.

Kernel string એકલી Ubuntu release કે support coverage સાબિત કરતી નથી. Provider cloud-specific kernel વાપરી શકે છે. Amd64-only binary arm64 પર native ચાલે એમ ન માનો; Arm build અથવા સ્પષ્ટ રીતે supported વિકલ્પ તપાસો.

Image કેવી રીતે તૈયાર થઈ તે તપાસો

ઘણી images keys, accounts અને networking માટે 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.'
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 scripts logsમાં sensitive values લખી શકે છે; શેર કરતાં પહેલાં ઢાંકો. Error છુપાવવા cloud-init clean ચલાવશો નહીં કે network files બદલશો નહીં. Provisioning પૂર્ણ થવું app, database અથવા backup jobની તંદુરસ્તીનો પુરાવો નથી.

Install કરતાં પહેલાં package candidates જુઓ

Metadata refresh કરીને ઉપયોગી packagesના candidates અને repository નોંધો. આ commands application packages install કરતા નથી.

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

Installed: (none) એટલે package install નથી. Candidate: (none) એટલે હાલના package sources તેને આપતા નથી. કોઈ પણ repository ઉમેરતાં પહેલાં નામ, architecture અને Ubuntu components તપાસો.

Php અને postgresql જેવા metapackages default implementation પસંદ કરે છે; versioned package પણ જુઓ. Install થયેલી software માટે actual executable અથવા running service તપાસો. python3 --version અને php --version તે executable બતાવે છે; database server અને client toolsની versions જુદી હોઈ શકે.

Compatibilityનો નિર્ણય ઉદાહરણથી સમજો

માનો appને માત્ર Python 3.10 જોઈએ અને native extension માત્ર amd64 માટે મળે છે. આ કલ્પિત જરૂરિયાત છે, કોઈ નામવાળી product વિશેનો દાવો નથી. Default Ubuntu 24.04 arm64 બે રીતે ન મળે: Python 3.12 છે અને extensionનું architecture જુદું છે.

Amd64 પસંદ કરવાથી architecture સુધરે, Python default નહીં. Virtual environment બનાવનાર interpreter જ વાપરે છે; તે Python 3.12ને 3.10માં ફેરવતું નથી. App માટે Ubuntuનું system Python બદલો નહીં.

App upgrade, અથવા અલગ રીતે maintained runtime/container જેવા વિકલ્પ તપાસો અને support plan રાખો. બધા native componentsનું platform support ચકાસો. જૂની Ubuntu releaseને પોતાની બાકી maintenance window હોય છે; તે આપોઆપ ઉકેલ નથી.

Stagingમાં extensionનો actual code path, database operation, background job અને backup/restore અજમાવો. Versions અને app build નોંધો. Install સફળ અથવા homepage ખુલે એટલાથી compatibility સાબિત થતી નથી.

Containers અને package supportનો પણ હિસાબ રાખો

Container app dependencies અલગ રાખે છે, પણ host kernel, storage અને network પર આધારિત છે. તમારા platform માટે supported image build તપાસો. Emulation performance અને support assumptions બદલે છે; તેને native buildનો ચૂપચાપ વિકલ્પ ન બનાવો.

Data documented volumes અથવા external storageમાં રાખો અને disposable containerથી સ્વતંત્ર રીતે restore અજમાવો. Repeatable build માટે releases અથવા image digests pin કરો, સાથે updatesનું આયોજન રાખો. Vulnerable image કાયમ pin રાખવી યોગ્ય જાળવણી નથી.

Ubuntu release support અને દરેક packageની coverage અલગ છે. Standard security maintenance અને Ubuntu Proની coverage જુદી છે. Third-party repositories, downloaded binaries અને container imagesના પોતાના maintainers હોય છે. દરેક layer કોણ update કરે છે તેની નોંધ રાખો.

સામાન્ય update અને release upgrade અલગ રાખો

Package metadata refresh પછી pending updates અને 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માં review કરીને updates લગાવો અને app checks ફરી કરો. Services restart થઈ શકે છે. Reboot marker હોય તો ઉપયોગી છે; ન હોય એટલે બધું current છે એમ નહીં.

Release upgrade copy અથવા નવી machine પર અજમાવો. Runtimes, repositories, database upgrade અને extensions ફરી તપાસો. Final data sync અને નવા writesને ધ્યાનમાં રાખતો rollback રાખો. Upgrade પહેલાંના snapshotમાં પછીના customer orders નથી હોતા.

ફરી બનાવી શકાય તેવી image નોંધ રાખો

નાની સ્ક્રીન પર બધા કૉલમ જોવા કોષ્ટકને આડું સરકાવો.

નોંધમાં secrets ન રાખો; non-secret configuration version-controlમાં રાખો. મહત્વની dependencies બદલાય ત્યારે અલગથી rebuild તપાસો. Public cloud experiment માટે Ubuntu instance સેટઅપ અને image યોગ્ય હોય પછી HTTPS deployment વાંચો.

પ્રશ્નો અને જવાબો

દસ્તાવેજો અને સ્રોતો

• સ્રોત: Ubuntu 24.04 release notes
• સ્રોત: Ubuntu release lifecycle
• સ્રોત: cloud-init status documentation
• સ્રોત: Ubuntu dpkg manual
• સ્રોત: Python virtual environments
• સ્રોત: Ubuntu package management