PHP Uygulamasını Üretime Almak: Yapılandırma ve Güvenlik

Bir uygulamanın üretime alınması, dosyaların sunucuya kopyalanmasından ibaret değildir. Hata görüntüleme, dosya izinleri, sırların saklanması ve dağıtım sırasında oluşan kesinti, ayrı ayrı ele alınması gereken konulardır. Serinin son bölümü, yayına almadan önce tamamlanması gereken işleri topluyor.

Buradaki maddelerin çoğu bir kez yapılıp unutulur, ancak atlandıklarında sonuçları ağırdır: kaynak kodun indirilebilmesi, hata ekranında veritabanı bilgilerinin görünmesi ya da yükleme dizininden betik çalıştırılabilmesi gibi.

Belge kökü ve dizin yapısı

Sunucunun belge kökü, uygulamanın kök dizini değil yalnızca genel erişime açılacak dizin olmalıdır. Kaynak kod, yapılandırma dosyaları ve bağımlılıklar bu dizinin dışında kalır; böylece bir yapılandırma hatası dosyaların indirilmesine yol açmaz.

/var/www/uygulama/
  public/          <- belge kökü yalnızca burası
    index.php
    varlik/
  src/
  gorunum/
  vendor/
  depo/            <- günlükler, önbellek, yüklemeler
  .env             <- web üzerinden erişilemez

Yüklenen dosyaların saklandığı dizinde betik çalıştırılması engellenmelidir. Dosyaların belge kökü dışında tutulup uygulama üzerinden sunulması en güvenli yoldur; bu mümkün değilse sunucu yapılandırmasında çalıştırma kapatılır.

Üretim yapılandırması

; hata yönetimi
display_errors = Off
display_startup_errors = Off
log_errors = On
error_reporting = E_ALL
error_log = /var/log/php/uygulama.log

; sınırlar
memory_limit = 256M
max_execution_time = 30
post_max_size = 12M
upload_max_filesize = 10M

; oturum
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax
session.use_strict_mode = 1

; bilgi sızıntısı
expose_php = Off

Bu ayarların bir bölümü uygulama içinden de değiştirilebilir, ancak yapılandırmanın tek bir yerde toplanması tercih edilir. Sunucudaki değer ile koddaki değer birbirinden farklı olduğunda, hangisinin geçerli olduğunu anlamak zaman kaybettirir.

Sürüm bilgisinin yanıt başlıklarında yayımlanmaması, bilinen açıklara sahip sürümlerin hedeflenmesini zorlaştırır. Bellek ve süre sınırları ise ihtiyacın üzerinde tutulmamalıdır; yüksek sınırlar, sorunlu bir isteğin sunucunun tamamını etkilemesine imkan tanır.

Sırların yönetimi

Veritabanı parolaları, API anahtarları ve oturum gizli anahtarı kaynak koda yazılmaz. Bu değerler ortam değişkeni olarak tanımlanır ve sürüm denetimine dahil edilmez. Örnek bir dosya, hangi değişkenlerin gerektiğini gösterir.

$dsn = getenv('VERITABANI_DSN') ?: throw new RuntimeException('VERITABANI_DSN tanımsız');
$anahtar = getenv('OTURUM_ANAHTARI') ?: throw new RuntimeException('OTURUM_ANAHTARI tanımsız');

Eksik bir değişkenin sessizce varsayılan değere düşmesi tehlikelidir; uygulamanın açılışta hata vermesi, yanlış yapılandırmayla çalışmasından daha iyidir. Anahtar sızdığında yenilenebilmesi için de değerlerin tek yerden yönetilmesi gerekir.

Dosya izinleri

Web sunucusunun kaynak kod dizinine yazma izni olmamalıdır. Yazma izni yalnızca gerçekten yazılan dizinlerde bulunur: günlükler, önbellek ve yüklemeler.

# kaynak kod: okuma ve çalıştırma
find /var/www/uygulama -type d -exec chmod 755 {} +
find /var/www/uygulama -type f -exec chmod 644 {} +

# yalnızca yazılabilir dizinler
chown -R www-data:www-data /var/www/uygulama/depo
chmod -R 775 /var/www/uygulama/depo

# sırlar yalnızca sahibine açık
chmod 600 /var/www/uygulama/.env

Dağıtım akışı

Dosyaların doğrudan çalışan dizin üzerine kopyalanması, kopyalama sürerken gelen isteklerin yarı güncellenmiş bir kod tabanıyla karşılaşmasına yol açar. Yeni sürüm ayrı bir dizine hazırlanıp bağlantı tek adımda değiştirildiğinde bu sorun ortadan kalkar.

# yeni sürümü ayrı dizine hazırla
git clone --depth 1 repo /var/www/surumler/2026-07-27
cd /var/www/surumler/2026-07-27
composer install --no-dev --optimize-autoloader --no-interaction

# paylaşılan dizinleri bağla
ln -s /var/www/paylasilan/depo depo
ln -s /var/www/paylasilan/.env .env

# veritabanı göçlerini uygula, sonra tek adımda geçiş yap
php bin/goc.php
ln -sfn /var/www/surumler/2026-07-27 /var/www/aktif

# önbellekleri tazele
php bin/onbellek-temizle.php
systemctl reload php8.4-fpm

Göç adımlarının dağıtımdan önce çalıştırılması, yeni kodun eksik bir şemayla karşılaşmasını önler. Bunun için göçlerin eski kodla da uyumlu olması gerekir: önce sütun eklenir, kod yayına alınır, eski sütun ancak daha sonra kaldırılır.

Geri alma, dağıtımın ayrılmaz parçasıdır. Önceki sürüm dizini yerinde durduğu sürece bağlantının geri alınması saniyeler sürer. Veritabanı değişiklikleri ise geri alınabilir biçimde tasarlanmalıdır: sütun silme gibi işlemler, yeni sürüm bir süre sorunsuz çalıştıktan sonra ayrı bir adımda yapılır.

Zamanlanmış görevler ve kuyruklar

Web isteği içinde yapılmaması gereken işler vardır: toplu e-posta gönderimi, büyük rapor üretimi, dış servislerle toplu eşitleme. Bu işler kuyruğa alınır ve ayrı bir süreç tarafından yürütülür; kullanıcı yanıtı beklemez.

Zamanlanmış görevlerde iki noktaya dikkat edilir. Birincisi, aynı görevin üst üste çalışmasını engelleyen bir kilit bulunmalıdır; önceki çalıştırma bitmediyse yenisi başlamamalıdır. İkincisi, görevin çıktısı ve hataları günlüğe yazılmalıdır; sessizce başarısız olan bir görev, günler sonra fark edilir.

$kilit = fopen('/var/www/uygulama/depo/gorev.kilit', 'c');

if (!flock($kilit, LOCK_EX | LOCK_NB)) {
    exit(0);                     // önceki çalıştırma sürüyor
}

try {
    $gorev->calistir();
} catch (Throwable $e) {
    error_log('Görev başarısız: ' . $e);
    exit(1);
} finally {
    flock($kilit, LOCK_UN);
    fclose($kilit);
}

Yayına almadan önce

Aşağıdaki maddeler, ilk yayına alma öncesinde ve her büyük değişiklikten sonra gözden geçirilir.

• Tüm sayfalar HTTPS üzerinden sunuluyor, HTTP isteği yönlendiriliyor.
• Güvenlik başlıkları tanımlı: içerik güvenlik politikası, tür denetimi, yönlendirici bilgisi.
• Yönetim panelleri ve hata ayıklama uçları erişime kapalı.
• Sürüm denetimi dizini ve yedek dosyaları web üzerinden indirilemiyor.
• Veritabanı kullanıcısının yalnızca gereken yetkileri var.
• Yedekleme çalışıyor ve geri yükleme en az bir kez denenmiş.
• Günlükler dönüşümlü olarak arşivleniyor, disk dolmuyor.
• Bağımlılıklarda bilinen açık denetimi yapılmış.

İzleme

Yayına alma işin sonu değildir. Hata oranı, yanıt süresi ve disk kullanımı izlenmediğinde sorunlar kullanıcı bildirimiyle öğrenilir. Basit bir sağlık kontrolü ucu ve günlüklerdeki hata sayısının izlenmesi, küçük kurulumlarda bile belirgin fark yaratır.

// GET /saglik
jsonYanit([
    'ok' => true,
    'veritabani' => $baglanti->calisiyorMu(),
    'disk_bos_yuzde' => $disk->bosYuzde(),
    'surum' => getenv('SURUM') ?: 'bilinmiyor',
]);

Kontrol listesi

• Belge kökü yalnızca genel dizini gösteriyor.
• Üretimde hata görüntüleme kapalı, kayıt açık.
• Sırlar ortam değişkeninde, sürüm denetiminde değil.
• Web sunucusunun kaynak koda yazma izni yok.
• Dağıtım atomik ve geri alınabilir.
• Bağımlılıklar geliştirme paketleri olmadan kuruluyor.
• Yedekleme ve izleme çalışır durumda.

İlgili yazılar

• Günlükleme ve performans ölçümü
• Güvenli çıktı ve güvenlik başlıkları
• Composer ile üretim kurulumu

PHP eğitim serisi

Bu yazı, temel sözdiziminden üretim ortamına kadar ilerleyen 25 bölümlük serinin bir parçası. Bölümler sırayla okunacak biçimde hazırlandı, ancak her biri tek başına da kullanılabilir.

Temeller

1. Kurulum ve temel sözdizimi
2. Döngüler ve akış kontrolü
3. Diziler
4. Fonksiyonlar
5. String fonksiyonları
6. Süper globaller
7. Form işleme
8. Dosya işlemleri

Dilin ayrıntıları

9. Tip sistemi ve strict_types
10. Hata ve istisna yönetimi
11. Düzenli ifadeler
12. Tarih ve saat işlemleri

Nesne yönelimli PHP

13. Sınıf ve nesne
14. Kalıtım, arayüz ve trait
15. Statik üyeler, sabitler ve enum
16. Namespace, Composer ve autoload

Veri ve güvenlik

17. PDO ile veritabanı işlemleri
18. Oturum yönetimi ve kimlik doğrulama
19. Güvenli çıktı ve XSS
20. JSON ile veri değişimi

Dış dünya ve üretim

21. cURL ile dış API çağırma
22. Kendi REST API'ni yazmak
23. PHPUnit ile birim test
24. Hata ayıklama ve performans ölçümü
25. Üretime alma ve güvenlik (bu yazı)