Git Push ile Kubernetes'e Otomatik Deploy
Bir web projesini güncellediğinizde genelde şu adımlar vardır: kodu kaydetmek, sunucuya bağlanmak, imajı derlemek, kümede güncellemek. Bu işler tekrarlandıkça hem zaman kaybedilir hem de küçük hatalar ortaya çıkabilir.
GitOps yaklaşımında ise tek kaynak Git deposudur. Siz main branch'ine push yaptığınızda geri kalan adımların büyük kısmı otomatik işler. Bu yazı, kişisel bir Next.js blog projesinde kurulan akışı herkesin okuyabileceği sade bir dille anlatır; ayrıntılı komut listesi veya kurulum rehberi değildir.
Süreç tek cümlede
Kod değişir → otomasyon yeni container imajını üretir → Kubernetes tanım dosyası güncellenir → küme yeni sürümü devreye alır.
Kim ne yapar?
| Adım | Ne olur? | Kim / ne yapar? |
|------|----------|-----------------|
| 1 | Geliştirici blog, sayfa veya kod değişikliği yapar | Siz (yerel bilgisayar) |
| 2 | Değişiklikler main branch'ine gönderilir | git push |
| 3 | Yeni uygulama imajı derlenir (amd64 + arm64) | GitHub Actions |
| 4 | İmaj paket kayıt defterine yüklenir | GitHub Container Registry (GHCR) |
| 5 | Kümedeki deployment tanımındaki imaj etiketi güncellenir | GitHub Actions (otomatik commit) |
| 6 | Küme Git'teki tanımla eşitlenir | Argo CD |
| 7 | Eski pod kapanır, yenisi açılır | Kubernetes (rolling update) |
Bu tabloda önemli nokta şudur: siz yalnızca 1 ve 2'yi yaparsınız; geri kalanı tanımlı kurallar yürütür.
Kullanılan parçalar (kısaca)
| Parça | Görevi (sade anlatım) |
|-------|------------------------|
| GitHub | Kodun ve deployment tanımlarının ana deposu |
| GitHub Actions | Push sonrası imaj build ve manifest güncelleme |
| GHCR | Derlenmiş container imajlarının saklandığı yer |
| Argo CD | Git'teki k8s klasörünü izleyip kümede uygular |
| Kubernetes | Uygulamanın çalıştığı ortam |
Argo CD, Git deposunu sürekli dinleyen bir senkronizasyon aracı gibi düşünülebilir: Git'te ne yazıyorsa küme ona yaklaşır.
Neden imaj etiketinde commit numarası?
Her deploy'da latest yerine commit SHA (Git'teki benzersiz kimlik) kullanmak yaygın bir iyi pratiktir. Böylece hangi kodun canlıda olduğu netleşir; geri almak veya karşılaştırmak kolaylaşır.
Multi-arch (çok mimari) imaj neden önemli?
Bazı sunucular amd64, bazı geliştirme makineleri arm64 (örneğin Apple Silicon) kullanır. İmaj yalnızca tek mimari için üretilirse küme pod'u başlatamayabilir. Otomasyonun her iki mimariyi de desteklemesi bu tür sürprizleri azaltır.
Manuel deploy hâlâ gerekir mi?
Hayır, günlük akış için gerekmez. Acil müdahale veya otomasyon devreye girmeden önce test için yerelde script ile deploy seçeneği tutulabilir; asıl hedef push ile otomatik güncellemedir.
Bu yazı neden burada?
Bu içerik, otomatik deploy zincirinin uçtan uca çalıştığını doğrulamak için eklenmiş küçük bir deneme yazısıdır. İleride aynı yöntemle yeni blog yazıları ve site güncellemeleri de main'e push edilerek yayına alınabilir.
Özet
- Git'e push = deploy sürecinin başlangıcı.
- CI (GitHub Actions) imajı üretir ve tanım dosyasını günceller.
- Argo CD değişikliği kümede uygular.
- Siz kod yazmaya odaklanırsınız; tekrarlayan sunucu işleri azalır.
Daha derinlemesine kurulum adımları (Argo CD kurulumu, secret'lar, NodePort ayarları) ayrı teknik yazılarda ele alınabilir; bu metin yalnızca genel resmi ve yol haritasını paylaşmak içindir.