Ubuntu Sunucularda Servis Dağıtımı ve Yönetim İpuçları

Bir uygulamanın geliştirici bilgisayarında sorunsuz çalışması, production sunucuda da aynı güvenle çalışacağı anlamına gelmez. Production tarafında process yönetimi, güvenlik, TLS, reverse proxy, loglama, monitoring, backup ve rollback gibi katmanların birlikte düşünülmesi gerekir. Yaklaşık on yıllık sunucu ve deployment çalışmalarında en sık gördüğüm sorun, ekiplerin uygulamayı ayağa kaldırmayı deployment sürecinin sonu sanmasıdır. Oysa iyi bir deployment, servis çöktüğünde ne olacağını, sertifika yenilenmediğinde nasıl alarm üretileceğini ve yeni sürüm başarısız olduğunda nasıl geri dönüleceğini de önceden tanımlar. Bu rehberde Ubuntu Sunucularda Servis Dağıtımı ve Yönetim İpuçları konusunu systemd, Nginx, güvenlik ve kesintisiz deployment perspektifinden ele alacağız.

Ubuntu sunucuda uygulama ve servis deployment nasıl yapılır sorusunun güvenilir cevabı tek bir komutta bulunmaz. Aynı şekilde Ubuntu server systemd servis oluşturma ve yönetme nasıl yapılır, Ubuntu sunucuda Nginx reverse proxy SSL ve firewall yapılandırması nasıl hazırlanır veya Ubuntu production sunucuda Docker servis monitoring log ve otomatik restart yönetimi nasıl kurulmalıdır gibi sorular birbirine bağlıdır. Bu yazıda küçük bir VPS'ten daha kurumsal yapılara kadar uygulanabilecek bir model kuracağız. Amaç yalnızca çalışan bir sistem değil, yönetilebilir ve gözlemlenebilir bir production ortamı oluşturmaktır. Her adımda pratikte neden o tercihin yapıldığını da açıklayacağım.

Ubuntu Sunucuda Servis Dağıtımı Nedir?

Servis dağıtımı, uygulama kodunu sunucuya kopyalamaktan çok daha geniş bir süreçtir. Uygulamanın belirli kullanıcı yetkileriyle çalışması, reboot sonrasında otomatik başlaması, hata durumunda kontrollü biçimde yeniden başlatılması ve dış dünyaya güvenli şekilde yayınlanması gerekir. Production ortamında runtime, process manager, reverse proxy, TLS, logging, monitoring ve backup birlikte değerlendirilmelidir. Bu parçaların herhangi biri eksik olduğunda uygulama çalışsa bile operasyon güvenilirliği düşer. İyi deployment tasarımı ilk kurulumdan incident anına kadar bütün yaşam döngüsünü kapsar.

Development Ortamından Production'a Geçiş

Development ortamı geliştiricinin hızlı değişiklik yapmasına göre tasarlanır, production ise kararlılık ve güvenlik bekler. Development server çoğu zaman debug açık çalışır ve tek process kullanır. Production'da servis kullanıcısı, health check, restart policy ve reverse proxy gerekir. Ayrıca dependency sürümleri sabitlenmeli ve deployment tekrar üretilebilir olmalıdır. Benim uyguladığım temel kural, geliştirme kolaylığı sağlayan her özelliğin production'a taşınmadan önce güvenlik ve dayanıklılık açısından yeniden değerlendirilmesidir.

Bir Uygulamayı Servis Olarak Çalıştırmak Ne Demektir?

Bir uygulamayı servis olarak çalıştırmak, process'in terminal oturumundan bağımsız biçimde işletim sistemi tarafından yönetilmesi anlamına gelir. Kullanıcı SSH bağlantısını kapattığında uygulama çalışmaya devam etmelidir. Sunucu yeniden başladığında servis otomatik olarak ayağa kalkabilmelidir. Process çökerse belirlenen restart politikası devreye girmelidir. Ubuntu üzerinde bu görevlerin önemli bölümü systemd tarafından yönetilebilir.

Production Deployment'ın Temel Bileşenleri

Sağlıklı production deployment birkaç temel bileşenin birlikte çalışmasına dayanır. Runtime uygulamayı çalıştırırken process manager çalışma döngüsünü yönetir. Reverse proxy public trafik ile application process arasında güvenli katman oluşturur. TLS, logging ve monitoring güvenlik ile görünürlüğü artırır. Backup ise sistemin geri döndürülemez bir hata karşısında kurtarılabilmesini sağlar.

Application runtime

Application runtime kullanılan programlama dilinin uygulamayı çalıştırdığı ortamdır. Python interpreter, Node.js runtime, JVM ve .NET runtime buna örnektir. Production sunucuda runtime sürümü açıkça belirlenmelidir. Sistem paketlerinin güncellenmesiyle beklenmedik runtime değişikliği yaşanmaması için version pinning uygulanabilir. Runtime sürümü deployment kayıtlarında tutulursa hata araştırmak çok daha kolaylaşır.

Process manager

Process manager uygulamanın başlatılması, durdurulması ve gerektiğinde yeniden çalıştırılmasından sorumludur. Ubuntu üzerinde native servislerde systemd güçlü ve yerleşik bir çözümdür. Process çöktüğünde restart uygulanabilir ve loglar journald üzerinden toplanabilir. Kaynak limitleri de aynı servis tanımı içinde ayarlanabilir. Böylece uygulamanın terminalden manuel çalıştırılmasına ihtiyaç kalmaz.

Reverse proxy

Reverse proxy public HTTP veya HTTPS trafiğini backend uygulama servisine yönlendirir. Nginx bu amaçla Ubuntu sunucularda yaygın olarak kullanılır. Backend yalnızca localhost veya Unix socket üzerinde dinleyebilir. TLS termination, rate limiting ve static file serving reverse proxy katmanında uygulanabilir. Bu ayrım uygulama server'ının doğrudan internete açılmasını önler.

TLS

TLS istemci ile sunucu arasındaki trafiği şifreler. Production web uygulamalarında HTTPS temel gereksinim olarak görülmelidir. Sertifika kurulumu kadar yenileme sürecinin otomatik ve izlenebilir olması önemlidir. Yenileme başarısızlığı için alarm bulunmalıdır. Sertifika yenilendikten sonra ilgili web servisine güvenli reload uygulanması gerekebilir.

Logging

Logging uygulamada ne olduğunu anlamanın ilk yollarından biridir. systemd servisleri stdout ve stderr çıktısını journald üzerinden merkezi biçimde tutabilir. Yapılandırılmış JSON loglar arama ve analiz süreçlerini kolaylaştırır. Hassas verilerin loglara yazılmaması gerekir. Retention politikası disk kullanımını kontrol altında tutmalıdır.

Monitoring

Monitoring servis çalışıyor mu sorusundan daha fazlasını cevaplamalıdır. CPU, memory, disk, request rate, error rate ve latency birlikte izlenmelidir. Application-level metric olmadan yalnızca sunucunun ayakta olduğunu bilirsiniz. Health check ve business metric daha doğru görünürlük sağlar. Kritik eşikler için alert oluşturulmalıdır.

Backup

Backup sistemi yanlış deployment, veri kaybı veya sunucu arızasına karşı son güvenlik katmanlarından biridir. Yalnızca database değil, config ve kullanıcı upload'ları da değerlendirilmelidir. Backup farklı fiziksel veya mantıksal konumda tutulmalıdır. Daha önemlisi restore testi düzenli yapılmalıdır. Hiç restore edilmemiş backup güvenilir kabul edilmemelidir.

Ubuntu Sunucu İçin Temel Production Mimarisi

Temel production mimarisinde internet trafiği önce firewall ve reverse proxy katmanına ulaşır. Nginx veya Caddy isteği localhost üzerinde çalışan application service'e yönlendirir. Application process systemd tarafından yönetilebilir. Database ve cache mümkün olduğunca doğrudan public internete açılmaz. Log, monitoring ve backup katmanları ise sistemi yalnızca çalışır değil, yönetilebilir hale getirir.

Internet

Public internet sistemin en kontrolsüz giriş alanıdır. Bu nedenle yalnızca gerçekten gereken servisler public port üzerinden erişilebilir olmalıdır. Web uygulaması için çoğu zaman 80 ve 443 yeterlidir. SSH erişimi daha sınırlı source adreslerine kapatılabilir. Public exposure ne kadar küçük olursa saldırı yüzeyi de o kadar azalır.

Firewall

Firewall hangi network trafiğinin sunucuya ulaşabileceğini belirler. Ubuntu tarafında UFW sade bir yönetim arayüzü sunar. Varsayılan incoming deny yaklaşımı güvenli başlangıçtır. Yalnızca SSH, HTTP ve HTTPS gibi gerekli portlar açılır. Cloud sağlayıcının firewall katmanı varsa host firewall ile birlikte kullanılabilir.

Nginx veya Caddy

Nginx ve Caddy reverse proxy katmanında uygulamayı internetten ayırır. Nginx daha geniş konfigürasyon kontrolü sunar. Caddy ise TLS otomasyonunu daha sade hale getirebilir. Her iki durumda backend application yalnızca localhost veya private socket üzerinde tutulabilir. Reverse proxy health, timeout ve header davranışını merkezi yönetmenize imkan verir.

Application Service

Application service gerçek business logic'i çalıştırır. Public port açmak yerine local interface üzerinde dinlemesi daha güvenlidir. Dedicated service user kullanılması gerekir. Process lifecycle systemd veya container runtime üzerinden yönetilebilir. Health endpoint deployment sonrası doğrulamaya yardımcı olur.

systemd

systemd Ubuntu servis yaşam döngüsünün merkezindedir. Servisin boot sırasında başlamasını sağlayabilir. Failure durumunda restart politikası uygulayabilir. Dependency order ve resource limit tanımlanabilir. journald entegrasyonu sayesinde loglar tek komutla incelenebilir.

Database ve Cache

Database ve cache application state'inin kritik parçalarıdır. Mümkünse public IP üzerinden erişime açılmamalıdır. Localhost, private network veya managed service bağlantısı kullanılabilir. Credential'lar uygulama kodundan ayrı tutulmalıdır. Backup ve recovery planı özellikle database için önceden test edilmelidir.

Log ve Monitoring

Loglar olayın ayrıntısını, metric'ler ise sistem davranışının eğilimini gösterir. İkisi birlikte kullanıldığında troubleshooting çok daha hızlı olur. Nginx access log, application log ve system metric ortak zaman çizelgesinde incelenebilir. Alert yalnızca servis tamamen down olduğunda değil performans bozulduğunda da üretilebilir. Merkezi log platformu birden fazla sunucuda özellikle yararlıdır.

Backup

Backup yalnızca uygulama kurulumunun sonunda yapılacak bir iş değildir. İlk production tasarımının parçası olmalıdır. Database, user upload ve önemli config düzenli korunmalıdır. Off-site kopya sunucu kaybına karşı ek güvenlik sağlar. Restore süreleri uygulamanın kabul ettiği RTO hedefiyle uyumlu olmalıdır.

Servis Dağıtımından Önce Ubuntu Sunucu Nasıl Hazırlanır?

Yeni Ubuntu sunucuda ilk deployment'tan önce işletim sistemi temeli hazırlanmalıdır. Paket güncellemeleri, hostname, DNS ve saat senkronizasyonu kontrol edilmelidir. Root yerine non-root admin kullanıcı oluşturulmalı ve SSH key authentication tercih edilmelidir. Firewall kuralları uygulanmadan uygulama portu public olarak açılmamalıdır. Hazırlık aşamasını standart script veya configuration management ile tekrar üretilebilir hale getirmek uzun vadede ciddi zaman kazandırır.

Sistem Paketlerini güncelleme

Yeni kurulan image bile yayınlandığı tarihten sonra güvenlik güncellemeleri almış olabilir. Bu nedenle package index yenilenmeli ve planlanan paket güncellemeleri uygulanmalıdır. Production'a geçmeden önce reboot gereksinimi kontrol edilmelidir. Güncelleme sonrasında kritik servisler test edilmelidir. Büyük fleet ortamında canary update yaklaşımı daha güvenlidir.

Hostname ve DNS

Hostname sunucuyu operasyon sırasında tanımayı kolaylaştırır. Anlamlı ve tutarlı naming scheme kullanılması faydalıdır. DNS kayıtları doğru IP'yi göstermelidir. TLS sertifikası alınmadan önce DNS çözümlemesi doğrulanmalıdır. Reverse DNS bazı mail veya network senaryolarında ayrıca gerekebilir.

Saat ve NTP

Doğru sistem saati log korelasyonu ve TLS doğrulaması için kritiktir. NTP veya systemd-timesyncd ile zaman senkronizasyonu sağlanmalıdır. Saat farkı authentication token'larının geçersiz görünmesine yol açabilir. Distributed sistemlerde olay sırasını anlamak da zorlaşır. Monitoring sunucunun senkronizasyon durumunu izleyebilir.

Non-Root Admin User

Günlük yönetim için doğrudan root hesabı kullanılmamalıdır. Sudo yetkili ayrı admin kullanıcı oluşturmak daha güvenli yaklaşımdır. Bu sayede komutların hangi kullanıcı tarafından çalıştırıldığı daha iyi izlenir. Root SSH login ayrıca kapatılabilir. Yetkiler ekip rolüne göre sınırlandırılmalıdır.

SSH Key Authentication

SSH key authentication parola tabanlı girişe göre daha güçlü koruma sağlayabilir. Private key güvenli cihazda saklanmalıdır. Public key yalnızca gereken kullanıcının authorized_keys dosyasına eklenir. Kullanılmayan key'ler kaldırılmalıdır. Kurumsal ortamlarda kısa ömürlü credential veya bastion yaklaşımı değerlendirilebilir.

UFW Firewall

UFW Ubuntu üzerinde basit firewall yönetimi sağlar. Default incoming deny ile başlamak faydalıdır. SSH erişimi açılmadan firewall enable edilmemelidir. Ardından 80 ve 443 gibi gerekli servisler eklenebilir. Kurallar uygulandıktan sonra farklı terminal oturumundan erişim test edilmelidir.

Açık Portların Kontrolü

Sunucuda hangi servislerin listen ettiğini düzenli kontrol etmek gerekir. ss -lntup gibi araçlar açık socket'leri gösterir. Beklenmeyen public listener güvenlik riski olabilir. Database veya cache yalnızca local ya da private interface üzerinde dinlemelidir. Firewall ile process bind address birlikte değerlendirilmelidir.

Ubuntu'da Root Kullanıcıyla Uygulama Çalıştırılmalı mı?

Çoğu web uygulaması root yetkisine ihtiyaç duymaz. Uygulamanın root olarak çalışması, process compromise olduğunda saldırganın tüm sunucuda geniş yetki kazanmasına yol açabilir. Dedicated service user yalnızca gerekli dosyalara ve socket'lere erişmelidir. Deploy kullanıcısı da servis kullanıcısından ayrılabilir. Least privilege yaklaşımı production güvenliğinde basit ama etkili kontrollerden biridir.

Root Process Riskleri

Root process filesystem ve birçok kernel kaynağı üzerinde geniş yetkiye sahiptir. Application açığı doğrudan sistem yetkisine dönüşebilir. Yanlışlıkla çalıştırılan dosya işlemleri daha büyük zarar oluşturabilir. Web service için 80 veya 443 portuna doğrudan bind etme ihtiyacı reverse proxy ile ortadan kaldırılabilir. Bu nedenle root execution çoğu uygulamada gereksizdir.

Dedicated Service User

Her uygulama için ayrı service user oluşturmak failure isolation sağlar. Kullanıcı login shell'e ihtiyaç duymayabilir. Yalnızca application dosyaları ve gerekli runtime path'leri erişilebilir olmalıdır. Bir servis ele geçirilse bile başka uygulamanın dosyalarına ulaşması zorlaştırılır. systemd User ayarı bu modeli destekler.

Dedicated Deploy User

Deploy user artifact indirme ve release hazırlama görevini üstlenebilir. Application runtime user ile aynı olmak zorunda değildir. Sudo yetkisi yalnızca belirli systemctl veya symlink işlemleriyle sınırlandırılabilir. CI/CD credential bu hesaba bağlanabilir. Böylece deployment yetkisi full root erişimine dönüşmez.

Least Privilege

Least privilege kullanıcıya yalnızca görevi için gereken yetkiyi vermeyi amaçlar. Service yalnızca gerekli dizinlere yazabilmelidir. Network erişimi de gerekenden fazla olmamalıdır. systemd sandbox seçenekleri ek koruma sağlar. Yetki ihtiyacı değiştikçe izinler tekrar gözden geçirilmelidir.

Dosya Sahipliği ve İzinler

Application dosyalarının sahibi ve group yapısı baştan planlanmalıdır. Deploy user release dosyasını yazabilir, service user yalnızca okuyabilir. Mutable data için ayrı yazılabilir dizin kullanılmalıdır. Secret dosyaları daha dar izinlerle korunmalıdır. chmod 777 gibi genel çözümler production için uygun değildir.

Uygulama Dosyaları Ubuntu'da Nerede Tutulmalı?

Filesystem yerleşimi bakım ve güvenliği doğrudan etkiler. Application binary veya release dosyaları /opt ya da /srv altında tutulabilir. Web root ihtiyacı varsa /var/www kullanılabilir. Mutable application data için /var/lib, configuration için /etc, loglar için /var/log doğal alanlardır. Kod, config ve mutable data'yı ayırmak deployment ve backup stratejisini belirgin hale getirir.

/opt

/opt üçüncü taraf veya kendi application paketlerini tutmak için uygundur. Versioned release dizinleri burada rahatça oluşturulabilir. Örneğin /opt/myapp/releases yapısı kullanılabilir. Application code system package dosyalarından ayrılır. Rollback için eski release'leri saklamak kolaylaşır.

/srv

/srv sistem tarafından sunulan servis verileri için kullanılabilir. Web veya repository tabanlı bazı uygulamalar burada düzenlenebilir. Ekip standardı /opt yerine /srv seçebilir. Önemli olan tutarlı ve belgelenmiş yapıdır. Mutable ve immutable dosyalar yine ayrı tutulmalıdır.

/var/www

/var/www özellikle static web içerikleri için alışılmış bir dizindir. Nginx doğrudan buradan dosya servis edebilir. Full application runtime'ı burada tutmak şart değildir. Modern API servisleri /opt altında çalışırken static asset /var/www altında bulunabilir. Sahiplik web server ihtiyacına göre ayarlanmalıdır.

/var/lib

/var/lib servisin kalıcı mutable state'i için uygundur. Uygulamanın runtime sırasında ürettiği dosyalar burada tutulabilir. Release değiştiğinde bu data korunur. Backup politikası bu dizini ayrıca kapsayabilir. Permission yalnızca ilgili service user'a verilmelidir.

/etc

/etc sistem ve application configuration dosyalarının doğal yeridir. Örneğin /etc/myapp/myapp.env kullanılabilir. Config release artifact'ten ayrıldığı için aynı artifact farklı environment'ta çalışabilir. Secret izinleri burada sıkı tutulmalıdır. Config değişikliği version control veya configuration management üzerinden izlenmelidir.

/var/log

/var/log file tabanlı application loglarının klasik yeridir. Ancak systemd servislerinde stdout ve stderr'i journald'a göndermek çoğu zaman daha sade olabilir. File log kullanılıyorsa rotation zorunlu düşünülmelidir. Çok hızlı büyüyen log disk dolmasına yol açabilir. Merkezi log forwarding production görünürlüğünü artırır.

Kod, Config ve Mutable Data'yı Ayırmak

Kod immutable release olarak değiştirilebilir. Config environment'a göre ayrı yönetilir. Mutable data ise deployment sırasında korunmalıdır. Bu ayrım rollback'i çok daha güvenli hale getirir. Eski release'e dönerken user upload veya runtime data yanlışlıkla silinmez.

Önerilen Application Directory Yapısı

Versioned release yapısı küçük bir Ubuntu sunucuda bile deployment kalitesini yükseltebilir. Benim sık kullandığım modelde release'ler ayrı dizinlerde tutulur ve current symlink aktif sürümü gösterir. Shared data ve config release dizininden bağımsızdır. Böylece yeni sürüm hazırlanırken çalışan sürüme dokunulmaz. Health check başarılı olunca symlink değiştirilerek hızlı ve kontrollü geçiş yapılabilir.

/opt/myapp/releases

Her deployment ayrı release dizini oluşturur. Dizin adı timestamp, Git SHA veya release version olabilir. Eski birkaç stable release korunabilir. Yeni artifact burada unpack edilir. Çalışan current sürüm yeni release hazırlığından etkilenmez.

/opt/myapp/current

current aktif release dizinine işaret eden symlink olabilir. systemd WorkingDirectory veya ExecStart bu path üzerinden çalışabilir. Deployment sırasında symlink atomic biçimde değiştirilir. Ardından service reload veya restart uygulanır. Rollback eski release'e tekrar symlink vermek kadar hızlı olabilir.

/opt/myapp/shared

Release'ler arasında korunması gereken ortak dosyalar burada tutulabilir. User upload veya runtime-generated data buna örnek olabilir. Bu dizin her release içine symlink edilebilir. Backup policy ayrı uygulanır. Kod deploy sırasında shared içeriği silinmemelidir.

/etc/myapp

Application configuration için ayrı dizin kullanılması deployment artifact'ini temiz tutar. Environment variable dosyaları burada saklanabilir. Secret file permissions dar tutulur. Configuration management tool bu dizini yönetebilir. Release rollback sırasında config compatibility ayrıca kontrol edilmelidir.

/var/lib/myapp

Application state veya persistent internal data için kullanılabilir. Service user yazma yetkisine sahip olabilir. Backup ihtiyacı data tipine göre belirlenir. Temp dosyalar başka dizinde tutulmalıdır. Release artifact bu state üzerinde doğrudan ownership değiştirmemelidir.

/var/log/myapp

Application file log kullanıyorsa bu dizin uygun olabilir. Logrotate veya application rotation yapılandırılmalıdır. Service user'ın yazma yetkisi sınırlandırılır. Disk usage monitoring eklenmelidir. journald tercih ediliyorsa bu dizine ihtiyaç olmayabilir.

Application Runtime Nasıl Yönetilmelidir?

Runtime yönetiminde temel hedef aynı application release'in farklı deployment zamanlarında beklenmedik biçimde değişmemesidir. Python, Node.js, Java ve .NET sürümleri açıkça belirlenmelidir. Go gibi tek binary üretilebilen diller deployment'ı sadeleştirebilir. Runtime kurulumu server bootstrap veya configuration management üzerinden otomatikleştirilmelidir. Production sunucuda "mevcut en yeni sürümü kur" yaklaşımı yerine test edilen version kullanılmalıdır.

Python

Python uygulamalarında sistem Python'u ile application dependency'lerini karıştırmamak önemlidir. Virtual environment bağımlılıkları izole eder. WSGI için Gunicorn, ASGI için Uvicorn veya benzeri production server kullanılabilir. Development server production'a taşınmamalıdır. Runtime ve package sürümleri lock dosyalarıyla kontrol edilmelidir.

venv

venv uygulamaya özel Python ortamı oluşturur. Dependency'ler sistem package alanından ayrılır. Her release kendi virtual environment'ını taşıyabilir veya build artifact içinde hazır gelebilir. Activation shell'e bağlı olmak zorunda değildir. systemd doğrudan virtual environment içindeki executable path'i çalıştırabilir.

Gunicorn

Gunicorn production WSGI uygulamalarında process yönetimi sağlayabilir. Worker sayısı workload ve CPU kapasitesine göre ayarlanmalıdır. systemd Gunicorn ana process'ini yönetebilir. Nginx local TCP veya Unix socket üzerinden bağlanabilir. Timeout ve graceful shutdown değerleri deployment modeliyle uyumlu olmalıdır.

Uvicorn

Uvicorn ASGI uygulamaları için yaygın bir server seçeneğidir. Async web framework'lerle kullanılabilir. systemd doğrudan Uvicorn çalıştırabilir veya Gunicorn worker modeliyle birlikte kullanılabilir. Proxy header ayarları reverse proxy kullanımına göre yapılandırılmalıdır. Worker restart ve graceful shutdown davranışı test edilmelidir.

Node.js

Node.js servisleri production ortamında belirli runtime version ile çalışmalıdır. Application doğrudan systemd tarafından yönetilebilir. Ayrı process manager kullanmak zorunlu değildir. stdout ve stderr journald'a gönderilebilir. Graceful shutdown için SIGTERM handling application içinde doğru uygulanmalıdır.

Node runtime

Node major ve minor version farkları application davranışını etkileyebilir. CI ve production aynı version'ı kullanmalıdır. Runtime version manager yerine server bootstrap'ta fixed package source tercih edilebilir. Container kullanılıyorsa image tag veya digest runtime'ı sabitler. Deployment metadata runtime version'ı içerebilir.

systemd

systemd Node process'ini doğrudan başlatabilir. Restart=on-failure crash sonrası kontrollü recovery sağlar. EnvironmentFile ile config uygulanabilir. Memory limit cgroup üzerinden sınırlandırılabilir. Bu yapı küçük ve orta ölçekli Ubuntu servislerinde oldukça sade bir operasyon modeli sunar.

Go

Go uygulamaları çoğu zaman tek binary olarak deploy edilebilir. Runtime dependency az olduğu için server kurulumu sadeleşir. Binary CI içinde cross-compile edilip artifact olarak sunucuya gönderilebilir. systemd doğrudan executable'ı çalıştırabilir. Health endpoint ve graceful shutdown yine application içinde uygulanmalıdır.

Static binary

Statik veya az bağımlılıklı binary deployment tekrar üretilebilirliğini artırabilir. Sunucuda build toolchain gerekmez. Artifact checksum ile doğrulanabilir. Rollback eski binary'ye dönmek kadar basit olabilir. İşletim sistemi compatibility gereksinimleri yine test edilmelidir.

Java

Java servisleri JVM üzerinde çalışır. Runtime major version application build'iyle uyumlu olmalıdır. JAR artifact CI içinde üretilip sunucuya taşınabilir. systemd JVM process'ini doğrudan yönetebilir. Heap ve GC ayarları sunucu kaynaklarına göre belirlenmelidir.

JVM

JVM sürümü deployment environment'ın önemli parçasıdır. Java 17 ile test edilen uygulamanın farklı major version'da çalıştırılması beklenmeyen davranış oluşturabilir. Memory limit ile JVM heap ayarı uyumlu olmalıdır. Container veya systemd cgroup limiti dikkate alınmalıdır. Runtime metric'leri monitoring sistemine aktarılabilir.

JAR

JAR immutable deployment artifact olarak saklanabilir. Release version ve Git SHA artifact metadata içinde tutulabilir. Sunucuda yeniden build alınmamalıdır. systemd ExecStart satırı belirli JAR path'ini çalıştırır. Rollback eski JAR ve config compatibility kontrolüyle yapılabilir.

.NET

.NET uygulamaları framework-dependent veya self-contained biçimde deploy edilebilir. Kestrel backend server olarak kullanılabilir. Public trafik genellikle Nginx üzerinden Kestrel'e aktarılır. Runtime version CI ve production arasında aynı tutulmalıdır. systemd application process'ini yönetebilir.

Kestrel

Kestrel production web server olarak güçlü bir backend sunar. Public internet için reverse proxy arkasında kullanılması sık rastlanan modeldir. Localhost port veya Unix socket üzerinde dinleyebilir. Forwarded header ayarları güvenilir proxy sınırıyla yapılandırılmalıdır. Graceful shutdown deployment sırasında test edilmelidir.

Runtime Sürümlerini Pinlemek

Runtime sürümünü pinlemek reproducibility için önemlidir. Major update application davranışını değiştirebilir. CI ortamında kullanılan version production'da da uygulanmalıdır. Package repository update sonucu sessiz version değişimi engellenmelidir. Sürüm yükseltmeleri ayrı change olarak test edilmelidir.

Ubuntu'da systemd Nedir?

systemd modern Ubuntu sistemlerinde init ve service manager görevini üstlenir. PID 1 olarak boot sürecini yönetir ve servis dependency'lerini düzenler. Application servisleri start, stop, restart ve reload gibi yaşam döngüsü işlemlerini systemd üzerinden alabilir. Restart policy, resource control ve sandbox ayarları aynı unit içinde tanımlanabilir. Ubuntu server systemd servis oluşturma ve yönetme nasıl yapılır sorusunun temelinde unit dosyalarının doğru anlaşılması vardır.

PID 1

Linux sisteminde PID 1 özel role sahiptir. systemd çoğu Ubuntu sürümünde bu process olarak çalışır. Servislerin başlatılması ve shutdown sırası buradan yönetilir. Orphan process davranışında da PID 1 önemlidir. Application process'i systemd supervision altında daha kontrollü çalışır.

Service Management

systemd servisleri unit dosyalarıyla tanımlar. systemctl komutu yönetim arayüzüdür. Servis status, restart ve enable işlemleri merkezi biçimde yapılır. Boot sonrası otomatik başlangıç ayarlanabilir. Failure state monitoring sistemine bağlanabilir.

Dependency Management

Unit'ler diğer servislerle order ve requirement ilişkisi tanımlayabilir. Network hazır olmadan application başlatılmaması gerekebilir. Mount dependency veya database service ilişkisi kurulabilir. Ancak After ile Requires aynı anlama gelmez. Dependency davranışı unit tasarımında dikkatle seçilmelidir.

Automatic Restart

Application beklenmedik şekilde çıktığında systemd yeniden başlatabilir. Restart=on-failure bu amaçla sık kullanılır. Restart storm oluşmaması için limit ve delay uygulanmalıdır. Sürekli başarısız process sonsuz hızda yeniden çalıştırılmamalıdır. Permanent failure durumunda alert üretilmelidir.

Logging

systemd servis stdout ve stderr çıktısını journald üzerinden toplayabilir. journalctl -u servisadi ile ilgili servis logları görülebilir. Timestamp ve boot bilgisi otomatik eklenir. Log filtering troubleshooting süresini azaltır. Disk retention ayrıca yapılandırılmalıdır.

Timers

systemd timer zamanlanmış görevleri servis unit'leriyle ilişkilendirir. Cron'a alternatif olabilir. Execution logları journald içinde görülebilir. Missed run davranışı belirli ayarlarla yönetilebilir. Backup ve maintenance işleri için kullanışlıdır.

Socket Activation

Socket activation'da systemd socket'i application process'ten önce açabilir. İlk connection geldiğinde servis başlatılabilir. Restart sırasında socket'in açık kalması bazı tasarımlarda bağlantı kaybını azaltır. Unix veya TCP socket kullanılabilir. Her web framework bu modeli aynı kolaylıkla desteklemez.

Resource Control

systemd cgroup tabanlı kaynak sınırları uygulayabilir. CPU, memory ve task sayısı kontrol edilebilir. Tek bir servisin tüm sunucuyu tüketmesi engellenebilir. Limit aşımı monitoring'e bağlanmalıdır. Kaynak değerleri gerçek workload testlerine göre belirlenmelidir.

systemctl ile Temel Servis Yönetimi

systemctl systemd servislerini yönetmek için kullanılan ana araçtır. Start ve stop process yaşam döngüsünü değiştirir, status çalışma durumunu gösterir. Enable ile servis boot sırasında otomatik başlatılabilir. Disable veya mask farklı seviyelerde servis activation'ını engeller. Operasyon script'lerinde is-active ve is-enabled gibi kontrol komutları automation için faydalıdır.

start

systemctl start myapp servisi hemen başlatır. Bu işlem boot autostart durumunu değiştirmez. Unit dependency'leri uygulanır. Başarısızlık status ve journal üzerinden incelenebilir. Deployment sonrası health check ayrıca yapılmalıdır.

stop

systemctl stop myapp servisi durdurur. systemd configured stop signal ve timeout'u uygular. Application graceful shutdown destekliyorsa aktif işler tamamlanabilir. Stop sonrası socket veya child process kalıp kalmadığı kontrol edilebilir. Maintenance sırasında kullanılabilir.

restart

restart servisi durdurup tekrar başlatır. Aktif connection'lar etkilenebilir. Yeni binary veya bazı config değişiklikleri için gerekli olabilir. Zero-downtime hedefi varsa tek process restart yeterli olmayabilir. Health check restart sonrası çalıştırılmalıdır.

reload

reload servis destekliyorsa process'i kapatmadan configuration yeniden yükler. Nginx bunun iyi örneğidir. Application unit içinde ExecReload tanımlanabilir. Reload her serviste mevcut değildir. Desteklenmediği durumda restart gerekir.

status

systemctl status servis state'i, son loglar ve process bilgisi verir. İlk troubleshooting komutlarından biridir. Exit code ve failure nedeni görülebilir. Ancak yalnızca service active bilgisi application'ın kullanıcıya doğru cevap verdiğini garanti etmez. Health endpoint ile birlikte kullanılmalıdır.

enable

enable servis unit'ini uygun boot target'a bağlar. Sonraki reboot sırasında otomatik başlatılabilir. Mevcut anda servisi başlatmaz. --now ile enable ve start birlikte yapılabilir. Production servislerinde boot recovery için önemlidir.

disable

disable boot sırasında otomatik activation bağlantısını kaldırır. Çalışan servisi otomatik olarak durdurmaz. Bakım veya devre dışı bırakılmış eski servislerde kullanılabilir. Dependency başka şekilde servisi başlatabilir. Kesin engelleme gerekiyorsa mask değerlendirilebilir.

mask

mask servisin manuel veya dependency üzerinden başlatılmasını güçlü biçimde engeller. Yanlış service activation'ını önlemek için kullanışlıdır. Yeniden kullanmak için unmask gerekir. Production'da neden mask edildiği dokümante edilmelidir. Kritik servis üzerinde yanlış mask outage oluşturabilir.

is-active

is-active servisin çalışma durumunu script içinde kontrol etmek için uygundur. Exit code automation kararında kullanılabilir. Deployment health check için tek başına yeterli değildir. Process active olup HTTP endpoint başarısız olabilir. Application-level doğrulama eklenmelidir.

is-enabled

is-enabled servisin boot activation durumunu kontrol eder. Configuration management drift tespitinde kullanılabilir. Servis çalışıyor olsa bile disabled olabilir. Reboot sonrası beklenmedik outage bu nedenle yaşanabilir. Deployment checklist bu kontrolü içerebilir.

restart ile reload Arasındaki Fark

Restart process'i tamamen yeniden başlatırken reload mevcut process'e configuration değişikliğini yeniden okumasını söyler. Bu ayrım özellikle Nginx gibi aktif connection taşıyan servislerde önemlidir. Reload doğru uygulanırsa mevcut connection'lar kesilmeden yeni config devreye alınabilir. Application server reload davranışı kullanılan runtime'a göre değişir. Hangi servisin hangi yöntemi desteklediği runbook içinde açıkça belirtilmelidir.

Full Process Restart

Full restart mevcut process'i sonlandırır ve yeni process başlatır. Memory state temizlenir. Yeni binary kesin olarak yüklenir. Ancak connection kesintisi oluşabilir. Tek instance sistemlerde kullanıcı etkisi daha belirgin olabilir.

Graceful Configuration Reload

Graceful reload çalışan bağlantıları koruyarak yeni configuration uygulamayı hedefler. Nginx yeni worker process'ler başlatıp eskilerin işleri tamamlamasını bekleyebilir. Böylece config değişikliği daha az kesintiyle uygulanır. Config syntax test reload'dan önce yapılmalıdır. Application service de benzer signal handling destekleyebilir.

Aktif Connection'lara Etkisi

Restart sırasında uzun HTTP request veya WebSocket bağlantısı kesilebilir. Reload ise servis desteğine göre mevcut connection'ların tamamlanmasına izin verebilir. Streaming servislerinde bu ayrım daha önemlidir. Deployment sırasında connection drain kullanılabilir. Client retry davranışı da hesaba katılmalıdır.

Hangi Serviste Hangisi Kullanılmalı?

Config değişikliğini hot reload destekleyen servislerde reload tercih edilebilir. Binary değiştiyse genellikle restart gerekir. Nginx config güncellemesinde reload uygundur. Application service yeni release'e geçtiğinde blue-green veya graceful restart modeli kullanılabilir. Karar servis dokümantasyonu ve gerçek test sonuçlarına göre verilmelidir.

reload-or-restart

reload-or-restart reload destekleniyorsa onu, desteklenmiyorsa restart davranışını kullanabilir. Automation script'lerinde pratik olabilir. Ancak active connection etkisini anlamadan kullanmak doğru değildir. Critical service için davranış önceden test edilmelidir. Deployment log hangi action'ın çalıştığını göstermelidir.

systemd Service Unit Nasıl Oluşturulur?

systemd service unit uygulamanın nasıl başlatılacağını, hangi kullanıcıyla çalışacağını ve failure durumunda nasıl davranacağını tanımlar. Unit çoğunlukla /etc/systemd/system altında oluşturulur. [Unit] metadata ve dependency'leri, [Service] process davranışını, [Install] ise enable ilişkisinin nasıl kurulacağını belirler. Değişiklik sonrası systemctl daemon-reload çalıştırılmalıdır. Unit mümkün olduğunca açık, sade ve application gereksinimleriyle sınırlı tutulmalıdır.

[Unit]

[Unit] servisin açıklama ve dependency bilgilerini tutar. Başlatma sırası burada belirlenebilir. Network veya başka servislerle ilişki kurulabilir. Requirement ve ordering farklı kavramlardır. Yanlış dependency boot sırasında gecikme veya failure oluşturabilir.

Description

Description unit'in insanlar tarafından okunabilir açıklamasıdır. Status çıktısında görünür. Uygulama ve rol bilgisini açık yazmak faydalıdır. Çok genel isimler operasyon sırasında karışıklık yaratır. Environment ismi gerekirse açıklamaya eklenebilir.

After

After yalnızca ordering ilişkisi tanımlar. Belirtilen unit'in mutlaka başarıyla çalışmasını gerektirmez. Network target sonrası başlatma için kullanılabilir. Application'ın gerçek network hazır olma ihtiyacı ayrıca düşünülmelidir. Ordering ile dependency aynı şey değildir.

Wants

Wants daha zayıf dependency ilişkisi oluşturur. İlgili unit başlatılmaya çalışılır ancak başarısız olması ana servisi her zaman düşürmez. Yardımcı servislerde uygun olabilir. Critical dependency için yeterli olmayabilir. Uygulama failure mode'a göre seçilmelidir.

Requires

Requires daha güçlü dependency tanımlar. Bağımlı unit başlatılamazsa ana servisin davranışı etkilenebilir. Her external service için kullanılması doğru değildir. Remote database gibi systemd tarafından yönetilmeyen bağımlılık burada temsil edilemez. Health ve retry application seviyesinde ayrıca uygulanmalıdır.

[Service]

[Service] application process'inin gerçek çalışma davranışını tanımlar. Type, user, working directory ve start command burada bulunur. Restart ve environment ayarları da bu bölümde yer alır. Security sandbox seçenekleri ayrıca eklenebilir. Unit'in en kritik kısmı çoğu zaman burasıdır.

Type

Type systemd'nin servisin ne zaman başlamış kabul edileceğini belirler. Modern foreground application'larda simple veya exec sık kullanılır. notify service readiness sinyali verebildiğinde daha doğru olabilir. Forking eski daemon modelleri içindir. Yanlış type readiness davranışını bozabilir.

User

User application process'inin hangi Linux hesabıyla çalışacağını belirler. Dedicated non-root kullanıcı kullanılmalıdır. Kullanıcının yalnızca gereken dosyalara erişimi olmalıdır. Login yetkisi kapatılabilir. Root seçmek son çare olmalıdır.

Group

Group process'in primary group'unu belirler. Unix socket permission paylaşımı için kullanılabilir. Nginx ve application ortak group üzerinden socket erişimi kurabilir. Grup üyeliği gereksiz genişletilmemelidir. File ownership modeliyle tutarlı olmalıdır.

WorkingDirectory

WorkingDirectory process'in başlangıç çalışma dizinidir. Relative path kullanan uygulamalarda önemlidir. /opt/myapp/current gibi symlink kullanılabilir. Release swap sonrası restart yeni dizini kullanır. Uygulamanın mutable dosyayı working directory içine yazmaması daha güvenlidir.

EnvironmentFile

EnvironmentFile environment variable değerlerini ayrı dosyadan yükleyebilir. Config koddan ayrılır. File permission dar tutulmalıdır. Secret içeriyorsa backup ve process environment riskleri değerlendirilmelidir. Değişiklik sonrası service restart gerekebilir.

ExecStart

ExecStart servisin çalıştıracağı ana komuttur. Absolute path kullanmak belirsizliği azaltır. Shell expansion beklenmemelidir. Virtual environment executable doğrudan çağrılabilir. Command manuel test edilmeden unit içine alınmamalıdır.

ExecReload

ExecReload reload sırasında çalıştırılacak komutu tanımlar. Application signal ile config reload destekliyorsa kullanılabilir. Yanlış reload process'i beklenmedik state'e sokabilir. Reload sonrası health check uygulanmalıdır. Desteklenmiyorsa tanımlanmaması daha doğrudur.

Restart

Restart process çıktığında systemd'nin nasıl davranacağını belirler. Web servislerinde on-failure sık kullanılan seçenektir. Manual stop sonrası yeniden başlamaması operasyonu kolaylaştırır. always bazı worker veya daemon senaryolarında tercih edilebilir. Restart storm limiti ayrıca tanımlanmalıdır.

[Install]

[Install] unit enable edildiğinde hangi target ile ilişki kurulacağını tanımlar. Production application'lar çoğunlukla multi-user target altında çalışır. Enable boot sırasında otomatik başlangıç sağlar. Unit çalıştırmak için Install bölümü her durumda zorunlu değildir. Ancak standard service deployment'ta açık tanım faydalıdır.

WantedBy

WantedBy=multi-user.target server servislerinde sık kullanılan ayardır. systemctl enable ilgili symbolic link'i oluşturur. Reboot sonrası servis doğru target içinde başlatılır. Enable sonrası is-enabled ile doğrulama yapılabilir. Boot test deployment checklist'e eklenmelidir.

systemd Type Seçimi

systemd service type seçimi process'in readiness ve lifecycle davranışını etkiler. Foreground çalışan modern web servislerinde simple veya exec çoğu zaman yeterlidir. Application systemd notification protokolünü destekliyorsa notify daha doğru readiness bilgisi verir. Forking geleneksel daemon'lar için, oneshot ise kısa görevler için uygundur. Type seçimini eski örneklerden kopyalamak yerine process'in gerçekten nasıl çalıştığına göre yapmak gerekir.

simple

simple ExecStart process başlatıldığında servis başladı kabul edilir. Foreground application için uygundur. Process başka child oluşturmadan ana process olarak kalır. Readiness tamamlanmadan systemd started state gösterebilir. Health check bunu tamamlamalıdır.

exec

exec executable gerçekten çalıştırıldığında start başarısını daha net ele alır. Command bulunamadığında failure daha erken anlaşılır. Modern foreground service için iyi seçim olabilir. Application readiness yine ayrıca ölçülmelidir. Daemonize olan servisler için uygun değildir.

notify

notify application systemd'ye hazır olduğunu bildirebildiğinde kullanılır. Startup initialization tamamlanmadan service ready sayılmaz. Dependency zincirlerinde daha doğru davranış sağlar. Application veya runtime notification desteği sunmalıdır. Health check yine dış doğrulama olarak değer taşır.

forking

forking process'in daemonize olup parent process'ten ayrıldığı eski model içindir. PIDFile gerekebilir. Modern uygulamalarda foreground çalışma daha sade yönetilir. Yanlış forking ayarı systemd'nin ana process'i kaybetmesine yol açabilir. Mümkünse native foreground mode tercih edilmelidir.

oneshot

oneshot kısa süreli görevler için tasarlanmıştır. Migration, setup veya maintenance scriptlerinde kullanılabilir. Process bitince unit tamamlanmış sayılır. RemainAfterExit bazı durumlarda state tutabilir. Sürekli çalışan web service için uygun değildir.

Modern Web Servisleri İçin Hangi Type?

Çoğu modern web application foreground process olarak çalıştırılabilir. Bu durumda simple veya exec pratik tercihtir. Readiness notification desteği varsa notify daha güçlü olabilir. Application'ın daemonize edilmesi gereksizdir. Kesin seçim runtime ve framework davranışı test edilerek yapılmalıdır.

Servis Crash Olduğunda systemd Ne Yapmalıdır?

Production servisin hiç crash olmaması gerçekçi hedef değildir. Daha önemli soru failure olduğunda sistemin kontrollü biçimde nasıl davranacağıdır. systemd belirli exit durumlarında restart uygulayabilir. Restart gecikmesi ve start limit ayarları crash loop'un sunucuyu tüketmesini önler. Sürekli başarısız servis sonunda permanent failure state'e geçmeli ve on-call ekibe alarm üretmelidir.

Restart=on-failure

Restart=on-failure process beklenmedik hata ile çıktığında yeniden başlatır. Manual stop genellikle restart tetiklemez. Web application için dengeli bir seçenektir. Exit code davranışı application tarafından anlamlı kullanılmalıdır. Monitoring restart sayısını takip etmelidir.

Restart=always

always process normal çıksa bile yeniden başlatmayı hedefler. Sürekli çalışması gereken bazı worker'larda uygun olabilir. Manual stop davranışı systemd yönetiminde ayrıca değerlendirilmelidir. Bilerek tamamlanan task için uygun değildir. Yanlış kullanım gereksiz loop oluşturabilir.

RestartSec

RestartSec failure ile yeni deneme arasına gecikme koyar. Çok kısa değer dependency outage sırasında restart storm yaratabilir. Çok uzun değer recovery süresini artırabilir. Servis karakterine göre seçilmelidir. Exponential backoff application tarafında ayrıca gerekebilir.

Crash Loop

Crash loop process'in başlar başlamaz tekrar tekrar düşmesidir. Yanlış config veya eksik dependency sık sebeptir. Sürekli restart log ve CPU tüketimini artırır. Start limit devreye girmelidir. Alert root cause araştırmasını başlatmalıdır.

Restart Storm

Çok sayıda instance aynı anda hızlı restart yaparsa downstream sistemler yük altında kalabilir. Database connection storm buna örnektir. Restart delay ve jitter büyük fleet sistemlerinde faydalıdır. systemd tek host seviyesinde limit sağlar. Deployment platformu fleet-wide kontrolü ayrıca yönetmelidir.

Start Limit

Start limit belirli zaman penceresinde kaç restart denemesine izin verileceğini sınırlar. Sürekli başarısız servis bir noktada stopped failure state'e geçer. Bu davranış sonsuz restart'tan daha güvenlidir. Limit değerleri troubleshooting ihtiyacına göre seçilmelidir. Alert bu state'i yakalamalıdır.

Permanent Failure Durumu

Servis belirlenen deneme sayısından sonra hâlâ başlayamıyorsa insan müdahalesi gerekebilir. systemd failure state açıkça görünmelidir. Monitoring incident oluşturabilir. Rollback veya config düzeltmesi uygulanabilir. Automation sorunu anlamadan sonsuz tekrar yapmamalıdır.

systemd Service Hardening

systemd yalnızca process manager değil, application yetkilerini daraltabilecek önemli güvenlik kontrolleri de sunar. NoNewPrivileges, ProtectSystem ve PrivateTmp gibi ayarlar process'in erişebildiği kaynakları sınırlar. Her seçeneği kör biçimde açmak uygulamayı bozabilir. Önce servisin gerçekten hangi dosya, device ve network kaynaklarına ihtiyaç duyduğu belirlenmelidir. Hardening staging üzerinde test edilerek kademeli uygulanmalıdır.

NoNewPrivileges

NoNewPrivileges process ve child process'lerin ek privilege kazanmasını engellemeye yardımcı olur. Birçok web service için uygundur. Setuid mekanizması gereken uygulamalarda sorun çıkarabilir. Uygulama davranışı test edilmelidir. Least privilege yaklaşımını güçlendirir.

ProtectSystem

ProtectSystem filesystem'in bazı bölümlerini read-only hale getirebilir. Application'ın system directory'lerini değiştirmesini engeller. Yazması gereken path'ler ayrı izinle açılabilir. Mutable data'nın /var/lib/myapp altında tutulması bu modeli kolaylaştırır. Staging testinde write path'leri doğrulanmalıdır.

ProtectHome

ProtectHome service'in kullanıcı home dizinlerine erişimini sınırlar. Web application çoğu zaman home içeriğine ihtiyaç duymaz. Credential leakage riskini azaltır. Application kodu home altında tutuluyorsa yapı değiştirilmesi gerekebilir. Standard filesystem düzeni hardening'i kolaylaştırır.

PrivateTmp

PrivateTmp servis için izole temp alanı sağlar. Diğer process'lerin temporary file'larına erişimi azaltır. Application normal temp API kullanıyorsa genellikle sorunsuz çalışır. Shared temp file bekleyen legacy sistemlerde sorun çıkabilir. Kullanım öncesi test edilmelidir.

PrivateDevices

PrivateDevices service'in device erişimini sınırlar. Çoğu web API özel hardware device kullanmaz. Bu nedenle ek güvenlik sağlayabilir. GPU veya özel device gerektiren workload için uygun olmayabilir. Servis ihtiyacına göre karar verilmelidir.

ProtectKernelTunables

Bu ayar process'in kernel tunable alanlarını değiştirmesini sınırlar. Normal application için bu erişim çoğu zaman gereksizdir. Compromise etkisini azaltabilir. Low-level system daemon'larda ihtiyaç olabilir. Web service için staging testinden sonra uygulanabilir.

ProtectKernelModules

Kernel module yükleme veya değiştirme yetkisini sınırlar. Application process'inin böyle bir yetkiye ihtiyacı olmamalıdır. Güvenlik sınırını güçlendirir. Sistem management servislerinde dikkat gerekir. Dedicated application unit için çoğu zaman uygundur.

ProtectControlGroups

Control group hierarchy'ye yazma erişimini sınırlar. Application'ın system resource management yapısını değiştirmesini engeller. Normal web process için faydalıdır. Container runtime gibi cgroup yönetimi gereken servislerde uygulanamaz. Servis rolü göz önünde tutulmalıdır.

RestrictNamespaces

Linux namespace oluşturma yetkisi sınırlandırılabilir. Birçok application bunu kullanmaz. Sandbox kaçış alanını azaltabilir. Container veya browser benzeri process namespace ihtiyacı duyabilir. Bu nedenle application test edilmeden production'a uygulanmamalıdır.

RestrictAddressFamilies

Servisin kullanabileceği socket family'leri sınırlandırılabilir. Yalnızca IPv4, IPv6 ve Unix socket gerektiren web uygulaması daha dar listeyle çalışabilir. Gereksiz network capability azalır. DNS ve local IPC ihtiyacı düşünülmelidir. Yanlış kısıtlama beklenmeyen bağlantı hatası oluşturabilir.

ReadWritePaths

Read-only filesystem hardening kullanırken application'ın gerçekten yazması gereken dizinler açıkça belirtilebilir. Örneğin /var/lib/myapp ve belirli upload dizini writable olabilir. Bu yaklaşım accidental write riskini azaltır. Temp ve log path davranışı ayrıca kontrol edilmelidir. Permission modeli service user ile uyumlu olmalıdır.

systemd Servisinde Kaynak Limitleri

Tek bir application process'in bütün CPU veya memory'yi tüketmesi aynı sunucudaki diğer servisleri etkileyebilir. systemd cgroup tabanlı limitlerle bu riski azaltabilir. CPUQuota ve MemoryMax gibi ayarlar kritik kaynakları sınırlar. TasksMax process sayısını, LimitNOFILE ise open file limitini kontrol eder. Değerler tahminle değil load test ve production metric'leriyle belirlenmelidir.

CPUQuota

CPUQuota servis için kullanılabilecek CPU miktarını sınırlayabilir. Yanlış kod sonsuz loop'a girse bile tüm host CPU'yu tüketmesi engellenebilir. Çok düşük değer latency artışına yol açar. Burst workload düşünülmelidir. Monitoring throttling etkisini göstermelidir.

MemoryMax

MemoryMax cgroup memory kullanımına üst sınır koyar. Memory leak bütün sunucunun swap veya OOM sorunu yaşamasını önleyebilir. Limit aşılırsa process sonlandırılabilir. Application heap ayarı bu sınırla uyumlu olmalıdır. Alert limit yaklaşımını önceden göstermelidir.

TasksMax

TasksMax process ve thread sayısını sınırlar. Fork bomb veya kontrolsüz worker artışına karşı koruma sağlayabilir. Java veya yüksek concurrency runtime daha fazla thread isteyebilir. Değer gerçek workload'a göre ayarlanmalıdır. Limit aşım logları gözlenmelidir.

LimitNOFILE

Open file descriptor limiti yüksek bağlantılı servislerde önemlidir. Çok düşük limit connection failure oluşturabilir. Çok yüksek değer tek başına capacity problemi çözmez. Nginx ve application limitleri uyumlu olmalıdır. Kernel-level limitler de kontrol edilmelidir.

IOWeight

Disk I/O paylaşımında servis önceliğini etkileyebilir. Aynı hostta backup job ile production database yarışıyorsa faydalı olabilir. Her filesystem ve scheduler ortamında etkisi aynı olmayabilir. I/O bottleneck önce metric ile doğrulanmalıdır. Kritik workload'a daha uygun ağırlık verilebilir.

Bir Servisin Tüm Sunucuyu Tüketmesini Önlemek

Kaynak limitlerinin amacı application'ı cezalandırmak değil failure isolation sağlamaktır. CPU, memory ve process limitleri birlikte kullanılabilir. Disk ve log growth ayrıca kontrol edilmelidir. Aynı sunucuda birden fazla service varsa limitler daha önemli hale gelir. Capacity planlama yine toplam host kaynaklarına göre yapılmalıdır.

systemd Unit Dosyaları Nasıl Değiştirilmeli?

Paket yöneticisinin sağladığı unit dosyasını doğrudan değiştirmek güncelleme sırasında değişikliklerin kaybolmasına yol açabilir. Yerel custom unit'ler /etc/systemd/system altında tutulmalıdır. Vendor unit için drop-in override kullanmak daha güvenlidir. systemctl edit bu süreci kolaylaştırır. Her değişiklik sonrası daemon-reload ve status doğrulaması yapılmalıdır.

/lib/systemd/system

Ubuntu paketleri unit dosyalarını çoğu zaman bu alan veya ilgili vendor dizinleri altında sağlar. Dosyalar package ownership altındadır. Paket upgrade içeriği değiştirebilir. Doğrudan manuel düzenleme kalıcı yöntem değildir. Override yaklaşımı tercih edilmelidir.

/etc/systemd/system

Yerel administrator unit ve override'ları için doğru alandır. Custom application service burada tutulabilir. Configuration management bu dosyaları versioned template ile yönetebilir. Package update bunları overwrite etmez. Permission ve syntax kontrol edilmelidir.

Drop-In Override

Drop-in belirli unit ayarlarını vendor dosyasını kopyalamadan değiştirmeyi sağlar. Yalnızca gereken satırlar override edilir. Paket update ile yeni default'lar alınmaya devam eder. Değişiklik kapsamı daha anlaşılır olur. systemctl cat birleşik configuration'ı gösterebilir.

systemctl edit

systemctl edit servis güvenli drop-in oluşturmayı kolaylaştırır. Editor açılır ve override dosyası doğru yere kaydedilir. Yanlış tam unit kopyası oluşturma riski azalır. Sonrasında daemon-reload gerekir. Configuration management ortamında manuel edit yerine template kullanılabilir.

systemctl cat

systemctl cat vendor unit ve drop-in'lerin birleşik görünümünü verir. Troubleshooting sırasında hangi ayarın nereden geldiğini anlamak kolaylaşır. Birden fazla override varsa sıraları görülebilir. Beklenmeyen config drift hızlı bulunur. Deployment debug için değerli komuttur.

daemon-reload

Unit file değişiklikleri systemd manager tarafından otomatik okunmayabilir. systemctl daemon-reload unit tanımlarını yeniden yükler. Bu işlem servisi otomatik restart etmez. Sonrasında restart veya reload ihtiyacı ayrı değerlendirilir. Automation bu adımı değişiklik sonrası koşullu çalıştırabilir.

Paket Tarafından Sağlanan Unit'i Doğrudan Değiştirmemek

Vendor file üzerinde manuel değişiklik package upgrade sırasında kaybolabilir. Hangi satırın yerel olduğu da anlaşılması zorlaşır. Drop-in override daha temiz ve sürdürülebilir yöntemdir. Configuration review kolaylaşır. Bu yaklaşım özellikle Nginx veya database servislerinde önemlidir.

systemd Socket Activation Nedir?

Socket activation, connection kabul eden socket'in application service'ten ayrı olarak systemd tarafından yönetilmesini sağlar. Socket process başlamadan önce hazır olabilir. İstek geldiğinde servis başlatılabilir veya restart sırasında socket açık kalabilir. Bu model bazı servislerde availability avantajı sağlar. Ancak application'ın socket activation protokolünü doğru desteklemesi gerekir.

.socket Unit

.socket unit hangi Unix veya TCP socket'in açılacağını tanımlar. systemd socket'i dinler. Connection geldiğinde ilgili service tetiklenebilir. Permission socket seviyesinde yönetilebilir. Web application framework desteği kontrol edilmelidir.

.service Unit

.service unit gerçek application process'ini başlatır. Socket file descriptor service'e aktarılabilir. Process kendi socket'ini bind etmek zorunda kalmaz. Restart sırasında listener systemd tarafında kalabilir. Application integration doğru yapılmalıdır.

Unix Socket

Unix socket aynı host üzerindeki process'ler için kullanılabilir. Filesystem permission ile erişim kontrol edilir. Nginx backend bağlantısında sık tercih edilir. TCP port yönetimi gerekmez. Container senaryolarında volume paylaşımı ek ihtiyaç oluşturabilir.

TCP Socket

systemd local veya public TCP socket açabilir. Localhost kullanımında application process bind işlemi systemd tarafından yönetilir. Port readiness application startup'tan bağımsız olabilir. Firewall exposure ayrıca kontrol edilmelidir. Her framework inherited socket'i desteklemez.

Restart Sırasında Connection Yönetimi

Socket activation bazı tasarımlarda restart sırasında yeni connection'ları socket queue'da tutabilir. Application geri geldiğinde işlemler devam eder. Bu davranış gerçek zero-downtime garantisi değildir. Uzun active request state'i ayrıca yönetilmelidir. Load test ile doğrulanmalıdır.

Zero-Downtime Tasarımdaki Rolü

Socket activation connection endpoint'i process lifecycle'dan ayırdığı için kesintiyi azaltabilir. Ancak çoğu modern web deployment blue-green veya load balancer üzerinden daha açık kontrol sağlar. Tek sunucuda faydalı bir seçenek olabilir. Application desteği yoksa zorlamak gereksizdir. Kullanılacak yöntem operasyon ekibinin anlayacağı kadar sade olmalıdır.

Unix Socket mı TCP Localhost mı?

Nginx ile application arasında Unix socket ve localhost TCP iki yaygın seçenektir. Unix socket filesystem permission üzerinden erişim kontrolü sağlar. TCP localhost ise debug ve container integration açısından çoğu ekip için daha kolaydır. Performance farkı çoğu web uygulamasında kararın ana nedeni olmamalıdır. Ben seçim yaparken ekip operasyon kolaylığını ve deployment modelini ham performanstan daha önemli görüyorum.

Unix Domain Socket

Unix socket yalnızca aynı host içindeki process'ler arasında çalışır. Public network exposure yoktur. File permission ile Nginx erişimi kontrol edilir. Path cleanup deployment sırasında düşünülmelidir. Socket ownership yanlışsa 502 hatası oluşabilir.

127.0.0.1:PORT

Localhost TCP uygulamayı dış internete açmadan network socket kullanır. curl ile test etmek kolaydır. Nginx proxy_pass ile basit bağlanır. Birden fazla instance farklı portlarda çalışabilir. Firewall yine public bind olmadığını doğrulamalıdır.

Permission Yönetimi

Unix socket filesystem ownership gerektirir. Nginx worker group ile application group uyumlu olmalıdır. TCP localhost'ta erişim daha çok bind address ve host firewall ile yönetilir. Her iki modelde least privilege mümkündür. Permission problemi troubleshooting dokümantasyonunda belirtilmelidir.

Performance

Unix socket bazı workload'larda daha düşük overhead sunabilir. Ancak modern web servislerinde application ve database latency farkı çoğu zaman daha büyüktür. Gerçek trafik olmadan performans varsayımıyla mimari seçmek doğru değildir. Benchmark gerekiyorsa production-benzeri ortamda yapılmalıdır. Operasyon sadeliği genellikle daha değerli olur.

Debug Kolaylığı

Local TCP endpoint curl 127.0.0.1:8000 gibi komutlarla hızlı test edilebilir. Unix socket için farklı curl syntax veya permission kontrolü gerekir. Junior ekipler TCP modelini daha kolay anlayabilir. Basitlik incident çözme süresini azaltabilir. Güvenlik local bind ile korunur.

Container Senaryoları

Container'lar arasında TCP networking doğal modeldir. Unix socket paylaşımı volume gerektirir. Aynı pod veya host içinde kullanılabilir ama lifecycle yönetimi daha karmaşık olabilir. Docker Compose veya Kubernetes service networking TCP'yi kolaylaştırır. Native systemd deployment'ta iki seçenek de uygundur.

Nginx Reverse Proxy Nedir?

Nginx reverse proxy istemci ile application server arasına girerek public trafiği backend'e yönlendirir. Backend'in doğrudan internete açılmasını önleyebilir. TLS termination, static asset, connection management, load balancing ve rate limiting aynı katmanda uygulanabilir. Ubuntu sunucuda Nginx reverse proxy SSL ve firewall yapılandırması planlanırken bu katman güvenlik sınırı olarak düşünülmelidir. Application yalnızca trusted reverse proxy'den gelen forwarding header'larına güvenmelidir.

Public Port ile Backend'i Ayırmak

Nginx 80 ve 443 portlarında public dinleyebilir. Application ise localhost üzerinde 8000 gibi port kullanır. Public kullanıcı backend'e doğrudan ulaşamaz. Firewall application portunu dışarı açmaz. Bu model saldırı yüzeyini azaltır.

TLS Termination

TLS sertifikası Nginx üzerinde yönetilebilir. Backend local networkte HTTP çalışabilir. Böylece application runtime TLS certificate lifecycle'ını yönetmez. Central security header ve protocol policy uygulanabilir. Internal threat model gerekiyorsa backend TLS ayrıca değerlendirilebilir.

Static File Serving

Nginx static dosyaları application process'e gitmeden sunabilir. CSS, JavaScript ve image request yükü backend'den alınır. Cache header merkezi belirlenebilir. User upload ile application asset ayrılmalıdır. Path traversal riskleri config testinde değerlendirilmelidir.

Connection Management

Nginx client connection'ları etkin şekilde yönetebilir. Slow client backend worker'ı doğrudan meşgul etmeyebilir. Keepalive davranışı ayarlanabilir. Timeout ve buffer ayarları workload'a göre seçilmelidir. WebSocket ve streaming için ayrı config gerekir.

Load Balancing

Birden fazla backend instance Nginx upstream altında tanımlanabilir. Traffic instance'lar arasında dağıtılır. Blue-green veya basit high availability uygulanabilir. Backend failure behavior ayrıca yönetilebilir. Health check yetenekleri kullanılan Nginx modeline göre değerlendirilmelidir.

Rate Limiting

Rate limiting belirli endpoint veya client için request hızını sınırlar. Brute-force ve accidental traffic spike etkisini azaltabilir. Application-level business limit'in yerine geçmez. Proxy arkasındaki gerçek client IP doğru çıkarılmalıdır. Fazla agresif limit meşru kullanıcıları engelleyebilir.

Nginx ile Uygulama Servisini Yayınlama

Nginx config oluştururken domain, location ve backend adresi açıkça tanımlanmalıdır. server_name doğru hostname'i, proxy_pass ise backend'i belirtir. Backend Unix socket veya localhost TCP olabilir. Forwarded header'lar application ihtiyacına göre eklenir. Her değişiklikten önce nginx -t ile syntax doğrulaması yapılmalıdır.

server_name

server_name hangi hostname için ilgili server block'un kullanılacağını belirler. DNS kaydı bu hostname'e yönelmelidir. Yanlış veya eksik değer default virtual host'a düşmeye yol açabilir. TLS certificate domain listesiyle uyumlu olmalıdır. Birden fazla domain açıkça tanımlanabilir.

location

location URL path bazında davranış seçer. Application proxy, static file veya special endpoint ayrılabilir. Prefix ve regex matching sırası iyi anlaşılmalıdır. Yanlış location security kontrolünü atlayabilir. Config küçük ve okunabilir tutulmalıdır.

proxy_pass

proxy_pass isteğin hangi backend'e gönderileceğini belirler. URL path davranışı trailing slash kullanımına göre değişebilir. Backend timeout ve header ayarları yanında düşünülmelidir. Upstream block kullanmak birden fazla backend için daha düzenlidir. Config testinden sonra gerçek request ile doğrulama yapılmalıdır.

Unix Socket Backend

Nginx Unix socket üzerinden application'a bağlanabilir. Socket path doğru olmalıdır. Nginx worker'ın socket üzerinde permission sahibi olması gerekir. Application restart sırasında stale socket file problemi yaşanabilir. Deployment script bu durumu güvenli yönetmelidir.

TCP Backend

TCP backend localhost port üzerinden çalışabilir. Debug son derece kolaydır. Application 127.0.0.1 üzerinde bind edilirse dışarıdan erişilemez. Birden fazla instance ayrı portlarda çalıştırılabilir. Nginx upstream bu portları birlikte kullanabilir.

Nginx Config Test

nginx -t syntax ve temel configuration geçerliliğini kontrol eder. Test başarısızsa reload yapılmamalıdır. CI veya deployment script config testini otomatik çalıştırabilir. Syntax doğru olsa bile backend connectivity ayrıca test edilmelidir. Reload sonrası health endpoint doğrulanmalıdır.

Reverse Proxy Header'ları

Reverse proxy arkasındaki application gerçek host, protocol ve client IP bilgisini forwarding header'ları üzerinden alabilir. Ancak bu header'lara her kaynaktan güvenmek güvenlik açığı oluşturabilir. Nginx gerekli değerleri normalize etmelidir. Application yalnızca bilinen proxy'den gelen header'ları trusted kabul etmelidir. Özellikle auth redirect, secure cookie ve audit log davranışı doğru proxy configuration'a bağlıdır.

Host

Host application'ın hangi domain üzerinden çağrıldığını anlamasını sağlar. Proxy orijinal host bilgisini iletebilir. Host header injection riskleri application seviyesinde doğrulanmalıdır. Allowed hosts listesi kullanılabilir. URL generation doğru domain'i kullanmalıdır.

X-Real-IP

X-Real-IP gerçek client adresini backend'e aktarmak için kullanılabilir. Application doğrudan public'te değilse bu bilgi proxy'den gelir. Client'ın sahte header göndermesi Nginx tarafından override edilmelidir. Audit log ve rate limit bu bilgiye güvenebilir. Trusted proxy boundary açık olmalıdır.

X-Forwarded-For

X-Forwarded-For proxy zincirindeki client adreslerini taşıyabilir. Birden fazla proxy varsa liste oluşur. Application hangi hop'un güvenilir olduğunu bilmelidir. İlk değeri kör biçimde almak yanlış olabilir. Cloud load balancer ve Nginx zinciri birlikte yapılandırılmalıdır.

X-Forwarded-Proto

Bu header orijinal request'in HTTP mi HTTPS mi olduğunu backend'e söyler. TLS Nginx üzerinde sonlandırılıyorsa backend HTTP görür. Secure redirect ve cookie davranışı header'a bağlı olabilir. Proxy doğru değeri set etmelidir. Application trusted proxy olmadan client-provided değere güvenmemelidir.

Proxy Header'larına Körü Körüne Güvenmeme

Client istediği X-Forwarded-For değerini gönderebilir. Proxy bunu güvenilir şekilde yeniden üretmezse IP tabanlı güvenlik atlatılabilir. Application proxy chain'i bilmelidir. Framework trusted proxy ayarları doğru yapılmalıdır. Public backend exposure varsa daha da dikkat gerekir.

Uygulamada Trusted Proxy Ayarı

Framework'lerin çoğu proxy trust configuration sunar. Yalnızca Nginx veya load balancer IP range'i trusted olmalıdır. Tüm interneti proxy kabul etmek yanlış client IP üretir. Container network değişiyorsa CIDR planı düşünülmelidir. Testlerde gerçek ve spoofed header senaryoları denenebilir.

Nginx Upstream Kullanımı

Nginx upstream block backend adreslerini merkezi biçimde tanımlamayı sağlar. Tek backend için bile config okunabilirliğini artırabilir. Birden fazla backend olduğunda load balancing, weight ve backup server gibi seçenekler kullanılabilir. Keepalive backend connection overhead'ini azaltabilir. Failure handling application health ve deployment stratejisiyle birlikte tasarlanmalıdır.

Tek Backend

Tek application instance bile upstream adıyla tanımlanabilir. Server block backend detayından ayrılır. Daha sonra ikinci instance eklemek kolaylaşır. Blue-green geçiş için upstream dosyası değiştirilebilir. Config tekrarları azalır.

Birden Fazla Backend

İki veya daha fazla process farklı portlarda çalışabilir. Nginx request'leri dağıtır. Bir instance restart olurken diğeri traffic taşır. Capacity her instance için yeterli planlanmalıdır. Shared session state kullanılmamalı veya external store'a taşınmalıdır.

Keepalive

Backend connection'larını tekrar kullanmak connection setup maliyetini azaltabilir. Özellikle yüksek request rate'te faydalıdır. Application server keepalive davranışıyla uyumlu olmalıdır. Çok fazla idle connection database değil Nginx kaynaklarını etkileyebilir. Metric ile ayarlanmalıdır.

Backup Server

Backup backend normal durumda traffic almayıp primary unavailable olduğunda kullanılabilir. Bu model basit failover sağlar. Backup server'ın config ve data uyumluluğu korunmalıdır. Uzun süre kullanılmayan instance drift yaşayabilir. Düzenli health doğrulaması gerekir.

Weight

Weight backend'lerin traffic oranını değiştirebilir. Daha güçlü instance daha fazla request alabilir. Canary için de sınırlı biçimde kullanılabilir. Ancak request sayısı kullanıcı veya session dağılımını tam temsil etmeyebilir. Deployment validation metric'leriyle birlikte kullanılmalıdır.

Failure Handling

Backend timeout veya connection failure durumunda Nginx farklı upstream'e yönelmeyi deneyebilir. Retry idempotent olmayan request'lerde yan etki oluşturabilir. POST işlemleri dikkatle değerlendirilmelidir. Application failure state monitoring ile görünür olmalıdır. Proxy retry gerçek root cause'u gizlememelidir.

Nginx Timeout Ayarları

Timeout değerleri rastgele büyütülmemelidir. Connect timeout backend'e bağlantı kurmayı, read timeout response beklemeyi, send timeout ise veri gönderimini etkiler. Çok uzun timeout backend sorununu connection birikimine dönüştürebilir. Çok kısa timeout ise normal uzun işlemleri kesebilir. Uzun süren işler mümkünse background job olarak ayrılmalı ve HTTP request süresi kontrollü tutulmalıdır.

Connect Timeout

Backend'e TCP veya socket connection kurma süresini sınırlar. Local backend için normalde çok kısa olmalıdır. Uzun connection gecikmesi ciddi problem işaretidir. Çok yüksek değer worker'ları bekletir. Failure metric ayrıca izlenmelidir.

Read Timeout

Backend response sırasında veri bekleme sınırını etkiler. Uzun rapor veya streaming endpoint daha yüksek değer isteyebilir. Normal API için aşırı yüksek timeout problemi gizleyebilir. Application kendi deadline mantığına sahip olmalıdır. Proxy ve client timeout zinciri uyumlu olmalıdır.

Send Timeout

Client veya backend tarafına veri gönderme davranışını etkileyebilir. Yavaş client connection'ları kaynak tüketebilir. Streaming uygulamalarında dikkatle seçilmelidir. Default değer her workload için ideal değildir. Real traffic metric üzerinden ayarlanmalıdır.

Çok Uzun Timeout'ların Riski

Beş dakikalık API timeout çoğu zaman kötü iş tasarımını gizleyebilir. Request thread veya worker uzun süre tutulur. Proxy connection sayısı artar. User belirsiz süre bekler. Uzun işi queue'ya aktarmak daha iyi olabilir.

API ve Background İşlemlerini Ayırmak

HTTP request hızlı kabul edip uzun işi background worker'a gönderebilir. Client job ID alır ve progress izleyebilir. Böylece Nginx timeout büyütmek gerekmez. Worker retry ve idempotency ayrı yönetilir. Production capacity daha öngörülebilir olur.

WebSocket ve Streaming Servislerinin Dağıtımı

WebSocket, Server-Sent Events ve streaming response normal kısa HTTP request'lerden farklı connection davranışı gösterir. Reverse proxy upgrade header ve buffering ayarlarını doğru yönetmelidir. Timeout değerleri uzun connection modeline göre düzenlenebilir. Deployment sırasında connection drain özellikle önemlidir. Zero-downtime hedefi için eski instance'ın aktif stream'leri tamamlamasına zaman tanınmalıdır.

HTTP Upgrade

WebSocket connection HTTP upgrade handshake ile başlar. Nginx gerekli Upgrade header'ını backend'e iletmelidir. Backend protokolü desteklemelidir. Yanlış config connection'ın normal HTTP olarak kalmasına yol açar. Browser network log troubleshooting için faydalıdır.

Connection Header

Upgrade bağlantısında uygun Connection header gerekir. Nginx config bunu request türüne göre set edebilir. Her HTTP request'e yanlış değer göndermek gerekmez. Map directive kullanılabilir. Backend framework davranışı test edilmelidir.

Uzun Timeout

WebSocket uzun süre açık kalabilir. Default read timeout idle connection'ı kapatabilir. Ping veya heartbeat protokolü kullanılabilir. Çok uzun zombie connection kaynak tüketebilir. Timeout ile heartbeat birlikte tasarlanmalıdır.

Proxy Buffering

Streaming response için proxy buffering gecikme yaratabilir. Belirli endpoint'lerde kapatılması gerekebilir. Her site için global kapatmak performans avantajını kaybettirir. Response type bazında uygulanabilir. Load test ile memory etkisi incelenmelidir.

Server-Sent Events

SSE uzun açık HTTP response kullanır. Buffering ve timeout ayarları önemlidir. Client reconnect davranışı desteklenmelidir. Deployment sırasında reconnect yeni instance'a yönlenebilir. Event ID ile kayıp mesaj azaltılabilir.

Streaming Response

Large download veya AI response stream gibi senaryolar bağlantıyı uzun tutabilir. Nginx buffering ve timeout değerleri endpoint ihtiyaçlarına göre ayarlanmalıdır. Client disconnect application'a iletilmelidir. Resource cleanup önemlidir. Restart sırasında graceful drain uygulanmalıdır.

HTTPS ve TLS Nasıl Kurulur?

Production web servisi HTTPS olmadan yayınlanmamalıdır. Let's Encrypt ücretsiz sertifika sağlayabilir ve Certbot birçok Ubuntu kurulumu için süreci otomatikleştirir. Nginx TLS configuration sertifika path'lerini ve secure protocol tercihlerini içerir. HTTP request'leri HTTPS'e yönlendirilebilir. Kurulumun en önemli kısmı sertifikanın otomatik yenilenmesi ve yenileme başarısızlığının izlenmesidir.

Let's Encrypt

Let's Encrypt domain doğrulaması üzerinden TLS sertifikası sağlar. Sertifikalar kısa ömürlü olduğu için otomatik renewal beklenir. DNS veya HTTP challenge kullanılabilir. Public domain'in doğru resolve olması gerekir. Rate limit ve staging test seçenekleri dikkate alınmalıdır.

Certbot

Certbot certificate issuance ve renewal sürecini kolaylaştırır. Nginx plugin otomatik config düzenleyebilir. Kurumsal yapılandırmada değişikliklerin kontrol altında tutulması için manual veya webroot yöntemleri tercih edilebilir. Renewal timer durumu kontrol edilmelidir. Dry-run düzenli test için faydalıdır.

Nginx TLS

Nginx certificate ve private key dosyalarını kullanır. Private key permission sıkı tutulmalıdır. Modern TLS protocol ve cipher default'ları güncel package ile yönetilebilir. Certificate chain doğru servis edilmelidir. External TLS test ile doğrulama yapılabilir.

HTTP → HTTPS Redirect

HTTP request'leri permanent redirect ile HTTPS'e yönlendirilebilir. Certificate challenge ihtiyacı config'te korunmalıdır. Redirect loop reverse proxy veya CDN kullanırken dikkat gerektirir. Application forwarded proto bilgisini doğru okumalıdır. HSTS ancak HTTPS tamamen kararlı olduktan sonra değerlendirilmelidir.

Certificate Renewal

Sertifika yenileme manuel hatırlamaya bırakılmamalıdır. Certbot timer veya cron otomatik çalışabilir. Renewal yalnızca gerekli olduğunda certificate'i günceller. Private key veya symlink path değişimi Nginx tarafından reload sonrası okunabilir. Başarısızlık alert üretmelidir.

Renewal Testi

certbot renew --dry-run renewal flow'u gerçek expiration beklemeden test eder. DNS, firewall ve challenge path problemleri ortaya çıkabilir. Yeni sunucu kurulumundan sonra mutlaka denenmelidir. Package update sonrası periyodik test faydalıdır. Başarı logu monitoring'e bağlanabilir.

Sertifika Sonrası Service Reload

Certificate file disk üzerinde yenilense bile çalışan process eski sertifikayı memory'de tutabilir. Renewal hook Nginx reload çalıştırabilir. Reload config testten sonra yapılmalıdır. Process restart'a çoğu zaman gerek yoktur. Yeni certificate dışarıdan HTTPS request ile doğrulanmalıdır.

TLS Sertifika Yenilemesi Nasıl İzlenir?

TLS kurulumu yalnızca ilk sertifikayı almakla bitmez. Renewal timer'ın çalışması, dry-run'ın başarılı olması ve gerçek certificate expiry tarihinin izlenmesi gerekir. Automation hatası aylar sonra production outage olarak ortaya çıkabilir. Ben monitoring'de en az iki katman kullanmayı tercih ediyorum: renewal job sonucu ve dışarıdan certificate expiry kontrolü. Böylece local automation yeşil görünse bile public endpoint yanlış certificate sunuyorsa alarm alınabilir.

Certbot systemd Timer

Certbot package systemd timer sağlayabilir. Timer'ın enabled ve active durumu kontrol edilmelidir. Son ve sonraki çalışma zamanı görülebilir. Timer çalışıyor olması renewal'ın başarılı olduğunu garanti etmez. Journal log ayrıca incelenmelidir.

certbot renew --dry-run

Dry-run renewal configuration'ını gerçek certificate'i değiştirmeden test eder. Challenge ve hook davranışı doğrulanır. Yeni server provisioning checklist'e eklenebilir. Belirli aralıklarla automation üzerinden çalıştırılabilir. Failure alert oluşturmalıdır.

Renewal Hook

Certificate yenilendiğinde web server yeni dosyayı yüklemelidir. Deploy hook yalnızca başarılı renewal sonrası reload çalıştırabilir. Reload öncesi config test yapılabilir. Hook idempotent olmalıdır. Loglarda hangi certificate'in yenilendiği görünmelidir.

Certificate Expiry Monitoring

External monitor public endpoint'e bağlanıp certificate expiry tarihini ölçebilir. Otuz, on dört ve yedi gün gibi eşikler kullanılabilir. Böylece Certbot log sorunlarından bağımsız kontrol sağlanır. Wildcard ve farklı hostname'ler ayrı izlenmelidir. Alarm gerçekten on-call ekibe ulaşmalıdır.

Yenileme Hataları İçin Alert

Renewal failure yalnızca log içinde kalmamalıdır. systemd failure veya log-based alert kullanılabilir. Certificate expiry yaklaşımı ikinci sinyal olur. Alarm mesajı hangi domain'in etkilendiğini göstermelidir. Runbook dry-run ve DNS kontrol adımlarını içermelidir.

Ubuntu Sunucuda Firewall Yapılandırması

Firewall uygulama portlarını minimum seviyede public tutmalıdır. UFW üzerinde default deny incoming iyi başlangıçtır. SSH, HTTP ve HTTPS kontrollü biçimde açılır. Database portları mümkün olduğunca public internete açılmaz. Cloud firewall kullanılıyorsa host firewall ikinci koruma katmanı olarak değerlendirilebilir.

UFW

UFW iptables veya nftables tabanlı firewall yönetimini daha basit hale getirir. Rule set okunabilir ve hızlı yönetilebilir. Enable öncesi SSH erişimi izinli hale getirilmelidir. Status verbose ile aktif policy kontrol edilir. Configuration management ile kurallar standardize edilebilir.

Default Deny Incoming

Varsayılan incoming deny yalnızca açıkça izin verilen portları kabul eder. Yeni service yanlışlıkla public port açsa bile firewall koruma sağlayabilir. Outgoing policy ihtiyaçlara göre ayrıca değerlendirilebilir. Localhost trafiği etkilenmemelidir. Rule değişiklikleri remote lockout riskine karşı dikkatle yapılmalıdır.

SSH

SSH yalnızca gereken source network'lerden erişilebilir yapılabilir. Public internet erişimi gerekiyorsa key authentication zorunlu tutulabilir. Rate limiting ek koruma sağlayabilir. Port değiştirmek tek başına güvenlik stratejisi değildir. Bastion veya VPN daha güçlü erişim sınırı sunabilir.

HTTP

Port 80 Let's Encrypt challenge ve HTTPS redirect için açık olabilir. Application backend portu public açılmamalıdır. Tüm normal kullanıcı trafiği HTTPS'e yönlendirilebilir. HTTP access log beklenmeyen kullanım için izlenebilir. HSTS gibi policy HTTPS tarafında uygulanır.

HTTPS

Port 443 web servisin ana public girişidir. Nginx burada TLS termination yapabilir. Certificate ve protocol ayarları düzenli güncellenmelidir. Firewall yalnızca Nginx gibi public service'e izin verir. Backend localhost üzerinde kalır.

Database Portlarını Public Açmamak

PostgreSQL, MySQL veya Redis portlarını public internete açmak çoğu architecture'da gereksizdir. Local application aynı hosttaysa localhost yeterlidir. Ayrı server varsa private network kullanılabilir. Yönetim erişimi VPN veya bastion üzerinden sağlanabilir. Firewall database için dar source CIDR uygulamalıdır.

UFW + Cloud Firewall

Cloud firewall network edge'de, UFW ise host üzerinde ek kontrol sunar. İkisini birlikte kullanmak defense in depth sağlar. Fakat kural drift troubleshooting'i zorlaştırabilir. Source of truth dokümante edilmelidir. Açık port kontrolü iki katmanda da yapılmalıdır.

SSH Güvenliği

SSH production sunucunun en kritik yönetim girişlerinden biridir. Key authentication tercih edilmeli, root login ve password authentication ihtiyaca göre kapatılmalıdır. Configuration değişikliği syntax testinden geçirilmelidir. Büyük ekip veya kritik sistemlerde MFA, bastion veya kısa ömürlü credential kullanılabilir. SSH ayarı değiştirirken mevcut oturumu kapatmadan ikinci bağlantıyla doğrulama yapmak lockout riskini azaltır.

SSH Key Authentication

Public key server'da, private key istemci tarafında tutulur. Private key paylaşılmamalıdır. Kullanıcı bazlı key ayrı tutulursa revoke işlemi kolaylaşır. Passphrase ek koruma sağlar. Kurumsal ortamda merkezi key lifecycle tercih edilebilir.

Root Login'i Kapatma

Root SSH login kapatıldığında saldırgan doğrudan en yetkili hesapla giriş yapamaz. Admin kullanıcı sudo üzerinden kontrollü yükselir. Audit trail daha anlamlı olur. Recovery için cloud console veya break-glass erişimi planlanmalıdır. Ayar test edilmeden mevcut root session kapatılmamalıdır.

Password Authentication'ı Kapatma

Key authentication doğrulandıktan sonra password login kapatılabilir. Brute-force parola saldırıları etkisiz hale gelir. Kullanıcı key kaybına karşı recovery prosedürü bulunmalıdır. Legacy automation password kullanıyorsa önce migrate edilmelidir. Config syntax testinden sonra reload uygulanmalıdır.

SSH Config Syntax Test

Yanlış SSH config remote erişimi tamamen kesebilir. sshd -t syntax kontrolü için kullanılabilir. Test başarısızsa reload yapılmamalıdır. Yeni session açılarak login doğrulanmalıdır. Cloud console emergency erişimi hazır olmalıdır.

MFA / Bastion Gereksinimi

Kritik production erişimi için yalnızca SSH key yeterli görülmeyebilir. Bastion merkezi erişim noktası sağlar. MFA identity doğrulamasını güçlendirir. Short-lived SSH certificate modeli statik key riskini azaltabilir. Sistem büyüdükçe merkezi erişim yönetimi daha değerli hale gelir.

Lockout Riskini Önlemek

Firewall veya sshd değişikliğinde mevcut session açık tutulmalıdır. İkinci terminalden yeni bağlantı denenmelidir. Syntax test yapılmalıdır. Cloud console erişimi önceden doğrulanmalıdır. Remote sunucuda erişimi tek değişiklikle kapatmak recovery süresini gereksiz büyütür.

Fail2Ban Her Ubuntu Sunucuda Gerekli midir?

Fail2Ban log tabanlı tekrar eden başarısız bağlantıları geçici olarak engelleyebilir. Fakat SSH key authentication, firewall ve doğru exposure varsa her sunucuda zorunlu değildir. Fail2Ban temel authentication güvenliğinin yerine geçmez. Ayrıca gerçek DDoS koruması sağlamaz. Kullanım kararı public service exposure ve threat model'e göre verilmelidir.

SSH Key Kullanımı

Password login kapalıysa klasik SSH brute-force saldırısının etkisi önemli ölçüde azalır. Yine de sürekli denemeler log gürültüsü oluşturabilir. Fail2Ban bu kaynakları engelleyebilir. Ancak key güvenliği ve user lifecycle daha önemlidir. Public SSH erişimini daraltmak ilk tercihtir.

Firewall

SSH yalnızca belirli IP range'lerine açıksa Fail2Ban ihtiyacı azalır. VPN veya bastion kullanımı daha güçlü sınır koyar. Public exposure zorunluysa rate limiting uygulanabilir. Firewall policy basit tutulmalıdır. Fail2Ban ek katman olarak değerlendirilebilir.

Log Tabanlı Blocking

Fail2Ban belirli log pattern'lerini izler. Threshold aşılırsa IP firewall üzerinden engellenir. Yanlış pattern meşru kullanıcıyı block edebilir. NAT arkasındaki çok sayıda kullanıcı aynı IP'yi paylaşabilir. Ban süreleri gerçek threat model'e göre seçilmelidir.

Fail2Ban'ın Rolü

Fail2Ban repeated abuse kaynaklarını azaltmaya yardımcı olur. Authentication yerine savunmanın yardımcı katmanıdır. Application login endpoint için de kullanılabilir ancak proxy client IP doğru olmalıdır. Merkezi WAF bazı durumlarda daha uygun çözüm olur. Operasyon ekibi ban listesini yönetebilmelidir.

DDoS Korumasından Farkı

Fail2Ban host seviyesinde log gördükten sonra aksiyon alır. Büyük volumetric DDoS trafik sunucuya ulaşmadan upstream seviyede durdurulmalıdır. CDN veya provider network koruması bu amaç için daha uygundur. Fail2Ban bandwidth kapasitesini artırmaz. İki mekanizma farklı problem çözer.

Application Secrets Nasıl Yönetilmeli?

Secret, source code veya public repository içinde tutulmamalıdır. Küçük sistemlerde permission korumalı environment file kullanılabilir. Sistem büyüdükçe merkezi secret manager rotation ve audit açısından avantaj sağlar. Secret erişimi yalnızca ilgili service user ile sınırlandırılmalıdır. Backup ve log süreçlerinde secret değerlerinin yanlışlıkla kopyalanmadığı doğrulanmalıdır.

Secret'ları Git'e Koymamak

Git history'den secret silmek yalnızca son commit'i değiştirmek kadar kolay değildir. Secret önceki commit'lerde kalabilir. Repository private olsa bile erişim geniş olabilir. Commit edilen credential hemen rotate edilmelidir. Secret scanning CI sürecine eklenebilir.

Environment Variables

Environment variable application config için pratik yöntemdir. Ancak process environment bazı debug araçlarında görülebilir. Çok hassas secret için file veya manager entegrasyonu daha iyi olabilir. Unit file içine doğrudan secret yazılmamalıdır. Environment source permission kontrollü olmalıdır.

.env Dosyası

.env küçük deployment'larda sade config modeli sağlar. Dosya repository dışında tutulmalıdır. Permission yalnızca gerekli kullanıcıya verilmelidir. Backup sistemi dosyayı güvenli biçimde korumalı veya hariç tutmalıdır. Çok sayıda server olduğunda dağıtımı zorlaşır.

File Permissions

Secret file world-readable olmamalıdır. Genellikle owner read permission yeterlidir. Deploy process'in dosyaya gerçekten ihtiyacı olup olmadığı düşünülmelidir. Group erişimi gerekiyorsa dar tutulmalıdır. Configuration management mode değerlerini enforce edebilir.

systemd EnvironmentFile

systemd environment file ile config kolayca yüklenebilir. Dosya unit'ten ayrı tutulur. Service user'ın ihtiyaç duyduğu değerler burada bulunabilir. Değişiklik sonrası restart gerekir. Secret manager kadar güçlü audit ve rotation sağlamaz.

Secret Manager

Merkezi secret manager erişim policy ve versioning sağlar. Credential runtime'da alınabilir. Rotation daha kolay otomatikleştirilir. Static server file sayısı azalır. Ancak uygulama ve network dependency eklenir.

Secret Rotation

Secret süresiz aynı kalmamalıdır. Rotation application downtime oluşturmadan yapılabilmelidir. Bir süre eski ve yeni credential birlikte geçerli olabilir. Revocation sonrası health check uygulanmalıdır. Rotation runbook test edilmelidir.

.env Dosyası Production İçin Yeterli midir?

Küçük bir VPS ve sınırlı ekip için permission korumalı .env dosyası kabul edilebilir başlangıç olabilir. Ancak merkezi audit, otomatik rotation ve çok sunuculu dağıtım ihtiyacı arttıkça bu model zorlanır. Process environment leakage ve backup kopyaları ayrıca risk oluşturur. Secret manager'a geçiş ihtiyacı sistem büyüklüğü ve güvenlik gereksinimine göre değerlendirilmelidir. En önemli nokta dosyanın Git repository içinde tutulmamasıdır.

Avantajları

.env basit ve framework desteği geniştir. Küçük ekip için öğrenme maliyeti düşüktür. Configuration ayrı tutulabilir. Deployment automation dosyayı oluşturabilir. Merkezi platform gerektirmez.

Dosya İzinları

Dosya yalnızca service user veya gerekli group tarafından okunmalıdır. World-readable permission kabul edilmemelidir. Parent directory izinleri de önemlidir. Backup operator erişimi düşünülmelidir. Permission configuration management ile doğrulanabilir.

Process Environment Leakage

Environment değerleri process inspection veya crash dump içinde görünebilir. Debug log yanlışlıkla tüm environment'ı yazmamalıdır. Support bundle hazırlanırken secret filtrelenmelidir. Çok hassas credential file descriptor veya secret manager üzerinden alınabilir. Threat model bunu belirler.

Backup'larda Secret Riski

Config directory backup'a dahil edilirse secret kopyası başka storage'a taşınır. Backup encryption ve access control önemlidir. Retention süresi eski credential'ları saklayabilir. Rotate edilmiş secret backup içinde bulunmaya devam eder. Recovery prosedürü de güvenli olmalıdır.

Merkezi Secret Manager'a Ne Zaman Geçilmeli?

Sunucu sayısı arttığında manuel secret dağıtımı hata riski yaratır. Sık rotation veya compliance gereksinimi merkezi çözümü değerli hale getirir. Access audit ve short-lived credential ihtiyaçları da güçlü sinyaldir. Birden fazla ekip aynı secret lifecycle'ını paylaşıyorsa merkezi yönetim daha uygundur. Geçiş kademeli yapılabilir.

Dependency Management ve Reproducible Deployment

Reproducible deployment aynı source version'ın aynı dependency setiyle çalışmasını hedefler. Python, npm, Go ve JVM ekosistemlerinde lock veya version pinning mekanizmaları kullanılır. "Latest" dependency production build için güvenilir referans değildir. Dependency update ayrı change olarak test edilmelidir. Artifact mümkünse CI içinde bir kez oluşturulup sunucuya hazır halde gönderilmelidir.

Python Requirements Lock

Python dependency'leri exact version ile kilitlenebilir. Sadece geniş range kullanmak sonraki deployment'ta farklı package çekebilir. Hash verification supply-chain güvenliğini artırabilir. Virtual environment artifact içinde hazırlanabilir. Update kontrollü pull request olarak yapılmalıdır.

npm Lockfile

npm lockfile transitive dependency version'larını sabitler. CI'da deterministic install komutu kullanılmalıdır. Lockfile repository'de tutulmalıdır. Package version update review edilmelidir. Production sunucuda rastgele npm update çalıştırılmamalıdır.

Go Modules

Go modules dependency version'larını açıkça tanımlar. go.sum checksum doğrulaması sağlar. Build CI içinde yapılabilir. Sunucuya yalnızca binary gönderilebilir. Bu model production dependency yükleme ihtiyacını azaltır.

Maven/Gradle Locking

Java build tool'larında dependency version yönetimi açık yapılmalıdır. Dynamic version production build'te risklidir. Locking veya dependency management kullanılabilir. Artifact repository erişimi kontrol edilmelidir. JAR tekrar build edilmeden deploy edilmelidir.

Version Pinning

Runtime ve dependency pinning birlikte düşünülmelidir. Yalnızca application package sabit olup base runtime değişirse davranış yine farklılaşabilir. Pinning update yapılmayacağı anlamına gelmez. Update planlı ve test edilmiş değişiklik olur. Security patch süreci ayrıca hızlı tutulmalıdır.

“Latest” Dependency Kullanmanın Riski

Latest etiketi bugün başka, yarın başka version gösterebilir. Aynı commit farklı günlerde farklı build üretebilir. Rollback güvenilirliğini azaltır. Dependency veya container image digest kullanılmalıdır. Upgrade ayrı release olarak izlenmelidir.

Sunucuda git pull Yapmak mı Artifact Deploy Etmek mi?

Sunucuda doğrudan git pull küçük projelerde kolay görünür, ancak production kontrolünü zayıflatabilir. Build artifact modelinde kod CI içinde test edilir ve immutable çıktı olarak sunucuya gönderilir. Böylece production sunucuda compiler, package registry ve repository credential ihtiyacı azalır. Rollback eski artifact'i yeniden activate etmekle yapılabilir. Production büyüdükçe artifact deployment modeli genellikle daha güvenli ve tekrar üretilebilir hale gelir.

Git Pull Deployment

Git pull çalışan directory'yi doğrudan değiştirir. Partial failure durumunda belirsiz state oluşabilir. Sunucuda build ve dependency install gerekir. Repository credential production'a taşınır. Küçük internal proje için kullanılabilse de ölçeklendikçe risk artar.

Build Artifact

CI source code'u build edip test edilmiş çıktı üretir. Server yalnızca artifact indirir. Build toolchain production'a kurulmaz. Checksum ve signature doğrulanabilir. Deployment daha hızlı ve tahmin edilebilir olur.

Immutable Release

Release dosyası deploy edildikten sonra değiştirilmez. Yeni sürüm yeni directory veya artifact version olarak gelir. Eski release korunabilir. Debug sırasında çalışan code state bellidir. Rollback çok daha kolaydır.

Reproducibility

Tek artifact environment'lar arasında promote edilir. Aynı source'tan production'da yeniden build alınmaz. Dependency drift riski azalır. CI log ve build ID traceability sağlar. Incident sırasında hangi binary'nin çalıştığı kesin bilinir.

Rollback

Git pull modelinde eski commit checkout etmek dependency veya build değişikliğini çözmeyebilir. Artifact modelinde previous release zaten hazırdır. Symlink veya service switch ile geri dönülebilir. Config ve database compatibility yine kontrol edilmelidir. Recovery süresi kısalır.

Production İçin Hangi Model Daha Güvenli?

Çoğu production sistemi için immutable artifact modeli daha güvenlidir. CI içinde build ve test merkezi yapılır. Server minimum toolchain taşır. Audit ve rollback kolaylaşır. Çok küçük projede git pull kullanılacaksa bile versioned directory ve health check eklenmelidir.

Atomic Deployment Nedir?

Atomic deployment yeni release hazırlanırken çalışan release'e dokunmamayı hedefler. Yeni version ayrı directory içinde kurulur ve doğrulanır. Ardından current symlink tek işlemle yeni release'e yönlendirilir. Eski release saklandığı için geri dönüş hızlıdır. Bu model tek Ubuntu sunucuda bile güvenli deployment için oldukça etkili olabilir.

Versioned Release Directory

Her release ayrı directory altında tutulur. Directory Git SHA veya timestamp ile isimlendirilebilir. Dosyalar deployment sırasında mevcut release'i değiştirmez. Yeni version local health testten geçirilebilir. Retention eski release sayısını sınırlar.

/releases/2026-08-21

Tarih tabanlı release directory insan tarafından kolay okunur. Aynı gün birden fazla deployment varsa timestamp veya build ID eklenmelidir. Release metadata dosyası Git SHA'yı içerebilir. Directory immutable tutulmalıdır. Automation dizini kendisi oluşturmalıdır.

/current Symlink

/current hangi release'in aktif olduğunu gösterir. systemd bu path üzerinden executable çalıştırabilir. Deployment state tek yerde görünür hale gelir. Symlink target doğrulanmalıdır. Manual değişiklik audit edilmelidir.

Symlink Swap

Yeni symlink hazırlanıp atomic rename ile aktif hale getirilebilir. Böylece yarım kopyalanmış release çalışmaz. Service restart veya reload sonrasında yeni target kullanılır. Health check başarısızsa önceki target geri alınabilir. Deployment script idempotent olmalıdır.

Eski Release'i Saklamak

En az birkaç stable release disk üzerinde tutulabilir. Disk usage gözlenmelidir. Security açığı olan artifact retention policy ile ayrıca işaretlenebilir. Eski release bağımlılıklarıyla birlikte tutulmalıdır. Rollback için yeniden download bile gerekmeyebilir.

Hızlı Rollback

Previous release symlink target olarak yeniden seçilebilir. systemd service kontrollü restart edilir. Health check çalıştırılır. Database migration compatibility ayrıca doğrulanır. Bu model recovery süresini dakikalardan saniyelere indirebilir.

Zero-Downtime Deployment Nedir?

Zero-downtime deployment kullanıcıların yeni sürüme geçiş sırasında servis kesintisi yaşamamasını hedefler. Tek process'i doğrudan restart etmek kısa bağlantı kayıpları oluşturabilir. İki application instance çalıştırıp traffic'i health durumuna göre değiştirmek daha güvenilir modeldir. Eski instance aktif connection'ları tamamladıktan sonra kapatılır. Gerçek kesintisizlik yalnızca process değil database ve external dependency compatibility'sini de gerektirir.

Simple Restart Problemi

Tek application process restart edilirken birkaç saniye endpoint unavailable olabilir. Long request yarıda kesilebilir. Client retry varsa etki azalabilir ama tamamen çözülmez. Deployment sıklığı arttıkça bu küçük kesintiler görünür hale gelir. İkinci instance modeli daha güvenlidir.

Graceful Reload

Application master process yeni worker başlatıp eskileri drain edebiliyorsa graceful reload kullanılabilir. Runtime desteği farklılık gösterir. Binary değişikliği reload ile gerçekten uygulanıyor mu doğrulanmalıdır. Timeout sonunda eski worker zorla kapatılabilir. Metric'ler mixed-version dönemini göstermelidir.

İki Application Instance

Blue ve green gibi iki instance farklı portlarda çalışabilir. Biri traffic taşırken diğeri yeni release'i test eder. Yeni instance hazır olduğunda Nginx route değiştirilir. Eski instance bir süre tutulur. Rollback çok hızlı olur.

Traffic Drain

Yeni request eski instance'a gönderilmez. Mevcut connection'ların tamamlanması beklenir. Drain timeout uzun request süresine göre ayarlanmalıdır. WebSocket özel handling gerektirir. Timeout sonrası kalan process kontrollü sonlandırılır.

Health Check

Yeni instance traffic almadan health doğrulaması yapılmalıdır. Sadece process active kontrolü yeterli değildir. Readiness endpoint temel dependency'leri kontrol edebilir. Deep health her request'te çalıştırılmamalıdır. Deployment script birkaç retry uygulayabilir.

Switch

Nginx upstream yeni instance'a yönlendirilir. Config syntax test edilmelidir. Reload ile aktif connection'lar korunabilir. Traffic geçişi metric üzerinden gözlenir. Yeni release hata verirse route hızlıca geri alınır.

Eski Instance'ı Kapatmak

Stabilization süresi tamamlanmadan eski instance hemen kapatılmayabilir. Bu rollback penceresi sağlar. Resource maliyeti tek sunucuda sınırlayıcı olabilir. Traffic tamamen yeni version'da doğrulandıktan sonra stop edilir. Eski artifact yine disk üzerinde tutulabilir.

Blue-Green Deployment Ubuntu Sunucuda Nasıl Yapılır?

Blue-green model tek Ubuntu sunucuda iki ayrı application instance ile kurulabilir. Blue mevcut stable sürümü, green yeni release'i çalıştırır. İki process farklı port veya Unix socket kullanır. Nginx upstream yalnızca aktif environment'a yönlendirilir. Yeni version health check'i geçerse traffic switch yapılır, sorun çıkarsa route blue'ya geri çevrilir.

Blue Instance

Blue aktif production release'tir. Nginx traffic başlangıçta buraya gider. Green hazırlanırken blue değiştirilmez. Stabilization tamamlanana kadar çalışır durumda tutulabilir. Rollback target olarak kullanılır.

Green Instance

Green yeni release'i ayrı process olarak çalıştırır. Public traffic almadan localhost üzerinden test edilir. Config ve database bağlantısı doğrulanır. Resource kullanımına dikkat edilir. Hazır olduğunda Nginx route için aday olur.

İki Port veya Socket

Blue ve green aynı portu paylaşamaz. Farklı local portlar veya socket path'leri kullanılır. Configuration bunu parametreyle belirleyebilir. Firewall bu portları public açmaz. Deployment script aktif ve standby port bilgisini yönetebilir.

Nginx Upstream

Nginx aktif backend'i upstream üzerinden tanımlar. Configuration symlink veya template ile değiştirilebilir. Switch öncesi nginx -t çalıştırılır. Reload kesintisiz geçiş sağlar. Config version audit edilmelidir.

Yeni Versiyon Health Check

Green localhost üzerinden readiness testine alınır. Database read ve basit business endpoint kullanılabilir. Birkaç ardışık başarılı sonuç beklenebilir. Startup warm-up süresi hesaba katılır. Başarısızsa public traffic verilmez.

Traffic Switch

Nginx route green'e çevrilir. Reload sonrası gerçek public request test edilir. Error ve latency izlenir. Session state external olduğunda geçiş daha kolaydır. Problem görülürse hızlı rollback yapılır.

Rollback

Rollback Nginx route'u tekrar blue backend'e döndürür. Green process analiz için açık tutulabilir. Database backward compatibility bulunmalıdır. User flow düzelince incident stabil hale gelir. Ardından code fix ayrı release olarak hazırlanır.

Canary Deployment Nedir?

Canary deployment yeni release'i tüm kullanıcılara açmadan önce küçük trafik oranında test eder. Böylece problem varsa etkilenen kullanıcı sayısı sınırlı kalır. Nginx weighted upstream ile basit canary dağıtımı yapılabilir. Error rate ve latency stable sürümle karşılaştırılmalıdır. Otomatik rollback için yeterli sample ve açık threshold gerekir.

Trafiğin Küçük Bölümünü Yeni Sürüme Yönlendirmek

Yeni backend ilk aşamada yüzde birkaç traffic alabilir. Gerçek production koşullarında davranış görülür. Çok düşük trafik yeterli sample vermeyebilir. Kritik tenant ilk test grubu olmamalıdır. Traffic oranı aşamalı artırılır.

Weighted Upstream

Nginx upstream server weight ile request dağılımını etkileyebilir. Basit canary senaryosunda kullanılabilir. Sticky session veya hash algoritması dağılımı değiştirebilir. Weight gerçek kullanıcı yüzdesine birebir eşit olmayabilir. Metric version label taşımalıdır.

Error Rate İzleme

Canary ve stable request'leri ayrı label ile ölçülmelidir. Global error rate küçük canary sorununu gizleyebilir. 5xx oranı baseline ile karşılaştırılır. Minimum request sayısı gereklidir. Business metric de birlikte değerlendirilmelidir.

Kademeli Trafik Artışı

Canary sağlıklıysa traffic oranı adım adım artırılır. Her adım için observation window kullanılabilir. Yüzde yüz traffic sonrasında stabilization devam eder. Eski release hemen silinmez. Promotion otomasyonu policy ile yönetilebilir.

Automatic Rollback

Canary metric belirlenen sınırı aşarsa traffic stable backend'e geri döndürülebilir. Automatic rollback yalnızca güvenilir metric varsa uygulanmalıdır. Database migration irreversible ise otomasyon durmalıdır. Failed release yeniden otomatik promote edilmemelidir. Human alert aynı anda oluşturulmalıdır.

Health Check Endpoint Nasıl Tasarlanmalı?

Health endpoint process'in ayakta olmasıyla application'ın traffic almaya hazır olması arasındaki farkı açıkça göstermelidir. Liveness process'in yaşadığını, readiness ise request kabul edebilme durumunu ifade eder. Database ve cache dependency'leri readiness içinde dikkatle değerlendirilebilir. Her external API'yi health request'inde çağırmak yeni failure zinciri yaratabilir. Basit ve deep health check ayrı endpoint olarak tasarlanabilir.

Liveness

Liveness application process'in temel event loop veya runtime açısından canlı olduğunu gösterir. Çok ağır dependency kontrolü yapmamalıdır. External service outage nedeniyle process sürekli restart edilmemelidir. Basit local state yeterli olabilir. systemd veya container platform bu endpoint'i kullanabilir.

Readiness

Readiness application'ın gerçek traffic almaya hazır olup olmadığını gösterir. Startup migration veya cache warm-up bitmemişse false olabilir. Critical database connection gereksinimi burada değerlendirilebilir. Fail durumunda traffic kesilir ama process mutlaka restart edilmez. Zero-downtime deployment için önemlidir.

Database Bağlantısı

Application database olmadan çalışamıyorsa readiness kontrolünde hafif query kullanılabilir. Her health request'te ağır query çalıştırılmamalıdır. Connection pool state kontrol edilebilir. Database outage tüm pod'ları unready yapıp yeni sorun oluşturabilir. Dependency failure mode planlanmalıdır.

Cache Bağlantısı

Cache optional ise failure application'ı tamamen unready yapmak zorunda değildir. Fallback davranışı varsa degraded state raporlanabilir. Cache critical session store ise readiness için daha önemli olabilir. Health response dependency detayını internal endpointte gösterebilir. Public endpoint hassas bilgi vermemelidir.

External Dependency

Third-party API'yi her health check'te çağırmak rate limit ve dependency coupling yaratır. Circuit breaker state veya son başarı zamanı kullanılabilir. External outage uygulamanın bazı feature'larını etkileyebilir ama tamamını değil. Health status service capability bazında tasarlanabilir. Deep diagnostic endpoint ayrı tutulmalıdır.

Basit Health Check ile Deep Health Check Farkı

Basit check hızlı ve sık çalıştırılabilir. Deep check database, cache ve external dependency gibi daha kapsamlı test yapar. Deep endpoint monitoring veya deployment validation için daha seyrek kullanılabilir. Public erişim kısıtlanabilir. İki seviyeli model gereksiz yükü azaltır.

Deployment Sonrası Doğrulama

Deployment komutunun başarılı olması application'ın kullanıcıya hizmet verdiğini kanıtlamaz. systemd status, health endpoint, Nginx config ve gerçek HTTP request birlikte kontrol edilmelidir. Application loglar yeni error'lar için incelenmelidir. Error rate ve response time önceki release ile karşılaştırılabilir. Deployment ancak bu doğrulamalar tamamlandığında başarılı kabul edilmelidir.

systemd Status

Service active ve expected PID ile çalışıyor olmalıdır. Restart loop görünmemelidir. Son log satırları startup problemine işaret edebilir. Unit yeni release path'ini kullanmalıdır. Active state tek başına yeterli değildir.

Health Endpoint

Local ve public health endpoint kontrol edilebilir. Local test application'ı, public test ise Nginx ve TLS zincirini doğrular. Response expected version bilgisini taşıyabilir. Database readiness ayrıca görülebilir. Birkaç ardışık başarılı cevap güveni artırır.

Nginx Configuration

nginx -t config syntax kontrolü yapar. Active upstream doğru backend'i göstermelidir. Reload failure journal veya error log'da görünür. TLS certificate path doğrulanır. Config deployment artifact gibi versioned tutulabilir.

HTTP Status

Gerçek public endpoint uygun status code dönmelidir. Redirect chain doğru olmalıdır. 502 veya 504 hemen investigation gerektirir. Auth gerektirmeyen smoke endpoint kullanılabilir. HTTP status business correctness'in tamamını göstermez.

Application Logs

Deployment timestamp sonrası loglar filtrelenebilir. Startup exception ve dependency warning aranır. Yeni release ile error spike var mı kontrol edilir. Structured log version field taşıyabilir. Sensitive data loglanmamalıdır.

Error Rate

Yeni release sonrası 5xx oranı baseline ile karşılaştırılır. Düşük trafik sisteminde yeterli sample beklenmelidir. Nginx ve application error metric ayrı görülebilir. Sudden 4xx artışı contract problemi gösterebilir. Threshold aşılırsa rollback değerlendirilebilir.

Response Time

Average response time tek başına yeterli değildir. P95 ve P99 latency izlemek tail regression'ı gösterir. Cache warm-up sonrası geçici spike olabilir. Observation window buna göre seçilir. Sürekli kötüleşme release failure sinyali olabilir.

Database Migration Deployment'ta Nasıl Yönetilmeli?

Database migration production deployment'ın en riskli parçalarından biridir. Migration öncesi backup bulunması önemlidir, ancak rollback planını yalnızca backup restore üzerine kurmak doğru değildir. Backward-compatible schema değişiklikleri application rollback penceresini korur. Expand-and-contract modeli breaking değişiklikleri birkaç release'e böler. Destructive migration ancak yeni version stabil olduktan sonra uygulanmalıdır.

Migration Öncesi Backup

Critical schema değişikliği öncesi güncel backup veya snapshot alınabilir. Backup'ın restore edilebilir olduğu önceden test edilmiş olmalıdır. Snapshot süresi deployment planına dahil edilir. Büyük database için snapshot performans etkisi kontrol edilir. Backup tek başına safe rollback değildir.

Backward-Compatible Migration

Yeni column eklemek eski column'u silmekten daha güvenlidir. Eski application yeni schema üzerinde çalışmaya devam edebilir. Required field aşamalı uygulanabilir. Database change application'dan önce deploy edilebilir. Rollback böylece kolaylaşır.

Expand-and-Contract Pattern

İlk release yeni schema'yı ekler. Sonraki aşama data ve application kullanımını taşır. Eski alan yalnızca stabilization sonrasında kaldırılır. Bu süreç daha fazla deployment gerektirir. Buna karşılık production riskini önemli ölçüde azaltır.

Migration ile Kod Deploy Sırası

Backward-compatible migration çoğu zaman application'dan önce uygulanabilir. Yeni code eski ve yeni schema geçişini destekler. Destructive cleanup sonraki release'e bırakılır. Worker ve cron process'leri aynı schema timeline'a göre değerlendirilmelidir. Deployment runbook sequence'i açıkça yazmalıdır.

Rollback Problemleri

Application eski version'a dönerken database ileride kalabilir. Eski code yeni schema ile uyumlu değilse rollback başarısız olur. Down migration data kaybı yaratabilir. Bu nedenle rollback test deployment öncesi yapılmalıdır. Gerektiğinde roll forward planı hazır tutulmalıdır.

Destructive Migration Riskleri

Column drop veya irreversible data transformation geri dönüşü zorlaştırır. Kullanıcılar yeni schema'ya veri yazdıktan sonra eski state kaybolabilir. Contract aşaması geciktirilmelidir. Backup restore gerçek kullanıcı verisini de geriye sarabilir. Human approval gerekebilir.

Rollback Stratejisi

Rollback yalnızca application binary'yi eski version'a çevirmek değildir. Previous release, symlink, configuration ve database state ayrı düşünülmelidir. En hızlı recovery çoğu zaman eski immutable release'i yeniden active etmektir. Database rollback ise çok daha yüksek risk taşır. Her rollback sonunda health check ve kullanıcı akışı doğrulanmalıdır.

Previous Release

Önceki deployment her zaman known-good olmayabilir. Stable olarak doğrulanmış release hedeflenmelidir. Artifact, config ve schema version birlikte kaydedilebilir. Security durumu da kontrol edilmelidir. Rollback script target version'ı açıkça göstermelidir.

Symlink Rollback

Versioned release dizininde current symlink eski release'e çevrilebilir. İşlem hızlıdır. Service restart sonrası old binary çalışır. Config compatibility kontrol edilmelidir. Health verification tamamlanmadan incident kapanmamalıdır.

Application Rollback

Application artifact eski version'a döner. Nginx route veya systemd service bu artifact'i kullanır. Worker version da gözden geçirilmelidir. Database yeni schema ile uyumlu olmalıdır. Error metric recovery'yi doğrular.

Configuration Rollback

Yeni config application hata yaratmış olabilir. Config version ayrı tutuluyorsa eski state geri getirilebilir. Secret rotation aynı işlem gibi görülmemelidir. Nginx veya application reload gerekebilir. Audit log değişikliği kaydetmelidir.

Database Rollback

Database rollback son derece dikkatli yapılmalıdır. Down migration data kaybı oluşturabilir. Snapshot restore yeni doğru kayıtları silebilir. Çoğu durumda backward-compatible schema bırakıp application rollback daha güvenlidir. DBA veya data owner approval gerekebilir.

Rollback Sonrası Health Check

Doğru application version'ın çalıştığı kontrol edilir. Public health endpoint test edilir. Nginx error ve application log incelenir. Database read-write doğrulanır. Business flow normale dönmeden rollback tamamlanmış sayılmamalıdır.

Deployment Script Nasıl Tasarlanmalı?

Deployment script tekrar çalıştırıldığında öngörülebilir davranmalıdır. Shell script kullanılıyorsa hata handling açık olmalıdır. Version kontrolü, artifact doğrulama, config validation ve health check ayrı adımlar halinde bulunmalıdır. Migration ve service switch mümkün olduğunca geri alınabilir sırada yapılmalıdır. Script başarısız olduğunda hangi noktada kaldığını loglamalıdır.

set -euo pipefail

Bash scriptlerinde set -euo pipefail birçok sessiz hatayı görünür hale getirir. Failed command deployment'ı durdurabilir. Undefined variable yanlış environment'a işlem yapılmasını önleyebilir. Pipeline failure doğru propagate edilir. Yine de beklenen hata durumları explicit handle edilmelidir.

Version Kontrolü

Deploy edilecek release ID açıkça parametre olmalıdır. "Latest" gibi belirsiz target kullanılmamalıdır. Artifact metadata Git SHA içerebilir. Aynı version tekrar deploy edilirse script davranışı bilinmelidir. Failed release block listesi kontrol edilebilir.

Artifact Download

Artifact trusted repository'den indirilmeli ve checksum doğrulanmalıdır. Network failure partial file bırakabilir. Temporary path kullanılıp download tamamlanınca release directory'ye taşınabilir. Authentication token minimum yetkili olmalıdır. Download log release ID'yi göstermelidir.

Dependency Install

Mümkünse dependency CI artifact içinde hazır olmalıdır. Sunucuda install gerekiyorsa lockfile kullanılmalıdır. Production package registry outage deployment'ı etkileyebilir. Yeni dependency mevcut release'i değiştirmemelidir. Versioned directory isolation korunmalıdır.

Migration

Migration execution explicit step olmalıdır. Hangi migration'ın çalışacağı önceden görülebilir. Destructive operation için approval eklenebilir. Migration başarısızsa application switch yapılmamalıdır. Recovery instruction log'da görünmelidir.

Config Validation

Application config schema deployment öncesi doğrulanabilir. Nginx için nginx -t çalıştırılır. Eksik environment variable erken yakalanır. Secret değeri loglanmamalıdır. Config validation başarısızsa current release korunur.

Service Switch

Yeni release hazır olduktan sonra symlink veya upstream değiştirilir. İşlem mümkün olduğunca atomic olmalıdır. Zero-downtime modelde green instance önce başlatılır. Traffic switch en son yapılır. Rollback target kaydedilir.

Health Verification

Local health check yeni backend'i doğrular. Public request Nginx ve TLS zincirini test eder. Retry sınırlı sayıda uygulanabilir. Error metric kısa observation window boyunca izlenir. Başarısızsa rollback action tetiklenebilir.

Rollback

Script eski release kimliğini önceden bilmelidir. Failed deployment target yeniden active edilmemelidir. Database action otomatik rollback'tan ayrılmalıdır. Rollback sonrası health check tekrar çalışır. Sonuç audit log'a yazılır.

CI/CD ile Ubuntu Sunucuya Deployment

CI/CD, build ve deployment işlemlerini tekrar üretilebilir hale getirir. GitHub Actions, GitLab CI veya Jenkins gibi sistemler aynı temel modeli uygulayabilir. Source önce build ve test edilir, ardından immutable artifact oluşturulur. Deploy job artifact'i Ubuntu sunucuya gönderir ve health check çalıştırır. Failure durumunda rollback kontrollü pipeline adımı olarak devreye girebilir.

GitHub Actions

GitHub Actions repository event'leriyle pipeline çalıştırabilir. Build ve test runner üzerinde yapılabilir. Artifact registry'ye çıktı yüklenir. Production deploy environment protection ile sınırlandırılabilir. SSH veya agent tabanlı deployment güvenli credential kullanmalıdır.

GitLab CI

GitLab CI stage ve environment modelini kullanır. Protected variable ve protected branch production erişimini sınırlandırabilir. Artifact veya container registry entegre kullanılabilir. Manual approval job eklenebilir. Deployment history environment üzerinden izlenebilir.

Jenkins

Jenkins esnek pipeline automation sağlar. Credential store kullanılmalıdır. Agent ve plugin güncellemeleri yönetilmelidir. Pipeline as code repository içinde tutulabilir. Production job yetkileri role bazlı sınırlandırılmalıdır.

Build

Source tek sefer build edilir. Runtime ve dependency version sabittir. Artifact metadata commit SHA taşır. Build log saklanır. Production sunucuda build tekrarlanmaz.

Test

Unit ve integration test deployment öncesi çalışır. Config veya migration validation eklenebilir. Failure artifact promotion'ı engeller. Security scan uygulanabilir. Test sonuçları release metadata'ya bağlanabilir.

Artifact

Build sonucu versioned artifact repository'ye yüklenir. Checksum veya digest saklanır. Stable release retention korunur. Aynı artifact staging ve production'a taşınır. Rebuild yapılmaz.

Deploy

Deploy job server'a minimum credential ile bağlanır. Versioned release directory oluşturulur. Config uygulanır. New service instance başlatılır. Traffic switch validation sonrası yapılır.

Health Check

CI local ve public endpoint test edebilir. Response version doğrulanır. Error rate başlangıç penceresinde gözlenebilir. Failure pipeline'ı kırar. Production için yalnızca command exit code'a güvenilmemelidir.

Rollback

Failed release previous stable artifact'e geri döndürülebilir. Manual veya automatic trigger kullanılabilir. Database migration compatibility kontrol edilir. Failed artifact tekrar deploy edilmemelidir. Recovery verification ayrı stage olmalıdır.

CI/CD'de SSH Anahtarlarını Nasıl Yönetmeli?

CI/CD'nin production sunucuya bağlanması en hassas credential noktalarından biridir. Dedicated deploy account kullanılmalı ve sudo yetkisi minimum tutulmalıdır. Deploy key yalnızca gerekli server ve işlem için geçerli olmalıdır. Secret store private key'i pipeline logundan uzak tutar. Daha olgun yapılarda short-lived credential ve SSH command restriction statik anahtar riskini azaltabilir.

Dedicated Deploy Account

CI normal admin hesabını kullanmamalıdır. Deploy için ayrı kullanıcı oluşturulmalıdır. Home ve file permission görevine göre sınırlandırılır. Interactive login ihtiyacı olmayabilir. Audit log automation action'larını ayırır.

Minimum Sudo Yetkisi

Deploy user full passwordless sudo almamalıdır. Yalnızca belirli systemctl veya deployment command izinli olabilir. Sudoers syntax dikkatle test edilmelidir. Wildcard kullanımından kaçınılmalıdır. Daha güvenli wrapper script tercih edilebilir.

Deploy Key

Deploy key yalnızca deployment amacıyla oluşturulmalıdır. Developer kişisel key'i CI'a kopyalanmamalıdır. Rotation periyodu belirlenebilir. Server compromised olduğunda key revoke edilmelidir. Aynı key çok sayıda environment için paylaşılmamalıdır.

Secret Store

CI secret store private key'i encrypted biçimde saklar. Pipeline çıktısında value maskelenmelidir. Fork pull request'lerine production secret verilmemelidir. Environment protection uygulanmalıdır. Secret erişimi audit edilebilir olmalıdır.

Short-Lived Credentials

Kısa ömürlü credential statik SSH key riskini azaltır. Certificate authority veya cloud identity entegrasyonu kullanılabilir. Credential yalnızca pipeline süresince geçerli olur. Revocation ihtiyacı azalır. Kurulum daha fazla altyapı gerektirir.

SSH Command Restriction

authorized_keys içinde belirli command restriction uygulanabilir. Key ele geçirilse bile generic shell erişimi verilmez. Deployment wrapper yalnızca güvenli parametreleri kabul eder. Path traversal ve command injection engellenmelidir. Audit daha anlaşılır hale gelir.

Audit Logging

Hangi pipeline'ın ne zaman hangi release'i deploy ettiği kaydedilmelidir. SSH login, sudo command ve deployment ID ilişkilendirilebilir. Secret value loglanmamalıdır. Incident sırasında timeline hızlı oluşturulur. Audit retention policy belirlenmelidir.

Ansible ile Ubuntu Servis Dağıtımı

Ansible sunucu configuration'ını idempotent hale getirmek için güçlü bir araçtır. Paket, kullanıcı, config, systemd ve Nginx ayarları playbook içinde version control altında tutulabilir. Aynı playbook yeni server provisioning ve mevcut server drift düzeltme için kullanılabilir. Application deployment ile base configuration ayrı role'lere bölünebilir. Çok sunuculu yapıda rolling update riski azaltır.

Idempotent Configuration

Playbook tekrar çalıştığında yalnızca gerekli değişikliği yapmalıdır. Aynı user veya package tekrar oluşturulmaz. Handler yalnızca config değiştiğinde service reload edebilir. Drift hızlı düzeltilir. Manual server değişiklikleri zamanla azalır.

Package Management

Gerekli package listesi açıkça tanımlanır. Version pin gerekiyorsa role içinde belirtilebilir. Cache update kontrollü yapılır. Security update politikası deployment'tan ayrılabilir. Package state audit edilebilir hale gelir.

User Management

Service ve deploy user otomatik oluşturulabilir. SSH key ve group membership versioned policy ile yönetilir. Eski kullanıcılar kaldırılabilir. Home ve shell ayarları standardize edilir. Fleet access daha tutarlı olur.

Config Template

Nginx veya application config template üzerinden üretilir. Environment value variable ile gelir. Secret Ansible Vault veya external manager üzerinden alınabilir. Template değişince handler çalışır. Syntax test başarısızsa reload engellenebilir.

systemd Service

Unit template server'a kopyalanabilir. Değişiklik sonrası daemon-reload handler tetiklenir. Service enable ve started state enforce edilir. Hardening seçenekleri aynı role içinde tutulur. Manual drift azalır.

Nginx

Virtual host config Ansible ile yönetilebilir. TLS path ve proxy upstream variable olarak verilebilir. Config test handler içinde uygulanabilir. Başarısız test active config'i bozmamalıdır. Birden fazla server aynı standardı kullanır.

Rolling Deployment

Ansible serial execution ile server'lar sırayla güncellenebilir. Load balancer'dan node çıkarılıp deploy yapılabilir. Health check sonrası traffic geri verilir. Failure sonraki hostlara geçişi durdurabilir. High availability korunur.

cloud-init ile İlk Sunucu Kurulumu

cloud-init yeni Ubuntu instance ilk açıldığında temel bootstrap işlemlerini otomatikleştirebilir. User, SSH key, package ve firewall başlangıç ayarları uygulanabilir. Ancak cloud-init zamanla tüm server configuration'ını taşıyan büyük script'e dönüşmemelidir. İlk bootstrap sonrasında Ansible gibi configuration management aracına devretmek daha sürdürülebilir olabilir. Böylece server provisioning standardı ve günlük yönetim ayrılır.

User

İlk admin veya deploy user cloud-init ile oluşturulabilir. Sudo policy açıkça tanımlanır. Root login azaltılabilir. Default cloud user kullanılmayacaksa lifecycle planlanmalıdır. SSH key aynı anda eklenebilir.

SSH Key

Public key provisioning sırasında eklenebilir. Image içinde private key bulunmamalıdır. Kullanıcı bazlı key tercih edilmelidir. Merkezi identity sistemi varsa bootstrap sonrası entegre edilir. Key rotation cloud-init görevi değildir.

Packages

Temel paketler ilk boot sırasında kurulabilir. Çok büyük install listesi instance readiness süresini uzatır. Package repository availability dikkate alınmalıdır. Production app dependency'leri artifact içinde tutulabilir. Base tooling sade olmalıdır.

Firewall

UFW temel kuralları bootstrap içinde uygulanabilir. SSH erişiminin yanlışlıkla kapanmaması gerekir. Cloud firewall ile birlikte planlanmalıdır. Application portları deployment sonrası açılabilir. Default deny güvenli başlangıçtır.

Bootstrap Script

Bootstrap script minimum sorumluluk taşımalıdır. Logging açık olmalıdır. Başarısızlık console üzerinden görülebilmelidir. Secret hardcode edilmemelidir. İkinci configuration management aşaması için agent veya user hazırlayabilir.

Configuration Management'e Devretme

Sunucu temel network ve admin erişimi kazandıktan sonra Ansible veya başka araç devralabilir. Uzun cloud-init script bakım yükü azalır. Aynı configuration mevcut server'larda da uygulanabilir. Drift kontrol edilir. Infrastructure ve configuration lifecycle daha net ayrılır.

systemd Timer mı Cron mu?

Cron basit zamanlanmış görevler için yıllardır kullanılan güçlü bir araçtır. systemd timer ise servis yönetimi, journald logging ve dependency modeliyle daha sıkı entegrasyon sağlar. Backup veya maintenance task aynı .service unit üzerinden çalıştırılabilir. Missed run davranışı timer ayarlarıyla daha açık yönetilebilir. Seçim ekip standardı ve görevin complexity seviyesine göre yapılmalıdır.

Cron

Cron syntax kısa ve taşınabilirdir. Basit günlük script için yeterli olabilir. Environment cron altında interactive shell'den farklıdır. Output yönlendirilmezse loglama sorunlu olabilir. Job overlap ayrıca kontrol edilmelidir.

systemd Timer

Timer ayrı service unit tetikler. Job output journald'a gider. Dependency ve resource limit uygulanabilir. Calendar syntax çeşitli schedule ihtiyaçlarını destekler. systemctl üzerinden status kolay görülür.

Service ile Timer Entegrasyonu

Zamanlama timer unit içinde, gerçek task service unit içinde tanımlanır. Aynı service manuel de çalıştırılabilir. Başarı ve failure state systemd tarafından izlenir. Resource limit eklenebilir. Testing daha kolay olur.

Logging

Cron job logu explicit yönlendirme gerektirebilir. systemd task stdout ve stderr'i journald'a gönderir. Unit bazlı filter kullanılabilir. Monitoring failure state'i yakalayabilir. Operasyon görünürlüğü artar.

Missed Run

Sunucu kapalıyken cron görevi kaçabilir. systemd timer belirli ayarlarla missed execution'ı boot sonrası çalıştırabilir. Her task için catch-up istenmeyebilir. Backup job için faydalı olabilir. Report email gibi görevlerde duplicate davranışı düşünülmelidir.

Backup ve Maintenance Jobs

Backup script'i oneshot service olarak tanımlanabilir. Timer belirli saatte tetikler. Failure alert alınabilir. CPU ve I/O limiti uygulanabilir. Job'un application peak saatine denk gelmemesi planlanmalıdır.

Ubuntu Servis Logları Nasıl İzlenir?

Ubuntu production sunucuda troubleshooting yaparken journald ve journalctl temel araçlardır. Servis bazında, boot bazında veya zaman aralığına göre log filtrelenebilir. Follow mode canlı hata takibini sağlar. Priority filter yalnızca warning veya error seviyelerini gösterebilir. Ubuntu production sunucuda Docker servis monitoring log ve otomatik restart yönetimi kullanılsa bile host-level journald kayıtları çoğu incident'te değerli bilgi sağlar.

journald

journald systemd log toplama servisidir. Kernel ve service çıktıları merkezi olarak saklanabilir. Metadata unit, PID ve timestamp içerir. Persistent veya volatile storage kullanılabilir. Disk retention ayarı yönetilmelidir.

journalctl

journalctl journald kayıtlarını sorgular. Filtreler incident araştırmasını hızlandırır. Root veya gerekli group yetkisi gerekebilir. Pager kullanımı büyük logda kolaylık sağlar. Output JSON formatında alınabilir.

Unit Bazlı Log

journalctl -u myapp yalnızca ilgili service loglarını gösterir. Application startup ve crash analizi için idealdir. Multiple unit filtrelenebilir. Version release sırasında timestamp ile daraltılabilir. CI deployment sonrası log check otomatikleştirilebilir.

Follow Mode

journalctl -f veya unit ile birlikte -f canlı log akışı verir. Deployment sırasında anlık error görmek için faydalıdır. Uzun süre açık session yerine merkezi monitoring tercih edilmelidir. High-volume log terminali doldurabilir. Filtering eklenebilir.

Priority Filter

Journal priority seviyelerine göre filtre yapılabilir. Warning, error ve critical kayıtları ayrıştırılabilir. Application stdout seviyeleri native syslog priority ile her zaman eşleşmeyebilir. Structured logging daha tutarlı hale getirilebilir. Alert için doğru severity mapping önemlidir.

Boot Bazlı Loglar

Previous boot logları reboot sonrası incident analizinde değerlidir. Boot index ile filtrelenebilir. Kernel veya service startup failure görülebilir. Persistent journal kapalıysa önceki boot logları kaybolabilir. Production'da retention buna göre ayarlanmalıdır.

Zaman Aralığına Göre Filtre

Incident başlangıç ve bitiş zamanına göre log seçilebilir. Deployment timestamp ile korelasyon yapılır. Timezone farkı dikkate alınmalıdır. UTC kullanımı merkezi sistemlerde faydalıdır. Narrow query büyük log hacmini yönetilebilir hale getirir.

journald Disk Kullanımı Nasıl Yönetilir?

journald logları sınırsız bırakılırsa disk kullanımı zamanla büyüyebilir. Journal disk usage düzenli kontrol edilmelidir. Retention ve maksimum boyut ayarları kullanılabilir. Vacuum komutları mevcut logları yaş veya boyuta göre temizleyebilir. Persistent journal ile log rotation stratejisi birlikte planlanmalıdır.

Journal Disk Usage

journalctl --disk-usage logların kapladığı alanı gösterir. Disk alert ile birlikte izlenebilir. Ani büyüme application error loop işareti olabilir. Root cause yalnızca log temizlemek değildir. Üreten servis de araştırılmalıdır.

Retention

Log retention compliance ve troubleshooting ihtiyacına göre belirlenir. Çok kısa süre geçmiş incident analizini engeller. Çok uzun süre local disk tüketir. Merkezi log gönderiliyorsa host retention daha kısa olabilir. Policy bütün serverlarda standardize edilmelidir.

Vacuum

Journal vacuum eski logları boyut veya zaman sınırına göre temizler. Acil disk problemi sırasında kullanılabilir. Ancak sürekli manual vacuum yerine kalıcı retention ayarı gerekir. Kritik incident logları silinmeden önce merkezi kopya kontrol edilmelidir. Automation kontrollü uygulanmalıdır.

Persistent Journal

Persistent journal reboot sonrasında logların korunmasını sağlar. Server troubleshooting için değerlidir. Disk kullanımına etkisi vardır. Rotation ve max size belirlenmelidir. Çok hassas log content security açısından ayrıca değerlendirilmelidir.

Log Rotation Stratejisi

journald kendi retention mekanizmasını kullanır. File tabanlı loglar için logrotate gerekebilir. İki sistemin aynı dosyayı yönetmemesi gerekir. Application'ın kendi rotation özelliği varsa conflict kontrol edilir. Monitoring disk growth'u izlemelidir.

Application Logları Nerede Tutulmalı?

Native systemd servislerde application loglarını stdout ve stderr'e yazmak çoğu zaman sade bir model sunar. journald merkezi toplama yapar. File log gerekiyorsa /var/log/myapp gibi ayrı dizin kullanılabilir. Structured JSON log merkezi sistemlerde sorgulamayı kolaylaştırır. Access, error ve security loglarının retention ile hassas veri politikaları ayrı belirlenmelidir.

stdout/stderr → journald

Application sadece stdout ve stderr'e yazar. systemd journald tarafından otomatik toplar. File ownership veya rotation application sorumluluğu olmaz. Container modeline de benzer yaklaşım sunar. Log severity ve structure yine application tarafından belirlenebilir.

/var/log/myapp

File log gereken legacy veya özel sistemlerde kullanılabilir. Directory service user'a ait olabilir. Logrotate zorunlu düşünülmelidir. File permission hassas data'ya göre ayarlanır. Merkezi agent bu dosyaları okuyabilir.

Structured JSON Logs

JSON log field bazlı arama sağlar. Request ID, user-safe identifier ve release version eklenebilir. Mesaj text parse ihtiyacı azalır. Secret ve kişisel veri filtrelenmelidir. Merkezi log platformu bu formatı doğrudan indexleyebilir.

Access Logs

Access log request method, path, status ve latency gibi bilgileri içerir. Nginx veya application seviyesinde tutulabilir. Duplicate log maliyeti değerlendirilmelidir. Sensitive query string maskelenmelidir. Traffic trend için metric'e de dönüştürülebilir.

Error Logs

Error log exception ve runtime failure bilgisi sağlar. Stack trace production debug için değerlidir. Secret veya token yazılmamalıdır. Aynı error'un milyonlarca kez loglanması rate control gerektirebilir. Error aggregation alert'e bağlanabilir.

Merkezi Log Platformu

Birden fazla server olduğunda tek tek SSH ile log bakmak verimsizdir. Merkezi platform search ve correlation sağlar. Host, service ve release label eklenmelidir. Retention maliyeti kontrol edilmelidir. Access yetkisi log hassasiyetine göre sınırlandırılmalıdır.

Nginx Logları Nasıl Kullanılır?

Nginx access ve error logları reverse proxy kaynaklı sorunları application hatalarından ayırmada çok değerlidir. Status code, upstream response time ve client IP bilgisi birlikte incelenebilir. Özellikle 499, 502, 503 ve 504 kodları farklı failure türlerine işaret eder. Log formatına upstream address ve request time eklemek troubleshooting'i hızlandırır. Sensitive header ve token değerleri loglanmamalıdır.

Access Log

Her request için method, path ve status kaydedilebilir. Latency field eklenebilir. Traffic pattern ve bot activity görülebilir. Log volume yüksek olabilir. Sampling veya retention ihtiyaca göre ayarlanabilir.

Error Log

Nginx configuration, upstream connection ve TLS sorunları error log'a yazılır. 502 problemi araştırırken ilk kaynaklardan biridir. Severity seviyesi production ihtiyacına göre seçilir. Debug level sürekli açık tutulmamalıdır. Log timestamp application loguyla karşılaştırılabilir.

Status Code

2xx, 4xx ve 5xx oranları servis sağlığını gösterir. 499 Nginx'e özgü client disconnect sinyali verir. 502 backend erişim sorunu olabilir. 503 availability veya upstream capacity problemi gösterebilir. 504 backend response timeout ile ilişkilidir.

Upstream Response Time

Bu değer backend application'ın cevap süresini ayırmaya yardımcı olur. Total request time yüksek ama upstream düşükse client veya proxy katmanı incelenebilir. Upstream yüksekse application veya database muhtemel adaydır. Metric olarak da export edilebilir. P95 trend deployment sonrası karşılaştırılabilir.

Client IP

Doğru client IP audit ve abuse detection için önemlidir. CDN veya load balancer varsa real IP module yapılandırılmalıdır. Trusted proxy range dışındaki forwarding header kabul edilmemelidir. IPv6 desteği unutulmamalıdır. Privacy ve retention politikası uygulanmalıdır.

499/502/503/504 Analizi

499 client connection'ı Nginx cevap vermeden kapattığında görülür. 502 genellikle upstream connection veya protocol problemidir. 503 service unavailable veya capacity failure olabilir. 504 upstream belirtilen sürede cevap vermediğinde görülür. Bu kodları topluca "Nginx hatası" diye değerlendirmek doğru root cause'u geciktirir.

Monitoring'de Hangi Sunucu Metrikleri İzlenmeli?

Sunucu monitoring yalnızca CPU ve memory ile sınırlı olmamalıdır. Load average, disk kullanımı, disk I/O, network ve open file sayısı application sağlığını doğrudan etkiler. Process count veya task sayısı runaway process problemini gösterebilir. Metric'lerin normal baseline'ı bilinmelidir. Alert eşikleri her server type için aynı sabit değeri kullanmak yerine workload davranışına göre ayarlanmalıdır.

CPU

CPU sürekli yüzde yüze yakınsa request latency artabilir. Tek process mi tüm host mu tüketiyor ayrılmalıdır. Steal time virtual server capacity problemi gösterebilir. Short spike normal olabilir. Sustained kullanım alert için daha anlamlıdır.

Memory

Free memory tek başına Linux'ta doğru yorum olmayabilir. Available memory ve swap davranışı izlenmelidir. Memory leak zaman içinde artan trend gösterir. OOM event kritik alarmdır. systemd MemoryMax ile service isolation sağlanabilir.

Load Average

Load average runnable ve uninterruptible task sayısına dair sinyal verir. CPU core sayısıyla birlikte yorumlanmalıdır. Yüksek disk I/O da load değerini artırabilir. Tek başına CPU metric olarak görülmemelidir. Trend uygulama latency'siyle karşılaştırılmalıdır.

Disk Usage

Disk dolduğunda application log yazamayabilir veya database durabilir. Root filesystem ve data volume ayrı izlenmelidir. Percentage yanında free byte değeri de önemlidir. Inode tükenmesi ayrıca gözlenebilir. Warning ve critical threshold erken alarm vermelidir.

Disk I/O

High I/O wait application latency'sini artırabilir. Database ve backup aynı disk üzerinde yarışabilir. Throughput, IOPS ve latency birlikte değerlendirilmelidir. Cloud volume limitleri bilinmelidir. Backup schedule peak traffic dışında tutulabilir.

Network

Network throughput, packet error ve connection count izlenebilir. Bandwidth saturation 5xx üretmeden performansı düşürebilir. External API timeout ile host network problemi ayrılmalıdır. Interface drop kritik sinyaldir. Traffic baseline kapasite planlamaya yardımcı olur.

Open File Count

Her socket file descriptor tüketir. Limit yaklaşınca yeni connection açılamayabilir. Nginx ve application için ayrı değer izlenebilir. Leak uzun süreli trend oluşturur. Limit artırmak root cause çözümü olmayabilir.

Process Count

Kontrolsüz child process oluşturma host kaynaklarını tüketebilir. Worker count release sonrası değişebilir. systemd TasksMax koruma sağlayabilir. Zombie process ayrıca izlenebilir. Normal baseline bilinmelidir.

Application Monitoring'de Hangi Metrikler İzlenmeli?

Host metric'leri sağlıklı olsa bile application kullanıcıya hata verebilir. Bu nedenle uptime, request rate, error rate ve latency doğrudan servis seviyesinde ölçülmelidir. Worker usage, queue depth ve database connection count backend kapasitesini gösterir. Her metric release version etiketi taşıyabilirse deployment karşılaştırması kolaylaşır. Monitoring gerçek kullanıcı sonucuna yakın business metric'lerle tamamlanmalıdır.

Uptime

Process uptime restart pattern'ini gösterir. Çok sık restart service instability işaretidir. HTTP uptime monitor dışarıdan erişimi test eder. Process uptime ile public uptime farklı olabilir. İkisi birlikte izlenmelidir.

Request Rate

Request rate traffic değişimini gösterir. Ani artış kapasite veya abuse problemi yaratabilir. Deployment sonrası traffic düşüşü route hatasına işaret edebilir. Endpoint bazında dağılım önemlidir. Rate business seasonality ile karşılaştırılmalıdır.

Error Rate

HTTP 5xx ve application exception metric ana sağlık göstergelerindendir. Total error yanında endpoint ve version kırılımı gerekir. Düşük trafikte percentage yanıltıcı olabilir. Minimum sample alert'e eklenebilir. Business failure 200 response içinde de olabilir.

Latency

P50 kullanıcıların çoğunu, P95 ve P99 tail davranışını gösterir. Average tek başına regression'ı gizleyebilir. Database query ve external call latency ayrı instrument edilebilir. Deployment marker chart'a eklenmelidir. Slow endpoint breakdown root cause'u hızlandırır.

Worker Usage

Worker concurrency ve busy oranı capacity durumunu gösterir. Sürekli yüzde yüz kullanım queue birikmesine yol açabilir. Çok fazla idle worker gereksiz memory tüketebilir. Autoscaling yoksa fixed count metric üzerinden ayarlanır. Deployment sonrası worker leak kontrol edilir.

Queue Depth

Queue depth background processing'in yetişip yetişmediğini gösterir. Tek başına sayıya değil lag süresine de bakılmalıdır. Traffic artışı normal geçici backlog oluşturabilir. Sürekli yükselen trend alarmdır. Worker failure ve dependency slowdown ayrı incelenir.

Database Connections

Connection pool kullanımı database kapasitesini etkiler. Deployment sırasında tüm process'lerin aynı anda reconnect olması spike yaratabilir. Idle ve active bağlantılar ayrılmalıdır. Pool limit host veya service sayısıyla uyumlu olmalıdır. Connection saturation error rate'ten önce alarm verebilir.

Servis Down Olduğunda Nasıl Alert Üretilir?

Servis down alarmı tek kaynağa bağlı olmamalıdır. systemd failure local process durumunu, health check application readiness'i, external uptime monitor ise gerçek kullanıcı erişimini gösterir. Log-based alert belirli exception pattern'lerini yakalayabilir. Disk ve certificate alarmı outage oluşmadan önce uyarı sağlayabilir. On-call notification gerçekten aksiyon alabilecek kişiye doğru severity ile ulaşmalıdır.

systemd Failure

Service failed state monitoring agent tarafından izlenebilir. Restart limit aşıldığında alert üretilebilir. Yalnızca tek restart için pager açmak gereksiz olabilir. Sürekli failure kritik hale gelir. Alert journal linki veya runbook içerebilir.

Health Check Failure

Health endpoint belirli aralıklarla sorgulanabilir. Birkaç ardışık failure sonrası alarm üretmek transient network sorununu filtreler. Local ve external monitor farklı katmanları test eder. Response latency de threshold olabilir. Health endpoint güvenilir ve hafif olmalıdır.

HTTP Uptime Monitoring

Dış monitoring gerçek internet yolunu test eder. DNS, TLS, firewall ve Nginx aynı anda doğrulanır. Farklı region'lardan kontrol false positive'i azaltabilir. Expected content veya status doğrulanabilir. Certificate bilgisi de ölçülebilir.

Log-Based Alerts

Belirli error pattern veya exception count alert tetikleyebilir. Tek stack trace pager gerektirmeyebilir. Rate ve severity kullanmak daha anlamlıdır. Secret içeren log alert mesajına kopyalanmamalıdır. Release version label eklenmelidir.

Disk Alert

Disk yüzde yüz olmadan erken alarm verilmelidir. Growth rate kalan süreyi tahmin etmeye yardımcı olur. Log, upload veya Docker image kaynağı ayrılabilir. Inode kullanımı da kontrol edilmelidir. Runbook cleanup için güvenli alanları belirtmelidir.

Certificate Alert

Certificate expiry yaklaşırken warning üretilmelidir. External endpoint üzerinden gerçek certificate kontrol edilmelidir. Renewal job failure ayrı alarm olabilir. Wildcard domain coverage incelenmelidir. Alarm gün sayısını açıkça göstermelidir.

On-Call Notification

Critical alarm yalnızca e-posta klasöründe kalmamalıdır. On-call kanalına ulaşmalıdır. Severity ve service owner doğru route edilmelidir. Duplicate alert incident sırasında gürültü yaratmamalıdır. Acknowledgement ve escalation policy tanımlanmalıdır.

Ubuntu Paket Güncellemeleri Nasıl Yönetilmeli?

Production Ubuntu sunucuda package update süresiz ertelenmemelidir. Özellikle güvenlik güncellemeleri düzenli uygulanmalıdır. Ancak her paket upgrade'i kontrolsüz biçimde anında production'a yüklemek de risk taşıyabilir. Update logları, reboot requirement ve service restart etkileri izlenmelidir. Çok sunuculu yapıda önce canary server üzerinde uygulamak daha güvenlidir.

apt update

apt update package index bilgisini yeniler. Kurulu paketleri tek başına değiştirmez. Upgrade öncesi hangi version'ların mevcut olduğunu görmeye yardımcı olur. Repository error kontrol edilmelidir. Automation exit code'u izlemelidir.

apt upgrade

apt upgrade uygun package update'lerini uygular. Service restart veya config prompt davranışı dikkate alınmalıdır. Maintenance window kullanılabilir. Critical server önce snapshot almak isteyebilir. Sonrasında health verification yapılmalıdır.

Security Updates

Security patch'ler yüksek önceliklidir. CVE severity ve exposure değerlendirilir. Internet-facing service hızlı güncellenmelidir. Application compatibility test mümkünse staging'de yapılır. Patch gecikmesi risk acceptance gerektirebilir.

unattended-upgrades

unattended-upgrades belirli paket güncellemelerini otomatik uygulayabilir. Security update gecikmesini azaltır. Ancak service restart etkisi anlaşılmalıdır. Reboot davranışı ayrıca ayarlanır. Critical uygulamalarda canary veya maintenance policy ile birlikte kullanılmalıdır.

Package Blacklist

Bazı paketler geçici olarak otomatik update dışına çıkarılabilir. Kernel, database veya custom runtime buna örnek olabilir. Blacklist kalıcı unutulmamalıdır. Security etkisi düzenli review edilmelidir. Upgrade planı ayrı ticket ile takip edilmelidir.

Update Logs

Hangi paketin ne zaman güncellendiği incident analysis için değerlidir. apt history log ve unattended-upgrades log incelenebilir. Deployment timeline ile ilişkilendirilebilir. Monitoring package update sonrası service failure'ı yakalamalıdır. Fleet management merkezi görünürlük sağlayabilir.

Production'da Automatic Security Updates Güvenli midir?

Automatic security update saldırı penceresini azaltır, ancak service restart ve compatibility etkisini de beraberinde getirebilir. Tek sunuculu küçük sistemde uygun maintenance yaklaşımıyla oldukça faydalı olabilir. Kritik uygulamalarda canary server veya staged fleet update daha güvenli modeldir. needrestart hangi servislerin eski library ile çalıştığını göstermeye yardımcı olabilir. Otomatik reboot varsayılan seçenek haline getirilmeden önce high availability ve health verification tasarlanmalıdır.

Güvenlik Avantajı

Patch yayınlandıktan sonra manual takvimi beklemek risk oluşturur. Automation güvenlik update'ini hızla uygular. Özellikle internet-facing paketler için değerlidir. Human unutma faktörü azalır. Vulnerability management yine asset inventory gerektirir.

Beklenmeyen Service Restart

Package update servis restart tetikleyebilir. Tek instance uygulamada kısa kesinti yaşanabilir. Connection drain uygulanmayabilir. Maintenance window bu riski azaltır. Update sonrası health check zorunlu olmalıdır.

needrestart

needrestart hangi process'lerin güncellenmiş library sonrası restart gerektirdiğini gösterebilir. Otomatik restart policy ortamın ihtiyacına göre seçilmelidir. Critical service kontrollü restart edilebilir. Reboot requirement ayrı incelenir. CI/CD deployment ile çakışmaması gerekir.

Maintenance Window

Update belirli düşük trafik saatlerinde uygulanabilir. Kullanıcıya bakım bildirimi gerekebilir. High availability varsa node'lar sırayla güncellenir. Backup ve rollback hazırlığı kontrol edilir. Window sonunda health verification yapılır.

Critical Service Exclusion

Database veya özel runtime otomatik restart'tan geçici olarak hariç tutulabilir. Ancak exclusion security patch'i sonsuza kadar engellememelidir. Ayrı kontrollü update planı oluşturulur. Owner ve deadline belirlenir. Risk görünür tutulmalıdır.

Canary Server Update

Fleet içindeki bir sunucu önce güncellenebilir. Health ve metric birkaç saat gözlenir. Problem yoksa diğer node'lara rollout yapılır. Load balancer traffic kontrolü kullanılır. Single-host sistemde staging server benzer rol oynayabilir.

Fleet Management

Onlarca server olduğunda tek tek apt çalıştırmak sürdürülebilir değildir. Merkezi patch orchestration kullanılabilir. Update compliance ve failure görünür olur. Server grupları kademeli güncellenir. Audit log hangi hostun hangi version'da olduğunu gösterir.

Sunucu Ne Zaman Reboot Edilmeli?

Kernel veya bazı low-level library güncellemeleri reboot gerektirebilir. Ubuntu sistemlerinde reboot-required işareti bu ihtiyacı gösterebilir. Reboot maintenance window içinde planlanmalı ve startup dependency'leri önceden test edilmelidir. Otomatik reboot tek instance production'da kullanıcı kesintisi oluşturabilir. Reboot sonrası yalnızca SSH erişimi değil application health ve background job'lar da doğrulanmalıdır.

/var/run/reboot-required

Bu dosyanın varlığı reboot gerektiğine işaret edebilir. Automation monitoring'e metric gönderebilir. Dosya tek başına acil reboot zamanı belirlemez. Maintenance planı yapılmalıdır. Neden reboot gerektiği package context ile incelenebilir.

Kernel Update

Yeni kernel çoğu durumda reboot sonrası aktif olur. Security patch önemine göre zamanlama yapılır. Live patch bazı senaryolarda seçenek olabilir. Reboot sonrası doğru kernel version kontrol edilir. Driver veya module compatibility test edilmelidir.

Maintenance Window

Traffic düşük zaman seçilebilir. Backup ve on-call erişimi hazır olmalıdır. Boot failure durumunda console erişimi gereklidir. High availability varsa node'lar sırayla reboot edilir. Window bitmeden application doğrulanmalıdır.

Automatic Reboot Riski

Tek production server beklenmedik saatte reboot olursa outage oluşur. Application enable edilmemişse boot sonrası gelmez. Database recovery süresi olabilir. Scheduled jobs etkilenebilir. Bu nedenle automatic reboot environment'a göre dikkatle yapılandırılmalıdır.

Reboot Sonrası Health Verification

systemd servisleri active mi kontrol edilir. Nginx ve TLS endpoint test edilir. Database connection doğrulanır. Queue worker ve timer'lar gözden geçirilir. Monitoring normale dönmeden maintenance tamamlanmış sayılmamalıdır.

Backup Stratejisi Nasıl Oluşturulur?

Backup stratejisi yalnızca server snapshot almak değildir. Application file, config, database ve user upload ayrı recovery ihtiyacına sahiptir. Secret'lar backup içinde bulunuyorsa encryption ve access control daha sıkı olmalıdır. Off-site kopya aynı provider veya sunucu kaybına karşı koruma sağlar. Recovery tasarımında hangi verinin ne kadar sürede ve ne kadar eski haliyle geri getirilebileceği açıkça tanımlanmalıdır.

Application Files

Immutable artifact registry'de tutuluyorsa application code ayrıca backup gerektirmeyebilir. Ancak custom file veya runtime asset incelenmelidir. Release artifact tekrar indirilebilir olmalıdır. Source Git repository'de korunur. Backup kaynakları gereksiz duplicate oluşturmamalıdır.

Config

Version control dışında kalan production config backup'a dahil edilmelidir. Secret içeriyorsa encrypted tutulmalıdır. Configuration management kullanılıyorsa restore source of truth üzerinden yapılabilir. Manual server-only config risklidir. Recovery runbook config kaynaklarını listeler.

Database

Database backup en kritik parçadır. Logical dump, physical backup veya managed snapshot kullanılabilir. RPO ihtiyacı backup sıklığını belirler. PITR transaction log desteği sağlayabilir. Restore testi düzenli yapılmalıdır.

User Uploads

User upload application release'ten bağımsız mutable data'dır. Object storage veya ayrı volume kullanılabilir. Backup ve replication uygulanmalıdır. File metadata ve permission restore edilmelidir. Büyük media dataset için incremental yaklaşım faydalıdır.

Secrets

Secret backup gerekiyorsa güçlü encryption uygulanmalıdır. Eski credential recovery sonrası geçersiz olabilir. Secret manager kendi backup ve disaster recovery modeline sahip olabilir. Access ayrı role ile sınırlandırılmalıdır. Backup içinde plain text bırakılmamalıdır.

Server Snapshot

Server snapshot hızlı full-system recovery sağlayabilir. Ancak application-consistent database backup yerine geçmeyebilir. Snapshot aynı cloud account içinde olduğundan account compromise riskini paylaşabilir. Off-site kopya ayrıca gerekir. Restore test yapılmalıdır.

Off-Site Backup

Backup aynı server diskinde tutulursa disk kaybında birlikte gider. Farklı storage veya provider kopyası ek koruma sağlar. Access credential primary sistemden ayrılabilir. Immutable retention ransomware riskini azaltabilir. Restore bandwidth ve süre bilinmelidir.

3-2-1 Backup Yaklaşımı

3-2-1 yaklaşımı kritik verinin üç kopyasını, iki farklı ortamını ve bir off-site kopyasını hedefler. Modern altyapıda farklı ortam kavramı farklı storage sınıfları veya hesaplarla uygulanabilir. Immutable backup ransomware ve accidental deletion riskini azaltır. Model tek başına yeterli değildir, restore başarısı ayrıca test edilmelidir. Uygulama RPO ve RTO değerleri backup sıklığını ve mimarisini belirler.

Üç Kopya

Primary data dahil toplam üç kopya hedeflenebilir. Bir backup bozulduğunda ikinci kopya seçenek sağlar. Kopyalar aynı failure domain içinde olmamalıdır. Database ve upload için farklı strategy olabilir. Kritikity düzeyi sayıdan daha önemlidir.

İki Farklı Ortam

Aynı fiziksel disk veya storage sistemi tek hata noktasıdır. Farklı storage media veya hizmet kullanmak dayanıklılığı artırır. Cloud object storage ve local snapshot birlikte kullanılabilir. Access policy ayrı tutulmalıdır. Verification checksum ile yapılabilir.

Bir Off-Site Kopya

Yangın, region outage veya account compromise local kopyaları etkileyebilir. Off-site backup farklı location'da tutulur. Encryption key recovery ayrıca planlanmalıdır. Transfer maliyeti ve restore süresi bilinmelidir. Periyodik restore drill yapılmalıdır.

Immutable Backup

Belirli retention süresinde silinemeyen backup ransomware riskini azaltır. Admin credential compromise olsa bile saldırgan kopyayı silemeyebilir. Retention maliyet yaratır. Compliance gereksinimiyle uyumlu seçilmelidir. Break-glass deletion policy sıkı tutulmalıdır.

Ransomware Dayanıklılığı

Backup sistemi production credential ile tamamen aynı yetkiye sahip olmamalıdır. Immutable storage ve ayrı account kullanılabilir. Backup agent yalnızca write yetkisiyle sınırlanabilir. Restore credential farklı korunmalıdır. Incident drill bu senaryoyu da test etmelidir.

Backup Almak Yeterli midir?

Backup dosyasının mevcut olması recovery yapılabileceği anlamına gelmez. Restore testi yapılmamış backup eksik, şifreli veya bozuk çıkabilir. RPO ne kadar veri kaybının kabul edilebilir olduğunu, RTO ise servisin ne kadar sürede geri gelmesi gerektiğini tanımlar. Database ve full server recovery farklı runbook gerektirebilir. Gerçek güven backup alınmasıyla değil, doğrulanmış restore kapasitesiyle oluşur.

Restore Test

Backup periyodik olarak ayrı ortamda restore edilmelidir. Database integrity kontrolü yapılmalıdır. Application test query çalıştırabilir. Restore süresi kaydedilir. Failure backup pipeline'ın kendisi kadar kritik görülmelidir.

RPO

Recovery Point Objective kabul edilen maksimum veri kaybı penceresini ifade eder. RPO bir saat ise backup veya replication buna uygun tasarlanmalıdır. Finansal sistem daha düşük değer isteyebilir. Sadece günlük backup yeterli olmayabilir. İş ihtiyacı teknik çözümü belirler.

RTO

Recovery Time Objective servis ne kadar sürede geri gelmeli sorusunu cevaplar. Büyük backup restore saatler sürebilir. High availability daha düşük RTO sağlayabilir. Runbook manuel adımları azaltabilir. Düzenli drill gerçek süreyi gösterir.

Database Recovery

Database recovery snapshot, dump veya PITR üzerinden yapılabilir. Application version schema ile uyumlu olmalıdır. Restore sırasında yazma trafiği durdurulabilir. Data consistency kontrol edilir. Recovery sonunda business validation gerekir.

Full Server Recovery

Sunucu tamamen kaybolduysa yeni instance provisioning gerekebilir. cloud-init ve Ansible bu süreci hızlandırır. Application artifact registry'den alınır. Config ve data backup restore edilir. DNS veya load balancer yeni server'a yönlendirilir.

Recovery Runbook

Runbook hangi backup'ın nerede olduğunu açıklar. Credential ve encryption key erişim yolu bulunmalıdır. Restore komutları test edilmiş olmalıdır. Verification adımları yazılır. Owner ve escalation contact güncel tutulur.

Ubuntu Sunucuda Disk Dolması Nasıl Önlenir?

Disk dolması en basit görünen ama production servislerini tamamen durdurabilen olaylardan biridir. Log growth, eski release dizinleri, package cache ve Docker image'ları düzenli alan tüketir. User upload ve database logları daha hızlı büyüyebilir. Disk usage alert doluluk kritik seviyeye gelmeden çalışmalıdır. Otomatik cleanup yalnızca güvenli ve gerçekten yeniden üretilebilir dosyaları hedeflemelidir.

Log Growth

Application error loop saniyeler içinde büyük log oluşturabilir. journald retention ve logrotate uygulanmalıdır. Log rate alert root cause'u erken gösterebilir. Debug logging production'da sürekli açık tutulmamalıdır. Merkezi forwarding local retention ihtiyacını azaltabilir.

Old Releases

Versioned deployment disk üzerinde eski artifact'leri bırakır. Son birkaç stable release korunabilir. Çok eski release otomatik temizlenebilir. Active current target hiçbir zaman silinmemelidir. Security veya audit retention ayrıca değerlendirilmelidir.

Package Cache

apt cache zaman içinde alan tüketebilir. Güvenli cleanup yapılabilir. Ancak disk probleminde asıl kaynağı bulmadan cache temizlemek geçici çözüm olur. Server image standardı gereksiz package sayısını azaltır. Monitoring growth trend'ini göstermelidir.

Docker Images

Docker eski image ve layer'ları biriktirebilir. Kör prune rollback artifact'lerini silebilir. Production stable image korunmalıdır. Registry ana source olsa bile network outage senaryosu düşünülmelidir. Cleanup label veya retention policy ile yapılmalıdır.

User Uploads

User upload kontrolsüz büyüyebilir. Quota ve object storage kullanılabilir. Local disk yalnızca temporary cache olarak tutulabilir. Upload size limit uygulanmalıdır. Backup storage büyüklüğü ayrıca planlanmalıdır.

Database Logs

Database WAL veya binary log retention yanlışsa disk hızla dolabilir. Replication veya backup dependency buna bağlı olabilir. Rastgele silmek data recovery'yi bozabilir. Database-specific cleanup policy kullanılmalıdır. Alert data volume için ayrı oluşturulmalıdır.

Disk Usage Alerts

Warning threshold yüzde yetmiş veya seksen gibi erken seviyede başlayabilir. Growth velocity daha faydalı olabilir. Root ve data filesystem ayrı izlenmelidir. Inode alarmı eklenmelidir. Alert güvenli cleanup runbook'una bağlantı içerebilir.

502 Bad Gateway Nasıl Çözülür?

502 Bad Gateway Nginx'in backend application'dan geçerli yanıt alamadığını gösterir. İlk olarak application service durumuna, socket veya port değerine ve permission'a bakılmalıdır. Nginx error log genellikle doğrudan ipucu verir. systemd journal application'ın neden başlamadığını gösterebilir. Sorunu çözmeden timeout değerini büyütmek çoğu zaman doğru yaklaşım değildir.

Application Service Down

systemctl status myapp service active mi kontrol edilir. Failed ise journal log incelenir. Config veya runtime error olabilir. Restart loop varsa root cause düzeltilmelidir. Servis healthy olduktan sonra Nginx tekrar test edilir.

Yanlış Socket/Port

Nginx bir portu beklerken application başka portta dinliyor olabilir. ss ile gerçek listener kontrol edilir. Unix socket path typo olabilir. Deployment sonrası symlink path değişmiş olabilir. Config iki tarafta aynı olmalıdır.

Permission

Unix socket backend'de Nginx worker'ın socket erişimi olmayabilir. Parent directory execute permission da gereklidir. Ownership group üzerinden çözülebilir. 777 vermek yerine doğru permission modeli kurulmalıdır. AppArmor gibi ek güvenlik katmanı varsa ayrıca incelenmelidir.

Timeout

Backend connection kuruluyor ama cevap vermiyorsa timeout görülebilir. Application log long-running request'i göstermelidir. Database veya external dependency yavaş olabilir. Timeout büyütmek sadece semptomu geciktirebilir. Performance root cause bulunmalıdır.

Nginx Error Log

Error log "connection refused", "no such file" veya "permission denied" gibi açık mesaj verebilir. Mesaj doğrudan hangi katmana bakılacağını söyler. Timestamp application restart ile karşılaştırılır. Tek satır yerine surrounding context incelenmelidir. Log level geçici artırılabilir.

systemd Journal

Application crash veya config failure journal'da görünür. Exit code ve stack trace incelenir. EnvironmentFile eksik olabilir. Port already in use mesajı bulunabilir. Deployment release version ile log ilişkilendirilmelidir.

Servis Başlamıyorsa Nasıl Troubleshooting Yapılır?

Servis başlamıyorsa rastgele config değiştirmek yerine sistematik sıra izlemek daha hızlı sonuç verir. Önce systemctl status, ardından journal log ve exit code incelenmelidir. Environment variable, file permission ve port conflict sık sebeplerdir. Dependency failure da application startını engelleyebilir. Değişiklik yaptıktan sonra tek seferde bir hipotez test etmek troubleshooting'i anlaşılır tutar.

systemctl status

Status unit state ve son logları gösterir. ExecStart command veya permission hatası görülebilir. Active değilse failure timestamp incelenir. Restart count önemli sinyaldir. Sonraki adım journal detayına geçmektir.

journalctl -u

Unit loglarını daha geniş zaman aralığında gösterir. Startup stack trace burada bulunabilir. Previous boot log gerekirse seçilebilir. Error öncesindeki warning incelenmelidir. Log filter troubleshooting süresini azaltır.

Exit Code

Process exit code failure türünü anlamaya yardımcı olur. systemd status bazı result bilgisini gösterir. Application kendi anlamlı exit code'larını kullanabilir. Signal ile termination ayrı incelenmelidir. OOM kill durumunda kernel log kontrol edilir.

Environment Variable

Eksik database URL veya secret startup failure oluşturabilir. EnvironmentFile path doğru olmalıdır. Variable syntax shell ile aynı değildir. Secret value loglanmadan existence kontrol edilebilir. Deployment config validation bunu önceden yakalayabilir.

File Permission

Service user executable veya config okuyamıyor olabilir. Working directory traverse permission gerekir. Log veya data dizinine write izni eksik olabilir. sudo -u serviceuser ile command test edilebilir. Ownership doğru modelle düzeltilmelidir.

Port Conflict

Başka process aynı portu dinliyor olabilir. ss -lntp listener'ı gösterir. Eski release process'i kalmış olabilir. systemd duplicate unit hatası olabilir. Portu değiştirmekten önce beklenmeyen process araştırılmalıdır.

Dependency Failure

Database, DNS veya mount hazır değilse application başlayamayabilir. systemd ordering tek başına remote dependency availability garanti etmez. Application retry strategy kullanabilir. Health readiness false kalabilir. Dependency monitor root cause'u ayrı göstermelidir.

Port Çakışması Nasıl Tespit Edilir?

Port conflict deployment sırasında yeni instance'ın başlamasını engelleyebilir. ss ile listening socket ve process PID görülebilir. systemd socket activation varsa portu application değil systemd tutuyor olabilir. Container port mapping ayrıca kontrol edilmelidir. Yanlış bind address de servisin beklenenden farklı interface üzerinde dinlemesine yol açabilir.

ss

ss modern Linux socket inceleme araçlarından biridir. TCP ve UDP listener'ları gösterebilir. PID bilgisi için gerekli yetki gerekebilir. Filter kullanarak belirli port incelenebilir. Troubleshooting script'te güvenilir başlangıçtır.

Listening Socket

Port LISTEN state'te mi kontrol edilir. Yalnızca 127.0.0.1 mı yoksa 0.0.0.0 mı dinlediği önemlidir. Public exposure bind address'ten anlaşılır. IPv6 listener ayrıca görülebilir. Nginx ve application listener'ları ayrı olmalıdır.

Process PID

Socket'i hangi process'in tuttuğu PID üzerinden bulunur. Eski deploy process'i olabilir. systemd main PID ile karşılaştırılır. Manual process çalıştırılmışsa stop edilmelidir. Kill kullanmadan önce process ownership anlaşılmalıdır.

systemd Socket

Portu .socket unit tutuyor olabilir. Application başlatılınca inherited socket alabilir. Bu durumda ikinci manual process bind edemez. systemctl status socket unit incelenmelidir. Tasarım dokümante edilmelidir.

Container Port

Docker host port publish etmiş olabilir. Container stop edilmeden native service aynı portu kullanamaz. docker ps mapping'i gösterir. Compose config incelenmelidir. Host firewall container rule davranışı ayrıca düşünülmelidir.

Yanlış Bind Address

Application sadece localhost beklenirken tüm interface'lerde dinliyor olabilir. Bu security riskidir. Tersi durumda Nginx başka interface'e bağlanmaya çalışabilir. Config address açıkça belirtilmelidir. Deployment verification listener address kontrolünü içerebilir.

Servis Boot Sonrası Neden Başlamıyor?

Servis manuel start ile çalışıp reboot sonrasında başlamıyorsa enable ve dependency ayarları kontrol edilmelidir. WantedBy doğru target ile ilişki kurmalıdır. Network veya mount readiness startup sırasını etkileyebilir. Environment file boot sırasında farklı path veya mount üzerinde olmayabilir. Reboot testi production hazırlığının gerçek parçası olmalıdır.

systemctl enable

Servis yalnızca start edilmiş ancak enable edilmemiş olabilir. is-enabled durumu doğrulanır. Enable appropriate target symlink oluşturur. Running state reboot guarantee değildir. Configuration management enable state'i enforce edebilir.

WantedBy

WantedBy enable sırasında hangi target'a link kurulacağını belirler. Server application için multi-user target uygundur. Yanlış target boot sırasında devreye girmeyebilir. Unit install section gözden geçirilmelidir. Enable sonrası link oluşturulduğu doğrulanabilir.

Dependency Order

Application required mount veya networkten önce başlayabilir. After ordering yardımcı olur. Ancak remote database availability garanti edilmez. Application startup retry kullanmalıdır. Boot log dependency timeline'ı gösterir.

Network-Online

network-online.target network configuration'ın hazır olmasını hedefler. Her environment'ta internet erişimi garantisi değildir. Service remote endpoint'e bağımlıysa retry gerekir. Boot yavaşlamaması için gereksiz dependency eklenmemelidir. Cloud network initialization test edilmelidir.

Mount Dependency

Application data ayrı disk veya network mount üzerindeyse boot order kritik olabilir. Mount başarısızsa service başlamamalı veya degraded davranmalıdır. systemd mount dependency tanımlanabilir. Data directory fallback yanlış local path oluşturmamalıdır. Alert mount failure'ı yakalamalıdır.

Environment File

EnvironmentFile boot sırasında mevcut olmayabilir. Secret mount daha geç bağlanabilir. Wrong permission service startını engeller. Optional file kullanımı bilinçli yapılmalıdır. Startup error journal'da açık görünmelidir.

systemd ile Servis Performansı Nasıl Analiz Edilir?

systemd ve cgroup araçları application'ın host kaynaklarını nasıl kullandığını görmeye yardımcı olur. systemd-cgtop servis bazlı CPU ve memory görünümü sağlayabilir. Process tree child process dağılımını gösterir. Resource limit değerleri gerçek kullanım ile karşılaştırılmalıdır. Boot performance ise startup zincirinde hangi unit'in gecikme oluşturduğunu ortaya çıkarabilir.

systemd-cgtop

systemd-cgtop cgroup bazlı kaynak kullanımını gösterir. Hangi service'in CPU veya memory tükettiği hızlı görülebilir. Container ve native servisler farklı hierarchy altında bulunabilir. Snapshot yerine trend monitoring daha değerlidir. Incident sırasında hızlı teşhis aracıdır.

CPU Kullanımı

Service CPU değeri host total ile karşılaştırılmalıdır. Single-thread uygulama bir core'u tamamen tüketebilir. CPUQuota throttling uygulanıyorsa metric ayrıca incelenir. Deployment regression correlation yapılabilir. Profiling root cause için gerekebilir.

Memory

Resident memory ve cgroup memory kullanımına bakılabilir. Cache ve heap davranışı runtime'a göre farklıdır. MemoryMax yakınında application risk altındadır. Leak zaman içinde artan çizgi oluşturur. Restart geçici çözüm olsa da root cause araştırılmalıdır.

Process Tree

Worker ve child process'lerin parent ilişkisi görülebilir. Beklenmeyen orphan veya zombie process bulunabilir. Gunicorn worker sayısı doğrulanabilir. Fork storm kolay fark edilir. systemd main PID ile tree karşılaştırılır.

Resource Limits

Unit üzerindeki limitler gerçek workload ihtiyacını karşılamalıdır. Çok düşük file limit veya memory cap random error oluşturabilir. Limitsiz service host riskini artırır. Load test optimum değer bulmaya yardımcı olur. Limit değişikliği audit edilmelidir.

Boot Performance

systemd-analyze benzeri araçlar boot sırasında hangi unit'in yavaş olduğunu gösterebilir. Application startup sırası incelenir. Gereksiz network wait service boot'u geciktirebilir. Reboot RTO bu sürelerden etkilenir. High availability için node recovery süresi önemlidir.

Tek Ubuntu Sunucuda Birden Fazla Servis Nasıl Çalıştırılır?

Tek Ubuntu sunucuda birden fazla application servisi çalıştırmak mümkündür ve küçük ekipler için maliyet avantajı sağlar. Her servis farklı local port veya Unix socket kullanmalıdır. Nginx subdomain veya path bazında virtual host yönlendirmesi yapabilir. Dedicated user ve resource limit failure isolation sağlar. Bir servisin memory veya disk problemi diğer uygulamaları etkilemesin diye monitoring daha dikkatli kurulmalıdır.

Farklı Local Portlar

Her application benzersiz localhost port kullanabilir. Nginx domain bazında doğru portu proxy eder. Port listesi configuration inventory içinde tutulmalıdır. Public firewall bu portları açmaz. Conflict deployment testinde yakalanabilir.

Unix Sockets

Her servis ayrı socket path kullanabilir. Permission group birbirinden ayrılabilir. Nginx worker gerekli socket'lere erişir. Socket directory runtime sırasında oluşturulabilir. Stale socket cleanup gerekir.

Subdomain Routing

api.example.com ve admin.example.com farklı backend'lere yönlendirilebilir. TLS certificate her domain'i kapsamalıdır. DNS aynı server IP'sine işaret edebilir. Nginx ayrı server block kullanır. Service failure diğer subdomain'i etkilememelidir.

Nginx Virtual Hosts

Her site için ayrı configuration file okunabilirliği artırır. Enable symlink modeli kullanılabilir. Config test bütün virtual hostları birlikte doğrular. Default host güvenli response vermelidir. Duplicate server_name warning kontrol edilmelidir.

Dedicated Users

Her service ayrı Unix user ile çalışır. File erişimi izole olur. Bir uygulama compromise olduğunda diğerinin config'ine erişim zorlaşır. Shared resource gerekiyorsa group ile kontrollü paylaşılır. Service account login kapalı tutulabilir.

Resource Limits

CPU ve memory limitleri noisy neighbor etkisini azaltır. Disk I/O ve open files da yönetilebilir. Aynı host kapasitesi toplam service peak'lerine göre planlanmalıdır. Limit aşımı alert üretmelidir. Critical service daha fazla reservation alabilir.

Failure Isolation

Tek sunucu fiziksel single point of failure olmaya devam eder. Ancak process ve user isolation application-level failure'ı sınırlayabilir. Bir servis crash diğerini restart etmemelidir. Shared Nginx veya disk yine ortak dependency'dir. Critical uygulamalar için multi-server mimari düşünülmelidir.

Container mı Native systemd Service mi?

Container ve native systemd deployment birbirinin doğrudan üstün alternatifi değildir. Native servis küçük VPS ve az sayıda application için çok sade olabilir. Docker dependency isolation ve portable artifact avantajı sunar. Container image rollback kolaylığı sağlar, fakat networking, volume ve image lifecycle gibi yeni operasyon alanları getirir. Seçimi ekip yetkinliği ve uygulama sayısı belirlemelidir.

Native Deployment

Application doğrudan host runtime üzerinde çalışır. systemd process'i yönetir. Dosya ve network yapısı daha sade olabilir. Container layer overhead ve tooling yoktur. Dependency isolation uygulama seviyesinde ayrıca sağlanmalıdır.

Docker

Docker application ve runtime'ı image içinde paketler. CI aynı image'ı staging ve production'a taşıyabilir. Image digest immutable artifact sağlar. Container restart policy veya systemd wrapper kullanılabilir. Volume ve log growth yönetilmelidir.

Dependency Isolation

Container her servis için ayrı filesystem ve runtime environment sağlar. Native deployment virtualenv veya fixed runtime ile isolation yapabilir. Çok farklı runtime version'ları aynı hostta container ile daha kolay yönetilebilir. Güvenlik isolation tamamen container'a bırakılmamalıdır. Host kernel ortaktır.

Resource Overhead

Container process virtual machine kadar ağır değildir. Yine de Docker daemon, image storage ve network layer operasyon maliyeti ekler. Küçük VPS'de disk alanı önemli olabilir. Native service daha az moving part içerir. Gerçek kaynak farkı application'a göre ölçülmelidir.

Rollback

Container image digest eski version'a hızlı dönüş sağlar. Native versioned directory aynı avantajı sunabilir. Her iki modelde database compatibility gerekir. Docker latest kullanımı rollback güvenliğini zayıflatır. Immutable version temel prensiptir.

Portability

Container runtime dependency'yi paketlediği için environment farklarını azaltır. Aynı image farklı hostlarda çalışabilir. Kernel ve architecture yine önemlidir. Native binary özellikle Go gibi dillerde oldukça portable olabilir. Tool seçimi mevcut deployment hedefleriyle uyumlu olmalıdır.

Küçük VPS İçin Hangisi?

Tek veya birkaç servis için systemd ve Nginx çoğu zaman yeterlidir. Ekip Docker biliyorsa container kullanmak da mantıklıdır. Sırf trend olduğu için container eklemek operasyon yükünü artırabilir. Runtime conflict veya CI image workflow varsa Docker değer kazanır. Basitlik küçük sistemlerde önemli güvenlik avantajıdır.

Ne Zaman Kubernetes'e Geçilmelidir?

Kubernetes'e geçiş yalnızca container kullandığınız için gerekli değildir. Tek sunucunun availability ve scaling sınırları iş ihtiyacını karşılamadığında orkestrasyon anlamlı hale gelir. Çok sayıda service, horizontal scaling ve self-healing ihtiyacı güçlü sinyallerdir. Buna karşılık Kubernetes önemli operasyon yükü getirir. systemd ve Nginx birçok küçük ve orta ölçekli sistemde yıllarca yeterli olabilir.

Tek Sunucunun Sınırları

Tek host hardware ve network failure için single point of failure'dır. Dikey scaling bir noktada sınıra ulaşır. Maintenance reboot outage oluşturabilir. İkinci server ve load balancer önceki adım olabilir. Kubernetes tek seçenek değildir.

High Availability

Bir node kaybolduğunda service başka node üzerinde devam etmelidir. Kubernetes scheduling bunu otomatikleştirebilir. Database availability yine ayrı problem olarak kalır. Load balancer ve storage tasarımı gerekir. HA iş ihtiyacına göre maliyetlendirilmelidir.

Çok Sayıda Service

Onlarca microservice'in port, deployment ve restart yönetimi native hostlarda zorlaşabilir. Kubernetes declarative workload modeli standardizasyon sağlar. Service discovery ve config yönetimi kolaylaşır. Buna karşılık cluster operasyon bilgisi gerekir. Küçük monolith için gereksiz olabilir.

Horizontal Scaling

Replica sayısı workload'a göre artırılabilir. Load balancing platform tarafından sağlanır. Stateless application buna uygun olmalıdır. Session ve upload externalize edilmelidir. Database capacity bottleneck olmaya devam edebilir.

Self-Healing

Health check başarısız pod yeniden oluşturulabilir. Node failure durumunda workload başka node'a schedule edilebilir. Bu automation root cause'u çözmez. Restart loop yine gözlemlenmelidir. Availability için doğru readiness ve resource request gerekir.

Operasyonel Karmaşıklık

Cluster networking, ingress, storage ve upgrade yeni sorumluluk getirir. Küçük ekip için bakım yükü uygulama geliştirmeyi gölgeleyebilir. Managed Kubernetes bazı işleri azaltır. Yine de observability ve security bilgisi gerekir. İhtiyaç oluşmadan geçiş yapmak gereksiz olabilir.

systemd + Nginx'in Hâlâ Yeterli Olduğu Durumlar

Az sayıda servis ve düşük trafik için systemd ile Nginx güçlü çözümdür. Deployment artifact ve blue-green modeli uygulanabilir. Backup ve monitoring doğru kurulduğunda operasyon oldukça güvenilir olabilir. İki server ile HA da kurulabilir. Platform seçimi sistemin gerçek gereksinimini yansıtmalıdır.

High Availability İçin Birden Fazla Ubuntu Sunucu

Kubernetes kullanmadan da birden fazla Ubuntu sunucuyla yüksek erişilebilirlik kurulabilir. Load balancer iki veya daha fazla application server arasında trafik dağıtır. Database external veya shared HA çözümünde tutulabilir. Session state local disk yerine merkezi store'a taşınmalıdır. Rolling deployment ile node'lar sırayla güncellenerek kullanıcı kesintisi azaltılabilir.

Load Balancer

Load balancer public traffic'i healthy server'lara yönlendirir. Health check failed node'u havuzdan çıkarır. Managed veya self-hosted olabilir. TLS termination burada veya node Nginx'inde yapılabilir. Load balancer kendisi de HA olmalıdır.

İki veya Daha Fazla Application Server

Her node aynı immutable release'i çalıştırır. Config environment standardıyla yönetilir. Bir node maintenance sırasında traffic dışına alınabilir. Capacity tek node failure durumunu taşıyabilmelidir. Deployment sıra ile yapılır.

Shared/External Database

Application node'ların local database kullanması data consistency problemi yaratır. Ortak external database tercih edilir. Database'in kendi HA stratejisi bulunmalıdır. Connection limit total node sayısına göre ayarlanır. Backup ayrı uygulanır.

Session State

Session local memory'de tutulursa load balancer sticky session gerektirebilir. Redis veya signed token gibi external/stateless model daha esnektir. Node failure kullanıcı login state'ini kaybetmez. Security ve expiration doğru tasarlanmalıdır. Rolling deployment kolaylaşır.

Rolling Deployment

Bir node load balancer'dan çıkarılır. Yeni release deploy edilir ve health test çalışır. Node tekrar traffic'e alınır. Ardından sıradaki node güncellenir. Failure halinde rollout durdurulur.

Server Failure

Bir node tamamen kaybolduğunda diğerleri traffic taşır. Capacity headroom gereklidir. Monitoring unhealthy node'u hızlı tespit etmelidir. Provisioning automation replacement server kurabilir. Database veya load balancer single point olmamalıdır.

Ubuntu Servis Yönetiminde Güvenlik Checklist'i

Ubuntu production güvenliği tek bir ayardan oluşmaz. Non-root service user, SSH key, UFW ve minimum public port temel koruma sağlar. systemd sandbox application process'in yetkilerini daraltabilir. Secret protection, security updates, backup ve audit log tamamlayıcı katmanlardır. Checklist deployment öncesi otomatik veya yarı otomatik doğrulanmalıdır.

Non-Root Service User

Application root çalışmamalıdır. Ayrı service user kullanılmalıdır. Login shell kapatılabilir. File write izinleri gerekli path'lerle sınırlanır. systemd User ayarı bunu enforce eder.

SSH Key

Parola yerine key authentication tercih edilmelidir. Private key güvenli tutulur. Kullanıcı bazlı key kullanılır. Kullanılmayan erişimler kaldırılır. Kritik sistemde MFA veya short-lived credential değerlendirilir.

UFW

Default incoming deny uygulanır. Yalnızca gerekli portlar açılır. SSH source IP sınırlandırılabilir. Database public açılmaz. Rule drift düzenli kontrol edilir.

Minimum Public Port

Web servis için çoğu zaman yalnızca 80 ve 443 yeterlidir. Application portları localhost'ta kalır. Admin interface VPN arkasına alınabilir. Açık port inventory tutulur. Beklenmeyen listener alarm konusu olabilir.

systemd Sandbox

NoNewPrivileges ve filesystem protection seçenekleri kullanılabilir. Application ihtiyacına göre kademeli uygulanır. Breakage staging'de test edilir. Writable path açıkça tanımlanır. Service privilege yüzeyi küçülür.

Secret Protection

Secret Git'e konmaz. File permission dar tutulur. Log ve backup leakage kontrol edilir. Rotation planlanır. Merkezi manager gerektiğinde devreye alınır.

Security Updates

Paketler süresiz eski bırakılmamalıdır. Critical update hızlı uygulanır. Restart ve reboot etkisi planlanır. Canary update kullanılabilir. Vulnerability inventory güncel tutulur.

Backup

Database ve mutable data düzenli korunur. Off-site kopya bulunur. Backup encrypted tutulabilir. Restore düzenli test edilir. RPO ve RTO açıkça belirlenir.

Audit Log

SSH login, sudo ve deployment action kaydedilir. Release ID ve kullanıcı bilgisi ilişkilendirilir. Loglara secret yazılmaz. Retention security ihtiyacına göre belirlenir. Incident timeline hızlı oluşturulabilir.

Production Deployment Checklist

Production deployment öncesi checklist insan hafızasına bağımlılığı azaltır. Application testleri, dependency pinning ve production config doğrulanmalıdır. systemd, Nginx ve security ayarları kontrol edilmelidir. Health, logs, monitoring, backup ve rollback hazır olmadan release tamamlanmış kabul edilmemelidir. Checklist mümkün olduğunca CI/CD içinde otomatik hale getirilmelidir.

Application

Application release deployment'a hazır olmalıdır. Test sonuçları geçerli olmalıdır. Dependency version'ları sabitlenmelidir. Production config schema doğrulanmalıdır. Release artifact immutable olmalıdır.

Tests geçti mi?

Unit ve integration test sonuçları başarılı olmalıdır. Kritik API contract'ları kontrol edilmelidir. Migration testleri varsa çalıştırılmalıdır. Failed test manual bypass edilmemelidir. Exception gerekiyorsa risk kaydı tutulmalıdır.

Dependencies pinlendi mi?

Package version'ları lockfile veya explicit version ile sabitlenmelidir. Latest kullanılmamalıdır. Runtime version da aynı yaklaşımı izlemelidir. Security scan dependency durumunu göstermelidir. Upgrade ayrı change olmalıdır.

Production config hazır mı?

Required environment variable'lar mevcut olmalıdır. Secret değerleri güvenli kaynaktan gelmelidir. Debug mode kapalı olmalıdır. External endpoint URL'leri production değerlerini göstermelidir. Config validation deploy öncesi çalışmalıdır.

systemd

Unit file production standardına uygun olmalıdır. Dedicated user kullanılmalıdır. Restart policy ve start limit tanımlanmalıdır. Hardening uygulama ihtiyacına göre eklenmelidir. Enable state reboot öncesi kontrol edilmelidir.

Dedicated user

Servis root yerine application user ile çalışmalıdır. User yalnızca gerekli file path'lere erişmelidir. Login shell gerekmez. Group permission kontrollü verilmelidir. Ownership deployment script tarafından korunmalıdır.

Restart policy

Unexpected crash sonrası kontrollü restart gerekir. on-failure çoğu web servisinde uygundur. RestartSec ve limit eklenmelidir. Manual stop behavior bilinmelidir. Restart count monitoring'e bağlanmalıdır.

Hardening

NoNewPrivileges ve filesystem protection seçenekleri değerlendirilebilir. Uygulamanın gerçekten yazması gereken path listelenmelidir. Staging test yapılmalıdır. Çok agresif sandbox production startup'ını kırmamalıdır. Security baseline versioned tutulabilir.

Nginx

Nginx public trafik katmanıdır. Configuration syntax doğrulanmalıdır. TLS certificate doğru domain'i kapsamalıdır. Proxy header'lar trusted boundary ile set edilmelidir. Upstream yalnızca local veya private application adresine gitmelidir.

Config test

nginx -t reload öncesi mutlaka çalışmalıdır. Syntax failure active config'i değiştirmemelidir. Deployment script testi otomatik yapabilir. Warning'ler de incelenmelidir. Reload sonrası public request test edilir.

TLS

Certificate geçerli ve yenileme mekanizması aktif olmalıdır. Private key permission korunmalıdır. HTTP redirect çalışmalıdır. Expiry monitoring bulunmalıdır. Renewal dry-run test edilmelidir.

Proxy headers

Host ve forwarded protocol doğru aktarılmalıdır. Client IP spoofing engellenmelidir. Application trusted proxy ayarı yapılmalıdır. Secure cookie behavior HTTPS ile uyumlu olmalıdır. Header configuration test case içerebilir.

Security

Firewall yalnızca gerekli portları açmalıdır. Secret'lar repository dışında tutulmalıdır. Sistem paketleri kabul edilebilir patch seviyesinde olmalıdır. SSH erişimi minimum yetkiyle sınırlandırılmalıdır. Audit ve backup politikaları kontrol edilmelidir.

Firewall

UFW status kontrol edilir. SSH erişimi kaybedilmemelidir. Backend ve database portları public olmamalıdır. Cloud firewall ile rule uyumu gözden geçirilir. Yeni port açma gerekçesi dokümante edilir.

Secrets

Production secret loglarda görünmemelidir. Permission dar tutulmalıdır. Expired credential kontrol edilir. Rotation planı bulunmalıdır. CI pipeline secret value'yu çıktılamamalıdır.

Updates

Security patch backlog kontrol edilmelidir. Critical package eski kalmamalıdır. Reboot requirement bilinmelidir. Update deployment ile aynı anda gereksiz risk yaratmamalıdır. Maintenance planı varsa uygulanır.

Operations

Deployment'ın operasyonel güvenilirliği health ve monitoring ile doğrulanır. Loglar erişilebilir olmalıdır. Backup güncel olmalıdır. Rollback target önceden bilinmelidir. On-call ekip yeni release hakkında bilgi sahibi olmalıdır.

Health check

Local ve public endpoint başarılı olmalıdır. Readiness dependency durumunu doğru göstermelidir. Version bilgisi doğrulanabilir. Health response hassas detail vermemelidir. CI deployment sonrası otomatik test edebilir.

Logs

Application ve Nginx logları toplanıyor olmalıdır. Deployment sonrası yeni error oluşmadığı kontrol edilir. Retention disk kapasitesine uygundur. Secret redaction çalışmalıdır. Merkezi platform varsa label doğru olmalıdır.

Monitoring

Error, latency ve resource metric görünür olmalıdır. Deployment marker chart'a eklenebilir. Alert route doğru on-call ekibe gitmelidir. Certificate ve disk alarmı aktif olmalıdır. Business KPI mümkünse izlenmelidir.

Backup

Son başarılı backup zamanı kontrol edilir. Restore test durumu bilinmelidir. Migration öncesi ek snapshot gerekiyorsa alınır. Off-site kopya korunur. Recovery credential erişilebilir olmalıdır.

Rollback

Previous known-good release açıkça bilinmelidir. Artifact veya release directory hâlâ mevcut olmalıdır. Database compatibility kontrol edilir. Rollback komutu test edilmiş olmalıdır. Recovery health check adımı tanımlanmalıdır.

Ubuntu Sunucularda En Sık Yapılan Deployment Hataları

Deployment sorunlarının büyük bölümü ileri seviye teknik hatalardan değil temel kontrollerin atlanmasından çıkar. Root kullanıcı, development server ve Git içindeki secret'lar bunların başında gelir. Nginx veya TLS kullanmamak public attack surface'i büyütür. Health check, rollback ve restore testlerinin olmaması küçük hataları uzun outage'a dönüştürür. Ubuntu Sunucularda Servis Dağıtımı ve Yönetim İpuçları uygulanırken basit güvenlik ve operasyon kuralları çoğu zaman en büyük farkı yaratır.

Uygulamayı Root Olarak Çalıştırmak

Application açığı doğrudan sistem yetkisine dönüşebilir. Dedicated service user daha güvenlidir. Privileged port ihtiyacı Nginx ile çözülür. File ownership doğru tasarlanmalıdır. systemd User ayarı kullanılmalıdır.

Development Server'ı Production'da Kullanmak

Framework development server performans ve güvenlik için tasarlanmamıştır. Debug mode hassas bilgi açabilir. Production worker modeli kullanılmalıdır. Nginx reverse proxy eklenmelidir. Load ve graceful shutdown test edilmelidir.

Secret'ları Git'e Commit Etmek

Secret Git history içinde kalabilir. Repository private olsa bile risk vardır. Commit edilen credential rotate edilmelidir. Secret scanning kullanılabilir. Config güvenli kaynaktan verilmelidir.

Portu Doğrudan Internet'e Açmak

Application server public exposure için gerekli security katmanlarını taşımayabilir. Backend localhost'ta tutulmalıdır. Nginx public giriş olarak kullanılır. Firewall application portunu kapalı tutar. TLS ve rate limit proxy'de uygulanabilir.

Nginx Kullanmamak

Her uygulama için Nginx zorunlu değildir, ancak klasik Ubuntu web servislerinde güçlü fayda sağlar. TLS, static files ve proxy management merkezileşir. Application public protocol detayından ayrılır. Birden fazla servis kolay route edilir. Alternatif reverse proxy kullanılacaksa aynı sorumluluklar karşılanmalıdır.

TLS Kullanmamak

HTTP trafik ağ üzerinde açık gider. Credential ve session bilgisi riske girer. Modern browser özellikleri HTTPS bekler. Let's Encrypt maliyet engelini büyük ölçüde kaldırır. Renewal otomasyonu da kurulmalıdır.

nginx -t Yapmadan Reload Etmek

Syntax hatalı config reload failure yaratabilir. Bazı durumlarda service restart sonrası tamamen açılmayabilir. Config test saniyeler sürer. Deployment script'e otomatik eklenmelidir. Başarısız test current config'i korumalıdır.

Restart ile Aktif Connection'ları Kesmek

Uzun request ve WebSocket bağlantısı restart sırasında kopabilir. Graceful reload veya dual instance kullanılabilir. Traffic drain uygulanabilir. Client retry tek başına çözüm değildir. Deployment yöntemi connection modeline uygun olmalıdır.

Health Check Olmadan Deployment Yapmak

Process başlamış görünse bile application işlevsiz olabilir. Database bağlantısı yanlış olabilir. Nginx route hatalı olabilir. Health ve synthetic test deployment doğrulaması sağlar. Başarısız release traffic almamalıdır.

Rollback Planı Olmamak

Incident sırasında eski version'ın nerede olduğu bilinmeyebilir. Database yeni schema'ya geçmiş olabilir. Hızlı recovery gecikir. Known-good artifact ve runbook önceden hazırlanmalıdır. Rollback drill yapılmalıdır.

Backup Alıp Restore Testi Yapmamak

Backup dosyası bozuk olabilir. Encryption key bulunamayabilir. Restore saatler sürebilir. Gerçek test olmadan RTO bilinmez. Periyodik recovery drill yapılmalıdır.

Log Rotation Yapmamak

Application logları disk doldurabilir. Disk dolunca database ve service failure oluşabilir. journald retention veya logrotate kullanılmalıdır. Log growth alert eklenmelidir. Debug log sürekli açık tutulmamalıdır.

Disk Doluluğunu İzlememek

Disk yüzde yüze ulaştığında birçok servis beklenmedik davranır. Warning erken verilmelidir. Log, release ve Docker image source ayrı ölçülmelidir. Inode kullanımını da izlemek gerekir. Cleanup policy otomatik olabilir.

Paket Güncellemelerini Süresiz Ertelemek

Security vulnerability'ler zaman içinde birikir. "Production'a dokunmayalım" yaklaşımı uzun vadede riski büyütür. Staging ve maintenance window ile patch uygulanabilir. Critical fix daha hızlı ele alınmalıdır. Update sonrası health test gerekir.

Uçtan Uca Ubuntu Servis Deployment Workflow

Sağlıklı deployment belirli ve tekrar edilebilir sırayı takip etmelidir. Önce sunucu temeli hazırlanır, ardından kullanıcı, runtime ve versioned release yapısı kurulur. Application local testten sonra systemd ve Nginx üzerinden yayınlanır. TLS, health, log, monitoring ve backup doğrulandıktan sonra traffic açılır. Son aşamada rollback testi ve CI/CD otomasyonu süreci insan hatasına daha az bağımlı hale getirir.

1. Sunucuyu Güncelleyin

Package index ve security update'leri kontrol edin. Reboot gereksinimini production trafiği gelmeden çözün. Gereksiz paketleri kurmayın. Saat ve hostname ayarlarını doğrulayın. Temiz baseline oluşturun.

2. Deploy ve Service User Oluşturun

Application root çalışmamalıdır. Deploy ve runtime görevlerini gerekirse ayrı hesaplara bölün. Sudo permission minimum tutulmalıdır. Home ve shell ihtiyaca göre ayarlanır. File ownership modeli bu kullanıcılarla uyumlu kurulmalıdır.

3. SSH ve Firewall'ı Güvenceye Alın

SSH key authentication doğrulanır. Root ve password login ihtiyaca göre kapatılır. UFW default deny uygulanır. Yalnızca gereken public port açılır. İkinci SSH session ile lockout testi yapılır.

4. Runtime'ı Kurun

Test edilmiş runtime version kurulur. Python, Node, Java veya .NET version CI ile aynı olmalıdır. Unnecessary compiler package production'da tutulmayabilir. Runtime path explicit kullanılmalıdır. Version kaydedilmelidir.

5. Versioned Release Dizini Oluşturun

/opt/myapp/releases yapısı hazırlanır. current symlink tasarlanır. Shared, config ve data path ayrılır. Permission service user'a göre ayarlanır. Eski release retention belirlenir.

6. Artifact'i Deploy Edin

CI tarafından üretilmiş artifact indirilir. Checksum doğrulanır. Yeni release directory içine yerleştirilir. Çalışan current release değiştirilmez. Artifact metadata kontrol edilir.

7. Config ve Secret'ları Ekleyin

Environment config /etc/myapp altında tutulabilir. Secret repository'den gelmemelidir. File permission dar tutulur. Required variable validation yapılır. Config release ile uyumlu olmalıdır.

8. systemd Unit Oluşturun

Dedicated user ve absolute ExecStart kullanılır. WorkingDirectory current path'i gösterebilir. Restart policy eklenir. EnvironmentFile tanımlanır. Unit enable ve start edilir.

9. systemd Hardening Uygulayın

NoNewPrivileges ve uygun filesystem protection ayarları eklenir. Writable path explicit verilir. Resource limit uygulanabilir. Staging test yapılır. Application gereksinimi olmayan privilege'ler kapatılır.

10. Application'ı Local Olarak Test Edin

Nginx'ten önce localhost backend test edilir. Health endpoint çalışmalıdır. Database connection doğrulanır. Version bilgisi kontrol edilir. Error log temiz olmalıdır.

11. Nginx'i Yapılandırın

server_name ve proxy_pass eklenir. Forwarded header'lar doğru set edilir. Backend public olmayan adrese gider. nginx -t çalıştırılır. Reload sonrası HTTP request test edilir.

12. TLS Kurun

Let's Encrypt veya uygun certificate kaynağı kullanılır. HTTPS server block etkinleştirilir. HTTP redirect uygulanır. Renewal automation doğrulanır. Expiry monitoring eklenir.

13. Health Check Çalıştırın

Local ve public endpoint test edilir. Birden fazla ardışık başarı beklenebilir. Deep dependency test gerekirse ayrı çalıştırılır. Response expected release version'ı göstermelidir. Failure traffic açılmasını engeller.

14. Trafiği Açın

Firewall veya DNS gerektiği şekilde aktif edilir. Blue-green modelde Nginx route yeni backend'e geçer. Error metric izlenir. İlk kullanıcı request'leri loglardan kontrol edilir. Gerekirse hızlı rollback hazır tutulur.

15. Log ve Monitoring'i Doğrulayın

journald application loglarını almalıdır. Nginx access ve error logları çalışmalıdır. CPU, memory, error ve latency metric görünmelidir. Alert test edilir. Deployment marker dashboard'a eklenir.

16. Backup Alın

Config, database ve mutable data backup kapsamına alınır. Off-site kopya doğrulanır. Restore süresi bilinmelidir. Encryption uygulanır. Son başarılı backup monitoring'de görünmelidir.

17. Rollback Testi Yapın

Previous release'e dönüş kontrollü ortamda denenir. Symlink veya route switch süresi ölçülür. Database compatibility test edilir. Health check rollback sonrası çalışır. Runbook eksikleri düzeltilir.

18. Deployment'ı CI/CD ile Otomatikleştirin

Manuel adımlar pipeline'a taşınır. Build, test, artifact, deploy ve health aşamaları ayrı görünür olur. Production credential minimum yetkiyle verilir. Failed deployment automatic veya manual rollback başlatabilir. Audit ve release history merkezi tutulur.

Ubuntu ve DevOps İçin En İyi Programlama Dili Hangisidir?

DevOps için tek bir en iyi programlama dili yoktur. Bash küçük sistem işleri ve deployment scriptleri için çok değerlidir. Python daha büyük automation, API ve tooling geliştirmede güçlüdür. Go tek binary ve cloud-native tooling açısından avantaj sağlar. Bunların öncesinde Linux filesystem, permission, process, network ve systemd temellerini anlamak çok daha önemlidir.

Bash

Bash Linux yönetiminin doğal araçlarından biridir. Kısa automation ve deployment işleri için idealdir. Pipe ve standard tool'larla güçlü sonuç verir. Büyük business logic için bakım zorlaşabilir. Error handling bilinçli yapılmalıdır.

Server automation

Bash package ve service komutlarını birleştirebilir. Basit bootstrap scriptleri hazırlanabilir. Idempotency elle düşünülmelidir. Çok hostlu yapı için Ansible daha uygun olabilir. Script version control altında tutulmalıdır.

Deployment scripts

Artifact indirme ve symlink switch gibi adımlar Bash ile rahat yapılabilir. set -euo pipefail hata yönetimini güçlendirir. Input validation zorunludur. Secret loglanmamalıdır. Script büyürse daha yapılandırılmış tool'a geçilebilir.

Python

Python automation ve API entegrasyonlarında oldukça kullanışlıdır. Standard library ve package ekosistemi geniştir. JSON, HTTP ve cloud SDK işleri Bash'e göre daha okunabilir olur. Error handling daha kontrollüdür. Uzun automation tool'ları için iyi seçimdir.

Automation

Server inventory ve deployment orchestrator Python ile yazılabilir. Retry ve parallel execution daha açık yönetilir. Test yazmak kolaydır. Packaging ve virtual environment gerekir. Küçük task için gereksiz olabilir.

API

Cloud veya monitoring API'leri Python client ile kolay kullanılabilir. Authentication ve pagination kodu daha düzenli olur. Deployment sonrası metric query yapılabilir. Secret manager entegrasyonu eklenebilir. Script reusable library haline getirilebilir.

Configuration tooling

YAML veya JSON config validate eden tool yazılabilir. Schema checking deployment öncesi çalışır. Nginx veya systemd template üretimi yapılabilir. Unit test ile reliability artar. Generated config version control dışında artifact olarak saklanabilir.

Go

Go özellikle infrastructure ve network tooling dünyasında güçlüdür. Tek binary üretmek deployment'ı kolaylaştırır. Concurrency modeli agent ve service geliştirmeye uygundur. Runtime dependency azdır. Yeni başlayan için Linux temellerinin yerini tutmaz.

Cloud-native tooling

Birçok modern infrastructure aracı Go ile geliştirilmiştir. Static binary dağıtımı operasyonu kolaylaştırır. API client ve daemon yazılabilir. Cross-compilation mümkündür. Profiling araçları production analizinde faydalıdır.

Tek binary deployment

Binary artifact registry'de versioned tutulabilir. Sunucuda package install gerekmez. systemd doğrudan çalıştırır. Rollback eski binary'ye dönebilir. Architecture compatibility kontrol edilmelidir.

YAML ve Configuration Dilleri

DevOps çalışırken YAML, JSON, TOML ve benzeri formatlar sık kullanılır. Bunlar programlama dili değildir ancak configuration yönetimi için önemlidir. Indentation veya type hataları production sorununa dönüşebilir. Schema validation ve lint uygulanmalıdır. Configuration değişikliği de code review'dan geçmelidir.

Programlama Dilinden Daha Önemli Olan Linux Temelleri

Bir process neden başlamıyor sorusunu çözmek için önce Linux process, permission ve network mantığını bilmek gerekir. Bash veya Python bunu otomatikleştirir ama temel problemi açıklamaz. Filesystem, TCP/IP, DNS, SSH ve systemd bilgisi kritik altyapıdır. Bu temeller oturduktan sonra automation dili seçmek kolaylaşır. Araç bilgisi temel sistem anlayışını tamamlamalıdır.

Linux/DevOps Alanında Yazılımcı Olmak İçin Ne Yapmalı?

Linux ve DevOps öğrenirken yalnızca araç ezberlemek yerine uçtan uca küçük production sistemi kurmak daha kalıcı öğrenme sağlar. Command line, filesystem, permission ve network temellerinden başlanabilir. Ardından SSH, systemd, Nginx ve Git ile gerçek servis deployment yapılmalıdır. Docker, CI/CD ve cloud daha sonra bu temelin üzerine eklenebilir. Her aşamada log okuyup hata çözmek öğrenmenin en değerli parçasıdır.

Linux Command Line

Shell günlük server yönetiminin temelidir. File, process ve network komutları öğrenilmelidir. Pipe ve redirect davranışı anlaşılmalıdır. Manual komut daha sonra script'e dönüştürülebilir. Help ve man sayfası kullanma alışkanlığı önemlidir.

Filesystem ve Permissions

/etc, /var, /opt gibi dizin rolleri öğrenilmelidir. Owner, group ve mode mantığı anlaşılmalıdır. ACL ve umask daha ileri adımlardır. Permission hataları production'da çok yaygındır. Root ile çözmek yerine doğru ownership kurulmalıdır.

TCP/IP

IP, port, TCP connection ve routing temel kavramlardır. Localhost ile public bind farkı bilinmelidir. Firewall problemi application probleminden ayrılabilir. NAT ve private network cloud ortamında önemlidir. ss ve curl ile pratik yapılmalıdır.

DNS

Domain resolution web deployment'ın temelidir. A, AAAA ve CNAME kayıtları öğrenilebilir. TTL deployment ve failover süresini etkiler. DNS cache troubleshooting sırasında dikkate alınmalıdır. TLS domain doğrulaması DNS'e bağlı olabilir.

SSH

Key authentication ve host key validation öğrenilmelidir. Port forwarding güçlü troubleshooting aracı olabilir. Agent forwarding güvenlik riski taşıyabilir. Sudo ve user management ile birlikte düşünülmelidir. Bastion modeli ileri aşamada öğrenilebilir.

systemd

Service unit oluşturmak gerçek Linux servis yönetimini öğretir. Restart, dependency ve logging pratiği yapılır. Timer ile scheduled job çalıştırılabilir. Resource limit ve hardening daha ileri konulardır. Bir küçük web API'yi systemd altında çalıştırmak iyi projedir.

Nginx

Reverse proxy, TLS ve virtual host öğrenilir. Local backend public endpoint'e dönüştürülür. Header ve timeout behavior test edilir. Access log analizi yapılır. Blue-green deployment için upstream değişikliği uygulanabilir.

Git

Infrastructure ve config değişiklikleri version control altında tutulmalıdır. Branch ve pull request workflow öğrenilir. Tag release management için kullanılabilir. Secret commit edilmemelidir. Revert incident recovery açısından önemlidir.

Bash/Python

Tekrarlanan manual işi automation'a çevirin. Önce kısa Bash script yazın. Logic büyüdüğünde Python değerlendirin. Error handling ve logging ekleyin. Script için test ve dry-run yaklaşımı geliştirin.

Docker

Image, container, network ve volume kavramları öğrenilmelidir. Immutable image deployment pratiği yapılabilir. Docker log ve restart behavior incelenmelidir. Host firewall ilişkisi anlaşılmalıdır. Production için tag yerine version kullanılmalıdır.

CI/CD

Push sonrası build ve test pipeline kurun. Artifact üretin. Staging deploy ve health check ekleyin. Production approval ve rollback adımı ekleyin. Böylece deployment sürecinin tamamı pratikte öğrenilir.

Cloud

Compute, network, storage ve IAM kavramlarını öğrenin. Tek VPS ile başlayabilirsiniz. Sonra load balancer ve managed database ekleyin. Backup ve monitoring servislerini deneyin. Maliyet görünürlüğünü de teknik tasarımın parçası yapın.

Open Source ve İşbirliği ile Ubuntu Sunucu Yönetimi

Ubuntu tabanlı production altyapısının büyük bölümü açık kaynak bileşenlere dayanır. Linux kernel, systemd, Nginx, Ansible ve Git birlikte çok güçlü bir ekosistem oluşturur. Bu araçların yalnızca kullanıcı olmak yerine dokümantasyon, issue ve örnek configuration katkısı yapmak öğrenmeyi hızlandırır. Ekip içinde tekrar kullanılabilir systemd unit ve Ansible role paylaşmak ortak standart oluşturur. Gerçek sorunlardan üretilen küçük katkılar teknik gelişim için oldukça değerlidir.

Ubuntu

Ubuntu server paket yönetimi ve uzun süreli destek seçenekleriyle yaygın platformdur. Release lifecycle takip edilmelidir. Security update ve upgrade planı hazırlanmalıdır. Community dokümantasyonu geniştir. Production standardı seçilen Ubuntu version'a göre oluşturulmalıdır.

Linux Kernel

Process, network ve filesystem davranışının altında kernel bulunur. Her DevOps uzmanının kernel geliştiricisi olması gerekmez. Ancak cgroup, socket ve permission temelini anlamak troubleshooting'i güçlendirir. Kernel update reboot ihtiyacını etkileyebilir. Performance metric'leri kernel kaynaklarından gelir.

systemd

systemd unit örnekleri topluluk tarafından paylaşılabilir. Hardening seçenekleri üzerinde pratik yapılabilir. Issue ve documentation okumak gerçek davranışı anlamayı kolaylaştırır. Timer ve socket activation laboratuvarı kurulabilir. Config kopyalamadan önce neden kullanıldığını anlamak gerekir.

Nginx

Nginx config örnekleri reverse proxy öğrenmek için iyi kaynaktır. Ancak internetten alınan snippet doğrudan production'a konmamalıdır. Header, TLS ve timeout davranışı test edilmelidir. Documentation üzerinden directive anlamı doğrulanmalıdır. Lab ortamında farklı failure senaryoları denenebilir.

Ansible

Ansible role paylaşımı configuration standardizasyonunu kolaylaştırır. Molecule veya test araçlarıyla role doğrulanabilir. Community collection kullanılabilir. Third-party role production'a alınmadan review edilmelidir. Küçük kendi role projesi iyi öğrenme çalışmasıdır.

Git

Configuration ve runbook Git repository'de paylaşılabilir. Pull request review ekip bilgisini artırır. Release tag ve changelog uygulanabilir. Secret scanning kullanılmalıdır. Incident sonrası düzeltme ve lesson aynı repository'ye eklenebilir.

Açık Kaynak Monitoring Araçları

Metric, log ve alert için farklı açık kaynak seçenekleri bulunur. Basit node monitoring ile başlanabilir. Application metric zaman içinde eklenir. Tool sayısı gereksiz artırılmamalıdır. Operasyon ekibinin gerçekten kullanacağı dashboard tasarlanmalıdır.

GitHub Üzerinden Konfigürasyon Paylaşımı

Örnek systemd unit, Nginx config ve Ansible role public repository'de paylaşılabilir. Secret ve gerçek domain bilgileri çıkarılmalıdır. README kurulum ve rollback adımlarını açıklamalıdır. Issue üzerinden topluluk geri bildirim verebilir. Version tag kullanmak örnekleri izlenebilir hale getirir.

Infrastructure Dokümantasyonuna Katkı

Dokümantasyon katkısı teknik bilgiyi netleştirmenin güçlü yoludur. Eksik bir troubleshooting örneği eklenebilir. Translation veya correction çalışması yapılabilir. Contribution guideline takip edilmelidir. Küçük katkılar zaman içinde önemli deneyime dönüşür.

Diyarbakır Yazılım Topluluğu İçin Ubuntu ve DevOps Proje Fikirleri

Ubuntu ve DevOps öğrenmenin en iyi yollarından biri gerçek deployment problemlerini küçük topluluk projelerine dönüştürmektir. Bir Ubuntu server kurulumundan başlayıp systemd, Nginx ve CI/CD aşamalarını adım adım uygulamak güçlü bir eğitim serisi olabilir. Daha ileri aşamada zero-downtime deployment, monitoring ve Ansible role çalışmaları eklenebilir. Ortak self-hosted servis projesi ekip üyelerine gerçek on-call ve bakım deneyimi de kazandırabilir. Topluluk projelerini https://www.diyarbakiryazilim.com.tr/projects adresinden takip edebilirsiniz.

Ubuntu Server Kurulum Atölyesi

Katılımcılar temiz bir Ubuntu VM oluşturabilir. User, SSH ve UFW adımlarını uygular. systemd ile basit servis çalıştırılır. Nginx ve TLS eklenir. Atölye sonunda herkes çalışan production-benzeri servis kurmuş olur.

systemd Service Workshop

Basit Python veya Go API hazırlanabilir. Unit file sıfırdan yazılır. Restart ve hardening seçenekleri denenir. Crash senaryosu bilinçli oluşturulur. journalctl ile troubleshooting yapılır.

Nginx Reverse Proxy Lab

İki backend farklı portta çalıştırılır. Nginx upstream oluşturulur. TLS ve proxy header ayarları eklenir. 502 ve timeout senaryoları bilinçli üretilir. Katılımcılar loglardan root cause bulur.

Zero-Downtime Deployment Projesi

Blue ve green application instance kurulur. Health check ve Nginx switch script yazılır. Yeni release traffic'e alınır. Hatalı release ile rollback denenir. Deployment süresi ve error metric ölçülür.

CI/CD ile VPS Deployment

Repository push sonrası test pipeline çalışır. Artifact hazırlanır. Dedicated deploy user ile VPS'e aktarılır. Health check başarısızsa rollback yapılır. Secret ve SSH key yönetimi ayrıca öğretilir.

Open Source Ansible Role Projesi

Topluluk reusable Ubuntu web service role hazırlayabilir. User, package, systemd ve Nginx configuration otomatik kurulur. Variables ile farklı application'lara uyarlanır. README ve test senaryoları eklenir. GitHub üzerinden katkı süreci uygulanır.

Monitoring ve Alerting Atölyesi

CPU, memory ve disk metric toplanır. Application health ve error rate eklenir. Nginx loglarından 502 alarmı hazırlanır. Certificate expiry monitor edilir. Bilerek servis durdurulup alert zinciri test edilir.

Ortak Self-Hosted Servis Projesi

Topluluk küçük bir ortak servis çalıştırabilir. Deployment, backup ve monitoring sorumlulukları paylaşılır. Gerçek maintenance ve incident deneyimi oluşur. Runbook hazırlanır. Cloud depolama ve otomasyon senaryoları için https://www.diyarbakiryazilim.com.tr/posts/cloudflare-r2-ile-otomatik-veri-yukleme-ve-depolama-yonetimi içeriğinden de yararlanılabilir.

Sık Sorulan Sorular

Ubuntu'da bir uygulama nasıl servis olarak çalıştırılır?

Uygulama için önce dedicated non-root user oluşturulur. Runtime veya immutable artifact uygun dizine yerleştirilir. Ardından /etc/systemd/system altında service unit hazırlanır. systemctl daemon-reload, enable ve start işlemleri uygulanır. Son olarak status, journal ve application health endpoint ile servis doğrulanır.

systemd service nasıl oluşturulur?

Unit dosyasında [Unit], [Service] ve çoğu zaman [Install] bölümleri bulunur. User, WorkingDirectory ve ExecStart açıkça yazılır. Restart policy eklenebilir. Dosya kaydedildikten sonra daemon-reload çalıştırılır. Servis enable ve start edilerek boot ve runtime davranışı test edilir.

systemctl restart ile reload arasındaki fark nedir?

Restart process'i tamamen kapatıp tekrar açar. Reload servis destekliyorsa process'i durdurmadan config'i yeniden yükler. Nginx config değişikliklerinde reload genellikle daha uygun olur. Binary değişikliği çoğu application'da restart gerektirir. Aktif connection etkisi deployment tasarımına göre değerlendirilmelidir.

Servis crash olduğunda otomatik nasıl yeniden başlatılır?

systemd service içinde Restart=on-failure kullanılabilir. RestartSec yeni deneme öncesi gecikme verir. Start limit crash loop'u sınırlar. Sürekli failure alarm üretmelidir. Restart uygulamak root cause araştırmasının yerine geçmez.

Nginx reverse proxy neden kullanılır?

Nginx public traffic ile backend uygulama arasında güvenli katman oluşturur. TLS termination, static files ve connection management sağlar. Backend localhost üzerinde kalabilir. Birden fazla service domain bazında yönlendirilebilir. Load balancing ve rate limiting gibi imkanlar da eklenebilir.

Ubuntu sunucuda HTTPS nasıl kurulur?

Domain DNS kaydı sunucuya yönlendirilir. Let's Encrypt ve Certbot ile certificate alınabilir. Nginx TLS server block yapılandırılır. HTTP request HTTPS'e yönlendirilir. Renewal automation ve expiry monitoring mutlaka doğrulanmalıdır.

Let's Encrypt sertifikası otomatik yenilenir mi?

Certbot kurulumu çoğu Ubuntu ortamında timer veya benzeri mekanizmayla otomatik renewal sağlayabilir. Bunun çalışıyor olduğunu varsaymak yerine kontrol etmek gerekir. certbot renew --dry-run testi yapılabilir. Renewal sonrası Nginx reload hook'u gerekebilir. Certificate expiry dış monitoring ile ayrıca izlenmelidir.

Ubuntu sunucu nasıl güvenli hale getirilir?

Non-root admin ve service user kullanılmalıdır. SSH key authentication ve minimum firewall portları uygulanmalıdır. Application backend public internete açılmamalıdır. Secret ve security update süreçleri yönetilmelidir. Backup, monitoring ve audit log güvenlik planının parçası olmalıdır.

Uygulama root olarak çalıştırılmalı mı?

Çoğu web application root yetkisine ihtiyaç duymaz. Dedicated service user kullanmak compromise etkisini sınırlar. Nginx privileged public portları yönetebilir. systemd sandbox ek koruma sağlayabilir. Root çalışma yalnızca açık teknik gerekçe varsa değerlendirilmelidir.

.env dosyası production için güvenli midir?

Küçük sistemde repository dışında ve sıkı file permission ile kullanılabilir. Ancak merkezi audit ve rotation sağlamaz. Backup ve process environment leakage riskleri bulunur. Sunucu sayısı arttığında secret manager daha uygun olabilir. Dosyada bulunan credential Git'e commit edilmemelidir.

Zero-downtime deployment nasıl yapılır?

Yeni release ayrı application instance olarak başlatılır. Health check başarılı olmadan public traffic verilmez. Nginx route yeni instance'a graceful reload ile çevrilebilir. Eski instance mevcut connection'ları tamamlayana kadar çalışır. Stabilization döneminde hızlı rollback için korunabilir.

Blue-green deployment Ubuntu'da nasıl uygulanır?

Blue ve green instance farklı localhost port veya socket üzerinde çalıştırılır. Nginx aktif environment'ı upstream üzerinden seçer. Yeni green sürüm local health check'ten geçirilir. Traffic Nginx reload ile green'e yönlendirilir. Problem çıkarsa route tekrar blue'ya döndürülür.

502 Bad Gateway hatası nasıl çözülür?

Önce backend application service'in çalışıp çalışmadığı kontrol edilir. Ardından Nginx'in kullandığı socket veya port doğrulanır. Unix socket permission incelenir. Nginx error log ve systemd journal birlikte okunur. Timeout büyütmeden önce gerçek backend failure sebebi bulunmalıdır.

systemd logları nasıl görüntülenir?

journalctl -u servisadi belirli servis loglarını gösterir. -f ile canlı takip yapılabilir. Boot ve zaman aralığı filtreleri kullanılabilir. Priority filter hata seviyelerini daraltır. Production'da journal retention ve disk kullanımı ayrıca yönetilmelidir.

unattended-upgrades production sunucuda kullanılmalı mı?

Security patch gecikmesini azaltmak için faydalı olabilir. Ancak service restart ve reboot etkisi anlaşılmalıdır. Kritik sistemlerde canary veya maintenance window ile birlikte uygulanabilir. Excluded package'ler düzenli review edilmelidir. Update sonrası health verification yapılmalıdır.

Ubuntu sunucuda backup nasıl alınır?

Database, user upload ve gerekli config ayrı değerlendirilmelidir. Backup farklı storage veya off-site konumda tutulmalıdır. Encryption ve retention uygulanmalıdır. Yalnızca backup almak yeterli değildir. Periyodik restore testi yapılarak RPO ve RTO doğrulanmalıdır.

systemd mi Docker mı kullanılmalı?

Az sayıda service ve küçük VPS için native systemd son derece yeterli olabilir. Docker dependency isolation ve immutable image avantajı sunar. Ekip container workflow biliyorsa operasyon kolaylaşabilir. Buna karşılık image, volume ve network lifecycle ek sorumluluk getirir. Uygulama ihtiyacı ve ekip yetkinliği seçimde belirleyici olmalıdır.

Ubuntu sunucuda CI/CD deployment nasıl yapılır?

CI önce application'ı build ve test eder. Immutable artifact oluşturup registry veya artifact store'a yükler. Deploy job dedicated account ile Ubuntu server'a ulaşır. Yeni release health check'ten geçirildikten sonra traffic'e alınır. Failure durumunda known-good release'e rollback mekanizması bulunmalıdır.

DevOps için Bash mi Python mı öğrenilmelidir?

İkisini rakip olarak görmek yerine farklı seviyelerde araç olarak düşünmek daha doğrudur. Bash kısa Linux automation işleri için çok değerlidir. Python daha büyük workflow, API ve veri işleme görevlerinde okunabilirlik sağlar. Önce Linux command line ve process mantığı öğrenilmelidir. Sonra Bash ve Python ihtiyaç oldukça birlikte kullanılabilir.

Ubuntu sunucularda uygulama ve servis dağıtımı nasıl yapılır?

Ubuntu sunucuda uygulama ve servis deployment nasıl yapılır sorusuna üretim ortamı açısından baktığımızda süreç sunucu hazırlığıyla başlar. Non-root kullanıcı, SSH, firewall ve runtime kurulduktan sonra application versioned release dizinine yerleştirilir. systemd service lifecycle'ı, Nginx ise public traffic ve TLS katmanını yönetir. Health check, log ve monitoring doğrulamasından sonra trafik açılır. En sonunda backup ve rollback test edilerek deployment gerçekten tamamlanmış olur.

Ubuntu’da systemd ve systemctl kullanarak servisler nasıl oluşturulur, başlatılır ve otomatik yeniden başlatılır?

/etc/systemd/system altında service unit oluşturularak User, WorkingDirectory ve ExecStart değerleri tanımlanır. systemctl daemon-reload sonrasında service enable ve start edilir. Restart=on-failure crash durumunda otomatik yeniden başlatma sağlayabilir. RestartSec ve start limit değerleri crash loop'u kontrol altında tutar. Service status ve loglar systemctl ile journalctl üzerinden izlenmelidir.

Nginx reverse proxy, SSL ve güvenlik duvarı ayarları servis dağıtımında nasıl yapılandırılmalıdır?

Nginx 80 ve 443 portlarında public trafik kabul ederken application yalnızca localhost üzerinde çalışmalıdır. TLS certificate Let's Encrypt veya başka güvenilir certificate kaynağıyla kurulabilir. UFW üzerinde default incoming deny uygulanıp yalnızca gerekli portlar açılmalıdır. Database ve backend application portları public internete açılmamalıdır. Proxy header ve trusted proxy ayarları istemci IP ile HTTPS bilgisinin güvenli aktarılmasını sağlamalıdır.

Ubuntu sunucularda servis logları journalctl ile nasıl izlenir ve dağıtım sonrası hatalar nasıl yönetilir?

journalctl -u servisadi belirli systemd servisinin loglarını gösterir. Deployment timestamp sonrası kayıtlar filtrelenerek startup exception, config veya dependency hataları bulunabilir. Nginx error log ile application journal aynı zaman aralığında karşılaştırılmalıdır. Error rate ve latency monitoring üzerinden izlenmelidir. Problemli release kullanıcı etkisi oluşturuyorsa önceden hazırlanmış rollback süreci uygulanmalıdır.

Ubuntu sunucularda servis dağıtımı ve yönetimi konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Ubuntu sunucu ve Linux sistem yönetimi danışmanlığı yakınımda şeklinde araştırma yaparken yalnızca ilk kurulum hizmetine değil, deployment, monitoring, backup ve recovery süreçlerini birlikte ele alan yaklaşıma odaklanmak faydalıdır. Kurumsal Ubuntu sunucu kurulum deployment ve sistem yönetimi hizmeti kapsamında systemd, Nginx, TLS, firewall ve CI/CD birlikte değerlendirilmelidir. Diyarbakır Yazılım Topluluğu'nun yürüttüğü çalışmaları https://www.diyarbakiryazilim.com.tr/projects adresinden inceleyebilirsiniz. Topluluk hakkında bilgi almak için https://www.diyarbakiryazilim.com.tr/about adresini kullanabilirsiniz. Bu tür çalışmalar gerçek deployment senaryolarını birlikte deneyimlemek için güçlü bir öğrenme alanı sunar.

Sonuç

Ubuntu Sunucularda Servis Dağıtımı ve Yönetim İpuçları doğru uygulandığında production yönetimi rastgele SSH komutlarından çıkar ve tekrar edilebilir bir operasyon modeline dönüşür. systemd application process'ini, Nginx public trafiği, TLS güvenli bağlantıyı, UFW ise network sınırını yönetebilir. Versioned release, health check, monitoring, backup ve rollback süreci eklenince küçük bir Ubuntu sunucu bile oldukça güvenilir biçimde işletilebilir. Benim en güçlü önerim, deployment'ı yalnızca "yeni kodu çalıştırma" işi olarak değil, failure sonrasında sistemi nasıl geri getireceğinizi de tanımlayan bir süreç olarak ele almanızdır. Ubuntu Sunucularda Servis Dağıtımı ve Yönetim İpuçları, DevOps ve production operasyonları üzerine daha fazla proje ve topluluk çalışması için https://www.diyarbakiryazilim.com.tr adresini ziyaret edebilirsiniz.