“`html
Kubernetes’te Uygulama Yönetimi: Helm ile Tanışın
Kubernetes ekosisteminde uygulamalarınızı paketlemek, dağıtmak ve yönetmek karmaşık bir süreç olabilir. Peki ya tüm bu süreci basitleştirecek, tekrarlayan görevleri otomatikleştirecek ve dağıtım süreçlerinizi standartlaştıracak bir aracınız olsa? İşte bu noktada Helm devreye giriyor. Bu makalede, Kubernetes’te uygulama yönetimi konusunu en temelden başlayarak, adım adım Helm’in gücünü keşfedeceğiz. Uygulamalarınızı nasıl daha verimli yönetebileceğinizi, tekrarlayan komutlardan kurtulup daha stratejik konulara odaklanabileceğinizi öğreneceksiniz. Özellikle CI/CD (Sürekli Entegrasyon/Sürekli Dağıtım) pipeline’larınızda Helm’in nasıl bir oyun değiştirici olabileceğine dair ipuçları bulacaksınız.
Helm Nedir ve Neden Kullanmalıyız?
Günümüzde mikroservis mimarileri ve konteyner teknolojileri hızla yaygınlaşıyor. Bu durum, uygulamaların daha modüler ve bağımsız hale gelmesini sağlarken, aynı zamanda dağıtım ve yönetim süreçlerini de bir o kadar karmaşıklaştırıyor. İşte bu noktada Kubernetes gibi orkestrasyon araçları devreye giriyor. Kubernetes, konteynerize edilmiş uygulamalarınızın dağıtımını, ölçeklendirilmesini ve yönetimini otomatikleştirmemize olanak tanıyor. Ancak, Kubernetes’in kendi başına sunduğu manifest dosyaları (YAML formatında tanımlanan kaynaklar), özellikle karmaşık uygulamalar için yönetimi zor ve tekrarlayan bir hale getirebiliyor. Bir uygulamanın birden fazla servisi, veritabanı, yapılandırma dosyası ve güvenlik ayarı olabilir. Bunların her birini ayrı ayrı tanımlamak ve güncellemeleri yönetmek zaman alıcı ve hataya açık bir süreçtir.
İşte tam da bu sorunlara çözüm sunmak için Helm ortaya çıkıyor. Helm, Kubernetes için bir paket yöneticisidir. Tıpkı Linux’taki APT veya Red Hat’teki YUM gibi, Helm de Kubernetes uygulamaları için paketleme, dağıtım ve yaşam döngüsü yönetimi sağlar. Helm ile uygulamalarınızı “Chart” adı verilen paketler halinde tanımlayabilirsiniz. Bu Chart’lar, uygulamanızın çalışması için gereken tüm Kubernetes kaynaklarını (Deployment, Service, ConfigMap, Secret, PersistentVolume vb.) içeren şablonlardır. Helm’in en büyük avantajlarından biri, bu şablonları parametrelendirebilmesidir. Yani, aynı Chart’ı farklı ortamlar (geliştirme, test, üretim) için farklı yapılandırmalarla kolayca dağıtabilirsiniz. Örneğin, bir veritabanı bağlantı dizesini veya bir servis portunu Chart’ı dağıtırken belirleyebilirsiniz. Bu, kod tekrarını önler ve yapılandırma yönetimini büyük ölçüde basitleştirir.
Helm kullanmanın temel nedenleri şunlardır:
- Paketleme ve Yeniden Kullanılabilirlik: Uygulamalarınızı ve bağımlılıklarını tek bir birimde paketleyerek farklı ortamlarda kolayca yeniden kullanabilirsiniz.
- Parametrelendirme: Chart’larınızı farklı ortamlar için özelleştirebilirsiniz. Bu, aynı uygulamanın farklı yapılandırmalarla dağıtılmasını sağlar.
- Versiyonlama ve Geri Alma: Helm, dağıtımlarınızı versiyonlar halinde yönetir. Bir hata durumunda önceki sürüme kolayca geri dönebilirsiniz.
- Bağımlılık Yönetimi: Bir uygulamanın başka bir uygulamaya bağımlılığı varsa, Helm bu bağımlılıkları otomatik olarak yönetebilir.
- Standartlaştırma: Uygulama dağıtım süreçlerinizi standartlaştırarak ekip içinde tutarlılık sağlar ve yeni ekip üyelerinin sürece daha hızlı adapte olmasına yardımcı olur.
- Community Charts: Helm Hub gibi platformlarda yüzlerce hazır Chart bulunmaktadır. Popüler veritabanları, mesaj kuyrukları ve diğer altyapı bileşenlerini kolayca Kubernetes’e dağıtabilirsiniz.
Kısacası, Helm, Kubernetes üzerinde uygulama yönetimi yükünü önemli ölçüde azaltarak geliştiricilerin ve operasyon ekiplerinin daha verimli çalışmasını sağlar. Tekrarlayan ve sıkıcı görevleri otomatikleştiren Helm, sizlerin daha stratejik ve yenilikçi projelere odaklanmasına olanak tanır.
Helm Chart’ları Nasıl Çalışır?
Helm Chart’ları, Kubernetes uygulamalarınızın dağıtımı için gerekli tüm bilgileri içeren standartlaştırılmış bir dizin yapısına sahip paketlerdir. Bir Chart, uygulamanızın hangi Kubernetes kaynaklarına ihtiyaç duyduğunu tanımlayan şablonlar (templates) ve bu şablonları özelleştirmek için kullanılan değerler (values) gibi temel bileşenlerden oluşur. Bu yapıyı daha iyi anlamak için, bir Helm Chart’ının temel dizin yapısını inceleyelim:
chart-adı/
├── Chart.yaml # Chart'ın meta verileri (adı, sürümü, açıklaması vb.)
├── values.yaml # Varsayılan yapılandırma değerleri
├── charts/ # Alt-Chart'lar (bağımlılıklar)
└── templates/ # Kubernetes manifest şablonları
├── deployment.yaml
├── service.yaml
├── ingress.yaml
└── _helpers.tpl # Yardımcı şablonlar (isteğe bağlı)
Şimdi bu bileşenlere daha yakından bakalım:
Chart.yaml: Chart'ın Kimlik Kartı
Chart.yaml dosyası, Helm Chart'ınızın temel meta verilerini içerir. Bu dosya, Chart'ın adı, sürümü, açıklaması, geliştiricisi ve hangi Kubernetes sürümleriyle uyumlu olduğu gibi bilgileri barındırır. Bu bilgiler, Helm'in Chart'ı tanıması ve yönetmesi için kritik öneme sahiptir. Örneğin, bir Chart'ın sürümünü belirterek, belirli bir versiyonu kurabilir veya güncelleyebilirsiniz.
values.yaml: Yapılandırmanın Kalbi
values.yaml dosyası, Chart'ınızın varsayılan yapılandırma değerlerini tanımlar. Bu dosya, uygulamanızın farklı ortamlarda nasıl davranacağını belirleyen anahtar-değer çiftlerini içerir. Örneğin, bir web uygulamasının kaç replikaya sahip olacağını, hangi portu dinleyeceğini, veritabanı bağlantı bilgilerini veya harici servislerin adreslerini burada tanımlayabilirsiniz. Bu değerler, Chart'ı kurarken veya güncellerken üzerine yazılarak (override edilerek) özelleştirilebilir. Bu, Helm'in esnekliğinin temelini oluşturur.
templates/ Dizin: Kubernetes Manifest Şablonları
templates/ dizini, uygulamanızın çalışması için gereken tüm Kubernetes manifest dosyalarını (Deployment, Service, ConfigMap, Secret, Ingress vb.) barındırır. Ancak bu dosyalar, standart YAML dosyaları değil, Go template motoru kullanılarak oluşturulmuş şablonlardır. Bu şablonlar, values.yaml dosyasındaki değişkenleri kullanarak dinamik olarak oluşturulur. Örneğin, bir Deployment şablonunda, replika sayısını {{ .Values.replicaCount }} gibi bir ifadeyle belirleyebilirsiniz. Helm, bu şablonları values.yaml dosyasındaki değerlerle doldurarak gerçek Kubernetes manifestlerini oluşturur ve Kubernetes API'sine gönderir.
_helpers.tpl: Tekrarı Önleyen Yardımcılar
_helpers.tpl dosyası, sık kullanılan şablon parçacıklarını tanımlamak için kullanılır. Bu, özellikle karmaşık Chart'larda kod tekrarını önlemeye yardımcı olur. Örneğin, bir servis adı veya etiket (label) gibi tekrar eden tanımlamaları bir helper fonksiyonu içinde tanımlayabilir ve farklı şablonlarda bu fonksiyonu çağırabilirsiniz. Bu, Chart'ın okunabilirliğini ve bakımını kolaylaştırır.
charts/ Dizin: Bağımlılık Yönetimi
charts/ dizini, ana Chart'ınızın bağımlı olduğu diğer Chart'ları içerir. Bu, karmaşık uygulamaların, örneğin bir web uygulaması ile birlikte gelen bir veritabanı veya mesaj kuyruğu gibi bağımlılıklarını yönetmek için kullanılır. Helm, bir ana Chart'ı kurduğunda, charts/ dizinindeki tüm alt-Chart'ları da otomatik olarak kurar. Bu özellik, uygulamalarınızın tüm bileşenlerinin birlikte tutarlı bir şekilde dağıtılmasını sağlar.
Bu yapı sayesinde Helm, Kubernetes'te uygulamaları yönetmek için güçlü ve esnek bir çerçeve sunar. Tekrarlayan YAML dosyaları yazmak yerine, uygulamanızın mantığını ve yapılandırmasını odaklanabilirsiniz.
İlk Helm Chart'ınızı Oluşturma: Adım Adım Rehber
Şimdiye kadar Helm'in ne olduğunu ve nasıl çalıştığını teorik olarak anladık. Şimdi sıra geldi kendi ilk Helm Chart'ımızı oluşturmaya. Bu süreç oldukça basittir ve birkaç temel komutla tamamlanabilir. Bu adım adım rehber, size yol gösterecektir.
1. Helm Kurulumu
Öncelikle bilgisayarınızda Helm'in kurulu olması gerekiyor. Eğer kurulu değilse, resmi Helm belgelerinden işletim sisteminize uygun kurulum talimatlarını takip edebilirsiniz. Genellikle tek bir komutla veya bir paket yöneticisi aracılığıyla kolayca kurulabilir.
2. Yeni Bir Chart Oluşturma
Yeni bir Helm Chart oluşturmak için helm create komutunu kullanırız. Bu komut, yukarıda bahsettiğimiz standart dizin yapısına sahip boş bir Chart iskeleti oluşturur. Terminalinizi açın ve şu komutu çalıştırın:
helm create my-first-chartBu komut, my-first-app adında yeni bir dizin oluşturacak ve içine standart Helm Chart yapısını yerleştirecektir. Bu dizine girdiğinizde, Chart.yaml, values.yaml ve templates/ gibi dosyaları göreceksiniz.
3. Chart'ı Anlama ve Düzenleme
Şimdi my-first-chart dizininin içine girerek dosyaları inceleyelim:
Chart.yaml Dosyasını Düzenleme
Chart.yaml dosyasını bir metin editörüyle açın. Varsayılan olarak şuna benzer bir içeriği olacaktır:
apiVersion: v2
name: my-first-chart
description: A Helm chart for Kubernetes
type: application
version: 0.1.0
appVersion: "1.16.0"
Burada name, description ve version alanlarını kendi projenize uygun şekilde güncelleyebilirsiniz. appVersion ise uygulamanızın kendi sürümünü belirtir.
values.yaml Dosyasını Düzenleme
values.yaml dosyası, Chart'ınızın yapılandırma değerlerini içerir. Varsayılan olarak, bu dosya bir Nginx web sunucusunu dağıtacak şekilde yapılandırılmıştır. İçeriği inceleyerek veya kendi uygulamanıza göre düzenleyerek, örneğin replika sayısını, imaj adını veya port numaralarını değiştirebilirsiniz:
replicaCount: 1
image:
repository: nginx
pullPolicy: IfNotPresent
tag: ""
imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""
serviceAccount:
create: true
annotations: {}
name: ""
podAnnotations: {}
podLabels: {}
podSecurityContext: {}
securityContext: {}
service:
type: ClusterIP
port: 80
ingress:
enabled: false
className: ""
annotations: {}
hosts:
- host: chart-example.local
paths:
- path: /
pathType: ImplementationSpecific
tls: []
resources: {}
nodeSelector: {}
tolerations: []
affinity: {}
Örneğin, replika sayısını 3 yapmak isterseniz, replicaCount: 1 satırını replicaCount: 3 olarak değiştirebilirsiniz. Ya da uygulamanızın kullanacağı Docker imajını belirtmek isterseniz, image.repository ve image.tag alanlarını güncelleyebilirsiniz.
templates/ Dizinindeki Şablonları İnceleme
templates/ dizinine girin. Burada deployment.yaml, service.yaml gibi dosyalar göreceksiniz. Bu dosyalar, Go template syntax'ı ile yazılmış Kubernetes manifest şablonlarıdır. Örneğin, deployment.yaml dosyasında replika sayısını belirten satırı inceleyebilirsiniz:
replicas: {{ .Values.replicaCount }}
Bu satır, values.yaml dosyasındaki replicaCount değerini alarak Deployment nesnesinin replika sayısını belirler.
4. Chart'ı Yerel Olarak Test Etme
Chart'ınızı oluşturduktan sonra, onu gerçek bir Kubernetes kümesine dağıtmadan önce yerel olarak test etmek iyi bir fikirdir. Bunun için helm template komutunu kullanabilirsiniz. Bu komut, Chart'ınızın values.yaml dosyasındaki değerlerle oluşturacağı nihai Kubernetes manifestlerini çıktılar:
helm template .
Bu komutun çıktısını inceleyerek, oluşturulan manifestlerde herhangi bir hata olup olmadığını kontrol edebilirsiniz. Ayrıca, helm lint komutu ile Chart'ınızın yapısını ve olası sorunları kontrol edebilirsiniz:
helm lint .
5. Chart'ı Kubernetes Kümesine Dağıtma
Her şey yolunda görünüyorsa, artık Chart'ınızı Kubernetes kümenize dağıtabilirsiniz. Bunun için helm install komutunu kullanırız:
helm install my-release ./my-first-chart
Burada my-release, bu dağıtım için vereceğiniz benzersiz isimdir. ./my-first-chart ise oluşturduğunuz Chart'ın yoludur. Bu komut, Chart'ı indirip Kubernetes'e uygulayacaktır.
6. Dağıtımı Güncelleme ve Kaldırma
Uygulamanızda bir değişiklik yaptığınızda, Chart'ı güncelleyebilirsiniz. Örneğin, replika sayısını değiştirdiyseniz, values.yaml dosyasını güncelleyip şu komutu çalıştırın:
helm upgrade my-release ./my-first-chart
Dağıtımı kaldırmak için ise helm uninstall komutunu kullanabilirsiniz:
helm uninstall my-release
Bu adımları takip ederek, kendi ilk Helm Chart'ınızı başarıyla oluşturabilir ve Kubernetes kümenize dağıtabilirsiniz. Bu, daha karmaşık uygulamalar için temel oluşturacaktır.
Gerçek Dünya Senaryosu: Bir Web Uygulamasını Helm ile Dağıtma
Şimdiye kadar temel bir Helm Chart oluşturmayı öğrendik. Ancak gerçek dünya senaryolarında uygulamalarımız genellikle daha karmaşıktır ve birden fazla bileşeni içerebilir. Bu bölümde, popüler bir web uygulamasını (örneğin, bir blog veya e-ticaret sitesi) Helm ile nasıl paketleyip dağıtabileceğimizi inceleyeceğiz. Bu senaryo, Helm'in bağımlılık yönetimi, yapılandırma esnekliği ve versiyonlama gibi özelliklerinin nasıl kullanıldığını gösterecektir.
Senaryo: Basit Bir Web Uygulaması ve Veritabanı
Diyelim ki, bir Node.js tabanlı basit bir web uygulamamız var ve bu uygulama çalışmak için bir PostgreSQL veritabanına ihtiyaç duyuyor. Geleneksel yöntemlerle bu iki bileşeni Kubernetes'e dağıtmak, ayrı ayrı Deployment, Service ve PersistentVolume tanımlamaları gerektirecektir. Ancak Helm ile bu süreci çok daha entegre hale getirebiliriz.
1. Ana Chart ve Bağımlılık Chart'ları
Bu senaryoda, ana Helm Chart'ımız web uygulamamız için olacaktır. PostgreSQL veritabanı için ise Helm Hub'dan hazır bir PostgreSQL Chart'ı kullanacağız. Bu, Helm'in bağımlılık yönetiminin gücünü gösterir.
Öncelikle, web uygulamamız için bir ana Chart oluşturalım:
helm create my-webapp
Ardından, my-webapp dizininin içine girip Chart.yaml dosyasını düzenleyelim. Buraya, PostgreSQL Chart'ına olan bağımlılığımızı ekleyeceğiz. Bunun için dependencies bölümünü kullanırız:
apiVersion: v2
name: my-webapp
description: A Helm chart for my web application
type: application
version: 0.1.0
appVersion: "1.0.0"
dependencies:
- name: postgresql
version: "10.x.x" # PostgreSQL Chart'ının uygun sürümünü belirtin
repository: "https://charts.bitnami.com/bitnami"
alias: db # Bu bağımlılığa bir takma ad veriyoruz
Burada name, bağımlı Chart'ın adını; version, kullanmak istediğimiz sürüm aralığını; repository, Chart'ın bulunduğu Helm deposunu belirtir. alias: db ise bu PostgreSQL bağımlılığına "db" adını verir. Bu takma ad, ana Chart'ımızın values.yaml dosyasında bu bağımlılığı yapılandırmak için kullanılacaktır.
2. Bağımlılıkları Çekme
Bağımlılıkları ekledikten sonra, helm dependency update komutu ile bu bağımlılıkları indirebiliriz:
helm dependency update ./my-webapp
Bu komut, my-webapp/charts/ dizinine PostgreSQL Chart'ını indirecektir.
3. Ana Chart'ın Yapılandırması (values.yaml)
Şimdi, ana Chart'ımızın values.yaml dosyasını düzenleyerek web uygulamamızın ve PostgreSQL veritabanının yapılandırmasını yapacağız:
# Web Uygulaması Yapılandırması
replicaCount: 3
image:
repository: my-docker-repo/my-web-app
tag: "latest"
pullPolicy: IfNotPresent
service:
type: ClusterIP
port: 8080
# PostgreSQL Veritabanı Yapılandırması (Alias: db kullanıldı)
db:
enabled: true # PostgreSQL'i kurmak istediğimizi belirtiyoruz
replicaCount: 1
postgresqlDatabase: myappdb
postgresqlUsername: appuser
postgresqlPassword: mysecurepassword # Gerçek şifreyi burada saklamayın! Secret kullanın.
persistence:
enabled: true
size: 10Gi
Dikkat ederseniz, PostgreSQL ile ilgili yapılandırma parametreleri, db alias'ı altında gruplanmıştır. Bu, Helm'in bağımlılıkların yapılandırmasını ana Chart'tan yönetmesini sağlar. db.enabled: true, PostgreSQL Chart'ının kurulacağını belirtir. postgresqlPassword gibi hassas bilgilerin gerçek bir üretim ortamında doğrudan buraya yazılmaması gerektiğini unutmayın. Bunun yerine Kubernetes Secrets veya Helm Secrets eklentileri kullanılmalıdır.
4. Şablonları Güncelleme (templates/)
Ana Chart'ımızın templates/ dizinindeki dosyaları da web uygulamamızın gereksinimlerine göre düzenlememiz gerekebilir. Örneğin, deployment.yaml dosyasında doğru Docker imajını ve portu belirttiğimizden emin olmalıyız. Ayrıca, web uygulamamızın PostgreSQL'e bağlanması için gerekli ortam değişkenlerini (environment variables) Deployment şablonuna eklemeliyiz:
# templates/deployment.yaml içinde ilgili container tanımına ekleyin:
env:
- name: DATABASE_URL
value: "postgresql://{{ .Values.db.postgresqlUsername }}:{{ .Values.db.postgresqlPassword }}@{{ include "my-webapp.postgresqlServiceUrl" . }}:5432/{{ .Values.db.postgresqlDatabase }}"
- name: NODE_ENV
value: "production"
Burada {{ include "my-webapp.postgresqlServiceUrl" . }} gibi ifadeler, bağımlı PostgreSQL Chart'ının otomatik olarak oluşturduğu servis adını çekmek için kullanılır. Bu tür helper fonksiyonları, bağımlılıklarla entegrasyonu kolaylaştırır.
5. Dağıtım ve Yönetim
Artık ana Chart'ımızı dağıtabiliriz:
helm install my-app-release ./my-webapp
Helm, hem web uygulaması Deployment'ını hem de PostgreSQL veritabanını içeren gerekli tüm kaynakları oluşturacaktır. Uygulama çalışmaya başladığında, ortam değişkenleri aracılığıyla PostgreSQL'e bağlanabilecektir.
6. Versiyonlama ve Geri Alma
Birkaç hafta sonra web uygulamanızın yeni bir sürümünü yayınlamak istediğinizde, my-webapp/Chart.yaml dosyasındaki appVersion'ı güncelleyip helm upgrade komutunu çalıştırabilirsiniz. Eğer yeni sürümde bir sorun olursa, helm history my-app-release ile önceki sürümleri görebilir ve helm rollback my-app-release komutu ile kolayca geri dönebilirsiniz.
Bu senaryo, Helm'in sadece tek bir uygulama paketlemekle kalmayıp, birden fazla bağımlılığı olan karmaşık sistemleri yönetmek için de ne kadar güçlü bir araç olduğunu göstermektedir. Tekrarlayan kurulum ve yapılandırma süreçlerini otomatikleştiren Helm, geliştirme ve operasyon ekiplerinin verimliliğini önemli ölçüde artırır.
İleri Düzey Helm Kullanımı: Özel Fonksiyonlar ve Hook'lar
Helm'in sunduğu temel özelliklerin yanı sıra, daha karmaşık ve özelleştirilmiş senaryolar için ileri düzey yetenekleri de bulunmaktadır. Bu bölümde, özel fonksiyonlar oluşturmayı ve Helm Hook'larını kullanarak dağıtım süreçlerinizi daha da otomatikleştirmeyi öğreneceğiz.
Özel Fonksiyonlar (Helpers) Oluşturma
Daha önce bahsettiğimiz _helpers.tpl dosyası, sık kullanılan şablon parçacıklarını tanımlamak için kullanılır. Bu, tekrarı önler ve Chart'ınızın okunabilirliğini artırır. Örneğin, bir Kubernetes kaynağının adını belirlerken, genellikle bir ön ek ve bir anahtar kelimeyi birleştiririz. Bu işlemi bir helper fonksiyonu ile soyutlayabiliriz:
{{/*
Helper function to create a fully qualified app name.
*/}}
{{ define "mychart.fullname" -}}
{{- if .Values.fullnameOverride -}}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" -}}
{{- else -}}
{{- $name := default .Chart.Name .Values.nameOverride -}}
{{- if contains $name .Release.Name -}}
{{- .Release.Name | trunc 63 | trimSuffix "-" -}}
{{- else -}}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" -}}
{{- end -}}
{{- end -}}
{{- end -}}
Bu fonksiyon, .Release.Name (Helm tarafından atanan sürüm adı) ve .Values.nameOverride veya .Chart.Name gibi değerleri kullanarak benzersiz ve standart bir isim oluşturur. Bu fonksiyonu daha sonra diğer şablonlarda şu şekilde kullanabilirsiniz:
metadata:
name: {{ include "mychart.fullname" . }}
Bu tür helper fonksiyonları, Chart'larınızın daha modüler ve sürdürülebilir olmasını sağlar. Karmaşık adlandırma kuralları veya hesaplamalar için de kullanılabilirler.
Helm Hook'ları: Dağıtım Sürecini Özelleştirme
Helm Hook'ları, bir Chart'ın yaşam döngüsü sırasında belirli olaylarda çalıştırılabilen özel Kubernetes kaynaklarıdır. Bu, kurulum öncesi veya sonrası görevleri otomatikleştirmek için çok kullanışlıdır. Örneğin, bir veritabanı şemasını güncellemek, önbelleği temizlemek veya bir uygulamanın yeni sürümüne geçiş yapmadan önce testler çalıştırmak gibi görevler için Hook'lar kullanılabilir.
Helm Hook'ları, genellikle bir kind alanına özel bir annotation eklenerek tanımlanır. En yaygın Hook türleri şunlardır:
pre-install: Kurulum başlamadan önce çalışır.post-install: Kurulum tamamlandıktan sonra çalışır.pre-upgrade: Yükseltme başlamadan önce çalışır.post-upgrade: Yükseltme tamamlandıktan sonra çalışır.pre-delete: Silme başlamadan önce çalışır.post-delete: Silme tamamlandıktan sonra çalışır.
Bir örnek olarak, bir uygulamanın yeni sürümünü dağıtmadan önce bir veritabanı migrasyon betiği çalıştırmak için pre-upgrade Hook'u kullanalım:
Öncelikle, templates/ dizinine bir migration-job.yaml dosyası ekleyelim:
apiVersion: batch/v1
kind: Job
metadata:
name: {{ include "mychart.fullname" . }}-migration
labels:
{{ include "mychart.labels" . | nindent 4 }}
annotations:
"helm.sh/hook": pre-upgrade # Bu kaynak bir pre-upgrade hook'udur
"helm.sh/hook-weight": "-5" # İşlem sırasını belirler (daha düşük değerler önce çalışır)
"helm.sh/hook-delete-policy": hook-succeeded # Başarılı olursa silinsin
spec:
template:
metadata:
name: {{ include "mychart.fullname" . }}-migration
labels:
{{ include "mychart.labels" . | nindent 6 }}
spec:
restartPolicy: Never
containers:
- name: migration
image: my-docker-repo/my-migration-tool:latest
command: ["/app/run-migrations.sh"]
env:
- name: DATABASE_URL
valueFrom:
secretKeyRef:
name: my-db-secret
key: url
Bu Job kaynağı, pre-upgrade Hook'u olarak işaretlenmiştir. Bu, bir helm upgrade komutu çalıştırıldığında, Helm bu Job'u başlatacaktır. Job tamamlandıktan sonra (veya başarısız olursa, hook-delete-policy'ye bağlı olarak), Helm yükseltme işlemine devam edecektir. hook-weight, birden fazla Hook olduğunda bunların çalışma sırasını belirler; daha düşük değerler daha erken çalışır.
Hook'lar, dağıtım süreçlerinizi daha güvenli ve otomatize hale getirmenize olanak tanır. Ancak, Hook'ların dikkatli kullanılması gerekir, çünkü yanlış yapılandırıldığında dağıtım süreçlerini engelleyebilirler.
Helm ile CI/CD Pipeline'larını Otomatikleştirme
Helm'in en güçlü kullanım alanlarından biri, CI/CD (Sürekli Entegrasyon/Sürekli Dağıtım) pipeline'larında uygulama dağıtımını otomatikleştirmektir. Bir kod değişikliği yapıldığında, bu değişikliğin otomatik olarak test edilip ardından Kubernetes kümesine dağıtılması, modern yazılım geliştirme süreçlerinin temelini oluşturur. Helm, bu süreci hem basitleştirir hem de daha güvenilir hale getirir.
CI/CD'de Helm'in Rolü
Geleneksel CI/CD pipeline'larında, her yeni sürüm için Kubernetes manifestlerini manuel olarak güncellemek veya karmaşık scripting kullanmak gerekebilir. Bu, hem zaman alıcı hem de hata yapmaya açıktır. Helm ile bu süreç şu şekilde standartlaştırılabilir:
- Kod Değişikliği ve Build: Geliştirici bir kod değişikliği yapar, bu değişiklik versiyon kontrol sistemine (örneğin Git) gönderilir. CI sunucusu bu değişikliği algılar ve uygulamayı build eder, ardından Docker imajını oluşturup bir container registry'ye (örneğin Docker Hub, GCR, ECR) gönderir.
- Helm Chart Güncellemesi: CI pipeline'ı, oluşturulan yeni Docker imaj etiketini (tag) kullanarak ilgili Helm Chart'ının
values.yamldosyasını günceller. Bu güncelleme otomatik olarak yapılır. - Testler: Pipeline, güncellenmiş Helm Chart'ını kullanarak uygulamayı bir test ortamına dağıtır. Ardından otomatik testler (birim testleri, entegrasyon testleri vb.) çalıştırılır.
- Üretim Dağıtımı: Testler başarılı olursa, pipeline aynı Helm Chart'ını kullanarak uygulamayı üretim ortamına dağıtır. Bu dağıtım, farklı ortamlar için özelleştirilmiş
values.yamldosyaları veya Helm komut satırı argümanları kullanılarak gerçekleştirilebilir.
Örnek CI/CD Workflow (Jenkins ile)
Birçok CI/CD aracı (Jenkins, GitLab CI, GitHub Actions, CircleCI vb.) Helm ile entegre olabilir. İşte Jenkins ile basitleştirilmiş bir örnek:
Jenkinsfile (örnek):
pipeline {
agent any
stages {
stage('Checkout') {
steps {
git 'https://github.com/your-username/your-repo.git'
}
}
stage('Build and Push Docker Image') {
steps {
script {
def imageTag = env.BUILD_ID ?: "latest" // Jenkins build ID'sini veya 'latest' kullan
docker.build("my-docker-repo/my-web-app:${imageTag}")
docker.withRegistry('https://index.docker.io/v1/', 'docker-hub-credentials') {
docker.image("my-docker-repo/my-web-app:${imageTag}").push()
}
}
}
}
stage('Update Helm Chart') {
steps {
script {
// values.yaml dosyasındaki imaj etiketini güncelle
sh "sed -i 's|tag: .*|tag: \"${env.BUILD_ID ?: 'latest'}\"|g' ./my-helm-chart/values.yaml"
}
}
}
stage('Deploy to Staging') {
steps {
script {
// Staging ortamı için değerleri belirle
def stagingValues = "--set image.tag=${env.BUILD_ID ?: 'latest'} --set environment=staging"
sh "helm upgrade --install my-staging-release ./my-helm-chart ${stagingValues} --namespace staging"
}
}
}
stage('Run Staging Tests') {
steps {
// Otomatik testleri çalıştır (örneğin kubectl ile servis adresini alıp curl ile test et)
echo "Running staging tests..."
// ... test komutları ...
}
}
stage('Approve for Production') {
// Manuel onay adımı eklenebilir
input message: 'Proceed to production deployment?'
}
stage('Deploy to Production') {
steps {
script {
// Production ortamı için değerleri belirle
def productionValues = "--set image.tag=${env.BUILD_ID ?: 'latest'} --set environment=production"
sh "helm upgrade --install my-prod-release ./my-helm-chart ${productionValues} --namespace production"
}
}
}
}
}
Bu örnekte:
- Docker imajı oluşturulur ve registry'ye push edilir.
sedkomutu ilevalues.yamldosyasındaki imaj etiketi güncellenir.helm upgrade --installkomutu ile uygulama önce staging ortamına dağıtılır.--setparametresi ile spesifik değerler üzerine yazılır.- Otomatik testler çalıştırılır.
- Manuel onay sonrası üretim ortamına dağıtım yapılır.
Helm'in versiyonlama ve geri alma yetenekleri, CI/CD pipeline'larında güvenliği artırır. Bir dağıtım hatası durumunda, önceki stabil sürüme hızlıca geri dönmek mümkündür.
Helm ile Güvenlik ve Yapılandırma Yönetimi
CI/CD pipeline'larında Helm kullanırken, hassas bilgilerin (şifreler, API anahtarları vb.) yönetimi kritik öneme sahiptir. Bu bilgileri doğrudan values.yaml dosyasına yazmak yerine, Kubernetes Secrets veya Helm'in kendi Secret yönetimi mekanizmaları kullanılmalıdır. CI/CD araçları, bu sırları güvenli bir şekilde depolamak ve pipeline'a enjekte etmek için mekanizmalar sunar.
Helm, farklı ortamlar için farklı yapılandırmaları yönetmeyi kolaylaştırır. Her ortam için ayrı values-staging.yaml, values-production.yaml gibi dosyalar oluşturabilir ve bunları helm upgrade komutunda -f parametresi ile belirtebilirsiniz:
helm upgrade --install my-prod-release ./my-helm-chart -f ./my-helm-chart/values-production.yaml --namespace production