linux – KertenKerem.NET

Mayıs 22 2026

HAProxy ile Yüksek Erişilebilirlik: Keepalived ve Health Check

Modern mikroservis mimarilerinde veya yüksek trafikli web uygulamalarında kesintisiz hizmet sunmak artık bir lüks değil, zorunluluk. Tam da bu noktada, haproxy ve keepalived ikilisi, linux sunucularınız üzerinde kurabileceğiniz, kurumsal sınıfta, maliyetsiz ve son derece güvenilir bir aktif-pasif ha (high availability) loadbalancer çözümü olarak imdadımıza yetişiyor. Peki ama bu iki canavarı prod ortamında birbirine küstürmeden, arkadaki servislerin sağlık durumlarına (health check) ve gelen isteğin içeriğine (ACL) göre nasıl kusursuzca dans ettireceğiz? Bu yazıda lafı hiç dolandırmadan, doğrudan production ortamında hırpalanmış senaryolardan süzülen pratik bir mimariyi ayağa kaldıracağız.

Neden Sadece HAProxy Yetmiyor? (SPOF Nedir?)

HAProxy, performansına ve stabilitesine şapka çıkardığımız harika bir load balancer. Ancak ne kadar güçlü olursa olsun, tek bir sunucu üzerinde çalıştığı sürece sisteminizde bir SPOF (Single Point of Failure) yani tek hata noktası oluşturur. HAProxy’nin üzerinde çalıştığı Linux sunucunun donanımı çökerse, network kartı yanarsa ya da kernel panik yaparsa tüm sisteminiz karanlığa gömülür.

İşte bu riski bertaraf etmek için Keepalived devreye giriyor. Keepalived, VRRP (Virtual Router Redundancy Protocol) protokolünü kullanarak iki farklı load balancer sunucusunun tek bir Sanal IP (Virtual IP – VIP) arkasında çalışmasını sağlar. Aktif olan sunucu çöktüğünde, pasif durumdaki yedek sunucu VIP’yi milisaniyeler içinde üzerine alır. Kullanıcılar bu failover sürecini ruhları bile duymadan atlatırlar.

Altyapı Hazırlığı ve Olmazsa Olmaz Kernel Parametresi

Kuruluma başlamadan önce topolojimizi netleştirelim. Elimizde iki adet Linux (Ubuntu/Debian tabanlı kabul ediyoruz) sunucu olduğunu varsayalım:

LB01 (Master): 192.168.1.10
LB02 (Backup): 192.168.1.11
Sanal IP (VIP): 192.168.1.100

Şimdi kıdemli bir sistemcinin asla atlamayacağı o kritik kernel ayarına gelelim: net.ipv4.ip_nonlocal_bind. Varsayılan olarak Linux, sunucu üzerinde fiziksel olarak tanımlanmamış bir IP adresine servislerin bind olmasını (yani o IP’yi dinlemesini) engeller. VIP, pasif sunucuda o an aktif olmadığı için backup sunucudaki HAProxy servisi başlatılamaz ve çöker. Bunun önüne geçmek için her iki sunucuda da şu komutu koşturuyoruz:

echo "net.ipv4.ip_nonlocal_bind=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Bu sihirli dokunuş sayesinde HAProxy, sunucuda henüz tanımlanmamış olan 192.168.1.100 IP’sini hiç çekinmeden dinlemeye başlayacaktır.

Keepalived ile Aktif-Pasif VIP Kurulumu

Her iki sunucuya da keepalived paketini kuralım:

sudo apt update && sudo apt install keepalived -y

Şimdi konfigürasyon zamanı. En kritik nokta, master sunucu çöktüğünde VIP’nin pasif sunucuya geçmesi, ancak master geri geldiğinde (eğer istemiyorsak) gereksiz yere VIP’yi geri alıp ufak da olsa bir kesinti yaratmamasıdır. Buna “non-preemptive” yapılandırma denir. Ancak biz bu örnekte klasik aktif-pasif öncelik yapısını kuracağız.

Master (LB01) Konfigürasyonu

/etc/keepalived/keepalived.conf dosyasını oluşturun ve aşağıdaki gibi düzenleyin:

vrrp_script check_haproxy {
    script "killall -0 haproxy" # HAProxy çalışıyor mu kontrol et
    interval 2                  # Her 2 saniyede bir çalıştır
    weight 2                    # Başarılıysa önceliğe (priority) 2 ekle
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0              # Network arayüzünüzün adı (ip a ile kontrol edin)
    virtual_router_id 51        # İki sunucuda da AYNI olmalı
    priority 101                # Master daha yüksek önceliğe sahip
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass GizliSifre123  # İki sunucuda da aynı olmalı
    }

    virtual_ipaddress {
        192.168.1.100/24         # Paylaşılan Sanal IP (VIP)
    }

    track_script {
        check_haproxy
    }
}

Backup (LB02) Konfigürasyonu

Backup sunucumuzda ise dosya neredeyse aynıdır, sadece state ve priority değerleri değişir:

vrrp_script check_haproxy {
    script "killall -0 haproxy"
    interval 2
    weight 2
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100                # Master'dan daha düşük
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass GizliSifre123
    }

    virtual_ipaddress {
        192.168.1.100/24
    }

    track_script {
        check_haproxy
    }
}

Konfigürasyonları kaydettikten sonra her iki sunucuda da servisi başlatalım:

sudo systemctl enable --now keepalived

Eğer her şey yolunda gittiyse, LB01 üzerinde ip a show eth0 komutunu verdiğinizde secondary IP olarak 192.168.1.100 adresini görmelisiniz. LB02’de ise bu IP görünmemelidir.

HAProxy Kurulumu ve Sağlık Kontrolü (Health Check) Sanatı

Sıra geldi yük dengeleme katmanımıza. HAProxy’yi kuralım:

sudo apt install haproxy -y

Bir load balancer’ı akıllı kılan şey, arkasındaki uygulama sunucularının (backend) gerçekten yaşayıp yaşamadığını bilmesidir. Sadece TCP portunun açık olması (Layer 4) uygulamanın sağlıklı çalıştığı anlamına gelmez. Uygulama veritabanına bağlanamadığı için HTTP 500 hatası veriyor olabilir ama TCP portu hala ayaktadır. Bu yüzden her zaman HTTP tabanlı (Layer 7) health check tercih etmelisiniz.

Gelin, hem gelişmiş health check mekanizmasını hem de VIP binding konseptini barındıran örnek bir /etc/haproxy/haproxy.cfg dosyası hazırlayalım:

global
    log /dev/log local0
    log /dev/log local1 notice
    chroot /var/lib/haproxy
    user haproxy
    group haproxy
    daemon

defaults
    log     global
    mode    http
    option  httplog
    option  dontlognull
    timeout connect 5000ms
    timeout client  50000ms
    timeout server  50000ms

frontend http_front
    bind 192.168.1.100:80 # Sadece VIP üzerinden gelen istekleri dinle
    mode http
    default_backend app_backend

backend app_backend
    mode http
    balance roundrobin
    
    # Layer 7 Health Check Yapılandırması
    option httpchk GET /healthz HTTP/1.1\r\nHost:\ myapp.local
    http-check expect status 200
    
    # Backend Sunucuları
    server app01 192.168.1.20:8080 check inter 3000 rise 2 fall 3
    server app02 192.168.1.21:8080 check inter 3000 rise 2 fall 3

Burada Neler Döndü? (Detaylı “Neden” Analizi)

bind 192.168.1.100:80: HAProxy’ye sadece VIP adresini dinlemesini söyledik. Bu, trafiğin kontrolsüz şekilde doğrudan nodeların kendi IP’leri üzerinden akmasını engeller.
option httpchk GET /healthz: HAProxy, backend sunucularına her 3 saniyede bir (inter 3000) HTTP GET isteği gönderir.
http-check expect status 200: Gelen yanıtın HTTP 200 OK olması durumunda sunucu “sağlıklı” kabul edilir.
rise 2 fall 3: Bir sunucu ardışık 3 kez başarısız health check yanıtı verirse (fall), trafik ona gönderilmez (out of rotation). Ne zaman ki ardışık 2 başarılı yanıt verir (rise), o zaman tekrar gruba dahil edilir.

Gelişmiş ACL (Access Control List) Tabanlı Routing

Prod ortamlarında genellikle tek bir domain arkasında birden fazla mikroservis barındırırız. Örneğin /api ile başlayan isteklerin API servislerine, statik dosyaların ise başka bir backende gitmesini isteriz. HAProxy’nin ACL mekanizması bu konuda tam bir canavardır.

Aşağıdaki konfigürasyon örneğinde, path ve domain bazlı yönlendirmeyi nasıl yapacağımızı görelim:

frontend http_front_advanced
    bind 192.168.1.100:80
    mode http

    # ACL Tanımları
    acl is_api path_beg -i /api
    acl is_static path_end -i .jpg .png .css .js
    acl host_admin hdr_beg(host) -i admin.

    # Yönlendirme Kuralları (Routing Rules)
    use_backend api_backend if is_api
    use_backend static_backend if is_static
    use_backend admin_backend if host_admin
    
    # Varsayılan Backend
    default_backend web_backend

backend web_backend
    server web01 192.168.1.30:80 check

backend api_backend
    server api01 192.168.1.40:8080 check

backend static_backend
    server storage01 192.168.1.50:80 check

backend admin_backend
    server admin01 192.168.1.60:80 check

Bu yapıyla birlikte, tek bir load balancer IP’si üzerinden gelen istekleri, url path’ine veya HTTP host header’ına göre ayıklayıp tamamen farklı sunucu gruplarına sıfır performans kaybıyla dağıtabiliyoruz.

Failover Testi: Fişi Çektiğimizde Ne Oluyor?

Kurulumumuzu tamamladık ve servislerimizi başlattık (sudo systemctl enable --now haproxy). Peki sistemimiz gerçekten yüksek erişilebilir mi? Bunu test etmenin en vahşi (ve keyifli) yolu canlı ortamda simülasyon yapmaktır.

Öncelikle master sunucumuzda (LB01) IP adresini izleyelim:

ip addr show eth0

Burada 192.168.1.100 IP’sini görmeliyiz. Şimdi master sunucu üzerinde HAProxy servisini durdurarak Keepalived’ın bu durumu fark etmesini sağlayalım:

sudo systemctl stop haproxy

Hemen ardından pasif sunucuya (LB02) geçip logları izleyelim:

tail -f /var/log/syslog | grep Keepalived

Loglarda şuna benzer bir satır görmelisiniz:

Keepalived_vrrp[1234]: VRRP_Instance(VI_1) Entering MASTER STATE

Ve ip addr show eth0 çalıştırdığınızda, VIP’nin saniyeden daha kısa bir sürede LB02’ye göç ettiğini göreceksiniz. Kullanıcılarınız, veritabanına veri yazmaya ve web sitenizde gezinmeye kesintisiz olarak devam edecektir. İşte gerçek HA kalitesi!

Sonuç ve Pro-Tip

HAProxy ve Keepalived ikilisi, karmaşık cloud mimarilerine veya pahalı donanımsal load balancer cihazlarına ihtiyaç duymadan, Linux’un gücüyle scale olabilen harika bir çözümdür.

Son bir prod tavsiyesi: Keepalived loglarını mutlaka merkezi bir izleme aracına (Elasticsearch, Loki vb.) yönlendirin ve VIP geçişlerinde (state transitions) ekibinize Slack veya Teams üzerinden alert atacak bir script tetikleyin (bunun için Keepalived’ın notify_master ve notify_backup direktiflerini araştırabilirsiniz). VIP’nin sessiz sedasız sürekli yer değiştirmesi, altyapınızda sinsi bir network dalgalanması olduğunun habercisi olabilir.

Category: Genel | LEAVE A COMMENT

Ekim 11 2024

Linux Namespace ve Cgroup: Container’ların Altındaki Mekanizma

Eğer bir teknik mülakatta ya da kahve molasında “Container nedir?” sorusuna “Hizmetleri izole eden hafifletilmiş sanal makinelerdir (VM)” yanıtını verdiyseniz, bugün bu ezberi bozuyoruz. Çünkü aslında işletim sistemi seviyesinde “container” diye bir nesne veya teknoloji bulunmuyor. Bizim docker, containerd ya da podman adını verdiğimiz araçların yaptığı her şey, linux çekirdeğinin (kernel) sunduğu iki temel özelliğin etrafına örülmüş şık birer kullanıcı arayüzü (wrapper) olmaktan ibaret: namespace ve cgroup.

Bu makalede, işin kolayına kaçıp hazır CLI araçları kullanmak yerine, modern bir container runtime’ın (örneğin containerd) yaptığı işi tamamen elle (manual) yapacağız. Sıfırdan izole bir root filesystem (rootfs) hazırlayacak, kendi ağ geçidimizi kuracak, prosesleri izole edecek ve cgroup v2 ile kaynak sınırları koyacağız. Arkanıza yaslanın, terminalinizi açın ve container dünyasının arka bahçesine hoş geldiniz.

1. Hazırlık: Minimal Bir Root Filesystem (rootfs) Oluşturmak

Bir container’ın kendi dünyasında yaşayabilmesi için öncelikle bağımsız bir dosya sistemine ihtiyacı vardır. Docker imajları aslında katmanlaştırılmış (layered) tar dosyalarından başka bir şey değildir. Biz de işe minimal bir Alpine Linux rootfs indirerek başlayacağız.

# Çalışma dizinimizi oluşturalım
mkdir -p /tmp/kerten-container/rootfs
cd /tmp/kerten-container

# Alpine rootfs indiriyoruz
curl -sSL https://dl-cdn.alpinelinux.org/alpine/v3.18/releases/x86_64/alpine-minirootfs-3.18.4-x86_64.tar.gz -o alpine.tar.gz
tar -xzf alpine.tar.gz -C rootfs/
rm alpine.tar.gz

Artık elimizde izole bir işletim sisteminin sahip olması gereken tüm temel dizin yapısı (bin, sbin, etc, lib, proc…) mevcut. Sıradaki adım, bu dizini yeni dünyamızın kök dizini (root) haline getirmek.

2. Chroot Değil, Pivot Root: Güvenli Mount Namespace

Dosya sistemi izolasyonu denince akla gelen ilk syscall (sistem çağrısı) genellikle chroot olur. Ancak chroot esnektir ve root yetkilerine sahip bir proses kolayca bu hapishaneden kaçabilir (jailbreak). Modern container dünyası bunun yerine çok daha güvenli olan pivot_root sistem çağrısını kullanır.

pivot_root, mevcut mount namespace’in root mount noktasını yeni bir dizine taşır ve eski root’u başka bir dizine bind eder. Bunu elle simüle etmek için öncelikle yeni bir mount namespace oluşturmamız gerekir.

İşte sihirli komutumuz: unshare. Bu komut, belirtilen namespace türlerini sıfırdan oluşturarak yeni bir proses başlatır.

# Mount, UTS (hostname) ve IPC namespace'lerini izole ederek yeni bir bash oturumu açıyoruz
unshare --mount --uts --ipc --fork /bin/bash

Şu andan itibaren açılan bu yeni shell oturumunda yaptığımız mount işlemleri host sistemimizi etkilemeyecek. Şimdi rootfs dizinimizi bir mount noktasına dönüştürelim ve pivot_root için hazırlayalım:

# rootfs dizinimizi bir bind mount olarak işaretliyoruz (pivot_root bunu şart koşar)
mount --bind /tmp/kerten-container/rootfs /tmp/kerten-container/rootfs

# Eski root dizinini koyacağımız geçici bir klasör oluşturuyoruz
mkdir -p /tmp/kerten-container/rootfs/put_old

# pivot_root komutunu çalıştırıyoruz: [yeni_root] [eski_root_un_duracagi_yer]
cd /tmp/kerten-container/rootfs
pivot_root . put_old

# Artık yeni root içerisindeyiz. Eski sisteme ait mount noktalarını temizleyelim
cd /
umount -l /put_old
rmdir /put_old

# Hostname'i değiştirelim (UTS namespace sayesinde host etkilenmez)
hostname kerten-container

Harika! Şu an sadece kendi hazırladığımız rootfs içerisindeki ikili dosyaları (binaries) görebilen, izole edilmiş bir dosya sistemindeyiz. Ancak eksik bir şeyler var: Prosesler nerede?

3. PID Namespace: “Ben Kimim?” Sorusu

Eğer az önce oluşturduğumuz ortamda ps aux çalıştırmayı denerseniz, hata alırsınız. Çünkü proseslerin yönetildiği ve kernel bilgilerinin okunduğu sanal dosya sistemi olan /proc henüz mount edilmedi. Daha da önemlisi, hala host sistemin PID (Process ID) uzayını paylaşıyoruz.

Gelin, yeni bir PID namespace oluşturalım. Bunun için yeni bir terminal penceresi açıp host üzerinde çalışmaya devam edeceğiz. Bu sayede hem host hem de container arasındaki ilişkiyi daha net görebiliriz.

Bu sefer PID namespace’i de işin içine katarak unshare ile yeni bir container başlatalım (dosya sistemi adımlarını bu yeni namespace içinde hızlıca tekrarladığımızı varsayalım veya doğrudan aşağıdaki komutla temiz bir başlangıç yapalım):

# PID ve Mount namespace izole edilmiş şekilde başlatıyoruz
unshare --mount --pid --fork --mount-proc /bin/bash

--mount-proc parametresi, bizim için otomatik olarak yepyeni ve izole bir /proc dosya sistemi mount eder. Şimdi bu oturumda prosesleri listeleyelim:

ps aux

Çıktıya dikkat edin:

PID   USER     TIME  COMMAND
    1 root      0:00 /bin/bash
    2 root      0:00 ps aux

İşte container dünyasının kutsal kasesi! Host üzerinde binlerce çalışan proses varken, bizim container’ımız kendisini dünyadaki tek proses (PID 1) olarak görüyor. PID 1 olmak büyük bir sorumluluktur; eğer bu proses ölürse, kernel tüm namespace’i sonlandırır.

4. Network Namespace: Kablolama İşlemleri

Şu ana kadar dosya sistemini ve prosesleri izole ettik ancak container’ımızın dış dünya ile bağlantısı yok (loopback arayüzü bile kapalı). Docker arkada bu işi sanal bir switch (docker0 bridge) ve veth pair (sanal ethernet kablosu) kullanarak çözer.

Gelin bu kablolamayı host üzerinde elle yapalım. Bu senaryo için host üzerinde root yetkileriyle yeni bir terminal açın.

Öncelikle container’ımızın namespace’ini kalıcı hale getirmemiz gerekir ki host üzerinden oraya erişebilelim. Linux’ta her namespace /proc/[PID]/ns/ altında bir dosya olarak temsil edilir.

# Container'ımızın PID'sini host üzerinde bulalım (örneğin 12345 olsun)
# Host üzerinde:
ip netns attach kerten-netns 12345

Şimdi sanal ethernet çiftimizi oluşturalım. Bu işlem, bir ucu hostta, diğer ucu container içinde olan sanal bir kablo yaratacaktır:

# veth çiftini oluştur
ip link add veth-host type veth peer name veth-container

# Kablonun container ucunu container'ın network namespace'ine taşıyalım
ip link set veth-container netns kerten-netns

# Host tarafındaki uca IP verelim ve ayağa kaldıralım
ip addr add 10.200.0.1/24 dev veth-host
ip link set veth-host up

# Container tarafındaki uca IP verelim ve ayağa kaldıralım
ip netns exec kerten-netns ip addr add 10.200.0.2/24 dev veth-container
ip netns exec kerten-netns ip link set veth-container up
ip netns exec kerten-netns ip link set lo up # Loopback'i unutmayalım

# Container için default gateway tanımlayalım
ip netns exec kerten-netns ip route add default via 10.200.0.1

Artık container içinden host tarafındaki 10.200.0.1 IP adresine ping atabilirsiniz. Container runtime’ların her container için saniyeler içinde yaptığı o karmaşık ağ konfigürasyonunun temel mekanizması tam olarak budur.

5. Cgroup v2 Sihri: Kaynakları Sınırlandırmak

Güzel, izole bir ortamımız ve ağımız var. Peki ya bu container içerisindeki bir proses çıldırır ve host sistemin tüm CPU ve RAM kaynaklarını tüketmeye çalışırsa? İşte burada devreye cgroup (Control Groups) giriyor.

Modern Linux dağıtımları artık varsayılan olarak cgroup v2 kullanıyor. Cgroup v2, v1’deki dağınık yapıyı tek bir hiyerarşik ağaç altında birleştirerek işleri inanılmaz derecede kolaylaştırdı. Cgroup v2 hiyerarşisi varsayılan olarak /sys/fs/cgroup dizininde yaşar.

Şimdi elle “kerten-limit” adında bir kontrol grubu oluşturalım ve container’ımızın bellek kullanımını 100 MB ile sınırlayalım:

# Host üzerinde cgroup dizinine gidelim
cd /sys/fs/cgroup

# Yeni bir grup oluşturmak sadece bir dizin oluşturmaktan ibarettir!
mkdir kerten-limit
cd kerten-limit

# Kernel, bu dizini oluşturduğumuz an içine kontrol dosyalarını otomatik olarak yerleştirir.
ls -la

Şimdi bellek sınırımızı (memory limit) 100MB (104857600 bytes) olarak ayarlayalım:

echo "104857600" > memory.max

Peki bu sınırı container prosesimize nasıl uygulayacağız? Çok basit: Container prosesimizin host üzerindeki PID’sini (örneğin 12345) cgroup altındaki cgroup.procs dosyasına yazmamız yeterli:

echo "12345" > cgroup.procs

Artık bu proses veya bu prosesten türeyecek (fork) olan tüm alt süreçler toplamda 100 MB bellek sınırını aşamazlar. Sınırı aşmaya çalıştıkları anda kernel’ın meşhur OOM-Killer (Out of Memory Killer) mekanizması devreye girecek ve o prosesi acımasızca sonlandıracaktır. Tıpkı Kubernetes ortamında aldığınız o meşhur OOMKilled hatası gibi!

Özet: Container Aslında Bir İllüzyondur

Gördüğünüz gibi, arka planda çalışan gizemli hipervizörler, sanal donanımlar veya ağır sanallaştırma katmanları yok. Yaptığımız her şey, Linux kernel’ına “Bu prosese sadece şu dizini göster (mount namespace), sadece şu prosesleri görmesine izin ver (PID namespace), ağ trafiğini şu sanal kabloya yönlendir (net namespace) ve şu kadar kaynak tüketmesine izin ver (cgroups)” demekten ibaretti.

Docker ve containerd gibi araçlar, bu karmaşık syscall ve CLI yönetimini otomatize ederek bize pratik birer imaj paketleme ve dağıtım standardı sunar. Bu temel mekanizmayı kavramak, Kubernetes ortamlarında veya büyük ölçekli altyapılarda karşılaştığınız ağ, performans ve izolasyon sorunlarını (troubleshooting) çok daha hızlı ve profesyonelce çözmenizi sağlayacaktır.

Bir sonraki derin dalış makalemizde görüşmek üzere, sistemleriniz ayakta, container’larınız hafif kalsın!

Category: Genel | LEAVE A COMMENT

Ekim 4 2024

Cron İşlerini Bash ile Monitör Etme ve Alerting

Modern altyapılarda Kubernetes cronjob’ları, serverless scheduler’lar havada uçuşsa da, günün sonunda hepimizin bir yerlerde tıkır tıkır çalışan (ya da çalıştığını umduğu) emektar bir linux sunucusu ve içinde barınan klasik cron işleri vardır. Ancak cron’un en büyük problemi “sessiz ölüm” (silent failure) dediğimiz durumdur. Bir backup script’i patladığında, disk dolduğunda veya API key’in süresi geçtiğinde cron bunu size söylemez. Bu yazıda, kendi yazacağımız esnek bir bash wrapper script ile tüm cron işlerinizi merkezi olarak monitoring dünyasına entegre edecek, hata durumlarında anında alert üretecek ve üçüncü parti servislerle nasıl haberleştireceğimizi göreceğiz.

Klasik Cron Yaklaşımlarının Sorunu Nedir?

Hepimiz o yollardan geçtik. Bir cron işinin çıktısını almak için satırın sonuna efsanevi >> /var/log/myjob.log 2>&1 yönlendirmesini yazarız. Sonra ne mi olur? O log dosyası gigabaytlarca büyür, diski doldurur ve bir gün script hata verdiğinde kimsenin haberi olmaz. Çünkü logları aktif olarak okuyan kimse yoktur.

Eski usul Linux yöneticileri size “MTA (Mail Transfer Agent) kurun, cron hata aldığında lokal mail atsın” diyecektir. Yıl 2024+. ephemeral VM’lerin, cloud instance’larının cirit attığı bu çağda localhost mail kuyruklarıyla uğraşmak, postfix yapılandırmak ve spame düşen lokal mailleri takip etmek tam bir operasyonel işkencedir. Bizim daha proaktif, modern ve DevOps pratiklerine uygun bir çözüme ihtiyacımız var.

Wrapper Script Pattern Neden En İyi Çözümdür?

Elinizde 20 farklı cron script’i olduğunu düşünün. Her birinin içine tek tek Slack webhook entegrasyonu, hata yakalama (error handling) ve çalışma süresi ölçümü eklemek tam bir anti-pattern’dir. Kod tekrarı yaratır ve yarın öbür gün Slack yerine Teams’e geçildiğinde 20 farklı script’i update etmeniz gerekir.

Wrapper Script Pattern, çalıştırılacak asıl komutu sarmalayan, onun exit code’unu yakalayan, standart output (stdout) ve standart error (stderr) akışlarını yöneten merkezi bir aracıdır. Crontab içerisindeki tanımımız şuna benzer:

0 4 * * * /usr/local/bin/cron-wrapper.sh --job "db-backup" --cmd "/opt/scripts/backup.sh --force"

Bu yaklaşım sayesinde, asıl işi yapan script’in monitoring mantığından tamamen bağımsız (decoupled) kalmasını sağlarız. Script sadece işini yapar ve exit code döner; wrapper ise raporlamayı üstlenir.

Adım 1: Savaşçı Ruhlu Bash Wrapper Script

Lafı uzatmadan production ortamında güvenle kullanabileceğiniz, hata durumunda exit code’u ve logları yakalayan, zaman aşımı (timeout) kontrolü yapabilen wrapper script’imizi yazalım. Bu script’i /usr/local/bin/cron-wrapper.sh olarak kaydedebilirsiniz.

#!/usr/bin/env bash

# Robust Bash Ayarları
set -o nounset
set -o pipefail

# Değişken Tanımları
JOB_NAME=""
COMMAND=""
SLACK_WEBHOOK_URL="${SLACK_WEBHOOK_URL:-""}"
HEALTHCHECK_URL="${HEALTHCHECK_URL:-""}"

# Kullanım Yardımcısı
usage() {
    echo "Kullanım: $0 --job [JOB_NAME] --cmd [COMMAND]"
    exit 1
}

# Parametreleri Parse Etme
while [[ $# -gt 0 ]]; do
    case "$1" in
        --job)
            JOB_NAME="$2"
            shift 2
            ;;
        --cmd)
            COMMAND="$2"
            shift 2
            ;;
        *)
            usage
            ;;
    esac
done

if [[ -z "$JOB_NAME" || -z "$COMMAND" ]]; then
    usage
fi

# Geçici Log Dosyası Oluşturma (Güvenli yöntem)
LOG_FILE=$(mktemp /tmp/cron_wrapper_${JOB_NAME}.XXXXXX)

# Her durumda temizlik yapılması için trap kullanımı
cleanup() {
    rm -f "$LOG_FILE"
}
trap cleanup EXIT

# Zamanı Ölçmeye Başla
START_TIME=$(date +%s)

echo "[$(date '+%Y-%m-%d %H:%M:%S')] Job '$JOB_NAME' başlatılıyor..." >> "$LOG_FILE"
echo "Komut: $COMMAND" >> "$LOG_FILE"
echo "--------------------------------------------------" >> "$LOG_FILE"

# Komutu çalıştır ve tüm çıktıyı log dosyasına yönlendir
# set +e kullanıyoruz çünkü komut hata verirse wrapper script'in hemen çökmesini istemiyoruz,
# hatayı yakalayıp alert üreteceğiz.
set +e
eval "$COMMAND" >> "$LOG_FILE" 2>&1
EXIT_CODE=$?
set -e

# Zamanı Hesapla
END_TIME=$(date +%s)
DURATION=$((END_TIME - START_TIME))

echo "--------------------------------------------------" >> "$LOG_FILE"
echo "[$(date '+%Y-%m-%d %H:%M:%S')] Job bitti. Süre: ${DURATION}sn, Exit Code: $EXIT_CODE" >> "$LOG_FILE"

# Sonuçları Değerlendir
if [ $EXIT_CODE -eq 0 ]; then
    echo "Başarılı: $JOB_NAME sorunsuz tamamlandı."
    # Eğer tanımlıysa Healthcheck ping'i gönder (Mavi Tik)
    if [ -n "$HEALTHCHECK_URL" ]; then
        curl -fsS --retry 3 "$HEALTHCHECK_URL" > /dev/null 2>&1 || true
    fi
else
    echo "HATA: $JOB_NAME başarısız oldu! Exit code: $EXIT_CODE" >&2
    
    # Slack Alert Tetikleme fonksiyonunu çağır
    if [ -n "$SLACK_WEBHOOK_URL" ]; then
        # Log dosyasının son 20 satırını alalım ki Slack mesajı devasa olmasın
        LAST_LOGS=$(tail -n 20 "$LOG_FILE" | sed 's/"/\\"/g' | sed ':a;N;$!ba;s/\n/\\n/g')
        
        PAYLOAD=$(cat <<EOF
{
  "text": "🚨 *Cron Job Hatası!*",
  "attachments": [
    {
      "color": "danger",
      "fields": [
        { "title": "Job Adı", "value": "${JOB_NAME}", "short": true },
        { "title": "Exit Code", "value": "${EXIT_CODE}", "short": true },
        { "title": "Süre", "value": "${DURATION} saniye", "short": true },
        { "title": "Sunucu", "value": "$(hostname)", "short": true }
      ],
      "text": "*Son Loglar:*\n\`\`\`${LAST_LOGS}\`\`\`"
    }
  ]
}
EOF
)
        curl -X POST -H 'Content-type: application/json' --data "$PAYLOAD" "$SLACK_WEBHOOK_URL" > /dev/null 2>&1 || true
    fi
    
    # Wrapper kendisi de hata koduyla çıksın ki pipeline'lar veya üst sistemler anlasın
    exit $EXIT_CODE
fi

Neden “set +e” ve “set -o pipefail” Kullandık?

Bash’te hata yönetimi hassas bir konudur. set -o pipefail komutu, bir pipe zincirindeki herhangi bir komut hata verirse tüm satırın hata kodu dönmesini sağlar. Wrapper script’in başında bunu aktif ettik. Ancak, sarmaladığımız asıl komut hata verdiğinde script’imizin patlayıp Slack alert’ini gönderemeden sonlanmasını engellemek için, çalıştırma aşamasında geçici olarak set +e ile esneklik sağladık, exit code’u güvenli bir şekilde $? ile lokal değişkene aldık ve ardından set -e ile güvenli modumuza geri döndük.

Ayrıca mktemp kullanımı, paralel çalışan cron işlerinin aynı log dosyası üzerine yazarak yarış durumuna (race condition) girmesini engeller.

Adım 2: “Dead Man’s Snitch” Mantığı ile Healthcheck Entegrasyonu

Peki ya sunucunun kendisi çökerse? Ya da cron daemon durursa? Bu durumlarda “hata aldığımda Slack’e yaz” mantığı tamamen devre dışı kalır. Çünkü çalışmayan bir sistem hata mesajı da gönderemez. Buna monitoring dünyasında silent failure denir.

Çözüm: Inverted Monitoring (Ters İzleme) ya da bilinen adıyla Heartbeat / Dead Man’s Snitch pattern. Sistem çalışmayı durdurduğunda alarm çalmasını istiyorsak, sistemin düzenli aralıklarla “Ben hayattayım!” sinyali göndermesi gerekir. Eğer sinyal gelmezse, monitoring sunucumuz bizi uyarır.

Bu iş için healthchecks.io veya kendi host ettiğiniz open-source alternatiflerini (örneğin Uptime Kuma) kullanabilirsiniz. Script’imizdeki HEALTHCHECK_URL tam olarak bunu yapar. Cron başarılı biterse ilgili adrese bir curl isteği atar. Eğer o istek zamanında gitmezse, dış dünya sunucunun patladığını anlar.

Adım 3: Slack Webhook ile Gerçek Zamanlı Alerting

Yukarıdaki script’imizde Slack için JSON payload’unu dinamik olarak oluşturduk. Bash içinde JSON oluştururken kaçış karakterleri (escaping) her zaman baş ağrıtır. Bu yüzden log dosyasından okuduğumuz son 20 satırı (LAST_LOGS) temizlemek için sed ile yeni satır karakterlerini (\n) ve çift tırnakları escape ettik.

Slack’te görünecek mesaj, hata anında debug yapmanızı inanılmaz kolaylaştıracaktır. Hangi sunucuda, ne kadar sürede patladığını ve hatanın son satırlarını terminale girmeden telefonunuzdan görebilirsiniz:

Slack Notification Alerting

Adım 4: Crontab Yapılandırması

Şimdi yazdığımız bu sistemi gerçek bir senaryoda test edelim. Sunucumuzdaki env variable’ları crontab ortamına geçirmek bazen can sıkıcı olabilir. En temiz yöntem webhook url gibi hassas verileri wrapper script içine hardcode etmek yerine wrapper’ı çağırırken bir konfigürasyondan beslemek veya crontab’ın üst kısmında tanımlamaktır.

# /etc/cron.d/my-monitored-crons veya crontab -e

SLACK_WEBHOOK_URL="https://hooks.slack.com/services/T00/B00/X00"
HEALTHCHECK_URL="https://hc-ping.com/your-uuid-here"

# Her gece 03:00'te yedek al, hata olursa Slack'e bildir, başarılı olursa ping at
0 3 * * * root /usr/local/bin/cron-wrapper.sh --job "database-backup" --cmd "/opt/backups/pg_dump.sh"

Dikkat Edilmesi Gereken İpuçları

Mutlak Yol (Absolute Paths) Kullanın: Cron ortamında $PATH değişkeni kısıtlıdır. Hem wrapper script’in içinde çağırdığınız tool’ların (curl, sed vb.) hem de crontab içindeki komutların tam yollarını yazmaya özen gösterin.
Yetkilendirme: Wrapper script’in çalıştırılabilir olduğundan emin olun: chmod +x /usr/local/bin/cron-wrapper.sh
Log Rotasyonu: Biz script içinde trap kullanarak geçici logları işlem sonunda siliyoruz. Ancak işlem yarıda kesilirse (örneğin kill -9) loglar kalabilir. Periyodik olarak /tmp dizininin temizlendiğinden emin olun (çoğu modern Linux dağıtımı bunu otomatik yapar).

Özet

Cron işlerini kendi haline bırakmak, prod ortamında saatli bir bomba üzerinde oturmak gibidir. Bu makalede yazdığımız esnek bash wrapper script sayesinde, mevcut hiçbir altyapınızı bozmadan, tek bir merkezi mekanizma ile tüm linux cron işlerinizi modern birer microservice gibi monitoring ve alert süreçlerine dahil ettik. Unutmayın, en iyi sistem tıkır tıkır çalışan değil, bozulduğunda neresinin bozulduğunu size ilk söyleyen sistemdir.

Category: Genel | LEAVE A COMMENT

Eylül 27 2024

Linux Sistem Performans Analizi: perf, strace ve eBPF Araçları

Bir sabah Slack’ten gelen o korkunç alarm sesiyle uyandınız: “Production veritabanı sunucusunda latency uçtu, CPU %99!” Hemen sunucuya SSH ile bağlandınız, top komutunu çalıştırdınız ve evet, CPU gerçekten can çekişiyor. Ancak top veya htop gibi geleneksel araçlar size sadece “yangın olduğunu” söyler; yangının hangi odada, hangi kibritle başladığını göstermez. İşte bu noktada modern bir SRE (Site Reliability Engineer) gibi düşünmeli ve linux çekirdeğinin (kernel) derinliklerine inmeliyiz. Bu yazıda, modern altyapılarda performance sorunlarını iğne deliğinden geçirir gibi analiz etmenizi sağlayacak üç silahşörü inceleyeceğiz: perf, strace ve devrim niteliğindeki ebpf tabanlı bpftrace.

1. Donanımın Nabzını Tutmak: perf (CPU & Hardware Profiling)

perf, Linux çekirdeği ile doğrudan entegre çalışan inanılmaz güçlü bir profil çıkarma (profiling) aracıdır. CPU döngülerini (cycles), cache miss (önbellek kaçırma) oranlarını ve CPU talimatlarını (instructions) donanımsal sayaçları (PMU – Performance Monitoring Unit) kullanarak analiz eder.

Neden Sadece CPU Yüzdesine Bakmak Yanıltıcıdır?

Çoğu mühendis CPU %100 olduğunda uygulamanın çok yoğun hesaplama yaptığını düşünür. Ancak durum her zaman bu değildir. CPU, RAM’den veri beklerken de (stall cycles) %100 meşgul görünebilir. Biz buna Memory-Bound (bellek sınırlandırılmış) deriz. Eğer CPU gerçekten matematiksel işlemler yapıyorsa buna da Compute-Bound denir.

Bu ayrımı görmek için ilk yapmamız gereken şey perf stat komutunu çalıştırmaktır:

# Belirli bir PID'yi 5 saniye boyunca analiz edelim
perf stat -p 1234 sleep 5

Karşımıza şöyle bir çıktı gelecektir:

 Performance counter stats for process id '1234':

       2001.45 msec task-clock                #    0.400 CPUs utilized          
              1234  context-switches          #    0.617 K/sec                  
                45  cpu-migrations            #    0.022 K/sec                  
               105  page-faults               #    0.052 K/sec                  
        4002938102  cycles                    #    2.000 GHz                    
        2001467291  instructions              #    0.50  insn per cycle         
         120495839  branches                  #   60.204 M/sec                  
           4958102  branch-misses             #    4.11% of all branches        

       5.002345123 seconds time elapsed

Burada odaklanmamız gereken en kritik metrik insn per cycle (IPC) değeridir. IPC (Instructions Per Cycle), CPU’nun her döngüde kaç talimat çalıştırdığını gösterir.

IPC < 1.0 ise: Uygulamanız muhtemelen I/O veya memory erişimi bekliyor (Memory-Bound). CPU boşta (stall) bekliyor demektir.
IPC > 1.5 ise: CPU gerçekten yoğun şekilde kodunuzu çalıştırıyor demektir (Compute-Bound).

Sıcak Noktaları Bulmak: perf record ve perf report

Uygulamanın tam olarak hangi fonksiyonunun CPU’yu sömürdüğünü bulmak için örnekleme (sampling) yapmamız gerekir. Bu işlem production ortamlarında genellikle %1 ila %5 arasında çok düşük bir overhead (ek yük) ile yapılabilir.

# Saniyede 99 frekansla (overkill olmaması için idealdir) 10 saniye boyunca kayıt alalım
# -g parametresi call-graph (çağrı ağacı) kaydetmesini sağlar
perf record -F 99 -p 1234 -g -- sleep 10

Bu komut geçerli dizinde perf.data adında bir dosya oluşturur. Bu dosyayı analiz etmek için terminalden şu komutu veririz:

perf report -n --stdio

Karşınıza çıkan interaktif arayüzde hangi fonksiyonun (sembolün) CPU döngülerinin yüzde kaçını harcadığını hiyerarşik bir şekilde görebilirsiniz. Eğer fonksiyon isimleri yerine [hexadecimal] adresler görüyorsanız, uygulamanızın “debug symbols” (hata ayıklama sembolleri) eksiktir demektir. Go kullanıyorsanız binary’nizi strip etmeyin, C++/Rust kullanıyorsanız -g flag’i ile derlediğinizden emin olun.

2. Karanlıkta Kalan Sistem Çağrıları: strace

Uygulamanız çalışıyor ama hiçbir şey yapmıyor gibi mi görünüyor? Dosya okumaya çalışırken kilitlenmiş olabilir mi? Yoksa DNS çözümlemesi yaparken timeout mu yaşıyor? Bu gibi durumlarda, uygulamanın kernel ile olan iletişimini yani System Calls (syscalls) trafiğini izlememiz gerekir.

İşte strace bu işin mutfağıdır.

Production Uyarısı: strace’i Dikkatli Kullanın!

Geliştirme ortamında strace my_app yazıp geçmek harikadır ancak bunu canlı production ortamında sakın yapmayın! strace, izlediği process’in her syscall yaptığında durdurulmasını (ptrace ile) sağlar. Bu durum, uygulamanın performansını %100 ila %1000 oranında düşürebilir.

Bunun yerine, production dostu parametrelerle nokta atışı yapmalıyız:

# Uygulamanın en çok hangi sistem çağrısında ne kadar zaman harcadığını özetleyelim
# Bu işlem ham log akıtmaya göre çok daha az overhead yaratır
strace -c -p 1234

Çıktı bize muhteşem bir özet sunacaktır:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 89.45    1.204958         120     10041           read
 10.12    0.136120          13     10200      1050 openat
  0.43    0.005789          11       500           write
------ ----------- ----------- --------- --------- ----------------
100.00    1.346867                 20741      1050 total

Yukarıdaki tabloda net bir şekilde görüyoruz ki, uygulama zamanının %89’unu read sistem çağrısında harcıyor ve ciddi miktarda openat (dosya açma hatası) alıyor. Hangi dosyayı açamadığını bulmak için sadece hatalı çağrıları filtreleyebiliriz:

# Sadece başarısız olan (errors) openat çağrılarını göster
strace -e trace=openat -Z -p 1234

3. Modern Çağın Sihirli Değneği: eBPF ve bpftrace

Geleneksel araçların kısıtlamalarından sıkıldıysanız, sahneye eBPF (Extended Berkeley Packet Filter) çıkıyor. eBPF, Linux çekirdeğinin kodunu değiştirmeden veya kernel modülü yüklemeden, güvenli sandbox’lar içinde doğrudan çekirdekte kod çalıştırmamızı sağlar.

bpftrace ise eBPF dünyasının “awk” dilidir. Son derece hafif, pratik ve neredeyse sıfır overhead ile çalışan tek satırlık (one-liners) script’ler yazmamıza olanak tanır.

Örnek 1: Disk I/O Latency Analizi (Biolatency)

Diskinizin yavaş olduğunu düşünüyorsunuz ama hangi process’in ne kadarlık bir gecikmeye sebep olduğunu bulamıyorsunuz. Geleneksel iostat size sadece ortalama değerler verir. bpftrace ile gerçek zamanlı bir histogram çizelim:

# Disk I/O tamamlanma sürelerini mikrosaniye cinsinden histogram olarak gösterir
bpftrace -e '
kprobe:vfs_read { @start[tid] = nsecs; } 
kretprobe:vfs_read /@start[tid]/ { 
    @latency = hist((nsecs - @start[tid]) / 1000); 
    delete(@start[tid]); 
}'

Bu script, her vfs_read (sanal dosya sistemi okuma) başladığında bir zaman damgası alır ve bittiğinde aradaki farkı hesaplayıp logaritmik bir grafik çizer:

@latency: 
[2, 4)                12 |@@@@                                        |
[4, 8)                85 |@@@@@@@@@@@@@@@@@@@@@@@@                    |
[8, 16)              142 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[16, 32)              45 |@@@@@@@@@@@@                                |
[32, 64)               8 |@@                                          |

Bu grafiğe bakarak, okuma işlemlerinin büyük çoğunluğunun 8-16 mikrosaniye arasında tamamlandığını, yani diskimizin sağlıklı çalıştığını saniyeler içinde anlayabiliriz.

Örnek 2: Bellek Sızıntısı (Memory Leak) Avı

Sisteminizde gizemli bir bellek şişmesi var. Hangi uygulamanın sürekli malloc çağırıp free etmediğini bulmak istiyorsunuz. eBPF ile kullanıcı alanındaki (user-space) bellek allocation çağrılarını takip edebiliriz:

# libc içindeki malloc çağrılarının byte boyutlarına göre dağılımını izleyelim
bpftrace -e 'usdt:/lib/x86_64-linux-gnu/libc.so.6:libc:memory_malloc_retry { @[arg0] = count(); }'

Bu sayede production ortamında çalışan uygulamanıza hiçbir kütüphane enjekte etmeden veya onu durdurmadan bellek tüketim kalıplarını yakalayabilirsiniz.

Özet ve Doğru Aracı Seçme Rehberi

Sistem tıkandığında hangi aracı ne zaman kullanacağınıza karar vermek, tecrübeli bir mühendisi amatörden ayıran en önemli özelliktir. İşte size pratik bir başucu tablosu:

Senaryo / Belirti	Kullanılacak Araç	Neden?
Yüksek CPU kullanımı var, hangi kod satırının yavaş olduğunu bulmak istiyorum.	`perf record / report`	Düşük overhead ile CPU çağrı ağacını (call graph) çıkarır.
Uygulama kilitlendi (stuck), log üretmiyor, ne yaptığını göremiyorum.	`strace -p <PID>`	Çekirdeğe gönderdiği sistem çağrılarını (network, dosya erişimi) anlık listeler.
Disk performansından şüpheleniyorum ama genel istatistikler yetersiz kalıyor.	`bpftrace (eBPF)`	Kernel seviyesinde I/O kuyruk gecikmesini histogram olarak gösterir.
Sistemin donanımsal düzeyde (L1/L2 Cache, CPU Cycles) analizine ihtiyacım var.	`perf stat`	İşlemcinin donanımsal sayaçlarına doğrudan erişim sağlar.

Performans analizi yaparken her zaman en az invaziv (sisteme en az müdahale eden) yöntemden başlayın. Önce perf stat ve bpftrace ile genel resmi görün, gerekirse ve güvenliyse strace ile derinlemesine inceleme yapın. Unutmayın, iyi bir SRE sadece sorunu çözen değil, sorunu çözerken production sistemini ayakta tutabilen kişidir!

Category: Genel | LEAVE A COMMENT

Eylül 20 2024

Bash’te Hata Yönetimi: set -euo pipefail ile Güvenli Script Yazımı

Hepimiz oradaydık: Gece yarısı gelen bir PagerDuty alarmı, çöken bir production sunucusu ve kaynağı belirsiz, yarıda kesilmiş bir deploy süreci. Loglara baktığınızda ise “exit 0” ile başarıyla tamamlanmış görünen ama arkasında enkaz bırakmış bir script görüyorsunuz. Modern devops ve altyapı otomasyonu dünyasında, linux üzerinde koşan bash scripting süreçleri hala sistemlerin can damarıdır. Ancak Kubernetes manifestleri veya Terraform kodları yazarken gösterdiğimiz özeni, maalesef bu kabuk script’lerine göstermiyoruz. “Çalışıyorsa dokunma” felsefesi, ilk production kazasına kadar kulağa hoş gelir.

Bu yazıda, Bash script’lerinizi “çocuk oyuncağı” olmaktan çıkarıp, kurumsal seviyede hata toleranslı ve güvenli hale getirecek teknikleri ele alacağız. Sadece komutları sıralamayacağız; arkasındaki “neden” sorusuna yanıt arayacağız.

Sessiz Katilleri Durdurun: set -euo pipefail

Bash’in varsayılan davranışı inanılmaz derecede affedicidir. Bir satır hata verse bile, script bir sonraki satırdan neşeyle çalışmaya devam eder. Bu durum, otomasyon süreçlerinde tam bir felaket senaryosudur. Bu vurdumduymazlığı engellemenin yolu, script’in en başına o sihirli satırı eklemektir:

#!/usr/bin/env bash
set -euo pipefail

Peki bu parametreler tam olarak ne işe yarıyor? Tek tek inceleyelim ve neden hayati olduklarını görelim.

1. set -e (Exit on Error)

Varsayılan olarak Bash, sıfırdan farklı (non-zero) bir exit code ile dönen komutları önemsemez. Örneğin, veritabanı yedeği almaya çalışan bir script düşünün:

pg_dump -U admin mydb > backup.sql
tar -czf backup.tar.gz backup.sql
aws s3 cp backup.tar.gz s3://my-bucket/

Eğer pg_dump komutu yetki hatasından dolayı başarısız olursa, script durmaz. Boş bir backup.sql dosyasını sıkıştırır ve S3’e yükler. Pipeline’ınız yeşil yanar ama elinizde yedek yoktur! set -e (veya uzun adıyla set -o errexit), herhangi bir komut başarısız olduğunda script’in anında sonlanmasını sağlar.

2. set -u (Nounset / Unset Variables)

Bash’te tanımlanmamış bir environment variable kullanmaya çalışırsanız, Bash bunu sessizce boş bir string olarak kabul eder. Şu meşhur felaket senaryosuna bakalım:

TARGET_DIR="" # Bir hata sonucu boş kaldı
rm -rf "$TARGET_DIR/*"

Eğer set -u (veya set -o nounset) aktif değilse, bu komut rm -rf /* olarak çalışacak ve sisteminizi silecektir. Bu parametre açık olduğunda, tanımlanmamış bir değişken kullanıldığı anda Bash çalışmayı durdurur ve unbound variable hatası verir.

3. set -o pipefail

İşte en çok gözden kaçan parametre. set -e tek başına pipeline (boru hattı) kullanan komutlardaki hataları yakalayamaz. Örneğin:

non_existent_command | grep "foo"

Burada ilk komut hata verecektir (exit code 127). Ancak pipeline’ın toplam exit code’u, en son komutun (yani grep’in) exit code’udur. Grep başarıyla çalıştığı için (veya eşleşme bulamadığı için) tüm satır başarılı kabul edilir. set -o pipefail eklediğimizde, pipeline içindeki herhangi bir komut hata verirse, tüm zincir başarısız kabul edilir.

Geri Temizlik (Cleanup) ve Trap Mekanizması

Script’imiz hata aldığında veya yarıda kesildiğinde (örneğin kullanıcı Ctrl+C yaptığında), arkasında geçici dosyalar, kilit (lock) dosyaları veya açık portlar bırakabilir. Linux dünyasında bu durum “resource leak” olarak adlandırılır. Bash’in sunduğu trap mekanizması, script nasıl sonlanırsa sonlansın (ister başarıyla, ister hata ile) çalışacak temizlik rutinleri yazmamızı sağlar.

Aşağıdaki örneği inceleyelim:

#!/usr/bin/env bash
set -euo pipefail

# Geçici bir dosya oluşturalım
TEMP_FILE=$(mktemp /tmp/api_response.XXXXXX)

# Temizlik fonksiyonu
cleanup() {
    echo "⚙️ Temizlik yapılıyor: ${TEMP_FILE} siliniyor..."
    rm -f "$TEMP_FILE"
}

# EXIT sinyalini yakala ve cleanup fonksiyonunu çalıştır
trap cleanup EXIT

# Script ana gövdesi
echo "Veri çekiliyor..."
curl -s https://api.kertenkerem.net/status > "$TEMP_FILE"

# Eğer burada bir hata olursa bile, trap sayesinde cleanup çalışacaktır.
grep -q "SUCCESS" "$TEMP_FILE"
echo "İşlem başarıyla tamamlandı."

Burada trap cleanup EXIT tanımı sayesinde, script normal bir şekilde bittiğinde veya aradaki bir komut hata verip script’i sonlandırdığında cleanup fonksiyonu otomatik olarak tetiklenir.

Hata Detaylarını Yakalamak: ERR Sinyali

Sadece temizlik yapmak yetmez, bazen hatanın hangi satırda ve hangi fonksiyon içinde gerçekleştiğini loglamak isteriz. Bunun için ERR sinyalini yakalayabiliriz:

failure_handler() {
    local exit_code=$?
    local line_no=$1
    echo "❌ HATA: Script ${line_no}. satırda, exit code ${exit_code} ile çöktü!" >&2
    # Buraya Slack/Teams webhook entegrasyonu eklenebilir.
}

trap 'failure_handler ${LINENO}' ERR

Exit Code Standartları

Yazdığınız script’lerin birer “iyi vatandaş” olması gerekir. Yani başka bir program (örneğin Jenkins, GitHub Actions veya GitLab CI) sizin script’inizi çağırdığında, neyin yanlış gittiğini sadece loglardan değil, exit code’dan da anlayabilmelidir.

Her zaman sadece exit 1 kullanmak tembelliktir. POSIX standartlarına göre bazı exit code’ların özel anlamları vardır:

0: Başarılı sonlanma.
1: Genel bilinmeyen hatalar.
2: Hatalı argüman veya CLI parametresi kullanımı (Misuse of shell builtins).
126: Komut çalıştırılamadı (Permission denied / Not executable).
127: Komut bulunamadı (Command not found).
128+n: Fatal error signal “n” (Örn: Ctrl+C ile sonlandırma için 130).

Kendi script’lerinizde özel hata durumları için 64-113 arasındaki değerleri kullanabilirsiniz. Örneğin:

readonly ERR_DB_CONNECTION=74
readonly ERR_INVALID_CONFIG=78

if ! ping -c 1 "$DB_HOST" &> /dev/null; then
    echo "Veritabanına erişilemiyor!" >&2
    exit "$ERR_DB_CONNECTION"
fi

Bash Script Test Edilir mi? Karşınızda: Bats (Bash Automated Testing System)

“Script’i yazdım, bir kere manuel çalıştırdım, çalışıyor” mantığı modern DevOps pratiklerine aykırıdır. Altyapı kodunuz değiştikçe, yazdığınız script’lerin de test edilmesi gerekir. Bunun için en popüler framework Bats-core‘dur.

Bats, script’lerinizi gerçek assertion’lar ile test etmenizi sağlayan TAP (Test Anything Protocol) uyumlu bir test aracıdır.

Örnek Bir Bats Testi

Öncelikle test etmek istediğimiz küçük bir fonksiyonumuz olsun (helper.sh):

# helper.sh
is_semver() {
    local version=$1
    if [[ $version =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
        return 0
    else
        return 1
    fi
}

Şimdi bu fonksiyon için yazacağımız test dosyası (helper.bats):

# helper.bats
setup() {
    source ./helper.sh
}

@test "Geçerli semver formatını doğrula" {
    run is_semver "1.2.3"
    [ "$status" -eq 0 ]
}

@test "Geçersiz semver formatını reddet" {
    run is_semver "v1.2"
    [ "$status" -eq 1 ]
}

CI/CD pipeline’ınızda bats helper.bats komutunu çalıştırarak bu testleri otomatik hale getirebilirsiniz. Böylece birisi script’i refactor ettiğinde bir şeylerin kırılıp kırılmadığını anında görebilirsiniz.

Özet: Kurşun Geçirmez Bir Bash Şablonu

Tüm bu öğrendiklerimizi bir araya getiren, yeni projelerinizde doğrudan kopyalayıp kullanabileceğiniz güvenli bir Bash şablonu ile yazıyı sonlandıralım:

#!/usr/bin/env bash

# Güvenlik flag'leri
set -euo pipefail
IFS=$'\n\t'

# Script dizinini bul (Path bağımsız çalışabilmek için)
readonly SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"

# Global Hata Yakalama
error_handler() {
    local exit_code=$?
    local line_no=$1
    echo "❌ Hata oluştu! Satır: ${line_no} | Exit Code: ${exit_code}" >&2
    cleanup
    exit "$exit_code"
}

cleanup() {
    echo "🧹 Geçici kaynaklar temizleniyor..."
    # Temizlik komutları buraya
}

# Sinyalleri dinle
trap 'error_handler ${LINENO}' ERR
trap cleanup EXIT

# Ana Kod
main() {
    echo "🚀 Script başlatılıyor, dizin: ${SCRIPT_DIR}"
    # Uygulama mantığınız buraya gelecek
}

main "$@"

Bash scripting, doğru yapılandırılmadığında production ortamlarında saatli bir bombaya dönüşebilir. Ancak yukarıdaki pratikleri benimseyerek, kodunuzun öngörülebilir, test edilebilir ve en önemlisi güvenli olmasını sağlayabilirsiniz.

Category: Genel | LEAVE A COMMENT