הקמת צינור CI/CD עם Tekton עבור Kubernetes

הגדרת Pipeline של Tekton CI/CD עבור Kubernetes

לעתים קרובות ראינו שתשתית CI/CD הופכת ל"קופסה שחורה": שירותי CI של ספקים לא מאפשרים ניהול תלות גמיש, ובנייה במצב הרשאות גבוהות (privilege mode) יוצרת פרצת אבטחה. במקרים כאלה, אנו מגדירים את Tekton — מסגרת עבודה (framework) ילידת Kubernetes שבה כל שלב ב-Pipeline הוא Pod נפרד והתצורה היא קובץ Kubernetes רגיל. במהלך השנים האחרונות, יישמנו את Tekton עבור יותר מ-15 צוותי פלטפורמה ועזרנו להם להיפטר מתלות בספק (vendor lock). לדוגמה, עבור פרויקט פינטק עם 40 מיקרוסרביסים, בנינו Pipeline של Tekton שהפחית את זמן הפריסה מ-25 ל-7 דקות — מהיר פי 3.5.

Tekton מספקת רמת שליטה ששירותי CI בענן לא יכולים להשתוות אליה. כל Task הוא Pod בודד, כל שלב הוא קונטיינר. ה-Pipeline מתואר כגרף משימות (DAG), המאפשר ביצוע מקבילי מפורש ותלות. הכל מנוהל באמצעות kubectl ונשמר ב-etcd — אין צורך במסדי נתונים נוספים. הודות לתלות מפורשת ב-DAG, Tekton מריצה משימות מקבילות פי 2–3 מהר יותר מ-GitLab CI או GitHub Actions, שבהן המקביליות מוגבלת על ידי רמות.

למה Tekton עבור צוות פלטפורמה?

Tekton היא כלי להנדסת פלטפורמות. צוות הפלטפורמה מגדיר אותה, ומפתחים משתמשים ב-Tasks מוכנים מהקטלוג. אם אין לכם צוות פלטפורמה ייעודי, העלות הנוספת של Tekton עשויה שלא להיות שווה את זה. GitHub Actions או GitLab CI יכסו את המשימה בפחות מאמץ.

השוו יכולות מפתח:

מודל CRD: Tasks, Pipelines, Triggers

Task — יחידת עבודה אטומית. קבוצה של Steps, כל אחד הוא קונטיינר.

---
apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: build-and-push
  namespace: tekton-pipelines
spec:
  params:
    - name: image-name
      type: string
    - name: image-tag
      type: string
    - name: context
      type: string
      default: "."
  workspaces:
    - name: source
      description: Source code workspace
  steps:
    - name: build
      image: gcr.io/kaniko-project/executor:v1.21.0
      args:
        - --dockerfile=$(workspaces.source.path)/Dockerfile
        - --context=$(workspaces.source.path)/$(params.context)
        - --destination=$(params.image-name):$(params.image-tag)
        - --cache=true
        - --cache-repo=$(params.image-name):cache
      env:
        - name: DOCKER_CONFIG
          value: /kaniko/.docker
      volumeMounts:
        - name: docker-config
          mountPath: /kaniko/.docker
  volumes:
    - name: docker-config
      secret:
        secretName: registry-credentials
        items:
          - key: .dockerconfigjson
            path: config.json

Kaniko במקום Docker-in-Docker הוא קריטי לאבטחה. אין קונטיינרים עם הרשאות גבוהות, בניית תמונות מתבצעת ללא Docker daemon. לדוגמה, בפרויקט סטארטאפ פינטק אחד, המעבר ל-Kaniko הפחית את הסיכון לדליפת אישורים וקיצר את זמן הבנייה ב-40%.

Pipeline מרכיב Tasks לגרף עם תלות:

---
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: ci-cd-pipeline
  namespace: tekton-pipelines
spec:
  params:
    - name: repo-url
      type: string
    - name: image-name
      type: string
    - name: git-revision
      type: string
  workspaces:
    - name: shared-workspace
    - name: git-credentials
  tasks:
    - name: clone
      taskRef:
        resolver: cluster
        params:
          - name: kind
            value: task
          - name: name
            value: git-clone
          - name: namespace
            value: tekton-pipelines
      params:
        - name: url
          value: $(params.repo-url)
        - name: revision
          value: $(params.git-revision)
      workspaces:
        - name: output
          workspace: shared-workspace
        - name: ssh-directory
          workspace: git-credentials
    - name: test
      runAfter: [clone]
      taskRef:
        name: run-tests
      workspaces:
        - name: source
          workspace: shared-workspace
    - name: security-scan
      runAfter: [clone]
      taskRef:
        name: trivy-scan
      params:
        - name: image-name
          value: $(params.image-name)
      workspaces:
        - name: source
          workspace: shared-workspace
    - name: build-push
      runAfter: [test, security-scan]
      taskRef:
        name: build-and-push
      params:
        - name: image-name
          value: $(params.image-name)
        - name: image-tag
          value: $(params.git-revision)
      workspaces:
        - name: source
          workspace: shared-workspace
    - name: deploy-staging
      runAfter: [build-push]
      taskRef:
        name: helm-deploy
      params:
        - name: namespace
          value: staging
        - name: image-tag
          value: $(params.git-revision)
---

apiVersion: tekton.dev/v1 kind: Task metadata: name: build-and-push namespace: tekton-pipelines spec: params: - name: image-name type: string - name: image-tag type: string - name: context type: string default: "." workspaces: - name: source description: Source code workspace steps: - name: build image: gcr.io/kaniko-project/executor:v1.21.0 args: - --dockerfile=$(workspaces.source.path)/Dockerfile - --context=$(workspaces.source.path)/$(params.context) - --destination=$(params.image-name):$(params.image-tag) - --cache=true - --cache-repo=$(params.image-name):cache env: - name: DOCKER_CONFIG value: /kaniko/.docker volumeMounts: - name: docker-config mountPath: /kaniko/.docker volumes: - name: docker-config secret: secretName: registry-credentials items: - key: .dockerconfigjson path: config.json ו-apiVersion: tekton.dev/v1 kind: Pipeline metadata: name: ci-cd-pipeline namespace: tekton-pipelines spec: params: - name: repo-url type: string - name: image-name type: string - name: git-revision type: string workspaces: - name: shared-workspace - name: git-credentials tasks: - name: clone taskRef: resolver: cluster params: - name: kind value: task - name: name value: git-clone - name: namespace value: tekton-pipelines params: - name: url value: $(params.repo-url) - name: revision value: $(params.git-revision) workspaces: - name: output workspace: shared-workspace - name: ssh-directory workspace: git-credentials - name: test runAfter: [clone] taskRef: name: run-tests workspaces: - name: source workspace: shared-workspace - name: security-scan runAfter: [clone] taskRef: name: trivy-scan params: - name: image-name value: $(params.image-name) workspaces: - name: source workspace: shared-workspace - name: build-push runAfter: [test, security-scan] taskRef: name: build-and-push params: - name: image-name value: $(params.image-name) - name: image-tag value: $(params.git-revision) workspaces: - name: source workspace: shared-workspace - name: deploy-staging runAfter: [build-push] taskRef: name: helm-deploy params: - name: namespace value: staging - name: image-tag value: $(params.git-revision) רצים במקביל (שניהם תלויים רק ב-test). security-scan ממתין לשניהם. זהו מודל תלות מפורש ב-DAG — בניגוד ל-GitHub Actions, שבו clone מציין רק את שם העבודה, לא את הסמנטיקה.

Tekton Triggers — ביצוע אוטומטי

Tekton Triggers מטפל באירועים נכנסים (Webhook של GitHub, Webhook של GitLab) ויוצר PipelineRun:

---
apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: github-listener
  namespace: tekton-pipelines
spec:
  serviceAccountName: tekton-triggers-sa
  triggers:
    - name: github-push
      interceptors:
        - ref:
            name: github
          params:
            - name: secretRef
              value:
                secretName: github-webhook-secret
                secretKey: secretToken
            - name: eventTypes
              value: [push]
      template:
        ref: pipeline-trigger-template
      bindings:
        - ref: github-push-binding

ה-EventListener נפרס כ-Service בתוך הקלאסטר. ה-Webhook של GitHub מצביע על build-push או needs של שירות זה. בכל Push, נוצר PipelineRun עם פרמטרים מה-Binding.

Tekton Chains — אבטחת שרשרת אספקה

Tekton Chains הוא הרחבה לחתימה אוטומטית על ארטיפקטים. לאחר כל TaskRun מוצלח, Chains יוצר הצהרת SLSA Provenance וחותם על התמונה באמצעות Cosign:

# Проверка подписи образа
cosign verify \
  --certificate-identity "https://tekton.dev/chains" \
  --certificate-oidc-issuer "https://accounts.google.com" \
  registry.example.com/myapp:abc123

עבור צוותים עם דרישות אבטחת שרשרת אספקה (SOC 2, SLSA level 2+), Tekton Chains מכסה זאת ישירות מהקופסה. — מתוך תיעוד Tekton Chains. כדי להעריך את הפרויקט שלכם, צרו קשר — נכין הצעה אישית.

תהליך שלב-אחר-שלב להגדרת Tekton CI/CD

1. ביקורת תשתית: ניתוח ה-Pipelines הקיימים, דרישות אבטחה, נפח בנייה מקבילית.
2. עיצוב: הגדרת קבוצת ה-Tasks, DAG של ה-Pipeline, ואינטגרציות (GitHub, GitLab, ArgoCD).
3. פריסה: התקנת Tekton Pipelines, Triggers, Dashboard באמצעות Helm או קבצי Manifest גולמיים.
4. פיתוח Tasks: כתיבת Tasks לשימוש חוזר (clone, test, security-scan, build, deploy).
5. אינטגרציה: הגדרת Triggers, חיבור Webhook, בדיקה מקצה לקצה.
6. פריסה לייצור: הוספת Tekton Chains לחתימה, הגדרת ניטור (Grafana, Prometheus).

מה כלול

• פריסת Tekton Pipelines + Triggers + Dashboard בקלאסטר
• פיתוח ספריית Tasks לשימוש חוזר
• הגדרת Triggers עבור Webhook של GitHub/GitLab
• אינטגרציה עם ArgoCD לחלק ה-CD (אופציונלי)
• הגדרת Tekton Chains לאבטחת שרשרת אספקה (לפי דרישה)
• תיעוד והדרכת צוות

איך Tekton פותרת את בעיית התלות בספק

בניגוד לשירותי CI בענן, כל התצורות של Tekton הן קבצי Kubernetes סטנדרטיים. ניתן לאחסן אותם ב-Git, לנהל גרסאות, ולהחיל אותם באמצעות GitOps. אין תלות ב-API של צד שלישי או בפורמטים קנייניים. זה חשוב במיוחד לחברות שצריכות להעביר Pipelines בין קלאסטרים או עננים.

שלבי עבודה

קבלו ייעוץ ממומחה — נבחן את התשתית שלכם ונציע פתרון. הזמינו הגדרת Tekton סוהר עם אחריות SLA.