הגדרת קונטיינרים ללא שרת: Fargate, Cloud Run, ACI

האם הקונטיינרים שלכם רצים ביעילות נמוכה או דורשים ניהול ידני מתמיד? אנו מגדירים קונטיינרים ללא שרתים ב-AWS Fargate, GCP Cloud Run ו-Azure Container Instances, ומבצעים אוטומציה של קנה המידה וביטול זמני השבתה. הצוות שלנו מספק פרויקטים סוהריים—מבחירת הפלטפורמה ועד ליישום ותמיכה שוטפת—ומבטיח פעולה אמינה וחסכונית של היישומים שלכם.

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

שאלות נפוצות

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

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

אתם מביאים תמונת Docker—אנחנו מקימים תשתית שמתרחבת עם העומס, לא יושבת בטלה, ולא דורשת ניהול ידני של צמתים. המהנדסים המוסמכים שלנו העבירו למעלה מ-50 פרויקטים לקונטיינרים ללא שרת מאז 2018, והשיגו חיסכון בעלויות של 40–70% לעומת מכונות וירטואליות מסורתיות. צוותים נתקלים לעיתים קרובות בבעיות התנעה קרה (1–5 שניות ב-Cloud Run אם לא שומרים מופעים חמים), עיכובי רשת בגישה למשאבים פרטיים, ובזבוז משאבים מקונטיינרים שהוגדרו לא נכון. אנחנו מבטיחים ביקורת יסודית ובחירת פלטפורמה מותאמת לצרכים שלכם.

מחשוב ללא שרת הוא לא רק טרנד—זו דרך לקצץ בעלויות תשתית בעד 70%. שלוש הפלטפורמות הגדולות עובדות בצורה שונה, והבחירה תלויה לעיתים קרובות במקום שבו התשתית הקיימת שלכם נמצאת. בואו נפרק את החוזקות והמלכודות שלהן.

איך לבחור את הפלטפורמה המתאימה לתרחיש שלכם

AWS Fargate: אינטגרציה לתוך האקוסיסטם

Fargate רץ דרך ECS או EKS. אתם צריכים קלאסטר ECS/EKS כדי להפעיל משימות Fargate. Fargate עצמו לא מטפל בתעבורת HTTP—אתם צריכים ALB.

היתרון המרכזי של Fargate הוא אינטגרציה טבעית עם שירותי AWS: IAM Task Roles מספקים גישה מאובטחת ל-S3/DynamoDB/Secrets Manager ללא אישורים במשתני סביבה, רשת VPC טבעית, CloudWatch Logs מובנה, ו-Service Connect לרשת שירותים בין שירותים.

למשימות עם מצב (stateful), אפשר לחבר EFS למשימת Fargate—אחסון מתמשך ללא ניהול EBS.

מגבלות: אין קונטיינרים עם הרשאות גבוהות (privileged), אין מצב רשת host, תמיכה מוגבלת ב-GPU (רק ב-ECS, לא ב-EKS). אם אתם צריכים --privileged, השתמשו בסוג ההשקה EC2.

GCP Cloud Run: ההשקה הפשוטה ביותר

ל-Cloud Run יש את חסם הכניסה הנמוך ביותר. gcloud run deploy myservice --image gcr.io/my-project/myimage --region us-central1—והשירות שלכם פעיל עם כתובת HTTPS ציבורית.

תכונה ייחודית של Cloud Run היא קנה מידה לאפס. כשאין תעבורה, אין מופעים; העלות היא $0. מושלם לסביבות פיתוח, כלים פנימיים, ושירותים לא סדירים. לייצור עם דרישות זמן השהיה מתחת ל-200ms, קחו בחשבון התנעה קרה: הבקשה הראשונה למופע קר לוקחת 1–5 שניות תלוי בגודל התמונה ובסביבת הריצה.

כדי להפחית התנעה קרה, השתמשו ב---min-instances 1 כדי לשמור מופע חם אחד. עלות הבטלה למופע Cloud Run אחד היא קטנה אבל לא אפסית.

Cloud Run תומך ב---concurrency—מספר הבקשות בו-זמנית לכל מופע (עד 1000). זה שונה מהותית מ-Lambda (בקשה אחת לכל מופע): מופע Cloud Run אחד יכול לטפל במאות בקשות במקביל, מה שהופך אותו ליעיל פי 5 עבור API עם תפוקה גבוהה.

# cloud-run-service.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: myapp
  annotations:
    run.googleapis.com/ingress: all
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "1"
        autoscaling.knative.dev/maxScale: "100"
        run.googleapis.com/cpu-throttling: "false" # CPU не throttle вне запросов
    spec:
      containerConcurrency: 80
      containers:
        - image: gcr.io/my-project/myapp:latest
          resources:
            limits:
              cpu: "1"
              memory: "512Mi"
          env:
            - name: DB_URL
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: url

# cloud-run-service.yaml apiVersion: serving.knative.dev/v1 kind: Service metadata: name: myapp annotations: run.googleapis.com/ingress: all spec: template: metadata: annotations: autoscaling.knative.dev/minScale: "1" autoscaling.knative.dev/maxScale: "100" run.googleapis.com/cpu-throttling: "false" # CPU не throttle вне запросов spec: containerConcurrency: 80 containers: - image: gcr.io/my-project/myapp:latest resources: limits: cpu: "1" memory: "512Mi" env: - name: DB_URL valueFrom: secretKeyRef: name: db-credentials key: url הופך את המעבד לזמין בכל עת, לא רק בזמן עיבוד בקשות. שימושי למשימות רקע (ניקוי מטמון, שליחת מדדים) בתוך המופע.

Azure Container Instances: השקה מהירה, ללא אורכסטרציה

ACI הוא הפשוט מבין השלושה—רק השקת קונטיינר ללא אורכסטרציה מובנית או קנה מידה אוטומטי. אין HTTPS מובנה, אין מאזן עומסים, אין קנה מידה אוטומטי.

ACI מתאים לתרחישים שבהם אין צורך באורכסטרציה: משימות אצווה חד-פעמיות (הרצה, המתנה, כיבוי), sidecars בצינורות CI/CD, סביבות פיתוח לפי דרישה, בדיקות תמונות.

לשירותי HTTP בייצור, ACI ללא רכיבים נוספים (Application Gateway, AGIC) אינו מתאים.

למה קונטיינרים ללא שרת מנצחים מכונות וירטואליות

מכונות וירטואליות דורשות ניהול מערכת הפעלה, ניטור תיקונים, והזמנת קיבולת. קונטיינרים ללא שרת חוסכים עד 40% בעלויות ניהול ו-30–50% בעלויות מחשוב. אתם משלמים רק על משאבים שנצרכו—אין חיוב על זמן בטלה. עלות הבעלות הכוללת (TCO) יורדת ב-40–70% לעומת תשתית VM. כדי להעריך חיסכון לפרויקט שלכם, הזמינו ביקורת—נכין חישוב מפורט עם סכומים בדולרים לפי ההוצאה הנוכחית שלכם.

אינטגרציית רשת

כל שלוש הפלטפורמות תומכות ברשת פרטית:

  • Fargate: משימות רצות בתוך VPC, מקבלות ENI עם כתובת IP פרטית. קבוצות אבטחה שולטות בתעבורה נכנסת/יוצאת.
  • Cloud Run: השתמשו ב-VPC Connector או Direct VPC Egress למשאבים פרטיים (Cloud SQL, Memorystore). תעבורה נכנסת דרך Load Balancer או ישירות דרך IAM.
  • ACI: רשת וירטואלית דרך אינטגרציית Azure VNet.

ניהול סודות

עיקרון משותף לכולם: לעולם אל תאחסנו סודות במשתני סביבה בתצורות פריסה.

  • Fargate: Secrets Manager או SSM Parameter Store דרך שדה secrets בהגדרת משימת ECS.
  • Cloud Run: Secret Manager דרך הרכבת כרך או הפניית משתנה סביבה.
  • ACI: Key Vault דרך זהות מנוהלת.

איך אנחנו עושים את זה: שלב אחר שלב

  1. ביקורת ובחירת פלטפורמה. ניתוח עומס, דרישות זמן השהיה, תקציב, סביבת הענן הנוכחית.
  2. עיצוב רשת. הקמת VPC, נקודות קצה פרטיות, קבוצות אבטחה, VPC Connector.
  3. הקמת CI/CD. אינטגרציה של GitLab CI או GitHub Actions עם פריסת Terraform.
  4. פריסה ובדיקות. אימות קנה מידה (HPA, במקביליות), התנעה קרה, קישוריות רשת.
  5. ניטור ותיעוד. הקמת Prometheus/Grafana, יצירת runbook, הדרכת הצוות שלכם.
פרטים נוספים על לוחות זמניםזמני הקמה אופייניים: Cloud Run עם VPC פרטי ו-Secret Manager: 1–2 ימים. Fargate עם ECS, ALB ו-CI/CD: 2–3 ימים. ACI למשימות אצווה: יום אחד. הערכת פרויקט לוקחת יום אחד.

מה כלול בעבודה שלנו

  • ביקורת תשתית נוכחית ובחירת פלטפורמה
  • הקמת צינור CI/CD (GitLab CI, GitHub Actions, Cloud Build)
  • תצורת רשת: VPC, נקודות קצה פרטיות, קבוצות אבטחה
  • פריסה עם קנה מידה אוטומטי (HPA, תצורת במקביליות)
  • אינטגרציית ניטור (Prometheus/Grafana, CloudWatch)
  • תיעוד runbook והדרכת צוות
  • תמיכה לאחר השקה (SLA לפי בקשה)

השוואת פלטפורמות

קריטריון AWS Fargate (ECS) GCP Cloud Run Azure Container Instances
קנה מידה לאפס לא (ברירת מחדל) כן לא
קנה מידה אוטומטי דרך ECS Service מובנה ידני
התנעה קרה אין (תמיד N מופעים) 1–5 שניות אין (ללא קנה מידה אוטומטי)
HTTPS מובנה לא (דורש ALB) כן לא
תמיכת GPU מוגבלת כן (A100, T4) לא
מודל תמחור לפי vCPU/RAM לשנייה לפי בקשה + בטלה לפי vCPU/RAM לשנייה

Cloud Run מתרחב לאפס, וחוסך עד 70% לעומת Fargate בעומס לסירוגין. לתעבורה יציבה, Fargate עם ALB אמין יותר ב-20% מבחינת ערבויות זמינות (99.95% לעומת 99.9% ל-Cloud Run).

לוחות זמנים ומורכבות

פלטפורמה זמן הקמה (ימים) מומחיות נדרשת
Cloud Run + VPC פרטי + CI/CD 1–2 היכרות עם GCP, Terraform
Fargate + ECS + ALB + CI/CD 2–3 רשתות AWS, ECS, IAM
ACI למשימות אצווה 1 ידע בסיסי ב-Azure

נעריך את הפרויקט שלכם ונמליץ על הפתרון הטוב ביותר. עם ניסיון של 5+ שנים ורקורד של 50+ הגירות מוצלחות, אנחנו מבטיחים הקמה חסכונית ואמינה. צרו קשר לייעוץ והערכת עלות תוך יום אחד. הזמינו ביקורת תשתית—נתאים לכם את הפלטפורמה הנכונה.