הגדרת GitHub Container Registry עבור CI/CD ו-Kubernetes

מגבלות ההורדה של Docker Hub מאטות את ה-CI/CD ויוצרות אי נוחות לצוותים המשתמשים ב-GitHub. אנו מגדירים את GitHub Container Registry (ghcr.io) עבור הפרויקט שלכם, ומשלבים אותו עם GitHub Actions ו-Kubernetes. הצוות שלנו מספק הטמעה מלאה - מבדיקת מצב ועד פריסה ותמיכה שוטפת - ומבטיח אספקת תמונות אמינה ומהירה.

היכולות שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

מגבלות הקצב של Docker Hub—200 משיכות אנונימיות ו-600 משיכות מאומתות לשעה—מהוות צוואר בקבוק אמיתי. GitHub Container Registry (ghcr.io) הוא חלופה טבעית לפרויקטים שכבר נמצאים ב-GitHub לקוד וב-GitHub Actions ל-CI/CD. אנו עוזרים לך להגדיר את ghcr.io לפרויקט שלך, מאינטגרציה בסיסית ועד הגירה מלאה מ-Docker Hub תוך 1–2 ימים. ghcr.io מציע עד 500 MB אחסון חינם לחשבון ומאגרים פרטיים ללא הגבלה לארגונים, מה שמפחית את עלויות התשתית ב-30–50% בהשוואה לתוכניות בתשלום של Docker Hub. מהירויות המשיכה גבוהות בממוצע ב-40% מאלה של Docker Hub עבור אזורים באירופה. האינטגרציה עם GitHub Actions מובנית—אין צורך בסודות נוספים.

למה לבחור ב-GitHub Container Registry?

ghcr.io מספק מאגרים פרטיים בחינם לחשבונות אישיים ולארגוני קוד פתוח. התמונות נמצאות לצד הקוד, הגישה מנוהלת באמצעות GITHUB_TOKEN, ומהירויות המשיכה/דחיפה גבוהות יותר הודות ל-CDN המבוזר גיאוגרפית. לדוגמה, משיכת תמונה מ-ghcr.io מהירה בממוצע ב-40% מאשר מ-Docker Hub עבור אזורים באירופה. עבור צוות של 10 אנשים, החיסכון בתשתית לעומת Docker Hub Pro יכול להיות משמעותי.

כיצד ghcr.io משפר את ה-CI/CD?

היתרון המרכזי: GITHUB_TOKEN ללא סודות נוספים. ב-GitHub Actions, אימות ל-ghcr.io אינו דורש סודות נפרדים. ה-token נוצר אוטומטית עבור כל ריצת workflow:

---
name: Build and Push
on:
  push:
    branches: [main]
env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - name: Log in to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - name: Extract metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=sha
            type=ref,event=branch
            type=semver,pattern={{version}}
      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max
---

name: Build and Push on: push: branches: [main] env: REGISTRY: ghcr.io IMAGE_NAME: ${{ github.repository }} jobs: build: runs-on: ubuntu-latest permissions: contents: read packages: write steps: - uses: actions/checkout@v4 - name: Log in to GHCR uses: docker/login-action@v3 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - name: Extract metadata id: meta uses: docker/metadata-action@v5 with: images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} tags: | type=sha type=ref,event=branch type=semver,pattern={{version}} - name: Build and push uses: docker/build-push-action@v5 with: context: . push: true tags: ${{ steps.meta.outputs.tags }} labels: ${{ steps.meta.outputs.labels }} cache-from: type=gha cache-to: type=gha,mode=max מאחסן את מטמון השכבות ב-GitHub Actions Cache, לא ב-registry. הבנייה הראשונה של ענף מתחילה מקור; בניות עוקבות עושות שימוש חוזר במטמון. זה מהיר משמעותית מאשר cache-from: type=gha מ-registry. לפי המדריך הרשמי, גישה זו מאיצה בניות בעד 30%. --cache-from יוצר תגיות אוטומטית: docker/metadata-action עבור כל commit, sha-a1b2c3 עבור הענף הראשי, main עבור תגיות git. אין צורך לכתוב תגיות ידנית. תן לנו להגדיר את ה-pipeline שלך—נשלב את ghcr.io עם ה-CI/CD שלך תוך חצי יום.

כיצד לנהל גישה לחבילות?

כברירת מחדל, לחבילה (תמונה) ב-ghcr.io יש נראות שעוברת בירושה מהמאגר. מאגר ציבורי → תמונה ציבורית. מאגר פרטי → תמונה פרטית.

נהל גישה בהגדרות החבילה (v1.2.3 או github.com/users/<user>/packages). חבילות ארגוניות יכולות להיות מקושרות למאגר ספציפי; אז ה-GITHUB_TOKEN של אותו מאגר מקבל אוטומטית הרשאות push. לשליטה מדויקת, השתמש ב-RBAC ברמת הארגון: הגדר צוותים עם רמות גישה שונות לחבילות.

למשיכה מ-ghcr.io פרטי מחוץ ל-GitHub Actions, יש צורך ב-Personal Access Token (קלאסי) עם היקף github.com/orgs/<org>/packages או ב-PAT עם הרשאות מדויקות. ב-Kubernetes, זה מוגדר כ-imagePullSecret:

kubectl create secret docker-registry ghcr-secret \
  --docker-server=ghcr.io \
  --docker-username=$GITHUB_USER \
  --docker-password=$GITHUB_TOKEN \
  --namespace=production

כיצד להפוך את ניקוי הגרסאות הישנות לאוטומטי?

ghcr.io אינו מוחק גרסאות ישנות אוטומטית. עבור ארגונים עם CI פעיל, מספר גרסאות החבילה גדל במהירות. לדוגמה, אם אתה דוחף 10 תמונות ביום, יהיו לך 300 גרסאות בחודש (או 1000 עם 30 דחיפות). GitHub מספק API למחיקת גרסאות, ופעולות marketplace מציעות מדיניות שמירה.

השתמש ב-GitHub Action read:packages לניקוי אוטומטי. לדוגמה, תצורה זו מסירה את כל הגרסאות ללא תגית, תוך שמירה על לפחות 10 האחרונות:

---
- uses: actions/delete-package-versions@v4
  with:
    package-name: myapp
    package-type: container
    min-versions-to-keep: 10
    delete-only-untagged-versions: true

kubectl create secret docker-registry ghcr-secret \ --docker-server=ghcr.io \ --docker-username=$GITHUB_USER \ --docker-password=$GITHUB_TOKEN \ --namespace=production מסיר רק שכבות ללא תגית, ומשאיר תמונות עם תגית ללא פגע. בטוח להריץ בלוח זמנים (לדוגמה, שבועי). הגדרת מדיניות שמירה מפחיתה את עלויות האחסון ב-20-30%.

מה לשקול בעת הגירה מ-Docker Hub?

בעת הגירה, עדכן את הפניות לתמונות בכל קבצי ה-manifest של Kubernetes (deployments, cronjobs) וב-pipelines של CI/CD. אנו ממליצים על גישה הדרגתית: ראשית הגר את התמונות הקריטיות ביותר, ולאחר מכן את השאר. ghcr.io תומך באותן פקודות Docker, כך שאין צורך ללמוד מחדש. הגירה טיפוסית אורכת 1–2 ימים וכוללת עדכון של 10–50 קבצי manifest.

כיצד אנו מגדירים את ghcr.io

התהליך שלנו כולל את השלבים הבאים:

  1. ניתוח ה-pipelines וה-CI/CD הנוכחיים.
  2. עיצוב workflows עם הרשאות ומטמון אופטימליים.
  3. יישום באמצעות המדריך הרשמי ו-metadata-action.
  4. אינטגרציה עם Kubernetes (imagePullSecret, ServiceAccounts).
  5. הגדרת מדיניות שמירה באמצעות API או actions.
  6. תיעוד והדרכת הצוות.
משימה זמן משוער
הגדרה בסיסית + workflow 0.5 יום
+ אינטגרציה עם Kubernetes +0.5 יום
מחזור מלא (ניתוח, יישום, בדיקה, פריסה) 1–2 ימים

התמחור הוא לפי פרויקט; צור קשר לייעוץ.

השוואה: ghcr.io מול Docker Hub

פרמטר GitHub Container Registry Docker Hub
מגבלת מאגרים פרטיים ללא הגבלה (לארגונים) 1 פרטי לחשבון חינמי
מהירות משיכה גבוהה (CDN, ~200 ms) בינונית (~350 ms, האטות מדי פעם)
אינטגרציה עם GitHub Actions מובנית (GITHUB_TOKEN) דורש token של Docker Hub
מדיניות שמירה באמצעות API/actions לא מובנית

מה כלול

  • הגדרת pipeline לבנייה ופרסום תמונות.
  • יצירה והגדרה של imagePullSecret עבור Kubernetes.
  • פיתוח מדיניות אחסון וניקוי תמונות.
  • תיעוד על גישה ותהליכים.
  • הדרכת צוות (שעה אחת).
  • אחריות תמיכה ל-30 יום.

המהנדסים שלנו מחזיקים בהסמכות AWS Certified DevOps Engineer ו-CKA, עם ניסיון של למעלה מ-5 שנים. השלמנו למעלה מ-100 פרויקטים של הגירה והגדרת container registry.

צור קשר כדי לדון בפרויקט שלך ולקבל ייעוץ תוך יום אחד. ספר לנו על המחסנית הנוכחית שלך: Kubernetes, GitLab CI, או GitHub Actions—נמצא את הפתרון הטוב ביותר.