Docker üretim ortamı: restart politikası, log döndürme ve kaynak sınırları

Geliştirme ortamı ile üretim arasındaki fark

Bir konteyner dizüstü bilgisayarda çalıştı diye üretimde sağlam çalışacağı anlamına gelmez. Geliştirmede konteyner çökerse yeniden başlatırsınız; üretimde ise gece yarısı çöken bir servis müşteriyi etkiler. Üretim ortamı konteynerlerin kendiliğinden toparlanmasını, kaynakları kontrolsüz tüketmemesini, günlüklerin diski doldurmamasını ve güvenlik açıklarının daraltılmasını gerektirir.

Tek sunuculu bir Docker kurulumunda temel ayarlar şunlardır: yeniden başlatma politikası, kaynak sınırları, günlük döndürme, sağlık kontrolü ve güvenlik ayarları. Çok sunuculu ya da otomatik ölçekleme gerektiren kurulumlarda bir orkestrasyon platformu devreye girer; temel ilkeler yine de aynıdır.

Yeniden başlatma politikası

Docker'da --restart bayrağı, konteyner durduğunda ne olacağını belirler. Resmî belgelerdeki seçenekler:

• no: Varsayılan. Konteyner hiç otomatik başlamaz.
• on-failure: Yalnızca sıfırdan farklı bir çıkış koduyla durduğunda yeniden başlatır. İsteğe bağlı bir deneme sınırı verilebilir. Docker sunucusu yeniden başlarsa bu politika konteyneri başlatmaz.
• always: Durduğunda her zaman yeniden başlatır. Elle durdurulmuşsa Docker sunucusu yeniden başlayana ya da konteyner elle başlatılana kadar kapalı kalır.
• unless-stopped: always gibidir, ama elle durdurulan konteyner Docker sunucusu yeniden başlasa bile durduğu yerde kalır.

Üretimde sürekli çalışması gereken servisler için genellikle unless-stopped tercih edilir: sunucu yeniden başladığında servis geri gelir, bakım için elle durdurduğunuz şey ise kendiliğinden kalkmaz. Politika, konteyner başarıyla ayağa kalkıp kısa bir süre çalıştıktan sonra devreye girer; böylece hiç açılmayan bir konteyner sonsuz yeniden başlatma döngüsüne girmez.

Docker belgeleri, restart politikalarının systemd ya da supervisor gibi süreç yöneticileriyle birlikte kullanılmamasını söyler; çakışırlar. Mevcut bir konteynerin politikasını docker update --restart ile değiştirebilirsiniz.

Önemli: Yeniden başlatma politikası çöken bir uygulamayı kurtarır, ama çökme nedenini çözmez. Sürekli yeniden başlayan konteyner için günlüklere bakın.

Kaynak sınırları: bellek ve işlemci

Sınırsız bırakılan bir konteyner, hatalı bir döngü ya da bellek sızıntısıyla tüm sunucunun kaynaklarını tüketebilir. Docker, sınırları çalıştırma anında bayraklarla ya da Compose dosyasında tanımlamanıza izin verir.

docker run -d --name uygulama --memory=<bellek-sınırı> --cpus=<işlemci-sayısı> imaj-adi

--memory konteynerin kullanabileceği bellek üst sınırını koyar. Sınır aşıldığında Linux çekirdeği bellek yetersizliği (OOM) durumunda süreçleri sonlandırabilir. Docker belgeleri, sunucunun kendisinin de risk altına girebileceğini belirtir ve bu yüzden uygulamanın bellek ihtiyacını önce test edip makul bir sınır koymayı önerir. OOM öldürücüyü kapatan bayrak, yalnızca bellek sınırıyla birlikte ve ihtiyatla kullanılmalıdır.

--cpus ise konteynerin kullanabileceği işlemci miktarını sınırlar; kesirli değer alabilir. Göreli ağırlık veren --cpu-shares değeri ise yalnızca işlemci kıt olduğunda anlamlıdır ve hiçbir kaynak rezerve etmez. Bu ayrım önemlidir: yük yokken ağırlık hiçbir şey değiştirmez.

Compose dosyasında benzer sınırlar mem_limit ve cpus alanlarıyla ya da deploy altındaki kaynak sınırlarıyla tanımlanır. Sınır değerleri tahminle değil, ölçümle belirleyin: yük altında konteynerin gerçek tüketimine bakın, üzerine pay bırakın.

Günlük (log) yönetimi

Docker'ın varsayılan günlük sürücüsü json-file'dır. Resmî belgelerin uyarısı açıktır: bu sürücü varsayılan olarak günlük döndürme yapmaz. Çok yazan bir konteyner, günlük dosyasıyla diski doldurabilir ve sunucudaki bütün servisleri durdurabilir. Bu, üretimde en sık görülen ve en kolay önlenebilen sorunlardan biridir.

Çözüm, günlük sürücüsü seçeneklerinde azami dosya boyutunu ve saklanacak dosya adedini sınırlamaktır. Sunucu genelinde daemon.json dosyasında:

{ "log-driver": "json-file", "log-opts": { "max-size": "<boyut>", "max-file": "<adet>" } }

Seçenek değerleri metin olarak yazılır. Ayar değiştikten sonra Docker servisi yeniden başlatılır ve yalnızca bundan sonra oluşturulan konteynerleri etkiler; mevcut konteynerler eski ayarla çalışmaya devam eder, yeniden oluşturulmaları gerekir. Alternatif olarak belgeler döndürme desteği olan local sürücüsünü önerir.

Daha büyük kurulumlarda günlükler konteynerden çıkarılıp merkezi bir günlük sistemine gönderilir. Konteyner içinde dosyaya log yazmak yerine standart çıktıya yazmak, Docker günlük mekanizmasının toplayabilmesi için önemlidir.

Sağlık kontrolü, güvenlik ve değiştirilemez imaj

Çalışan bir konteyner, hizmet verdiği anlamına gelmez. Sağlık kontrolü (healthcheck), uygulamanın gerçekten yanıt verip vermediğini düzenli sorgular. Docker durumu "sağlıklı" ya da "sağlıksız" olarak işaretler ve izleme araçları bu bilgiyi kullanır. Yanıt vermeyen ama süreci hâlâ ayakta olan uygulamaları yakalamanın yolu budur.

Güvenlik ayarlarının başında yetkisiz kullanıcıyla çalıştırmak gelir. İmajda USER talimatı kullanılır ya da çalıştırma anında kullanıcı verilir. Kök dosya sistemini salt okunur yapmak, saldırganın konteyner içinde dosya değiştirmesini zorlaştırır; yazma gereken yerler için ayrıca volume ya da geçici bellek bağlanır. Compose'ta bu iş read_only alanıyla yapılır.

Ana süreç olarak çalışan uygulamanın sinyal ve zombi süreç yönetimi için init seçeneği (Compose'ta init: true) bir başlatıcı süreç ekler; sinyalleri iletir ve biten alt süreçleri toplar.

Taban imajı belirli bir sürüme sabitleyin, latest etiketine güvenmeyin. İmajları bir kayıt defterinden çekin, güvenlik taraması yapın ve gizli bilgileri imaja değil çalışma anında ortam değişkeni ya da gizli bilgi mekanizmasıyla verin. Güncelleme için konteyneri yamalamak yerine yeni imajla yeniden oluşturmak, ortamları öngörülebilir tutar.

Üretim öncesi kontrol listesi ve sık hatalar

• Yeniden başlatma politikası tanımlı mı? Gerçekten çökme durumunda mı, sunucu yeniden başlarken mi devreye giriyor, denendi mi?
• Bellek ve işlemci sınırları ölçüme dayanıyor mu?
• Günlük döndürme açık mı? Disk kullanımı izleniyor mu?
• Sağlık kontrolü uygulamanın gerçek işlevini sorguluyor mu, yoksa yalnızca süreç var mı diye mi bakıyor?
• Konteyner yetkisiz kullanıcıyla çalışıyor mu? Gereksiz port yayınlanmış mı?
• Veri volume'de mi, yedeği ve geri yükleme prosedürü var mı?
• Taban imaj sabit sürümde mi? Gizli bilgi imajın içinde mi?
• Dağıtım ve geri alma adımları yazılı mı?

Sık yapılan hata: sınırsız günlük, sınırsız bellek ve latest etiketi. Bunlar birlikte, bir gece çıkan tek bir sorunu bütün sunucuyu etkileyen bir olaya çevirir. Bir diğeri de bu ayarları yalnızca elle komut satırında vermektir: ayarlar Compose dosyasında ya da dağıtım betiğinde yazılı olmalı ki sunucuyu yeniden kurduğunuzda aynı ortama ulaşabilesiniz.

Mindset programlarında nerede çalışılır?

Docker ve Container Teknolojileri eğitimi, konteynerleri üretimde işletecek DevOps, sistem ve platform ekipleri için tasarlanmıştır; müfredatında "Üretim Docker Ortamı", "Docker Registry ve Image Güvenliği" ve "Docker Ağ ve Depolama" modülleri yer alır. Temel Docker Eğitimi ise bu sayfadaki ayarlara geçmeden önce imaj, konteyner ve Compose temellerini oturtmak isteyenler için uygundur.

Bir ekip için pratik kazanım, üretim standartlarını yazılı bir kontrol listesine çevirmektir: her yeni servis aynı yeniden başlatma, günlük ve kaynak kurallarıyla yayına çıkar.