Docker

ininia.com'un kendi container'ı: tek imajda php-fpm, kuyruk ve zamanlayıcı

Bu siteyi taşıyan imaj php:8.4-fpm-alpine üzerine kuruludur ve içinde üç süreç birden çalışır: php-fpm, queue:work ve schedule:work. Süreç yöneticisi supervisord. Ayrı bir kuyruk container'ı, ayrı bir scheduler container'ı yok.

Bu, "bir container bir süreç" öğüdüne aykırı. Bilerek aykırı. Tek sunucuda onlarca uygulama barındıran bir kurulumda üç yerine bir container, üç kat daha az imaj katmanı, tek log akışı ve tek yeniden başlatma noktası demek. Ayırma kararı, kuyruk yükü php-fpm'i aç bırakmaya başladığında verilir; öncesinde değil.

Kuyruk süreci şu parametrelerle çalışıyor:

php artisan queue:work --sleep=3 --tries=3 --max-time=3600 \
    --memory=192 --max-jobs=500

--memory=192 keyfi değil. PHP bellek limiti 256M iken worker varsayılan 128 MB eşiğiyle çalıştırıldığında birkaç saniyede exit 12 verip ölüyordu; Laravel worker'ı bellek eşiğini aşınca kendini sonlandırır ve supervisord anında yeniden başlatır, yani dışarıdan "kuyruk çalışıyor" görünür ama hiçbir iş bitmez. --max-jobs=500 ise sızıntıya karşı periyodik temiz yeniden başlatma.

Alpine imajında root ile artisan çalıştırmak siteyi 500'e düşürür

Bu, Docker'a yeni geçen PHP ekiplerinin en sık düştüğü tuzak ve hata mesajı hiçbir şey açıklamaz. Sebep tek bir sayı: Alpine tabanlı imajlarda www-data kullanıcısının uid'i 82, Debian tabanlı imajlarda 33.

Container'a girip php artisan komutunu root ile çalıştırdığınızda üretilen her dosya (günlük log, derlenmiş Blade görünümü, config cache) root'a ait olur. php-fpm ise www-data ile koşar. Bir sonraki istekte fpm o dosyaya yazamaz ve tüm site 500'e düşer. Deploy sırasında değil, deploy'dan dakikalar sonra, ilk log satırı yazılmak istendiğinde.

Düzeltme host tarafından chown çekmek DEĞİLDİR. Host'un www-data'sı 33, container'ınki 82; host'tan verilen sahiplik container içinde yabancı bir uid olarak görünür ve sorun aynen sürer.

İki doğru yol var:

# 1) Komutu zaten fpm'in kullanıcısıyla çalıştır
docker compose exec -T -u www-data app php artisan config:cache

# 2) Root ile çalıştırdıysan sahipliği container İÇİNDEN geri ver
docker compose exec -T app \
  chown -R www-data:www-data /var/www/html/storage /var/www/html/bootstrap/cache

Varsayılan log sürücüsü diski doldurur; bunu kimse ayarlamadan fark etmez

Docker'ın varsayılan günlük sürücüsü json-file ve resmî dokümantasyonun ifadesiyle "varsayılan olarak hiçbir log döndürme işlemi yapılmaz; bu da çok çıktı üreten container'larda diskin tükenmesine kadar gidebilir" (bkz. Docker Docs, Configure logging drivers). Uygulama tarafında da aynı hata yapılabilir: Laravel'in single veya stack kanalı tek bir laravel.log dosyasına yazar ve o dosya yüzlerce megabayta ulaşır.

İki katmanı da aynı anda kapatın. Docker tarafı, /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" }
}

Laravel tarafı, .env:

LOG_CHANNEL=daily
LOG_DAILY_DAYS=1

daemon.json değişikliği yalnızca yeni container'lara uygulanır. Mevcut container'lar eski ayarla çalışmaya devam eder; yeniden oluşturmadan ölçüm yapmayın.

Docker yeter mi, Kubernetes gerekir mi?

Bu kararı trafik değil, operasyon modeli belirler. Tek bir uygulamayı tek sunucuda çalıştıran ekipler için Kubernetes, çözdüğünden fazla sorun üretir.

Efor tarafı: bir uygulamanın Docker'a alınması, CI/CD hattının kurulması ve yayına çıkarılması bizim projelerimizde 3-6 adam-gün sabit kalemdir. Adam-gün birim fiyatımız 300-400 USD. Kubernetes'e geçiş bu kalemin yerine geçmez, üstüne biner; küme kurulumu, ingress, secret yönetimi ve gözlemlenebilirlik ayrı bir iştir.

Devamı: DevOps danışmanlığı, Kubernetes danışmanlığı, AWS mimarisi ve maliyet optimizasyonu, DevOps ve altyapı hizmetleri.