Azure Kubernetes Service (AKS)’e Azure Pipelines ile Uygulama Dağıtımı Rehberi

Modern yazılım geliştirme süreçlerinde uygulamaların hızlı, güvenilir ve otomatik bir şekilde dağıtılması kritik bir öneme sahiptir. Bu kapsamlı rehber, Azure Kubernetes Service (AKS) üzerine Azure Pipelines kullanarak Continuous Integration/Continuous Delivery (CI/CD) süreçlerinin nasıl kurulacağını adım adım ele almaktadır. Bu yöntemle yazılım geliştiriciler, üretim ortamına kadar uzanan dağıtım akışlarını otomatize edebilir ve operasyonel verimliliği önemli ölçüde artırabilirler.

Günümüzün rekabetçi iş dünyasında, işletmelerin müşterilerine hızlı bir şekilde değer sunması hayati öneme sahiptir. Bu durum, yazılım geliştirme ekipleri üzerinde sürekli entegrasyon (CI) ve sürekli dağıtım (CD) pratiklerini benimseme baskısı yaratmaktadır. Peki, bu süreci en verimli ve esnek şekilde nasıl yönetebiliriz? Cevap genellikle Azure Kubernetes Service (AKS) ve Azure Pipelines gibi güçlü bulut tabanlı araçların entegrasyonunda yatmaktadır. Bu iki teknoloji, modern DevOps kültürünün temel taşlarını oluşturarak, uygulamaların geliştirme aşamasından üretime kadar olan yolculuğunu sorunsuz ve otomatik hale getirir.

Öncelikle, konteynerizasyonun yükselişiyle birlikte karmaşık uygulamaların dağıtımı ve yönetimi oldukça kolaylaşmıştır. Kubernetes, konteynerleştirilmiş iş yüklerini ve hizmetlerini yönetmek için açık kaynaklı, portatif ve genişletilebilir bir platform sunar. Uygulamaların ölçeklenmesinden, hatalara karşı direncine, kaynak kullanımının optimizasyonundan, dağıtım süreçlerinin standartlaşmasına kadar birçok avantaj sağlar. Ancak Kubernetes’in kendisi karmaşık olabilir; işte bu noktada Azure Kubernetes Service (AKS) devreye girer. AKS, Kubernetes’i yönetilen bir hizmet olarak sunarak, altyapı yönetimi yükünü Azure’a bırakır ve geliştiricilerin sadece uygulamalarına odaklanmasını sağlar. Bu sayede, operasyonel maliyetler azalır, güvenlik güncellemeleri otomatikleşir ve kümelerin bakımı basitleşir. Örneğin, büyük bir e-ticaret platformu, yoğun talep dönemlerinde otomatik ölçeklenebilirlik sağlamak için AKS’i tercih ederek, insan müdahalesi olmadan binlerce konteyneri sorunsuz bir şekilde yönetebilir.

İkinci olarak, Azure Pipelines, herhangi bir dil veya platform için CI/CD iş akışları oluşturmanızı sağlayan kapsamlı bir hizmettir. Kod değişikliklerinin otomatik olarak derlenmesini, test edilmesini ve dağıtılmasını sağlayarak, geliştiricilerin daha hızlı yinelemeler yapmasına ve daha az hata ile karşılaşmasına olanak tanır. Bir yazılım ekibi, yeni bir özellik geliştirirken, kodu her değiştirdiğinde otomatik testlerin çalışmasını ve başarılı olursa uygulamanın AKS üzerindeki test ortamına dağıtılmasını Azure Pipelines ile sağlayabilir. Bu durum, manuel dağıtım süreçlerinin ortadan kalkmasıyla hata oranlarını düşürür ve dağıtım sürelerini dakikalara indirir. Ayrıca, Azure Pipelines’ın YAML tabanlı tanımları sayesinde, CI/CD süreçleri kod olarak versiyonlanabilir (Infrastructure as Code mantığıyla), bu da şeffaflığı ve tekrarlanabilirliği artırır. Geliştirme, test ve üretim ortamları arasındaki tutarlılığı sağlamak, büyük ölçekli projeler için olmazsa olmaz bir gerekliliktir.

Bu iki teknolojinin birleşimi, geliştirme süreçlerini hızlandırmanın yanı sıra, uygulama kalitesini ve operasyonel güvenilirliği de artırır. Azure Pipelines’ın esnekliği sayesinde, Docker görüntüleri oluşturulabilir, Container Registry’ye itilebilir ve ardından Kubernetes manifest dosyaları kullanılarak AKS’e dağıtılabilir. Bu entegrasyon, modern bulut yerel uygulama mimarileri için standart bir uygulama haline gelmiştir. Sonuç olarak, AKS ve Azure Pipelines ile dağıtım yapmak, sadece teknik bir tercih değil, aynı zamanda iş süreçlerini optimize etme, pazar hızına ayak uydurma ve rekabet avantajı elde etme stratejisinin de önemli bir parçasıdır. Bu rehber boyunca, bu güçlü entegrasyonun nasıl adım adım kurulacağını ve kullanılacağını detaylı bir şekilde inceleyeceğiz.

AKS ve Azure Pipelines Nedir? Temel Bilgilerle Konuya Giriş

Uygulama geliştirme ve dağıtım süreçlerini ele alırken, sıklıkla karşımıza çıkan iki kilit teknoloji Azure Kubernetes Service (AKS) ve Azure Pipelines’tır. Bu bölümde, konuya tamamen yabancı okuyucular için bu temel kavramları açıklayarak sağlam bir zemin oluşturacağız. Modern bulut yerel mimarilerinin temelini anlamak, bu araçları etkin bir şekilde kullanmanın ilk adımıdır.

Öncelikle, Kubernetes nedir? Basitçe ifade etmek gerekirse, Kubernetes, konteynerleştirilmiş uygulamaların dağıtımını, ölçeklendirmesini ve yönetimini otomatikleştiren açık kaynaklı bir platformdur. Konteynerler (örneğin Docker konteynerleri), uygulamaları ve bağımlılıklarını izole edilmiş, taşınabilir birimler halinde paketleyerek, farklı ortamlarda tutarlı bir şekilde çalışmalarını sağlar. Kubernetes ise bu konteynerleri binlerce sunucuda (düğümlerde) yöneten bir “orkestratördür”. Bir orkestra şefi gibi, hangi konteynerin nerede çalışacağını, ne zaman ölçekleneceğini, hatalı konteynerlerin nasıl yeniden başlatılacağını ve uygulamaların nasıl internete açılacağını denetler. Pod’lar (bir veya daha fazla konteyneri barındıran en küçük dağıtılabilir birim), Dağıtımlar (Deployment’lar, pod’ların nasıl çalışacağını ve ölçekleneceğini tanımlar) ve Hizmetler (Service’ler, pod’lara dışarıdan veya içeriden erişimi sağlar) Kubernetes’in temel yapı taşlarıdır. Mikroservis tabanlı uygulamalar için vazgeçilmez bir araçtır, çünkü her mikroservisin kendi konteynerinde bağımsız olarak çalışmasını ve yönetilmesini sağlar.

Peki, Azure Kubernetes Service (AKS) nedir? AKS, Microsoft Azure’un sunduğu yönetilen bir Kubernetes hizmetidir. Kubernetes’in karmaşık altyapı yönetimini Azure’a bırakarak, geliştiricilerin ve DevOps ekiplerinin Kubernetes’in sunduğu tüm avantajlardan yararlanmasını sağlar. AKS ile ana düğümlerin (master nodes) bakımı, yamalanması ve yükseltilmesi gibi operasyonel yükler Azure tarafından üstlenilir. Bu da ekiplerin sadece uygulama geliştirme ve dağıtım stratejilerine odaklanmasını mümkün kılar. Örneğin, bir uygulamayı AKS’e dağıttığınızda, Azure sizin için kümenin kontrol düzlemini (API sunucusu, zamanlayıcı vb.) yönetir, böylece siz sadece çalışan düğümleri ve uygulamalarınızı düşünürsünüz. Ayrıca, AKS, Azure Active Directory ile entegrasyon, Azure İzleyici (Monitor) ile izleme ve Azure Sanal Ağlar (VNet) ile ağ entegrasyonu gibi diğer Azure hizmetleriyle sorunsuz bir şekilde çalışır. Otomatik ölçekleme yetenekleri sayesinde, uygulamanızın trafiği arttığında otomatik olarak daha fazla kaynak tahsis edebilir ve trafik azaldığında kaynakları geri çekerek maliyetleri optimize edebilir. Bu esneklik, özellikle değişken iş yüklerine sahip uygulamalar için büyük bir avantajdır.

Şimdi gelelim Azure Pipelines‘a. Azure Pipelines, Microsoft Azure DevOps hizmetinin bir parçası olarak sunulan bulut tabanlı bir sürekli entegrasyon ve sürekli dağıtım (CI/CD) hizmetidir. Geliştiricilerin kodlarını derlemesini, test etmesini ve dağıtmasını otomatikleştiren güçlü ve esnek bir platformdur. Azure Pipelines ile herhangi bir dil (Node.js, Python, Java, .NET, Go vb.) veya platform (Linux, macOS, Windows konteynerleri dahil) için CI/CD iş akışları oluşturabilirsiniz. YAML tabanlı pipeline tanımları kullanır, bu da dağıtım süreçlerinizin kod olarak versiyonlanmasını ve Git depolarında saklanmasını sağlar (Infrastructure as Code prensibi). Bu sayede, dağıtım akışlarınız da uygulamanızın kodu gibi gözden geçirilebilir, test edilebilir ve sürüm kontrolü altında tutulabilir. Örneğin, bir geliştirici kodda bir değişiklik yaptığında, Azure Pipelines otomatik olarak bu kodu çeker, derler, bir Docker görüntüsü oluşturur, testleri çalıştırır ve eğer her şey yolundaysa bu görüntüyü bir konteyner kayıt defterine (örneğin Azure Container Registry) gönderir. Bu süreç, “Sürekli Entegrasyon” olarak adlandırılır. Ardından, “Sürekli Dağıtım” aşamasında, bu yeni görüntü otomatik olarak AKS kümesine dağıtılır. Bu otomasyon, insan hatasını minimize eder, geliştirme döngülerini hızlandırır ve yazılımın pazara sunulma süresini (Time-to-Market) önemli ölçüde kısaltır.

Özetle, AKS, konteynerleştirilmiş uygulamalarınız için güçlü, yönetilen ve ölçeklenebilir bir çalıştırma ortamı sunarken; Azure Pipelines, bu uygulamaların geliştirme aşamasından AKS’e kadar olan tüm dağıtım sürecini otomatikleştiren bir köprü görevi görür. Bu iki aracın entegrasyonu, modern DevOps yaklaşımlarının temelini oluşturur ve ekiplerin daha verimli, güvenilir ve esnek bir şekilde yazılım geliştirmesine olanak tanır. Konteynerizasyon, otomasyon ve bulut altyapısının birleşimi, şirketlerin dijital dönüşüm yolculuğunda önemli bir avantaj sağlar.

AKS’e Dağıtım Öncesi Gerekli Adımlar ve Ortam Kurulumu Nasıl Yapılır?

Azure Kubernetes Service (AKS) üzerine uygulama dağıtımına başlamadan önce, gerekli tüm araçların ve servislerin doğru bir şekilde yapılandırılması hayati öneme sahiptir. Bu ön hazırlık adımları, sorunsuz bir CI/CD süreci için temel oluşturur ve potansiyel aksaklıkları en aza indirir. Bu bölümde, bir AKS kümesi oluşturmaktan, Azure DevOps projesi kurmaya ve gerekli bağlantıları yapılandırmaya kadar tüm adımları detaylı bir şekilde ele alacağız.

Azure Subscription ve Azure CLI Kurulumu

Öncelikle, bir Azure hesabı ve aktif bir aboneliğinizin olması gerekmektedir. Eğer yoksa, Azure Ücretsiz Hesabı oluşturarak başlayabilirsiniz. Ardından, Azure kaynaklarını komut satırından yönetmek için Azure CLI’ı (Command Line Interface) bilgisayarınıza kurmanız gerekmektedir. Azure CLI, Windows, macOS ve Linux üzerinde çalışabilen platformlar arası bir araçtır. Kurulum talimatlarını Azure CLI belgeleri üzerinden bulabilirsiniz. Kurulumdan sonra, terminalinizi açarak az login komutu ile Azure hesabınıza giriş yapın. Bu komut, sizi web tarayıcınız üzerinden Azure portalına yönlendirecek ve kimlik doğrulama işlemini tamamlayacaktır.

AKS Kümesi Oluşturma

Uygulamalarımızı çalıştıracağımız Kubernetes kümesini oluşturmamız gerekiyor. Bu işlem için bir kaynak grubu ve ardından bu kaynak grubunun içine bir AKS kümesi tanımlayacağız. Kaynak grubu, Azure kaynaklarınızı mantıksal olarak düzenlemenizi sağlar.

# Kaynak grubu oluşturma
az group create --name myAKSResourceGroup --location eastus

# AKS kümesi oluşturma
az aks create --resource-group myAKSResourceGroup --name myAKSCluster --node-count 1 --enable-addons monitoring --generate-ssh-keys --kubernetes-version 1.28.3

# AKS kümesine bağlanmak için kimlik bilgilerini alma
az aks get-credentials --resource-group myAKSResourceGroup --name myAKSCluster

Yukarıdaki komutlar sırasıyla myAKSResourceGroup adında bir kaynak grubu oluşturur, içine myAKSCluster adında tek düğümlü bir AKS kümesi kurar ve izleme eklentisini etkinleştirir. Son komut ise kubectl aracının AKS kümenizle iletişim kurmasını sağlayacak kimlik bilgilerini (kubeconfig) yerel makinenize indirir. Artık kubectl get nodes komutunu çalıştırarak kümenizin durumunu kontrol edebilirsiniz.

Azure Container Registry (ACR) Oluşturma

Konteynerleştirilmiş uygulamalarımızın Docker görüntülerini depolamak için bir konteyner kayıt defterine ihtiyacımız var. Azure Container Registry (ACR), Docker görüntülerini ve Open Container Initiative (OCI) yapıtlarını bulutta depolamak ve yönetmek için yönetilen bir hizmettir. Azure Pipelines, oluşturduğu Docker görüntülerini buraya itecektir.

# ACR oluşturma
az acr create --resource-group myAKSResourceGroup --name myACRRegistry --sku Basic --admin-enabled true

# ACR giriş sunucusu adını (login server) almak (pipeline'da kullanılacak)
az acr show --name myACRRegistry --query loginServer --output tsv

Bu komutlar, myACRRegistry adında temel bir ACR örneği oluşturur ve yönetici kullanıcısını etkinleştirir. loginServer çıktısı, Docker görüntülerini itmek ve çekmek için kullanacağımız tam nitelikli kayıt defteri adını sağlayacaktır (örn. myacraregistry.azurecr.io).

Azure DevOps Organizasyonu ve Projesi Oluşturma

CI/CD süreçlerimizi yöneteceğimiz Azure Pipelines için bir Azure DevOps organizasyonu ve projesi oluşturmamız gerekiyor. Azure DevOps Portalına gidin ve bir organizasyon oluşturun veya mevcut bir organizasyonu kullanın. Ardından, yeni bir proje oluşturun (örn. my-aks-app). Bu proje, kaynak kodunuzu (Azure Repos), pipeline tanımlarınızı ve diğer DevOps artefaktlarınızı barındıracaktır.

Servis Bağlantısı (Service Connection) Kurulumu

Azure Pipelines'ın Azure kaynaklarınızla (AKS, ACR) etkileşime geçebilmesi için bir servis bağlantısı oluşturmanız gerekmektedir. Bu bağlantı, Pipeline'ın Azure aboneliğinizde kimlik doğrulaması yapmasını sağlar.

1. Azure DevOps projenize gidin.
2. Sol menüden Project settings (Proje ayarları) seçeneğine tıklayın.
3. Pipelines altında Service connections (Servis bağlantıları) seçeneğini seçin.
4. New service connection (Yeni servis bağlantısı) butonuna tıklayın.
5. Azure Resource Manager tipini seçin ve Next (İleri).
6. Service principal (automatic) veya Service principal (manual) seçeneğini tercih edin. Otomatik seçenek genellikle daha kolaydır.
7. Aboneliğinizi ve kaynak grubunuzu (örn. myAKSResourceGroup) seçin.
8. Servis bağlantınıza açıklayıcı bir ad verin (örn. AzureSubscriptionConnection).
9. Grant access permission to all pipelines (Tüm pipeline'lara erişim izni ver) kutucuğunu işaretleyin (basitlik adına, üretim ortamlarında daha kısıtlı izinler düşünebilirsiniz).
10. Save (Kaydet) diyerek bağlantıyı oluşturun.

Uzman İpucu: Üretim ortamlarında, servis bağlantıları için en az ayrıcalık ilkesini (Least Privilege Principle) uygulayın. Yani, sadece belirli kaynak gruplarına veya aboneliklere erişimi olan ve sadece AKS'e dağıtım için gerekli izinlere sahip bir servis ilkesi kullanın. Bu, güvenlik risklerini önemli ölçüde azaltacaktır.

Tüm bu adımları tamamladıktan sonra, Azure ortamınız ve Azure DevOps projeniz, uygulamanızı AKS'e dağıtmaya hazırdır. Bir sonraki aşamada, örnek bir uygulamanın Docker görüntüsünü oluşturup Kubernetes manifest dosyalarını hazırlayacağız. Bu ön hazırlık, CI/CD sürecinin başarılı bir şekilde otomatize edilmesi için sağlam bir temel oluşturur ve geliştirme ekiplerinin uygulamalarını daha hızlı ve güvenilir bir şekilde pazara sunmasına yardımcı olur.

Örnek Bir Uygulamanın Docker Görüntüsünü Oluşturma

Artık AKS kümemiz ve Azure Container Registry'miz (ACR) hazır olduğuna göre, dağıtımını yapacağımız örnek bir uygulamayı ele alabiliriz. Bu bölümde, basit bir .NET Core Web API uygulamasının Docker görüntüsünü nasıl oluşturacağımızı ve Kubernetes'te çalışacak hale getirecek manifest dosyalarını nasıl hazırlayacağımızı adım adım inceleyeceğiz. Bu örnek, modern mikroservis mimarilerinin temelini oluşturan konteynerizasyon sürecini anlamanıza yardımcı olacaktır.

Senaryomuz için, basit bir "Merhaba Dünya" mesajı döndüren bir .NET Core Web API uygulaması kullanacağız. Bu uygulama, herhangi bir karmaşık veritabanı bağlantısı veya harici bağımlılık gerektirmemesi nedeniyle konuyu basitleştirmek için idealdir. Tabii ki, aynı prensipler daha karmaşık uygulamalar için de geçerlidir.

İlk olarak, yerel makinenizde basit bir .NET Core Web API projesi oluşturun. Örneğin, Visual Studio Code'u veya komut satırını kullanarak aşağıdaki komutla yeni bir proje başlatabilirsiniz:

dotnet new webapi -n MyWebApp
cd MyWebApp

Bu, MyWebApp adında yeni bir Web API projesi oluşturacaktır. Şimdi, bu uygulamayı bir Docker konteyneri içinde çalıştırmak için bir Dockerfile oluşturmamız gerekiyor. Projenizin ana dizininde (MyWebApp klasörünün içinde) Dockerfile adında bir dosya oluşturun ve içine aşağıdaki içeriği yapıştırın:

# ASP.NET Core SDK görüntüsünü kullanarak uygulamayı derle
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY ["MyWebApp.csproj", "./"]
RUN dotnet restore "MyWebApp.csproj"
COPY . .
WORKDIR "/src/."
RUN dotnet build "MyWebApp.csproj" -c Release -o /app/build

# Yayınlama aşaması
FROM build AS publish
RUN dotnet publish "MyWebApp.csproj" -c Release -o /app/publish /p:UseAppHost=false

# Çalıştırma aşaması (daha küçük ve güvenli runtime görüntüsü)
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "MyWebApp.dll"]

Bu Dockerfile, çok aşamalı bir derleme stratejisi kullanır. İlk aşama (build), uygulamanın derlenmesi ve yayınlanması için gerekli SDK'yı içerir. İkinci aşama (publish), uygulamanın dağıtıma hazır hale getirilmiş çıktısını oluşturur. Son aşama (final) ise sadece uygulamanın çalışması için gerekli olan daha küçük ve güvenli ASP.NET Core çalışma zamanı görüntüsünü kullanır. Bu yaklaşım, ortaya çıkan Docker görüntüsünün boyutunu önemli ölçüde azaltır ve güvenlik açıklarını minimize eder. COPY komutları, proje dosyalarını konteynere kopyalar ve dotnet restore, dotnet build, dotnet publish komutları da uygulamayı derleme ve yayınlama işlemlerini gerçekleştirir.

Uygulamamız konteynerize edilmeye hazır olduğuna göre, bunu Kubernetes kümemizde dağıtmak için Kubernetes manifest dosyalarını hazırlamamız gerekiyor. Genellikle bir Deployment ve bir Service nesnesi tanımlarız. Projenizin kök dizininde kubernetes adında bir klasör oluşturun ve içine deployment.yaml ve service.yaml adında iki dosya ekleyin.

kubernetes/deployment.yaml dosyasının içeriği:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mywebapp-deployment
  labels:
    app: mywebapp
spec:
  replicas: 2 # Uygulamanın 2 kopyasını çalıştır
  selector:
    matchLabels:
      app: mywebapp
  template:
    metadata:
      labels:
        app: mywebapp
    spec:
      containers:
      - name: mywebapp
        image: REPLACE_IMAGE_NAME:REPLACE_IMAGE_TAG # Azure Pipelines tarafından doldurulacak
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
      imagePullSecrets:
      - name: acr-secret # ACR'den görüntü çekmek için secret

Bu deployment.yaml dosyası, mywebapp etiketine sahip pod'ların iki kopyasını çalıştıracak bir dağıtım tanımlar. image alanı, Azure Pipelines tarafından derlenen Docker görüntüsünün adıyla ve etiketiyle doldurulacaktır. resources kısmı, konteynerlerin ne kadar CPU ve bellek kullanabileceğini belirler. imagePullSecrets ise, Azure Container Registry gibi özel bir kayıt defterinden görüntü çekerken kimlik doğrulaması için kullanılır. Bu secret'ı daha sonra pipeline'da oluşturacağız.

kubernetes/service.yaml dosyasının içeriği:

apiVersion: v1
kind: Service
metadata:
  name: mywebapp-service
spec:
  selector:
    app: mywebapp # Bu servis, 'mywebapp' etiketine sahip pod'ları hedefler
  ports:
    - protocol: TCP
      port: 80 # Servisin dışarıdan dinleyeceği port
      targetPort: 80 # Pod'un içindeki konteynerin dinleyeceği port
  type: LoadBalancer # Dışarıdan erişilebilir bir LoadBalancer oluşturur

Bu service.yaml dosyası, mywebapp-deployment tarafından oluşturulan pod'lara trafik yönlendiren bir LoadBalancer tipi servis tanımlar. LoadBalancer tipi, Azure'da otomatik olarak bir genel IP adresi atayarak uygulamamızın internet üzerinden erişilebilir olmasını sağlar. port ve targetPort ayarları, trafiğin dışarıdan servise ve oradan da konteynere nasıl yönlendirileceğini belirtir.

Bu dosyaları hazırladıktan sonra, projenizin dizin yapısı aşağıdaki gibi görünmelidir:

MyWebApp/
├── Controllers/
├── Pages/
├── ... (Diğer .NET Core dosyaları)
├── MyWebApp.csproj
├── Dockerfile
└── kubernetes/
    ├── deployment.yaml
    └── service.yaml

Tüm bu adımlar, uygulamanızın konteynerleştirilmesi ve Kubernetes ortamında dağıtıma hazır hale getirilmesi için temel teşkil eder. Dockerfile uygulamayı taşınabilir ve izole edilebilir bir birim haline getirirken, Kubernetes manifest dosyaları bu birimin AKS kümesi içinde nasıl konuşlanacağını, ölçekleneceğini ve erişilebilir olacağını tanımlar. Bir sonraki bölümde, Azure Pipelines kullanarak bu Docker görüntüsünü nasıl derleyeceğimizi ve Azure Container Registry'ye nasıl göndereceğimizi ele alacağız. Bu sayede, kod değişikliklerinizin otomatik olarak dağıtıma hazır artefaktlara dönüşme sürecini otomatikleştireceğiz.

Uygulamanın Sürekli Entegrasyonu (CI): Azure Pipeline ile Docker Görüntüsü Nasıl Oluşturulur ve ACR'ye Gönderilir?

Uygulamamızın kodunu ve Kubernetes manifestlerini hazırladığımıza göre, şimdi sürekli entegrasyon (CI) sürecini Azure Pipelines ile otomatikleştirebiliriz. CI, geliştiricilerin kod değişikliklerini sık sık merkezi bir depoya birleştirdiği ve bu değişikliklerin otomatik olarak derlendiği ve test edildiği bir yazılım geliştirme pratiğidir. Bu bölümde, bir .NET Core uygulamasını Docker görüntüsü haline getirip, Azure Container Registry'ye (ACR) nasıl göndereceğimizi detaylı bir Azure Pipeline (YAML) örneğiyle açıklayacağız.

Azure DevOps projenizin Repos kısmında, projenizi (örneğin, MyWebApp) barındıran bir Git deposu oluşturduğunuzu ve yukarıda hazırladığımız Dockerfile ile kubernetes klasörünü bu depoya yüklediğinizi varsayıyoruz. Şimdi, depoda azure-pipelines.yml adında yeni bir dosya oluşturalım. Bu dosya, CI sürecimizi tanımlayacaktır.

# azure-pipelines.yml
trigger:
- master # master branch'ine yapılan her push bu pipeline'ı tetikleyecek

variables:
  # ACR adınız (önceki adımda oluşturduğumuz)
  acrServiceConnection: 'AzureSubscriptionConnection' # Servis bağlantısı adımız
  azureSubscription: 'myAKSResourceGroup' # Kaynak grubumuzun adı
  acrName: 'myACRRegistry' # ACR adımız
  imageRepository: 'mywebapp' # Docker görüntüsünün adı
  dockerfilePath: '$(Build.SourcesDirectory)/Dockerfile' # Dockerfile yolu
  tag: '$(Build.BuildId)' # Görüntü etiketi olarak Build ID'yi kullan

stages:
- stage: Build
  displayName: Build and Push Docker Image
  jobs:
  - job: BuildAndPush
    displayName: Build and Push
    pool:
      vmImage: 'ubuntu-latest' # Linux tabanlı bir agent kullan

    steps:
    - task: DockerInstaller@0
      displayName: 'Install Docker'
      inputs:
        dockerVersion: 'latest' # En son Docker sürümünü yükle

    - task: Docker@2
      displayName: 'Build and Push an image to ACR'
      inputs:
        command: 'buildAndPush'
        repository: '$(imageRepository)'
        dockerfile: '$(dockerfilePath)'
        containerRegistry: '$(acrServiceConnection)' # Servis bağlantımızı kullan
        tags: |
          $(tag)
          latest
        buildContext: '$(Build.SourcesDirectory)' # Dockerfile'ın bulunduğu dizin

    - task: PublishBuildArtifacts@1
      displayName: 'Publish Artifacts'
      inputs:
        PathtoPublish: '$(Build.SourcesDirectory)/kubernetes'
        ArtifactName: 'kubernetes_manifests'
        publishLocation: 'Container'

Şimdi bu YAML dosyasını adım adım inceleyelim:

• trigger: - master: Bu kısım, master branch'ine yapılan her bir kod değişikliğinin (push) bu pipeline'ı otomatik olarak tetiklemesini sağlar. Bu, sürekli entegrasyonun temelidir; her değişiklik derlenir ve test edilir.
• variables: Burada pipeline'da kullanacağımız değişkenleri tanımlarız. acrName, imageRepository, dockerfilePath gibi değerler, pipeline'ın okunabilirliğini artırır ve bakımı kolaylaştırır. tag: '$(Build.BuildId)' ifadesi, her derleme için benzersiz bir etiket oluşturur (Azure DevOps tarafından otomatik olarak atanan bir kimlik). Ayrıca latest etiketi de ekliyoruz.
• stages: Pipeline'ı mantıksal aşamalara ayırmamızı sağlar. Burada sadece bir Build aşamamız var. Daha sonra CD için başka aşamalar ekleyeceğiz.
• jobs: Bir aşama içinde çalışacak işleri tanımlar. BuildAndPush işi, Docker görüntüsünü oluşturup ACR'ye göndermekten sorumludur.
• pool: vmImage: 'ubuntu-latest': Bu işin çalışacağı ajanı (sunucuyu) belirtir. ubuntu-latest, Azure DevOps tarafından sağlanan Ubuntu tabanlı bir sanal makinedir.
• steps: İşin içinde çalıştırılacak adımları tanımlar.
  • DockerInstaller@0: Bu görev, Azure DevOps aracısına Docker'ı kurar. Bu genellikle CI/CD süreçlerinde konteyner görüntüleri oluşturmak için gereklidir.
  • Docker@2: Bu, Docker komutlarını çalıştırmak için özel bir Azure Pipelines görevidir.
    • command: 'buildAndPush': Hem Docker görüntüsünü derler hem de belirtilen kayıt defterine gönderir.
    • repository: '$(imageRepository)': Docker görüntüsünün adını belirtir (örn. mywebapp).
    • dockerfile: '$(dockerfilePath)': Dockerfile'ın yolunu gösterir.
    • containerRegistry: '$(acrServiceConnection)': Önceki adımda oluşturduğumuz Azure Resource Manager servis bağlantısının adını kullanır. Bu bağlantı sayesinde Azure Pipelines, ACR'ye kimlik doğrulaması yaparak erişebilir.
    • tags: | $(tag) latest: Oluşturulan görüntüye Build.BuildId ve latest etiketlerini ekler.
    • buildContext: '$(Build.SourcesDirectory)': Docker'ın derleme bağlamını belirtir. Tüm kaynak kodunun bulunduğu kök dizini işaret eder.
  • PublishBuildArtifacts@1: Bu görev, kubernetes klasörümüzdeki YAML manifest dosyalarını bir derleme artefaktı olarak yayınlar. Bu, CD aşamasında bu dosyaları kullanmamızı sağlar. Bu artefaktlar, Azure DevOps'ta derleme özet sayfasında görülebilir ve indirilebilir.

Uzman İpucu: Docker görüntülerinizin boyutunu optimize etmek, hem derleme sürelerini kısaltır hem de dağıtım hızını artırır. Çok aşamalı derlemeler (multi-stage builds) ve gereksiz dosyaları .dockerignore ile hariç tutmak bu konuda etkili yöntemlerdir. Ayrıca, güvenlik taramaları için Docker görüntülerinizin kalite ve güvenlik denetimlerini CI aşamasına entegre etmeyi düşünebilirsiniz. Örneğin, üçüncü taraf bir araç (Aqua Security, Clair gibi) veya Azure Container Registry'nin yerleşik güvenlik özellikleri (Defender for Cloud) kullanılabilir.

Bu azure-pipelines.yml dosyasını depomuza kaydettikten sonra, Azure DevOps Pipelines bölümünde yeni bir pipeline oluşturup bu YAML dosyasını seçerek çalıştırabiliriz. İlk çalıştırmada, Azure DevOps kodu çekecek, Docker görüntüsünü derleyecek, ACR'ye gönderecek ve Kubernetes manifest dosyalarını bir artefakt olarak yayınlayacaktır. Bu başarılı CI süreci, bir sonraki aşama olan sürekli dağıtım (CD) için temel bir adımdır. Uygulamanız artık konteynerleştirilmiş ve dağıtıma hazır bir halde beklemektedir.

Uygulamanın Sürekli Dağıtımı (CD): Azure Pipeline ile AKS'e Otomatik Dağıtım Nasıl Yapılır?

Sürekli Entegrasyon (CI) aşamasında Docker görüntümüzü başarıyla oluşturup Azure Container Registry'ye (ACR) gönderdik ve Kubernetes manifest dosyalarımızı bir artefakt olarak yayınladık. Şimdi sıra Sürekli Dağıtım (CD) aşamasında: Bu görüntüyü Azure Kubernetes Service (AKS) kümemize otomatik olarak dağıtmak. Bu bölümde, azure-pipelines.yml dosyamızı genişleterek, AKS'e dağıtım görevini nasıl ekleyeceğimizi ve bu süreci nasıl otomatikleştireceğimizi detaylı bir şekilde inceleyeceğiz.

CD aşaması, CI aşamasının çıktısı olan derlenmiş ve test edilmiş kodun, bir ortamda (test, hazırlık veya üretim) otomatik olarak yayınlanması sürecidir. Bu, insan müdahalesini en aza indirir, hataları azaltır ve uygulamanın pazara sunulma süresini önemli ölçüde hızlandırır.

azure-pipelines.yml dosyamızı güncelleyerek, Deploy adında yeni bir stage ekleyeceğiz. Bu stage, bir önceki Build stage'inden bağımsız olarak veya başarılı bir Build sonrası tetiklenecek şekilde yapılandırılabilir. Basitlik adına, şimdilik aynı pipeline içinde ayrı bir stage olarak ele alacağız:

# azure-pipelines.yml (CI aşamasına ek olarak)
# ... (önceki CI kodları: trigger, variables, Build stage)

- stage: Deploy
  displayName: Deploy to AKS
  dependsOn: Build # Bu stage, Build stage'i başarıyla tamamlandığında çalışır
  jobs:
  - job: DeployJob
    displayName: Deploy to AKS
    pool:
      vmImage: 'ubuntu-latest'
    
    variables:
      # Kubernetes manifest dosya yolu
      kubernetesManifestPath: '$(Pipeline.Workspace)/kubernetes_manifests' 
      imagePullSecretName: 'acr-secret' # ACR secret adı

    steps:
    - task: DownloadPipelineArtifact@2
      inputs:
        artifact: 'kubernetes_manifests'
        path: '$(kubernetesManifestPath)'
      displayName: 'Download Kubernetes Manifests'

    - task: AzureCLI@2
      displayName: 'Create/Update imagePullSecret for ACR'
      inputs:
        azureSubscription: '$(acrServiceConnection)'
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          # ACR login server'ı alın
          ACR_LOGIN_SERVER=$(az acr show --name $(acrName) --query loginServer --output tsv)
          
          # ACR admin kullanıcı adı ve şifresini alın
          ACR_USERNAME=$(az acr credential show --name $(acrName) --query "username" --output tsv)
          ACR_PASSWORD=$(az acr credential show --name $(acrName) --query "passwords[0].value" --output tsv)
          
          # Kubernetes secret'ını oluşturun veya güncelleyin
          kubectl create secret docker-registry $(imagePullSecretName) \
            --docker-server=$ACR_LOGIN_SERVER \
            --docker-username=$ACR_USERNAME \
            --docker-password=$ACR_PASSWORD \
            --namespace default --dry-run=client -o yaml | kubectl apply -f -
          
          echo "ACR secret '$(imagePullSecretName)' created/updated in 'default' namespace."

    - task: KubernetesManifest@1
      displayName: Deploy to Kubernetes cluster
      inputs:
        action: deploy
        kubernetesServiceConnection: '$(acrServiceConnection)' # Servis bağlantımız
        namespace: 'default' # Dağıtım yapılacak namespace
        manifests: |
          $(kubernetesManifestPath)/deployment.yaml
          $(kubernetesManifestPath)/service.yaml
        containers: |
          $(acrName).azurecr.io/$(imageRepository):$(tag) # Doğru görüntü adını ve etiketini kullan
        imagePullSecrets: '$(imagePullSecretName)' # Görüntü çekme secret'ını belirt
        # rollOutRestart: true # Dağıtımdan sonra tüm pod'ları yeniden başlat

Şimdi bu yeni Deploy stage'ini detaylıca inceleyelim:

• stage: Deploy: Bu, dağıtım sürecini temsil eden yeni aşamamızdır.
• dependsOn: Build: Bu, Deploy stage'inin yalnızca Build stage'i başarıyla tamamlandığında çalışacağını garanti eder. Bu, CI/CD akışında mantıksal bir sıralama sağlar.
• jobs: - job: DeployJob: Bu aşamadaki dağıtım görevini tanımlayan bir iştir.
• pool: vmImage: 'ubuntu-latest': Dağıtım için de aynı Ubuntu tabanlı ajanı kullanıyoruz.
• variables: Bu aşamaya özel değişkenler tanımlıyoruz. kubernetesManifestPath, CI aşamasında yayımladığımız artefaktların indirileceği yolu belirtir. imagePullSecretName ise ACR'den görüntü çekerken kullanılacak secret adıdır.
• steps:
  • DownloadPipelineArtifact@2: Bu görev, önceki Build stage'inde PublishBuildArtifacts göreviyle yayımladığımız kubernetes_manifests artefaktını indirir. Bu artefakt, deployment.yaml ve service.yaml dosyalarımızı içerir.
  • AzureCLI@2 - Create/Update imagePullSecret for ACR: Bu kritik adım, AKS'in özel kayıt defterinizden (ACR) Docker görüntüsünü çekebilmesi için gerekli olan imagePullSecrets'ı oluşturur veya günceller.
    • az acr show ve az acr credential show komutları ile ACR'nin giriş sunucusunu, yönetici kullanıcı adını ve şifresini alırız.
    • kubectl create secret docker-registry komutu, bu bilgileri kullanarak Kubernetes'te bir docker-registry tipinde secret oluşturur. --dry-run=client -o yaml | kubectl apply -f - yapısı, secret'ı önce YAML olarak oluşturup sonra kubectl apply ile uygulamamızı sağlar, bu da idempotency (tekrar çalıştırılabilir olma) sağlar. Eğer secret zaten varsa, güncellenir.
    • Bu secret, default namespace'inde oluşturulur. Eğer uygulamanız farklı bir namespace kullanıyorsa, --namespace değerini değiştirmeyi unutmayın.
  • KubernetesManifest@1 - Deploy to Kubernetes cluster: Bu, AKS'e dağıtım yapmanın ana görevidir.
    • action: deploy: Dağıtım eylemini belirtir.
    • kubernetesServiceConnection: '$(acrServiceConnection)': Önceki adımlarda oluşturduğumuz Azure Resource Manager servis bağlantısını kullanır. Bu bağlantı, Pipeline'ın AKS kümesine komutlar göndermesini sağlar.
    • namespace: 'default': Uygulamanın hangi Kubernetes namespace'ine dağıtılacağını belirtir.
    • manifests: Dağıtılacak Kubernetes manifest dosyalarının yollarını belirtir. Burada indirilen deployment.yaml ve service.yaml dosyalarını kullanıyoruz.
    • containers: | $(acrName).azurecr.io/$(imageRepository):$(tag): Bu kısım çok önemlidir. Kubernetes dağıtım manifestimizdeki image alanını dinamik olarak günceller. REPLACE_IMAGE_NAME:REPLACE_IMAGE_TAG placeholder'ını, CI aşamasında oluşturduğumuz ve ACR'ye gönderdiğimiz Docker görüntüsünün tam yolu ve etiketiyle değiştirir.
    • imagePullSecrets: '$(imagePullSecretName)': Dağıtım sırasında kullanılacak imagePullSecrets'ı belirtir, böylece AKS, ACR'den görüntüyü çekebilir.
    • rollOutRestart: true: (Yorum satırında) Dağıtım tamamlandıktan sonra pod'ların yeniden başlatılmasını sağlar. Yeni konfigürasyonların hemen uygulanması için faydalı olabilir.

Uzman İpucu: Daha karmaşık dağıtım senaryoları için Helm Charts kullanmayı düşünebilirsiniz. Helm, Kubernetes uygulamalarını yönetmek için bir paket yöneticisidir. Bir uygulamanın tüm Kubernetes kaynaklarını tek bir "Chart" içinde paketlemenizi ve kolayca dağıtmanızı, yükseltmenizi ve geri almanızı sağlar. Azure Pipelines, Helm görevlerini de destekler. Ayrıca, dağıtım stratejileri olarak Canary Dağıtımları (yeni sürümü küçük bir kullanıcı grubuna dağıtıp gözlemleme) veya Blue/Green Dağıtımları (eski ve yeni sürümü aynı anda çalıştırıp trafik yönlendirme) gibi daha gelişmiş yöntemleri keşfetmek, kesintisiz güncellemeler ve daha az riskli dağıtımlar için önemlidir. Bu stratejiler, KubernetesManifest@1 görevinin sunduğu strategy parametresi ile veya daha karmaşık senaryolarda bağımsız araçlarla (örneğin Istio, Linkerd) entegre edilerek uygulanabilir.

Bu azure-pipelines.yml dosyasını depomuza kaydettikten sonra, her kod değişikliğinde (veya manuel tetiklemeyle), uygulamamız otomatik olarak derlenecek, Docker görüntüsü oluşturulacak, ACR'ye gönderilecek ve ardından AKS kümemize dağıtılacaktır. Bu, modern DevOps'un gücünü sergileyen tam otomatik bir CI/CD akışıdır. Uygulamanızın yaşam döngüsü boyunca tutarlılık, hız ve güvenilirlik sağlar. Artık, dağıtım süreci otomatize edildiği için geliştiriciler, yeni özelliklere odaklanabilirken, operasyon ekipleri de daha az manuel müdahale ile ortamları yönetebilir.

AKS ve Azure Pipelines Entegrasyonunda İleri Düzey Uygulamalar Nelerdir?

Temel bir CI/CD akışını kurup uygulamamızı AKS'e dağıttık. Ancak Azure Kubernetes Service ve Azure Pipelines entegrasyonu, daha karmaşık ve güvenli senaryolar için birçok ileri düzey yetenek sunar. Bu bölümde, deneyimli kullanıcılar için uygulamaların yönetimini, güvenliğini ve izlenebilirliğini artıracak ipuçlarını ve püf noktalarını ele alacağız. Bu ileri düzey uygulamalar, büyük ölçekli ve kurumsal projelerde başarılı bir dağıtım stratejisi oluşturmanın anahtarıdır.

Helm Charts ile Dağıtım Yönetimi

Kubernetes manifest dosyaları, küçük uygulamalar için yeterli olabilirken, karmaşık mikroservis mimarileri ve farklı ortamlar için yönetimi zorlaşabilir. İşte burada Helm devreye girer. Helm, Kubernetes için bir paket yöneticisidir. Uygulamaların tüm Kubernetes kaynaklarını (Deployment, Service, Ingress, ConfigMap vb.) tek bir paket (Chart) içinde birleştirmenizi sağlar. Bu Chart'lar, değerleri (örneğin, görüntü etiketi, replika sayısı, ortam değişkenleri) parametreleştirmeye olanak tanır, böylece aynı Chart'ı farklı ortamlara (geliştirme, test, üretim) kolayca uyarlayabilirsiniz.

# azure-pipelines.yml içinde Helm ile dağıtım örneği
- task: HelmInstaller@1
  displayName: 'Install Helm'
  inputs:
    helmVersion: 'latest'

- task: HelmDeploy@0
  displayName: 'Deploy Helm Chart to AKS'
  inputs:
    command: 'upgrade'
    chartType: 'FilePath'
    chartPath: '$(Pipeline.Workspace)/helm_charts/mywebapp' # Helm Chart'ın yolu
    releaseName: 'mywebapp-release' # Helm sürümünün adı
    namespace: 'default'
    # Görüntü etiketini ve diğer değerleri override etme
    values: |
      image.tag=$(tag)
      image.repository=$(acrName).azurecr.io/$(imageRepository)
      replicaCount=3
    arguments: '--install --atomic' # Eğer yoksa kur, başarılı olmazsa rollback yap
    # Kubernetes servis bağlantısı zaten tanımlı olmalı
    # kubernetesServiceConnection: '$(acrServiceConnection)'

Helm, sürüm kontrolü, kolay geri alma (rollback) ve bağımlılık yönetimi gibi özellikler sunarak, Kubernetes dağıtımlarınızı çok daha yönetilebilir hale getirir. Azure Pipelines, HelmInstaller@1 ve HelmDeploy@0 gibi özel görevlerle Helm entegrasyonunu kolaylaştırır.

Ortam Bazlı Dağıtımlar (Geliştirme, Test, Üretim)

Gerçek dünya senaryolarında, uygulamaları doğrudan üretime dağıtmadan önce farklı ortamlarda test etmek istenir. Azure Pipelines, environments ve stages özellikleri ile bu senaryoyu kolayca yönetmenizi sağlar. Her ortam (Dev, Test, Prod) için ayrı bir stage tanımlayabilir, onay kapıları (approval gates) ekleyebilir ve belirli kullanıcıların veya grupların onayı olmadan bir dağıtımın bir sonraki ortama geçmesini engelleyebilirsiniz. Bu, dağıtım süreçlerinize ek bir güvenlik katmanı ekler.

# Farklı ortamlar için pipeline tanımı
stages:
- stage: Build
  # ... (Build stage kodları)

- stage: DeployToDev
  displayName: 'Deploy to Development'
  dependsOn: Build
  environment: 'Development' # Ortam tanımı
  jobs:
  - deployment: DeployDev
    # ... (Dev ortamına dağıtım adımları)

- stage: DeployToProd
  displayName: 'Deploy to Production'
  dependsOn: DeployToDev
  condition: succeeded('DeployToDev') # Dev başarılıysa çalıştır
  environment: 'Production'
  jobs:
  - deployment: DeployProd
    # ... (Prod ortamına dağıtım adımları)

Bu yapıda, Production ortamına dağıtımdan önce manuel bir onay adımı ekleyebilir, güvenlik taramaları çalıştırabilir veya performans testleri yapabilirsiniz.

Azure Key Vault Entegrasyonu ile Hassas Veri Yönetimi

Uygulamalar genellikle veritabanı bağlantı dizeleri, API anahtarları veya diğer hassas bilgileri saklamak zorundadır. Bu tür bilgileri doğrudan kodda veya Kubernetes manifestlerinde saklamak büyük bir güvenlik riskidir. Azure Key Vault, şifreleri, anahtarları ve sertifikaları güvenli bir şekilde depolamak ve bunlara erişimi kontrol etmek için kullanılan bulut tabanlı bir hizmettir. Azure Pipelines, Key Vault ile entegrasyonu kolaylaştırır.

# Azure Key Vault'tan secret çekme
variables:
  - group: MySecrets # Azure DevOps değişken gruplarına eklenen Key Vault group
# MySecrets group'u içinde "DbConnection" adında bir secret olduğu varsayılır.

steps:
- task: KubernetesManifest@1
  inputs:
    # ...
    # Aşağıdaki gibi, uygulama içindeki bir değişken olarak kullanabiliriz
    # veya Kubernetes secret'ı olarak deploy edebiliriz.
- script: echo "Database Connection String: $(DbConnection)"
  displayName: 'Display DB Connection (only for demo, avoid in prod)'

Key Vault'tan çekilen secret'ları Kubernetes secret'ları olarak AKS'e dağıtabilir veya Pod'lara ortam değişkenleri olarak enjekte edebilirsiniz. Bu, hassas verilerinizi güvende tutmanın ve merkezi olarak yönetmenin en iyi yoludur.

Monitoring ve Logging (Azure Monitor, Log Analytics)

Dağıtılan uygulamaların performansını ve sağlığını sürekli olarak izlemek, sorunları proaktif olarak tespit etmek ve çözmek için hayati öneme sahiptir. AKS, Azure Monitor ve Log Analytics ile derinlemesine entegrasyon sunar. AKS kümesi oluştururken --enable-addons monitoring parametresini kullanarak veya sonradan etkinleştirerek, konteynerlerinizden, pod'larınızdan ve düğümlerinizden metrikleri ve günlükleri otomatik olarak toplayabilirsiniz. Azure Pipelines, bu izleme verilerini kullanarak dağıtım sonrası sağlık kontrolleri yapabilir. Örneğin, yeni bir sürüm dağıtıldıktan sonra CPU veya bellek kullanımında ani bir artış olup olmadığını kontrol edebilir ve anormal bir durum varsa otomatik olarak geri alma (rollback) işlemini tetikleyebilir.

Güvenlik (RBAC, Azure Policy)

AKS'in güvenlik özellikleri, kurumsal düzeyde uygulamalar için vazgeçilmezdir. Azure Active Directory (AAD) tabanlı Role-Based Access Control (RBAC) entegrasyonu sayesinde, hangi kullanıcının veya servisin Kubernetes kümesinde hangi kaynaklara erişebileceğini detaylı bir şekilde kontrol edebilirsiniz. Azure Policy ise, AKS kümelerinizdeki güvenlik ve uyumluluk politikalarını zorunlu kılmanızı sağlar. Örneğin, sadece belirli bir kayıt defterinden görüntü çekilmesini veya sadece onaylanmış görüntülerin kullanılmasını zorunlu kılabilirsiniz. Azure Pipelines'ın servis bağlantıları da bu RBAC prensiplerine uygun olarak minimum ayrıcalık ilkesiyle yapılandırılmalıdır.

GitOps Yaklaşımları (Flux CD, Argo CD)

Gelişmiş senaryolarda, Kubernetes dağıtımlarını yönetmek için GitOps yaklaşımları popülerlik kazanmaktadır. GitOps, dağıtım state'ini (istenilen durumu) Git depolarında tutarak, değişikliklerin deklaratif ve versiyon kontrolü altında olmasını sağlar. Flux CD veya Argo CD gibi araçlar, Git deposundaki değişiklikleri sürekli olarak izler ve Kubernetes kümenizin durumunu bu depodaki tanıma eşitlemeye çalışır. Azure Pipelines, bu GitOps araçlarını tetikleyerek veya bunlarla entegre olarak, CI aşamasını yönetirken, CD'yi GitOps operatörlerine devredebilir. Bu, dağıtım süreçlerinin denetlenebilirliğini ve güvenilirliğini artırır.

Uzman İpucu: Mobil uyumlu HTML tasarımı, içeriğinizin farklı cihazlarda (telefon, tablet) düzgün görüntülenmesi için önemlidir. Bu makale saf HTML çıktısı verdiğinden, CSS media query örnekleri doğrudan dahil edilemez. Ancak, uygulamanızın web arayüzünü tasarlarken viewport meta etiketini kullanmak (), esnek bir grid sistemi uygulamak ve görselleri ölçeklenebilir hale getirmek (max-width: 100%; height: auto;) mobil uyumluluk için atılabilecek ilk adımlardır. CSS'te @media kurallarını kullanarak farklı ekran boyutlarına özel stiller tanımlayabilirsiniz (örn. @media (max-width: 768px) { ... }).

Bu ileri düzey uygulamalar, AKS ve Azure Pipelines entegrasyonunuzu daha olgun, güvenli ve verimli hale getirmenize yardımcı olacaktır. Her bir konu başlığı, kendi içinde derinlemesine bilgi gerektirse de, bu genel bakış, DevOps yolculuğunuzda bir sonraki adımları belirlemeniz için bir yol haritası sunar. Otomasyonu, güvenliği ve izlenebilirliği bir araya getirerek, modern bulut uygulamalarını başarılı bir şekilde yönetebilirsiniz.

Büyük Ölçekli Bir Şirketin Mikroservis Dağıtım Yolculuğu: Bir Vaka Analizi

Bir e-ticaret devinin, "GlobalMarket" adında, on yıldan uzun süredir monolitik bir yapı üzerinde çalışan ve pazarın hızla değişen taleplerine ayak uydurmakta zorlanan bir platformu olduğunu hayal edin. Yeni özelliklerin devreye alınması haftalar sürüyor, dağıtımlar genellikle kesintilere yol açıyor ve geliştirme ekipleri farklı modüller üzerinde birbirlerinin işini engelliyordu. GlobalMarket, bu sorunları çözmek ve rekabet avantajını geri kazanmak için platformunu mikroservis mimarisine taşımaya ve DevOps kültürünü benimsemeye karar verdi. Bu dönüşüm yolculuğunda Azure Kubernetes Service (AKS) ve Azure Pipelines kritik rol oynadı.

Mevcut Durum ve Zorluklar

GlobalMarket'in eski platformu, büyük bir Java uygulamasıydı ve tüm iş mantığı tek bir kod tabanında yer alıyordu. Bu monolitik yapı, aşağıdaki zorlukları beraberinde getiriyordu:

• Yavaş Dağıtımlar: Uygulamanın küçük bir bölümündeki bir değişiklik bile tüm uygulamanın yeniden derlenip dağıtılmasını gerektiriyordu, bu da haftalık dağıtım döngüleri anlamına geliyordu.
• Ölçeklenebilirlik Sorunları: Sadece belirli bir modül (örneğin sepet) yoğun talep görse bile, tüm uygulamanın ölçeklenmesi gerekiyordu, bu da kaynak israfına yol açıyordu.
• Geliştirici Verimliliği: Büyük kod tabanı, farklı ekiplerin eş zamanlı çalışmasını zorlaştırıyordu. Bir ekip bir modülde değişiklik yaparken, diğer ekiplerin işleri etkilenebiliyordu.
• Güvenilirlik ve Kurtarma: Tüm uygulama tek bir hata noktasında olduğu için, bir modüldeki hata tüm platformu çökertme potansiyeli taşıyordu. Geri alma (rollback) süreçleri karmaşıktı.

Dönüşüm Yolculuğu ve Çözümler

GlobalMarket, bu zorlukları aşmak için platformunu yaklaşık 50 farklı mikroservise ayırma kararı aldı. Her mikroservis, kendi iş alanına odaklanacak ve bağımsız olarak geliştirilip dağıtılabilecekti. Bu yeni mimari için bulut tabanlı bir konteyner orkestrasyon platformu ve güçlü bir CI/CD sistemi gerekiyordu.

1. AKS'e Geçiş: GlobalMarket, mikroservislerini çalıştırmak için Azure Kubernetes Service'i (AKS) seçti. AKS'in yönetilen hizmet yapısı sayesinde, GlobalMarket'in operasyon ekipleri Kubernetes ana düğümlerinin yönetimiyle uğraşmak yerine, uygulamaların dağıtımına ve sağlığına odaklanabildi. AKS'in otomatik ölçekleme yetenekleri, Kara Cuma gibi yoğun talep dönemlerinde platformun sorunsuz çalışmasını sağlarken, boş zamanlarda kaynakları optimize ederek maliyet tasarrufu sağladı.
2. Azure Pipelines ile CI/CD: Her mikroservis için ayrı bir Git deposu oluşturuldu ve her depo için Azure Pipelines'da YAML tabanlı CI/CD pipeline'ları tanımlandı. Bu pipeline'lar, her kod değişikliğinde aşağıdaki adımları otomatik olarak gerçekleştiriyordu:
   • Derleme ve Test: Mikroservisin kodu derleniyor, birim ve entegrasyon testleri çalıştırılıyordu.
   • Docker Görüntüsü Oluşturma: Başarılı testlerin ardından, mikroservisin bir Docker görüntüsü oluşturuluyordu. Çok aşamalı derlemeler kullanılarak görüntü boyutları minimize ediliyordu.
   • ACR'ye Gönderme: Oluşturulan Docker görüntüsü, Azure Container Registry (ACR) üzerine gönderiliyordu. ACR'nin entegre güvenlik taramaları, görüntülerde bilinen güvenlik açıklarını tespit etmeye yardımcı oluyordu.
   • Helm ile Dağıtım: Her mikroservis için bir Helm Chart oluşturulmuştu. Azure Pipelines, ACR'deki yeni görüntüyü kullanarak Helm Chart'ı AKS'e dağıtıyordu. Helm'in parametreleştirme özelliği sayesinde, aynı Chart geliştirme, test ve üretim ortamlarına kolayca uyarlanabiliyordu.
3. Ortam Bazlı Dağıtım ve Onay Kapıları: GlobalMarket, dağıtım sürecini Geliştirme, Test, Hazırlık (Staging) ve Üretim (Production) olmak üzere dört aşamalı bir yaklaşımla tasarladı. Her ortam arasında otomatik testler ve manuel onay kapıları eklenerek, uygulamanın kalitesi ve güvenliği garanti altına alındı. Örneğin, Hazırlık ortamına dağıtımdan sonra otomatik performans testleri çalıştırılıyor, Üretim ortamına geçiş ise Operasyon Ekibi Lideri'nin onayıyla gerçekleşiyordu.
4. Azure Key Vault Entegrasyonu: Veritabanı bağlantı dizeleri, API anahtarları gibi hassas bilgiler Azure Key Vault'ta saklanıyordu. Azure Pipelines, bu secret'ları güvenli bir şekilde çekip Kubernetes Secret'ları olarak AKS'e dağıtıyordu, böylece hassas veriler asla kod depolarında yer almıyordu.
5. İzleme ve Gözlemlenebilirlik: AKS kümeleri ve mikroservisler, Azure Monitor ve Log Analytics ile entegre edildi. Bu sayede, performans metrikleri, günlükler ve hatalar merkezi olarak toplanıp analiz edilebiliyordu. Operasyon ekipleri, Prometheus ve Grafana gibi araçlarla bu verileri görselleştirerek, olası sorunları proaktif olarak tespit edebiliyordu.

Elde Edilen Kazanımlar

Bu dönüşümün ardından GlobalMarket, önemli kazanımlar elde etti:

• Hızlanan Dağıtımlar: Yeni özelliklerin pazara sunulma süresi haftalardan saatlere indi. Geliştiriciler, bağımsız olarak özellikler üzerinde çalışıp, kodlarını birkaç saat içinde üretime dağıtabiliyorlardı.
• Artan Güvenilirlik: Mikroservislerin izole yapısı ve otomatik geri alma yetenekleri sayesinde, bir servisteki hata tüm platformu etkilemiyordu. Hata oranları önemli ölçüde azaldı.
• Kaynak Verimliliği: AKS'in otomatik ölçekleme özelliği sayesinde, sadece ihtiyaç duyulan mikroservisler ölçeklenerek, bulut maliyetlerinde belirgin bir azalma sağlandı.
• Geliştirici Otonomisi ve Verimliliği: Ekipler, kendi mikroservisleri üzerinde tam otonomiye sahip oldu, bu da yenilikçiliği teşvik etti ve geliştirici verimliliğini artırdı.

GlobalMarket'in vaka analizi, AKS ve Azure Pipelines entegrasyonunun, büyük ve karmaşık sistemlerin modernizasyonunda nasıl bir katalizör görevi görebileceğini açıkça ortaya koymaktadır. Bu entegrasyon, yalnızca teknik bir iyileştirme değil, aynı zamanda iş süreçlerini ve şirket kültürünü de dönüştüren kapsamlı bir DevOps yolculuğunun temelini oluşturmuştur.

Azure Pipelines ile AKS Dağıtımının Geleceği ve Sıkça Sorulan Sorular

Azure Kubernetes Service (AKS) ve Azure Pipelines entegrasyonu, modern bulut yerel uygulama dağıtımı için güçlü, esnek ve ölçeklenebilir bir çözüm sunmaktadır. Bu makale boyunca, temel kavramlardan ileri düzey uygulamalara kadar bu entegrasyonun nasıl kurulacağını ve yönetileceğini adım adım inceledik. Gördük ki, kod değişikliklerinin otomatik olarak derlenmesinden, Docker görüntülerinin oluşturulmasına, Azure Container Registry'ye (ACR) gönderilmesinden, son olarak AKS'e güvenli ve otomatik bir şekilde dağıtılmasına kadar tüm süreçler Azure Pipelines ile sorunsuz bir şekilde otomatize edilebilmektedir.

Bu otomasyon, geliştirme ekiplerinin üretkenliğini artırır, insan hatasını minimize eder, dağıtım hızını önemli ölçüde artırır ve yazılımın pazara sunulma süresini (Time-to-Market) kısaltır. AKS'in yönetilen hizmet yapısı, operasyonel yükü Azure'a devrederek ekiplerin daha çok iş değeri katmaya odaklanmasını sağlar. Ayrıca, Helm gibi araçlarla entegrasyon, ortam bazlı dağıtımlar, Azure Key Vault ile hassas veri yönetimi ve kapsamlı izleme yetenekleri, kurumsal düzeyde uygulama yaşam döngüsü yönetimini daha da güçlendirir.

Gelecekte, bulut yerel teknolojiler ve DevOps pratikleri daha da yaygınlaşacak, otomasyonun kapsamı artacak ve yapay zeka/makine öğrenimi destekli operasyonlar (AIOps) ile süreçler daha akıllı hale gelecektir. Azure Pipelines ve AKS gibi platformlar, bu evrimin ön saflarında yer almaya devam edecektir. Sürekli iyileştirme, güvenlik ve ölçeklenebilirlik, her zaman öncelikli olmaya devam edecek ve bu araçlar, işletmelerin bu hedeflere ulaşmasına yardımcı olacaktır.

Bu güçlü entegrasyonu benimsemek, sadece teknik bir tercih değil, aynı zamanda çevikliği, güvenilirliği ve rekabet gücünü artıran stratejik bir yatırımdır. Artık uygulamalarınızı Azure Kubernetes Service'e Azure Pipelines ile dağıtmak için gereken bilgiye ve kaynaklara sahipsiniz. Bu yolculukta başarılar dileriz!

Sıkça Sorulan Sorular

1. Azure Pipelines ile AKS'e dağıtım yaparken güvenlik için nelere dikkat etmeliyim?

Cevap: Güvenlik, CI/CD sürecinin her aşamasında öncelikli olmalıdır. Dikkat etmeniz gereken başlıca noktalar şunlardır:

• Servis Bağlantıları: Azure DevOps'taki servis bağlantılarınıza en az ayrıcalık ilkesiyle izinler verin. Yalnızca gerekli kaynaklara (AKS, ACR) erişim sağlayın.
• Azure Key Vault: Hassas verileri (veritabanı şifreleri, API anahtarları vb.) doğrudan manifestlerde veya pipeline değişkenlerinde saklamak yerine Azure Key Vault'ta yönetin ve pipeline'lar aracılığıyla güvenli bir şekilde çekin.
• Docker Görüntüsü Güvenliği: Azure Container Registry'nin güvenlik taramalarını (Defender for Cloud) etkinleştirin veya pipeline'a üçüncü taraf güvenlik tarayıcıları entegre edin. Yalnızca güvenilir taban görüntüler kullanın.
• Kubernetes RBAC: AKS'te kullanıcı ve servis hesaplarına en az ayrıcalık ilkesine göre Role-Based Access Control (RBAC) rolleri atayın.
• Ağ Güvenliği: AKS kümeleriniz için Azure Sanal Ağları (VNet) kullanarak ağ segmentasyonu ve güvenlik gruplarıyla erişim kontrolü sağlayın.

2. Azure Pipelines'ta dağıtım sonrası geri alma (rollback) nasıl yapılır?

Cevap: Kubernetes'in yerleşik Deployment kaynakları, geri alma yeteneklerine sahiptir. Azure Pipelines'ta bir dağıtım başarısız olduğunda veya yeni sürümde sorunlar tespit edildiğinde, genellikle iki yöntemle geri alma yapabilirsiniz:

• kubectl rollout undo: Bu komut, önceki başarılı sürüme geri dönmenizi sağlar. Azure Pipelines'ta Kubernetes@1 görevini kullanarak veya bir AzureCLI@2 görevi içinde kubectl rollout undo deployment/mywebapp-deployment komutunu çalıştırarak geri alma işlemi tetiklenebilir.
• Pipeline Geri Alma: Azure DevOps'ta, önceki başarılı bir derlemenin dağıtımını yeniden çalıştırarak da geri alma yapabilirsiniz. Bu, pipeline geçmişinden belirli bir derlemeyi seçip "Redeploy" (Yeniden Dağıt) işlevini kullanarak eski görüntüyü ve manifestleri tekrar AKS'e dağıtmanızı sağlar.

3. Farklı ortamlara (Dev, Test, Prod) nasıl dağıtım yapabilirim?

Cevap: Azure Pipelines, farklı ortamlara dağıtımı yönetmek için güçlü özellikler sunar:

• Aşamalar (Stages): Pipeline'ınızı Build, DeployToDev, DeployToTest, DeployToProd gibi ayrı aşamalara ayırın. Her aşama, belirli bir ortama dağıtımdan sorumlu olabilir.
• Ortamlar (Environments): Azure DevOps'ta "Environments" özelliğini kullanarak her dağıtım ortamını tanımlayın. Bu ortamlar üzerinde onay kapıları (approval gates) ve kaynak kontrolleri tanımlayarak dağıtım süreçlerinizi daha güvenli hale getirebilirsiniz.
• Değişkenler: Ortam bazlı farklılıkları (veritabanı bağlantı dizeleri, API URL'leri vb.) yönetmek için pipeline değişkenlerini veya değişken gruplarını kullanın. Helm Charts kullanıyorsanız, values.yaml dosyalarını ortama özel olarak yapılandırabilirsiniz.
• Koşullu Yürütme: Her aşamanın, bir önceki aşamanın başarısına veya belirli bir dalda (branch) yapılan değişikliklere bağlı olarak çalışmasını sağlayabilirsiniz (condition ifadesi ile).

4. Azure Pipelines ile AKS'e dağıtım yaparken maliyetleri nasıl optimize edebilirim?

Cevap: Maliyet optimizasyonu için birkaç yaklaşım mevcuttur:

• AKS Otomatik Ölçekleme: AKS'in yerleşik otomatik ölçekleme özelliklerini (Horizontal Pod Autoscaler ve Cluster Autoscaler) kullanarak kaynakları talebe göre dinamik olarak artırıp azaltın.
• Doğru Boyutlandırma: Konteynerleriniz için CPU ve bellek kaynak isteklerini (requests) ve limitlerini (limits) doğru bir şekilde belirleyin. Gereksiz yere fazla kaynak ayırmaktan kaçının.
• Kullanılmayan Kaynakları Kapatma: Geliştirme ve test ortamlarınızdaki AKS kümelerini çalışma saatleri dışında kapatmayı veya ölçeğini küçültmeyi düşünebilirsiniz.
• Verimli Docker Görüntüleri: Çok aşamalı derlemeler ve .dockerignore kullanarak Docker görüntülerinizin boyutunu küçültün. Bu, kayıt defteri depolama maliyetlerini ve ağ trafiğini azaltır.
• Spot Örnekler: AKS'te kesintiye dayanıklı iş yükleri için daha uygun fiyatlı spot sanal makine örneklerini kullanmayı düşünebilirsiniz.

5. Azure Pipelines, Kubernetes manifest dosyalarındaki görüntü etiketlerini otomatik olarak nasıl günceller?

Cevap: Azure Pipelines'taki KubernetesManifest@1 görevi, containers girdisi aracılığıyla bu işlemi otomatik olarak gerçekleştirir. Dağıtım görevine containers parametresiyle doğru görüntü adını ve etiketini sağladığınızda (örneğin, myACRRegistry.azurecr.io/mywebapp:$(tag)), görev, deployment.yaml dosyanızdaki image alanını dinamik olarak bu yeni değerle günceller. Bu sayede, manifest dosyasını manuel olarak değiştirmeye gerek kalmaz ve CI/CD süreci tamamen otomatize edilmiş olur. Ayrıca Helm Charts kullanıyorsanız, values parametresiyle görüntü etiketini ve kayıt defteri bilgilerini kolayca geçersiz kılabilirsiniz.