Bu rehber neyi çözer?
Docker ve Podman OCI container iş yükleri için güçlü araçlardır; seçim geliştirici deneyimi, rootless güvenlik ve mevcut CI/CD entegrasyonlarına göre yapılmalıdır.
Docker yaklaşımı
Geniş geliştirici ekosistemi, image/registry iş akışları ve Compose yaygınlığı önemli avantajdır.
Daemon modeli ve socket erişim yetkileri güvenlik tasarımında dikkate alınmalıdır.
Podman yaklaşımı
Daemonless ve rootless çalışma modeli Linux sunucu güvenliğinde avantaj sağlayabilir.
Docker benzeri CLI geçişi kolaylaştırabilir; systemd entegrasyonu da operasyon açısından değerlidir.
Image ve registry
OCI uyumlu image’lar geniş ölçüde taşınabilir; build, volume, network ve compose davranışları pilotta doğrulanmalıdır.
Private registry, image signing ve vulnerability scanning üretim standardına eklenmelidir.
Container güvenliği
Rootless, capability azaltma, read-only filesystem, seccomp/SELinux/AppArmor ve secret yönetimi birlikte kullanılmalıdır.
Host patching ve image güncelleme süreci container güvenliğinin parçasıdır.
Sık Sorulan Sorular
Podman Docker image çalıştırabilir mi?
Birçok OCI/Docker uyumlu image çalışır; compose, network ve volume davranışı uygulama bazında test edilmelidir.
Rootless neden önemli?
Container process’lerinin host üzerinde root yetkisi olmadan çalışmasını sağlayarak etki alanını azaltabilir.
Container kullanınca VM gerekmez mi?
Hayır. VM ve container farklı izolasyon modelleridir ve sıkça birlikte kullanılır.
Kaynaklar ve teknik referanslar
Linux Sunucu Projenizi Değerlendirelim
Mevcut Windows/Linux rollerinizi, uygulama bağımlılıklarını ve geçiş hedeflerinizi birlikte değerlendirebiliriz.
Mimari ve çalışma modeli
Container image uygulama dosyaları ve bağımlılıklarını taşır; kalıcı veri volume veya harici hizmette bulunabilir. Docker ve Podman işletim modeli, daemon, rootless ve yönetim entegrasyonu açısından karşılaştırılmalıdır. Rootless çalışma ana makinedeki bütün riskleri kaldırmaz. Docker hizmetine ayrıcalıklı erişim güçlü host yetkileri verebilir.
- 1Image ve runtime
- 2Sınırlı process/namespace
- 3Volume ve servis bağımlılığı
- 4Yeniden oluşturma testi
Tasarım parametreleri
- UID ve rootless
- Container UID, host UID ve user namespace eşleştirmesini volume izinleriyle birlikte doğrulayın.
- Kalıcılık ve lifecycle
- Image, writable layer ve volume farklıdır; yeniden oluşturma sırasında kalıcı veriyi test edin.
- Servis ve kullanıcı
- Gerçek servis kullanıcısını, grup üyeliğini, çalışma dizinini ve gerekli yetkileri listeleyin. Root ile başarılı test sınırlı hesapla çalışmayı kanıtlamaz.
- Depolama ve kalıcılık
- Mount, dosya sistemi, inode ve kalıcı veriyi birlikte kontrol edin. Yeniden başlatma ve yeniden oluşturma aynı test değildir.
- Ağ ve güvenlik katmanı
- Dinlenen arayüz, firewall, TLS ve SELinux/AppArmor politikalarını ayırın. Bir katmandaki engel başka katmanın ayarıyla çözülmez.
- Paket ve işletim yöntemi
- Sürüm, depo, güncelleme yöntemi ve servis bağımlılıklarını belgeleyin. Bakım sonrası reboot ve uygulama doğrulamasını planlayın.
Hesap ve uygulama örneği
Örnek uygulamayı container silinip yeniden oluşturulduktan sonra test edin: volume verisi korunmalı, geçici dosya korunmak zorunda olmamalıdır. UID/GID eşlemesini, ağ portunu ve secret kaynağını doğrulayın. Image güncellemesini veri backupı saymayın; eski image ile yeni schema uyumu rollbacki sınırlayabilir.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Container volumea yazamıyor | UID eşleştirmesi, SELinux etiketi veya read-only mount olabilir. | Container kimliği, mount ve host güvenlik bağlamını karşılaştırın. |
| Servis aktif ama yanıt vermiyor | Process sağlığı, port dinleme ve uygulama sağlığı farklı kontrollerdir. | Yerel sağlık kontrolünü uzak istemci isteğiyle karşılaştırın; log ve bağımlılık durumunu inceleyin. |
| Dosya yazılamıyor | İzin, ACL, read-only mount, inode veya disk doluluğu etkili olabilir. | Servis kimliğiyle dizin zincirini ve mount durumunu doğrulayın; izinleri topluca açmayın. |
| Reboot sonrası yapılandırma kayboldu | Geçici mount, runtime ayarı veya yanlış yapılandırma kaynağı kullanılmış olabilir. | Kalıcı ayarı ve açılış sırasını kontrol edin; temiz reboot testini tekrarlayın. |
Kabul ve doğrulama kontrolleri
- Kalıcı verinin yeri, servis UID’si ve yeniden oluşturma davranışını birlikte doğrulayın.
- Servisi tanımlanan sınırlı kimlikle çalıştırıp temel iş akışını test edin.
- Reboot sonrasında mount, ağ, zaman ve uygulama durumunu doğrulayın.
- Yapılandırma, veri ve anahtarları ayrı kurtarma kalemleri olarak kaydedin.
- Güncellemeden önce ve sonra aynı sağlık testini çalıştırın.
- Ayrı hedefe geri yükleyerek platform bağımlılıklarını doğrulayın.
İlgili kavramlar
İzolasyon ile sanallaştırma ayrımı
Container ve sanal makine aynı izolasyon sınırını sunmaz. Containerlar host çekirdeğini paylaşırken sanal makineler konuk işletim sistemi çalıştırır. Rootless kullanım, namespace ve capability kısıtları riski azaltabilir; yapılandırma ve host güvenliği yine önemlidir. Image, çalışan container ve kalıcı volume ayrı yaşam döngülerine sahiptir. Image güncellemek veriyi yedeklemez. Testte process izinlerini, mountları, ağ erişimini ve kalıcı verinin yeniden oluşturma sonrasında korunmasını ayrı ayrı doğrulayın.
Dosya izinleri ve servis kimliği
Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACL’leri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.
Dosya sistemi ve depolama katmanları
Uygulama dizini, mount point, mantıksal disk ve fiziksel depolama aynı katman değildir. Boş alan kadar inode tükenmesi, read-only mount ve dosya sistemi hataları da yazmayı durdurabilir. Snapshot genellikle aynı depolama arızasını paylaşır ve bağımsız yedek sayılmaz. Mount seçenekleri ve kapasite genişletme yöntemi dosya sistemine göre değişir. İşletim sistemi yeniden açıldığında doğru depolamanın doğru dizine bağlandığını doğrulayın; mount edilmeyen dizine yazılan veri yanlış diski doldurabilir.
Servis yaşam döngüsü ve bağımlılıklar
Çalışan bir process, hizmetin kullanıcıya doğru yanıt verdiğini kanıtlamaz. Başlangıç sırası, ağ veya veritabanı bağımlılığı, ortam değişkenleri, dosya erişimi ve sağlık kontrolü birlikte incelenir. Servis yeniden başlatma döngüsü bazen gerçek nedeni gizler. Exit code, son loglar ve kaynak sınırlarını karşılaştırın. Uygulama dışında systemd veya container yönetim katmanının neden yeniden başlatma yaptığını da kaydedin. Kontrollü restart sonrasında oturum, veri yazma ve bağımlı servislerin davranışını doğrulayın.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
En az yetki ve görev ayrımı
En az yetki, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.