> For the complete documentation index, see [llms.txt](https://docs.kangal.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kangal.dev/tr/production-operasyonlari/deployment.md).

# Deployment

Docker Compose'u yerel geliştirme ve yalıtılmış tanıtım ortamları için kullanın. Paylaşılan test, hazırlık ve üretim ortamlarında imzalı üretim Helm paketini kullanın. Compose dosyası yerel kimlik bilgileri, tek düğümlü bağımlılıklar ve ana makine portları içerdiğinden üretim topolojisi olarak değerlendirilmemelidir.

## Dağıtım kipleri

Chart dört dağıtım kipini destekler:

| Kip             | Bileşenler                        | Kullanım amacı                                                |
| --------------- | --------------------------------- | ------------------------------------------------------------- |
| `standalone`    | API ve ön yüz                     | Değerlendirme veya küçük, özel bir kontrol düzlemi            |
| `control-plane` | API ve ön yüz                     | Ayrı dağıtılan veri düzlemlerine sahip üretim kontrol düzlemi |
| `data-plane`    | Bağımsız veri düzlemi             | Kontrol düzlemine bağlı bölgesel veya uç çalışma zamanı       |
| `split`         | API, ön yüz ve proxy/veri düzlemi | Birleşik bölgesel kurulum                                     |

Arka plan çalışanları bağımsız olarak etkinleştirilir. Üretimde API üreticilerini ve çalışanları ayrı Deployment kaynakları olarak çalıştırın; böylece iş yürütme yükü istek işleme kaynaklarıyla yarışmaz.

## Ön koşullar

* Desteklenen bir ingress veya Gateway API uygulamasına sahip Kubernetes kümesi;
* hedef namespace için Helm 3 ve `kubectl` erişimi;
* replica set veya sharded cluster transaction desteğine sahip haricî MongoDB;
* kimlik doğrulamalı ve kalıcı Redis;
* önceden oluşturulmuş çalışma zamanı Secret'ı veya haricî secret operatörü;
* aynı sürümden değiştirilemez API, ön yüz ve veri düzlemi imajları;
* platform ekibi tarafından hazırlanmış DNS, TLS issuer, depolama, izleme ve uyarılar.

Seçilen sürüme ekli imzalı chart paketini indirip doğrulayın. Ardından `KANGAL_CHART` değişkenini açılmış chart dizinine veya pakete yöneltin:

```bash
export KANGAL_CHART=/secure/path/kangal-<chart-version>.tgz
export RELEASE=kangal
export NAMESPACE=kangal
```

## Çalışma zamanı Secret sözleşmesi

Sürümü render etmeden önce çalışma zamanı Secret'ını gizli bilgi dağıtım sisteminizle oluşturun. API ve arka plan çalışanları aynı veri tabanı, Redis, imzalama ve alan şifreleme malzemesini kullanmalıdır. Değerleri kabuk geçmişine veya Helm komut argümanlarına yazmayın.

Secret genellikle `MONGODB_URL`, `REDIS_URL`, `SECRET_KEY`, `FIELD_ENCRYPTION_KEY`, OAuth/SMTP kimlik bilgileri ve sağlayıcı kimlik bilgileri gibi anahtarlar sunar. Çok bölgeli çalışanlar ayrıca ortak kalıcı iş Redis URL'sini kullanır. Ayrıntılar için [Gizli bilgiler](/tr/production-operasyonlari/secrets.md) rehberine bakın.

## Üretim values örneği

Ortama özgü overlay dosyasını korumalı bir dağıtım deposunda tutun. Aşağıdaki örnek beklenen yapıyı gösterir; eksiksiz bir ortam dosyası değildir:

```yaml
deploymentMode: control-plane

global:
  imagePullSecrets:
    - name: kangal-registry

api:
  replicaCount: 3
  image:
    repository: registry.example.com/kangal-api
    tag: "<immutable-release-tag>"
    pullPolicy: IfNotPresent
  config:
    APP_ENV: production
    KANGAL_BACKGROUND_JOBS_BACKEND: redis-streams
    KANGAL_BACKGROUND_JOBS_RUN_WORKER: "false"
  extraEnvFrom:
    - secretRef:
        name: kangal-runtime
  autoscaling:
    enabled: true
    minReplicas: 3
    maxReplicas: 12
  podDisruptionBudget:
    enabled: true
    minAvailable: 2
  networkPolicy:
    enabled: true

backgroundJobs:
  enabled: true
  replicaCount: 2
  networkPolicy:
    enabled: true

frontend:
  replicaCount: 3
  image:
    repository: registry.example.com/kangal-frontend
    tag: "<immutable-release-tag>"
  config:
    NODE_ENV: production
    API_BASE_URL: http://kangal-api:8001
  autoscaling:
    enabled: true
    minReplicas: 3
    maxReplicas: 10
  podDisruptionBudget:
    enabled: true
    minAvailable: 2
  networkPolicy:
    enabled: true

mongodb:
  enabled: false
  external:
    enabled: true
    connectionSecret:
      name: kangal-runtime
      key: MONGODB_URL
    topology:
      mode: replicaset
      verified: true

redis:
  enabled: false

ingress:
  enabled: true
  className: nginx
  hosts:
    - host: console.example.com
      front:
        path: /
        pathType: Prefix
      api:
        paths:
          - path: /admin
          - path: /api
          - path: /auth
          - path: /health
          - path: /ready
  tls:
    - secretName: kangal-tls
      hosts:
        - console.example.com
```

Ağ politikasını etkinleştirmeden önce çıkış kurallarını inceleyin. DNS, MongoDB, Redis, gözlemlenebilirlik, kimlik, e-posta, yapay zekâ sağlayıcıları ve tanımlanmış üst sunucular erişilebilir kalmalıdır. Yalnızca port açan bir politika başlangıç noktasıdır; üretimde hedef bazlı izin listesi uygulayın.

## Render ve doğrulama

Tüm kontrolleri dağıtılacak chart ve overlay dosyasının tam hâliyle çalıştırın:

```bash
helm dependency build "$KANGAL_CHART"
helm lint "$KANGAL_CHART" -f values.production.yaml
helm template "$RELEASE" "$KANGAL_CHART" \
  --namespace "$NAMESPACE" \
  -f values.production.yaml > /tmp/kangal-rendered.yaml
kubectl apply --dry-run=server -f /tmp/kangal-rendered.yaml
```

Render edilmiş imaj etiketlerini, Secret referanslarını, ServiceAccount token bağlamalarını, güvenlik bağlamlarını, yazılabilir volume'leri, probe'ları, Service, ingress, PDB, HPA ve ağ politikalarını inceleyin. Haricî bağımlılıkların erişimini sunucu taraflı dry-run sonrasında ayrıca sınayın.

## Kurulum veya yükseltme

Şema, yapılandırma ya da durum geçişi içeren değişikliklerden önce doğrulanmış bir veri tabanı yedeği alın. Ardından sürümü dağıtın:

```bash
helm upgrade --install "$RELEASE" "$KANGAL_CHART" \
  --namespace "$NAMESPACE" \
  --create-namespace \
  -f values.production.yaml \
  --atomic \
  --cleanup-on-fail \
  --wait \
  --wait-for-jobs \
  --timeout 15m \
  --history-max 10
```

`--atomic`, başarısız sürümde önceki Helm revizyonuna döner. MongoDB, Redis veya operatör tarafından değiştirilmiş Kangal yapılandırması için ilgili yedek ya da anlık görüntü kurtarma prosedürünü ayrıca uygulayın.

Yeni bir kalıcı iş payload sürümü getiren dağıtımda önce uyumlu çalışanları yayınlayın. Eski stream kayıtları tükenene kadar yeni çalışanları hazır tutun. Uyumsuz payload teslimi güvenli biçimde başarısız olur; içeriği tahmin edilerek çalıştırılmaz.

## Kabul kontrolleri

```bash
kubectl -n "$NAMESPACE" get deploy,pod,svc,ingress,hpa,pdb
kubectl -n "$NAMESPACE" wait \
  --for=condition=Available deployment \
  -l app.kubernetes.io/instance="$RELEASE" \
  --timeout=10m
kubectl -n "$NAMESPACE" logs \
  -l app.kubernetes.io/instance="$RELEASE",app.kubernetes.io/component=api \
  --tail=200
curl -fsS https://console.example.com/health
curl -fsS https://console.example.com/ready
```

Ayrıca oturum açmayı, kimliği doğrulanmış bir yönetici okumasını, yönlendirilmiş bir test isteğini, çalışan sağlığını, kuyruk derinliğini, MongoDB transaction yeteneğini, Redis kalıcılığını, metrik toplamayı ve sunulan sertifikayı doğrulayın. Değişiklik routing, TLS, WebSocket, gRPC, TCP, eklenti veya üst sunucu işlemesine dokunuyorsa ilgili protokol ve yük testlerini çalıştırın.

## Geri alma

```bash
helm history "$RELEASE" -n "$NAMESPACE"
helm rollback "$RELEASE" <revision> -n "$NAMESPACE" --wait --timeout 10m
```

Geri almadan önce sürüm notlarındaki veri uyumluluğunu kontrol edin. Durum kurtarması gerekiyorsa yazmaları dondurun ve [Yedekleme ve geri yükleme](/tr/production-operasyonlari/backup-restore.md) ya da yapılandırma geri alma akışını izleyin. Eski ve yeni Helm revizyonlarını, imaj özetlerini, nedeni, zaman damgalarını ve geri alma sonrası smoke test kanıtını kaydedin.

## Sorumluluklar

Chart, tanımlanan Kubernetes kaynaklarını üretir; Kubernetes bunları çalıştırır. Doğru values, bağımlılık topolojisi, Secret oluşturma, ağ izin listeleri, depolama, sertifika issuer hazırlığı, kapasite, kabul testleri ve geri alma onayı operatörün sorumluluğundadır.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.kangal.dev/tr/production-operasyonlari/deployment.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
