Generative AI ile CI/CD: deterministik container, Terraform ve minikube örneği

Hedefler: yapay zeka eğitimi ve ai destekli yazılım geliştirme bağlamı

Bu bölümde hedefimiz: generative ai destekli kod üretimini üretim benzeri ortamlarda tekrarlanabilir hale getirmek. Adım 1: kaynak kodu git üzerinde monorepo veya multi-repo olarak tutun; komut: git clone && git checkout . Araç tavsiyesi: GitHub Actions ile CI CD pipeline kurup, artifactleri content-addressable registry (örn. Amazon ECR veya Google Artifact Registry) üzerine digest ile push edin: docker buildx build --push --tag $REGISTRY/$IMAGE@sha256:$DIGEST .

Eğitim bağlamı: yazılım eğitimi ya da teknoloji eğitimi olarak bu akışı vibe coding eğitimi veya vibe coding kursu içeriğine dahil edebilirsiniz; uygulama ödevi olarak öğrencilerden Dockerfile'da cache-optimize edilmiş bir build hazırlamalarını isteyin ve sonuçları time docker build ile ölçün: time docker build -t test:local .

Deterministik Docker build: layer cache, BuildKit ve buildx kullanımı

Neden önemlidir: Docker layer cache, dosya içerik hash'ine dayalı çalışır; kaynak dosya sırası cache hit oranını doğrudan etkiler. Uygulama: Dockerfile'da dependency dosyalarını (package.json, go.mod, requirements.txt) önce COPY edip dependency install yapın, sonra kaynakları kopyalayın. Örnek Dockerfile (çok aşamalı):

FROM node:slim AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --only=production

FROM node:slim AS build
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

FROM node:slim AS prod
WORKDIR /app
COPY --from=build /app/dist ./dist
CMD ["node", "dist/index.js"]

Komut: DOCKER_BUILDKIT=1 docker buildx build --cache-from type=local,src=/tmp/.buildx-cache --cache-to type=local,dest=/tmp/.buildx-cache-new -t myapp:latest .

Ölçüm ve karşılaştırma: önce baseline alın: time DOCKER_BUILDKIT=1 docker build -t myapp:baseline .; sonra optimizasyonu uygula ve yeniden ölç: time DOCKER_BUILDKIT=1 docker buildx build -t myapp:opt .; ölçüm mantığı: her iki çalıştırmada gerçek duvar saati (real) karşılaştırılır, ayrıca docker buildx du --builder ile cache kullanımı raporunu alın. Neden: BuildKit paralelizasyon ve cache-to mekanizması, ağ ve IO maliyetini azaltarak tekrarlanan build süresini düşürür çünkü layer'lar re-use edilir.

Kubernetes eğitimi: minikube ile local container orchestration ve performans profili

Local test ortamı kurun: minikube start --driver=docker --cpus=4 --memory=8192 ile başlayın ve uygulamayı deploy etmek için kubectl apply -f k8s/deployment.yaml kullanın. Örnek Deployment (resource tuning):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: myregistry/api:sha256-
        resources:
          requests:
            cpu: "250m"
            memory: "256Mi"
          limits:
            cpu: "1000m"
            memory: "1Gi"
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

Bu manifest ile pod scheduling, OOM ve CPU throttling risklerini azaltır, container orchestration davranışı gerçekçi şekilde gözlemlenir.

Profiling adımları: uygulama dili Python ise py-spy; Go ise net/http/pprof veya pprof binary kullanın. Örnek py-spy profil kaydı: kubectl exec -it -- apt-get update && apt-get install -y python3-pip && pip3 install py-spy && kubectl exec -it -- py-spy record -o /tmp/profile.svg --pid 1 --duration 30s. Yük testi: hey -z 30s -c 50 http://:/api. Karşılaştırma: baseline profil (ör: profile_baseline.svg) alıp kaynak sınırlarını değiştirdikten sonra (örn. limits.cpu 2000m -> 1000m) yeniden profil alın; CPU profillerini karşılaştırırken hot path fonksiyon süreleri ve syscall/GC etkilerini ölçün. Neden: CPU throttling ve GC tuningi, latency tail'lerini doğrudan etkiler; profiller hot path'leri gösterir ve optimizasyonun mekanizması bu fonksiyonların CPU kullanımı azaltılarak latency'nin düşürülmesidir.

CI CD pipeline: deterministik artifact, cache ve Terraform ile infrastructure as code

Deterministik pipeline için üç ilke: 1) kaynak-odaklı cache anahtarı (lockfile checksum), 2) content-addressable image/tag (sha256 digest), 3) immutable infra plan. GitHub Actions örneği (cache + build + push + terraform plan):

name: ci
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Cache node_modules
        uses: actions/cache@v4
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
      - name: Build and push
        env:
          REGISTRY: ${{ secrets.REGISTRY }}
        run: |
          DOCKER_BUILDKIT=1 docker buildx build --push --tag $REGISTRY/myapp:$(git rev-parse --short HEAD) .
  infra:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - uses: actions/checkout@v3
      - name: Terraform Init
        run: |
          terraform init -backend-config="bucket=${{ secrets.TF_STATE_BUCKET }}"
      - name: Terraform Plan
        run: terraform plan -out=tfplan

Bu pipeline'da cache key olarak lockfile hash'i kullanmak deterministik dependency set sağlar; image tag olarak commit hash/digest kullanmak aynı kodun aynı artifacte işaret etmesini sağlar.

Terraform state ve infrastructure as code: öneri - remote state (S3/GCS) + state locking (DynamoDB veya GCS locking) kullanın. Komutlar: terraform init -backend-config='bucket=proj-state' && terraform plan -out=tfplan && terraform apply tfplan. Edge case: lockfile drift; çözüm: pipeline'da `npm ci` veya `go mod download` gibi deterministik adımlar ve lockfile doğrulaması (git diff --exit-code package-lock.json) ekleyin. Neden: lockfile drift, farklı runner'larda farklı dependency graph oluşturur; bu da non-deterministic buildlere yol açar. CI CD pipeline içinde otomatik lockfile kontrolü uygulamak, sürüm tutarlılığını sağlar.

LLM eğitimi ve generative ai entegrasyonu: önbellekleme, audit ve güvenlik

LLM çağrıları maliyetli ve non-deterministic olabilir; önbellekleme ile tekrarlı istekleri azaltın. Teknik uygulama: prompt+context checksum'u (SHA256) anahtar yapıp Redis'te saklayın. Node.js örnek cache kodu:

const crypto = require('crypto')
const Redis = require('ioredis')
const redis = new Redis(process.env.REDIS_URL)

async function cachedLLM(prompt, model) {
  const key = 'llm:' + crypto.createHash('sha256').update(model + '|' + prompt).digest('hex')
  const cached = await redis.get(key)
  if (cached) return JSON.parse(cached)
  const resp = await callLLMApi(model, prompt) // uygulamaya göre OpenAI/Anthropic vs
  await redis.set(key, JSON.stringify(resp), 'EX', 3600)
  return resp
}

Bu yaklaşımla generative ai çağrılarının deterministiğini bir ölçüde artırır, maliyeti düşürür ve eğitim (llm eğitimi / llm kursu) demo senaryolarında tekrarlanabilir örnekler sağlar.

Audit ve gözlemlenebilirlik: LLM yanıtlarını OpenTelemetry span'larına bağlayın ve request/context checksum'unu trace metadata olarak gönderin. Örnek komut: otel-collector konfigürasyonuyla traces ve metrics to AWS X-Ray veya Google Cloud Trace aktarımı yapın. Güvenlik: prompt enjeksiyonunu azaltmak için prompt template'lerini server-side kontrol edin; sensitive environment secrets'ları LLM prompt'larına inject etmeyin. Bu başlıklar hem yapay zeka kursu içeriği, hem de devops eğitimi ve docker eğitimi/kubernetes eğitimi uygulamalarında ele alınmalı.

Operasyonel incelikler, edge case'ler ve eğitim planı önerisi

Edge case: local minikube üzerindeki nodePort testlerinde host network I/O sınırları farklı olabilir; production için multicore node testleri gereklidir. Deney: minikube profile create perf --cpus=8 --memory=16384; minikube start -p perf --driver=docker. Yük testi aracınız: vegeta veya hey; örnek vegeta komutu: echo "GET http://$IP:$PORT/api" | vegeta attack -duration=1m -rate=200 | vegeta report.

Eğitim planı önerisi: 1) docker eğitimi: Dockerfile, BuildKit, cache stratejileri; 2) kubernetes eğitimi: manifests, resource tuning, HPA; 3) terraform eğitimi: remote state ve module best practices; 4) ai destekli yazılım geliştirme ve generative ai modülü: LLM entegrasyonu, önbellekleme, audit. Her modülde pratik ödev olarak vibe coding kursu tarzı hands-on lab verin: minikube + Terraform ile tam bir cloud native mimari kurup CI CD pipeline ile deploy edin. Bu yapı aynı zamanda aws eğitimi veya google cloud eğitimi modüllerinde genişletilebilir.

Sık Sorulan Sorular

CI CD pipeline içinde deterministik Docker cache nasıl sağlanır?

Öncelikle Dockerfile'ı dependency-first sıraya göre düzenleyin; DOCKER_BUILDKIT=1 ve docker buildx ile --cache-from/--cache-to kullanın. Pipeline'da cache key olarak lockfile checksum'u kullanın: key: ${{ hashFiles('**/package-lock.json') }}. Build sonrası image'i digest ile push edin: docker buildx build --push --tag $REGISTRY/myapp@sha256:$DIGEST . Bu sayede aynı kaynak kümesi aynı layer dizisini üretir ve artifact deterministik olur.

minikube üzerinde LLM inference performansını nasıl profillemeliyim?

Önce minikube start ile yeterli kaynak verin (cpu/memory). Pod içine py-spy veya pprof agent yerleştirip yük testi ile birlikte kayıt alın: kubectl exec -- py-spy record -o /tmp/profile.svg --duration 30s. Yük için hey veya vegeta kullanın: hey -z 30s -c 50 http://:/predict. Sonuçları baseline ve tuning sonrası karşılaştırın; özellikle GC, lock contention ve syscall oranlarına bakın. Ayrıca eBPF tabanlı ağ ölçümü için cilium/hubble veya bpftrace kullanın.

Terraform ile infrastructure as code'da state yönetimini nasıl sağlam ve tekrarlanabilir tutarım?

Remote state backend (S3 veya GCS) ve state locking (DynamoDB veya GCS locking) kullanın. Pipeline içinde terraform init -backend-config='bucket=...' ile başlatın, plan'ı tfplan dosyasına çıkartın: terraform plan -out=tfplan && terraform apply tfplan. Ayrıca module ve provider versiyon sabitlemesi yapın, terraform validate ve terraform fmt aşamalarını CI'ye ekleyin. State drift'i engellemek için düzenli plan taramaları ve drift alarm'ları ekleyin.