16 Ağustos 2026 Pazar

Uygulama Dağıtımını Altyapı İle Karıştırma

 Son yıllarda, Terraform'un yükselişi  (Pulumi gibi benzer araçların) Takımların altyapı kodlarını taşınmasına izin vermesi, altyapı deploymentlarında aynı yolla kodlarında taşınmasına izin vermelidir.

Pipeline da altyapı kodunu deploy edebiliyorsan, bu altyapı ve uygulama deploymentları bir seferde yapılabilirliğin önünü açmış olacak değildir. 





Birçok takım tek bir pipeline yaratıyor ve bu pipeline içerisinde hem altyapıyı oluşturuyor ( Bir kubernetes cluster, container, registry v.b )  oluşturuyor ve uygulama bu pipeline en üstünde deploy ediliyor. 


Bu teoride harika çalışsa da, (dağıtımlar, her biriyle sıfırdan başladığınız anlamına geldiği için) kaynaklar ve zaman açısından oldukça israftır.


Çoğu durumda, uygulama kodu altyapıdan çok daha hızlı değişecektir. 


Tüm şirketler için genelleştirmek için çok zordur.  ancak çoğu durumda uygulama değişim oranı Altyapıdan 2x-10 kat daha sık olabilir.


Her ikisini de yapan tek bir pipeline  varsa, bu durumda  asla basit bir şekilde altyapıyı kaldırıp/yeniden yaratamazsınız. Çünkü yeni bir versiyon deploy etmeye ihtiyacınız olacaktır.


Her şeyi (infra/app) dağıtan pipeline 30 dakika sürebilirken, bir pipeline yalnızca bir uygulama deploy etmesi sadece 5 dakikasını alır. Siz üzerinde herhangi bir altyapısal bir değişiklik sebebi olmayan sadece bir deployment adımı için  25 dakika fazladan harcamış olursunuz. 





.


İkinci dezavantaj, tek bir pipeline kırılırsa, kimin bakması gerektiğinin net olmamasıdır.

Eğer bir geliştiriciysem ve uygulamamı Kubernetes'te dağıtmak istiyorsam, Terraform hataları, sanal ağlar veya depolama birimleri ilgilenmiyorum diyebilme hakkım oluşuyor.


DevOps'un amacı, geliştiricileri self servis araçlarla güçlendirmektir. Geliştiricileri zorlamamalı.


İhtiyaç duymadıklarında altyapıyla başa çıkmamalılar, yaptıkları işlemde ilgili değillerse geriye doğru bir bakacakları bir işlem olmamalıdır.

 

Doğru çözüm elbette dağıtım veya altyapıyı kendi sahip oldukları pipelinelarda bölmektir.


Altyapı pipeline’lar, uygulamadan daha az tetiklenecek ve Uygulama dağıtımları daha hızlı yaratılacaktır (oluşturma süresini kısaltacaktır).





Geliştiriciler ayrıca, uygulama pipeline bozulduğunda uğraşmalarına gerek olmadığını da bilecekler.


Altyapı hatalarıyla veya Kubernetes cluster nasıl oluşturulduğunu bilmelerine gerek yoktur. 


Operatörler geliştiricileri hiç etkilemeden altyapı pipeline üzerinde ince ayar yapabilirler. Herkes bağımsız olarak çalışabilir.


Bazen şirketlerin bulunduğu bu anti-desenlerde (altyapıyı uygulamayla karıştırıldığını) görüyoruz.


Uygulamanın tarafından sağlanan bir şeye ihtiyacı olduğu için ilerlemenin tek yolu altyapı pipeline larda olmalıdır.


Klasik örnek, Terraform ile bir şeyler oluşturmak ve ardından çıktısını iletmektir. (örneğin bir IP adresi)


Uygulama koduna input olarak pipeline dinlemeli. Eğer sınırlamaya sahipseniz, önceki anti-desenden muzdarip olduğunuz anlamına gelir (Altyapının ayrıntılarına uygulama birleştirme sorunu ) ve bu sorunu kaldırmanız gerekir.  (yani Uygulama kodunun dağıtılması için belirli bir IP adresine ihtiyaç duymamalıdır).


Aynı yaklaşımın veritabanı yükseltmelerine genişletilebileceğine dikkat edin. Eğer veritabanı değişiklikleri için pipeline  kullanıyorsanız, uygulama kaynak kodundan bağımsız olmalıdırlar.


Yalnızca DB şemasını veya yalnızca uygulama kodunu kendi başına güncelleyebilmeniz gerekir,


Her dağıtım için her ikisini de yapmak zorunda kalmadan bu ayrım kullanılabilir olmalıdır.

9 Ağustos 2026 Pazar

Kubernetes İle Birleşme Uygulamaları - Sebepsiz Özellikler/Hizmetler


    Bir uygulama geliştirmediğimiz sürece her container Kubernetes'in içinde koşan uygulamaların her birini bilmesine gerek yoktur.


Sadece yaratılan bir kümeyi idare etmeli, uygulamanız Kubernetes API veya diğer harici servisleri  kurcalamamalıdır. Sadece küme içerisinde varsayılan servisleri, hizmetleri bilmeli.



Bu senaryo, Kubernetes'i benimseyen ve başarısız olan aşırı hevesli ekiplerde çok yaygındır.


Uygulamalarını kümeden izole edin. Bazı klasik örnekler şu uygulamalardır:


* Diğer bölmelerle veri paylaşımı için belirli bir birim yapılandırması beklenmeli.


• Kubernetes ağı tarafından kurulan belirli bir hizmet/DNS adlandırması beklenmeli veya Belirli açık port varlığını varsaymalı.


• Kubernetes etiketlerinden ve açıklamalarından bilgi alınmalı.


• Bilgi için kendi bölmelerini sorgulamalı (örneğin hangi IP adresine sahip olduklarını görmek için)


• Yerel iş istasyonlarında düzgün çalışması için bir init veya sidecar konteynerine ihtiyaç duyar


• Diğer Kubernetes hizmetlerini doğrudan aranmalı. (örneğin,  Vault API gizli bilgileri bir Vault kurulumundan almalı ki varsayılan o anki cluster da olmalı.)


• Yerel bir kube yapılandırmasından veri okumalı.


  • Kubernetes API'sini uygulama içinden doğrudan kullanmalı.






Uygulamanız Kubernetes'e özgüyse (Otomatik ölçekleyici veya operatör) gerçekten de Kubernetes hizmetlerine doğrudan erişmesi gerekir.   


Ama standart web uygulamalarının %99'u bunun dışındadır.  uygulamanız tamamen Kubernetes'in içinde çalıştığından habersiz olmalı.








Uygulamanızın Kubernetes'e bağlı olup olmadığını gösteren litmus testi çalıştırma yeteneğini gösterir. 


Uygulamanız için  bir Docker compose file yaratırsanız basit bir şekilde ölecektir. Bu demektir ki; o zaman 12 faktörlü uygulama ilkelerini ve uygulamanızı takip ettiğiniz anlamına gelir özel ayarlara ihtiyaç duymadan herhangi bir cluster da kurulabilir.



Yerel Kubernetes testini anlamak önemlidir. Birkaç tane yerel Kubernetes dağıtımları için çözümler vardır.  (minikube, microk8s, kind vb.)


Bu çözümlere bakın ve bir uygulama üzerinde çalışan bir geliştiriciyseniz. Kubernetes'e dağıtmak ayrıca Kubernetes'i kendiniz çalıştırmanız gerekir.





Bu gerçeklerden daha uzak olmamalıdır. Uygulamanız doğru tasarlanmışsa bunları yapmamalısınız.


Taşırım doğru yapılmış ise entegrasyon testlerini local olarak çalıştırmak için Kubernetes'e ihtiyaç yoktur. Sadece uygulamayı kendi kendine başlatın. (Docker veya Docker-compose ile) ve testlerle doğrudan başlayın.





Bağımlılıklarınızdan bazılarının harici bir Kubernetes kümesinde çalışıyor olması sorun değil. Ama İşlevselliğini test ederken uygulamanın kendisinin Kubernetes'in içinde çalışmasına gerek olmamalıdır.


Alternatif olarak, yerel Kubernetes geliştirme için özel çözümlerden herhangi birini de kullanabilirsiniz.


Okteto, garden.io ve tilt.dev gibi.


19 Temmuz 2026 Pazar

Konteyner imajları içerisindeki Konfigürasyonlar


* Herhangi bir ortamda çalışabilmeleri anlamında "genel" olmalıdır.



* Konteyner görüntüleriniz bir kez oluşturulmalı ve daha sonra birinden yükseltilmelidir


* Konteynerin kendisinde hiçbir yapılandırma bulunmamalıdır.




Eğer Konteyner İmaj:


• sabit kodlanmış IP adresine sahipse,


• şifreler ve secret key içerirse,


• Diğer hizmetlere belirli URL'leri temsil ederse,


• "dev", "qa", "production" gibi etiketlere sahipse,


..O zaman çevreye bağlı konteyner görüntüleri oluşturma tuzağına düştünüz.






Bu durum her farklı ortam için, dağıtımda imajı yeniden oluşturmanız gerektiği anlamına gelir.




Bu sorunun çözümü çok basittir. Bilen "genel" konteyner görüntüleri oluşturun


Üzerinde koştukları ortam hakkında hiçbir şey yok. Yapılandırma için herhangi bir harici işlem.


Kubernetes configmaps, Hashicorp Consul, Apache Zookeeper vb. gibi yöntemler.






Artık tüm kümelerinizde dağıtılan tek bir görüntüye sahipsiniz.



İkincil bir avantaj, kümenizdeki yapılandırmayı değiştirmeniz gerekirse,


Tam konteyneri yeniden oluşturmak yerine harici yapılandırma sistemini basitçe değiştirebilir


Sıfırdan görüntü. Kullandığınız programlama diline ve çerçeveye bağlı olarak,


Herhangi bir yeniden başlatma veya yeniden dağıtım olmadan canlı yapılandırmayı bile güncelleyebilirsiniz.