تغییرات اخیر

در اینجا اطلاعیه‌ها، نسخه‌ها و تغییرات جدید لیارا فهرست می‌شوند.

آنچه در این مقاله می‌خوانید

Tekton چیست + نحوه بهینه‌سازی CI/CD در کوبرنتیز


۱۰ اسفند ۱۴۰۴

خلاصه کنید:

openaigeminiperplexity

ساخت یک پایپ‌لاین CI/CD قدرتمند برای تیم توسعه نرم‌افزار امری ضروری است. Tekton یک فریم‌ورک متن‌باز و سازگار برای ایجاد خطوط CI/CD در بستر کوبرنتیز است. این فریمورک کاملاً بر پایه کوبرنتیز طراحی شده و برای تعریف و اجرای پایپ‌لاین‌ها از منابع سفارشی (CRD) استفاده می‌کند. برای استفاده از این ابزار، می‌توانید نسخه‌ای از آن را به‌طور مستقیم روی کلاستر فعلی کوبرنتیز خود دپلیوی کنید. در این مقاله از لیارا بررسی خواهیم کرد که Tekton چگونه می‌تواند نحوه کار تیم توسعه‌تان را متحول کند. تا پایان همراه ما باشید تا با مراحل راه‌اندازی یک پایپ‌لاین واقعی با Tekton آشنا شوید و ببینید چطور می‌توانید فرآیندهای Build، Deploy و Delivery را در محیط‌های کوبرنتیزی مدیریت کنید. ضمناً، اگر از آن دسته توسعه‌دهندگانی هستید که بعد از هر دیپلوی با دلهره منتظر لاگ‌ها می‌مانید، Tekton همکار دقیق و منظم شما در مسیر CI/CD خواهد شد:)

آنچه در این مقاله می‌خوانید:

  • Tekton چیست؟
  • مزایای استفاده از Tekton در DevOps
  • مقایسه Tekton با Jenkins و GitHub Actions
  • چه زمانی باید از Tekton استفاده کنیم؟
  • ساخت یک پایپ‌لاین CI/CD ساده با Tekton
  • جمع‌بندی
  • سوالات متداول
Tekton چیست
برای آشنایی کامل با دواپس (DevOps) و اهمیت آن، مقاله زیرا می‌توانید مطالعه کنید.
دواپس (DevOps) چیست؟

Tekton چیست؟

Tekton یک راه‌حل Cloud-Native کاملاً مبتنی بر کوبرنتیز است. این ابزار با استفاده از مفاهیم اصلی کوبرنتیز مثل کانتینرها و پیکربندی‌های YAML، یک تجربه ماژولار، مقیاس‌پذیر و امن برای خودکارسازی فرایند توسعه نرم‌افزار در اختیار تیم‌های DevOps قرار می‌دهد.

ابزار Tekton از چند بخش اصلی تشکیل شده است:

  • Pipeline: تعریف کلی مراحل اجرای CI/CD.
  • Task: واحدهای کاری کوچکتر که هر کدام یک مرحله از پایپ‌لاین را انجام می‌دهند. (مثلاً build یا test).
  • Step: دستورات جزئی داخل هر Task که در قالب کانتینر اجرا می‌شود.
  • PipelineRun و TaskRun: نمونه‌های اجرایی از Pipeline و Task
  • Resource: تعریف ورودی/خروجی‌های پایپ‌لاین، مانند ریپازیتوری کد یا ایمیج داکر.
  • Triggers: برای شروع خودکار Pipelineها بر اساس رویدادهایی مانند push به گیت.

تمام این بخش‌ها روی کوبرنتیز تعریف شده‌اند.

مزایای استفاده از Tekton در DevOps

مزایای استفاده از Tekton در تیم‌های DevOps عبارتنداز:

  • یکپارچگی کامل با کوبرنتیز: Tekton بیشتر برای کار در محیط کوبرنتیز توسعه داده شده است. این یعنی می‌توانید پایپ‌لاین‌های CI/CD خود را کاملاً به‌صورت native در دل کلاستر کوبرنتیز مدیریت کنید.
  • مقیاس‌پذیری بالا: چه در پروژه‌های کوچک و چه در مقیاس‌های بزرگ، Tekton می‌تواند با حجم کاری شما رشد کند.
  • انعطاف‌پذیری و امکان سفارشی‌سازی: با استفاده از Taskها در Tekton، این امکان را دارید که مراحل مختلف پایپ‌لاین را متناسب با نیازهای پروژه خود طراحی و سفارشی کنید.
  • قابلیت اتصال به سایر ابزارها: Tekton به‌راحتی با ابزارهای محبوب CI/CD مانند Jenkins، GitLab و بسیاری دیگر ادغام می‌شود.
  • امنیت بالا: هر مرحله از اجرای پایپ‌لاین در Tekton در یک کانتینر جداگانه انجام می‌شود که این ساختار، امنیت و ایزوله‌سازی فرایندها را به‌شکل قابل‌توجهی افزایش می‌دهد.
  • پشتیبانی توسط جامعه متن‌باز: پشت Tekton یک جامعه بزرگ و فعال از توسعه‌دهندگان و تیم‌های DevOps قرار دارد که دائماً در حال بهبود و گسترش این پروژه هستند.
برای آشنایی کامل با کوبرنتیز (Kubernetes) و چگونگی کارکرد آن، مقاله زیر را از دست ندهید.
کوبرنتیز (Kubernetes) چیست؟

مقایسه Tekton با Jenkins و GitHub Actions

زمانی که صحبت پیاده‌سازی CI/CD روی کوبرنتیز می‌شود، بسیاری از ابزارهای قدیمی مانند Jenkins دیگر پاسخگوی نیازهای جدید نیستند و انعطاف کافی برای مدیریت منابع Cloud-Native را ندارند. در مقابل ابزار، Tekton به‌طور خاص برای کوبرنتیز طراحی شده و در مقایسه با GitHub Actions و Jenkins، کنترل دقیق‌تری روی اجرای Pipelineها دارد. در جدول زیر مقایسه این سه ابزار را به‌صورت خلاصه مشاهده می‌کنید.

ویژگی / ابزارJenkinsGitHub ActionsTekton
مختص Kubernetes❌✅
(در GitHub)		✅
کاملاً بومی
پیاده‌سازی Pipeline با YAML❌ ✅✅
سطح کنترل بر اجرای Jobمتوسطکمبسیار بالا (با Pod و CRD)
مقیاس‌پذیریکمخوببسیار بالا
ادغام با GitOps❌محدود✅
عالی (با ArgoCD و Flux)
سادگی در استفادهمتوسطخوبعالی (با مستندات جامع)
پشتیبانی از زبان‌های مختلفمحدودخوببسیار زیاد (با Taskهای سفارشی)
اگر به‌دنبال شناخت تفاوت‌های Ansible و Jenkins هستید، مقاله زیر را از دست ندهید.
تفاوت‌های Ansible و Jenkins

چه زمانی باید از Tekton استفاده کنیم؟

اگر تیم شما در حال استفاده از Kubernetes است و می‌خواهید یک ابزار CI/CD مناسب داشته باشید، به موارد زیر توجه کنید.

  • زمانی که زیرساخت شما روی کوبرنتیز قرار دارد و می‌خواهید تمام فرایندهای CI/CD خود را در همان محیط مدیریت کنید.
  • اگر امنیت و ایزوله‌سازی برایتان در اولویت است. زیرا هر پایپ‌لاین در یک کانتینر مجزا اجرا می‌شود.
  • اگر در حال پیاده‌سازی GitOps هستید؛ زیرا Tekton به‌طور کامل از GitOps پشتیبانی می‌کند.
  • در صورتی که به مدیریت بارکاری نیاز دارید، Tekton از افزایش حجم بار به‌طور کامل پشتیبانی می‌کند.
  • اگر به دنبال فرایندهای خودکارسازی کاملا قابل تنظیم هستید؛ Tekton پایپ‌لاین‌ها را با فایل YAML تعریف می‌کند و می‌توانید هر مرحله از فرآیند CI/CD را به دلخواه تنظیم کنید.
برای آموزش کامل ساخت و اجرای اولین Playbook در Ansible مقاله زیر را مطالعه کنید.
ساخت Playbook در Ansible

ساخت یک پایپ‌لاین CI/CD ساده با Tekton

در این بخش اجازه بدهید، قدرت ابزار Tekton را با ساخت یک پایپ‌لاین ساده CI/CD برای یک اپلیکیشن Node.js به شما نشان دهیم، در ادامه همراه ما باشید.

پیش‌نیازها

  • کلاستر Kubernetes: برای اجرای Tekton و پایپ‌لاین‌ها، شما به یک کلاستر Kubernetes نیاز دارید. اگر می‌خواهید روی سرور خودتان به‌صورت محلی تست کنید، می‌توانید از ابزار Minikube استفاده کنید، که این ابزار یک کلاستر Kubernetes روی سرور شما راه‌اندازی می‌کند.
  • نصب Tekton: برای شروع به‌کار با Tekton، ابتدا باید Tekton را روی کلاستر خود نصب کنید. برای این‌کار بهتر است راهنمای رسمی آن از طریق لینک راهنمای نصب Tekton دنبال کنید.
  • اپلیکیشن Node.js: شما باید یک اپلیکیشن Node.js آماده روی سرور خود داشته باشید. همچنین می‌توانید یک اپلیکیشن ساده ایجاد کنید. نکته مهم این‌است که برنامه شما باید یک Dockerfile داشته باشد. این فایل به Tekton کمک می‌کند که اپلیکیشن شما را در قالب یک کانتینر بسته‌بندی کرده و آن را برای استقرار روی Kubernetes آماده کند.
  • Docker Registry: در نهایت به یک Docker Registry نیاز دارید تا ایمیج Docker اپلیکیشن‌تان را ذخیره کند. برای این مورد از Docker Hub می‌توانید استفاده کنید. در این Registryها ایمیج کانتینری که برای اپلیکیشن شما ساخته می‌شود را نگهداری می‌کند.
  • ریپازیتوری GitHub: کد برنامه و فایل‌های مربوط به Tekton pipeline را باید در یک ریپازیتوری GitHub ذخیره کنید. در اینجا تمام کدها و پایپ‌لاین‌های Tekton ذخیره می‌شوند و Tekton به‌طور خودکار از این ریپازیتوری برای اجرای عملیات CI/CD استفاده می‌کند.

گام اول: ایجاد Task برای ساخت و ارسال ایمیج داکر

در این مرحله، یک Task با نام build-push تعریف می‌کنیم که مسئول ساخت ایمیج Docker از اپلیکیشن و ارسال آن به رجیستری است. برای این کار از ابزار Kaniko استفاده می‌شود که بدون نیاز به دسترسی مستقیم به Docker Daemon می‌تواند در محیط‌های Kubernetes ایمیج بسازد و Push کند.

ابتدا فایل زیر را با نام build-push.yaml ذخیره کنید:

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: build-push
spec:
  params:
    - name: IMAGE
      type: string
      description: Name (reference) of the image to build.
    - name: DOCKERFILE
      type: string
      description: Path to the Dockerfile to build.
      default: ./Dockerfile
    - name: CONTEXT
      type: string
      description: The build context used by Kaniko.
      default: ./
  steps:
    - name: build-and-push
      image: gcr.io/kaniko-project/executor:v1.6.0
      env:
        - name: DOCKER_CONFIG
          value: /tekton/home/.docker
      command:
        - /kaniko/executor
      args:
        - --dockerfile=$(params.DOCKERFILE)
        - --destination=$(params.IMAGE)
        - --context=$(workspaces.source.path)/$(params.CONTEXT)
        - --oci-layout-path=$(workspaces.source.path)/image-digest
        - --insecure
        - --skip-tls-verify
      securityContext:
        runAsUser: 0
  workspaces:
    - name: source

Task بالا با استفاده از ایمیج رسمی Kaniko، پروژه‌ی شما را در محیط Kubernetes به یک ایمیج Docker تبدیل می‌کند و آن را به رجیستری مشخص‌ شده Push می‌کند.

توضیح بخش‌های مختلف:

  • kind: Task: یک واحد کاری قابل استفاده مجدد در Tekton را تعریف می‌کند.
  • metadata.name: build-push: نامی توصیفی به Task اختصاص می‌دهد.
  • spec.params: پارامترهای ورودی برای Task را تعریف می‌کند.
    • IMAGE: مسیر کامل ایمیج Docker (مثلاً your-dockerhub-username/your-app:latest).
    • DOCKERFILE: مسیر فایل Dockerfile در ریپازیتوری (پیش‌فرض ./Dockerfile).
    • CONTEXT: کانتکست ساخت برای Kaniko که معمولاً شامل کد اپلیکیشن است.
  • spec.steps: مراحلی که درون Task اجرا می‌شوند را فهرست می‌کند.
    • در این‌جا، از ایمیج kaniko برای ساخت داخل کانتینر استفاده می‌شود. این ایمیج، فایل Dockerfile را دریافت کرده، ایمیج را می‌سازد و به رجیستری مشخص‌شده ارسال می‌کند.
  • spec.workspaces: مشخص می‌کند که Task چگونه با ولوم‌ها یا دایرکتوری‌ها تعامل دارد.
    • workspace با نام source برای فراهم کردن دسترسی به کد، mount می‌شود.

برای اجرای این Task در کلاستر Kubernetes، ابتدا فایل بالا را در مسیر پروژه (مثلاً tekton/tasks/build-push.yaml) ذخیره کنید و بعد از آن دستور زیر را اجرا کنید:

kubectl apply -f tekton/tasks/build-push.yaml

با اجرای این کد، Task در کلاستر ثبت می‌شود و می‌توانید از آن در یک Pipeline یا TaskRun استفاده کنید.

اگر می‌خواهید با نحوه راه‌اندازی Docker Compose از طریق Ansible در اوبونتو، آشنا شوید، مقاله زیر را از دست ندهید.
راه‌اندازی Docker Compose با Ansible

گام دوم: ایجاد Task برای دیپلوی کردن اپلیکیشن با kubectl

در این مرحله، یک Task با نام kubectl-deploy تعریف می‌کنیم که وظیفه‌اش به‌روزرسانی فایل Kubernetes با ایمیج جدید و اجرای دستور kubectl برای اعمال تغییرات است.

این مرحله بعد از ساخته شدن ایمیج Docker اجرا می‌شود تا اپلیکیشن با نسخه جدید در کلاستر مستقر شود.

فایل زیر را با نام kubectl-deploy.yaml ذخیره کنید:

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: kubectl-deploy
spec:
  params:
    - name: MANIFEST_PATH
      type: string
      description: Path to the manifest to apply
    - name: YAML_PATH_TO_IMAGE 
      type: string
      description: The path to the image to replace in the yaml manifest (arg to yq)
    - name: IMAGE 
      type: string
      description: The name of the image that was built 
    - name: ACTION
      type: string
      description: The action to perform with kubectl
      default: "apply"
  steps:
    - name: replace-image
      image: mikefarah/yq
      workingDir: $(workspaces.source.path)
      script: |
        yq w -i $(params.MANIFEST_PATH) "$(params.YAML_PATH_TO_IMAGE)" $(params.IMAGE) 
    - name: run-kubectl 
      image: lachlanevenson/k8s-kubectl
      workingDir: $(workspaces.source.path)
      script: |
        kubectl $(params.ACTION) -f $(params.MANIFEST_PATH)
  workspaces:
    - name: source
  results:
    - name: IMAGE 
      description: The name of the image that was built

بعد از ساخت این فایل، آن را با دستور زیر در کلاستر Kubernetes خود اجرا کنید:

kubectl apply -f tekton/tasks/kubectl-deploy.yaml

نکته: حتماً قبل از اجرای Task، مطمئن شوید که فایل مانیفست (مثل deployment.yaml) در مسیر مورد نظر موجود است و به‌درستی مسیر فیلد image را در آن مشخص کرده‌اید.

توضیح بخش‌های مختلف:

  • kind: Task: مشخص می‌کند که این یک Task مجدد می‌تواند استفاده شود.
  • metadata.name: kubectl-deploy: نام این Task را برابر با kubectl-deploy قرار می‌دهد.
  • spec.params: پارامترهای ورودی را تعریف می‌کند:
    • MANIFEST_PATH: مسیر فایل مانیفست Kubernetes (مثلاً deployment.yaml).
    • YAML_PATH_TO_IMAGE: مسیر فیلد مربوط به نام ایمیج Docker در فایل مانیفست (مثلاً spec.template.spec.containers[0].image).
    • IMAGE: نام ایمیجی که باید دیپلوی شود (معمولاً از Task قبلی دریافت می‌شود).
    • ACTION: عملیاتی که باید با kubectl انجام شود (پیش‌فرض apply است).
  • spec.steps:
    • از ایمیج mikefarah/yq برای به‌روزرسانی داینامیک نام ایمیج در فایل مانیفست Kubernetes استفاده می‌کند.
    • از ایمیج lachlanevenson/k8s-kubectl برای ارتباط با کلاستر Kubernetes و دیپلوی کردن اپلیکیشن استفاده می‌کند.
  • spec.workspaces: از workspace با نام source برای دسترسی به فایل مانیفست استفاده می‌شود.
برای آشنایی با انسیبل (Ansible) و کاربردهای آن، مقاله زیر را بخوانید.
انسیبل (Ansible) چیست؟

گام سوم: ایجاد Pipeline

در این گام، ما پایپ‌لاین را ایجاد می‌کنیم که اجرای مراحل مختلف از جمله مراحل build و deployment را هماهنگ می‌کند.

برای ایجاد پایپ‌لاین، فایل زیر را با نام pipeline.yaml ذخیره کنید:

apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: my-git-repo 
spec:
  type: git
  params:
    - name: url
      value: $(params.git-url) 
    - name: revision
      value: $(params.git-revision)
---
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: my-app-image 
spec:
  type: image
  params:
    - name: url 
      value: $(params.image-name)

توضیح بخش‌های مختلف:

  • kind: Pipeline: مشخص می‌کند که این یک پایپ‌لاین CI/CD است.
  • metadata.name: tekton-pipeline: به پایپ‌لاین شما یک نام می‌دهد.
  • spec.params: پارامترهای مربوط به کل پایپ‌لاین:
    • git-url: آدرس ریپازیتوری Git شما.
    • git-revision: شاخه یا تگی که باید استفاده شود (پیش‌فرض: main).
    • image-name: نام کامل ایمیج Docker.
  • spec.resources: منابعی که پایپ‌لاین از آن‌ها استفاده می‌کند:
    • source-repo: یک منبع Git برای گرفتن کد از ریپازیتوری شما.
    • built-image: یک منبع ایمیج برای ذخیره ایمیج ساخته شده.
  • spec.tasks: تعریف کارهایی که باید اجرا شوند و ترتیب آن‌ها:
    • fetch-and-build: کار build-push را اجرا می‌کند.
      • کد منبع را از source-repo می‌گیرد و ایمیج ساخته شده را به built-image می‌دهد.
    • deploy-to-cluster: کار kubectl-deploy را اجرا می‌کند.
      • ایمیج ساخته شده را به‌عنوان ورودی می‌گیرد و از طریق فایل منیفست آن را استقرار می‌دهد.

در این گام، به طور کلی، شما پایپ‌لاین را برای اجرای خودکار فرآیندهای build و deployment تنظیم کردید.

آموزش جامع کار با کانتینرهای داکر (ساخت + مدیریت و حذف کانتینرها) را در مقاله زیر مطالعه کنید.
نحوه کار با کانتینرها

گام چهارم: تعریف منابع پایپ‌لاین

در این مرحله باید، منابع مورد نیاز Pipeline خود را تعریف کنید. این منابع بخش‌هایی هستند که پایپ‌لاین برای انجام کارهای خود به آن‌ها نیاز دارد. شامل کد منبع، تصاویر Docker، یا دیگر داده‌هایی باشند که در طول فرآیند CI/CD استفاده می‌شوند.

برای تعریف منابع پایپ‌لاین، فایل زیر را با نام pipeline-resource.yaml ذخیره کنید:

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: tekton-run
spec:
  pipelineRef:
    name: tekton
  serviceAccountName: tekton-sa
  resources:
    - name: source-repo
      resourceRef:
        name: tekton-demo-git
    - name: image
      resourceRef:
        name: tekton-demo-image
  params:
    - name: git-url
      value: https://github.com/username/tekton-demo.git
    - name: git-revision
      value: main
    - name: image-name
      value: docker.io/username/tekton-demo:latest

توضیح بخش‌های مختلف:

  • kind: PipelineResource: مشخص می‌کند که این یک منبع مورد استفاده در پایپ‌لاین است.
  • metadata.name: نام منبع را تعیین می‌کند (مثل my-git-repo و my-app-image).
  • spec.type: git: نوع منبع را به‌عنوان یک ریپازیتوری Git مشخص می‌کند.
  • spec.params: پارامترهای مربوط به منبع Git را تعریف می‌کند (مثل URL و revision).
  • spec.type: image: نوع منبع را به‌عنوان یک ایمیج Docker مشخص می‌کند.
  • spec.params: آدرس ایمیج Docker را تعیین می‌کند.

در واقع، این منابع به پایپ‌لاین اجازه می‌دهند تا به ایمیج‌های Docker دسترسی پیدا کرده و آن‌ها را در فرآیند CI/CD استفاده کند.

گام پنجم: اجرای پایپ‌لاین

تا اینجای کار، تمام اجزای لازم برای اجرای یک CI/CD Pipeline با Tekton را آماده کردید؛ از تعریف تسک‌ها گرفته تا منابع و خود پایپ‌لاین. حالا وقت آن است که این پایپ‌لاین شروع به کار کند.

برای اجرای پایپ‌لاین، فایل زیر را با نام pipeline-run.yaml ذخیره کنید:

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: my-pipeline-run
spec:
  pipelineRef:
    name: tekton-pipeline 
  serviceAccountName: tekton-sa  
  resources:
    - name: source-repo 
      resourceRef:
        name: my-git-repo 
    - name: built-image 
      resourceRef:
        name: my-app-image
  params:
    - name: git-url 
      value: https://github.com/your-username/your-repo.git 
    - name: git-revision 
      value: main  
    - name: image-name 
      value: your-dockerhub-username/your-app:latest

توضیح بخش‌های مختلف:

  • kind: PipelineRun: نوع منبع را مشخص می‌کند که در اینجا یک اجرای Pipeline است.
  • metadata.name: my-pipeline-run: نام مشخصی برای این اجرای خاص از Pipeline تعیین می‌کند.
  • spec.pipelineRef: به Pipeline اصلی که باید اجرا شود اشاره دارد.
  • spec.serviceAccountName: tekton-sa: یک ServiceAccount مشخص می‌کند که دسترسی لازم به خوشه کوبرنتیز و در صورت نیاز به رجیستری Docker را دارد. در صورت عدم وجود، باید این حساب کاربری به‌صورت جداگانه ایجاد شود.
  • spec.resources: منابع تعریف‌شده در Pipeline را به نمونه‌های واقعی آن‌ها متصل می‌کند:
  • source-repo به منبع Git تحت عنوان my-git-repo متصل می‌شود.
  • built-image به منبع ایمیج my-app-image ارجاع داده می‌شود.
  • spec.params: مقادیر واقعی برای پارامترهای Pipeline را مشخص می‌کند. این مقادیر شامل آدرس ریپازیتوری Git، نام شاخه (مثلاً main) و مسیر کامل ایمیج Docker است.

به طور خلاصه، در این مرحله کل فرآیند، CI/CD وارد فاز اجرا می‌شود. با تعریف PipelineRun، به Tekton می‌گویید که پایپ‌لاین را با این منابع و پارامترها راه بیانداز و تمام تسک‌ها را به ترتیب و طبق وابستگی‌ها اجرا کند.

نکته مهم این است که پیش از اجرای Pipeline، مقادیر پیش‌فرض را باید با اطلاعات واقعی پروژه جایگزین کنید.

گام ششم: اعمال پیکربندی‌ها

در نهایت، حالا که پایپ‌لاین Tekton خود را در فایل‌های YAML تعریف کرده‌اید، باید آن‌را به کلاستر Kubernetes خود منتقل کنید. در این مرحله کوبرنتیز، وظیفه اجرا و اعمال پیکربندی شما را دارد و این تنظیمات را به یک پایپ‌لاین در حال اجرا تبدیل می‌کند.

برای این‌کار، ترمینال خود را باز کنید، به دایرکتوری‌ای که فایل‌های YAML شما در آن قرار دارند بروید و دستور زیر را اجرا کنید:

kubectl apply -f build-push.yaml -f kubectl-deploy.yaml -f pipeline.yaml -f pipeline-resource.yaml -f pipeline-run.yaml

دستور بالا، فایل‌های مختلف را به Kubernetes معرفی می‌کند تا پایپ‌لاین Tekton شما اجرا شود و فرآیند خودکارسازی CI/CD شما شروع شود.

فرآیندهای اجرای Tekton در Kubernetes

ایجاد منابع Kubernetes: کوبرنتیز هر فایل YAML را خوانده و نوع شیء مشخص شده (مانند Task، Pipeline، PipelineResource، PipelineRun) را شناسایی کرده و منابع مربوطه را در کلاستر ایجاد می‌کند. این سیستم به خوبی روابط وابستگی میان این منابع را درک می‌کند. به عنوان مثال، می‌داند که برای اجرای یک PipelineRun نیاز به یک Pipeline است و یک Pipeline به Tasks و PipelineResources وابسته است. این فرآیند به طور خودکار تنظیمات مختلف را برای اجرای بهینه هر مرحله از Pipeline مدیریت می‌کند.

زمان‌بندی و ارکستراسیون کانتینرها: Kubernetes زمان‌بندی اجرای پایپ‌لاین Tekton را انجام می‌دهد و تعیین می‌کند که کدام گره‌ها در کلاستر منابع لازم برای اجرای مراحل کانتینری شده در داخل Tasks را دارند. این سیستم همچنین چرخه زندگی Pods را که کوچک‌ترین واحدهای قابل استقرار در Kubernetes هستند، مدیریت می‌کند و تضمین می‌کند که آن‌ها منابع مورد نیاز را دریافت کنند و تا تکمیل یا بروز خطا ادامه یابند.

اجرای پایپ‌لاین: با آماده شدن همه‌چیز، Tekton مسئولیت ارکستراسیون اجرای پایپ‌لاین را به عهده می‌گیرد. این سیستم کد شما را از ریپازیتوری Git مشخص شده بارگیری می‌کند، ایمیج Docker را با استفاده از Kaniko می‌سازد، تگ ایمیج جدید را در مانفیست دپلویمنت به‌روزرسانی می‌کند و سپس تغییرات را با استفاده از kubectl به کلاستر اعمال می‌کند تا در نهایت اپلیکیشن به‌روزشده شما را دیپلوی کند.

اگر به‌دنبال آموزش کامل راه‌اندازی اولیه سرور مجازی با اوبونتو Ubuntu هستید، می‌توانید مقاله زیر را بخوانید.
راه‌اندازی سرور مجازی با اوبونتو

گام هفتم: نظارت و تائید عملکرد پایپ‌لاین

در آخر، بعد از اعمال تغییرات، نیاز است که به‌دقت اجرای پایپ‌لاین خود را نظارت کرده و موفقیت آن را با روش‌های زیر تایید کنید:

مانیتورینگ لحظه‌ای اجرای پایپ‌لاین با tkn CLI:

برای اینکه اجرای پایپ‌لاین Tekton را به‌صورت زنده دنبال کنید، می‌توانید از ابزار tkn استفاده کنید:

tkn pipelinerun logs my-pipeline-run -f

این دستور لاگ تمام مراحل اجرای پایپ‌لاین را به‌صورت لحظه‌ای نمایش می‌دهد. این لاگ‌ها اطلاعات بسیار مفیدی در مورد روند Build، خطاهای احتمالی و وضعیت کلی اجرای پایپ‌لاین به شما می‌دهند.

علاوه بر مشاهده لاگ‌ها، با استفاده از همین ابزار می‌توانید پایپ‌لاین اجراشده و منابع مرتبط با آن را مدیریت کنید:

tkn pipelinerun list              
tkn pipelinerun describe my-pipeline-run    
tkn pipelinerun delete my-pipeline-run

این ابزار به شما کمک می‌کند کنترل دقیق‌تری روی روند CI/CD داشته باشید و در صورت نیاز سریع‌تر واکنش نشان دهید.

تأیید موفقیت‌آمیز بودن استقرار اپلیکیشن

پس از آن‌که پایپ‌لاین با موفقیت اجرا شد، نوبت به بررسی وضعیت نهایی اپلیکیشن می‌رسد. یکی از روش‌های کلیدی برای اطمینان از اجرای صحیح اپلیکیشن، مشاهده لاگ‌ها در کلاستر Kubernetes است.

بررسی لاگ‌های اپلیکیشن: وارد کلاستر کوبرنتیز شوید و با استفاده از دستور kubectl logs، لاگ‌های مرتبط با استقرار یا پاد اپلیکیشن‌تان را بررسی کنید. با این کار متوجه می‌شوید که آیا اپلیکیشن بدون مشکل اجرا شده و درخواست‌ها را به درستی پاسخ می‌دهد یا خیر.

kubectl logs -l app=<your-app-name> -f

این مرحله برای اطمینان از سلامت نهایی سرویس پس از استقرار بسیار حیاتی است، به‌خصوص برای محیط‌هایی که پرمخاطب یا حساسیت بالایی دارند.

اعتبارسنجی نهایی در کوبرنتیز

برای این‌که مطمئن شوید، نسخه جدید اپلیکیشن به‌درستی در دسترس قرار گرفته و تغییرات اعمال‌شده به‌درستی کار می‌کنند، باید عملکرد نهایی را با روش‌های زیر بررسی کنید:

دسترسی به سرویس از طریق Endpoint: ابتدا با استفاده از دستور زیر، آدرس سرویس (Service Endpoint) را به‌دست آورید:

kubectl get service

برای اطمینان از عملکرد صحیح اپلیکیشن، می‌توانید آدرس سرویس را در مرورگر یا ابزارهای تست API مانند Postman باز کرده و قابلیت‌های کلیدی آن را بررسی کنید.

با این کار، مطمئن می‌شوید که تغییرات جدید به‌درستی اعمال شده‌اند و سیستم بدون خطا پاسخ می‌دهد.

بررسی Health Checkها: یا اگر برای اپلیکیشن‌تان Health Check تعریف کرده‌اید، بررسی کنید که وضعیت آن‌ها سبز و موفق باشد. عبور از Health Check‌ها نشان‌دهنده‌ی آن است که استقرار به‌درستی انجام شده و اپلیکیشن‌تان در وضعیت پایدار قرار دارد.

با ثبت‌نام در لیارا، ۱۰۰ هزار تومان اعتبار هدیه بگیرید و از سرور مجازی رایگان با کیفیت بالا و امکانات عالی استفاده کنید!
پشتیبانی ۲۴ ساعته برای کاربران سرور مجازی رایگان!
خرید سرور مجازی رایگان

جمع‌بندی

Tekton این فرصت را به شما می‌دهد تا پایپ‌لاین‌های CI/CD قدرتمند و انعطاف‌پذیر بسازید که به‌طور یکپارچه با گردش‌کارهای موجود در Kubernetes شما ادغام شود. با استفاده از Tekton و قابلیت‌های پیشرفته‌اش، می‌توانید فرآیند توسعه و تحویل نرم‌افزار را بهینه کنید و از حداکثر پتانسیل تیم DevOps خود استفاده کنید. در این مطلب، نحوه ساخت و پیکربندی پایپ‌لاین‌های CI/CD با Tekton در Kubernetes را بررسی کردیم. از ایجاد منابع، تنظیمات و اجرای پایپ‌لاین گرفته تا نظارت بر اجرای آن و اعتبارسنجی صحت عملکرد اپلیکیشن پس از استقرار را آموزش دادیم:)

برای آشنایی با نحوه استفاده از اسکن آسیب‌ پذیری در Kubescape، مقاله زیر را مطالعه کنید.
نحوه استفاده از اسکن آسیب‌ پذیری در Kubescape

سوالات متداول

Tekton رابط گرافیگی (UI) دارد؟

بله، Tekton دارای رابط کاربری گرافیگی به نام Tekton Dashboard است که می‌توانید نظارت پایپ‌لاین‌ها را به‌صورت بصری انجام دهید.

آیا Tekton فقط روی Kubernetes اجرا می‌شود؟

بله، Tekton به طور خاص برای کار در محیط Kubernetes طراحی شده و خارج از کوبرنتیز قابل دسترسی نیست.

آیا می‌توان از Tekton در کنار GitLab یا GitHub استفاده کرد؟

بله، شما می‌توانید Tekton Pipelineها را به‌گونه‌ای تنظیم کنید که با Webhookهای GitLab یا GitHub فعال شوند. به‌عبارتی دیگر، Tekton می‌تواند با هر سیستمی که امکان ارسال webhook را داشته باشد، یکپارچه شده و فرآیندهای CI/CD را به‌طور خودکار اجرا کند.

آیا Tekton با دیگر ابزارهای CI/CD مانند Jenkins قابل مقایسه است؟

بله، Tekton مشابه Jenkins برای مدیریت پایپ‌لاین‌ها است، اما Tekton به‌طور کامل در داخل Kubernetes اجرا می‌شود و با سایر ابزارهای بومی Kubernetes به‌راحتی یکپارچه می‌شود.


به اشتراک بگذارید