بهینه سازی عملکرد GitHub Actions: افزایش گردش کار با ذخیره سازی

این مقاله به مجموعه من در GitHub Actions ادامه می دهد. در این مقاله به شما نشان خواهم داد که چگونه با استفاده از کش کردن، زمان اجرای گردش کار GitHub Actions خود را بهبود ببخشید.

می توانید مقالات قبلی من در مورد اقدامات GitHub را بخوانید:

معرفی

GitHub Actions یک ابزار قدرتمند برای CI/CD است. این برای مخازن عمومی رایگان است و دارای یک ردیف رایگان سخاوتمندانه برای مخازن خصوصی است. با این حال، لایه آزاد دارای محدودیت هایی است. یکی از آنها محدودیت زمانی اجراست. به عنوان مثال، سطح رایگان برای مخازن خصوصی دارای محدودیت 2000 دقیقه در ماه است. این برای اکثر پروژه ها بیش از اندازه کافی است، اما اگر یک پروژه بزرگ با آزمایش های زیاد دارید، می توانید به راحتی به این محدودیت برسید. در این مقاله به شما نشان خواهم داد که چگونه با استفاده از کش کردن، زمان اجرای گردش کار GitHub Actions خود را بهبود ببخشید.

ذخیره سازی در GitHub Actions به شما امکان می دهد فایل ها یا وابستگی های خاصی را بین اجراهای گردش کار ذخیره و مجدداً استفاده کنید. با ذخیره کردن این مصنوعات، می توانید از محاسبات اضافی اجتناب کنید و زمان لازم برای کارهایی مانند نصب وابستگی ها، ساخت بسته ها یا کامپایل کد را کاهش دهید.

مزایای کش در اکشن های گیت هاب

در اینجا برخی از مزایای کلیدی استفاده از کش در GitHub Actions آورده شده است:

1. اجرای سریعتر گردش کار: ذخیره سازی به شما امکان می دهد از تکرار کارهای وقت گیر مانند دانلود و نصب وابستگی ها جلوگیری کنید. با ذخیره این فایل ها در حافظه نهان، اجرای گردش کار بعدی می تواند آنها را به سرعت بازیابی کند و زمان اجرای کلی را کاهش دهد.

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

3. بهره‌وری توسعه‌دهنده بهبودیافته: حلقه‌های بازخورد سریع‌تر به توسعه‌دهندگان این امکان را می‌دهد تا کد خود را بیشتر تکرار و آزمایش کنند. با کاهش مدت زمان انتظار برای تکمیل گردش کار، توسعه دهندگان می توانند روی نوشتن کد و ارائه سریعتر ویژگی ها تمرکز کنند.

بهترین روش ها برای ذخیره سازی در GitHub Actions

برای استفاده موثر از کش در GitHub Actions، بهترین روش‌های زیر را در نظر بگیرید:

1. مصنوعات قابل کش را شناسایی کنید: تعیین کنید کدام فایل ها یا وابستگی ها را می توان کش کرد. برای مثال، می‌توانید وابستگی‌های مدیران بسته‌ها را مانند حافظه پنهان ذخیره کنید node_modules یا pip packages. شناسایی مصنوعات مناسب برای کش برای دستیابی به حداکثر عملکرد بسیار مهم است.

2. کلیدهای کش را تعریف کنید: کلیدهای کش تعیین می کنند که چه زمانی باید از حافظه پنهان استفاده شود یا نامعتبر شود. GitHub Actions به شما اجازه می دهد تا کلیدهای کش سفارشی را بر اساس معیارهای خاصی مانند محتوای یک فایل یا نسخه یک وابستگی تعریف کنید. انتخاب کلیدهای کش مناسب تضمین می کند که حافظه پنهان تنها در صورت لزوم باطل می شود و از استفاده مجدد از مصنوعات قدیمی جلوگیری می کند.

3. از Cache Actions استفاده کنید: GitHub Actions اقدامات کش را ارائه می دهد که اجرای کش را ساده می کند. کتابخانه جاوا اسکریپت @actions/cache یک انتخاب محبوب برای مدیریت کش در گردش کار است. این گزینه های انعطاف پذیری را برای ذخیره و بازیابی مصنوعات کش بر اساس کلیدها، محدوده ها و مسیرها ارائه می دهد.

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

5. ماتریس گردش کار اهرمی: اگر گردش کار شما شامل چندین پلت فرم، نسخه یا پیکربندی است، از ویژگی ماتریس گردش کار استفاده کنید. با تعریف ترکیب‌های مختلف ماتریس، می‌توانید آرتیفکت‌های مخصوص هر پیکربندی را در حافظه پنهان ذخیره کنید و زمان اجرا را بهبود ببخشید.

حرف کافی است، کد را به من نشان بده

گردش کار بدون حافظه پنهان

ما دو نمونه از یک گردش کار را مرور خواهیم کرد. اولی از کش استفاده نمی کند و دومی از کش استفاده می کند. ما زمان اجرای هر دو گردش کار را با هم مقایسه می کنیم تا تفاوت را ببینیم. ما از یک پروژه FastApi موجود که در مقاله قبلی ایجاد کردم استفاده خواهیم کرد. می توانید پروژه را پیدا کنید

این پروژه از Docker و Docker Compose برای اجرای برنامه استفاده می کند. گردش کار برنامه را آزمایش می کند و یک تصویر Docker می سازد و آن را به Docker Hub می فرستد. گردش کار با هر فشاری که به آن وارد می شود، فعال می شود main شاخه. اینم فایل گردش کار:

name: Docker Compose Actions Workflow

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

env:
  # Use docker.io for Docker Hub if empty
  REGISTRY: docker.io
  # github.repository as <account>/<repo>
  IMAGE_NAME: ${{ github.repository }}

jobs:

  push_to_registry:
    name: Push Docker image to Docker Hub
    runs-on: ubuntu-latest
    steps:
      - name: Check out the repo
        uses: actions/checkout@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2

      - name: Log in to Docker Hub
        if: github.event_name != 'pull_request'
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: Extract metadata (tags, labels) for Docker
        id: meta
        uses: docker/metadata-action@818d4b7b91585d195f67373fd9cb0332e31a7175
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}

      - name: Build and push Docker image
        if : github.event_name != 'pull_request'
        uses: docker/build-push-action@v4
        with:
          context: "{{defaultContext}}:src"
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}

اجازه دهید روند کار را مرحله به مرحله مرور کنیم:

1. نام: نام گردش کار. این اختیاری است.
2. بر: رویدادی که جریان کار را آغاز می کند. در این حالت، گردش کار با هر فشاری که به آن وارد می شود، فعال می شود main شاخه.
3. Env: متغیرهای محیطی مورد استفاده در گردش کار. در این حالت دو متغیر محیطی داریم: REGISTRY و IMAGE_NAME. این REGISTRY متغیر برای تعیین رجیستری Docker برای فشار دادن تصویر به آن استفاده می شود. این IMAGE_NAME متغیر برای تعیین نام تصویر استفاده می شود.
4. شغل ها: گردش کار از یک کار تشکیل شده است به نام push_to_registry. این کار بر روی آخرین نسخه اوبونتو اجرا می شود.

5. درون push_to_registry مراحلی که باید اجرا شود را مشخص می کنیم. اولین قدم این است که مخزن را بررسی کنید. مرحله دوم راه اندازی Docker Buildx است. مرحله سوم ورود به داکر هاب است. مرحله چهارم استخراج ابرداده برای Docker است. مرحله پنجم ساخت و فشار دادن تصویر Docker است.

   5a. مخزن را بررسی کنید: این مرحله مخزن را بررسی می کند. این یک مرحله ضروری برای همه گردش کار است.

   5b. Docker Buildx را راه اندازی کنید: این مرحله Docker Buildx را راه اندازی می کند. Docker Buildx یک پلاگین CLI است که دستور Docker را با پشتیبانی کامل از ویژگی های ارائه شده توسط جعبه ابزار سازنده Moby BuildKit گسترش می دهد. این تجربه کاربری مشابه ساخت docker را با بسیاری از ویژگی‌های جدید مانند ایجاد نمونه‌های سازنده scoped و ساخت همزمان در برابر چندین گره ارائه می‌کند. در اینجا می توانید اطلاعات بیشتری در مورد Docker Buildx بخوانید.

   5c. وارد Docker Hub شوید: این مرحله به داکر هاب وارد می شود. این مرحله تنها در صورتی اجرا می‌شود که رویدادی که جریان کار را راه‌اندازی کرده است، درخواست کشش نباشد. مرحله با استفاده از DOCKER_USERNAME و DOCKER_PASSWORD اسرار ورود به داکر هاب اسرار در تنظیمات مخزن ذخیره می شوند. در اینجا می توانید اطلاعات بیشتری در مورد اسرار بخوانید. در این مثال مطمئن شوید که دارید DOCKER_USERNAME و DOCKER_PASSWORD اسرار تنظیم شده در تنظیمات مخزن شما.

   5d. استخراج فراداده (برچسب ها، برچسب ها) برای Docker: این مرحله ابرداده را برای Docker استخراج می کند. مرحله با استفاده از docker/metadata-action اقدام برای استخراج ابرداده این اکشن برای استخراج ابرداده از Dockerfiles و فایل‌های docker-compose استفاده می‌شود. خروجی عمل دو متغیر است: tags و labels. این tags متغیر حاوی تگ های تصویر داکر است. این labels متغیر حاوی برچسب های تصویر داکر است. می توانید در مورد آن بیشتر بخوانید docker/metadata-action در اینجا اقدام کنید

   5e. تصویر داکر را بسازید و فشار دهید: این مرحله تصویر Docker را ساخته و هل می دهد. مرحله با استفاده از docker/build-push-action اقدام برای ساخت و فشار دادن تصویر Docker. این اکشن برای ساخت و فشار دادن تصاویر Docker استفاده می شود. این عمل در پارامترهای زیر انجام می شود:

   • متن نوشته: زمینه ساخت. این مسیر به دایرکتوری حاوی Dockerfile است. در این مورد، زمینه ساخت است src.
   • فشار دادن: هل دادن یا نه. در این مورد، آن را تنظیم می کنیم true برای فشار دادن تصویر
   • برچسب ها: برچسب های تصویر داکر. در این مورد، ما از tags متغیر از مرحله قبل
   • برچسب ها: برچسب های تصویر داکر. در این مورد، ما از labels متغیر از مرحله قبل

اکنون اجازه دهید زمان اجرا را در اولین اجرا ببینیم:

همانطور که تصویر نشان می دهد، گردش کار 3 دقیقه و 25 ثانیه طول کشید. حالا اجازه می‌دهیم کش را پیاده‌سازی کنیم و ببینیم آیا می‌توانیم زمان اجرا را بهبود ببخشیم.

گردش کار با حافظه پنهان

استفاده از کش در GitHub Actions بسیار ساده است. شما فقط باید اضافه کنید actions/cache اقدام به گردش کار شما این عمل در پارامترهای زیر انجام می شود:

• مسیر: مسیر دایرکتوری که باید کش شود. در این مورد، ما می خواهیم حافظه پنهان را ذخیره کنیم src فهرست راهنما.
• کلید: کلیدی که برای بازیابی و ذخیره کش استفاده می شود.
• کلیدهای بازیابی: لیست مرتبی از کلیدها برای بازیابی حافظه پنهان در صورتی که هیچ ضربه ای به حافظه پنهان برای کلید رخ نداده باشد.
• نسخه کش: نسخه کش. این اختیاری است.
• اجرا کن: مراحل اجرا در صورت عدم بازیابی حافظه پنهان. این اختیاری است.

حالا بیایید اضافه کنیم actions/cache اقدام به گردش کار ما:

name: Docker Compose Actions Workflow

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

env:
  # Use docker.io for Docker Hub if empty
  REGISTRY: docker.io
  # github.repository as <account>/<repo>
  IMAGE_NAME: ${{ github.repository }}

jobs:
  push_to_registry:
    name: Push Docker image to Docker Hub
    runs-on: ubuntu-latest
    steps:
      - name: Check out the repo
        uses: actions/checkout@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2

      - name: Log in to Docker Hub
        if: github.event_name != 'pull_request'
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: Extract metadata (tags, labels) for Docker
        id: meta
        uses: docker/metadata-action@v4
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}

      - name: Cache Docker layers
        id: cache
        uses: actions/cache@v3
        with:
          path: /tmp/.buildx-cache
          key: ${{ runner.os }}-buildx-${{ github.sha }}
          restore-keys: |
              ${{ runner.os }}-buildx-

      - name: Build and push Docker image
        if : github.event_name != 'pull_request'
        uses: docker/build-push-action@v4
        with:
          context: "{{defaultContext}}:src"
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=local,src=/tmp/.buildx-cache
          cache-to: type=local,dest=/tmp/.buildx-cache

به تغییرات زیر توجه کنید:

• مرحله Cache Docker قبل از مرحله Build and push Docker image اضافه می شود.
• پارامترهای cache-from و cache-to به مرحله Build and push Docker image اضافه می شوند.

اجازه دهید تغییرات را با جزئیات تفکیک کنیم:

1. لایه های کش داکر: این مرحله لایه های Docker را کش می کند. مرحله با استفاده از actions/cache اقدام برای کش کردن لایه های Docker. این عمل در پارامترهای زیر انجام می شود:

   • مسیر: مسیر دایرکتوری که باید کش شود. در این مورد، ما می خواهیم حافظه پنهان را ذخیره کنیم src فهرست راهنما.
   • کلید: کلیدی که برای بازیابی و ذخیره کش استفاده می شود. در اینجا ما از runner.os و github.sha متغیرها برای ایجاد یک کلید منحصر به فرد برای کش.
   • کلیدهای بازیابی: لیست مرتبی از کلیدها برای بازیابی حافظه پنهان در صورتی که هیچ ضربه ای به حافظه پنهان برای کلید رخ نداده باشد. در اینجا ما از runner.os متغیر برای ایجاد یک کلید منحصر به فرد برای کش.

2. تصویر داکر را بسازید و فشار دهید: این مرحله تصویر Docker را ساخته و هل می دهد. مرحله با استفاده از docker/build-push-action اقدام برای ساخت و فشار دادن تصویر Docker. در اینجا ما اضافه کردیم cache-from و cache-to پارامترهای عمل این cache-from پارامتر حافظه پنهان مورد استفاده برای ساخت را مشخص می کند. این cache-to پارامتر حافظه پنهان مورد استفاده برای فشار را مشخص می کند. در این مورد، ما از type=local کش برای کش لایه های Docker. این src=/tmp/.buildx-cache منبع کش را مشخص می کند. این dest=/tmp/.buildx-cache مقصد کش را مشخص می کند.

اکنون اجازه دهید زمان اجرا را در اولین اجرا ببینیم:

همانطور که تصویر نشان می دهد، گردش کار در 15 ثانیه اجرا می شود! درصد بهبود تقریباً 92.68٪ است، اکنون این به هیچ وجه یک آزمایش قطعی نیست، اما پتانسیل کش کردن در GitHub Actions را نشان می دهد. همچنین توجه داشته باشید که با استفاده از کش، اجرای گردش کار در اجراهای بعدی متفاوت خواهد بود.

در زیر یک اسکرین شات از مرحله کش در اقدامات GitHub آمده است:

نتیجه

در این مقاله نحوه استفاده از کش در GitHub Actions را دیدیم. ما نحوه پیاده سازی کش را در یک گردش کار دیدیم و شاهد بهبود عملکرد بودیم. ما همچنین نحوه استفاده از آن را دیدیم actions/cache اقدام برای کش کردن لایه های Docker.

منابع

با خیال راحت با من تماس بگیرید توییتر برای هر گونه سوال یا بازخورد همچنین می توانید نظر خود را در زیر بنویسید.