שירותי הגדרת אירוח, פריסה ותשתית

אנו נתקלים לא פעם במצב: "האתר לא נפתח" ב-3 לפנות בוקר — ומסתבר שדיסק ה-VPS מלא כי לוגי nginx לא עברו רוטציה כבר חצי שנה. או שהשרת קרס תחת עומס ביום השקת קמפיין פרסומי כי לאירוח המשותף הייתה מגבלה של 50 חיבורים בו-זמנית. הגדרת אירוח ופריסה (deployment) אינה עוסקת ב"איפה יותר זול" אלא במה שקורה כשמשהו משתבש. הצוות שלנו מסייע למנוע תקריות כאלה על ידי תכנון תשתית שמתחשבת בדפוסי עומס אמיתיים.

מתי לבחור ב-Vercel וב-Netlify?

Vercel בנוי עבור Next.js — פריסה בלחיצה אחת, פריסות תצוגה מקדימה לכל PR, CDN אוטומטי, Edge Functions, ISR ללא צורך בהגדרה. עבור פרויקטים של Frontend ו-JAMstack, זו הבחירה האופטימלית: ללא תקורה תפעולית, זמן עד לפריסה נמדד בדקות.

מגבלות אמיתיות: פונקציות Serverless של Vercel רצות כברירת מחדל ב-us-east-1 (חביון עבור אירופה +80–100ms), מגבלת זמן לפונקציה 300 שניות בתוכנית Pro, רוחב פס 1TB/חודש בתוכנית Pro. עבור Backend כבד, יש צורך ב-Workers או בשרת נפרד.

Netlify קרובה יותר לאתרים סטטיים ול-Edge Functions המבוססים על Deno Deploy. דקות בנייה (Build minutes) הן המגבלה העיקרית בתוכנית החינמית.

מדוע Docker הוא הבסיס לפריסה צפויה?

"אצלי זה עובד" — קלאסיקה. Docker פותר זאת באמצעות קונטיינריזציה של הסביבה. אבל Dockerfile גרוע יוצר בעיות חדשות.

טעות אופיינית: העתקת הכל לתוך התמונה ללא .dockerignore, מה שגורם לתמונה של 800MB במקום 80MB. node_modules בתוך התמונה שוקל לא פחות. הגישה הנכונה: בנייה רב-שלבית (multi-stage build).

FROM node:20-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci --only=production COPY . . RUN npm run build FROM node:20-alpine AS runner WORKDIR /app COPY --from=builder /app/.next ./.next COPY --from=builder /app/node_modules ./node_modules COPY --from=builder /app/package.json ./package.json EXPOSE 3000 CMD ["npm", "start"] 

התמונה הסופית: 180MB במקום 1.2GB. זמן הבנייה ב-CI מתקצר בזכות שכבת מטמון (layer caching) — אם FROM node:20-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci --only=production COPY . . RUN npm run build FROM node:20-alpine AS runner WORKDIR /app COPY --from=builder /app/.next ./.next COPY --from=builder /app/node_modules ./node_modules COPY --from=builder /app/package.json ./package.json EXPOSE 3000 CMD ["npm", "start"] לא השתנה, השכבה עם package.json נלקחת מהמטמון.

Docker Compose לפיתוח מקומי ולתרחישי production פשוטים: אפליקציה + PostgreSQL + Redis בתצורה אחת. עבור production על שרת יחיד, זו אופציה מעשית לחלוטין אם אין דרישה לסקיילינג אופקי.

מידע נוסף על קונטיינריזציה — ויקיפדיה: Docker.

כיצד להגדיר Nginx כ-Reverse Proxy?

Nginx מול האפליקציה הוא הסטנדרט עבור VPS ושרתים ייעודיים. פונקציות עיקריות: סיום SSL, gzip, קבצים סטטיים, הגבלת קצב (rate limiting), איזון עומסים בין Upstreams.

תצורה שנעשית לא פעם בצורה שגויה: npm ci — מספר התהליכים שווה למספר ליבות ה-CPU. worker_processes auto — כלומר 1024 לכל תהליך עובד. עם 4 ליבות CPU ו-1024 חיבורים = 4096 חיבורים בו-זמנית. עבור אתר עם תעבורה גבוהה, יש צורך ב-worker_connections 1024 ולהגדיר worker_connections 4096.

עבור נכסים סטטיים עם hash בשם הקובץ:

location ~* \.(js|css|woff2|png|webp)$ { expires 1y; add_header Cache-Control "public, immutable"; } 

keepalive_timeout 65 אומר לדפדפן: אל תאמת מחדש את הקובץ הזה אפילו ברענון מלא (hard refresh). זה עובד נכון רק עם שמות קבצים המכילים hash (כפי ש-Vite/webpack עושים כברירת מחדל). תיעוד — ויקיפדיה: Nginx.

AWS: גמישות ומורכבות

EC2 + Auto Scaling Group — הקלאסיקה לסקיילינג אופקי. AMI עם אפליקציה מותקנת מראש, Launch Template, ASG עם מינימום/רצוי/מקסימום מופעים, Application Load Balancer. כאשר CPU > 70% למשך 3 דקות — הגדלה (scale out), כאשר CPU < 30% למשך 15 דקות — הקטנה (scale in). בדיקת בריאות (Health check) דרך ALB מסירה מופעים לא תקינים מהסבב.

ECS Fargate — קונטיינרים ללא ניהול EC2. פרסו תמונת Docker, ציינו CPU/זיכרון (512 יחידות CPU = 0.5 vCPU, מ-512MB זיכרון), ו-Fargate משיקה אותה. יקר יותר מ-Lambda, אך ללא Cold Start וללא מגבלות זמן. מתאים לתהליכים ארוכי טווח, שרתי WebSocket, ו-Workers כבדים.

RDS עבור PostgreSQL עם Multi-AZ: Failover אוטומטי תוך 1–2 דקות כאשר השרת הראשי נופל. Read Replicas לסקיילינג של קריאות. RDS Proxy עבור איגום חיבורים (connection pooling) — פונקציות Lambda אינן יכולות להחזיק חיבורים ארוכי טווח, ה-Proxy חוצץ זאת.

Kubernetes: מתי זה מוצדק

K8s מוסיף מורכבות תפעולית משמעותית. מוצדק כאשר: מספר צוותים פורסים שירותים עצמאיים, יש צורך בהקצאת משאבים מדויקת לכל שירות, נדרשות פריסות Canary ו-Blue/Green ללא זמן השבתה.

AWS EKS, GKE, או Kubernetes מנוהל מ-Hetzner (זול יותר). Helm charts לשירותים סטנדרטיים. Horizontal Pod Autoscaler המבוסס על CPU ומדדים מותאמים אישית (RPS דרך Prometheus).

עבור רוב הסטארטאפים והפרויקטים הבינוניים, Kubernetes הוא מוגזם. ECS או Fly.io מספקות 80% מהיכולות עם 20% מהמורכבות התפעולית.

ניטור והתראות

שרת ללא ניטור הוא המתנה לתקרית. ערימה מינימלית: Prometheus + Grafana (או Grafana Cloud לניהול מנוהל), התראות על דיסק > 80%, זיכרון > 85%, CPU > 90% למשך 5 דקות, שיעור שגיאות > 1%. זמינות (Uptime) דרך Better Uptime או Upptime (באירוח עצמי).

לוגים: Loki + Grafana או CloudWatch Logs Insights. לוגים מובנים בפורמט JSON (winston, pino) הם חובה — אחרת, חיפוש בלוגים הופך לסיוט.

מה כלול בהגדרת אירוח

• ביקורת של התשתית הקיימת ופרופיל עומסים
• בחירת ארכיטקטורת יעד (VPS, AWS, Serverless, Kubernetes)
• הגדרת צינור CI/CD (GitHub Actions, GitLab CI) עם פריסה אוטומטית
• IaC באמצעות Terraform או Pulumi (תשתית כקוד)
• הגדרת Nginx, אישורי SSL, HTTP/2, brotli
• ניטור והתראות (Prometheus + Grafana, PagerDuty)
• תיעוד Runbooks והדרכת צוות

בנוסף, צרו קשר אם אתם זקוקים למיגרציה מהאירוח הנוכחי או לאינטגרציה עם שירותים חיצוניים.

תהליך העבודה

1. ביקורת התשתית הקיימת (2–5 ימים)
2. בחירת ארכיטקטורת יעד עם הצדקת עומס ותקציב (1–3 ימים)
3. הגדרת צינור CI/CD (GitHub Actions, GitLab CI) (2–5 ימים)
4. IaC באמצעות Terraform או Pulumi (3–10 ימים)
5. הגדרת ניטור והתראות (2–5 ימים)
6. תיעוד Runbooks והדרכת צוות (1–3 ימים)

הניסיון שלנו — 7 שנים בשוק, מעל 50 פרויקטים, אחריות לתפקוד לאחר הפריסה.

לוח זמנים

• פריסה בסיסית על VPS עם Docker + Nginx + CI/CD: 1–2 שבועות.
• הגדרת תשתית AWS עם Auto Scaling, RDS, CDN: 3–6 שבועות.
• מיגרציה ל-EKS מאפס: 6–12 שבועות.
• הגדרת Vercel/Netlify עבור JAMstack: 3–5 ימים.

העלות מחושבת באופן אישי בהתאם למורכבות והיקף העבודה. קבלו ייעוץ — נעריך את הארכיטקטורה שלכם תוך יום אחד.