Tekton CI، قسمت دوم، به اشتراک گذاری اطلاعات

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

اکنون، بیایید به کاوش در آن ادامه دهیم بلوک های ساختمانی تکتون همانطور که ما یک سفر کامل از توسعه به تولید.

💡 اول از همه

ما از kubectl CLI و علیرغم اینکه برای کار و تجسم اجزای Tekton به اندازه کافی خوب است، Tekton CLI خود را ارائه می دهد که کار را کمی آسان تر می کند:

$ tkn pipelinerun list

NAME                   STARTED          DURATION   STATUS
hello-pipeline-x2s8p   26 minutes ago   8s         Succeeded

حتی بهتر از آن، Tekton یک داشبورد رابط کاربری خوب ارائه می دهد تا بتوانیم تجربه کاربری بهتری داشته باشیم:

بخش خوب این است که ما می توانیم port-forward داشبورد از آنجایی که به لوکال هاست یک است service در Kubernetes علاوه بر این، ما می توانیم یک را مستقر کنیم Ingress و DNS خود را در محیط های تولید ایجاد کنیم.

برای من، این یک مزیت بزرگ است، زیرا من سیستم CI/CD خود را تحت DNS خودم دارم.

❤️ مسائل جامعه

از آنجایی که جامعه Tekton پذیرش و توسعه خود را بسیار جدی می گیرد، بسیاری از وظایف می توانند توسط انجمن مجددا استفاده شوند، بنابراین Tekton Hub ایجاد شد.

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

استفاده كردن kubectl:

$ kubectl apply -f https://raw.githubusercontent.com/tektoncd/catalog/main/task/git-clone/0.9/git-clone.yaml

یا به سادگی tkn:

tkn hub install task git-clone

جالب است، اما چگونه از این وظیفه استفاده کنیم؟

یک خط لوله ساده

خط لوله ما با دو وظیفه اصلی تعریف می شود:

• git clone (با استفاده از Task که از Tekton Hub وارد کردیم)
• فهرست فهرست پس از کلون، صدور یک مرده ساده ls فرمان

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: my-pipeline
spec:
  params:
  - name: repo-url
    type: string
  - name: revision
    type: string
  tasks:
  - name: fetch-source
    taskRef:
      name: git-clone
    params:
      - name: url
        value: $(params.repo-url)
      - name: revision
        value: $(params.revision)
  - name: list-source
    runAfter: ["fetch-source"]
    taskRef:
      name: list-source

• خطوط لوله و وظایف اجازه می دهد تا اعلام کنید پارامترها، که توسط ارسال می شوند Pipeline Runs که در زمان اجرا. در مورد ما، repo-url برای کلون کردن از و revision (تعهد یا شعبه)
• اولین وظیفه نامیده می شود fetch-source که اشاره به git-clone ما وارد کردیم
• وظیفه دوم بعد از آن اجرا می شود fetch-source و نامیده می شود list-source، که به Task دیگری به نام اشاره دارد list-source

بیایید Task را بررسی کنیم list-source:

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: list-source
spec:
  steps:
  - name: ls
    image: ubuntu
    script: >
      ls

این فقط یک Pod است که یک ubuntu ظرفی که صادر می کند ls فرمان خیلی ساده، اوه؟

Tasks باید اطلاعات را از طریق Volume به اشتراک بگذارد

اما یک نکته مهم را به خاطر بسپار: پادها به طور پیش فرض حجم ها را به اشتراک نمی گذارند. بنابراین، وظایف مختلف اطلاعات را به اشتراک نمی گذارند. به این معنی وظیفه list-source مخزن کلون شده را نمی بیند fetch-source وظیفه.

تکتون چگونه این مشکل را حل می کند؟ وارد فضاهای کاری.

📦 فضاهای کاری

فضاهای کاری در Tekton مشابه Volumes در Kubernetes و Docker هستند. ناهمسان وظایف می تواند فضاهای کاری را به اشتراک بگذارد تا داده ها از آن عبور کنند خط لوله.

با توجه به مستندات آن، git-clone کار حداقل به دو پارامتر نیاز دارد: الف آدرس اینترنتی برای واکشی مخزن و الف فضای کار تحت عنوان خروجی.

خط لوله/وظیفه معمولاً فضای کاری و در زمان اجرا (از طریق a Pipeline Run یا الف TaskRun) فضای کاری نصب شده است در Kubernetes

فضاهای کاری می توانند باشند ConfigMaps، Secrets، Persistent Volumes یا حتی یک حجم EmptyDir که وقتی دور ریخته می شود TaskRun کامل می شود.

📝 یادداشتی برای خالی کردن Dir

این نوع حجم فقط کار می کند از طریق مراحل درون یک Task، اما آنها در وظایف مختلف کار نمی کند در یک خط لوله برای Pipelines به جای آن از Persistent Volumes استفاده کنید.

بیایید خط لوله و تعاریف وظایف خود را تغییر دهیم. موارد زیر را به spec گره در خط لوله:

  ...
  workspaces:
    - name: shared-data

اساساً اعلام می کند که Pipeline از یک فضای کاری به نام استفاده می کند shared-data.

بعد، در tasks node، فضای کاری مورد نیاز وظیفه را اعلام کنید git-clone به شرح زیر است:

    ...
    workspaces:
      - name: output
        workspace: shared-data

نام فضای کاری وظیفه است output و به فضای کاری اشاره دارد shared-data در بخش خط لوله اعلام شده است.

مرحله قبل را برای list-source تعریف وظیفه، اما در این مورد، اجازه دهید فضای کاری وظیفه را به عنوان نامگذاری کنیم source، با اشاره به shared-data فضای کاری اعلام شده در خط لوله:

    ...
    workspaces:
      - name: source
        workspace: shared-data

و اکنون، در داخل Task list-source، باید فضای کاری را اعلام کنیم source که از طریق خط لوله خواهد آمد. بنابراین، Task yaml به شکل زیر است:

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: list-source
spec:
  workspaces:
    - name: source
  steps:
  - name: ls
    image: ubuntu
    workingDir: $(workspaces.source.path)
    script: >
      ls

🏃 زمان دویدن!

در حال حاضر، ما همه تغییرات را اعمال می کنیم، اما فقط اعلامیه، خط لوله و وظایف داریم. به منظور انجام یک Pipeline Run، باید نحوه کار خط لوله را اعلام کنیم shared-data شبیه خواهد شد.

در این مورد نمی توانیم استفاده کنیم emptyDir، به همین دلیل است که ما یک volumeClaimTemplate که از کلاس ذخیره سازی استاندارد پیکربندی شده در خوشه ما استفاده می کند، درخواست 1 گیگابایت فضا.

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName: my-pipeline-
spec:
  pipelineRef:
    name: my-pipeline
  params:
  - name: repo-url
    value: https://github.com/leandronsp/chespirito.git
  - name: revision
    value: main
  workspaces:
  - name: shared-data
    volumeClaimTemplate:
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi

• ارائه repo-url، که به مخزن اشاره می کند https://github.com/leandronsp/chespirito.git
• همچنین ارائه revision، بنابراین Task پرداخت را از شعبه اصلی انجام می دهد
• و حداقل، اما بسیار مهم، فضای کاری خط لوله shared-data، با استفاده از a volumeClaimTemplate

اجرای خط لوله و …

🚀 چقدر باحاله؟ 🚀

در این پست به این موضوع پرداختیم Tekton CLI، داشبورد و Tekton Hub، از یک خط لوله ساده عبور می کند که از Task ساخته شده توسط جامعه برای شبیه سازی یک مخزن دلخواه از Github و لیست کردن فایل های آن در صفحه استفاده می کند.

در طول سفر با این موضوع آشنا شدیم فضاهای کاری و چگونه آنها مشکل را حل می کنند به اشتراک گذاری اطلاعات از طریق مراحل و وظایف در یک خط لوله.

با ما همراه باشید زیرا پست های بعدی چگونگی انجام این کار را بررسی خواهند کرد به رویدادهای Github گوش دهید و خط لوله ما را فعال کنید به جای اجرای دستی