Helm Chart, Helmfile ve Ötesi

Çok sıkmamayı planlıyor bu yazı. Okumayı, bir şeylerin geri planını ve tarihçesini öğrenmeyi, felsefesini anlamayı sevmiyoruz çünkü. Sıkılıyoruz.

“Ne” ve “nasıl” sorularını seviyoruz sadece. Bana “ne yapacağımı” söyle, “nasıl yapacağımı” söyle. Kafa ütüleme.

Bu da öyle bir yazı. Kafa ütülemeyen bir yazı. Tarihçeyi anlatmayan bir yazı. Felsefesinden bahsetmeyen bir yazı. Bir bağlam, bir perspektif vermeyi dert edinmeyen bir yazı.

Sadece taşınacak suyu, kırılacak odunu gösteren bir yazı.

Peki neler anlatılıyor? İlk bölümde bir uygulama için gerekli temel Kubernetes nesnelerinden bahsediliyor. İkinci bölümde Helm aracı, Helm chart ve Helm chart reponun ne olduğu, neden ihtiyaç duyulduğu ve Helm chart’ların anotomisi ve yaşam döngüsü anlatılıyor. Son bölümdeyse Helmfile aracı, neden ihtiyaç duyulduğu ve bir Helmfile projesinin anatomisi ve yaşam döngüsü anlatılıyor.

Bir Uygulama İçin Temel Kubernetes Nesneleri

Kubernetes nesnelerden oluşur. Bir uygulamanın Kubernetes üzerinde çalıştırılabilmesi için birden fazla Kubernetes nesnesine ihtiyaç duyulur. Her bir nesne yaml formatında deklaratif olarak ifade edilerek Kubernetes’e REST API’si ile iletilir. API’yi de direkt çağırmayız, kubectl benzeri araçları kullanırız.

Uygulamayı kurmak için bir Deployment nesnesine ihtiyaç duyarız. Kafka node’ları gibi veya DB node’ları gibi veri tutan stateful bir yapıya sahipse ve kimliksiz node’lar yeterli olmuyorsa Deployment yerine Statefulset nesnesi kullanırız.

Uygulamayı Kubernetes içinde diğer uygulamaların çağırabilmesi ve yük dağıtımı için Service nesnesine, dışarıya açmak için Ingress nesnesine, podların kaynaklara rol tabanlı erişimi için ServiceAccount nesnesine, otomatik ölçekleme için HorizontalPodAutoscaler nesnesine, harici disk bağlamak için PersistentVolumeClaim nesnesine, ortam değişkeni veya konfigürasyon dosyası gibi konfigürasyonları dışarıdan vermek için ConfigMap nesnesine, şifre vb. hassas bilgiler içinse Secret nesnesine ihtiyaç duyarız.

Kubernetes farklı ihtiyaçların karşılanması için bir sürü nesne sunar bu şekilde. Ayrıca genişletilebilir bir yapıdadır. Örneğin Ingress ortada yokken OpenShift, Kubernetes API’sini genişleterek aynı ihtiyaç için Route nesnesini ekleyip kullanıma sunmuş, sonrasında bu yaklaşım Ingress’i doğurmuştur.

Çok basit olarak bir Deployment nesnesi şuna benzer:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Helm Nedir, Helm Chart Nedir?

Helm, bir Kubernetes paket yöneticisidir. Bir araçtır. Uygulamanızı paketlemeyi, Kubernetes’e yüklemeyi, güncellemeyi ve silmeyi sağlar.

Paketlemeyi yaparken go dili tabanlı bir şablonlama mekanizması (templating engine) kullanır ve böylelikle ortam bazlı değişen değerleri parametrik olarak yönetmeyi sağlar.

Oluşan pakete Helm chart denir ve .tgz zip formatındadır.

Helm Chart Repo Nedir?

Helm chart paketlerini barındırdığımız depoya Helm chart repo denir. Konteynır imaj repolarına benzer bir işlevi vardır. Genellikle konteynır imaj repoları Helm chart desteği de sunmaktadır.

Popüler Helm chart repolarından önde gelen ikisi Nexus ve Harbor’dur.

Helm Chart Hangi Problemi Çözer?

Bir tane uygulamanız ve tek bir ortamınız varsa Kubernetes nesnelerini içeren dört beş tane yaml dosyanız olur. Veya hepsini alt alta koyarsınız ve tek bir manifest dosyanız olur. Sonra da bunu kubectl apply komutu ile çalıştırıverirsiniz olur biter.

kubectl apply -f ./app-manifest.yaml

Fakat beş on tane modülden oluşan bir uygulamanız varsa veya onlarca ekip yüzlerce servisten oluşan koca bir yapıya sahipseniz bu şekilde yönetemezsiniz.

Çünkü her bir Kubernetes nesnesi bir sürü konfigürasyon içerir. Metadalar, etiketler, ortam değişkenleri ve bunların içeriye nasıl geçirileceği ile ilgili tanımlamalar, cpu/bellek talep ve üst limitleri, kopya sayısı, otomatik ölçekleme koşulları, healthcheck/readiness vb. kontrollerin tanımları, disk boyutu, disk tipi, erişim şekli, portlar, konteynır imajının bilgileri, imaj repo bilgileri vesaire vesaire.

Ayrıca bu konfigürasyonların bir kısmı ortam bazlı değişebilir: dev, test, kabul, ref, prod. Test ortamında test veri tabanına gidersiniz, az cpu talep edersiniz. Prod ortamda prod ortam veritabanına gidersiniz, cpu limiti ve disk talebi çok daha yüksek olur, ortam değişkenleri ve şifre vb. bilgiler değişir.

Ek olarak farklı tipteki Kubernetes nesnelerinin yaml konfigürasyonlarında hem ortak olan kısımlar hem de kendilerine özgü kısımlar bulunur.

Bir sürü uygulamayı yönetmeniz gerektiğinde kopyala yapıştır kullanılabilir bir çözüm olmaktan çıkar.

Helm bu probleme şablonlama mekanizması (templating) üzerinden bir çözüm sunar. JSP, Freemarker, Handlebars gibi araçlar tarayıcılar için html üretmek üzere bir şablonlama mekanizması sunardı. Helm de Kubernetes yaml konfigürasyonu üretmek üzere benzer mantıkla çalışır.

Helm Nasıl Yüklenir?

Helm aracını yüklemek için farklı işletim sistemlerindeki Homebrew, Chocolatey, Snap, Apt, Yum vb. paket yöneticilierini kullanabiliriz.

Ayrıca çalışırken binary sürümü içeren ziplenmiş kurulum dosyasını da manuel olarak indirip, bir dizine koyup, dizini PATH değişkenine ekleyerek de kullanabiliriz.

Detaylar için: Helm | Installing Helm

Komutlar Üzerinden Helm Chart Yaşam Döngüsü

Helm Chart Repo Ekleme ve Hazır Bir Helm Chart’ı İndirme

Hazır bir Helm chart’ı kullanmak için, veya kendi Helm chart’ının içinde bir baz Helm chart’ı kullanmak için bir helm chart repo ekleriz.

helm repo add https://charts.bitnami.com/bitnami
helm repo add harbor-repo https://registry.xyz.com/chartrepo --username [username] --password
password]
helm repo add --force-update nexus-repo http://localhost:8081/repository/helm-releases/ --username $nexususer --password $nexuspass

helm repo list                    # eklenen repoları listele
helm search repo kafka --devel    # repolarda arama yap

helm fetch nexus-repo/kafka --version 1.0.0   # Kafka Helm chart'ını indir

Helm Chart Oluşturma

Uygulama için bir Helm chart yaratırız aşağıdaki gibi. Komut bir Helm chart iskeleti üretir. İhtiyacımıza göre değiştirerek ilerleriz.

Eğer uygulamanın yaşam döngüsü ile Helm chart’ın yaşam döngüsü örtüşüyorsa, proje ana dizini içinde chart isimli bir dizine koyabiliriz. Dockerfile dosyasının proje içerisinde takip edilmesi gibi.

helm create app1-chart

Helm Chart Kontrolü ve Kubernetes’e Gönderilecek Konfigürasyona Bakma

Helm chart’ın bulunduğu dizinde lint ve template komutlarını kullanarak yazım hatalarına ve nihai çıktıya bakabiliriz.

helm lint .
helm template .
helm template . > manifest.yaml

Kubernetes’e Yükleme, Güncelleme, Silme, Listeleme

helm install app1 .
helm upgrade app1 .
helm upgrade --install app1 . 
helm uninstall app1
helm list
helm get manifest app1   # Kubernetes'e yüklenen konfigürasyonu/manifestoyu göster

Helm Chart’ın Paketlenmesi ve Chart Repoya Yayınlama

Helm paketlendikten sonra Nexus veya Harbor’a yayınlanır. Nexus’a yayınlarken curl kullanılabilir. Harbor’a yayınlarken helm-push plugin’i kullanılabilir.

# Paketle
helm package app1/chart --debug

# Nexus'a yayınla
curl --fail --show-error -u $nexususer:$nexuspass http://localhost:8081/repository/helm-releases/ --upload-file app1-0.1.0.tgz

# Harbor'a yayınla
helm plugin install https://github.com/chartmuseum/helm-push
helm cm-push app1-0.10.tgz harbor-repo

Bir Helm Chart’ın Anatomisi

Yeni bir Helm chart oluşturuyoruz:

helm create app1-chart

Komutu çalıştırdığımızda aşağıdaki resimdeki gibi bir iskelet oluşur. Ardından ihtiyacımıza göre değişiklikler yaparak ilerleriz.

İhtiyaç olursa ConfigMap, Secret, PersistenVolumeClaim vb. Kubernetes nesneleri için ilgili şablonları templates dizinine, parametrik değerleri ise values.yaml içine koyarız.

1. Helm chart ana dizini. Otomatik olarak oluşturulan temel iskeleti içerir.
2. Helm chart künyesini içerir. Chart versiyonu, ismi, uygulama versiyonu, bağımlı olunan alt chart’lar vb.
3. values.yaml veya diğer bir deyişle parametreler. Bir uygulama için properties dosyaları ne ise bu da bir chart için odur. Ayrıca her bir ortam için farklı bir values.yaml dosyası vermemiz gerekir.
4. charts dizini bağımlı olunan alt Helm chart’ları içerir. Bunlar .tgz uzantılı ziplenmiş dosyalardır. İçini açıp ne içerdiklerine bakabilirsiniz.
5. templates dizini Kubernetes nesnelerinin şablonlarını içerir. values.yaml içindeki değerlerle birleştirildiğinde Kubernetes nesnelerine ait nihai yaml çıktıları elde edilir.
6. Deployment nesnesine ait şablonu içerir.
7. HorizontalPodAutoscaler nesnesine ait şablonu içerir.
8. Ingress nesnesine ait şablonu içerir.
9. Service nesnesine ait şablonu içerir.
10. ServiceAccount nesnesine ait şablonu içerir.
11. Şablonlarda kullanılan yardımcı fonksiyonları içerir. Şablonlama mekanizması Go templating dili kullandığından, o sentaksı bilmeniz işleri kolaylaştırır.

Chart.yaml İçeriği

apiVersion: v2
name: app1-chart
description: A Helm chart for Kubernetes

# A chart can be either an 'application' or a 'library' chart.
#
# Application charts are a collection of templates that can be packaged into versioned archives
# to be deployed.
#
# Library charts provide useful utilities or functions for the chart developer. They're included as
# a dependency of application charts to inject those utilities and functions into the rendering
# pipeline. Library charts do not define any templates and therefore cannot be deployed.
type: application

# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
# Versions are expected to follow Semantic Versioning (https://semver.org/)
version: 0.1.0

# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application. Versions are not expected to
# follow Semantic Versioning. They should reflect the version the application is using.
# It is recommended to use it with quotes.
appVersion: "1.16.0"

Deployment.yaml İçeriği

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "app1-chart.fullname" . }}
  labels:
    {{- include "app1-chart.labels" . | nindent 4 }}
spec:
  {{- if not .Values.autoscaling.enabled }}
  replicas: {{ .Values.replicaCount }}
  {{- end }}
  selector:
    matchLabels:
      {{- include "app1-chart.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      {{- with .Values.podAnnotations }}
      annotations:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      labels:
        {{- include "app1-chart.selectorLabels" . | nindent 8 }}
    spec:
      {{- with .Values.imagePullSecrets }}
      imagePullSecrets:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      serviceAccountName: {{ include "app1-chart.serviceAccountName" . }}
      securityContext:
        {{- toYaml .Values.podSecurityContext | nindent 8 }}
      containers:
        - name: {{ .Chart.Name }}
          securityContext:
            {{- toYaml .Values.securityContext | nindent 12 }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /
              port: http
          readinessProbe:
            httpGet:
              path: /
              port: http
          resources:
            {{- toYaml .Values.resources | nindent 12 }}
      {{- with .Values.nodeSelector }}
      nodeSelector:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      {{- with .Values.affinity }}
      affinity:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      {{- with .Values.tolerations }}
      tolerations:
        {{- toYaml . | nindent 8 }}
      {{- end }}

Values.yaml İçeriği (Kısmi)

# Default values for app1-chart.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount: 1

image:
  repository: nginx
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: ""

imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""

serviceAccount:
  # Specifies whether a service account should be created
  create: true
  # Annotations to add to the service account
  annotations: {}
  # The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname template
  name: ""

podAnnotations: {}

podSecurityContext: {}

securityContext: {}


service:
  type: ClusterIP
  port: 80

resources: {}
  # We usually recommend not to specify default resources and to leave this as a conscious
  # choice for the user. This also increases chances charts run on environments with little
  # resources, such as Minikube. If you do want to specify resources, uncomment the following
  # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
  # limits:
  #   cpu: 100m
  #   memory: 128Mi
  # requests:
  #   cpu: 100m
  #   memory: 128Mi

Deployment.yaml Şablonu + values.yaml Değerleri = Kubernetes Çıktısı

Chart dizini içinde “helm template apps .” komutunu çalıştırdığımızda aşağıdaki gibi bir nihai çıktı elde ederiz. Bu Kubernetes’e gidecek olan konfigürasyondur.

# Source: app1-chart/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: apps-app1-chart
  labels:
    helm.sh/chart: app1-chart-0.1.0
    app.kubernetes.io/name: app1-chart
    app.kubernetes.io/instance: apps
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: app1-chart
      app.kubernetes.io/instance: apps
  template:
    metadata:
      labels:
        app.kubernetes.io/name: app1-chart
        app.kubernetes.io/instance: apps
    spec:
      serviceAccountName: apps-app1-chart
      securityContext:
        {}
      containers:
        - name: app1-chart
          securityContext:
            {}
          image: "nginx:1.16.0"
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /
              port: http
          readinessProbe:
            httpGet:
              path: /
              port: http
          resources:
            {}

Helm Chart Bağımlılık Yönetimi ve Kalıtım

Bazen var olan bir Helm Chart’ı alıp bazı kısımlarını kendinize göre uyarlayıp kendi reponuza yayınlamak isteyebilirsiniz.

Bazen de modüler bir yapı kurgulayıp, tüm ekiplerin ortak olarak kullandığı şeyleri bir baz chart içinde tanımlayabilirsiniz. Yeni bir uygulama eklerken bu ortak baz chart’ı bağımlılık olarak deklare edip kullanabilirsiniz.

Buradaki örnekte gerçek zamanlı akan veri (streaming) işlemeyi sağlayan Apache Flink’in kolay yönetimini sağlayan Ververica platformunun Helm chart’ını alıp modifiye ederek kendi repomuza ekleyeceğiz.

Baştan söylemek gerekir ki, değiştirebileceğiz şeyler sadece values.yaml dosyasındaki değerlerdir. Chart’ın kendi iç yapısı ile oynama imkanımız bulunmuyor. Fakat kendi ihtiyacımıza göre yeni Kubernetes nesneleri ekleyebiliriz. Burada da Ingress nesnesi ekleyeceğiz.

Öncelikle yeni bir chart oluşturuyoruz “helm create” komutu ile.

İçinden ihtiyaç duymadığımız şeyleri temizliyoruz.

Ardından ververica-platform Helm chart’ını bağımlılık olarak deklare ediyoruz Chart.yaml dosyası içinde.

apiVersion: v2
name: ververica-platform
description: A Helm chart for Kubernetes

type: application

version: 5.3.0

appVersion: "2.7.0"


dependencies:
  - name: ververica-platform
    version: 5.3.0
    repository: https://charts.ververica.com

Bağımlılıkları ekledikten sonra proje içine çekmemiz gerekiyor. Komutlar için https://helm.sh/docs/helm/helm_dependency/ dokümanına bakabilirsiniz.

Aşağıda görüldüğü üzere orijinal chart charts dizini altına eklendi.

Ayrıca npm benzeri paket yöneticilerinin de yaptığı gibi, içinde bağımlıkların sha özetlerinin bulunduğu versiyon kilitleme mekanizması sunan Chart.lock dosyası da eklendi.

Values.yaml dosyasında baz chart’tan gelen değerleri ihtiyacımıza göre ezip, Ingress için gerekli tanımları ekliyoruz.

# Default values for ververica.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

ververica-platform:
  acceptCommunityEditionLicense: true

  ## See helm value overriding bug - false value as a workaround: https://github.com/helm/helm/issues/9136
  # Override to empty the securityContext values for OpenShift
  securityContext: false

  vvp:
    ### Configure VVP to use a local SQLite database
    persistence:
      type: local

    sqlService:
      pool:
        coreSize: 1
        maxSize: 1

    ### Configure Minio for Universal Blob Storage
    blobStorage:
      baseUri: s3://vvp
      s3:
        endpoint: http://minio.vvp.svc.cluster.local:9000

  blobStorageCredentials:
    s3:
      accessKeyId: minio-user
      secretAccessKey: minio-password

  ### Allow Ververica Platform to manage Apache Flink deployments in "vvp-jobs" namespace
  rbac:
    additionalNamespaces:
      - vvp-jobs

  ### Reduce gateway container memory requests.
  gateway:
    resources:
      limits:
        memory: 2Gi
      requests:
        memory: 1Gi

  appmanager:
    resources:
      limits:
        memory: 1Gi
      requests:
        memory: 500Mi

ingress:
  enabled: true
  targetPort: 80
  className: ""
  annotations: {}
  hosts:
    - host: vvp.apps.xyz.com
      paths:
        - path: /
          pathType: ImplementationSpecific
  tls: []

Artık kendimize göre uyarladığımız ververica-platform Helm chart’ı hazır hale geldi, bunu kendi repomuza yayınlıyoruz ilgili pipeline üzerinden. Uygulama taşıma sistemimizin ilgili adımında bu paketi repodan çekip Kubernetes veya OpenShift üzerine kuruyoruz.

Helmfile

Helmfile aracı kısaca “chart of Helm charts” olarak ifade edilir. Yani birden fazla uygulamayı (Helm chart) alıp, merkezi olarak tek bir noktadan farklı ortamlara farklı konfigürasyonlarla yüklemenizi sağlar.

Helmfile arka tarafta Helm aracını kullanır. Helmfile aracını yüklemek için https://helmfile.readthedocs.io/en/latest/ dokümanından faydalanabilirsiniz.

Helmfile Komutları Üzerinden Yaşam Döngüsü

Test Ortamına Kurulum veya Güncelleme için

helmfile -e test sync    # -e kurulum yapılacak ortamı belirtir 

Test Ortamına Kurulu Uygulamaları Silmek İçin

helmfile -e test destroy

Test Ortamını Güncellemeden Önce Farklara Bakmak İçin

Bu özellik arka tarafta https://github.com/databus23/helm-diff Helm pluginini kullanır, ihtiyacınız varsa kurmanız gerekir.

helmfile -e test diff

Test Ortamına Ait Yaml Dosya Çıktısını Almak İçin

Bazen uygulama taşıma sisteminizle helmfile üzerinden tüm uygulamalarınızı kurarsınız.

Bazense uygulamanız alt uygulamalardan oluşan bir üründür ve müşterinize vermeniz gerekir. Müşteriniz Helm chart değil yaml çıktısını isteyebilir. Siz de “helmfile template” konutu ile tüm yaml çıktısını bir dosyaya yazdırır iletirsiniz.

helmfile  -e test template
helmfile  -e test template > app-manifest.yaml

Helmfile Konfigürasyonlarında Hata Var mı Görmek İçin

helmfile  -e test lint

Bir Helmfile Projesinin Anotomisi

Öncelikle app-helmfiles isimli projemizi oluşturup içine aşağıdaki gibi temel dosyaları ve ortamlarımızı ekliyoruz.

1. repositories.yaml dosyası Helm chart repolarını içerir.
2. helmfile.yaml dosyası ana dosyadır, giriş noktasıdır, diğer her şey buradan dallanır.
3. helmdefaults.yaml dosyası helmfile aracına dair konfigürasyonları içerir.
4. environments.yaml farklı ortamlarımızı içerir.
5. uat ortamına ait konfigürasyonları içerir.
6. test ortamına ait konfigürasyonları içerir.
7. customer1-uat ortamına ait konfigürasyonları içerir.
8. customer1-test ortamına ait konfigürasyonları içerir.

Ortam Bazlı Konfigürasyonlar

1. Test ortamı için genel global değerler; hemfile.yaml dosyası içinde kullanılıyor.
2. app1 uygulaması için ortam için ezilen konfigürasyon değerleri.
3. app2 uygulaması için ortam için ezilen konfigürasyon değerleri.
4. app3 uygulaması için ortam için ezilen konfigürasyon değerleri.

test.yaml dosyası

# Values to be used in helmfile for the test environment

appChartVersion: 1.0.0

app1:
  enabled:  true
app2:
  enabled:  true
app3:
  enabled:  true

overrides/app1.yaml

# Put value overrides of the chart values.yaml for the test environment

ingress:
  hosts:
    - host: app1.apps.xyz.com
      paths:
        - path: /app1
          pathType: ImplementationSpecific

configMaps:
  envValues:
    dbUrl: "jdbc:oracle:thin:@199.199.199.199:1521/db-schema"

resources:
  limits:
    cpu: 1500m
    memory: 2500Mi
  requests:
    cpu: 1000m
    memory: 2500Mi

helmfile.yaml

1. bases bölümünde alt yaml dosylarını ekliyoruz.
2. releases bölümünde uygulamaları ekliyoruz.
3. Uygulama ismi, chart ismiyle aynı olacak şekilde.
4. Uygulama konfigürasyonunu için yukarıda yukarıda tanımladığımız appTemplate şablonunu kullanıyoruz kopyala-yapıştır yerine.
5. Uygulamanın o ortama yüklenip yüklenmeyeceğini app1.enabled değerine bakılacak şekilde ayarlıyoruz. Bu değer test ortamı için, test/test.yaml dosyasında tanımlanıyor.
6. templates bölümü kopyala-yapıştır yerine şablon tanımlamak için kullanıyor.
7. Şablonun ismi. birden fazla şablon tanımlamak mümkün farklı tipteki uygulamalar için.
8. Repodaki uygulama Helm chart’ının ismi
9. Yüklemek istediğimiz uygulama versiyonu
10. Development versiyonlarını kullanabilmek için
11. Helm Chart’ın yükleneceğini belirtiyoruz
12. Helm chart içindeki değerleri ortam bazlı ezmek için kullanılacak dosyayı belirtiyoruz
13. helm sync komutu öncesi çalışacak script’i belirtiyoruz. Global bir takım hazırlık işleriniz varsa hooks metotlarını kullanabilirsiniz.

repositories.yaml

repositories:
- name: our-product
  url: https://registry.xyz.com/chartrepo/our-product
  username: "{{ requiredEnv `CHART_REPO_USERNAME` }}"
  password: "{{ requiredEnv `CHART_REPO_PASSWORD` }}"

environments.yaml

environments:
  test:
    values:
      - test/test.values.yaml
  uat:
    values:
      - uat/uat.values.yaml
  customer1-test:
    values:
      - customer1-test/customer1-test.values.yaml
  customer1-uat:
    values:
      - customer1-uat/customer1-uat.values.yaml 

Bonus

• Yaml dosyalarını okumak ve işlemek için yq aracını kullanabilirsiniz.
• JSON dosyaları içinse jq aracını kullanabilirsiniz.