Google Artifact Registry: הגדרה וניהול של תמונות Docker

Google Artifact Registry: הגדרה וניהול של Docker Images

דמיינו ש-CI pipeline שלכם נכשל בגלל מגבלות pull rate מ-GCR, בעוד ש-Kubernetes cluster images לא מתעדכנים כי ההפניות מצביעות על ה-registry הישן. מפתחים מבזבזים שעות על דיבוג, ותיקון דחוף מגיע ל-production באיחור. Google Container Registry (GCR) מוגדר רשמית כ-deprecated ואינו מומלץ לפרויקטים חדשים. Artifact Registry הוא היורש שלו, המאחסן לא רק Docker images אלא גם Helm charts, חבילות npm, Maven artifacts ומודולי Python. מעבר ל-Artifact Registry מעניק לכם IAM גמיש, סריקת vulnerabilities מובנית, וניקוי אוטומטי של artifacts ישנים. המהנדסים שלנו עם ניסיון של 5+ שנים ב-GCP יעזרו לכם לבצע מעבר ללא downtime.

יתרונות Artifact Registry על פני GCR

Artifact Registry עולה על GCR בפרמטרים מרכזיים: הוא משתלב עם Container Analysis — vulnerabilities נבדקות בכל push. מדיניות ניקוי מונעת גידול בלתי מבוקר של אחסון, ומקצצת עלויות עד 40%. Artifact Registry עובד פי 2 מהר יותר באימות דרך Workload Identity בהשוואה ל-gcloud. registry יחיד למספר פורמטים מפשט את התשתית ומפחית עלויות תפעול ב-30%. הנה השוואה:

איך להגדיר Repository וגישה?

צרו repository באזור הרצוי והגדירו Docker credential helper. בחרו ב-europe-west1 ל-latency נמוך:

# Создание репозитория в europe-west1
gcloud artifacts repositories create my-app \
  --repository-format=docker \
  --location=europe-west1 \
  --description="Production Docker images" \
  --project=my-gcp-project

# Настройка docker credential helper
gcloud auth configure-docker europe-west1-docker.pkg.dev

# Push образа
docker tag my-app:1.0.0 europe-west1-docker.pkg.dev/my-gcp-project/my-app/my-app:1.0.0
docker push europe-west1-docker.pkg.dev/my-gcp-project/my-app/my-app:1.0.0

עבור CI/CD, צרו service account עם התפקיד # Создание репозитория в europe-west1 gcloud artifacts repositories create my-app \ --repository-format=docker \ --location=europe-west1 \ --description="Production Docker images" \ --project=my-gcp-project # Настройка docker credential helper gcloud auth configure-docker europe-west1-docker.pkg.dev # Push образа docker tag my-app:1.0.0 europe-west1-docker.pkg.dev/my-gcp-project/my-app/my-app:1.0.0 docker push europe-west1-docker.pkg.dev/my-gcp-project/my-app/my-app:1.0.0 . בצעו Pull מ-GKE דרך Workload Identity: הגדירו Kubernetes service account הממופה ל-Google service account עם התפקיד roles/artifactregistry.writer. לעולם אל תעניקו ל-CI pipelines את התפקיד roles/artifactregistry.reader — זו דרך ישירה לדליפת סודות ומחיקת images. עקרון ההרשאות המינימליות הוא הבסיס לאבטחה. השתמשו ב-Terraform כ-IaC: המודול roles/artifactregistry.admin מאפשר הגדרה דקלרטיבית של repositories ומדיניות.

איך להימנע מטעויות נפוצות בהגדרת IAM?

הטעות הנפוצה ביותר היא שימוש ב-terraform-google-artifact-registry עבור CI/CD. תפקיד זה מאפשר מחיקת repositories ו-images, מה שעלול להיות קטסטרופלי. במקום זאת, השתמשו בשילוב של writer (push) ו-reader (pull) דרך Workload Identity. בעיה נוספת היא images נטושים ללא tags שמעמיסים על האחסון. הפתרון הוא מדיניות ניקוי המתוארת להלן.

השוואת תפקידי IAM:

למה מדיניות ניקוי קריטית לתקציב?

ללא מדיניות ניקוי, עד 500 GB של זבל מצטברים בשנה — במיוחד אם CI מייצר builds בכל commit. זה מוביל להוצאה גבוהה פי 3 בהשוואה לאחסון מותאם. מדיניות ניקוי מקצצת עלויות אחסון פי 3. דוגמה טיפוסית: שמרו על 10 ה-tags האחרונים עם הקידומת roles/artifactregistry.admin ומחקו images ללא tags שגילם מעל 7 ימים:

{ "name": "keep-release-tags",
  "action": {"type": "Keep"},
  "condition": {
    "tagState": "tagged",
    "tagPrefixes": ["v"],
    "keepCount": 10
  }
}

gcloud artifacts repositories set-cleanup-policies my-app \ --location=europe-west1 \ --policy=cleanup-policy.json 

ללא מדיניות כזו, אתם עלולים לצבור terabytes של images בשנה. מדיניות ניקוי מקצצת עלויות אחסון פי 2-3, והפתרון שלנו הופך אותן לאוטומטיות דרך Terraform.

סריקת Vulnerabilities ומדיניות ניקוי

הפעילו סריקת vulnerabilities ברמת ה-repository. זהו שלב חובה לעמידה בדרישות אבטחה:

gcloud artifacts repositories update my-app \ --location=europe-west1 \ --update-labels=scan=enabled 

הסריקה מתבצעת בכל push — אתם מקבלים דוח עם חומרת CVE. אינטגרציה עם Container Analysis מאפשרת הגדרת התראות אוטומטיות כאשר vulnerabilities חורגות מסף מוגדר.

מה כלול בעבודת ההגדרה?

אנו מציעים הגדרת Artifact Registry במחזור מלא:

• ביקורת תשתית קיימת (GCR, CI/CD, Kubernetes manifests). אנו מעריכים את נפח הנתונים — פרויקט ממוצע מכיל 1000+ images.
• תכנון: בחירת אזור, repositories, סכמת תיוג (לדוגמה, v, { "name": "keep-release-tags", "action": {"type": "Keep"}, "condition": { "tagState": "tagged", "tagPrefixes": ["v"], "keepCount": 10 } } , gcloud artifacts repositories set-cleanup-policies my-app \ --location=europe-west1 \ --policy=cleanup-policy.json ).
• יישום: יצירת repository, הגדרת IAM (service accounts, Workload Identity).
• יישום מדיניות ניקוי וסריקת vulnerabilities.
• העברת images מ-GCR דרך gcloud artifacts repositories update my-app \ --location=europe-west1 \ --update-labels=scan=enabled — מהירות ממוצעת 2 GB/דקה.
• עדכון CI pipelines (GitLab CI, GitHub Actions) ו-Kubernetes manifests.
• תיעוד והנחיות לצוות.

כל השינויים מתועדים כמודולי Terraform או Ansible roles לשחזוריות. לדוגמה, המודול v1.0.0 פורס repository עם IAM ומדיניות ניקוי בפקודה אחת.

לוחות זמנים וכיצד להזמין

הגדרת repository עם IAM, credential helper ומדיניות ניקוי אורכת 4–8 שעות. אם נדרשת העברה מ-GCR ועדכון כל ההפניות, זה אורך 1–2 ימים. התמחור נקבע באופן אישי לאחר ביקורת תשתית. המהנדסים שלנו מוסמכים ב-Google Cloud עם ניסיון בהעברת 20+ פרויקטים; החיסכון הממוצע באחסון ללקוח הוא 35%. ההשקעה בהגדרה מחזירה את עצמה תוך 2-3 חודשים דרך הפחתת עלויות אחסון ו-pipelines מהירים יותר. הזמינו ביקורת תשתית GCP — נעריך את התצורה הנוכחית שלכם ונציע תוכנית העברה. קבלו ייעוץ ממהנדס Google Cloud.

Docker registry — הקונספט העומד בבסיס Artifact Registry.