Mayıs 28 2026

GitOps: Altyapınızın Orkestra Şefi Artık Git!

Merhaba sevgili teknoloji meraklıları, kod sihirbazları ve altyapı mimarları! Nasılsınız, iyi misiniz? Umarım her şey yolundadır ve sunucularınız tıkır tıkır çalışıyordur. Bugün, son zamanlarda adını sıkça duyduğumuz, hatta belki de “yeni nesil IaC” olarak nitelendirebileceğimiz bir konuya dalış yapacağız: GitOps.

Şimdi durup bir düşünelim: “Infrastructure as Code” (IaC) zaten hayatımızdaydı, değil mi? `CloudFormation`, `Terraform`, `Ansible` gibi araçlarla altyapımızı kod olarak tanımlıyor, versiyonluyor ve otomatikleştiriyorduk. Harika! Peki, bu kadar güzelliğin üzerine GitOps neyi farklı yapıyor? Neden şimdi herkes GitOps konuşuyor? İşte tam da bu noktada, Git’in sadece uygulama kodumuz için değil, tüm altyapımız için de “tek doğruluk kaynağı” (single source of truth) haline geldiği o büyülü dünyaya adım atıyoruz. GitOps, altyapı yönetimini, yazılım geliştirme pratiklerinin en iyi yönleriyle birleştirerek, bize daha güvenilir, daha şeffaf ve daha hızlı bir yol sunuyor. Hazır olun, çünkü altyapınızın orkestra şefi artık Git!

GitOps Nedir? Orkestrayı Kim Yönetiyor?

GitOps’u anlamanın en güzel yolu, onu bir orkestra metaforuyla açıklamaktır. Hayal edin: Bir orkestra var ve bu orkestranın her bir üyesi (sunucular, veritabanları, ağ bileşenleri, Kubernetes Pod’ları) kendi enstrümanını çalıyor. Peki, bu koca orkestrayı kim yönetiyor? Tabii ki bir orkestra şefi! GitOps dünyasında bu şef, sizin Git deponuz (Git repository).

GitOps’un temel felsefesi üç ana sütun üzerine kuruludur:

  1. Deklaratif Tanımlama (Declarative Configuration): Altyapınızın mevcut durumunu değil, olması gereken durumunu tanımlarsınız. Yani, “şu sunucuyu kur” demek yerine, “şöyle bir sunucu olsun” dersiniz. Bu tanımlamalar, `YAML` veya `JSON` gibi deklaratif dillerle Git deponuzda saklanır. Git deponuz, orkestranın çalacağı notaların yazılı olduğu partisyon gibidir.
  2. Versiyonlama ve Değişiklik Takibi (Versioned and Tracked Changes): Altyapınızdaki her değişiklik, tıpkı uygulama kodunuzdaki gibi, Git üzerinde bir `commit` olarak kaydedilir. Bu, her an altyapınızın geçmişteki herhangi bir durumuna geri dönebileceğiniz (rollback) anlamına gelir. Ayrıca, kimin ne zaman, hangi değişikliği yaptığını kolayca takip edebilirsiniz. Bu, partisyonun her bir revizyonunun kaydedilmesi gibidir; her zaman önceki versiyonlara bakabilir, hatta hatalı bir notayı düzeltebilirsiniz.
  3. Otomatikleştirilmiş Senkronizasyon (Automated Synchronization): Git deponuzdaki deklaratif tanımlamalar ile canlı altyapınız arasındaki senkronizasyon sürekli olarak otomatik bir şekilde sağlanır. Yani, Git’teki partisyon değiştiğinde, orkestra (altyapı) bu yeni notaları otomatik olarak çalmaya başlar. Bu otomasyon, genellikle bir “operatör” veya “agent” tarafından gerçekleştirilir. Bu operatör, Git deponuzu sürekli izler ve herhangi bir değişiklik olduğunda, canlı altyapıyı Git’teki duruma getirmek için gerekli aksiyonları alır. Bu sayede, insan hatası riski minimuma iner ve dağıtım süreçleri hızlanır.

Özetle, GitOps ile altyapınızdaki tüm değişiklikler sadece Git deponuza bir `commit` ve `pull request` gönderilerek yapılır. Doğrudan canlı ortama müdahale etmek yerine, Git üzerinden dolaylı ve kontrollü bir şekilde hareket edersiniz. Bu, hem güvenliği artırır hem de denetlenebilirliği maksimize eder.

[Buraya GitOps Akışını Gösteren Bir Diyagram Ekleyebilirsiniz]

Neden Kubernetes ve GitOps Mükemmel Bir İkili?

Kubernetes, doğası gereği deklaratif bir sistemdir. `Deployment`, `Service`, `Pod` gibi kaynakları `YAML` dosyalarıyla tanımlar ve Kubernetes’e “benim altyapım böyle olsun” dersiniz. Kubernetes de bu deklaratif tanıma ulaşmak için elinden geleni yapar. İşte bu deklaratif yapı, GitOps ile Kubernetes’i adeta ruh ikizi haline getiriyor.

Geleneksel Kubernetes yönetiminde, geliştiriciler veya operasyon ekipleri genellikle `kubectl apply -f my-app.yaml` gibi komutlarla doğrudan cluster’a müdahale ederler. Bu yaklaşım, küçük ölçekli projelerde sorun yaratmasa da, büyük ve dinamik ortamlarda ciddi problemlere yol açabilir:

  • Drift (Sapma): Canlı cluster’daki durum ile `YAML` dosyalarınızdaki tanımlar arasında zamanla farklar oluşabilir. Birisi cluster’da manuel bir değişiklik yapar, ancak bu değişiklik Git’e yansımaz. Sonuç? “Benim makinemde çalışıyordu!” sendromunun altyapı versiyonu.
  • Denetlenebilirlik Eksikliği: Kimin ne zaman, hangi değişikliği yaptığını takip etmek zorlaşır. Güvenlik ve uyumluluk açısından büyük bir risk.
  • Manuel Hatalar: İnsan faktörü, özellikle stresli anlarda, hatalı komutların çalıştırılmasına ve kesintilere neden olabilir.

GitOps, bu sorunların hepsine zarif bir çözüm sunar. Git deponuz, Kubernetes cluster’ınızın tek ve nihai doğruluk kaynağıdır. Cluster’da bir değişiklik mi yapmak istiyorsunuz? Doğrudan `kubectl` kullanmak yerine, Git deponuzdaki ilgili `YAML` dosyasını günceller, bir `commit` yapar ve bir `pull request` açarsınız. Bu `pull request` incelenir, onaylanır ve `merge` edildiğinde, GitOps operatörü bu değişikliği algılar ve Kubernetes cluster’ınızı otomatik olarak yeni duruma getirir.

Bu sayede:

  • Drift ortadan kalkar: Cluster her zaman Git’teki durumu yansıtır.
  • Tam denetlenebilirlik sağlanır: Her değişiklik Git geçmişinde kayıtlıdır.
  • Manuel hatalar azalır: Dağıtım süreçleri otomatikleşir ve insan müdahalesi minimuma iner.
  • Geri alma (Rollback) kolaylaşır: Hatalı bir dağıtım durumunda, Git geçmişindeki önceki bir `commit`’e geri dönmek kadar kolaydır.

Kubernetes’in deklaratif API’si ve Git’in versiyon kontrol yetenekleri birleştiğinde, altyapı yönetimi, uygulama geliştirme kadar çevik, güvenilir ve tekrarlanabilir hale gelir.

Sahnenin Yıldızları: Popüler GitOps Araçları

GitOps felsefesini hayata geçirmek için birçok harika araç mevcut. İşte sahnenin en parlak yıldızlarından ikisi:

Argo CD

`Argo CD`, Kubernetes için deklaratif, `GitOps` tabanlı sürekli dağıtım (Continuous Delivery) aracıdır. En belirgin özelliği, “pull” tabanlı çalışma mantığıdır. Yani, `Argo CD` cluster’ınızda bir `agent` olarak çalışır ve sürekli olarak Git deponuzu izler. Git’teki tanımlar ile canlı cluster’daki durum arasında bir fark (drift) tespit ettiğinde, cluster’ı otomatik olarak Git’teki duruma senkronize eder.

`Argo CD`’nin öne çıkan özellikleri:

  • Pull-Based Dağıtım: Cluster’ın içinden Git deponuzu izler ve değişiklikleri çeker. Bu, güvenlik açısından avantajlıdır çünkü cluster’a dışarıdan erişim izni vermeniz gerekmez.
  • Zengin Web Arayüzü: `Argo CD`, dağıtılan uygulamalarınızın durumunu, senkronizasyon sağlığını ve geçmişini görsel olarak takip edebileceğiniz kullanıcı dostu bir web arayüzüne sahiptir. Bu arayüz, özellikle büyük ve karmaşık ortamlarda sorun giderme ve izleme için paha biçilmezdir.
  • Otomatik Senkronizasyon ve Sağlık Kontrolü: Git’teki değişiklikleri otomatik olarak algılar ve cluster’a uygular. Ayrıca, dağıtılan kaynakların sağlığını sürekli kontrol eder.
  • Rollback ve Roll-Forward: Hatalı dağıtımları kolayca geri alabilir veya yeni bir `commit` ile ileriye doğru düzeltebilirsiniz.
  • Çoklu Cluster Desteği: Birden fazla Kubernetes cluster’ını tek bir `Argo CD` örneği üzerinden yönetebilirsiniz.

Flux CD

`Flux CD`, `Cloud Native Computing Foundation` (CNCF) bünyesinde geliştirilen bir başka popüler GitOps aracıdır. `Argo CD` gibi, `Flux` da “pull” tabanlı bir yaklaşımla çalışır ve Git deponuzu tek doğruluk kaynağı olarak kabul eder. `Flux`, özellikle `kustomize` ve `Helm` gibi Kubernetes paketleme araçlarıyla güçlü entegrasyonlarıyla bilinir.

`Flux CD`’nin temel özellikleri:

  • Git-Merkezli Yaklaşım: `Flux`, Git deponuzu merkeze alır ve tüm dağıtım süreçlerini buradan yönetir.
  • CNCF Projesi: `CNCF` çatısı altında olması, projenin uzun vadeli sürdürülebilirliği ve topluluk desteği açısından güven verir.
  • Kustomize ve Helm Entegrasyonu: `kustomize` ile Kubernetes manifestlerini özelleştirebilir ve `Helm` ile uygulamaları kolayca paketleyip dağıtabilirsiniz. `Flux`, bu araçlarla sorunsuz bir şekilde entegre olur.
  • Operatör Modeli: Kubernetes cluster’ında çalışan bir dizi operatörden oluşur. Bu operatörler, Git deponuzu izler ve cluster’daki kaynakları senkronize eder.
  • Genişletilebilirlik: `Flux`, `notification-controller`, `image-reflector-controller` gibi çeşitli bileşenlerle genişletilebilir bir yapıya sahiptir.
  • Sürekli Senkronizasyon: Git deponuzdaki değişiklikleri algılar ve cluster’ı otomatik olarak günceller.

Her iki araç da GitOps felsefesini başarıyla uygulasa da, arayüz, özellik setleri ve topluluk yaklaşımları açısından farklılıklar gösterirler. Seçiminiz, projenizin ihtiyaçlarına ve ekibinizin tercihlerine göre değişebilir.

Altın Değerinde İpuçları ve En İyi Pratikler (Tips & Tricks)

GitOps yolculuğunuzda size rehberlik edecek birkaç altın değerinde ipucu ve en iyi pratik:

Repo Yapılandırması: Uygulama Kodu ve Altyapı/Konfigürasyon Repolarını Ayırın

GitOps’a başlarken yapılan yaygın hatalardan biri, uygulama kodu ile altyapı/konfigürasyon tanımlamalarını aynı Git deposunda tutmaktır. Bu, başlangıçta kolay gibi görünse de, zamanla karmaşıklığı artırır ve sorumlulukların bulanıklaşmasına neden olur. En iyi pratik, bu iki alanı ayrı depolarda yönetmektir:

  • Uygulama Kodu Reposu: Sadece uygulamanızın kaynak kodunu, testlerini ve `Dockerfile` gibi uygulama özel dosyalarını içerir.
  • Altyapı/Konfigürasyon Reposu (Config Repo): Kubernetes manifestleri (`Deployment`, `Service`, `Ingress` vb.), `Helm` chart’ları, `kustomize` dosyaları ve diğer altyapı tanımlamalarını içerir.

Bu ayrım, “App-of-apps pattern” olarak da bilinir ve birçok fayda sağlar:

  • Sorumluluk Ayrımı: Geliştiriciler uygulama koduna, operasyon ekipleri ise altyapı konfigürasyonlarına odaklanabilir.
  • Daha Hızlı Dağıtım: Uygulama kodu değiştiğinde sadece uygulama `CI/CD` pipeline’ı tetiklenir. Altyapı değiştiğinde ise sadece GitOps pipeline’ı çalışır.
  • Gelişmiş Güvenlik: Uygulama koduna erişimi olan herkesin altyapı konfigürasyonlarını değiştirmesini engeller.
  • Daha Temiz Git Geçmişi: Her deponun kendi alanına özel, anlamlı `commit` geçmişi olur.

Gizli Bilgilerin (Secrets) Yönetimi: Git’te Şifreli Saklayın

GitOps’un temel prensibi, her şeyin Git’te olmasıdır. Ancak bu, veritabanı şifreleri, API anahtarları gibi hassas bilgileri (secrets) açık metin olarak Git’e koymanız gerektiği anlamına gelmez. Bu, büyük bir güvenlik açığıdır! `Secrets` yönetimi, GitOps’un en kritik ve dikkatli olunması gereken alanlarından biridir.

Çözüm, `secrets`’ları Git’te şifreli olarak saklamak ve sadece Kubernetes cluster’ında deşifre edilmesini sağlamaktır. Bu amaçla kullanabileceğiniz popüler araçlar şunlardır:

  • Sealed Secrets: `Bitnami` tarafından geliştirilen bu araç, `secrets`’larınızı Kubernetes cluster’ınızın anahtarlarıyla şifrelemenizi sağlar. Şifrelenmiş `secret`’ı Git’e `commit` edersiniz ve `Sealed Secrets` operatörü, cluster’da bu `secret`’ı deşifre ederek normal bir Kubernetes `Secret` objesine dönüştürür. Bu sayede, `secret`’lar Git’te güvenli bir şekilde saklanırken, sadece yetkili cluster’lar tarafından kullanılabilir.
  • HashiCorp Vault: Daha gelişmiş ve merkezi bir `secret` yönetimi çözümü arıyorsanız, `Vault` harika bir seçenektir. `Vault`, `secrets`’ları güvenli bir şekilde depolar ve Kubernetes cluster’ınızdaki uygulamaların bu `secrets`’lara erişmesini sağlar. `Vault` entegrasyonu genellikle `Vault Agent Injector` veya `External Secrets Operator` gibi araçlarla yapılır.

Unutmayın, `secrets`’ları asla açık metin olarak Git’e koymayın!

Pull Request (PR) Kültürü: Her Değişiklik Bir İncelemeden Geçsin

GitOps, sadece araçlardan ibaret değildir; aynı zamanda bir kültürdür. Bu kültürün merkezinde ise Pull Request (PR) mekanizması yer alır. Altyapınızda yapacağınız her değişiklik, küçük veya büyük olsun, bir `pull request` aracılığıyla yapılmalıdır.

`PR` kültürü, size şu faydaları sağlar:

  • Kod İncelemesi (Code Review): Her değişiklik, ekip üyeleri tarafından incelenir. Bu, hataların erken aşamada yakalanmasını, en iyi pratiklerin uygulanmasını ve bilgi paylaşımını teşvik eder.
  • Denetlenebilirlik ve Onay Süreci: `PR`’lar, değişikliklerin ne zaman, kim tarafından ve hangi amaçla yapıldığını gösteren resmi bir kayıt tutar. Ayrıca, değişikliklerin canlı ortama uygulanmadan önce onaylanması gereken bir süreç oluşturur. Bu, özellikle uyumluluk gereksinimleri olan sektörler için hayati öneme sahiptir.
  • İşbirliği ve Bilgi Paylaşımı: `PR`’lar, ekip üyelerinin birbirlerinin çalışmalarından haberdar olmasını ve altyapı hakkında ortak bir anlayış geliştirmesini sağlar.
  • Otomatik Testler: `PR`’lar, otomatik testlerin (linting, statik analiz, entegrasyon testleri) tetiklenmesi için mükemmel bir noktadır. Bu testler, değişikliklerin kalitesini ve güvenliğini artırır.

Her `commit` bir `PR`’a, her `PR` bir incelemeye ve her `merge` bir otomatik dağıtıma dönüşmelidir. Bu döngü, GitOps’un gücünü tam anlamıyla ortaya çıkarır.

Sonuç

GitOps, altyapı yönetimini, yazılım geliştirme dünyasının en iyi pratikleriyle buluşturan, devrim niteliğinde bir yaklaşımdır. Artık altyapınız, tıpkı uygulama kodunuz gibi, versiyonlanabilir, denetlenebilir ve otomatikleştirilebilir bir varlık haline geliyor. Git deponuz, altyapınızın tek doğruluk kaynağı olurken, `Argo CD` ve `Flux CD` gibi araçlar, bu vizyonu gerçeğe dönüştürmek için sahnedeki yerlerini alıyor.

Unutmayın, GitOps sadece bir araç seti değildir; aynı zamanda bir kültürdür. Deklaratif tanımlamalar, versiyon kontrolü ve sürekli otomasyon prensiplerini benimseyerek, ekipleriniz daha güvenilir, daha şeffaf ve daha verimli bir şekilde çalışabilir. Altyapınızdaki “drift” kabusuna son verin, manuel hataları minimuma indirin ve geliştirici verimliliğini artırın.

Eğer henüz GitOps dünyasına adım atmadıysanız, şimdi tam zamanı! Kubernetes ile olan mükemmel uyumu sayesinde, bulut yerel uygulamalarınızı yönetme şeklinizi kökten değiştirecek bu felsefeyi keşfetmekten çekinmeyin. Altyapınızın orkestra şefliğini Git’e devredin ve müziğin hiç durmamasını sağlayın!

Bir sonraki yazıda görüşmek üzere, kodunuz bol, sunucularınız stabil olsun!

Category: Genel | LEAVE A COMMENT
Mayıs 28 2026

30 Yaş Sonrası Kas Kaybına Savaş: Hücresel Yaşlanmayı Geciktiren Direnç Antrenmanları

30 mumlu o doğum günü pastasını üflediğimiz an, vücudumuzda sessiz sedasız bir şeyler değişmeye başlar. Hayır, bir gecede yaşlanmıyoruz tabii ki ama biyolojik saatimiz vites değiştiriyor. Bilim insanlarının “sarkopeni” dediği yaşa bağlı kas kaybı, tam da bu dönemde kapımızı çalar. Ancak panik yapmaya gerek yok; sarkopeni önleme sandığınızdan daha eğlenceli ve dinamik bir yolla mümkün. Hücresel yaşlanmayı geciktirmenin, metabolizmayı canavar gibi çalıştırmanın ve geleceğe yatırım yapmanın sırrı, o çok göz korkutan ağırlık çalışması seanslarında saklı.

Kertenkerem.net olarak bu yazıda, “Neden 30’dan sonra her şey daha zor?” sorusunun yanıtını arayacak ve sizi birer fitness salonu müdavimi yapmadan, evde veya salonda uygulayabileceğiniz bilimsel bir yol haritası sunacağız.

Sarkopeni Nedir ve Neden 30’dan Sonra Başlar?

Neden böyle oluyor? Doğa neden bize düşman? Aslında düşman değil, sadece tasarruflu. Vücudumuz son derece pragmatik bir organdır. Kullanılmayan her şeyi “gereksiz yük” olarak görür ve elden çıkarır. 30 yaşından sonra, hormonal seviyelerdeki (özellikle büyüme hormonu ve testosteron) doğal düşüşle birlikte, vücut kas kütlesini korumakta zorlanmaya başlar.

Araştırmalar gösteriyor ki, 30 yaşından sonra her on yılda ortalama %3 ila %8 oranında kas kütlesi kaybediyoruz. Eğer hareketsiz bir yaşam sürüyorsak, bu kayıp çok daha dramatik boyutlara ulaşıyor. Kas kaybı sadece kollarımızın sarkması demek değil; yavaşlayan bir metabolizma, azalan kemik yoğunluğu ve dolayısıyla erken yaşlanma anlamına geliyor.

Direnç Antrenmanı Faydaları: Hücresel Düzeyde Gençleşme

Peki, çözüm ne? Sadece kardiyo yapmak (koşmak, yürümek) kalp sağlığımız için harikadır ama kas kaybını durdurmakta yetersiz kalır. İşte burada devreye direnç antrenmanı faydaları giriyor. Direnç antrenmanı, kasları yerçekimine veya harici bir ağırlığa karşı çalışmaya zorlayan her türlü egzersizdir.

Bilimsel araştırmalar gösteriyor ki, ağırlık çalışmak hücrelerimizin enerji santralleri olan mitokondrileri gençleştiriyor. Kaslar kasıldığında, vücut “miyokin” adı verilen ve beyinden bağışıklık sistemine kadar tüm vücutta anti-enflamatuar (iltihap karşıtı) etkiler yaratan kimyasallar salgılar. Yani ağırlık kaldırmak, aslında hücrelerinize “Hâlâ hayattayız ve savaşmaya devam ediyoruz!” mesajı göndermektir. Bu yüzden uzun yaşam spor trendlerinin merkezinde artık maraton koşuları değil, akıllıca planlanmış ağırlık antrenmanları yer alıyor.

Önemli Uyarı: Eğer kronik bir rahatsızlığınız (özellikle fıtık, eklem problemleri veya kalp rahatsızlığı) varsa, yeni bir ağırlık antrenmanı programına başlamadan önce mutlaka uzman bir hekime danışmalısınız. Egzersizleri doğru formda yapmak sakatlanmaları önler.

Haftalık Direnç Antrenmanı Nasıl Planlanır?

Gözünüz korkmasın. Haftada 5 gün saatlerce ağırlık kaldırmak zorunda değilsiniz. Uzun vadeli ve sürdürülebilir bir plan, her zaman en vahşi plandan daha iyidir. İşte hücresel yaşlanmayı yavaşlatacak eyleme geçirilebilir bir haftalık planlama rehberi:

1. Bileşik Hareketlere (Compound Exercises) Odaklanın

Tek bir kas grubunu izole eden hareketler yerine, aynı anda birden fazla eklemi ve kas grubunu çalıştıran hareketleri seçin. Bunlar vücudun en çok hormon salgılamasını sağlayan hareketlerdir.

  • Squat (Çömelme): Bacak, kalça ve core bölgesini çalıştırır.
  • Push-up (Şınav) / Bench Press: Göğüs, omuz ve arka kolu hedefler.
  • Rowing (Kürek): Sırt ve pazu kaslarını güçlendirir.

2. Progresif Aşırı Yükleme (Progressive Overload) Uygulayın

Kaslarınızın gelişmeye ve adaptasyon sağlamaya devam etmesi için onları zamanla daha fazla zorlamalısınız. Her hafta aynı 5 kiloluk dambılı kaldırmak bir süre sonra fayda sağlamaz. Ağırlığı milimetrik olarak artırın, tekrar sayısını çoğaltın veya hareketler arasındaki dinlenme süresini kısaltın.

3. Haftalık Programınızı Sade Tutun

Haftada 2 veya 3 gün, tüm vücudu (Full Body) hedefleyen 40-45 dakikalık seanslar başlangıç için mükemmeldir. Aşağıdaki basit haftalık şablonu bilgisayarınıza veya telefonunuza kaydedebilirsiniz:


# kertenkerem.net Haftalık Direnç Planı
PAZARTESİ: Tüm Vücut (Squat + Şınav + Dumbbell Row) -> 3 set x 10 tekrar
ÇARŞAMBA : Dinlenme veya Hafif Yürüyüş
CUMA     : Tüm Vücut (Lunge + Overhead Press + Plank) -> 3 set x 12 tekrar
PAZAR    : Aktif Dinlenme (Mobilite ve Esneme)

Özet: Gelecekteki Kendinize Bir İyilik Yapın

Yaşlanmak kaçınılmaz bir biyolojik süreçtir ancak nasıl yaşlanacağımız büyük oranda bizim elimizde. Kaslarımız, bizim yaşlılık sigortamızdır. Bugün yapacağınız bilinçli bir ağırlık çalışması, 70’li yaşlarınızda merdivenleri tek başınıza çıkabilmenizi, torunlarınızla rahatça oynayabilmenizi ve metabolizmanızın tıkır tıkır çalışmasını sağlayacak.

Harekete geçmek için mükemmel anı beklemeyin. Kendi vücut ağırlığınızla yapacağınız basit bir şınav ve squat serisiyle bugün başlayın. Unutmayın, en iyi antrenman, yapılan antrenmandır!

Category: Genel | LEAVE A COMMENT
Mayıs 28 2026

Kendi Lokalinizde LLM Çalıştırmak: Ollama Kurulum Rehberi

Yapay zeka hayatımızın merkezine oturdu ama her sorduğumuz sorunun OpenAI veya Google sunucularına gitmesi canınızı sıkmıyor mu? İşte tam bu noktada local llm (yerel büyük dil modeli) kavramı devreye giriyor. Tamamen kendi bilgisayarınızda çalışan, internete ihtiyaç duymayan ve en önemlisi privacy (gizlilik) endişelerinizi sıfıra indiren bir yapay zeka deneyimi artık hayal değil. Bu rehberde, bu işi çocuk oyuncağı haline getiren ollama aracını mercek altına alıyor, Mac ve Linux sistemlerimizde llama, mistral gibi canavarları nasıl koşturacağımızı adım adım inceliyoruz.

Neden Bulut Değil de Local LLM?

ChatGPT veya Claude kullanırken aslında verilerimizi sürekli uzak sunuculara kiralıyoruz. Şirket sırları, kişisel günlükler veya üzerinde çalıştığınız yeni bir startup fikri… Hepsi birilerinin veri merkezinde işleniyor. Kendi bilgisayarınızda bir yapay zeka çalıştırmak ise size tam bir veri egemenliği sunar.

Bunun yanında, “Çevrimdışı çalışabilme” lüksü de cabası. Metroda, uçakta ya da internetin çekmediği bir kamp alanında, kod yazarken takıldığınız bir yeri yapay zekaya sorabildiğinizi hayal edin. Üstelik API ücreti yok, aylık abonelik derdi yok. Bilgisayarınızın elektriği ve donanımı yettiği sürece sınırsız kullanım hakkına sahipsiniz.

Ollama Nedir ve Ne İşe Yarar?

Eskiden lokalde model çalıştırmak tam bir işkenceydi. Hugging Face’ten gigabaytlarca dosya indirmeniz, doğru Python kütüphanelerini (PyTorch, llama.cpp vb.) kurmanız ve uyumluluk sorunlarıyla boğuşmanız gerekirdi. Ollama, bu karmaşayı tek bir satır kodla çözen harika bir araç. Kendisini yapay zeka modellerinin “Docker”ı olarak düşünebilirsiniz. Modelleri paketler, yönetir ve sisteminizde optimize bir şekilde çalıştırır.

[Görsel: Ollama logosu ve terminalde koşan şık, minimalist bir model çalıştırma ekranı]

Adım Adım Ollama Kurulumu

Lafı fazla uzatmadan işe koyulalım. Biz bu rehberde Mac ve Linux odaklı gideceğiz ancak Ollama’nın artık resmi bir Windows desteği de sunduğunu belirtelim.

macOS Kurulumu

Mac kullanıcıları için süreç inanılmaz derecede basit. Eğer sisteminizde Homebrew kuruluysa terminali açıp şu komutu yazmanız yeterli:

brew install ollama

Alternatif olarak, Ollama’nın resmi web sitesinden direkt bir `.dmg` dosyası indirip uygulamalar klasörünüze de sürükleyebilirsiniz.

Linux Kurulumu

Linux severler için ise tek satırlık bir script yeterli oluyor. Terminalinizi açın ve aşağıdaki komutu yapıştırın:

curl -fsSL https://ollama.com/install.sh | sh

İlk Modeli Ayaklandırmak: Llama 3, Mistral ve Phi-3

Kurulum bittiğine göre şimdi motoru çalıştırma zamanı. Ollama kütüphanesinde kullanabileceğimiz onlarca model var. Biz en popüler üç tanesini test ettik:

  • Llama 3 (8B): Meta’nın geliştirdiği, genel yetenekleri ve Türkçe anlama kapasitesi oldukça yüksek olan amiral gemisi.
  • Mistral (7B): Fransız menşeili Mistral AI tarafından geliştirilen, özellikle kodlama ve mantık yürütmede boyutuna göre devleşen bir model.
  • Phi-3 (3.8B): Microsoft’un “küçük ama zehir gibi” modeli. Düşük sistem kaynakları için ideal.

Gelin, hemen Meta’nın llama 3 modelini indirelim ve çalıştıralım:

ollama run llama3

Bu komutu verdiğinizde Ollama önce yaklaşık 4.7 GB boyutundaki modeli arka planda indirecek, ardından terminalinizi interaktif bir chat ekranına dönüştürecektir.

[Görsel: Terminal ekranında Ollama üzerinden Llama 3 modeline ‘Merhaba, bana yerel bir yapay zekanın avantajlarını anlat’ sorusunun sorulduğu ve saniyeler içinde alınan yanıtın ekran görüntüsü]

Deneyim ve Raporlama: Gerçekten Hızlı mı?

Lafı dolandırmayalım, doğrudan test sonuçlarımızı paylaşalım. Testi gerçekleştirdiğimiz makine: M1 MacBook Air (16 GB RAM).

Llama 3 (8B) modeline Türkçe bir soru sorduğumuzda aldığımız hız yaklaşık saniyede 15-18 token civarındaydı. Bu hız, rahatça okuyabileceğinizden daha hızlı bir şekilde metnin ekrana akması demek. Microsoft’un Phi-3 modelinde ise bu hız saniyede 30-35 token seviyelerine fırladı. Yani GPU olmadan, sadece Apple Silicon işlemcinin gücüyle bile akıcı bir deneyim elde etmek son derece mümkün.

Terminalden Sıkılanlara: Open WebUI Entegrasyonu

Terminal ekranında yapay zekayla sohbet etmek havalı görünse de, uzun vadede ChatGPT benzeri, sohbet geçmişini tutan, temiz bir arayüz arıyoruz. İşte burada imdadımıza Open WebUI yetişiyor.

Open WebUI’ı bilgisayarınızda çalıştırmanın en temiz yolu Docker kullanmaktır. Eğer bilgisayarınızda Docker kuruluysa, terminale şu komutu yazarak arayüzü başlatabilirsiniz:

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

Bu işlemden sonra tarayıcınızı açıp http://localhost:3000 adresine gittiğinizde, yerel ağınızda çalışan şık bir ChatGPT klonuyla karşılaşacaksınız. Üstelik Ollama ile indirdiğiniz tüm modeller sol üstteki açılır menüde otomatik olarak belirecektir.

[Görsel: Open WebUI arayüzünün karanlık modda çekilmiş ekran görüntüsü. Sol tarafta sohbet geçmişi, ortada ise Llama 3 ile yapılan Türkçe bir sohbet görünüyor.]

GPU Olmadan Performans Optimizasyonu Nasıl Yapılır?

Eğer güçlü bir ekran kartınız (NVIDIA RTX serisi gibi) veya bir Apple Silicon Mac’iniz yoksa, saf CPU gücüyle LLM çalıştırmak bilgisayarınızı biraz terletebilir. Ancak pes etmenize gerek yok, işte uygulayabileceğiniz optimizasyon adımları:

  1. Kuantize (Quantized) Modeller Seçin: Ollama varsayılan olarak modellerin 4-bit kuantize edilmiş sürümlerini indirir. Bu, modelin beynini (ağırlıklarını) biraz küçültmek ama zekasından çok az ödün vererek RAM kullanımını 1/4 oranına düşürmek demektir. Ekstra bir şey yapmanıza gerek yok, Ollama bunu sizin yerinize zaten yönetiyor.
  2. Küçük Modellere Yönelin: 8B (8 milyar parametre) yerine 3B veya 1.5B parametreli modelleri tercih edin. Örneğin ollama run phi3 veya ollama run gemma:2b düşük RAM’li bilgisayarlar için biçilmiş kaftandır.
  3. Arka Plan Uygulamalarını Kapatın: Yerel LLM çalıştırırken en kritik kaynak RAM’dir. Docker ve Ollama çalışırken özellikle RAM canavarı tarayıcı sekmelerini kapatmak performansı gözle görülür şekilde artırır.

Ollama: Artılar ve Eksiler

Kendi deneyimlerimiz doğrultusunda hazırladığımız dürüst tabloya göz atalım:

Artıları (+) Eksileri (-)
Tamamen ücretsiz ve açık kaynak kodlu. Çok büyük modeller (70B+) için aşırı güçlü donanım ister.
%100 gizlilik ve internet gerektirmeyen çalışma yapısı. Mobil cihazlarda doğrudan çalıştırmak (henüz) pratik değil.
Tek satırla model indirme ve güncelleme kolaylığı. Modeller geliştikçe diskte ciddi yer kaplıyorlar.
Aktif topluluk desteği ve harika API entegrasyonu. Türkçe dil desteği GPT-4 seviyesinde değil ama tatminkar.

Fiyat ve Ücretsiz Alternatifler

Ollama tamamen ücretsizdir. Kullandığınız modeller de açık kaynaklı olduğu için herhangi bir lisans ücreti ödemezsiniz.

Eğer Ollama’nın terminal tabanlı yapısı size hitap etmediyse, alternatif olarak şu tamamen ücretsiz araçları da deneyebilirsiniz:

  • LM Studio: Görsel bir arayüze sahip, modelleri arayıp tek tıkla indirebileceğiniz ve yerel sunucu kurabileceğiniz harika bir masaüstü uygulaması (Mac/Windows/Linux).
  • Jan.ai: Tamamen açık kaynaklı, şık arayüzlü bir başka yerel LLM istemcisi.

Kendi local LLM dünyanızı kurmak işte bu kadar kolay. Terminali açın, Ollama’yı kurun ve yapay zekanın kontrolünü kendi ellerinize alın. Bir sonraki rehberde görüşmek üzere!

Category: Genel | LEAVE A COMMENT
Mayıs 27 2026

Git Commit Çöplüğüne Son: CI/CD Pipeline Süreçlerini Yerelde Test Etme Yöntemleri

Yazım hatası yüzünden patlayan bir build. Arkasından gelen “fix typo” commit’i. O da yemedi; “fix syntax again”, “please work”, “test 4” ve nihayetinde “really fix this time”. Tanıdık geldi mi? Reponun commit geçmişini adeta bir çöplüğe çeviren bu döngü, yalnızca estetik bir problem değil. Her push işleminde buluttaki runner’ın ayağa kalkmasını beklemek, saatlik faturaları şişirmek ve geri bildirim döngüsünü (feedback loop) dakikalarca uzatmak demektir. Profesyonel bir SRE veya DevOps mühendisi için bu kabul edilemez bir zaman kaybıdır.

Bu pratik rehberde, commit-push-wait döngüsünden kurtulup yerel pipeline testi (local cicd testing) süreçlerini nasıl profesyonelce kurgulayacağımızı ele alacağız. GitHub Actions ve GitLab CI pipeline’larınızı, uzak sunuculara hiç dokunmadan, doğrudan kendi terminalinizde nasıl simüle edeceğinizi gerçek senaryolarla inceleyeceğiz.

Neden Yerelde Test Etmeliyiz? (The SRE Perspective)

Bunu sadece “temiz git geçmişi” motivasyonuyla açıklamıyoruz. Altında yatan asıl nedenler tamamen operasyonel verimlilik ve güvenlikle ilgilidir:

  • Hızlı Geri Bildirim Döngüsü: Buluttaki bir runner’ın kuyrukta beklemesi, imajı çekmesi ve init olması ortalama 1-3 dakika sürer. Yerelde bu süre saniyeler mertebesindedir.
  • Maliyet Optimizasyonu: GitHub Actions veya GitLab CI faturalarınızın önemli bir kısmı, aslında “deneme-yanılma” aşamasındaki başarısız run’lardan kaynaklanır.
  • Güvenli Secret Yönetimi: Yeni bir entegrasyonu denerken production secret’larını ya da hassas API anahtarlarını geçici olarak buluttaki CI ortamına eklemek her zaman güvenlik riski barındırır.

—

GitHub Actions’ı Yerelde Koşturmak: act

GitHub Actions workflow’larını yerel makinede çalıştırmanın fiili standardı act aracıdır. `act`, lokalinizdeki Docker daemon’ını kullanarak GitHub’ın runner ortamlarını simüle eden container’lar ayağa kaldırır ve tanımladığınız adımları bu container’lar içinde çalıştırır.

act Kurulumu ve Temel Kullanımı

Kurulumu macOS işletim sistemlerinde Homebrew ile hızlıca yapabilirsiniz:

brew install nektos/tap/act

Eğer Linux kullanıyorsanız, doğrudan binary olarak çekebilirsiniz:

curl -s https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash

Gerçekçi Bir Senaryo: Secret’lar ve Matrix Yapıları

Diyelim ki elinizde node.js uygulamasını test eden ve deploy etmeden önce bir API anahtarına ihtiyaç duyan aşağıdaki gibi bir `.github/workflows/ci.yml` dosyanız var:

name: Node.js CI

on:
  push:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18.x, 20.x]
    steps:
      - uses: actions/checkout@v3
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test
        env:
          DATABASE_URL: ${{ secrets.DATABASE_URL }}

Bu workflow’u yerelde çalıştırmak istediğinizde doğrudan `act` komutunu vermeniz yetmez; çünkü `secrets.DATABASE_URL` boş kalacaktır ve matrix yapısı yüzünden süreç uzayacaktır. İşte tam bu noktada profesyonel parametreler devreye giriyor.

Öncelikle bir `.secrets` dosyası oluşturun:

DATABASE_URL=mongodb://localhost:27017/test_db

Şimdi sadece Node 20 versiyonunu ve sadece `test` job’ını tetiklemek, üstelik bunu yaparken de yerel secret dosyamızı beslemek için şu komutu koşturuyoruz:

act -j test --matrix node-version:20.x --secret-file .secrets

In-depth Tip: Runner Boyutu Sorunsalı

`act` ilk çalıştığında size hangi imaj boyutunu kullanmak istediğinizi sorar (Micro, Medium, Large). Varsayılan “Micro” imaj genelde hızlı iner ancak içinde `curl`, `docker`, `aws-cli` gibi temel araçları barındırmaz. Gerçekçi bir act github actions deneyimi için en azından “Medium” imajı seçmeli veya `.actrc` dosyanıza şu custom imaj eşlemesini eklemelisiniz:

-P ubuntu-latest=catthehacker/ubuntu:act-latest

—

GitLab CI Pipeline’larını Yerelde Simüle Etmek

GitLab tarafında işler biraz daha karmaşıktır. Resmi `gitlab-runner exec` komutu uzun süredir “deprecated” durumdadır ve `needs`, `parent-child pipelines` veya modern `artifacts` tanımlamalarını tam olarak desteklemez. SRE topluluğu bu boşluğu doldurmak için harika bir açık kaynaklı alternatif geliştirdi: gitlab-ci-local.

gitlab-ci-local Kurulumu

NodeJS tabanlı bu CLI aracını sisteminize kurmak için NPM veya Homebrew kullanabilirsiniz:

brew install firecow/gitlab-ci-local/gitlab-ci-local

Uygulama: Kompleks Bir .gitlab-ci.yml Testi

Şöyle bir pipeline yapımız olduğunu düşünelim. Uygulamayı derliyor, artifact üretiyor ve bir sonraki stage’de bu artifact’i kullanıyor:

stages:
  - build
  - test

compile-code:
  stage: build
  image: node:20-alpine
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

run-unit-tests:
  stage: test
  image: node:20-alpine
  needs: ["compile-code"]
  script:
    - ls dist/
    - npm run test:unit

Bu pipeline’ı `gitlab-runner local` mantığıyla kendi makinenizde çalıştırmak için terminalden şu komutu vermeniz yeterlidir:

gitlab-ci-local

`gitlab-ci-local`, projenizin kök dizinindeki `.gitlab-ci.yml` dosyasını analiz eder, adımları sırasıyla çalıştırır, `needs` direktifine sadık kalır ve en önemlisi üretilen `dist/` klasörünü lokalinizdeki `.gitlab-ci-local/artifacts/` klasörüne otomatik olarak map eder. Böylece build artifact’lerinin bir sonraki job’a düzgün aktarılıp aktarılmadığını gözlerinizle görebilirsiniz.

Yerel GitLab Variable’larını Yönetmek

Gerçek CI ortamında GitLab UI üzerinden tanımladığınız “masked/protected” değişkenleri yerelde taklit etmek için `.gitlab-ci-local-variables.yml` adında bir dosya oluşturabilirsiniz:

STAGING_KUBE_TOKEN: "kube-token-12345"
DB_PASSWORD: "super-secret-password"

Bu dosya `.gitignore` listenizde olmalıdır. Araç, bu değişkenleri otomatik olarak okuyacak ve container’ların içerisine enjekte edecektir.

—

Docker-in-Docker (DinD) ve Soket Paylaşımı Çıkmazı

Yerel pipeline testlerinde en çok baş ağrıtan konulardan biri, pipeline adımının kendisinin de Docker ayağa kaldırmaya çalışmasıdır (örneğin, entegrasyon testleri için geçici bir DB container’ı başlatmak veya imajı `docker build` ile derlemek).

Eğer `act` kullanıyorsanız ve job’ınız içinde Docker komutları koşturacaksanız, lokalinizdeki Docker soketini container içine mount etmeniz gerekir:

act --bind-workdir -v /var/run/docker.sock:/var/run/docker.sock

Benzer şekilde, `gitlab-ci-local` kullanırken `services: – docker:dind` tanımınız varsa, aracın konfigürasyonunda yerel soketin paylaşıldığından emin olun. Bu sayede iç içe (nested) container yapısı yerine, tüm container’ların sizin host Docker daemon’ınız üzerinde “sibling” (kardeş) container’lar olarak ayağa kalkmasını sağlarsınız. Bu, hem disk alanından tasarruf sağlar hem de performansı katlar.

—

Özet ve Best Practice’ler

Süreci bir standarta oturtmak adına ekibinize şu kuralları aşılamanızı öneririz:

  1. Pre-commit Hook Entegrasyonu: Kritik CI script değişikliklerinde, geliştiricilerin lokalde en azından bir `act` veya `gitlab-ci-local` kuru testi yapmasını zorunlu tutun.
  2. Maksimum İmaj Önbellekleme (Caching): Lokal testlerin hızlı olması için Docker imajlarını yerelde optimize edin. Sık kullanılan base imajları (`node`, `python`, `golang` alpine versiyonları) önceden `docker pull` ile çekin.
  3. Lokal .env/.secrets Dosyalarını Asla Push Etmeyin: Güvenlik en katı kuraldır. `.gitignore` dosyanızda yerel pipeline testlerinde kullandığınız tüm taklit secret dosyalarının tanımlı olduğundan emin olun.

Geliştirme hızınızı (velocity) artırmak ve CI bütçelerini optimize etmek tamamen feedback loop süresini kısaltmaktan geçiyor. Araçlarınızı doğru yapılandırın, lokal gücü kullanın ve o commit çöplüğünü tarihe gömün.

Category: Genel | LEAVE A COMMENT
Mayıs 27 2026

Baharatların Dansı: Evde Restoran Usulü Hint Usulü Butter Chicken

Dışarıda yediğiniz o yumuşacık, sosu ekmek banmalık Hint yemekleri gözünüzü korkutmasın. Bugün mutfakta kendinizi bir şef gibi hissettirecek, sırrı marinasyonda saklı nefis bir butter chicken tarifi ile karşınızdayız. Giriş seviyesinde bir yemek meraklısı olsanız bile, doğru adımlarla evde Hint mutfağı rüzgarları estirmek sandığınızdan çok daha kolay ve kesinlikle sipariş vermekten daha keyifli. Hadi, baharatların o büyüleyici dünyasına adım atalım ve mutfağı mis gibi kokutalım!

Porsiyon: 4 Kişilik
Hazırlık Süresi: 20 dakika (Marinasyon için ekstra minimum 30 dakika)
Pişirme Süresi: 25 dakika

Neden Butter Chicken? (Murgh Makhani)

Butter chicken, ya da orijinal adıyla Murgh Makhani, Hint mutfağının dünyaya sunduğu en büyük hediyelerden biri. Neden mi bu kadar seviliyor? Çünkü acı ile kremsi dokunun, asit ile yağın mükemmel dengesini sunuyor. Tavuklar yoğurtla marine edildiği için lokum gibi yumuşuyor, sosundaki tereyağı ve krema ise baharatların o keskin köşelerini yumuşatarak damakta adeta bir şölen yaratıyor. Bu dengeli lezzet profili, onu Hint yemekleri dünyasına giriş yapmak isteyenler için en ideal tarif haline getiriyor.

Gerekli Malzemeler

Malzeme listesi gözünüzü korkutmasın; çoğu zaten dolabınızda olan, bulamadıklarınızı da kolayca ikame edebileceğiniz şeyler. Örneğin kaju alerjiniz varsa kullanmayabilir, tavuk but yerine tavuk göğsü de tercih edebilirsiniz.

Marinasyon İçin:

  • Tavuk: 700 gram kemiksiz tavuk but (göğüs eti de olur ama but eti çok daha sulu ve lezzetli kalacaktır)
  • Yoğurt: 4 yemek kaşığı süzme yoğurt (tavuğu yumuşatan sihirli asit kaynağımız)
  • Sarımsak ve Zencefil: 1’er yemek kaşığı rendelenmiş (Hint yemeklerinin olmazsa olmaz ikilisi)
  • Limon suyu: 1 yemek kaşığı
  • Baharatlar: 1 tatlı kaşığı toz kırmızı biber, 1 çay kaşığı zerdeçal, 1 tatlı kaşığı garam masala, 1 çay kaşığı tuz

Sos İçin (Gravy):

  • Tereyağı: 2 yemek kaşığı (veya tereyağının Hint versiyonu olan ghee)
  • Sıvı yağ: 1 yemek kaşığı (tereyağının yanmasını önlemek için)
  • Soğan: 1 adet büyük boy (piyazlık doğranmış)
  • Domates: 4 adet rendelenmiş (veya pratiklik açısından 1 kutu domates püresi)
  • Kaju: 10-12 adet çiğ kaju (sosu koyulaştırır ve orijinal bir kremsilik katar, yoksa yerine krema miktarını artırabilirsiniz)
  • Krema: Yarım su bardağı sıvı krema (heavy cream)
  • Baharatlar: 1 tatlı kaşığı toz kırmızı biber, 1 tatlı kaşığı garam masala, 1 çay kaşığı kimyon, 1 tatlı kaşığı şeker (asiditeyi dengelemek için)

Adım Adım Butter Chicken Yapılışı

Adımları sırayla takip ettiğinizde her şeyin ne kadar pratik ilerlediğini göreceksiniz. İşte evde Hint mutfağı deneyiminin aşamaları:

  1. Tavukları Marine Edin: Doğranmış tavukları yoğurt, sarımsak, zencefil, limon suyu ve baharatlarla iyice harmanlayın. Buzdolabında en az 30 dakika (vaktiniz varsa 2 saat) dinlenmeye bırakın.
  2. Tavukları Mühürleyin: Geniş bir tavada 1 yemek kaşığı tereyağı ve sıvı yağı kızdırın. Tavukları yüksek ateşte, dışı hafifçe karamelize olana kadar (yaklaşık 5-7 dakika) pişirin ve kenara alın. (İçinin tam pişmesine gerek yok, sosta pişecek).
  3. Sos Tabanını Hazırlayın: Aynı tavaya biraz daha yağ ekleyin. Soğanları yumuşayana kadar soteleyin. Ardından sarımsak, zencefil ve kalan baharatları ekleyip kokusu çıkana kadar 1-2 dakika kavurun.
  4. Domates ve Kajuyu Ekleyin: Domates püresini ve kajuları tavaya ilave edin. Kısık ateşte domatesler suyunu çekip koyulaşana kadar yaklaşık 10 dakika pişmeye bırakın.
  5. Pürüzsüzleştirin (En Önemli Adım!): Hazırladığınız bu sos karışımını ocaktan alın. El blenderı yardımıyla tamamen pürüzsüz, kadife gibi bir kıvama gelene kadar çekin. (Gerekirse sosu açmak için yarım çay bardağı sıcak su ekleyebilirsiniz).
  6. Buluşma Zamanı: Pürüzsüz sosu tekrar tavaya alın. Üzerine mühürlediğiniz tavukları ekleyin. Kısık ateşte tavuklar tamamen yumuşayana kadar 8-10 dakika pişirin.
  7. Son Dokunuş: Ocağın altını kapatın. Sıvı kremayı ve kalan tereyağını ekleyip karıştırın. İşte o muhteşem turuncu renk ve ipeksi doku hazır!

İşin Sırrı: Butter Chicken Püf Noktaları

Püf noktası: Butter chicken’ın o restoranlardaki derin ve hafif tütsü aromalı tadını yakalamak istiyorsanız, tavukları tavada pişirirken hafifçe “yakmaktan” korkmayın. Tavukların üzerindeki o kahverengi-siyahımsı karamelize noktalar (char), sosa otantik bir lezzet katacaktır. Ayrıca sosu blenderdan geçirdikten sonra ince bir süzgeçten süzerseniz, tam anlamıyla ipeksi (velvety) bir kıvama ulaşırsınız.

Yanına yapacağınız tane tane dökülen bir basmati pirinç pilavı veya sıcacık bir naan (Hint ekmeği) ile bu akşam kendinizi Yeni Delhi’de hissedeceksiniz. Şimdiden ellerinize sağlık ve afiyet olsun!

Category: Genel | LEAVE A COMMENT
Mayıs 26 2026

Bernina Express ve Ötesi: İsviçre Alpleri’ni Trenle Keşfetme Rehberi

İsviçre denince akla hemen cep yakan fiyatlar, steril sokaklar ve lüks saatler gelir. Ancak Alplerin kucağında, pencereden süzülen kar manzaraları eşliğinde yapacağınız bir isvicre tren turu, hayatınızda bir kez yaşamanız gereken o benzersiz, masalsı deneyimlerden biridir. Bu maceranın tam kalbinde ise kırmızı vagonlarıyla dağları aşan, UNESCO Dünya Mirası listesindeki ünlü bernina express yer alıyor. Peki, bu rüya rotayı cebimizi tamamen boşaltmadan, turistik klişelere teslim olmadan bir lokal gibi nasıl deneyimleriz? Gelin, tren seyahati tutkunlarının kutsal kasesi olan bu yola birlikte çıkalım ve Alplerin gerçek yüzünü keşfedelim.

Landwasser’den Poschiavo’ya: Bir Trenden Fazlası

Chur istasyonundan hareket ettiğinizde, modern dünyanın gürültüsü ve hızı yavaşça geride kalır. Tren, yaklaşık dört saatlik bir yolculukla kuzeydeki heybetli buzullardan güneydeki İtalya sınırına, Tirano’nun palmiye ağaçlarına doğru süzülür. Bu rotanın en ikonik anı, şüphesiz 65 metre yükseklikteki Landwasser Viaduct üzerinden geçiş anıdır. Lokomotif karanlık tünele girmeden hemen önce, tren penceresinden dışarıya süzülen o kırmızı kavis, size neden otoyolları değil de demir ağları seçtiğinizi fısıldar. Bu anı yaşarken acele etmeyin, sadece akışa ve mühendisliğin doğayla uyumuna odaklanın.

Yolculuk ilerledikçe vadi daralır, dağlar üzerinize doğru geliyormuş gibi hissettirir. Ospizio Bernina istasyonuna vardığınızda, tren yolculuğunun en yüksek noktasına, tam 2253 metreye ulaşırsınız. Burası adeta başka bir gezegendir. Lago Bianco (Beyaz Göl) kışın tamamen buzla kaplıyken, bahar aylarında adını aldığı o sütlü beyaz tonuyla parıldar. Tren buradan sonra dik bir inişe geçer. Sadece bir saat içinde, karların içinden sıyrılıp palmiye ağaçlarının ve İtalyan mimarisinin hakim olduğu Tirano’ya inersiniz. İklimin ve kültürün bu kadar kısa sürede bu denli radikal bir şekilde değişmesi, insanda adeta bir zaman makinesinde seyahat ediyormuş hissi uyandırır.

Bütçe Dostu Devrim: Bölgesel Tren Sırrı

Gelelim kertenkerem.net usulü en önemli bütçe tüyomuza. Bernina Express olarak adlandırılan o meşhur kırmızı, panoramik pencereli trenler harikadır, ancak koltuk rezervasyon ücreti adı altında ekstra bir bedel ödemeniz gerekir. Bu bedel sezonuna göre 20 ile 26 CHF arasında değişir. Üstelik bu vagonların pencereleri açılmaz, bu da fotoğraf çekerken camdaki yansımalarla boğuşacağınız anlamına gelir. Seyahati daha samimi kılmak ve bütçeyi korumak için aynı rayları kullanan sarı logolu RhB bölgesel trenlerini tercih edin.

Bölgesel trenlerde rezervasyon ücreti ödemezsiniz, kalabalıktan uzak kalırsınız ve en önemlisi, pencereleri aşağı kaydırıp Alplerin o buz gibi, taze havasını içinize çekerek temiz fotoğraflar çekebilirsiniz. Aynı manzarayı, aynı raylar üzerinde yarı fiyatına ve çok daha özgürce izlemek işte bu kadar basittir.

**Kertenkerem Tüyosu:** Bölgesel trenlerde seyahat ederken trenin en arkasındaki vagona geçmeye çalışın. Virajları dönerken trenin gövdesini ve Alplerin manzarasını aynı kadraja almak, bölgesel trenlerin açılan pencereleri sayesinde çok daha kolaydır. Üstelik bu trenler saat başı çalışır, yani dilediğiniz istasyonda inip bir sonrakine binebilirsiniz.

Klişelerden Uzak İsviçre Gezilecek Yerler

Çoğu turist St. Moritz’de inip pahalı kafelerde vakit geçirmeyi tercih eder. Ancak gerçek bir gezgin için isvicre gezilecek yerler listenin en değerli incileri, trenin durduğu o küçük ve sessiz istasyonlarda saklıdır. Örneğin Alp Grüm istasyonu bunlardan biridir. Deniz seviyesinden 2091 metre yükseklikte yer alan bu istasyona sadece trenle ya da zorlu bir yürüyüş rotasıyla ulaşabilirsiniz. İstasyonun hemen yanındaki taş binada yer alan restoranda sıcak bir çorba içip Palü Buzulu’nu izlemek, lüks bir kayak merkezinde harcayacağınız zamandan çok daha değerlidir.

Yolculuğun devamında karşınıza çıkan, İtalyanca konuşulan Poschiavo kasabası ise taş evleri ve dar sokaklarıyla size İsviçre’de olduğunuzu unutturacak bir sakinlik sunar. Burada büyük turist otobüsleri göremezsiniz; sadece yerel halkın sakin yaşamına tanıklık eder, meydandaki küçük fırından taze bir hamur işi alıp nehir kenarında yiyebilirsiniz. İşte gerçek İsviçre deneyimi tam olarak burada başlar.

Pratik Bilgiler ve Rezervasyon Tüyoları

Bu rüya gibi tren seyahati için planlama yaparken biletinizi son dakikaya bırakmamalısınız. İsviçre’de ulaşım pahalıdır ancak sistemi çözerseniz bütçenizi koruyabilirsiniz. Chur ile Tirano arasında tek yön bilet fiyatı normal şartlarda yaklaşık 63 CHF civarındadır. Ancak İsviçre Federal Demiryolları mobil uygulamasını indirip bir-iki ay öncesinden “Saver Day Pass” kovalarsanız, tüm gün geçerli sınırsız ulaşım biletini 52 CHF gibi çok daha uygun bir fiyata yakalayabilirsiniz. Eğer ülkede birkaç gün geçirecekseniz ve farklı şehirlere de seyahat edecekseniz, Swiss Travel Pass almak en mantıklı çözümdür; çünkü bu kart bölgesel trenleri tamamen ücretsiz hale getirir.

**Zamanlama Tüyosu:** En güzel manzaralar için trenin gidiş yönüne göre sağ tarafına oturmaya özen gösterin. Alp Grüm ve Lago Bianco manzaraları sağ tarafta çok daha büyüleyicidir. Seyahatinizi mayıs veya ekim aylarında planlarsanız, hem karlı zirveleri hem de yeşeren vadileri aynı anda görebilirsiniz.

Yolculuğa Hazırlık: Yanınıza Ne Almalı?

Alplerde hava durumu hızla değişebilir. Vadide sıcaklık 20 dereceyken, zirveye çıktığınızda kendinizi sıfır derecede bulabilirsiniz. Bu yüzden yanınıza mutlaka katman katman giyebileceğiniz kıyafetler alın. Ayrıca tren istasyonlarındaki marketler pahalı olduğundan, yolculuk öncesinde büyük süpermarketlerden sandviç, yerel İsviçre çikolatası ve suyunuzu alıp sırt çantanıza atmak bütçenizi büyük ölçüde rahatlatacaktır. Kendi pikniğinizi dağların zirvesinde yapmak, en lüks restorandan daha keyiflidir.

Sonuçta İsviçre Alpleri’ni trenle keşfetmek sadece bir noktadan diğerine gitmek değil, yolun kendisini bir yaşam biçimi haline getirmektir. Pencereden dışarı bakarken zamanın nasıl yavaşladığını hissedecek, hız çağında yavaşlamanın lüksünü tadacaksınız. Valizinizi hazırlayın, biletinizi erkenden alın ve Alplerin kalbine doğru giden o demir yollarının sesine kulak verin.

Category: Genel | LEAVE A COMMENT
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
Mayıs 22 2026

Zabbix + Alertmanager: PagerDuty ve Slack Entegrasyonu

Gece saat 03:00. Cep telefonunuz ardı ardına titriyor. Zabbix size “CPU usage high on prod-db-01” başlıklı tam 142 adet SMS göndermiş. Gözlerinizi oğuşturarak bilgisayarı açıyorsunuz ve durumun aslında sadece planlı bir veritabanı yedeğinden (backup job) ibaret olduğunu, diskin veya veritabanının çökmediğini görüyorsunuz. Bu esnada sinirden köpürürken kendinize şu soruyu soruyorsunuz: “Neden bu alarmları gruplayamadım? Neden nöbetçi arkadaşım yerine tüm ekip ayağa kalktı?”

İşte tam bu noktada, geleneksel izleme canavarımız zabbix ile modern bulut dünyasının alarm yönetim standardı olan alertmanager‘ı evlendirmenin vakti gelmiş demektir. Bu makalede, Zabbix’in topladığı metrik ve trigger’ları Alertmanager’a köprüleyecek, oradan da slack ve pagerduty entegrasyonları ile akıllı, gürültüsüz ve insan odaklı bir oncall yönetim yapısı kuracağız.

Neden Doğrudan Zabbix Değil de Alertmanager?

Zabbix, metrik toplama (polling), agent yönetimi ve esnek trigger tanımlama konularında harika bir araçtır. Ancak iş alarm yönetimine (alert routing, deduplication, inhibition ve silencing) geldiğinde Zabbix’in aksiyon (Action) arayüzü hantal kalır. GitOps felsefesine uygun değildir, sürüm kontrolü (version control) zordur ve karmaşık eskalasyon senaryolarında konfigürasyon cehennemine dönüşebilir.

Alertmanager ise Prometheus ekosisteminin kalbidir ancak sadece Prometheus ile sınırlı olmak zorunda değildir. Bize sunduğu avantajlar şunlardır:

  • Deduplication (Tekilleştirme): Aynı anda patlayan 50 benzer alarmı tek bir Slack mesajında birleştirir.
  • Inhibition (Bastırma): Eğer bir veri merkezi (datacenter) çöktüyse, o veri merkezinin içindeki 100 makine için “Node Down” alarmı göndermez; sadece “Datacenter Offline” alarmını geçirir, diğerlerini bastırır.
  • Dynamic Routing (Dinamik Yönlendirme): Alarma basılan etiketlere (labels) göre alarmı anında doğru ekibe (DBA, Network, Frontend) yönlendirir.

Adım 1: Zabbix Webhook ile Alertmanager API Köprüsü Kurmak

İlk yapmamız gereken iş, Zabbix’te bir trigger tetiklendiğinde bunu Alertmanager’ın /api/v2/alerts endpoint’ine gönderecek bir “Media Type” tanımlamaktır. Alertmanager, kendisine gönderilen JSON payload’unda belirli standartlar bekler.

Zabbix arayüzünde Administration -> Media Types sekmesine gidin ve “Create media type” butonuna tıklayın. Tipi Webhook olarak seçin ve aşağıdaki parametreleri ekleyin:

// Zabbix Webhook Script içeriği
try {
    var params = JSON.parse(value),
        req = new HttpRequest(),
        payload = [];

    if (typeof params.AlertmanagerURL === 'undefined') {
        throw 'AlertmanagerURL parametresi eksik.';
    }

    // Alertmanager API v2 formatı
    var alert = {
        "labels": {
            "alertname": params.AlertName,
            "severity": params.Severity,
            "instance": params.HostName,
            "service": params.Service || "infrastructure",
            "environment": params.Environment || "production"
        },
        "annotations": {
            "summary": params.TriggerDescription,
            "value": params.TriggerValue,
            "zabbix_url": params.ZabbixURL + "/tr_events.php?triggerid=" + params.TriggerID
        }
    };

    // Zabbix alarm durumuna göre durumu eşle (Eğer OK ise çözüldü olarak gönder)
    if (params.TriggerStatus === 'OK') {
        alert["endsAt"] = new Date().toISOString();
    } else {
        alert["startsAt"] = new Date().toISOString();
    }

    payload.push(alert);

    req.addHeader('Content-Type: application/json');
    var response = req.post(params.AlertmanagerURL + '/api/v2/alerts', JSON.stringify(payload));

    if (req.getStatus() !== 200 && req.getStatus() !== 201) {
        throw 'HTTP hatası: ' + req.getStatus() + '\nResponse: ' + response;
    }

    return 'OK';
} catch (error) {
    Zabbix.log(3, 'Alertmanager webhook hatası: ' + error);
    throw error;
}

Bu JS kodu, Zabbix trigger’ı tetiklendiğinde ya da çözüldüğünde (OK durumuna geçtiğinde) Alertmanager’a RFC3339 formatında zaman damgasıyla birlikte durumu iletir. Böylece Alertmanager alarmın çözüldüğünü (resolved) anlar ve Slack/PagerDuty üzerindeki açık alarmı otomatik olarak kapatır.

Adım 2: Alertmanager Konfigürasyonu (`alertmanager.yml`)

Şimdi Alertmanager tarafında bu alarmları nasıl karşılayacağımızı ve nereye yönlendireceğimizi tanımlayalım. production ortamlarında genellikle kritik alarmların PagerDuty’ye (ve dolayısıyla nöbetçi mühendisin telefonuna), uyarı seviyesindeki alarmların ise sadece Slack kanalına gitmesini isteriz.

global:
  resolve_timeout: 5m

route:
  group_by: ['alertname', 'instance', 'environment']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'slack-default'
  routes:
    # Kritik üretim alarmları hem Slack'e hem PagerDuty'ye gitsin
    - match:
        severity: 'disaster'
        environment: 'production'
      receiver: 'pagerduty-critical'
      continue: true
    
    # Tüm üretim alarmları Slack kanalına düşsün
    - match:
        environment: 'production'
      receiver: 'slack-production'

receivers:
- name: 'slack-default'
  slack_configs:
  - api_url: 'https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX'
    channel: '#ops-alerts-test'
    send_resolved: true
    text: "Alarm: {{ .CommonAnnotations.summary }}\nSeverity: {{ .CommonLabels.severity }}\nHost: {{ .CommonLabels.instance }}"

- name: 'slack-production'
  slack_configs:
  - api_url: 'https://hooks.slack.com/services/T00000000/B00000000/YYYYYYYYYYYYYYYYYYYYYYYY'
    channel: '#prod-alerts'
    send_resolved: true
    title: "[{{ .Status | toUpper }}] {{ .CommonLabels.alertname }}"
    text: "Host: {{ .CommonLabels.instance }}\nDetay: {{ .CommonAnnotations.summary }}\nZabbix Linki: {{ .CommonAnnotations.zabbix_url }}"

- name: 'pagerduty-critical'
  pagerduty_configs:
  - service_key: 'YOUR_PAGERDUTY_INTEGRATION_KEY_HERE'
    severity: 'critical'
    send_resolved: true
    client: 'Alertmanager'
    client_url: 'https://alertmanager.kertenkerem.net'
    description: "{{ .CommonAnnotations.summary }} - Host: {{ .CommonLabels.instance }}"

Adım 3: PagerDuty Üzerinde Akıllı On-Call ve Eskalasyon Politikaları

Alertmanager entegrasyonunu tamamladıktan sonra topu pagerduty tarafına atıyoruz. PagerDuty üzerinde bir servis (Service) oluşturup entegrasyon tipini “Prometheus/Alertmanager” olarak seçtiğinizde size yukarıdaki YAML dosyasında kullandığımız service_key (Integration Key) değerini verecektir.

Ancak iş sadece entegrasyonla bitmiyor. Gerçek bir oncall kültüründe şu üç yapıyı kurmanız gerekir:

1. Schedules (Nöbet Takvimleri)

Haftalık rotasyonlar tanımlayın. Örneğin, her Salı günü saat 09:00’da nöbet bir sonraki mühendise devretsin. PagerDuty üzerinde Primary ve Secondary (yedek) olmak üzere iki farklı takvim oluşturmak hayat kurtarır. Eğer Primary nöbetçisi o an ulaşılamaz durumdaysa (örneğin uçaktaysa), sistem otomatik olarak yedek nöbetçiyi arar.

2. Escalation Policies (Eskalasyon Politikaları)

Alarmların sahipsiz kalmaması için eskalasyon zinciri şarttır. Örnek bir kurumsal politika şu şekilde olmalıdır:

  • Adım 1: Alarm tetiklendiğinde o anki nöbetçiyi (Primary) ara ve SMS gönder. (0. dakika)
  • Adım 2: Eğer 10 dakika içinde “Acknowledge” (onay) gelmezse, yedek nöbetçiyi (Secondary) ara. (10. dakika)
  • Adım 3: Eğer hala ses çıkmıyorsa, tüm DevOps ekibine push notification at ve takım liderini devreye sok. (20. dakika)

3. Slack Entegrasyonu ve ChatOps

PagerDuty Slack uygulamasını kurarak, Slack kanalı üzerinden tek tıkla alarmı üstlenebilir (Acknowledge) veya çözebilirsiniz (Resolve). Bu, gece yarısı telefondan PagerDuty uygulamasına girmeye çalışırken harcayacağınız 30 saniyeyi size geri kazandırır.

Alert Fatigue (Alarm Yorgunluğu) ile Savaşmak

Sistemi kurduk ancak her gün 500 defa çalan bir pager sistemi, bir süre sonra mühendislerin uyarıları görmezden gelmesine (alert fatigue) sebep olur. Bunu engellemek için şu taktikleri uygulayın:

  • Sadece aksiyon alınabilir alarmları PagerDuty’ye gönderin: “Disk doluluğu %81 oldu” bir PagerDuty alarmı değildir, sadece Slack’e gitmelidir. Ancak “Disk doluluğu %95 ve 10 dakika içinde tamamen dolacak” alarmı nöbetçiyi yataktan kaldırmalıdır.
  • Inhibit Rules kullanın: Switch çöktüğünde arkasındaki 30 sunucu için tek tek “ping down” alarmı almamak için Alertmanager inhibit kurallarını tanımlayın.
  • Susturma (Silences): Planlı bakım çalışmalarından önce Alertmanager veya PagerDuty arayüzünden ilgili servisleri mutlaka susturun (Silence).

Özet

Zabbix’in köklü izleme yeteneklerini Alertmanager’ın modern yönlendirme mimarisiyle birleştirmek, altyapı yönetiminde adeta çağ atlatır. Bu sayede hem production ortamınızdaki anomalileri saniyeler içinde yakalarsınız, hem de ekibinizin akıl sağlığını gereksiz gürültülü alarmlardan korumuş olursunuz.

Bir sonraki yazımızda Alertmanager üzerinde gelişmiş inhibit_rules yazımını inceleyeceğiz. O zamana kadar, alarmınız az, uykunuz bol olsun!

Category: Genel | LEAVE A COMMENT
Mayıs 21 2026

Perplexity ile Araştırma Yapmak: Google’ı Nasıl Geçiyor?

Google’da arama yapıp ilk üç sayfanın reklam, sonraki beş sayfanın ise içi boş SEO çöplüğü çıktığı o sinir bozucu anları hepimiz yaşıyoruz. İşte tam bu noktada, geleneksel arama motorlarının tahtını sallayan perplexity ve onun başını çektiği yeni nesil ai search dalgası imdadımıza yetişiyor. Klasik arama motorları bize sadece web sitelerinin adreslerini verirken, modern llm tabanlı bu sistemler doğrudan sorumuzun cevabını sentezleyip sunuyor. Peki, üretken yapay zeka dünyasının en popüler tools listelerinde zirveye oynayan bu araçla gerçekten derinlemesine bir araştırma yapmak mümkün mü? Yoksa bu da sadece geçici bir heves mi? Gelin, lafı uzatmadan doğrudan deneyimlerimize ve test sonuçlarımıza bakalım.

Perplexity Nedir ve Neden Farklı?

Klasik yapay zeka sohbet robotları (ChatGPT veya Claude gibi), eğitildikleri veri kümesine sıkışıp kalırlar. Bilgileri eski olabilir veya bilmedikleri konularda “halüsinasyon” görerek bize tamamen uydurma bilgiler sunabilirler. Perplexity ise bu sorunu temelden çözüyor. O sadece bir dil modeli değil; interneti aktif olarak tarayan, kaynakları okuyan ve size sunduğu her cümlenin yanına referans linki bırakan akıllı bir arama motoru.

Kaynak Gösterme Mekanizması: Bilgi Nereden Geliyor?

Perplexity’nin en büyük gücü, şeffaflığında yatıyor. Yazdığı her cümlenin sonuna küçük rakamlar (1, 2, 3…) yerleştiriyor. Bu rakamlara tıkladığınızda, bilginin hangi web sitesinden, hangi makaleden alındığını anında görebiliyorsunuz. “Neden böyle?” sorusunun cevabı basit: Yapay zekaya güvenmek zordur ama kaynağı doğrulamak kolaydır. Perplexity size “bana güven” demiyor, “bak, buradaki verilere dayanarak bunu söylüyorum” diyor.

[Görsel: Perplexity arayüzünde bir arama sonucu ve metin içindeki kaynak gösterim numaralarının yakın plan görünümü]

Gerçek Dünya Testleri: Perplexity İş Başında

Sözü fazla uzatmayalım ve bu aracı gerçek hayatta en çok zorlandığımız iki farklı senaryoda test edelim. Promp’larımızı hazırladık ve sonuçları raporluyoruz.

Senaryo 1: Akademik Araştırma ve Literatür Taraması

Test etmek istediğimiz konu şu oldu: “Grafen bazlı bataryaların elektrikli araçlarda (EV) kullanılmasının önündeki temel teknik engeller nelerdir?”

Bu soruyu Google’a sorduğumuzda karşımıza sponsorlu siteler, popüler teknoloji bloglarının yüzeysel yazıları ve forum tartışmaları çıkıyor. Akademik bir makaleye ulaşmak için Google Scholar’da saatler harcamamız gerekiyor.

Aynı soruyu Perplexity’nin sol alt köşesindeki “Focus” (Odak) menüsünden “Academic” modunu seçerek sorduk. Sonuç şaşırtıcı derecede temizdi:

  • Doğrudan IEEE, ScienceDirect ve arXiv üzerindeki güncel makaleleri taradı.
  • “Isıl yönetim sorunları”, “üretim maliyetleri” ve “anot stabilitesi” gibi teknik engelleri başlıklar halinde özetledi.
  • Her başlığın altına, ilgili akademik yayının linkini ve yazar isimlerini iliştirdi.

[Görsel: Perplexity’nin “Academic Focus” modu aktifken yaptığı teknik literatür taraması ekran görüntüsü]

Senaryo 2: Sıcak Gelişmeler ve Güncel Haber Takibi

Yapay zeka dünyası çok hızlı değişiyor. İkinci test sorumuz: “Son 48 saat içinde OpenAI cephesinde yaşanan en önemli yönetimsel gelişmeler nelerdir?”

Bildiğiniz gibi standart LLM modelleri güncel internet erişimi olmadan bu soruya cevap veremez. Perplexity ise “Writing” yerine “All” (Genel Arama) modunu kullanarak X (Twitter), TechCrunch ve Reuters gibi platformları anında taradı. Gelişmeleri kronolojik bir sırayla, saat saat önümüze koydu. Birbirinden farklı haber kaynaklarındaki çelişkili bilgileri bile “Bazı kaynaklar X derken, diğerleri Y olduğunu belirtiyor” şeklinde analiz ederek sundu.

Pro vs. Ücretsiz Sürüm: Kasanın Durumu Nedir?

Perplexity’yi tamamen ücretsiz olarak kullanabilirsiniz. Ancak bir de aylık 20 dolar fiyat etiketine sahip olan “Pro” sürümü bulunuyor. Peki bu parayı ödemeye gerçekten gerek var mı?

Ücretsiz sürüm, hızlı günlük aramalar ve basit sorular için fazlasıyla yeterli. Ancak iş profesyonel araştırmaya, kod yazmaya veya büyük PDF dosyalarını analiz etmeye geldiğinde Pro sürümünün sunduğu avantajlar öne çıkıyor:

  • Model Seçimi: Pro üyeler, aramayı arkada hangi yapay zeka modelinin işleyeceğini seçebiliyor. Claude 3.5 Sonnet, GPT-4o veya Perplexity’nin kendi optimize edilmiş modelleri arasında geçiş yapabiliyorsunuz. Özellikle derin analizlerde Claude 3.5 Sonnet kullanmak tam bir cankurtaran.
  • Dosya Yükleme: Pro sürümde 100 sayfalık bir finansal raporu veya PDF kitabını sisteme yükleyip, “Bu raporun 50. sayfasındaki tabloya göre şirketin borç oranı nedir?” gibi spesifik aramaları internet verileriyle birleştirerek yapabiliyorsunuz.

[Görsel: Perplexity Pro ayarlar panelinde kullanıcıya sunulan GPT-4o, Claude 3.5 Sonnet ve Llama 3 model seçenekleri]

Artılar ve Eksiler Tablosu

Her aracın olduğu gibi Perplexity’nin de zayıf ve güçlü yanları var. Yaptığımız testler sonucunda ortaya çıkan tablo şu şekilde:

Özellik Artıları (+) Eksileri (-)
Kaynak Doğruluğu Her iddiaya doğrudan tıklanabilir linkler veriyor, bilgi kirliliğini önlüyor. Bazen çok popüler ama güvenilmez blogları da kaynak olarak seçebiliyor.
Kullanım Kolaylığı Reklamsız, sade ve doğrudan sonuca odaklı arayüz. Geleneksel “görsel arama” veya “alışveriş” kategorilerinde Google kadar pratik değil.
Esneklik (Pro) Claude 3.5 Sonnet ve GPT-4o gibi en güçlü modelleri tek bir abonelikte sunuyor. Aylık 20 dolarlık ücret, sadece arada sırada arama yapanlar için yüksek kalabilir.
Hız Saniyeler içinde onlarca siteyi tarayıp özet çıkarıyor. Çok karmaşık sorgularda arama süresi bazen 10-15 saniyeyi bulabiliyor.

Fiyatlandırma ve Ücretsiz Alternatifler

Eğer bütçeniz kısıtlıysa veya “Ben bir aramaya ayda 20 dolar vermem” diyorsanız, piyasada kullanabileceğiniz harika ücretsiz veya daha uygun fiyatlı alternatifler mevcut:

  • Phind: Özellikle yazılımcılar ve geliştiriciler için harika bir ücretsiz AI search aracı. Kod bloklarını ve teknik dökümantasyonları çok iyi tarıyor.
  • Microsoft Copilot: Microsoft Edge tarayıcısıyla entegre gelen Copilot, GPT-4 altyapısını ücretsiz olarak internet aramalarıyla birleştirerek sunuyor.
  • Consensus: Tamamen bilimsel ve akademik makaleler üzerine odaklanmış, kanıta dayalı bir yapay zeka arama motoru.

Sonuç: Google’ı Tamamen Hayatımızdan Çıkarıyor muyuz?

Dürüst olalım: Yakın bir gelecekte mahallenizdeki en iyi pizzacıyı bulmak, uçak bileti fiyatlarını karşılaştırmak veya hızlıca bir spor ayakkabı satın almak için yine Google’ı kullanacaksınız. Google, bu tarz “operasyonel” işlerde hala çok pratik.

Ancak konu derinlemesine bir konuyu öğrenmek, makale yazmak, karmaşık teknik bir problemi çözmek veya bir sektör raporunu analiz etmek olduğunda, Perplexity klasik aramayı çoktan tarihe gömmüş durumda. Bilgiyi aramakla vakit kaybetmek istemiyor, doğrudan öğrenmeye başlamak istiyorsanız Perplexity’ye mutlaka bir şans vermelisiniz.

Category: Genel | LEAVE A COMMENT
Mayıs 14 2026

Cursor vs GitHub Copilot: Hangisi Gerçekten İşe Yarıyor?

Yazılım dünyasında son yıllarda büyük bir devrim yaşanıyor. Artık kod yazarken yalnız değiliz; yanımızda sürekli fısıldayan, eksiklerimizi tamamlayan bir yapay zeka var. Bu alanda en çok öne çıkan iki developer tools devi ise şüphesiz emektar GitHub Copilot ve VS Code tabanlı yükselen yıldız Cursor. Peki, günlük kodlama pratiklerimizde bu ai asistanlarından hangisi gerçekten işe yarıyor? Sözü hiç dolandırmadan, pazarlama vaatlerini bir kenara bırakıp her iki aracı da gerçek bir projede test ettik ve sonuçları masaya yatırdık.

Nedir Bu Araçlar? (Kısa Bir Jargon Ayıklaması)

Karşılaştırmaya geçmeden önce, kafaları karıştırmamak için ufak bir sözlük yapalım. İki aracın da temel amacı aynı gibi görünse de felsefeleri oldukça farklı:

  • GitHub Copilot: VS Code, JetBrains gibi popüler editörlerin içine bir eklenti (extension) olarak kurulur. Siz kod yazarken satır içi (inline) öneriler yapar.
  • Cursor: Doğrudan VS Code tabanlı, kendi başına ayrı bir kod editörüdür. İçinde yapay zeka entegrasyonu derinlemesine (deeply integrated) yer alır. Yani VS Code’un aynısıdır ama yapay zeka için baştan tasarlanmıştır.

[Görsel: VS Code ve Cursor yan yana arayüz karşılaştırması]

Gerçek Bir Senaryo: Express.js ve React Projesi

Laf kalabalığı yapmayı sevmeyiz. Bu yüzden iki asistanı da orta ölçekli bir Full-Stack projede test ettik. Amacımız basit bir kullanıcı kayıt formu oluşturmak, şifreleri hash’lemek ve veritabanına kaydetmekti.

1. Raunt: Hız ve Otomatik Tamamlama (Autocomplete)

Kod yazarken ritmi kaybetmemek çok önemlidir. GitHub Copilot bu konuda tam bir canavar. Siz daha fonksiyonun adını yazarken (örneğin const hashPassword =) ne yapmak istediğinizi anlayıp gri renkle kodu önünüze seriyor. Tab tuşuna bastığınız anda kod orada.

Cursor ise kendi geliştirdiği “Copilot++” (yeni adıyla Cursor Tab) özelliğini kullanıyor. Sadece bir sonraki kelimeyi değil, bir sonraki satırı ve yapacağınız muhtemel düzenlemeyi de tahmin ediyor. Hız konusunda başa başlar, ancak Cursor’ın düzenleme önerileri biraz daha “akıllıca” hissettiriyor.

2. Raunt: Bağlam (Context) ve Projeyi Anlama Yeteneği

İşte burası dananın kuyruğunun koptuğu yer. Bir AI asistanının sadece o an açık olan dosyayı değil, tüm projeyi anlamasını isteriz. Buna teknik olarak context window (bağlam penceresi) deniyor.

GitHub Copilot, @workspace komutu ile tüm projeyi tarayabiliyor ancak bazen büyük projelerde kafası karışabiliyor veya güncel olmayan dosyalardan referans verebiliyor.

Cursor ise bu işi bambaşka bir seviyeye taşımış. Editörün içinde yer alan chat kısmına @database.js yazarak doğrudan spesifik bir dosyayı referans gösterebiliyorsunuz. Hatta tüm klasörü indeksleyip (indexing) projede yaptığınız bir değişikliğin diğer dosyaları nasıl etkileyeceğini hatasız analiz ediyor. Örneğin, veritabanı şemasını değiştirdiğimizde Cursor, tüm API uçlarını tek seferde güncelleyebildi.

[Görsel: Cursor editöründe @ symbol yardımıyla dosya referansı gösterme]

# Cursor içinde terminal komutlarını bile AI'a yazdırabiliyoruz:
# "Bana port 3000'i kullanan süreçleri bul ve sonlandır" dediğimizde:
lsof -i :3000 | awk '{print $2}' | tail -n +2 | xargs kill -9

Artılar ve Eksiler Tablosu

Her iki aracın da güçlü ve zayıf yönlerini şu şekilde özetleyebiliriz:

Özellik GitHub Copilot Cursor AI
Kurulum Çok kolay (Herhangi bir editöre eklenti olarak) Yeni bir editör indirmek gerekiyor (VS Code klonu)
Kod Tamamlama Hızı Mükemmel (Anında tepki) Çok iyi (Hafif gecikmeler olabilir)
Bağlam (Context) Orta (Bazen dosyaları kaçırıyor) Harika (Tüm projeyi indeksleme yeteneği)
Kullanılan Modeller OpenAI modelleri ve Codex Claude 3.5 Sonnet, GPT-4o ve özel Cursor modelleri
Gizlilik (Privacy) Kurumsal hesaplarda veri güvenliği yüksek “Privacy Mode” açıkken verileri sunucuda saklamıyor

Fiyatlandırma ve Ücretsiz Alternatifler

Geldik en can alıcı noktaya: Cüzdanımız bu işe ne diyor?

  • GitHub Copilot Fiyatı: Bireysel kullanım için aylık 10$ veya yıllık 100$. Öğrenciler ve popüler açık kaynaklı projelerin yöneticileri için tamamen ücretsiz.
  • Cursor Fiyatı: Aylık 50 “fast” (hızlı) premium sorgu içeren ücretsiz (Hobby) planı var. Pro planı ise aylık 20$. Ancak ücretsiz planda bile sınırsız yavaş sorgu hakkı sunması büyük bir artı.

Para Vermek İstemeyenler İçin Ücretsiz Alternatifler

Eğer bütçeniz kısıtlıysa veya bu araçlara hemen para yatırmak istemiyorsanız şu alternatifleri değerlendirebilirsiniz:

  1. VS Code + Codeium: Tamamen ücretsiz bir otomatik tamamlama eklentisi. Copilot kadar olmasa da oldukça başarılı.
  2. Windsurf: Son zamanlarda adını sıkça duyuran, Cursor benzeri bir başka yeni nesil AI IDE’si.
  3. Double.bot: VS Code için kullanımı kolay ve ücretsiz deneme süresi oldukça cömert bir alternatif.

[Görsel: GitHub Copilot’un VS Code ayarlarındaki aktiflik göstergesi]

Gizlilik Meselesi: Kodlarımız Güvende mi?

Bir yazılımcı olarak yazdığımız tescilli kodların bir yapay zekayı eğitmek için kullanılmasını istemeyiz.

GitHub Copilot, ayarlardan “kodlarımı eğitim için kullanma” seçeneğini kapatmanıza izin veriyor. Cursor tarafında ise ayarlardan Privacy Mode‘u aktif ettiğinizde, yazdığınız hiçbir kod sunucularda depolanmıyor veya modellerin eğitimi için kullanılmıyor. Kurumsal projelerde çalışıyorsanız, bu ayarları mutlaka kontrol etmenizi öneririz.

Sonuç: Hangisini Seçmeli?

Yaptığımız testler sonucunda vardığımız karar oldukça net:

Eğer halihazırda kurulu bir VS Code düzeniniz varsa, editör değiştirmek istemiyorsanız ve sadece kod yazarken hız kazanmak istiyorsanız GitHub Copilot sizin için en mantıklı ve stabil seçenek olmaya devam ediyor.

Ancak, “Ben yapay zekayı sadece kod tamamlasın diye değil, benimle birlikte projeyi geliştirsin, hata ayıklasın (debug), büyük refaktör işlemlerini tek komutla halletsin” diye istiyorsanız, Cursor şu an piyasadaki en gelişmiş ve yetenekli araç konumunda. Aylık 20$’lık fiyatını sunduğu zaman tasarrufuyla fazlasıyla hak ediyor.

Category: Genel | LEAVE A COMMENT