Ubuntu imajı seçimi: Sürümden paketlere kontrol listesi

Siparişten önce uyumluluk listesini hazırlayın

İşletim sistemi, runtime, veritabanı ve eklentilerin desteklediği sürümleri yazın. İzleme ve yedek araçlarını unutmayın. Üretici tarafından desteklenme ile kendi ekibinizin denemesini ayrı kaydedin.

1. Uygulamanın desteklediği Ubuntu, runtime ve veritabanı sürümlerini listeleyin.
2. Yerel eklenti, container ve yedek araçlarının mimarisini kontrol edin.
3. Uyumlu seçenekleri kalan bakım süresine göre daraltın.
4. Sağlayıcının gereken bölgede bu imaj ve mimariyi sunduğunu doğrulayın.
5. Kurulumdan sonra aşağıdaki kontrolleri yapın; veri ve trafiği taşımadan uygulamayı sınayın.

Ubuntu 24.04 örneği varsayılan Python 3.12, PHP 8.3 ve PostgreSQL 16 ailelerini getirdi; düzeltme sürümleri güncellemeyle değişir. Eski ana sürümü destekleyen uygulama yenisine otomatik olarak uyumlu değildir. LTS bakım tablosunu bu uyumluluk kararıyla birlikte kullanın.

Teslim edilen sistemi belirleyin

Aşağıdaki salt okunur komutları VPS içinde çalıştırın. Dağıtım, çalışan çekirdek, paket mimarisi ve makine mimarisini kaydedin.

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

Diğer sütunlar için tabloyu yana kaydırın →

Çekirdek adı tek başına Ubuntu sürümünü veya bakım kapsamını göstermez. Buluta özgü çekirdek bulunabilir. Yalnızca amd64 sunulan ikili dosya için Arm derlemesini veya açıkça desteklenen alternatifi doğrulamadan arm64 seçmeyin.

İlk yapılandırmanın durumunu inceleyin

Birçok imaj anahtar, kullanıcı ve ağı cloud-init ile hazırlar. Önce kurulu olup olmadığını kontrol edin. Yokluğu tek başına hata değildir; sağlayıcının imajı nasıl hazırladığını belirleyin.

if command -v cloud-init >/dev/null 2>&1; then
    cloud-init status --long
else
    printf '%s\n' 'cloud-init kurulu değil; sağlayıcının ilk yapılandırma yöntemini kontrol edin.'
fi

Running durumu işlemin devam ettiğini gösterir. Error veya degraded durumunda SSH çalışsa bile nedeni araştırın. cloud-init varsa ilgili günlükleri inceleyin.

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

Başlatma scriptleri gizli değerleri günlüğe yazabilir; paylaşmadan temizleyin. Hatayı gizlemek için cloud-init clean çalıştırmayın veya ağ dosyalarını değiştirmeyin. İlk yapılandırmanın tamamlanması uygulama ve yedek işinin sağlıklı olduğunu kanıtlamaz.

Paket adaylarını yüklemeden önce kontrol edin

Paket listesini yenileyip kullanacağınız bileşenlerin aday sürümlerini ve depolarını inceleyin. apt update bu uygulama paketlerini kurmaz.

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

Installed: (none) paketin kurulu olmadığını; Candidate: (none) ise mevcut kaynaklarda aday bulunmadığını gösterir. Rastgele depo eklemek yerine paket adı, mimari ve Ubuntu bileşenlerini kontrol edin.

php ve postgresql gibi metapaketler varsayılan uygulamayı seçer; sürümlü paketi de inceleyin. Kurulu yazılımda gerçek çalıştırılabilir dosyayı veya çalışan servisi kontrol edin. python3 --version ve php --version ilgili dosyayı gösterir; veritabanı istemcisiyle sunucu sürümü farklı olabilir.

Örnek bir uyumluluk kararını çözün

Varsayımsal bir uygulama yalnızca Python 3.10 desteklesin ve yerel eklentisini yalnızca amd64 için sunsun. Varsayılan Ubuntu 24.04 arm64 imajı iki kontrolü geçemez: Python 3.12 gelir ve eklenti başka mimaridedir. Bu, belirli bir ürün hakkında iddia değildir.

amd64 imaja geçmek mimariyi çözer, varsayılan Python’u değiştirmez. Sanal ortam, oluşturulduğu yorumlayıcıyla paketleri ayırır; Python 3.12’yi 3.10’a dönüştürmez. Uygulama uğruna Ubuntu’nun sistem Python’unu değiştirmeyin.

Uygulamayı yükseltmek veya belgelenmiş bakım planı olan ayrı runtime/container seçmek seçenek olabilir. Bütün yerel bileşenleri doğrulayın. Eski Ubuntu sürümünün de kalan bakım süresi vardır; otomatik çözüm değildir.

Testte eklentinin gerçekten kullanıldığı yolu, veritabanı işlemini, arka plan işini ve yedek/geri yüklemeyi sınayın. Sürümleri ve uygulama derlemesini kaydedin. Yalnızca kurulumun veya ana sayfanın başarılı olması yeterli değildir.

Container ve paket bakımını ayrı planlayın

Container bağımlılıkları ayırır, fakat ana sistemin çekirdek, depolama ve ağına dayanır. Platforma uygun imaj seçin. Emülasyonun performans ve destek varsayımlarını doğal çalışmayla aynı saymayın.

Kalıcı verileri belgelenmiş volume veya dış depoda tutup bağımsız geri yükleyin. Sürüm veya digest sabitlemek tekrar üretilebilirlik sağlar; güncelleme takvimiyle birlikte kullanılmalıdır. Açığı olan bir imajı sürekli sabit tutmak iyi bakım değildir.

Ubuntu standart güvenlik bakımı, Ubuntu Pro, üçüncü taraf depolar, indirilmiş ikili dosyalar ve container imajları farklı bakım kapsamlarına sahiptir. Her katmanı kimin güncelleyeceğini belirleyin.

Paket güncellemesini sürüm yükseltmesinden ayırın

Paket listesini yenileyin, bekleyen paketleri ve başarısız servisleri görün. Aşağıdaki komutlar dağıtım yükseltmesi yapmaz.

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

Bakım zamanında güncellemeleri gözden geçirip uygulayın ve uygulama kontrollerini tekrarlayın. Servisler yeniden başlayabilir. Reboot işareti varsa anlamlıdır; yokluğu bütün bileşenlerin güncel olduğunu kanıtlamaz.

Ubuntu sürüm yükseltmesini kopya veya yeni makinede deneyin. Depolar, runtime, veritabanı yükseltmesi ve eklentileri yeniden kontrol edin. Değişiklikten sonraki yazıları kapsayan veri eşitleme ve geri dönüş planı kurun. Eski snapshot, daha sonra verilen siparişleri içermez.

Kararı tekrar uygulanabilir biçimde kaydedin

Diğer sütunlar için tabloyu yana kaydırın →

Sırları kayıt dışında tutun; gizli olmayan yapılandırmayı sürüm kontrolünde saklayın. Önemli bağımlılık değişince ayrı ortamda yeniden kurun. Ücretsiz bulut denemesi için Oracle VM adımlarına, yayımlama için Nginx ve HTTPS kurulumuna geçin.

Sorular ve yanıtlar