DEV Community: TAHA TÜZEL

Bir Siparişten Satış Raporuna: OLTP, OLAP ve Data Warehouse

TAHA TÜZEL — Wed, 14 Oct 2026 07:12:26 +0000

Backend tarafında bir kullanıcı kaydı oluştururken veya bir siparişi kaydederken database kullanıyorum. Hangi alanları tutacağım, tabloları nasıl ilişkilendireceğim ve sorguyu nasıl yazacağım genellikle uygulamanın o anki ihtiyacına göre şekilleniyor.

Aynı veriden bir yıllık satış raporu çıkarmak istediğimde ise ihtiyaç değişiyor. Belirli bir müşterinin siparişini bulmakla bütün satışları aylara göre gruplamak aynı veriyi kullansa da database'den farklı işler istiyor.

Bu konuları çalışırken sık karşılaştığım açıklama şuydu:

OLTP günlük işlemler, OLAP analiz için kullanılır.

Bu ayrım başlangıç için anlamlı. Ama uygulamanın database'inde zaten rapor sorgusu yazabiliyorsam neden ayrıca data warehouse kullandığımızı tek başına açıklamıyor. Veriyi başka bir yere taşımak ne kazandırıyor, tablo yapısı neden değişiyor, satır ve sütun odaklı depolama bu resimde nereye oturuyor?

Bu yazıda önce bu kavramların neyi tarif ettiğini açıklayıp ardından aynı e-ticaret örneği üzerinde ilerleyeceğim. Ahmet'in 300 TL'lik muz siparişini, uygulamada oluştuğu andan aylık satış raporuna girdiği noktaya kadar takip edeceğiz. Tablolar ve sorgular anlatım için hazırladığım basitleştirilmiş örnekler.

Büyük Resim: Veriyi Kaydetmek ve Veriden Sonuç Çıkarmak

Bir veri sistemi, uygulamanın günlük işlemlerini yürütmek için çalışabilir. Kullanıcının hesabına erişmesi, bir kaydın durumunu görmesi veya yeni bir kayıt oluşturması bu kullanımın parçasıdır. Burada işlemlerin kısa sürede tamamlanması ve eşzamanlı kullanıcıların yaptığı değişikliklerin doğru yönetilmesi önemlidir.

Aynı veriyi analiz için kullandığımızda ise çok sayıda kaydı birlikte inceleriz. Toplamları hesaplar, dönemleri karşılaştırır veya veriyi farklı kırılımlarda gruplarız. Tek bir kaydın güncel durumundan, kayıtların birlikte ne anlattığına geçeriz.

OLTP (Online Transaction Processing) ilk kullanım biçimine, OLAP (Online Analytical Processing) ise analitik kullanıma odaklanır. Bunlar veriyi hangi iş için işlediğimizi anlatır. Data warehouse, analiz ihtiyacını desteklemek için kurduğumuz veri deposudur; farklı kaynaklardan gelen veriyi ortak bir düzen içinde saklamamızı sağlar.

E-ticaret örneğinde genel yol şöyle olabilir:

Müşteri sipariş verir
        ↓
Operasyonel Database
Siparişi kaydet, stok bilgisini güncelle → OLTP
        ↓
Veriyi analiz için hazırla ve aktar
        ↓
Data Warehouse
        ↓
Aylara ve kategorilere göre satışları hesapla → OLAP
        ↓
Satış raporu / Dashboard

Ahmet sipariş verdiğinde uygulama ona işlemin sonucunu gösteriyor. Ay sonunda hazırlanan raporda ise aynı sipariş, meyve kategorisinin satış toplamına katkı sağlıyor.

Her uygulama için bu aşamaları ayrı sistemlerle kurmamız gerekmiyor. Ancak bu yolu takip etmek, iki kullanımın nerede farklılaştığını anlamayı kolaylaştırıyor.

Adım 1: Database ve OLTP ile Günlük İşlemleri Yürütmek

Database, veriyi belirli bir düzen içinde sakladığımız ve sorguladığımız yapıdır. DBMS (Database Management System) ise bu verinin saklanmasını, okunmasını ve değiştirilmesini yöneten yazılımı ifade eder. PostgreSQL ve MySQL birer DBMS örneğidir.

İlişkisel bir database'de veriyi tablolarda tutarız. Satırlar kayıtları, sütunlar ise bu kayıtların alanlarını temsil eder. Primary key, bir kaydı benzersiz biçimde tanımlar; foreign key de tablolar arasındaki ilişkinin bütünlüğünü korumaya yardımcı olur.

Bir kaydı bulmak için kullanılan index, sorgunun ilgili verilere daha az kayıt okuyarak ulaşmasını sağlayan ek bir yapıdır. Bunun da maliyeti vardır: index alanı kaplar ve veri değiştiğinde database index'i de güncellemek zorunda kalabilir. Bu nedenle her sütuna index eklemek yerine uygulamanın sorgularını dikkate almak gerekir.

OLTP sistemleri bu araçları, çok sayıda kullanıcının kısa süren işlemlerini karşılamak için kullanır. İşlem çoğunlukla belirli bir müşteri, sipariş veya ürün gibi sınırlı bir kayıt kümesiyle ilgilidir. Hem okuma hem yazma vardır; yanıt süresinin kısa olması uygulamanın kullanımını doğrudan etkiler.

Örneğin Ahmet siparişinin durumunu görmek istediğinde bütün satış geçmişini incelemiyoruz. Belirli bir sipariş kaydına gidiyoruz:

SELECT order_id, customer_id, status, created_at
FROM orders
WHERE order_id = 1042;

order_id primary key ise bu alanı destekleyen index, database'in ilgili siparişi bulmasına yardımcı olur. Sonuç, sipariş ekranında göstereceğim durum bilgisi olabilir.

Aynı sırada başka bir kullanıcı yeni sipariş oluşturabilir, bir çalışan da başka bir siparişin durumunu güncelleyebilir. OLTP tarafındaki ihtiyaç bu işlemleri birlikte yürütürken veriyi doğru durumda tutmak. Sipariş kaydetmek kadar sipariş okumak da bu iş yüküne ait.

Normalization: Veriyi Neden Ayrı Tablolarda Tutuyoruz?

Normalization, veriyi ilişkilerine göre düzenleyerek gereksiz tekrarları ve bu tekrarlardan doğan değişiklik sorunlarını azaltma yaklaşımıdır. Aynı bilginin birçok kayıtta tutulması, bir değişiklik sırasında kopyaların bir bölümünün güncel, diğer bölümünün eski kalmasına yol açabilir.

Bu nedenle bir varlığa ait bilgiyi uygun tabloda saklar, diğer kayıtları ona anahtar üzerinden bağlarız. Bir ilişkiyi okumak için join yapmak gerekebilir; bunun karşılığında ortak bilgiyi her kopyasında ayrı ayrı güncellemekten kurtuluruz.

E-ticaret uygulamasında şöyle bir model kurabiliriz:

customers
  customer_id, name, email

orders
  order_id, customer_id, status, created_at

order_items
  order_item_id, order_id, product_id, quantity, unit_price

products
  product_id, name, category_id, current_price, stock_quantity

categories
  category_id, name

Ahmet'in adı ve e-posta adresi customers tablosunda duruyor. Sipariş kaydı, aynı alanları tekrar taşımak yerine customer_id ile Ahmet'e bağlanıyor. E-posta adresi değiştiğinde bütün eski siparişleri dolaşmam gerekmiyor.

orders, siparişin genel durumunu; order_items ise hangi üründen kaç adet alındığını saklıyor. Bir siparişte farklı ürünler bulunabileceği için ürün kalemlerini ayrı tutuyoruz.

Burada unit_price alanını özellikle sipariş kaleminde saklıyorum. Bu örnekte alan, indirim varsa onu da yansıtan satış anındaki birim fiyatı temsil etsin. Ahmet iki paket muzu paket başına 150 TL'den aldıysa sipariş tutarı 300 TL olur. Ürünün current_price değeri yarın değiştiğinde geçmiş siparişin fiyatını değiştirmek istemiyorum.

Bu iki fiyat alanı gereksiz bir kopya değil; biri güncel fiyatı, diğeri geçmiş satışın fiyatını anlatıyor. Veri modelini kurarken alanların yalnızca isimlerine değil, hangi bilgiyi temsil ettiklerine de bakmam gerekiyor.

Transaction: Birbiriyle İlgili Değişiklikleri Birlikte Tamamlamak

Transaction, database üzerindeki bir veya daha fazla işlemi bir bütün olarak ele aldığımız çalışma birimidir. Değişiklikleri COMMIT ile tamamlar, işlemden vazgeçtiğimizde veya hata durumunda ROLLBACK ile geri alırız.

Transaction kelimesi burada ödeme anlamına gelmiyor. Bir adres değişikliği veya kayıt silme de transaction içinde gerçekleşebilir. Önemli olan, database işlemlerinin hangi sınır içinde birlikte değerlendirildiğidir.

Transaction davranışını açıklamak için kullanılan ACID özellikleri şunlardır:

Atomicity: Transaction'ın değişiklikleri birlikte gerçekleşir; işlem tamamlanmazsa yarım değişiklikler kalıcı hale gelmez.
Consistency: Doğru tasarlanmış işlemler database'in tanımlı bütünlük kurallarını korur. Foreign key gibi kurallar bu sınırın parçasıdır.
Isolation: Database, eşzamanlı transaction'ların birbirlerinin değişikliklerini nasıl göreceğini yönetir. Davranış seçilen isolation level'a bağlıdır.
Durability: Database başarıyla commit ettiği değişiklikleri kalıcı tutma garantisi verir.

Ahmet'in siparişinde sipariş kaydı oluşturmak, ürün kalemini eklemek ve stoktan iki paket düşmek birlikte ele alınabilir:

BEGIN
  ↓
Sipariş kaydını oluştur
  ↓
Sipariş kalemini ekle
  ↓
Stok miktarını güncelle
  ↓
COMMIT

Bu değişiklikler aynı transaction içindeyse hata durumunda geri alabilirim. Böylece ürün kalemi oluşmadığı halde tamamlanmış görünen bir sipariş bırakmam.

Eşzamanlı stok kontrolünü de doğru tasarlamak gerekir. İki müşteri son ürünü aynı anda almaya çalışıyorsa kontrol ve güncellemeyi uygun koşullar veya kilitlemeyle yönetmeliyim. Sadece transaction başlatmak, uygulamadaki bütün iş kurallarını kendiliğinden doğru hale getirmiyor.

Sipariş kaydolduktan sonra uygulama günlük işlerini yapmaya devam edebilir. Şimdi aynı kayıtlara başka bir amaçla bakacağız.

Adım 2: OLAP ile Veriden Analiz Çıkarmak

OLAP, büyük veri kümeleri üzerinde analiz yapmaya odaklanan işlem yaklaşımıdır. Çok sayıda kaydı filtrelemek, gruplamak ve farklı dönemleri karşılaştırmak bu iş yükünde sık görülür.

Aggregation, birçok kayıttan toplam, ortalama veya adet gibi bir sonuç hesaplamaktır. SQL'deki SUM, AVG ve COUNT bu hesaplamalara örnek. Analizde kullandığımız satış tutarı veya ürün adedi gibi sayısal değerlere de measure diyebiliriz.

Bir measure'ı hangi açıdan inceleyeceğimizi ise dimension belirler. Tarih, ürün kategorisi veya mağaza gibi bilgiler, sonucu gruplamak ve filtrelemek için kullanabileceğimiz kırılımlardır. Böylece tek bir toplam yerine, o toplamın farklı bölümlerini inceleyebiliriz.

E-ticaret uygulamasında artık şu soruyu soralım:

2025 yılında aylara göre hangi ürün kategorisinden ne kadar satış yaptık?

Raporun kullanacağı kayıtların küçük bir bölümü şöyle olsun:

Tarih	Ürün	Kategori	Adet	Satış tutarı
12 Ocak 2025	Muz	Meyve	2	300 TL
13 Ocak 2025	Kahve	İçecek	1	120 TL
20 Ocak 2025	Muz	Meyve	1	150 TL
3 Şubat 2025	Muz	Meyve	1	150 TL
4 Şubat 2025	Kahve	İçecek	2	200 TL

Ahmet'in siparişi ilk satırda duruyor. Ocak ayının meyve satışlarını hesapladığımda onun 300 TL'lik siparişini, aynı ayın diğer 150 TL'lik muz satışıyla topluyorum. Bu örnekte sonuç 450 TL.

Satış tutarı measure, ay ve kategori ise analizin kırılımları. Başta tek bir siparişin durumuna bakıyorduk; şimdi birden fazla sipariş kaleminden sonuç çıkarıyoruz.

Analizin Ayrıntı Düzeyini Değiştirmek

OLAP analizinde aynı measure'ı farklı ayrıntı seviyelerinde inceleyebiliriz. Drill-down, yıllık toplamdan aylara veya aylardan günlere inmek gibi daha ayrıntılı bir seviyeye geçmeyi ifade eder. Roll-up ise ayrıntılı kayıtları daha üst bir seviyede toplar; günlük satışlardan aylık toplam çıkarmak buna örnek.

Bu geçişlerin mümkün olması, elimizdeki verinin ayrıntı düzeyine bağlıdır. Yalnızca aylık toplamı sakladıysak, günlük sonuçları o toplamdan geri çıkaramayız.

Örnekte Ocak ayındaki 450 TL'yi gördükten sonra günlere inebilirim. 12 Ocak'ta 300 TL, 20 Ocak'ta 150 TL meyve satışı görürüm. İki kaydı koruduğum için hem aylık rapor çıkarabiliyorum hem de o toplamın nasıl oluştuğunu inceleyebiliyorum.

OLAP İçin Mutlaka Ayrı Bir Sistem Gerekir mi?

OLAP bir kullanım biçimini tarif eder. İlişkisel bir database de JOIN ve GROUP BY gibi işlemlerle analitik sorgular çalıştırabilir. Küçük bir veri kümesinde mevcut database üzerinde rapor üretmek yeterli olabilir.

Ayrı bir analiz sistemi ihtiyacı, veri büyüklüğü ve sorguların yaptığı işle birlikte belirginleşir. Tek bir kaydı index üzerinden bulmakla geniş bir tarih aralığındaki tutarları okumak aynı maliyete sahip değildir. Analitik sorgu, uygulamanın günlük işlemleriyle aynı CPU, bellek ve disk kaynaklarını paylaşabilir.

Örnekte yıllık raporu PostgreSQL üzerinde çıkarabilirim. Ama rapor sorguları büyüdüğünde yeni siparişlerin yanıt süresini etkileyip etkilemediğine de bakmam gerekir. Fiziksel mağazaların satışlarını rapora eklemek istersem farklı kaynakları birleştirme ihtiyacı da doğar.

Bu noktada farkın bir bölümü sorgunun kapsamından, bir bölümü de verinin nasıl saklandığından geliyor.

Adım 3: Row-Based ve Column-Based Depolama

Row-based ve column-based storage, verinin fiziksel depolama düzenini anlatır. Tablo ekranda yine satır ve sütunlardan oluşabilir; değişen şey, database'in bu alanları depolama katmanında nasıl yerleştirdiğidir.

Bu ayrım, bir sorgunun ihtiyaç duyduğu verilere ulaşırken ne kadar veri okuduğunu etkileyebilir. Sorgu birkaç kaydın birçok alanını mı istiyor, yoksa çok sayıda kaydın yalnızca birkaç sütununu mu kullanıyor?

Row-Based Storage: Aynı Kaydın Alanları Birlikte

Satır odaklı depolamada aynı kayda ait alanlar birlikte yer alır. Belirli bir kaydın farklı alanlarını okumak veya o kayıt üzerinde değişiklik yapmak için uygun bir erişim düzenidir. Geleneksel OLTP sistemlerinde bu yaklaşım yaygındır.

Satış kayıtlarının ürün, adet ve tutar alanlarını kavramsal olarak şöyle gösterebiliriz:

[Muz,   2, 300]
[Kahve, 1, 120]
[Muz,   1, 150]
[Muz,   1, 150]
[Kahve, 2, 200]

Ahmet'in sipariş kalemini okuduğumda ürün, adet ve fiyat gibi alanları birlikte istiyorum. Satır odaklı yerleşim bu ihtiyaca uyuyor.

Ancak sadece bütün satış tutarlarını toplamak istersem satırları içeren depolama bloklarından, sorguda kullanmadığım alanları da okumam gerekebilir. Tabloda daha fazla sütun bulundukça bu fark büyüyebilir; gerçek maliyet sorgu planına ve depolama düzenine bağlıdır.

Column-Based Storage: Aynı Alanın Değerleri Birlikte

Sütun odaklı depolamada aynı sütuna ait değerler birlikte saklanır. Çok sayıda satırın az sayıda alanını kullanan sorgular, ihtiyaç duyduğu sütunların bloklarını okuyabilir. Benzer değerlerin bir arada bulunması sıkıştırmayı da kolaylaştırabilir.

Aynı örneğin sütun odaklı gösterimi şöyle olur:

Ürün:         [Muz, Kahve, Muz, Muz, Kahve]
Adet:         [2, 1, 1, 1, 2]
Satış tutarı: [300, 120, 150, 150, 200]

SUM(sales_amount) hesaplamak istediğimde yalnızca satış tutarı alanına ihtiyaç duyuyorum. Kategori bazında analiz yapıyorsam ilgili kategori bilgilerini de okurum; müşterinin adresi gibi raporda kullanmadığım alanları taşımam gerekmeyebilir.

Gerçek sistemlerde sütunlar bloklara ve farklı makinelere dağılabilir. Filtreler veya bölümleme sayesinde sütunun tamamı yerine ilgili bölümünü okumak yeterli olabilir. Çizim, bütün değerlerin tek ve kesintisiz bir yerde durduğunu söylemiyor.

Sütun odaklı sistemlere yeni veri yazmak da mümkündür. Bu sistemler toplu yüklemeler için optimizasyonlar kullanabilir; sık ve tekil satır güncellemelerinin maliyeti ise farklı olabilir. Aynı şekilde satır odaklı bir sisteme kayıt eklemek, index'ler ve bütünlük kontrolleri nedeniyle yalnızca yeni satırı diske koymaktan ibaret değildir.

Dolayısıyla “OLTP her zaman satır, OLAP her zaman sütun” kesin bir kural değil. Bu yerleşimler belirli erişim biçimlerini destekleyen yaygın tasarım tercihleridir. Verinin tablolar arasında nasıl modellendiği ise bundan ayrı bir karar; ona warehouse içinde döneceğiz.

Adım 4: Data Warehouse Nedir?

Data warehouse, analiz ve raporlama için tasarladığımız veri deposudur. Farklı kaynakların verilerini bir araya getirir, ortak tanımlarla düzenler ve tarihsel karşılaştırmalar için saklar. Kullanıcılar bu hazırlanmış veri üzerinden sorgular çalıştırabilir.

Buradaki düzen sadece dosyaların veya tabloların aynı yerde durmasıyla oluşmaz. Kaynakların alanlarını ortak anlamlara taşımak, ürün kodlarını eşleştirmek ve rapordaki hesapları tanımlamak gerekir. Bir kaynakta “satış” anlamına gelen kayıt, diğerinde farklı bir aşamayı temsil ediyorsa bunları doğrudan toplamak yanlış sonuç verebilir.

Warehouse genellikle satış veya finans gibi iş konuları etrafında düzenlenir. Veriyi farklı dönemlerde karşılaştırmak için tarihler ve gerektiğinde değişen bilgilerin geçmiş sürümleri de modelin parçası olur. Günlük uygulamada güncel duruma odaklanırken burada geçmişin hangi haliyle analiz edileceğini ayrıca düşünürüz.

Bu, warehouse'daki verinin hiçbir zaman değişmediği anlamına gelmez. Yeni kayıtlar yüklenebilir, hatalı veriler düzeltilebilir veya geç gelen bilgiler işlenebilir. Tarihsel analiz için önemli olan, bu değişiklikleri tanımlı kurallarla yönetmektir.

Database ile Data Warehouse Arasındaki İlişki

Database, veriyi saklama ve sorgulama için kullandığımız genel kavramdır. Warehouse da veritabanı teknolojileri kullanabilir. “Database mi, warehouse mı?” karşılaştırmasında çoğunlukla uygulamanın operasyonel database'i ile analitik veri deposunu karşılaştırıyoruz.

Operasyonel database, uygulamanın çalışma akışını destekler. Warehouse'ın modeli ve kaynakları ise raporlama ihtiyacına göre şekillenir. OLTP/OLAP işlem yaklaşımını, operasyonel database/warehouse ayrımı da bu yaklaşımı destekleyen veri düzenini anlatır.

Karşılaştırma	Operasyonel Database	Data Warehouse
Ana ihtiyaç	Günlük uygulama işlemlerini yürütmek	Analiz ve raporlama yapmak
Tipik erişim	Belirli kayıtlar üzerinde kısa okumalar ve değişiklikler	Geniş kayıt kümeleri üzerinde gruplama ve hesaplama
Veri düzeni	Uygulamanın iş kuralları ve ilişkileri	Ortak iş tanımları ve analitik model
Geçmiş	Uygulamanın ihtiyacına göre saklanır	Dönem karşılaştırmaları ve geçmişin yorumu için planlanır

Ahmet'in sipariş durumunu değiştirirken operasyonel database'e gidiyorum. Aylık satış raporunda ise warehouse'daki hazırlanmış satış verisini kullanabilirim. Uygulamanın database'i yıllarca sipariş saklayabilir; warehouse da birkaç dakika önce oluşan satışları içerebilir. Ayrımı yalnızca verinin yaşı belirlemiyor.

Satış Analizinde Warehouse Ne Kazandırır?

Warehouse kurarken veri kaynaklarını birleştirmenin yanında analiz yükünü ayrı yönetebiliriz. Bu, günlük uygulama işlemleri ile raporların aynı çalışma kaynakları için yarışmasını azaltmaya yardımcı olur. Karşılığında bir aktarım süreci kurmak, veri güncelliğini izlemek ve iki sistemin maliyetini yönetmek gerekir.

E-ticaret örneğinde internet siparişleriyle mağaza satışlarını birleştirelim. İnternet sisteminde muzun kodu 10, mağaza dosyasında MUZ-01 olabilir. Ortak ürün eşleştirmesi olmadan rapor bunları iki farklı ürün gibi sayabilir.

Benzer şekilde satış tutarının anlamını da belirlemem gerekiyor. Bu yazıdaki rapor tamamlanmış sipariş kalemlerinin indirim sonrası ürün tutarını hesaplasın; vergi, kargo ve iadeleri basit örneğin dışında tutalım. Gerçek kullanımda bu alanların her biri için iş kuralı gerekir.

Bu kararları hazırlık sırasında verdiğimde her rapor aynı satış tanımından hareket edebilir. Şimdi bu ortak veriyi warehouse içinde nasıl düzenleyeceğimize bakalım.

Adım 5: Fact ve Dimension ile Analitik Model Kurmak

Dimensional modeling, analiz için veriyi olaylar ve bu olayları açıklayan bilgiler etrafında düzenleme yaklaşımıdır. Amaç, hangi değerleri ölçtüğümüzü ve bunları hangi kırılımlarda inceleyebileceğimizi modelde görünür hale getirmek.

Fact table, satış gibi gerçekleşen olayları ve bu olaylara ait ölçümleri saklar. Dimension table ise olayları tarih, ürün veya müşteri gibi açılardan açıklayan bilgileri tutar. Fact içindeki anahtarlar, ilgili dimension kayıtlarına bağlanır.

Bu ayrım, raporun her defasında operasyonel sistemdeki bütün ilişkileri çözmesi yerine analize uygun bağlantılarla çalışmasını sağlar. Modelin doğru kurulması performans kadar hesapların anlamını da etkiler.

Satış örneğinde adet ve tutarı fact_sales içinde tutabiliriz. Ürünün adı ve kategorisi dim_product, tarih bilgileri ise dim_date içinde yer alabilir. Böylece satış miktarını ürün veya zaman kırılımıyla birlikte sorgulayabiliriz.

Grain: Bir Satır Tam Olarak Neyi Temsil Ediyor?

Grain, fact table'daki bir satırın temsil ettiği ayrıntı düzeyidir. Satır bir siparişin tamamını, tek bir sipariş kalemini veya günlük kategori toplamını temsil edebilir. Bu kararı baştan vermek, hangi measure'ları hangi düzeyde tutabileceğimizi belirler.

Farklı ayrıntı seviyelerini aynı hesapta karıştırırsak veriyi yanlış sayabiliriz. Bir siparişin toplamını her ürün kalemine tekrar yazmak, kalemleri topladığımızda aynı sipariş tutarını birkaç kez hesaba katmamıza neden olur.

Bizim fact_sales tablomuzda her satır tek bir sipariş kalemini temsil etsin. Ahmet'in iki paket muz aldığı kalem için adet 2, tutar 300 olur. Aynı siparişte kahve de olsaydı kahve ayrı bir satırda dururdu; iki satırın tutarlarını topladığımda siparişin ürün toplamına ulaşabilirdim.

Warehouse'da yalnızca günlük veya aylık toplam tutmamız gerekmez. Bu ayrıntılı kayıtları koruyarak farklı seviyelerde rapor çıkarabiliriz. Sık kullanılan sonuçlar için ayrıca özet tablolar hazırlamak mümkün; hangi ayrıntıyı saklayacağımızla hangi hesabı önceden yapacağımız ayrı kararlar.

Star Schema: Fact ve Dimension Tablolarını Bağlamak

Star schema, dimension tablolarının merkezdeki fact table'a doğrudan bağlandığı modeldir. Fact, olayın ölçümlerini ve dimension anahtarlarını tutar; dimension tablolarındaki alanlar filtreleme ve gruplama için kullanılır.

Dimension anahtarı, kaynak uygulamadaki kimlikle aynı olmak zorunda değildir. Warehouse içinde ayrı bir anahtar üretebiliriz. Bu, farklı kaynakların kayıtlarını eşleştirmeyi ve gerektiğinde bir varlığın geçmiş sürümlerini ayrı tutmayı kolaylaştırır.

Örnekteki model şöyle görünebilir:

dim_date                  fact_sales                  dim_product
  date_key          ←       date_key
  full_date                 product_key         →       product_key
  year                      order_item_id               product_id
  month                     quantity                    product_name
                            sales_amount                category_name

date_key, satışın ait olduğu tarih kaydına; product_key ise ürün dimension'ındaki kayda bağlanıyor. Bu örnekte satış tarihi için siparişin oluşturulma tarihini kullanıyoruz. Başka bir rapor ödeme veya teslim tarihini esas alabilir; tarih seçimi de raporun tanımına ait.

dim_date içinde yıl ve ayın yanında hafta veya hafta sonu bilgisi de saklayabilirim. Böylece aynı satış verisini farklı zaman kırılımlarında inceleyebilirim. dim_product ise ürün adıyla birlikte kategoriyi veriyor.

Denormalization: Analizde Gereken Bilgileri Bir Araya Getirmek

Denormalization, belirli sorguların ihtiyaç duyduğu bilgileri daha az ilişki üzerinden okuyabilmek için bazı verileri bir arada tutma veya kontrollü biçimde tekrar etme yaklaşımıdır. Normalization ile farklı bir kullanım ihtiyacına cevap verir.

Analitik modelde dimension'ların açıklayıcı alanlarını bir arada tutmak yaygındır. Bunun karşılığında veri hazırlama sırasında tekrarların doğru güncellenmesini yönetmemiz gerekir. Join sayısının azalması bazı sorguları kolaylaştırabilir, ancak daha az normalization her koşulda daha yüksek hız garantisi vermez.

Snowflake schema, bazı dimension bilgilerini ayrı ilişkili tablolara bölerek daha normalize biçimde düzenleyen modeldir. Veri tekrarını azaltabilir ama sorguda ek bağlantılar gerektirir. Star schema ile arasındaki fark, dimension bilgilerinin ne kadar ayrıştırıldığıyla ilgilidir.

Operasyonel modelde ürün ile kategoriyi ayrı tablolarda tutmuştuk. Warehouse'da category_name alanını dim_product içine koyabiliriz. Böylece rapor, ürün dimension'ına bağlandığında kategori bilgisine de ulaşır. Kategoriyi ayrı bir dimension olarak tutup ürün dimension'ını ona bağlarsam snowflake yaklaşımına geçmiş olurum.

Bizim basit satış raporumuzda star schema ile ilerleyebiliriz. Fact ile dimension tablolarını yine join edeceğiz. OLAP sistemlerinin join yapmadığı gibi bir kural yok; modelde analizin ihtiyaç duyduğu ilişkileri kullanıyoruz.

Değişen Dimension Bilgilerinin Geçmişini Korumak

Slowly Changing Dimensions (SCD), dimension alanları değiştiğinde geçmişi nasıl yöneteceğimizi ele alan yöntemlerdir. Yeni değerin eski kaydın üzerine yazılmasıyla ayrı bir sürüm olarak saklanması, raporun geçmişi yorumlama biçimini değiştirir.

Type 1 yaklaşımı eski değeri günceller ve o alanın geçmiş sürümünü korumaz. Type 2 ise yeni bir dimension satırı açarak sürümleri saklar; geçerlilik tarihleriyle hangi sürümün hangi döneme ait olduğunu belirleyebiliriz.

Kahveyi bugün “İçecek” kategorisinden “Kahve ve Çay” kategorisine taşıdığımızı düşünelim. Type 1 kullandığımda geçmiş satışlar da güncel kategori altında görünebilir. Type 2 kullandığımda ise yeni kategori için ayrı bir ürün sürümü oluşturur, eski satışları eski sürüme bağlı tutarım.

Hangi davranışın doğru olduğu raporun sorusuna bağlı. Geçmişi o dönemdeki sınıflandırmayla mı görmek istiyorum, yoksa bütün yılları bugünkü kategorilere göre mi karşılaştıracağım? Warehouse kurarken bunu da belirlemem gerekiyor.

Artık satışın ne anlama geldiğini ve onu hangi modelde saklayacağımızı biliyoruz. Sıradaki iş, kaynak veriyi bu modele ulaştırmak.

Adım 6: ETL ve ELT ile Veriyi Taşımak ve Dönüştürmek

Veriyi kaynak sistemlerden alıp başka bir veri deposuna hazırlayan akışlara data pipeline diyebiliriz. Bu akış veri çekme, kontrol etme ve hedefe yazma gibi işleri birbirine bağlar. Kaynak bir database olabileceği gibi bir API veya dosya da olabilir.

Extract, veriyi kaynaktan alma adımıdır. Transform, veriyi hedef kullanım için dönüştürmeyi; Load ise hedefe yüklemeyi ifade eder. Tarih formatlarını eşitlemek, kaynak ürün kodlarını eşleştirmek veya satış tutarını hesaplamak dönüşüme örnek.

ETL ve ELT, bu adımların hangi sırayla ve nerede gerçekleştiğini ayırır. İkisinde de analize uygun veri üretmek istiyoruz; dönüşümün hedefe yüklemeden önce veya sonra yapılması çalışma biçimini değiştiriyor.

ETL: Önce Dönüştürmek, Sonra Yüklemek

ETL (Extract, Transform, Load) akışında veriyi alır, hedefe yüklemeden önce bir işlem ortamında dönüştürür ve hazırladığımız sonucu hedefe yazarız. Dönüşüm, hedef warehouse'ın dışında çalışan bir işlem tarafından yürütülebilir.

Bu düzen, hedefe hangi verinin hangi biçimde gireceğini yükleme öncesinde kontrol etmeyi sağlar. Dönüşüm ortamının işlem kapasitesi ve hata durumları da akışın parçasıdır; veriyi almakla başarıyla yüklemek arasında izlememiz gereken işler vardır.

Sipariş örneğinde orders ile order_items kayıtlarını alıp ilgili alanları birleştirebilirim. Tamamlanmış siparişleri seçer, quantity × unit_price ile ürün tutarını hesaplar ve uygun dimension anahtarlarını bulurum. Ardından hazırladığım satış satırlarını fact_sales tablosuna yazarım.

Operasyonel Database
        ↓ Extract
Siparişleri ve sipariş kalemlerini al
        ↓ Transform
Kontrol et, birleştir, tutarı hesapla, anahtarları eşleştir
        ↓ Load
Hazırlanan kayıtları fact_sales tablosuna yükle

Ahmet'in iki paketlik sipariş kalemi bu akışın sonunda quantity = 2 ve sales_amount = 300 değerleriyle warehouse'a ulaşır.

ELT: Önce Yüklemek, Sonra Hedefte Dönüştürmek

ELT (Extract, Load, Transform) akışında veriyi önce hedef sistemin ham veri alanına yükler, dönüşümleri daha sonra o sistemin işlem gücüyle yaparız. Warehouse içinde çalışan SQL sorguları, ham tablolardan analitik tablolar üretebilir.

Ham veriyi almakla analize hazır veri sunmak farklı aşamalardır. Kaynak tabloların hedefe yüklenmesi, raporun bunları doğrudan kullanması gerektiği anlamına gelmez. Kontroller ve iş kuralları, dönüşüm sırasında yine uygulanır.

Örnekte sipariş ve sipariş kalemi tablolarını warehouse'ın ham alanına alabilirim. Ardından orada çalışan sorgularla tamamlanmış siparişleri seçer, fiyat hesaplarını yapar ve fact_sales tablosunu oluştururum:

Operasyonel Database
        ↓ Extract
Kaynak kayıtları al
        ↓ Load
Warehouse'ın ham veri alanına yükle
        ↓ Transform
Hedefteki sorgularla dimension ve fact tablolarını hazırla

ETL ile aynı satış sonucunu elde edebilirim. Fark, dönüşümün warehouse'a girmeden önce mi yoksa girdikten sonra mı çalıştığı.

Bu yöntemler sadece OLTP'den OLAP'e geçişte kullanılmaz. Mağazanın gönderdiği bir CSV dosyasını temizleyip yüklemek veya bir API'den gelen kayıtları hedef tabloya hazırlamak da ETL ya da ELT akışı olabilir.

Staging ve Data Lake Hangi İhtiyacı Karşılıyor?

Staging, gelen veriyi karşılamak ve sonraki işlem için hazırlamak amacıyla kullandığımız ara alanı ifade eder. Kayıtları kontrol etmek veya bir yükleme grubunu diğerinden ayırmak için kullanılabilir. ETL ve ELT akışlarının ikisinde de staging bulunabilir.

Data lake ise farklı türlerdeki veriyi, çoğu zaman kaynakta gelen ham biçimini de koruyarak saklayabildiğimiz alandır. Tablo verilerinin yanında JSON event'leri, görseller veya ses dosyaları da burada yer alabilir. Veriyi ham saklamak, ne içerdiğini belgelemek ve erişimini yönetmek ihtiyacını ortadan kaldırmaz.

Satış örneğinde mağazanın gönderdiği CSV dosyasını önce staging alanına alıp satırlarını kontrol edebilirim. Dosyanın orijinal halini ileride tekrar işlemek için data lake içinde saklamayı da tercih edebilirim. Böylece dönüşüm kuralını değiştirdiğimde kaynak dosyaya dönebilirim.

Her aktarımda ayrı bir data lake kurmak zorunda değilim. Veriyi doğrudan warehouse'a yükleyebilirim; bu bileşenlerin yerini, saklama ve yeniden işleme ihtiyacı belirler.

Adım 7: Verinin Güncelliğini ve Aktarımın Doğruluğunu Yönetmek

Bir pipeline'ın dönüşüm sırası kadar ne zaman çalıştığı da önemlidir. Raporun veri güncelliği, kaynaktaki değişikliklerin analitik sisteme ne kadar gecikmeyle ulaştığına bağlıdır.

Batch processing, belirli bir veri grubunu toplu işlemektir. İş saatlik veya günlük çalışabilir; bir dosyanın gelmesi de işlemi başlatabilir. Stream processing ise sürekli gelen veri akışını işleme yaklaşımıdır. Her kaydın sıfır gecikmeyle sonuçlanacağını garanti etmez; hedef daha kısa gecikmelerle akışı işlemektir.

Günlük satış raporunda siparişleri gece toplu aktarmak yeterli olabilir. Ahmet'in bugün verdiği sipariş, aktarım tamamlandıktan sonra yarınki raporda görünür. Satış ekranının gün içinde güncellenmesi gerekiyorsa daha sık yükleme veya değişiklikleri sürekli işleyen bir akış seçebilirim.

ETL/ELT ile batch/stream farklı kararları anlatır. İlki dönüşümün yüklemeye göre sırasıyla, ikincisi veriyi işleme biçimiyle ilgilidir.

Aynı Veriyi Tekrar Aktardığımızda Ne Olur?

Artımlı yükleme, her seferinde bütün kaynağı almak yerine yeni veya değişen kayıtları aktarma yaklaşımıdır. Bunun için hangi değişikliklerin gerçekleştiğini takip etmemiz gerekir. Güncellemeler kadar silmelerin hedefe nasıl yansıtılacağını da belirlemeliyiz.

CDC (Change Data Capture), kaynaktaki ekleme, güncelleme ve silmeleri yakalamaya yarayan yaklaşımı ifade eder. Bu değişiklikleri veri aktarımına girdi olarak kullanabiliriz. Hangi yöntemi seçeceğimiz, kaynak sistemin sunduğu imkanlara ve gerekli güncelliğe bağlıdır.

Örnekte her gece bütün sipariş geçmişini kopyalamak yerine yeni ve değişen siparişleri alabilirim. Ancak aktarım yarıda kalırsa aynı kayıtları yeniden işlemek gerekebilir. Ahmet'in siparişini ikinci kez eklersem 300 TL'lik satış raporda 600 TL görünür.

Bu yüzden kaydı hangi anahtarla tanıyacağımı ve tekrar geldiğinde nasıl davranacağımı belirlemem gerekiyor. Tek kaynaklı örnekte order_item_id satış kalemini tanıyabilir; farklı kaynakları birleştirdiğimde kaynak kimliğini de dikkate almam gerekir. Bir mağazanın 1042 numaralı kaydı, internet sistemindeki aynı numarayla aynı olay olmayabilir.

Pipeline'ın başarılı çalışması da yalnızca hata vermeden bitmesi değildir. Beklenen veriyi alıp almadığını kontrol etmeli, eksik veya başarısız aktarımda raporu güncelmiş gibi göstermemeliyim. Verinin doğruluğunu korumak, rapor sorgusundan önce başlayan bir iş.

Adım 8: BI ve Data Mart ile Hazırlanan Veriyi Kullanmak

BI (Business Intelligence), veriyi raporlar ve analizlerle iş kararlarında kullanılabilir hale getiren çalışmaların ve araçların genel adıdır. Bir BI aracı veri kaynağına bağlanabilir, ölçümleri hesaplayabilir ve sonuçları grafik veya dashboard olarak sunabilir.

Warehouse bu kullanım için düzenlenmiş veriyi sağlar. Rapor katmanı da bu veri üzerinde hangi measure'ların nasıl gösterileceğini belirler. Veri doğru gelse bile raporda farklı filtre veya hesap kullanmak sonucu değiştirebilir; modelin anlamını raporda da korumak gerekir.

Örnekte artık başta sorduğumuz soruya dönebiliriz:

2025 yılında aylara göre hangi ürün kategorisinden ne kadar satış yaptık?

Hazırladığımız modelde sorgu şöyle olabilir:

SELECT
    d.year,
    d.month,
    p.category_name,
    SUM(f.sales_amount) AS total_sales
FROM fact_sales AS f
JOIN dim_date AS d ON d.date_key = f.date_key
JOIN dim_product AS p ON p.product_key = f.product_key
WHERE d.year = 2025
GROUP BY d.year, d.month, p.category_name
ORDER BY d.year, d.month, total_sales DESC;

fact_sales, sipariş kalemlerinin tutarını veriyor. dim_date ile yıl ve ayı, dim_product ile kategoriyi öğreniyoruz. WHERE yalnızca 2025'i seçiyor; GROUP BY ise aynı ay ve kategoriye ait satışları birlikte hesaplamamızı sağlıyor.

İkinci bölümdeki beş örnek kayıtla beklenen sonuç şu olur:

Yıl	Ay	Kategori	Toplam satış
2025	1	Meyve	450 TL
2025	1	İçecek	120 TL
2025	2	İçecek	200 TL
2025	2	Meyve	150 TL

Ocak ayındaki 450 TL'nin 300 TL'si Ahmet'in siparişinden, kalan 150 TL'si aynı ayın diğer muz satışından geliyor. Ahmet'in kaydı warehouse'da ayrı bir satış kalemi olarak duruyor; raporda ise başka kayıtlarla aynı grupta yer alıyor.

Bir BI aracı bu sonucu aylık kategori grafiği olarak gösterebilir. Günlük ayrıntıya indiğimde yıl ve ayın yanında gün bilgisini de kullanırım. Bunun mümkün olması, satışları sipariş kalemi düzeyinde saklamamıza bağlı.

Data Mart: Belirli Bir Konuya Odaklanmak

Data mart, satış veya finans gibi belirli bir konuya odaklanan analitik veri kümesidir. Bir warehouse'ın ilgili bölümünden oluşturulabilir; ayrı bir depolama yapısı veya mantıksal veri modeli olarak sunulabilir. Her mart'ın mutlaka merkezi bir warehouse'dan gelmesi gerekmez.

Amaç, belirli kullanıcıların ilgilendiği verilere ve tanımlara daha kolay ulaşmasını sağlamaktır. Konuya odaklanmak karmaşıklığı azaltabilir; erişim güvenliğini ise ayrıca yetkilendirme kurallarıyla uygulamamız gerekir.

Bizim örnekte warehouse ileride satış dışındaki konuları da içerebilir. Satış ekibine fact_sales ve ilgili dimension'ları içeren bir satış mart'ı sunarak raporlarında kullanacakları modeli daraltabilirim. İlgisiz tabloları incelemek zorunda kalmazlar.

Diğer verilere erişmelerini engellemek istiyorsam gerekli izinleri de tanımlarım. Bir veri kümesine data mart adını vermek, tek başına güvenlik sınırı oluşturmuyor.

Ahmet'in siparişini uygulamada kaydetmekle başlayan yol, böylece satış raporuna ulaşıyor. İşlem sırasında gereken ayrıntıları OLTP tarafında yönettik; analize uygun modeli hazırlayıp OLAP sorgusuyla sonucu çıkardık.

Kendime Notlar

Bu konuları çalışırken OLTP, OLAP ve warehouse başta ayrı araç isimleri gibi görünüyordu. Aynı siparişi takip ettiğimde, bunların hangi ihtiyaca cevap verdiği daha anlaşılır hale geldi.

OLTP tarafında kısa süren okumalar ve değişiklikler var. OLAP tarafında ise birçok kaydı birlikte hesaplayıp sonucu farklı kırılımlarda inceliyoruz. Bu yüzden yalnızca “write için biri, read için diğeri” demek, iki taraftaki işlemleri açıklamaya yetmiyor.

Row-based ve column-based depolama, hangi alanlara nasıl eriştiğimi anlamama yardımcı oluyor. Normalization ve denormalization ise veriyi hangi ilişkilerle düzenlediğimle ilgili. Fiziksel depolamayla veri modelini ayrı düşündüğümde, tercihlerinin nedenlerini daha rahat takip edebiliyorum.

Warehouse kurarken veriyi taşımak kadar raporun anlamını belirlemek de gerekiyor. Ahmet'in satış anındaki fiyatını saklamasaydım yanlış tutar hesaplayabilirdim; aynı kalemi aktarımda iki kez ekleseydim toplamı şişirirdim. Raporun doğru olması, sorgudan önceki adımların da doğru olmasına bağlı.

Küçük bir uygulamada mevcut database üzerinde rapor çıkarmak yeterli olabilir. Analiz yükü, veri kaynakları ve tarihsel karşılaştırma ihtiyacı büyüdükçe ayrı bir warehouse'ın sağladığı düzen daha anlamlı hale geliyor.

Bir veri sistemiyle çalışırken önce hangi işlemi tamamlamak veya hangi soruyu cevaplamak istediğime bakmak istiyorum. Depolama biçimi, model ve aktarım kararları da bu sorunun ardından geliyor.

Koddan Deployment'a

TAHA TÜZEL — Tue, 06 Oct 2026 15:46:23 +0000

Lokal ortamda frontend'i, backend'i ve veritabanını ayrı ayrı çalıştırıyorum. Hepsi benim bilgisayarımda sorunsuz açılıyor; peki aynı uygulamayı başka bir makineye taşıdığımda ne değişiyor? Runtime sürümü, bağlantı adresleri ve servislerin birbirini bulması da artık benim sorumluluğumda.

Docker, test, CI/CD ve deployment başlıklarını çalışırken bunları kodun izlediği tek bir yol olarak anlamak istedim. Image'ı sunucuya nasıl taşıyorum, yeni sürüm eskisinin yerini nasıl alıyor, bir şey ters giderse bunu hangi kontrol gösteriyor?

Bu sorular için Nuxt, .NET API ve PostgreSQL kullanan küçük bir To-do uygulaması hazırladım. Git to Prod projesinde uygulamanın kendisini basit tuttum; asıl odağım kodu paketleyip test etmek ve K3s'e kadar götürmek oldu. Yazıda önce çalışma notlarımdaki teoriyi anlatıp her adımda projeden kod veya deployment denemesiyle örnekleyeceğim.

Bu nedenle anlatı container ve image ile başlayıp testlere, CI/CD'ye ve K3s deployment'ına ilerliyor. Her bölümde aynı soruyu takip edeceğim: Bu aşama zincire ne katıyor ve projedeki kodda bunu nerede görebiliyorum?

Büyük Resim: Kod Nasıl Çalışan Uygulamaya Dönüşüyor?

Yazdığımız kodun kullanıcıya ulaşmasını kabaca şöyle düşünebiliriz:

Kod değişikliği
    ↓
Otomatik kontroller ve testler
    ↓
Uygulamayı container image olarak paketleme
    ↓
Image'ı saklanacağı depoya (registry) gönderme
    ↓
Hedef ortamda yeni sürümü çalıştırma (deployment)
    ↓
Yeni sürümün çalıştığını kontrol etme

Bu, Git to Prod projesinde kurduğum akışın da özeti. Gerçek pipeline biraz daha somut ilerliyor:

Pull request
    ↓
Backend ve frontend kontrolleri
    ↓
main'e push veya elle Release başlatma
    ↓
Kontrolleri tekrar çalıştırma
    ↓
EF Core migration → PostgreSQL VM
    ↓
Commit SHA etiketli image'lar → GHCR
    ↓
Manifestleri K3s'e uygulama ve rollout'u bekleme
    ↓
ALB üzerinden ana sayfa ve API kontrolü

Yazının ana hattı bu: Her adım bir sonraki adıma bir çıktı bırakıyor. Testler kodun seçilmiş davranışlarını kontrol ediyor; Docker bu kodu image'a paketliyor; registry belirli image sürümünü saklıyor; K3s de manifestteki sürümü çalıştırmaya çalışıyor. Son HTTP kontrolü, zincirin dışarıdan erişilen ucunun da yanıt verdiğini gösteriyor.

Bir de veritabanı şeması değişebilir. Bu durumda uygulama koduyla birlikte şema güncellemesinin sırasını da düşünmem gerekiyor; deployment bölümünde buna döneceğim.

Adım 1: Docker ve Container Mantığı

Kaynak kodunu başka bir makineye kopyalamak, uygulamanın orada çalışacağı anlamına gelmiyor. O makinede farklı bir runtime sürümü olabilir; ihtiyaç duyduğum kütüphaneler de kurulu olmayabilir.

Benim bilgisayarımda çalışıyordu.

Container (konteyner), uygulamayı izole bir process olarak çalıştırır. Uygulama dosyalarını ve bağımlılıklarını bir image içinde paketlediğimde hedef makinede aynı dosyaları yeniden kurmak yerine bu image'dan container başlatabilirim.

İzolasyon, farklı uygulamaların kendi bağımlılıklarıyla aynı makinede çalışmasını sağlar. Container'lar host'un CPU ve RAM'ini paylaşır; process ve dosya alanlarını ayırır.

VM kendi işletim sistemini çalıştırır. Linux container'ları ise aynı Linux kernel'ini paylaşır; her container için baştan ayrı bir işletim sistemi açılmaz. Windows ve macOS üzerinde Docker Desktop, Linux container'ları sanallaştırılmış Linux ortamında çalıştırır.

Docker, image hazırlamak ve container çalıştırmak için kullandığım araçları sağlar. Paket aynı kalabilir, ama uygulamanın bağlanacağı veritabanı ve ağ erişimini yine ayarlamam gerekir.

Dockerfile, Image ve Container Arasındaki İlişki

Bu kavramların birbiriyle ilişkisi şöyle:

Kavram	Görevi
Dockerfile	Image'ı hazırlamak için gereken komutları tarif eder.
Image	Uygulama dosyalarını ve çalışma ortamını içeren pakettir.
Container	Image'dan başlattığımız uygulamanın izole çalışma ortamıdır.

Dockerfile → docker build → Image → docker run → Container

docker build, Dockerfile'daki talimatlarla image hazırlar; docker run bu image'dan container oluşturup başlatır.

Aynı image'dan birden fazla container başlatabilirim. Her biri kendi process'lerini ve yazılabilir katmanını kullanır. Bu ayrım, uygulamanın değişmeyen paketiyle çalışırken ürettiği veriyi ayrı düşünmemi sağlıyor.

Image Katmanları ve Build Cache

Dockerfile'daki komutların sırası build süresini etkiler. Docker her adımın sonucunu saklayabilir; bir adım değiştiğinde sonraki adımların da yeniden çalışması gerekebilir.

Örneğin önce paket listesini kopyalayıp bağımlılıkları yükler, sonra kaynak kodu kopyalarsam yalnızca kod değiştiğinde bağımlılık kurulumunu tekrar etmeyebilirim. Projedeki frontend Dockerfile'ında bu sıralama var:

COPY package.json package-lock.json ./
RUN npm install --global npm@11.17.0 && npm ci

COPY . ./
RUN npm run build

Bu sıralama, kaynak dosyaları her değiştiğinde bağımlılıkları baştan kurmamamı sağlıyor. Docker önce değişmeyen paket listesi adımını önbellekten kullanabilir.

Build sırasında gereksiz dosyaları .dockerignore ile dışarıda bırakıyorum. Özellikle parola içeren yerel ayar dosyalarını image'a kopyalamıyorum.

Derleme Ortamı ile Çalışma Ortamını Ayırmak

Derleme araçlarını son image'a taşımam gerekmiyor. Multi-stage build, derleme ve çalıştırma aşamalarını ayırıyor; backend Dockerfile'ında önce .NET SDK, ardından yalnızca uygulama runtime'ı kullanılıyor:

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /source

COPY src/ ./src/
RUN dotnet restore ./src/Api/Api.csproj
RUN dotnet publish ./src/Api/Api.csproj \
    --configuration Release \
    --no-restore \
    --output /app/publish
RUN rm /app/publish/appsettings.Development.json

FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS runtime
WORKDIR /app

ENV ASPNETCORE_HTTP_PORTS=8080
COPY --from=build /app/publish ./

USER $APP_UID
EXPOSE 8080
ENTRYPOINT ["dotnet", "Api.dll"]

İlk aşama kaynak kodunu yayıma hazırlıyor, ikinci aşama bu çıktıyı alıyor. SDK son image'a girmiyor. Container uygulamayı root yetkisi olmayan kullanıcıyla başlatıyor; ENTRYPOINT ise çalıştırılacak komutu belirliyor.

EXPOSE 8080, uygulamanın dinleyeceği port'u belirtir; tek başına dış erişim açmaz.

Frontend'in nasıl paketleneceği uygulamanın yapısına bağlı. Projedeki Nuxt, sunucu tarafında da kod çalıştırıp API çağrılarını ilettiği için runtime image'ında Node.js bulunuyor.

Docker Compose ile Servisleri Birlikte Çalıştırmak

Bir uygulama birden fazla servisten oluştuğunda her container için ayrı komut yazmak zorlaşır. Docker Compose, bir uygulamanın servislerini tek dosyada tanımlayıp birlikte başlatmayı, durdurmayı ve incelemeyi sağlayan araçtır. Hangi image'ın kullanılacağını, çalışma ayarlarını ve servislerin iletişimini burada tarif ederim.

Compose'ta servis, frontend veya backend gibi adı olan bir uygulama bileşeninin tanımıdır. Bu tanımdan container oluşturulur. Compose varsayılan olarak proje için ortak bir ağ oluşturur ve servisler bu ağda isimleriyle birbirine ulaşır.

Projedeki Compose dosyasının frontend bölümü şöyle:

frontend:
  build:
    context: ./frontend
    dockerfile: Dockerfile
  depends_on:
    - backend
  environment:
    NUXT_API_BASE_URL: http://backend:8080
  ports:
    - "3000:3000"
  restart: unless-stopped

Bu bölüm services altında bulunuyor. build.context, build sırasında erişilebilecek dizini; dockerfile, talimatların bulunduğu dosyayı seçiyor. environment çalışma ayarlarını, ports host üzerinden erişim eşlemesini belirliyor. restart: unless-stopped, elle durdurulmadığı sürece container için yeniden başlatma politikası tanımlıyor.

depends_on, frontend'den önce backend container'ının başlatılmasını sağlar.

Docker Compose ile tanımlanan bir proje, gerekli bağlantı ayarları ve dış bağımlılıkları hazır olduğunda şu komutla ayağa kaldırılabilir:

docker compose up --build

Compose dosyasının bulunduğu dizinde --build image'ları hazırlıyor, up container'ları başlatıyor. Çalışan servisleri docker compose ps, log'ları ise docker compose logs ile inceleyebilirim.

docker compose down ise Compose'un oluşturduğu container'ları ve proje ağını kaldırır; named volume'ları varsayılan olarak silmez.

Container Ağı: `localhost` Nereye Bakıyor?

Birden fazla container başlattığımda her birinin kendi ağ ortamı ve localhost adresi bulunur. localhost, isteği gönderen process'in çalıştığı makineyi ya da container'ı gösterir. Bu yüzden frontend container'ındaki localhost, backend container'ı değil, frontend'in kendisidir.

Compose dosyasında servisleri tanımladığımda Compose varsayılan bir network oluşturur ve bu servisleri o ağa bağlar. Aynı network'teki bir servis, diğerine değişebilen IP adresiyle değil servis adıyla ulaşabilir. Docker bu adı ilgili container'ın güncel IP'sine çözer. Projedeki ayarlar bu farkı gösteriyor:

services:
  backend:
    ports:
      - "5157:8080"
  frontend:
    environment:
      NUXT_API_BASE_URL: http://backend:8080
    ports:
      - "3000:3000"

Tarayıcı benim bilgisayarımda http://localhost:3000 adresinden Nuxt uygulamasını açar. Görev listesi istenirken tarayıcı aynı adreste /api/todo-items yoluna request gönderir. Nuxt'un server tarafındaki API route'u bu isteği alır ve backend'e iletir:

Browser
  │ http://localhost:3000/api/todo-items
  ▼
Host'taki 3000 portu → frontend container'ındaki 3000 portu
  │
  ▼
Nuxt server
  │ http://backend:8080/api/todo-items
  ▼
backend servis adı → backend container'ının 8080 portu

Nuxt burada reverse proxy gibi davranıyor; tarayıcıdan gelen request'i alıp iç network'teki backend'e aktarıyor. Bu nedenle backend:8080 adresini tarayıcının bilmesi gerekmiyor. Bu adresi Nuxt server kullanıyor. Tarayıcı yalnızca kendi açtığı localhost:3000 adresine request gönderiyor.

Buradaki iki port eşlemesi farklı yerlerden erişim sağlıyor. 3000:3000, benim bilgisayarımdaki 3000 portunu frontend container'ındaki 3000'e; 5157:8080 ise host'taki 5157'yi backend container'ındaki 8080'e bağlıyor. Yazım sırası host:container şeklinde:

ports:
  - "5157:8080"

Dolayısıyla host'taki bir araçla backend'e giderken localhost:5157, Compose network'ündeki frontend'den giderken backend:8080 kullanırım. Frontend ile backend'in konuşması için backend port'unu host'a yayınlamak şart değil; bu projede ports eşlemesi ayrıca host'tan test edebilmeyi de sağlıyor. Bir bağlantı hatasında hangi process'in hangi ağda bulunduğunu ve adresi nereden kullandığını kontrol etmek bu yüzden önemli.

Container Silinirse Veri Ne Oluyor?

Image, uygulamanın ve çalışma ortamının paketidir; container ise bu image'dan başlatılan çalışan kopyadır. Container çalışırken dosya yazarsa bu değişiklikler container'ın kendi yazılabilir katmanına gider. Container'ı durdurup yeniden başlatmak bu katmanı korur, ancak container'ı silip yenisini oluşturduğumda eski container'a ait katman da silinir. Veritabanı kayıtlarını burada tutarsam yeni sürüme geçerken veriyi kaybedebilirim.

Volume, container'ın ömründen ayrı tuttuğum depolama alanıdır. Volume'u container içindeki bir dizine bağlarım; uygulama o dizine yazdığında veri container'ın geçici katmanına değil volume'a gider. Yeni container'ı aynı volume ile başlatınca veriye erişmeye devam ederim.

Named volume'u Docker bir isimle yönetir. Container silinse bile volume ayrıca silinmedikçe kalır; yeni container'a aynı named volume'u bağlayabilirim. Bu, veriyi container'dan ayırır ama yedek anlamına gelmez. Volume host'un diskinde duruyorsa host'u kaybetmek volume'u da kaybettirebilir.

Bind mount ise host'ta seçtiğim dosya veya dizini container içindeki bir yola bağlar. Kaynağı Docker'ın yönettiği bir alan olarak değil, benim bilgisayarımdaki belirli bir yol olarak belirtirim. Git to Prod README'sinde geliştirme sırasında backend ayar dosyasını container'a bağlamak için şu örnek veriliyor:

services:
  backend:
    volumes:
      - ./backend/src/Api/appsettings.Development.json:/app/appsettings.Development.json:ro

İki yolun arasındaki : ayıracının solunda host'taki dosya, sağında container içindeki hedef yol bulunur. Sondaki :ro mount'u salt okunur yapar. Backend dosyayı container içindeki /app/appsettings.Development.json yolundan okur; ayar dosyasını image'a kopyalamam veya her değişiklikte image'ı yeniden üretmem gerekmez.

Bu mount, ana Compose tanımına eklenen yerel geliştirme ayarıdır. README, proje kökünde docker-compose.local.yml adında ikinci bir dosya oluşturup şu komutla iki tanımı birleştirmeyi öneriyor:

docker compose -f docker-compose.yml -f docker-compose.local.yml up --build

-f seçenekleri kullanılacak Compose dosyalarını belirtir. Compose bunları birleştirir; ikinci dosyadaki volumes ayarı backend servisinin ana tanımına eklenir. up servisleri başlatır, --build de image'ları oluşturur veya değişiklik varsa yeniden build eder.

Bu yerel senaryoda PostgreSQL container içinde değil, host makinede çalışıyor. Backend'in bağlantı ayarında README host.docker.internal adını kullanıyor; Compose dosyasındaki extra_hosts bu adı host gateway'e yönlendiriyor. Veritabanı ve tablo yapısının önceden hazır olması da gerekiyor. Canlı ortamda ise PostgreSQL'i ayrı bir VM'de tuttum; frontend ve backend container'ları veritabanı dosyalarını saklamıyor.

Bind mount kaynak kodu geliştirme sırasında container'a göstermek için de işe yarar. Dosya değişikliğinin container içinde görünmesi tek başına uygulamayı yeniden yüklemez; hot reload davranışını uygulamanın geliştirme sunucusu sağlar. Buradaki ayar dosyası mount'u ise yalnızca dosyayı bağlar ve :ro nedeniyle container'ın bu dosyaya yazmasını engeller.

Adım 2: Testing ile Uygulamanın Davranışını Kontrol Etmek

Image'ın build olması, uygulamanın doğru davrandığını göstermiyor. Kod derlenebilir; yine de endpoint yanlış cevap döndürebilir veya veriyi kaydedemeyebilir. Bu nedenle testin kapsamını, doğrulamak istediğim davranışa göre seçiyorum.

Bir testte önce başlangıç koşullarını hazırlar, ardından davranışı çalıştırıp sonucu beklediğim değerle karşılaştırırım. Bu yapı Arrange, Act, Assert olarak geçiyor: hazırla, çalıştır, doğrula. Assertion, sonuç beklediğimden farklıysa testi başarısız yapan kontroldür.

Kontrol edeceğim şey yalnızca başarılı sonuç olmayabilir. Validation, gelen verinin kurallara uygunluğunu denetler; zorunlu başlık eksikse görev oluşturmamak da beklenen bir davranıştır. HTTP cevabındaki status code işlemin sonucunu belirtir: 201 kaynağın oluştuğunu, 404 bulunamadığını gösterir.

Bu kontrolleri sonraki değişikliklerde yeniden çalıştırınca, daha önce çalışan bir davranışın bozulup bozulmadığını görebilirim. Buna regression kontrolü deniyor; yine de test yalnızca kapsadığı senaryolar hakkında bilgi verir.

Unit Test: Bir Parçanın Davranışı

Unit test, küçük bir parçayı bağımlılıklarından ayırarak sınar. Projedeki handler, görev oluşturma işlemini yürüten kod; repository ise kayıt ekleme ve okuma gibi veri erişim işlemlerini sunan parçadır. Handler'ı test ederken gerçek veritabanı yerine fake repository kullanabilirim; böylece kontrol ettiğim davranış handler'ın kendisi olur.

Projeden bir örnek:

var repository = new FakeTodoItemRepository();

var result = await new TodoItemCreateCommandHandler(repository, TodoItemTestMapper.Instance)
    .Handle(new TodoItemCreateCommand("Read", "Book", true), CancellationToken.None);

Assert.True(result.IsSuccess);
Assert.Equal(new TodoItemCreateCommandResponse(1, "Read", "Book", true), result.Response);
Assert.Empty(result.Errors);
Assert.Single(repository.Items);

Önce fake repository'yi hazırlıyorum, ardından Handle ile görev oluşturmayı çalıştırıyorum. Assertion'lar hem dönen cevabı hem de repository'ye tek kayıt eklendiğini kontrol ediyor. Gerçek PostgreSQL bağlantısı bu testin kapsamına girmiyor; bu sınır entegrasyon testinde değişiyor.

Integration Test: Parçalar Birlikte Çalışıyor mu?

Entegrasyon testi, birden fazla parçanın birlikte çalışıp çalışmadığını sınar. API'ye HTTP request gönderip gerçek veritabanına kayıt yapıldığını kontrol etmek, endpoint ile veri erişimini aynı akışta görmemi sağlar.

Bu amaçla projede WebApplicationFactory kullanıyorum; bu araç ASP.NET uygulamasını test ortamında başlatıp ona HTTP request göndermemi sağlar. Testcontainers, test sırasında gerçek bağımlılıkları container olarak başlatıp test sonunda temizlemeyi sağlayan kütüphanedir. Burada geçici PostgreSQL'i açıp tablo yapısını hazırlıyorum; testler canlı veritabanını kullanmıyor.

Görev oluşturma request'inin ilgili kısmı:

using var createResponse = await client.PostAsJsonAsync(
    "/api/todo-items",
    new CreateTodoItemRequest("First task", "Created by integration test", false),
    cancellationToken);

Assert.Equal(HttpStatusCode.Created, createResponse.StatusCode);
Assert.NotNull(createResponse.Headers.Location);

PostAsJsonAsync, veriyi JSON biçiminde POST request'iyle gönderiyor. Test ardından 201 Created cevabını ve yeni kaynağın adresini taşıyan Location başlığını doğruluyor.

Test devamında kaydı okuyup güncelliyor ve siliyor. Fake repository ile geçen bir testin yakalayamayacağı veri erişimi sorunları bu akışta ortaya çıkabilir.

Kullanıcı Akışı ve Deployment Kontrolü

End-to-end test, kullanıcının başlattığı akışı arayüzden depolamaya kadar sınar; Browser'da görev ekleyip sonucu görmek buna örnek. Projedeki frontend proxy testi bu kadar geniş değil: production Nuxt server ile sahte backend arasındaki HTTP aktarımını kontrol ediyor, Browser arayüzünü kapsamıyor.

Test kapsamı büyüdükçe daha fazla parçayı doğrularım, ancak kurulum ve hata ayıklama da zorlaşır. Unit testte sorun handler'a kadar daralırken geniş akışta Browser, API veya veritabanından kaynaklanabilir. Bu yüzden her seviyeden testin neyi kapsadığını açık tutuyorum.

Smoke test daha dar bir kontrol yapar: deployment sonrasında ana sayfa ve temel API erişilebilir mi? Projede / ve /api/todo-items adreslerine request gönderiyorum. Bu kontrol, uygulamanın temel erişim yolunu sınarken bütün CRUD senaryolarını tekrar etmiyor.

Adım 3: CI/CD ile Değişiklikleri Dağıtıma Hazırlamak

Testleri yalnızca kendi bilgisayarımda çalıştırırsam bir değişikliği kolayca atlayabilirim. CI (Continuous Integration), her değişiklikte aynı kontrolleri otomatik çalıştırarak bu riski azaltıyor. GitHub Actions'ta YAML dosyasına yazdığım workflow, bir olayla başlıyor; örneğin pull_request, push veya elle başlatılan workflow_dispatch.

Workflow içindeki job ayrı bir iş grubudur ve bir runner üzerinde çalışır. Job'un step'leri sırayla ilerler; run terminal komutu çalıştırır, uses hazır bir Action çağırır. Bağımsız job'lar paralel çalışabilir. Projede backend ve frontend CI kontrolleri kendi workflow dosyalarında tanımlı.

Kontroller farklı şeylere bakıyor: lint kurallara uymayan kodu bulmaya, typecheck tip uyuşmazlıklarını yakalamaya, testler davranışı doğrulamaya çalışıyor. Docker image build ise paketlemenin tamamlanabildiğini gösteriyor. Runner bunları başarıyla bitirse de uygulamayı sunucuda çalıştırmış olmuyor; o ayrı deployment adımı.

CD de iki farklı hedefi anlatabilir. Continuous Delivery, başarılı değişikliği dağıtıma hazırlar; canlıya geçiş için onay bekleyebilir. Continuous Deployment ise kontrollerden geçen değişikliği otomatik olarak canlıya taşır.

Bir Adım Diğerini Beklediğinde

Testler geçmeden migration'ın veya deployment'ın başlamasını istemem. Job bağımlılıkları bu sırayı kuruyor; release workflow'undaki kısaltılmış bölüm şöyle:

migrate:
  needs: [backend-ci, frontend-ci]

publish:
  needs: migrate

deploy:
  needs: publish

needs, bir job'un ilerlemeden önce bekleyeceği işleri belirtir. Önce backend ve frontend kontrolleri tamamlanıyor; ardından migrate veritabanı şemasını güncelliyor, publish image'ları registry'ye gönderiyor ve deploy yeni sürümü K3s'te çalıştırıyor. Migration başarısız olursa image yayımı ve deployment başlamıyor. Şema değişikliğinin neden image dağıtımından önce geldiğine deployment bölümünde döneceğim.

Registry ve Sürüm Takibi

Image hazırlandıktan sonra sunucunun da ona ulaşması gerekiyor. Container registry, image'ları sakladığım ve çalışma ortamına indirdiğim depo; Docker Hub ve GitHub Container Registry buna örnek.

Git her commit'i bir hash ile tanımlar; commit SHA, bu kimlik değeridir. latest etiketi zamanla başka image'ı gösterebilir. SHA etiketi ise hangi kaynak kodundan image üretildiğini izlemeyi kolaylaştırır.

Projede kullandığım GitHub Container Registry'nin kısaltması GHCR. Gönderdiğim image adlarından biri:

ghcr.io/tahatuzel/git-to-prod-backend:<commit-sha>

Registry'ye yeni image göndermek, çalışan container'ı kendiliğinden güncellemez. Deployment sırasında hedef ortama hangi image sürümünü çalıştıracağını ayrıca bildirmek gerekir.

Adım 4: Deployment, Kubernetes ve K3s

Image registry'ye ulaştı; peki sunucu onu nasıl çalıştıracak? Deployment, uygulama sürümünü hedef ortamda başlatıp mevcut sürümden yenisine geçme süreci. Bunun için veritabanı erişimi, bağlantı ayarları ve dış trafiğin uygulamaya ulaşacağı yol da hazır olmalı.

Aynı image'ı farklı ortamlarda kullanıp bağlantı ayarlarını çalışma anında verebilirim; her ortam için yeniden paketlemem gerekmez. Hassas bilgileri de image içine koymak yerine ortamın Secret mekanizmasıyla sağlıyorum.

Bu çalışmada Terraform ile AWS ağını ve makineleri hazırladım. PostgreSQL'i ayrı bir sanal makineye, K3s'i uygulama makinelerine kurdum; pipeline da uygulamanın yeni sürümlerini buraya taşıdı.

Veritabanı Şeması da Değişebiliyor

Uygulamanın kodu değişirken veritabanındaki tablolar da değişebilir. Örneğin yeni bir alan eklediğimde bu değişikliği migration olarak tanımlarım. Eski sürüm hâlâ çalışırken yeni sürümün ihtiyaç duyduğu alanı erkenden silmek sorun çıkarabilir; bu yüzden kod ve şema değişikliklerinin sırasını birlikte düşünmek gerekir.

Projede EF Core'un migration bundle'ı release akışında önce çalışıyor. Migration tamamlanırsa image'lar yayımlanıyor ve K3s'e dağıtılıyor. Böylece her uygulama kopyasının açılışta aynı şemayı değiştirmeye çalışmasını önlüyorum. Image'ı önceki sürüme döndürmek de veritabanı değişikliğini kendiliğinden geri almaz.

Kubernetes ve K3s Ne Yapıyor?

Compose ile servisleri tek makinede başlatabiliyorum. Birden fazla makinede ise hangi makinenin uygulamayı çalıştıracağını, kapanan bir kopyanın yerine ne geleceğini ve yeni sürüme nasıl geçileceğini de yönetmem gerekiyor. Kubernetes, container'ların bu yaşam döngüsünü yönetiyor.

Cluster içindeki makineler node olarak adlandırılır. Kubernetes uygulamayı Pod içinde çalıştırır; çoğu Pod'da bir uygulama container'ı bulunur. Kaç kopya istediğimi bir Deployment tanımında belirtirim:

spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: backend
          image: ghcr.io/tahatuzel/git-to-prod-backend:__IMAGE_TAG__

Burada iki backend kopyası istiyorum. Kubernetes mevcut durumu bu istekle karşılaştırır; bir Pod kapanırsa yenisini oluşturmaya çalışır. Scheduler Pod için uygun node'u seçer, node üzerindeki kubelet de container runtime'a uygulamayı başlatmasını söyler. K3s'in varsayılan runtime'ı containerd; bu nedenle worker makinelerine Docker Engine kurmam gerekmedi.

K3s, Kubernetes'i daha kolay kurup çalıştırmak için bazı bileşenleriyle birlikte paketleyen bir dağıtımdır. Yani K3s'te de Deployment, Pod ve Service aynı Kubernetes kaynaklarıdır. Projemde uygulama Pod'larını worker node'larda çalıştırmak için node label ve nodeSelector kullandım. İki replica istemek tek başına bunların farklı node'lara yerleşmesini garanti etmez.

Pod yeniden oluşturulunca IP'si değişebilir. Uygulamanın bu IP'yi takip etmemesi için Service sabit bir ad sağlar; Nuxt server projede backend'e http://todo-backend:8080 üzerinden ulaşıyor. Dışarıdan gelen HTTP trafiğinin hangi servise gideceğini Ingress tanımlar, K3s içindeki Traefik ise bu kuralı uygular.

Kurulumdaki istek yolu özetle şöyle:

Browser → AWS ALB → Traefik → frontend Service → Nuxt Pod
                                                   ↓
                                            backend Service
                                                   ↓
                                              .NET Pod
                                                   ↓
                                             PostgreSQL

PostgreSQL'i cluster dışında ayrı bir VM'de tuttum. Kubernetes bu projede frontend ve backend Pod'larını yönetiyor; veritabanının diskini veya yedeklerini yönetmiyor.

K3s ile Yeni Sürümü Çalıştırmak

Kubernetes'e istediğim durumu manifest adı verilen YAML dosyalarıyla bildiririm. Projedeki backend manifestinde image etiketi release sırasında commit SHA ile değiştirilir. Bağlantı bilgisi de dosyaya açık metin olarak yazılmaz; Pod bunu Kubernetes Secret'ından alır:

spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: backend
          image: ghcr.io/tahatuzel/git-to-prod-backend:__IMAGE_TAG__
          env:
            - name: ConnectionStrings__DefaultConnection
              valueFrom:
                secretKeyRef:
                  name: todo-db
                  key: connectionString

Bu, projedeki Deployment tanımının ilgili alanlarının sadeleştirilmiş hali. Release script'i image etiketini commit SHA ile doldurup manifesti cluster'a uygular:

sed "s/__IMAGE_TAG__/$release_sha/g" app.yaml | sudo k3s kubectl apply -f -
sudo k3s kubectl -n todo rollout status deployment/todo-backend --timeout=300s
sudo k3s kubectl -n todo rollout status deployment/todo-frontend --timeout=300s

kubectl apply, manifestteki istenen durumu cluster'a iletir. Rolling update sırasında Kubernetes yeni Pod'ları hazır etmeye çalışırken eski kopyaları kademeli kapatır. rollout status geçiş tamamlanana kadar bekler; ancak bunun düzgün çalışması için yeni Pod'un trafiğe hazır olup olmadığını da kontrol etmesi gerekir.

Projede bu iki kontrol backend manifestinde şöyle tanımlı:

readinessProbe:
  httpGet:
    path: /api/todo-items
    port: 8080
  periodSeconds: 10
livenessProbe:
  tcpSocket:
    port: 8080
  periodSeconds: 20

Readiness probe, her 10 saniyede /api/todo-items endpoint'ine istek gönderiyor. Başarısızsa Pod Service üzerinden trafik almıyor. Liveness probe ise her 20 saniyede container port'una bağlantı kurmayı deniyor; eşik aşılarak başarısız olursa kubelet container'ı yeniden başlatabiliyor. Bu iki kontrol farklı sorulara cevap veriyor: uygulama trafik alabilir mi, çalışmaya devam edebiliyor mu?

Rollout tamamlandıktan sonra GitHub Actions, ALB üzerinden hem ana sayfaya hem /api/todo-items yoluna HTTP isteği gönderiyor. Bu son smoke test, dış trafik yolunun da çalıştığını kontrol ediyor. Projenin akışı böylece testlerden migration'a, image yayımına, K3s rollout'una ve dışarıdan kontrole kadar ilerliyor.

Hands-on Denemesi: Host Bağlanıyor, Pod Neden Bağlanamıyor?

Sorun

İlk cluster kurulumunda worker makinesinden PostgreSQL'e bağlanabiliyordum; backend Pod'undan yaptığım aynı test ise zaman aşımına uğruyordu.

Worker host → PostgreSQL    Bağlantı kuruluyor
Backend Pod → PostgreSQL   Timeout

Önce iki arayüzü tanıtayım: ens5, worker makinesinin AWS VPC ağına bağlanan ağ arayüzü. cni0 ise K3s'in aynı worker üzerindeki Pod'ları bağladığı yerel ağ köprüsü. Devamında bu yolları kısaca VPC ağı ve K3s'in yerel Pod ağı olarak anacağım.

VPC'm 10.42.0.0/16 aralığını kullanıyordu. K3s'in varsayılan Pod ağı da 10.42.0.0/16 idi. Yani VPC'deki makinelerle Pod'lar aynı IP aralığını kullanıyordu. Aynı IP bloğu hem VPC'deki DB'yi hem de K3s'in yerel Pod ağını gösterebildiği için worker gelen paketi hangi yola vereceğine karar vermek zorundaydı.

Böyle tespit ettim

İlk timeout'ta paketin nerede kaybolduğunu bilmiyordum. Bunu görmek için daha küçük bir AWS ortamında sorunu kontrollü olarak tekrar oluşturdum. Bu ortamda bir K3s server, bir worker ve bir DB vardı. Server ve worker makinelerini farklı subnet'lere koydum; DB adresini ise worker'ın Pod'ları için kullandığı aralığa denk getirdim:

VPC:               10.42.0.0/16
Server EC2 subnet: 10.42.254.0/24
Worker EC2 subnet: 10.42.253.0/24
DB EC2 subnet:     10.42.1.0/24
Worker'ın Pod aralığı: 10.42.1.0/24

Pod IP:            10.42.1.2
DB IP:             10.42.1.63

Pod 10.42.1.63 adresindeki DB'ye bağlanmaya çalışırken worker'daki rota kontrolü K3s'in yerel Pod ağına giden yolu gösterdi:

Pod'dan gelen hedef:  10.42.1.63
Worker'ın seçtiği yol: K3s'in yerel Pod ağı (cni0)
DB tarafındaki sonuç:  Hiç paket görülmedi

DB IP'si 10.42.1.63, worker'ın Pod'ları için kullandığı 10.42.1.0/24 aralığıyla aynı blok içindeydi. Worker'ın rota tablosunda bu blok için K3s'in yerel ağına giden bir yol vardı. Hedef bu aralığa uyduğu için worker bu paket için tek bir yol seçti: VPC ağına göndermek yerine K3s'in yerel ağına verdi. DB IP'sinde yerel bir Pod bulunmadığından istek orada sonuçsuz kaldı. Paket VPC'ye hiç çıkmadı; DB tarafındaki tcpdump'ın hiç paket görmemesi de bunu doğruladı.

Dolayısıyla bu denemede sorun PostgreSQL'in isteği reddetmesi ya da yanıtın geri dönememesi değildi: istek DB'ye hiç ulaşmadı. Worker host'undan yapılan test farklıydı; bağlantı host'un kendi IP'si ve VPC yolu üzerinden çıkıyordu. Pod testi ise Pod IP'siyle başlayıp worker'da farklı bir yol seçiyordu.

Çözüm

Çözüm, K3s'in Pod adresleri için VPC'den farklı bir CIDR kullanmasıydı:

VPC ağı:  10.42.0.0/16
Pod ağı:  10.244.0.0/16

K3s server ayarı:
--cluster-cidr=10.244.0.0/16

--cluster-cidr, K3s'in Pod'lara vereceği IP aralığını belirliyor. Cluster'ı bu ayarla yeniden kurduğumda Pod ağı 10.244.0.0/16 oldu; DB ise aynı 10.42.1.63 adresinde kaldı. Artık DB adresi K3s'in Pod aralığında değildi. Worker hedefi K3s'in yerel ağıyla eşleştirmedi; paketi VPC yoluna, ens5 üzerinden gönderdi:

Pod IP'si:       10.244.1.3
DB IP'si:        10.42.1.63
Worker rotası:   VPC ağı (ens5)
DB tcpdump:      SYN paketi görüldü
Sonuç:           Bağlantı ve SELECT 1 / SELECT 2 başarılı

DB tcpdump'ında SYN paketi görüldü; SELECT 1 ve SELECT 2 başarılı oldu. Bu sonuç, isteğin DB'ye ulaştığını ve yanıtın Pod'a döndüğünü doğruladı. CIDR'lar ayrılınca worker'ın seçebileceği ağ yolu netleşti: DB isteği VPC üzerinden gitti. K3s'in Pod ağı ve Flannel yapılandırması K3s ağ seçeneklerinde açıklanıyor.

Hatanın hangi katmanda olduğunu aramak

Sorun olduğunda önce Pod'un durumunu ve log'larını inceleyebilirim:

sudo k3s kubectl -n todo get pods -o wide
sudo k3s kubectl -n todo describe pod POD_ADI
sudo k3s kubectl -n todo logs deployment/todo-backend

get pods -o wide, Pod'ları node ve IP bilgileriyle listeler. describe pod, seçilen Pod'un ayrıntılarını ve olaylarını; logs, uygulamanın mesajlarını gösterir. POD_ADI yerine listeden aldığım gerçek adı yazmam gerekir.

ImagePullBackOff image'ın indirilmesinde sorun olduğunu gösterir; image adı, tag ve registry erişimine bakarım. CrashLoopBackOff durumunda uygulama log'larını ve başlangıç ayarlarını incelerim. Pod çalışıyor ama hazır değilse readiness kontrolü ve onun bağımlılıkları öne çıkar.

Bağlantı hatalarında da request'i hangi ortamdan gönderdiğimi, kullanılan adresi ve aradaki ağları ayrı ayrı kontrol etmem gerekiyor.

Kendime Notlar

Bu çalışmada birden fazla kez aynı dersi gördüm: Bir adımın başarılı olması sonraki adımı garanti etmiyor. Testler kodun belirli davranışlarını kontrol etti; image build paketlemenin tamamlandığını gösterdi. Pod'dan veritabanına giden ağ yolunu ise ancak gerçek cluster'da fark ettim.

Kubernetes'te iki replica yazmak da yeterli olmadı; hangi node'da çalıştıklarını ve veritabanı gibi bağımlılıkların nerede durduğunu ayrıca düşünmem gerekti. Bir hata çıktığında artık yalnızca “uygulama çalışıyor mu?” diye bakmıyorum. Request hangi ortamdan çıkıyor, hangi adresi kullanıyor ve sıradaki kontrol neyi kanıtlıyor, bunları takip ediyorum.

Kod, test ve deployment tanımları GitHub'da:

Git to Prod: GitHub projesi

URL'den Response'a: Tarayıcıda Ne Oluyor?

TAHA TÜZEL — Sun, 27 Sep 2026 13:03:40 +0000

Her gün interneti kullanıyorum; bir siteye erişmek için adresi yazıp Enter'a basıyorum. Projelerde frontend tarafında fetch çağırıyorum, backend tarafında route tanımlıyorum. Bunlar sürekli kullandığım şeyler olsa da Browser ile Server arasında o kısa sürede tam olarak neler yaşandığı uzun süre benim için biraz ezberlenmiş bilgilerden ibaretti.

İzlediğim eğitim videolarının ve okuduğum blog yazılarının büyük bölümü benzer bir şablon üzerinden ilerliyordu:

DNS telefon rehberidir, IP bulunur, sayfa gelir.

Bu anlatım genel resmi anlamak için yeterli olsa da arka planda gerçekleşen süreci daha detaylı görmek istedim.

Bu nedenle teorik konuları çalışırken birkaç küçük lab yaptım; nslookup ve curl gibi araçlarla Request'in geçtiği adımları incelemeye çalıştım. Bu yazıda hem çalışma sırasında çıkardığım notları hem de kullandığım terminal komutlarını ve aldığım çıktıları tek bir akış altında topladım.

Büyük Resim: Request Nereden Geçiyor?

İlk olarak genel akışı oturtmak gerekiyor.

Browser'a bir adres yazıp Enter'a bastığımızda süreç kabaca şu sırayla ilerliyor:

URL girilir
DNS, domain adını IP adresine çevirir.
TCP connection kurulur.
HTTPS kullanılıyorsa TLS handshake gerçekleştirilir.
Client, HTTP request gönderir.
Server, HTTP response döndürür.
Browser gelen içeriği işleyerek sayfayı render eder.

Kısaca:

URL → DNS → TCP → TLS → HTTP Request → HTTP Response → Render

Bu iletişimde temelde iki taraf bulunuyor.

Request'i başlatan taraf Client. Bu bir Browser, mobil uygulama veya terminalde kullandığımız curl olabilir.

Karşı tarafta ise Request'e Response üreten Server bulunuyor. Bu Server tarafında Nginx, Apache, Go veya Node.js ile çalışan bir servis olabilir.

Akış ilk bakışta oldukça basit görünüyor. Ancak her adımın içine girdiğimizde arka planda çok daha fazla mekanizmanın çalıştığını görüyoruz.

Adım 1: Yazdığımız URL Nelerden Oluşuyor?

Süreci anlamak için önce Browser'a yazdığımız URL'nin yapısına bakalım.

Örnek olarak biraz uzun bir URL'yi parçalarına ayıralım:

https://api.example.com:443/products/5?category=tech&sort=asc#reviews

https://   api.   example   .com   :443   /products/5   ?category=tech&sort=asc   #reviews
│          │      │         │      │      │             │                         │
Scheme     Sub-   Domain    TLD    Port   Path          Query Parameters          Fragment
           domain

Buradaki her parçanın farklı bir görevi var:

Scheme (https): İletişimde hangi protocol'ün kullanılacağını belirtir.
Subdomain (api): Ana domain altında bulunan özelleşmiş servisi ifade eder. app, cdn veya api gibi yapılar burada karşımıza çıkar.
Domain (example): Ana domain adıdır.
TLD (.com): Top-Level Domain bölümüdür. .com, .org, .net, .dev gibi uzantılar bu gruba girer.
Port (:443): Server üzerinde hangi port'a bağlanılacağını belirtir. HTTP için varsayılan port 80, HTTPS için ise 443'tür. URL içerisinde açıkça yazılmasa bile Browser bunu bilir. Lokal geliştirmede kullandığımız localhost:3000 adresindeki 3000 de aynı kavramdır.
Path (/products/5): Server'dan istenen resource'un yolunu belirtir.
Query Parameters (?category=tech&sort=asc): Filtreleme veya sıralama gibi işlemler için kullanılan key-value çiftleridir.
Fragment (#reviews): Sayfa içerisindeki belirli bir bölümü ifade eder.

Burada diğer URL bileşenlerinden ayrılan kısım Fragment.

#reviews Server'a gönderilmez. Browser, sayfayı aldıktan sonra Fragment değerini Client tarafında kullanarak ilgili bölüme gider.

Yani URL'de gördüğümüz her bölüm HTTP Request'in bir parçası değildir.

Adım 2: DNS Sorgusu

URL'nin yapısından sonra sıradaki soru şu:

wikipedia.org yazdığımızda bilgisayar karşıdaki Server'ı nasıl buluyor?

Bilgisayarlar ve Router'lar bizim kullandığımız domain isimleri üzerinden iletişim kurmaz. Ağ üzerindeki cihazlara ulaşabilmek için IP adresleri kullanılır.

Bu nedenle Browser'ın wikipedia.org Server'ına ulaşabilmesi için önce bu domain'in arkasındaki IP adresini öğrenmesi gerekir.

Bu işlemi DNS — Domain Name System gerçekleştirir.

Browser bir IP adresini bulmaya çalışırken süreç kabaca şu şekilde ilerler:

Önce kendi Cache'ini kontrol eder.
Ardından işletim sisteminin Cache'ine ve yerel hosts dosyasına bakılır.
Burada sonuç bulunamazsa bilgisayarın ağ ayarlarında tanımlanmış DNS Resolver kullanılır. Bu ISP'nin Resolver'ı olabileceği gibi 1.1.1.1 veya 8.8.8.8 gibi public DNS servisleri de olabilir.
Resolver da cevabı bilmiyorsa Root DNS Server'lardan başlayarak ilgili TLD Server'a ve sonrasında domain'in Authoritative DNS Server'ına kadar uzanan sorgu süreci çalışır.

Burada önemli kavramlardan biri de TTL — Time To Live.

DNS record'larında bulunan TTL değeri saniye cinsinden tutulur ve DNS Response'unun Cache içerisinde ne kadar süre saklanabileceğini belirler.

Bunun pratikte önemli olduğu senaryolardan biri Server migration işlemidir.

Bir proje başka bir Server'a taşınıyor ve IP adresi değişiyorsa geçişten önce TTL değerinin düşürülmesi faydalı olabilir. Aksi durumda eski IP adresi bazı DNS Cache'lerinde kalmaya devam edebilir ve kullanıcıların bir bölümü eski Server'a yönlenebilir.

Terminal Denemesi: `wikipedia.org` IP Adresini Bulmak

DNS çözümlemesinin terminalde nasıl göründüğünü incelemek için PowerShell üzerinde nslookup kullanılabilir:

PS C:\> nslookup wikipedia.org
Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
Name:    wikipedia.org
Addresses:  2a02:ec80:600:ed1a::1
          185.15.58.224

Çıktıda birkaç önemli bilgi bulunuyor.

İlk olarak kullanılan DNS Resolver:

Server:  one.one.one.one
Address: 1.1.1.1

Burada sorgu Cloudflare'ın 1.1.1.1 DNS Resolver'ına gönderiliyor.

Bir diğer önemli satır:

Non-authoritative answer

1.1.1.1, Wikipedia'nın Authoritative DNS Server'ı değil. İlgili cevabı öğrenip Client'a ileten Resolver rolünde.

Response içerisinde iki farklı IP adresi de bulunuyor:

2a02:ec80:600:ed1a::1
185.15.58.224

İlk adres IPv6 tarafındaki AAAA record, ikinci adres ise IPv4 tarafındaki A record.

Bu kayıt türlerini örnek bir site üzerinden inceleyelim:

A record: benimsitem.com adını doğrudan sunucunun IPv4 adresine bağlar.
AAAA record: A record'un IPv6 adresleri için kullanılan karşılığıdır.
CNAME record: www.benimsitem.com adını bir IP adresine değil, benimsitem.com adına bağlar.

Böylece biri www.benimsitem.com adresini yazdığında DNS önce benimsitem.com adını, ardından onun A kaydındaki IP adresini bulur. www için aynı IP adresini ikinci kez yazmam gerekmez. CNAME bir HTTP yönlendirmesi yapmaz; tarayıcıdaki URL değişmez.

DNS'e URL Verirsek Ne Oluyor?

nslookup ile şu sorguyu çalıştırdığımızı düşünelim:

PS C:\> nslookup http://http.badssl.com/
Server:  one.one.one.one
Address:  1.1.1.1

*** one.one.one.one can't find http://http.badssl.com/: Non-existent domain

Buradaki problem DNS'e yalnızca domain vermek yerine bütün URL'nin gönderilmesi.

DNS'in görevi HTTP ile ilgilenmek değil; domain name resolution yapmaktır.

Bu nedenle http:// ve sondaki / domain'in bir parçası değildir.

Sadece hostname sorgulandığında sonuç alınabilir:

PS C:\> nslookup http.badssl.com
Non-authoritative answer:
Name:    http.badssl.com
Address:  104.154.89.105

Bu küçük deney URL ile domain arasındaki farkı oldukça net gösteriyor.

Adım 3: TCP ve UDP

DNS üzerinden IP adresini bulduk.

Artık hangi Server'a ulaşmak istediğimiz belli. Sıradaki konu ise verinin iki cihaz arasında nasıl taşındığı.

Transport Layer'da en sık karşılaşılan iki protocol:

TCP: Reliable Connection

Web tarafında sık karşılaştığımız protocol'lerden biri TCP.

Bir HTML dosyasının, API Response'unun veya başka bir verinin yalnızca bir bölümünün ulaşması yeterli değildir. Gönderilen verinin eksiksiz ve doğru sırada karşı tarafa ulaşması gerekir.

TCP bunu sağlayabilmek için veri transferinden önce Client ve Server arasında bir Connection oluşturur.

Bu süreç 3-Way Handshake olarak adlandırılır:

sequenceDiagram
    autonumber
    participant C as Client (Sender)
    participant S as Server (Receiver)
    C->>S: SYN
    S->>C: SYN-ACK
    C->>S: ACK

Akış şu şekilde ilerler:

Client, Server'a SYN göndererek Connection başlatmak istediğini bildirir.
Server, SYN-ACK ile cevap verir.
Client, ACK gönderir ve Connection kurulmuş olur.

Connection kurulduktan sonra veri tek parça halinde gönderilmez. Büyük veri, ağ üzerinde taşınabilecek daha küçük bölümler halinde iletilir.

TCP burada sequence number kullanır.

Sequence number'lar Receiver'ın gelen verinin hangi sıraya ait olduğunu anlamasını sağlar. Böylece veri farklı zamanlarda ulaşsa bile doğru sıraya yerleştirilebilir.

Basitleştirilmiş olarak şöyle düşünebiliriz:

Sender

Data
 ↓
[1] [2] [3] [4] [5]
 ↓   ↓   ↓   ↓   ↓
Network
 ↓
Receiver
 ↓
[1] [2] [3] [4] [5]
 ↓
Original Data

Network üzerinde her bölümün aynı anda veya aynı sırada ulaşması garanti değildir.

Örneğin veri şu şekilde ulaşabilir:

1 → 2 → 4 → 5

Burada 3 numaralı bölüm eksik.

TCP'nin reliability mekanizmaları sayesinde eksik veri tespit edilir ve gerekli bölüm yeniden gönderilebilir.

1 → 2 → 4 → 5
        ↑
        3 missing

Sender
  ↓
retransmission
  ↓
3

Bu sayede Receiver yalnızca gelen veriyi almakla kalmaz; eksik veya sırası bozulmuş veriyi de doğru şekilde işleyebilir.

REST API çağrıları, dosya indirme işlemleri veya database connection'ları gibi senaryolarda TCP kullanılmasının temel nedenlerinden biri bu reliability mekanizmasıdır.

UDP: Daha Hafif Bir Yaklaşım

UDP farklı bir çalışma modeline sahiptir.

TCP'deki gibi Connection kurulmaz ve 3-Way Handshake yapılmaz.

Packet gönderilir ancak karşı tarafa ulaşıp ulaşmadığına dair TCP seviyesinde bir garanti bulunmaz.

Packet kaybolduğunda otomatik retransmission garantisi de yoktur.

İlk bakışta bu bir dezavantaj gibi görünse de bazı kullanım alanlarında istenen davranış tam olarak budur.

Örneğin canlı yayın, online oyun veya görüntülü görüşme sırasında yarım saniye önce gönderilmiş bir Packet'ın tekrar ulaşması her zaman anlamlı olmayabilir. Güncel verinin düşük latency ile ulaşması daha önemli olabilir.

Bu nedenle bu tür senaryolarda UDP tercih edilebilir.

Adım 4: HTTP, HTTPS ve TLS

TCP Connection kurulduktan sonra HTTP Request gönderilebilir.

Burada HTTP ve HTTPS arasındaki farkı ayrı ele almak daha anlaşılır.

HTTP Request Gönderirsek Ne Oluyor?

HTTP tarafında Client ile Server arasındaki trafik TLS ile şifrelenmez.

Bu nedenle Request ve Response içerisinde taşınan bilgiler ağ üzerinde plaintext olarak görülebilir.

Örneğin:

GET /login HTTP/1.1
Host: example.com

gibi bir Request HTTP üzerinden gönderildiğinde aradaki trafik şifreli değildir.

Bu yalnızca verinin okunabilmesi anlamına gelmez. HTTP trafiği aynı zamanda iletişim sırasında değiştirilmesine karşı da TLS seviyesinde bir koruma sağlamaz.

HTTPS kullanılmasının temel amacı burada ortaya çıkıyor.

HTTPS aslında tamamen farklı bir HTTP protocol'ü değil. Temelde:

HTTP
  +
TLS
  =
HTTPS

şeklinde düşünülebilir.

TLS, HTTP iletişimine üç önemli özellik kazandırır:

Encryption: Client ile Server arasındaki trafiğin üçüncü kişiler tarafından okunmasını zorlaştırır.
Integrity: Trafiğin iletişim sırasında değiştirilip değiştirilmediğinin kontrol edilmesini sağlar.
Authentication: Client'ın gerçekten ulaşmak istediği Server ile iletişim kurduğunu doğrulamasına yardımcı olur.

Wikipedia'ya özellikle HTTP üzerinden bir Request gönderelim:

-I seçeneği GET yerine HEAD isteği gönderir; böylece yanıtın yalnızca durum satırını ve Header'larını görürüz.

PS C:\> curl.exe -I http://wikipedia.org
HTTP/1.1 301 Moved Permanently
content-length: 0
location: https://wikipedia.org/
server: HAProxy
x-cache: cp6014 int
x-cache-status: int-tls
connection: close

Burada Wikipedia HTTP Request'i kabul edip sayfanın içeriğini göndermek yerine Client'ı HTTPS adresine yönlendiriyor.

Bunu Response'un ilk satırında görebiliyoruz:

HTTP/1.1 301 Moved Permanently

301 Moved Permanently, istenen resource'un başka bir adrese taşındığını belirtiyor.

Nereye gidilmesi gerektiği ise Location Header içerisinde bulunuyor:

location: https://wikipedia.org/

Akış kabaca şu hale geliyor:

Client
  │
  │ HTTP Request
  │ http://wikipedia.org
  ▼
Server
  │
  │ 301 Moved Permanently
  │ Location: https://wikipedia.org/
  ▼
Client
  │
  │ HTTPS Request
  ▼
Server

Yani Browser'a http://wikipedia.org yazılmış olsa bile Server, Client'ı HTTPS endpoint'ine yönlendiriyor.

HTTPS Tarafında TLS Devreye Giriyor

HTTPS kullanıldığında HTTP iletişiminden önce TLS Handshake gerçekleşir.

HTTP Request henüz gönderilmeden önce Client ve Server güvenli iletişim için gerekli adımları tamamlar.

TLS'in ilk görevlerinden biri Client'ın bağlandığı Server'ın identity'sini doğrulamaktır.

Burada TLS Certificate devreye girer.

Server, TLS Handshake sırasında Client'a Certificate'ını gönderir.

Certificate içerisinde diğer bilgilerin yanında hangi domain veya domain'ler için geçerli olduğu bilgisi bulunur.

Client daha sonra kabaca şu kontrolleri yapar:

Server Certificate
        ↓
Certificate güvenilir bir CA tarafından imzalanmış mı?
        ↓
Certificate geçerlilik süresi içinde mi?
        ↓
Certificate bağlanılan domain için geçerli mi?
        ↓
Validation başarılı

Buradaki CA — Certificate Authority, Certificate'ların güvenilirliğini doğrulayan yapılardır.

Browser ve işletim sistemleri önceden güvendikleri Root CA'ların listesini tutar. Server'ın gönderdiği Certificate'ın güven zinciri bu trusted root'lardan birine kadar doğrulanabiliyorsa Certificate güvenilir kabul edilebilir.

Domain kontrolü de bu sürecin önemli bir parçasıdır.

Örneğin Client:

https://www.wikipedia.org

adresine bağlanıyorsa gelen Certificate'ın www.wikipedia.org için geçerli olup olmadığını kontrol eder.

Certificate, Server'ın public key'ini de içerir; eşleşen private key ise Client'a gönderilmez. Server, TLS Handshake sırasında private key'e sahip olduğunu dijital imzayla kanıtlar; Client bu imzayı public key ile doğrular. Böylece anahtar çifti Server'ın kimliğini doğrulamada kullanılır.

Client ve Server, Handshake sırasında ortak bir sır üzerinde anlaşarak simetrik session key'ler türetir. Sonraki HTTP iletişimi bu key'lerle şifrelenir; her Request public key ile ayrı ayrı şifrelenmez.

Basitleştirilmiş akış şu şekilde düşünülebilir:

Client
  │
  │ TCP Connection
  ▼
Server
  │
  │ TLS Handshake
  │ Certificate
  ▼
Client
  │
  │ Certificate Validation
  ▼
TLS Session Keys
  │
  ▼
Encrypted HTTP Request / Response

Bu noktadan sonra network üzerinde taşınan HTTP içeriği doğrudan plaintext olarak görülmez.

Yani HTTPS yalnızca "HTTP'nin şifreli hali" demekten biraz daha fazlasını sağlar.

Client açısından iki önemli soru cevaplanmış olur:

Doğru Server ile mi konuşuyorum?
        ↓
Certificate Authentication

Aradaki trafik okunabilir veya değiştirilebilir mi?
        ↓
Encryption + Integrity

Bu yapıdan sonra IP adresine doğrudan HTTPS Request gönderdiğimizde neden Certificate hatası aldığımızı inceleyebiliriz.

IP Adresine Doğrudan HTTPS Request Gönderirsek Ne Oluyor?

DNS sorgusundan Wikipedia'nın IP adreslerinden birini elde etmiştik:

185.15.58.224

IP adresini bildiğimize göre doğrudan HTTPS Request göndermeyi deneyebiliriz:

PS C:\> curl.exe  https://185.15.58.224

Ancak Request başarılı olmuyor:

curl: (60) schannel: SNI or certificate check failed: SEC_E_WRONG_PRINCIPAL (0x80090322) - Hedef asıl adı yanlış.

curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it.

Burada problem TCP Connection'dan farklı bir katmanda oluşuyor.

IP adresine ulaşabiliyoruz ancak TLS Certificate doğrulaması başarısız oluyor.

Server tarafından kullanılan Certificate, wikipedia.org gibi domain isimleri için düzenlenmiş durumda.

Client ise şu adrese bağlanmaya çalışıyor:

https://185.15.58.224

curl, Server'ın gönderdiği Certificate ile ulaşmaya çalıştığımız adresi karşılaştırıyor.

Certificate içerisindeki geçerli isimlerle IP adresi eşleşmediği için TLS doğrulaması başarısız oluyor ve HTTPS Connection devam etmiyor.

Aynı Request'i Domain ile Gönderirsek

Bu kez Request'i IP yerine domain üzerinden gönderelim:

PS C:\> curl.exe https://www.wikipedia.org
<!DOCTYPE html>
<html lang="en" class="no-js">
...

Bu durumda TLS doğrulaması başarılı oluyor ve Response alınabiliyor.

Burada SNI — Server Name Indication da devreye giriyor.

TLS Handshake sırasında Client, hangi domain'e ulaşmak istediğini Server'a bildiriyor.

Basitleştirilmiş olarak:

Client
  │
  │ TLS Handshake
  │ SNI: www.wikipedia.org
  ▼
Server
  │
  │ Certificate for wikipedia.org
  ▼
Client
  │
  │ Certificate validation
  ▼
HTTPS Connection

Böylece Server doğru Certificate'ı sunabiliyor ve Client Certificate doğrulamasını gerçekleştirebiliyor.

Burada DNS, TCP ve TLS'in farklı görevleri olduğu daha net görülüyor:

DNS
→ Hangi IP adresine gideceğiz?

TCP
→ Server ile reliable Connection nasıl kuracağız?

TLS
→ Bağlandığımız Server'ı nasıl doğrulayacağız ve trafiği nasıl şifreleyeceğiz?

HTTP
→ Hangi resource'u isteyeceğiz?

Adım 5: Tek IP Adresinde Birden Fazla Site Nasıl Çalışıyor?

Tek bir IP adresi birden fazla web sitesine hizmet verebilir. HTTP/1.1 Request'indeki Host Header'ı, Server'ın hangi site için yanıt üreteceğini belirlemesine yardımcı olur. Bunu http.badssl.com için bulduğumuz 104.154.89.105 adresiyle üç şekilde inceleyelim.

Yalnızca IP Adresine Request

Önce Host değerini ayrıca belirtmeden IP adresine gidelim:

PS C:\> curl.exe 104.154.89.105
<title>Welcome to nginx!</title>
...
<h1>Welcome to nginx!</h1>

Burada curl, URL'deki IP adresini Host değeri olarak kullanır. http.badssl.com istenmediği için BadSSL sayfası yerine Nginx'in karşılama sayfası döner.

IP Adresine Manuel `Host` Header ile Request

Şimdi aynı IP adresine bağlanıp hangi siteyi istediğimizi ayrıca belirtelim:

PS C:\> curl.exe 104.154.89.105 -H "Host: http.badssl.com"
<title>http.badssl.com</title>
...
<h1 style="font-size: 8vw;">http.badssl.com</h1>

Ağdaki hedef hâlâ 104.154.89.105. Değişen şey HTTP Request'indeki Host: http.badssl.com başlığı. Server bu bilgiyi kullanarak BadSSL sayfasını döndürüyor. Bu, Virtual Host mantığını somutlaştırıyor.

URL ile Request ve `curl -v` Çıktısı

Son olarak IP yerine URL'yi kullanalım. -v seçeneği bağlantı bilgisini, giden Request'i ve gelen Response'u görmemizi sağlıyor. Ham çıktının ilgili satırları şöyle:

PS C:\> curl.exe -v http://http.badssl.com
* Host http.badssl.com:80 was resolved.
* IPv4: 104.154.89.105
*   Trying 104.154.89.105:80...
* Established connection to http.badssl.com (104.154.89.105 port 80) from 192.168.18.51 port 57300
> GET / HTTP/1.1
> Host: http.badssl.com
> User-Agent: curl/8.21.0
> Accept: */*
< HTTP/1.1 200 OK
< Server: nginx/1.10.3 (Ubuntu)
< Content-Type: text/html
< Content-Length: 483
< Cache-Control: no-store
<!DOCTYPE html>
...
<title>http.badssl.com</title>

* ile başlayan satırlar adın IP adresine çözülmesini ve bağlantıyı gösteriyor. > işaretli satırlar giden HTTP Request'i: curl, URL'deki http.badssl.com adını alıp Host Header'ına otomatik eklemiş. < işaretli satırlar ise gelen Response'un status ve header bilgileri. 200 OK yanıtından sonra HTML içeriği geliyor.

Üç isteğin ulaştığı IP aynı; dönen sayfayı değiştiren, HTTP seviyesinde hangi host'un istendiği. DNS IP adresini bulurken Host Header'ı Server'ın doğru siteyi seçmesine yardımcı oluyor.

Adım 6: Gelen Yanıt Tarayıcıda Nasıl Görünüyor?

Şimdiye kadar Request'in Server'a ulaşmasını ve Response'un geri dönmesini inceledik. Peki Response Body içerisinde HTML geldiğinde Browser bunu nasıl gördüğümüz sayfaya dönüştürüyor?

Browser HTML'i okuyarak sayfanın yapısını temsil eden DOM'u oluşturur. HTML içinde bağlantısı verilen CSS, JavaScript ve görseller gibi dosyalar için de gerektiğinde yeni HTTP Request'ler gönderir. CSS kurallarını işleyip hangi öğelerin nasıl görüneceğini belirler; ardından öğelerin ekrandaki yerini hesaplar ve sayfayı çizer. JavaScript çalıştığında DOM'u değiştirebilir, yeni veriler isteyebilir ve sayfanın yeniden güncellenmesine yol açabilir.

Bu adımlar her zaman birbirini bekleyen tek bir sıra halinde gerçekleşmez. Browser, HTML'in tamamı gelmeden bazı kaynakları indirmeye ve sayfanın bir bölümünü göstermeye başlayabilir.

Terminalde kullandığımız curl ile Browser arasındaki fark da burada belirginleşir: curl bize Response'un içeriğini gösterir; Browser ise bu içeriği ve diğer kaynakları işleyerek ekranda gördüğümüz sayfayı oluşturur.

Kendime Notlar

Bu konuları çalışmadan önce networking tarafındaki birçok kavram birbirinden bağımsız başlıklar gibi görünüyordu.

DNS ayrı bir konu, TCP ayrı bir konu, TLS ayrı bir konu, HTTP ayrı bir konu.

Terminal üzerinde Request'in geçtiği adımları incelemeye başladığımda bunların aslında aynı iletişim sürecinin farklı aşamaları olduğu daha görünür hale geldi.

Frontend tarafında fetch() çağrısı yaparken veya backend tarafında bir route tanımlarken bütün bu katmanları sürekli düşünmek gerekmiyor.

Ancak Request beklediğimiz gibi çalışmadığında arka plandaki akışı bilmek problemin hangi noktada oluştuğunu anlamayı kolaylaştırıyor.

Bir HTTP Request artık yalnızca:

Client
  ↓
Server

şeklinde düşünülmek zorunda değil.

Arka plandaki akış daha çok şu şekilde ilerliyor:

URL
 ↓
DNS
 ↓
IP
 ↓
TCP
 ↓
TLS
 ↓
HTTP
 ↓
Response
 ↓
Browser'da işleme ve render

Bu çalışmadan çıkan en faydalı alışkanlıklardan biri de şu oldu:

Bir Request beklediğim gibi çalışmadığında yalnızca Browser Console'a veya backend log'larına bakmak yerine terminal üzerinden Request'in kendisini de incelemek.

DEV Community: TAHA TÜZEL

Bir Siparişten Satış Raporuna: OLTP, OLAP ve Data Warehouse

Büyük Resim: Veriyi Kaydetmek ve Veriden Sonuç Çıkarmak

Adım 1: Database ve OLTP ile Günlük İşlemleri Yürütmek

Normalization: Veriyi Neden Ayrı Tablolarda Tutuyoruz?

Transaction: Birbiriyle İlgili Değişiklikleri Birlikte Tamamlamak

Adım 2: OLAP ile Veriden Analiz Çıkarmak

Analizin Ayrıntı Düzeyini Değiştirmek

OLAP İçin Mutlaka Ayrı Bir Sistem Gerekir mi?

Adım 3: Row-Based ve Column-Based Depolama

Row-Based Storage: Aynı Kaydın Alanları Birlikte

Column-Based Storage: Aynı Alanın Değerleri Birlikte

Adım 4: Data Warehouse Nedir?

Database ile Data Warehouse Arasındaki İlişki

Satış Analizinde Warehouse Ne Kazandırır?

Adım 5: Fact ve Dimension ile Analitik Model Kurmak

Grain: Bir Satır Tam Olarak Neyi Temsil Ediyor?

Star Schema: Fact ve Dimension Tablolarını Bağlamak

Denormalization: Analizde Gereken Bilgileri Bir Araya Getirmek

Değişen Dimension Bilgilerinin Geçmişini Korumak

Adım 6: ETL ve ELT ile Veriyi Taşımak ve Dönüştürmek

ETL: Önce Dönüştürmek, Sonra Yüklemek

ELT: Önce Yüklemek, Sonra Hedefte Dönüştürmek

Staging ve Data Lake Hangi İhtiyacı Karşılıyor?

Adım 7: Verinin Güncelliğini ve Aktarımın Doğruluğunu Yönetmek

Aynı Veriyi Tekrar Aktardığımızda Ne Olur?

Adım 8: BI ve Data Mart ile Hazırlanan Veriyi Kullanmak

Data Mart: Belirli Bir Konuya Odaklanmak

Kendime Notlar

Koddan Deployment'a

Büyük Resim: Kod Nasıl Çalışan Uygulamaya Dönüşüyor?

Adım 1: Docker ve Container Mantığı

Dockerfile, Image ve Container Arasındaki İlişki

Image Katmanları ve Build Cache

Derleme Ortamı ile Çalışma Ortamını Ayırmak

Docker Compose ile Servisleri Birlikte Çalıştırmak

Container Ağı: localhost Nereye Bakıyor?

Container Silinirse Veri Ne Oluyor?

Adım 2: Testing ile Uygulamanın Davranışını Kontrol Etmek

Unit Test: Bir Parçanın Davranışı

Integration Test: Parçalar Birlikte Çalışıyor mu?

Kullanıcı Akışı ve Deployment Kontrolü

Adım 3: CI/CD ile Değişiklikleri Dağıtıma Hazırlamak

Bir Adım Diğerini Beklediğinde

Registry ve Sürüm Takibi

Adım 4: Deployment, Kubernetes ve K3s

Veritabanı Şeması da Değişebiliyor

Kubernetes ve K3s Ne Yapıyor?

K3s ile Yeni Sürümü Çalıştırmak

Hands-on Denemesi: Host Bağlanıyor, Pod Neden Bağlanamıyor?

Kendime Notlar

URL'den Response'a: Tarayıcıda Ne Oluyor?

Büyük Resim: Request Nereden Geçiyor?

Adım 1: Yazdığımız URL Nelerden Oluşuyor?

Adım 2: DNS Sorgusu

Terminal Denemesi: wikipedia.org IP Adresini Bulmak

DNS'e URL Verirsek Ne Oluyor?

Adım 3: TCP ve UDP

TCP: Reliable Connection

UDP: Daha Hafif Bir Yaklaşım

Adım 4: HTTP, HTTPS ve TLS

HTTP Request Gönderirsek Ne Oluyor?

HTTPS Tarafında TLS Devreye Giriyor

IP Adresine Doğrudan HTTPS Request Gönderirsek Ne Oluyor?

Aynı Request'i Domain ile Gönderirsek

Adım 5: Tek IP Adresinde Birden Fazla Site Nasıl Çalışıyor?

Yalnızca IP Adresine Request

IP Adresine Manuel Host Header ile Request

URL ile Request ve curl -v Çıktısı

Adım 6: Gelen Yanıt Tarayıcıda Nasıl Görünüyor?

Kendime Notlar

Container Ağı: `localhost` Nereye Bakıyor?

Terminal Denemesi: `wikipedia.org` IP Adresini Bulmak

IP Adresine Manuel `Host` Header ile Request

URL ile Request ve `curl -v` Çıktısı