İçindekiler

1. Tekton
   1. Tekton’u Bu Kadar Özel Kılan Ne?
   2. Temel Yapı Taşları
2. Tekton Kubernetes Kurulumu
   1. Gereksinimler
   2. Tekton Pipelines
   3. Tekton CLI
   4. Tekton Dashboard
   5. Tekton Trigger
3. Pipeline Örneği
   1. Paralel Tasklar
   2. Trigger
   3. Image Build
4. Sonuç
5. Kaynakça

Tekton

Bir zamanlar, yazılım dünyasında otomasyon denince akla Jenkins pipeline, GitLab’ın CI/CD (Continuous Integration/Continuous Deployment- Sürekli Entegrasyon/Sürekli Teslimat) ve arada kaybolan bash script’lerinin garip labirentleri gelirdi. Herkesin kendine ait bir çözümü, bazen de dertleri vardı. Bu sırada, bulut devrimleriyle rüzgarı arkasına alan bir grup yazılımcı, yeni bir fikirle ortaya çıktılar. Tekton adında modüler, esnek ve tamamen Kubernetes uyumlu bir pipeline framework’ü oluşturdular.

Neden “Tekton”? Yunanca’da “usta” anlamına gelen “Tekton”, bir zanaatkârın her parçayı ustalıkla işlemesi gibi, yazılım süreçlerinde de CI/CD yapı taşlarını ince ince işlemek için ortaya çıktı. Hikaye, 2018 yılında Google’ın Knative projesi kapsamında başladı. Başlangıçta “Knative Build” adında bir bileşendi; ancak topluluktan gelen ilgi o kadar yoğundu ki, proje ayrı bir CI/CD sistemi olarak kendi kimliğini buldu ve Tekton adıyla yola devam etti[2].

Bu Kadar Özel Kılan Ne?

Tekton, tamamen Kubernetes düşünülerek sıfırdan inşa edilmiştir. Tekton’u özel kılan başlıca özellikler:

1. Kubernetes Uyumlu Yapı: Tekton, CI/CD süreçlerinizi Kubernetes kaynakları olarak ele alır. Bu sayede, pipeline’larınızı YAML dosyaları ile tanımlar ve diğer Kubernetes objeleri gibi yönetirsiniz.
2. Kapsayıcı Tabanlı Adımlar: Pipeline’daki her aşama kod derlemeden kendi kapsayıcısı içinde çalışır. Bu yaklaşım, her adım için tutarlılık, tekrar üretilebilirlik ve izolasyon sağlar.
3. Esneklik ve Genişletilebilirlik: Tekton, “Task” adı verilen yeniden kullanılabilir yapı taşları sağlar ve bu taşlar sayesinde yaygın CI/CD işlemlerini kolayca tanımlayabilirsiniz. Aynı zamanda kendi özel task’larınızı oluşturarak Tekton’u ihtiyaçlarınıza göre özelleştirebilirsiniz.
4. Açık Kaynak ve Topluluk Desteği: Tekton, geniş bir açık kaynak topluluğundan güç alır ve bu sayede sürekli iş birliği, yenilik ve iyileştirme ile gelişmeye devam eder.

Temel Yapı Taşları

Tekton’un CI/CD süreçlerinde kullandığı temel bileşenler şunlardır:

Step (Adım): Pipeline’ın daha küçük yürütme birimi olan “Step”, bir Kubernetes container tanımını içerir. Bu tanım, container imaj’ını ve çalıştırmak için gereken komutlar veya environment variable’lar gibi tüm bilgileri kapsar. Örneğin, “mvn package” veya “docker build” gibi adımlar “Step” olarak tanımlanabilir ve bir Task Kubernetes custom resource’u içinde yer alır.

Task: Bir Kubernetes custom resource olan Task, aynı Kubernetes node’undaki tek bir pod üzerinde sıralı olarak çalışan adımların dizisini tanımlar[3].

Pipeline: Şekil 1’de görüldüğü gibi Birden fazla Task’tan oluşan bir grup olup, bu Task’ların paralel veya sıralı olarak çalışmasını sağlayacak şekilde yapılandırılabilir ve CI/CD pipeline’ınızı temsil eder.

TaskRun: Belirli bir Task’ın çalıştırılmasını sağlar. İlgili parametleri task’a sağlar. (Örneğin: git repository, hedef container imaj’ı veya dağıtım yapılacak ortam bilgileri.)

PipelineRun: Belirli bir Pipeline’ın çalışmasını sağlar. İlgili parametleri pipeline’a sağlar[5].

Tekton, her adımı bir konteyner içinde çalıştırır ve bu adımların sırasını ve durumunu Kubernetes Annotations kullanarak takip eder. Adımlar arasında bağımlılıklar, giriş noktası (entrypoint) mekanizmasıyla yönetilir; bir adım tamamlanmadan sonraki adım başlamaz. Ek olarak, giriş kaynaklarının alınması ve çıktıların depolanması gibi işlemleri desteklemek için önceden tanımlı konteynerleri otomatik olarak devreye alır[7].

Tekton Kubernetes Kurulumu

Gereksinimler

Tekton’u kurmadan önce aşağıdaki gereksinimlerin karşılandığından emin olunması gerekir:

1. Kubernetes Kümesi: Tekton kurulumu yapılmadan önce Kubernetes kümenizin sürümünün uygun olup olmadığını kontrol etmelisiniz. Örneğin, Tekton’un mevcut en güncel sürümünü kullanmak için Kubernetes versiyonunun en az 1.28 veya daha yeni bir sürüm olması gerekmektedir.
2. Kubectl: Kubernetes komut satırı aracı yüklü ve yapılandırılmış olmalıdır.
3. Cluster-Admin Yetkileri: Mevcut kullanıcıya cluster-admin yetkileri verilmelidir.

Tekton Pipelines

1
2
# Tekton Pipelines'ın son resmi sürümünü bir Kubernetes kümesine kurmak için:
kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml

Kurulum hakkında güncel ve detaylı bilgiliye Tekton Pipelines Kurulumu adresinden erişebilirsiniz[4].

Tekton CLI

Tekton CLI (Command Line Interface – Komut Satırı Arayüzü), kullanıcıların komut satırı üzerinden pipelines, task’ları ve ilgili çalıştırmaları yönetmesine olanak tanır. Kullanıcılar, tek bir komut ile PipelineRun veya TaskRun başlatabilir, durumları görüntüleyebilir ve hata ayıklama işlemlerini kolayca gerçekleştirebilir. CLI aracı, grafiksel arayüze ihtiyaç duymadan hızlı operasyonlar gerçekleştirmek isteyen geliştiriciler için idealdir.Kurulum hakkında güncel ve detaylı bilgiye Tekton CLI Kurulumu adresinden erişebilirsiniz.

Tekton Dashboard

Tekton Dashboard, kullanıcıların web arayüzü üzerinden pipeline’ları görselleştirmesine, Task ve Pipeline çalıştırmalarını takip etmesine ve hataları analiz etmesine olanak tanıyan bir bileşendir. Şekil 2’de görüldüğü gibi CLI yerine bir grafiksel arayüz tercih edenler için büyük kolaylık sağlar ve projelerin durumunu merkezi bir noktadan görüntülemeyi mümkün kılar. Tekton dashboardu “read-only” veya “read-write” olacak şekilde 2 farklı modda kurabilirsiniz. Kurulum hakkında güncel ve detaylı bilgiliye Tekton Dashboard’u Kubernetes’e yükleme adresinden erişebilirsiniz.

Tekton Trigger

Tekton Triggers, harici olaylarla pipeline’ların otomatik olarak tetiklenmesini sağlayan bir eklentidir. Örneğin, bir git push işlemi gerçekleştiğinde veya bir pull request açıldığında otomatik olarak ilgili pipeline’ın çalıştırılmasını sağlar. Bu özellik, event-driven CI/CD süreçleri kurmak için vazgeçilmezdir [1]. Tekton Trigger Kurulumu

Tekton Pipeline Örneği

Şimdiye kadar Tekton’un temel bileşenlerini ve avantajlarını ele aldık. Ancak, Tekton’un gerçek gücünü anlayabilmek için pratik örnekler üzerinden ilerlemek faydalı olacaktır. CI/CD süreçlerini daha iyi kavramak ve öğrenilen bilgileri pekiştirmek için basit ve kapsamlı Tekton pipeline örneklerine göz atacağız. Ayrıca, proje süreçlerinde karşılaştığımız ve çözüme kavuşturduğumuz spesifik sorunlara da değineceğiz.

Basit bir pipeline ile başlayalım.

Secret

Öncelikle pipeline içinde erişilerek kullanılacak basit bir secret objesi oluşturalım.

1
2
3
4
5
6
7
8
# secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: secret-message
type: Opaque
data:
  message: SGVsbG8sIFRla3RvbiE= #"Hello, Tekton!

Task

Ardından verdiğim workspace içerisindeki mesajı yazdıracak bir Task oluşturalım.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion: tekton.dev/v1
kind: Task
metadata:
   name: print-secret-task
spec:
   steps:
      - computeResources: {}
        image: ubuntu
        name: print-message
        script: |
           #!/bin/bash
           echo "The secret message is:"
           cat $(workspaces.secret-workspace.path)/message
   workspaces:
      - name: secret-workspace

Pipeline

Oluşturulan task’ı pipeline içerisinde çağıralım.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
   name: test-pipeline
spec:
   tasks:
      - name: print-secret-task
        taskRef:
           kind: Task
           name: print-secret-task
        workspaces:
           - name: secret-workspace
             workspace: secret-workspace
   workspaces:
      - name: secret-workspace

Pipelinerun

PipelineRun ile, test-pipeline’ını çalıştırıyorum.Secret’ı bağlamak için workspace olarak daha önceden oluşturduğum secret’ı veriyorum.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
   name: test-pipelinerun
   labels:
      tekton.dev/pipeline: test-pipeline
spec:
   pipelineRef:
      name: test-pipeline
   taskRunTemplate:
      serviceAccountName: pipeline-account
   timeouts:
      pipeline: 1h0m0s
   workspaces:
      - name: secret-workspace
        secret:
           secretName: secret-message

Pipeline’a ait çıktıyı tekton dashboard üzerinde veya pipelinerun’a ait pod’un loglarında görebiliriz.

1
2
The secret message is:
Hello, Tekton!

Paralel Tasklar

Paralel tasklar, bir Tekton pipeline içinde aynı anda çalışan bağımsız görevlerdir. Tekton, görevleri yönlendirilmiş asiklik grafik (directed acyclic graph) yapısına göre yönetir ve belirli bir görev başka bir görevle bağımlılık ilişkisi içinde değilse, bu görevler paralel olarak çalıştırılabilir. Paralel tasklar, özellikle zaman açısından kritik iş akışlarında süreci hızlandırmak için kullanışlıdır. Örneğin, bir uygulamanın birden fazla bağımsız modülünü test etmek veya derlemek için paralel tasklar kullanılabilir.

Bir task’ın başarısız olması, diğer paralel taskları doğrudan etkilemez. Ancak, başarısız olan bir task’ın sonucu diğer taskların ilerlemesi için bir koşul oluşturuyorsa (örneğin, bir bağımlılık ilişkisi varsa), bu durumda pipeline başarısız olabilir. Paralel tasklar, işlem sürelerini optimize ederek daha hızlı CI/CD süreçleri sağlar, kaynakların daha verimli kullanılmasını mümkün kılar ve büyük görevleri daha küçük bağımsız birimlere böler. Bu yapı, özellikle mikroservis mimarilerinde veya karmaşık test senaryolarında büyük avantaj sağlar.

Paralel Task Örneği

Yeni bir task oluşturalım ve bunu mevcut pipeline’da çalışan task’a (print-secret-task) paralel olarak ekleyelim.

1
2
3
4
5
6
7
8
9
10
11
apiVersion: tekton.dev/v1
kind: Task
metadata:
   name: paralel-task
spec:
   steps:
      - image: ubuntu
        name: print-message
        script: |
           #!/bin/bash
           echo "Task 2: Merhaba, Tekton!"

Pipeline’a ait yaml dosyamızda aşağıdaki satırları ekliyoruz.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# pipeline.yaml
...
tasks:
   - name: print-secret-task
     taskRef:
        kind: Task
        name: print-secret-task
     workspaces:
        - name: secret-workspace
          workspace: secret-workspace
   - name: paralel-task
     taskRef:
        kind: Task
        name: paralel-task
...

Pipeline içerisinde taskları biribirine paralel olarak ekledik (Temel yapı taşları başlığında Şekil 1’de görülen “b” ve “c” taskları gibi düşünebilirsiniz). Pipelinerun’ı çalıştırdığımızda tasklar ayrı taskrun pod’larında çalışacaktır. Çıktıyı incelemek için bu taskrun pod’larının loglarına bakabilir veya tekton arayüzünden çıktıları kolaylıkla görebiliriz.

1
2
3
4
The secret message is:
Hello, Tekton!

Task 2: Merhaba, Tekton!

Trigger

Tekton Trigger, bir CI/CD pipeline’ını belirli olaylara (event) dayalı olarak otomatik bir şekilde başlatmaya yarayan bir Tekton bileşenidir. Örneğin, GitHub deposunda bir pull request açıldığında veya Docker imaj’ı güncellendiğinde pipeline’ı tetiklemek için kullanılır. Tekton Trigger manuel pipeline başlatma süreçlerini ortadan kaldırarak, sürekli entegrasyon ve teslimat (CI/CD) döngüsünü otomatikleştirir ve hızlandırır. Genellikle, kod değişiklikleri, API çağrıları, zamanlanmış görevler gibi dış olaylara dinamik yanıt verilmesi gerektiğinde kullanılır.

Artıları arasında, yazılım teslim süreçlerinde hataların ve gecikmelerin azalması, olay tabanlı otomasyon sayesinde daha verimli iş akışlarının oluşturulması ve farklı kaynaklardan gelen tetikleyicilere kolayca adapte olabilme yeteneği bulunur.

Nasıl çalışır?

Tekton Triggers, Kubernetes kümeniz üzerinde çalışan bir kontrol hizmeti olup, Tekton Pipelines’ın işlevselliğini genişleterek olayları destekler. Bu, aşağıdaki Kubernetes Özel Kaynak Tanımlamaları (CRDs) ile sağlanır.

EventListener

Kubernetes kümeniz üzerinde belirli bir port’tan gelen olayları dinler. Bir veya daha fazla Trigger tanımlanabilir.

1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
   name: simple-eventlistener
spec:
   serviceAccountName: default
   triggers:
      - bindings:
           - kind: TriggerBinding
             ref: paralel-triggerbinding
        template:
           ref: paralel-triggertemplate

Trigger

EventListener, bir olay algıladığında ne yapılacağını belirtir. Trigger, aşağıdaki bileşenleri tanımlar:

• TriggerTemplate
• TriggerBinding
• Opsiyonel olarak Interceptor

TriggerTemplate

TriggerTemplate, kaynaklar (örneğin, TaskRun veya PipelineRun) için bir şablon oluşturur. Bu şablon, EventListener bir olayı algıladığında neyin oluşturulacağını ve/veya çalıştırılacağını belirtir. TriggerTemplate, kaynak şablonlarınız içinde kullanabileceğiniz parametreler tanımlar.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerTemplate
metadata:
  name: paralel-triggertemplate
spec:
  params:
    - default: '<github-repo>'
      description: The git repository URL
      name: git-url
    - default: main
      description: The git revision
      name: git-revision
  resourcetemplates:
    - apiVersion: tekton.dev/v1beta1
      kind: PipelineRun
      metadata:
        generateName: test-pipelinerun-
      spec:
        params:
          - name: git-url
            value: $(tt.params.git-url)
          - name: git-revision
            value: $(tt.params.git-revision)
        pipelineRef:
          name: test-pipeline
        workspaces:
        - name: secret-workspace
          secret:
            secretName: secret-message

TriggerBinding

TriggerBinding, olay yükünden (payload) hangi verilerin çıkarılacağını ve bu verilerle hangi TriggerTemplate alanlarının doldurulacağını belirtir. Bu alanlar daha sonra TriggerTemplate içinde doldurulur ve ilişkili TaskRun veya PipelineRun kaynaklarına aktarılır.

1
2
3
4
5
6
7
8
9
10
11
apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerBinding
metadata:
   name: paralel-triggerbinding
spec:
   params:
      - name: git-url
        value: $(body.repository.url)
      - name: git-revision
        value: $(body.ref)

ClusterTriggerBinding

Küme çapında yeniden kullanılabilirlik sağlamak için özellikle kullanışlı olan, küme düzeyinde tanımlanmış bir TriggerBinding versiyonudur.

Interceptor

Belirli bir platform için “her şeyi kapsayan” olay işleyicisidir. Interceptor, TriggerBinding çalıştırılmadan önce aşağıdaki işlemleri yapmanıza olanak tanır:

• Yük filtreleme,
• Doğrulama (bir secret kullanarak),
• Veri dönüştürme,
• Trigger koşulları tanımlama ve test etme.

Olay verileri Interceptor üzerinden geçtikten sonra Trigger‘a yönlendirilir ve ardından yük verileri TriggerBinding‘e aktarılır.

1
2
3
4
5
6
7
8
9
10
11
12
13
# eventlistener.yaml
...
interceptors:
   - ref:
        name: "gitlab"
     params:
        - name: "secretRef"
          value:
             secretName: foo
             secretKey: bar
        - name: "eventTypes"
          value: ["Push Hook"]
...

Image Build

Diyelim ki ekip arkadaşlarınızla birlikte karmaşık bir mikroservis tabanlı proje üzerinde çalışıyorsunuz. Her bir servisin bağımsız olarak test edilmesi, konteyner imaj’larının derlenmesi ve farklı ortamlar için dağıtıma hazırlanması gerekiyor. Tabi, işler yolunda gitmediğinde herkes suçlu olarak ci-cd-pipeline.yaml dosyasını gösteriyor! İşte böyle anlarda Tekton’un modüler yapısı ve gelişmiş özellikleri devreye giriyor.

Şimdi, çok adımlı bir iş akışını farklı task’lar ve tetikleyiciler kullanarak nasıl oluşturabileceğimize dair daha gerçekçi bir örnek inceleyelim. Bu örnekte aşağıdaki görevleri sırasıyla kullanacağız:

• Git Clone Task (kaynak) : Kod deposunu klonlamak için kullanılır.

• Maven Build Task (kaynak) : Maven kullanarak projeyi derler ve paketler.

• SonarQube Scanner Task (kaynak) : Kodun statik analizini yapmak ve kalite raporları oluşturmak için Sonarqube’e gönderir.

• Kaniko Task (kaynak): Docker Daemon’a ihtiyaç duymadan konteyner imaj’larını oluşturur ve bir container registry’ye yükler.

SonarQube Task’ında SSL (Secure Sockets Layer - Güvenli Yuva Katmanı) Doğrulama Aşaması Eklenmesi

Bazen hazır Tekton Hub üzerinde bulduğunuz task’lar tam olarak ihtiyacınızı karşılamaz ve biraz değiştirmeniz (modifiye) gerekir[8]. İşte bu, yazılım geliştiricilerin yaratıcı olmayı sevdiği anlardan biridir! SonarQube Scanner task’ında da durum böyle. Varsayılan task doğrudan SSL doğrulama için bir workspace talep etmez. Ancak biz kalite raporlarımızı güvenle gönderebilmek için özel bir SSL sertifikası eklemek istiyoruz. Bu amaçla, task içindeki sonar-scan adımını aşağıdaki gibi değiştiriyoruz:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
...
- computeResources: {}
    image: 'sonarsource/sonar-scanner-cli:5'
    name: sonar-scan
    script: |
      #!/usr/bin/env bash
      echo $JAVA_HOME
      echo "Importing SonarQube SSL certificate..."
      echo $SONAR_SCANNER_OPTS
      if [[ -f /workspace/certs/sonarqube.cer ]]; then
        keytool -import -trustcacerts -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit -alias sonarqube -file "/workspace/certs/sonarqube.cer" -noprompt
      else
        echo "SonarQube certificate not found!"
        exit 1
      fi
      sonar-scanner
...

Task’a workspace tanımlaması da ekleyerek sonarcert workspace’ini kullanabilir hale getiriyoruz:

1
2
3
4
5
6
7
...
workspaces:
  ...
  - description: sonar-certs
    mountPath: /workspace/certs/
    name: sonarcert
  ...

Bu küçük değişiklik sayesinde SonarQube task’ı artık SSL sertifikalarıyla uyumlu hale geliyor ve güvenle analiz yapabiliyor.

Pipeline.yaml Örneği

Aşağıda örnek Pipeline.yaml dosyası mevcut. Bu pipelineda, imaj’ları quay’a yükleyeceğiz ve bunun için bir robot hesabı kullanacağız. Ayrıca SonarQube için özel sertifika doğrulaması ekleyeceğiz.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
# DEMO-PIPELINE.yaml
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: demo-pipeline
spec:
  finally:
    - name: kaniko
      params:
        - name: IMAGE
          value: '$(params.image-url):$(params.image-tag)'
        - name: DOCKERFILE
          value: ./Dockerfile
        - name: CONTEXT
          value: ./
        - name: EXTRA_ARGS
          value: []
        - name: BUILDER_IMAGE
          value: 'gcr.io/kaniko-project/executor:v1.20.0'
      taskRef:
        kind: Task
        name: kaniko
      workspaces:
        - name: source
          workspace: source-workspace
        - name: dockerconfig
          workspace: dockerconfig
        - name: quaycert
          workspace: quaycert
  params:
    - name: image-tag
      type: string
    - default: <IMAGE'IN GÖNDERİLECEĞİ ADRES>
      name: image-url
      type: string
  tasks:
    - name: git-clone
      params:
        - name: url
          value: >-
            <KOD REPOSU>
        - name: revision
          value: master
        - name: refspec
          value: ''
        - name: submodules
          value: 'true'
        - name: depth
          value: '0'
        - name: sslVerify
          value: 'true'
        - name: crtFileName
          value: ca-bundle.crt
        - name: subdirectory
          value: ''
        - name: sparseCheckoutDirectories
          value: ''
        - name: deleteExisting
          value: 'true'
        - name: httpProxy
          value: ''
        - name: httpsProxy
          value: ''
        - name: noProxy
          value: ''
        - name: verbose
          value: 'true'
        - name: gitInitImage
          value: >-
            gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/git-init:v0.40.2
        - name: userHome
          value: /home/git
      taskRef:
        kind: Task
        name: git-clone
      workspaces:
        - name: output
          workspace: source-workspace
        - name: basic-auth
          workspace: basic-auth
    - name: build
      params:
        - name: MAVEN_IMAGE
          value: 'gcr.io/cloud-builders/mvn:latest'
        - name: GOALS
          value: package
        - name: DIRECTORY
          value: .
        - name: CACERTFILE
          value: <SERTİFİKA DOSYA ADI>
        - name: ARGS
          value:
            - ''
      runAfter:
        - git-clone
      taskRef:
        kind: Task
        name: build
      workspaces:
        - name: source
          workspace: source-workspace
        - name: maven-local-repo
          workspace: source-workspace
        - name: maven-settings
          workspace: maven-settings
        - name: certdir
          workspace: certdir
    - name: sonarqube-scanner
      params:
        - name: SONAR_HOST_URL
          value: '"https://sonarqube.example.com"'
        - name: SONAR_PROJECT_KEY
          value: "my-project"
        - name: PROJECT_VERSION
          value: '1.0'
        - name: SOURCE_TO_SCAN
          value: .
        - name: SONAR_ORGANIZATION
          value: <....>
        - name: SONAR_SCANNER_IMAGE
          value: >-
            docker.io/sonarsource/sonar-scanner-cli:4.6@sha256:7a976330a8bad1beca6584c1c118e946e7a25fdc5b664d5c0a869a6577d81b4f
        - name: SONAR_LOGIN_KEY
          value: login
        - name: SONAR_PASSWORD_KEY
          value: password
        - name: SONAR_TOKEN
          value: token
      runAfter:
        - build
      taskRef:
        kind: Task
        name: sonarqube-scanner
      workspaces:
        - name: source
          workspace: source-workspace
        - name: sonarcert
          workspace: sonarcert
        - name: sonar-credentials
          workspace: sonar-credentials
  workspaces:
    - name: source-workspace
    - name: basic-auth
    - name: certdir
    - name: maven-settings
    - name: sonar-credentials
    - name: sonarcert
    - name: dockerconfig
    - name: quaycert

Bu pipeline çeşitli workspace’ler tanımladık ve her biri farklı bir amaç için kullanılıyor[6].

• source-workspace: Kod deposu klonlandıktan sonra tüm adımların kaynak kod dosyalarına erişim sağlaması için ortak bir alan olarak kullanılıyor. Bu yaklaşım, pipeline adımları arasında verilerin tutarlı bir şekilde iletilmesini sağlar ve gereksiz veri kopyalamaların önüne geçer.
• basic-auth: Git deposu gibi kaynaklara erişim için temel kimlik doğrulama bilgilerini içeriyor.
• certdir: SSL sertifikası gibi güvenlik dosyalarının saklandığı ve kullanıldığı yerdir.
• maven-settings: Maven için özel yapılandırma dosyalarını bulunduruyor.
• sonar-credentials: SonarQube bağlantısı için gerekli olan kimlik bilgilerini içeriyor.
• sonarcert: SonarQube sunucusu için özel SSL sertifikalarını içeriyor.
• dockerconfig: Quay tekton bağlantısı için robot hesabın bilgilerini içeriyor.
• quaycert: Quay için özel sertifikanın saklandığı workspace.

Bu pipeline’ı çalıştırmadan önce yapmanız gereken iki önemli işlem bulunuyor. İlk olarak, Quay üzerinde bir robot account oluşturulmalı ve bu hesabı kullanarak gerekli secret oluşturulmalıdır. İkinci olarak, SonarQube task’ında özel SSL sertifikasını geçebilmek için ilgili task üzerinde küçük bir değişiklik yapmamız gerekmektedir. Bu adımlar tamamlandığında pipeline’ı başarıyla çalıştırılabiliriz.

Robot hesabın oluşturulması

Quay arayüzüne giriş yaptıktan sonra kullanacağınız Şekil 3’de görüldüğü gibi imaj’ın repository’sinin organizasyon sayfası üzerinden yeni bir robot hesap oluşturuyoruz.

Bu hesap, pipeline’ın quay’ya imaj göndermesi için gereklidir. Robot hesabın repository üzerinde “write” yetkisine sahip olması gerektiğini unutmayın. Bu yetkiyi robot hesap ayarlarından düzenleyebilirsiniz. Robot hesap ayarları içerisinde bulunan “Credentials” bölümünden “Docker Configuration” seçeneğini seçerek robot hesap bilgilerini JSON formatında alıyoruz.

1
2
3
4
5
6
7
{
  "auths": {
    "<repo-adresi>": {
      "auth": "<token>",
      "email": ""
    }
  }

Bu JSON dosyasını Kubernetes secret olarak ekleyerek bağlantı bilgilerini kullanabilirsiniz.

1
2
3
4
5
6
7
8
#robot hesap secret örneği
kind: Secret
apiVersion: v1
metadata:
  name: quay-credentials
data:
  .dockerconfigjson: ewogI....
type: Opaque

PipelineRun ile Çalıştırma ve Genişletme

Artık oluşturduğunuz bu pipeline’ı bir PipelineRun tanımlayarak tekrar tekrar çalıştırabilirsiniz. Ayrıca, Tekton Hub üzerinden bulabileceğiniz yeni task’lar ile pipeline’ınızı genişletebilir ya da kendi özel task’larınızı oluşturabilirsiniz. Pipeline’ın mevcut task’larını düzenleyebilir, adımlar ekleyebilir ya da çıkarabilirsiniz. Bu esneklik sayesinde, adeta kendi CI/CD laboratuvarınızı kurarak iş akışlarınızı tam ihtiyaçlarınıza göre şekillendirebilirsiniz. Bazen sadece “Acaba şu task eklenince ne olur?” diye merak etmek bile yeni otomasyon fikirleri doğurabilir!

Sonuç

Yazımızda yer verdiğimiz gibi, Tekton ile CI/CD dünyasında kendi oyun alanınızı oluşturmanız mümkün! YAML dosyalarıyla donatılmış birer yazılım ustası gibi pipeline’ları ilmek ilmek örüyor, task’ları özelleştiriyor ve projelerimizi güvenle otomasyona teslim ediyoruz. Tekton’un modüler yapısı sayesinde her şey elimizin altında: İster bir task ekleyin, ister paralel çalışan task’larla iş akışınızı hızlandırın, ister sertifika doğrulamalarını dahil edin. Unutmayın, otomasyon dünyasında “Bunu daha iyi nasıl yaparım?” sorusu hep yeni kapılar açar. Bu rehberle artık Tekton yolculuğunuzda güçlü bir başlangıç yaptınız. Şimdi sıra sizde! Yeni task’lar deneyin ve projelerinizi daha akıllı hale getirin.

Yazımızın teknik gözden geçirmesi için Ayşegül ÖZKAYA EREN’e, editör desteği için ise Kübra ERTÜRK’e teşekkür ederiz.

Kaynakça

• [1] Tekton, “GitLab Interceptors,” Tekton Trigger Docs. [Çevrimiçi]: https://tekton.dev/docs/triggers/interceptors/#gitlab-interceptors (Erişim Zamanı: Aralık, 8, 2024).
• [2] Knative, “Knative Joins the CNCF,” Knative Blog. [Çevrimiçi]: https://knative.dev/blog/steering/knative-cncf-donation/ (Erişim Zamanı: Aralık, 8, 2024).
• [3] Tekton, “Tekton Task Documentation,” Tekton Task Docs. [Çevrimiçi]: https://hub.tekton.dev/tekton/task (Erişim Zamanı: Aralık, 8, 2024).
• [4] Tekton, “Tekton Pipeline Documentation,” Tekton Pipeline Docs. [Çevrimiçi]: https://tekton.dev/docs/pipelines/ (Erişim Zamanı: Aralık, 25, 2024).
• [5] Tekton, “Tekton PipelineRun Documentation,” Tekton PipelineRun Docs. [Çevrimiçi]: https://tekton.dev/docs/pipelines/pipelineruns/ (Erişim Zamanı: Aralık, 9, 2024).
• [6] Tekton, “Tekton Pipeline Workspaces,” Tekton Pipeline Workspaces Docs. [Çevrimiçi]: https://tekton.dev/docs/pipelines/workspaces/ (Erişim Zamanı: Aralık, 9, 2024).
• [7] Tekton, “Tekton Concept Model,” Tekton Concept Docs. [Çevrimiçi]: https://tekton.dev/docs/concepts/concept-model/ (Erişim Zamanı: Aralık, 9, 2024).
• [8] Tekton, “Tekton Hub SonarQube Scanner Task,” Tekton Hub Sonarqube. [Çevrimiçi]: https://hub.tekton.dev/tekton/task/sonarqube-scanner (Erişim Zamanı: Aralık, 8, 2024).