שרת VPS ל-Docker על KVM עם NVMe

קונטיינרים של Docker חולקים את הקרנל של המכונה שעליה הם רצים. בגלל זה טכנולוגיית הווירטואליזציה שמתחת ל-VPS חשובה ל-Docker יותר כמעט מלכל דבר אחר.

ב-VPS מבוסס קונטיינרים (OpenVZ או LXC), ה"שרת" שלכם הוא בעצמו קונטיינר על הקרנל של הספק. להריץ בתוכו Docker זה קונטיינר בתוך קונטיינר, ואם זה עובד תלוי בדברים שהספק שולט בהם: גרסת הקרנל של השרת המארח, אילו מודולים טעונים, איך מואצלים ה-cgroups, האם nesting מופעל בכלל, והאם מותר להשתמש במערכות קבצים overlay ובחוקי iptables. יש ספקים שחוסמים Docker בחבילות כאלה לגמרי, ואחרים מאפשרים אותו עם מעקפים שנשברים בעדכון הבא של השרת המארח.

חבילות ה-VPS של Devoster הן מכונות וירטואליות KVM. אתם מעלים קרנל לינוקס משלכם, כך ש-Docker Engine מותקן מהמאגר הרשמי של Docker בדיוק כמו על שרת פיזי: cgroups, ‏namespaces, דרייבר האחסון overlay2 וחוקי ה-iptables של Docker עובדים בלי לבקש מאף אחד. ‏Ubuntu 24.04 ו-Debian 12 זמינים כאימג'ים ושניהם נתמכים רשמית על ידי Docker Engine.

דרייבר האחסון ברירת המחדל של Docker בלינוקס עדכני הוא overlay2. הוא מערים שכבות אימג' לקריאה בלבד מתחת לשכבה דקה וניתנת לכתיבה לכל קונטיינר, והוא דורש שמערכת הקבצים תחת /var/lib/docker תהיה ext4, או xfs שפורמט עם ftype=1. אחרי ההתקנה הריצו docker info וודאו ששורת ה-Storage Driver מציגה overlay2.

NVMe עוזר ל-Docker בדיוק איפה שכואב: פריסת שכבות אימג' ב-docker pull, קריאות וכתיבות קטנות ואקראיות של מסדי נתונים ב-volumes, ו-builds שנוגעים באלפי קבצים קטנים. נפח הדיסק הוא שאלה נפרדת, והוא מתמלא ממקומות שאנשים לא מסתכלים עליהם:

• אימג'ים ישנים ו-build cache. כל pull של תג חדש משאיר את הישן עד שמנקים. docker system df מראה את החלוקה; docker image prune ו-docker builder prune מפנים מקום.
• לוגים של קונטיינרים. דרייבר הלוגים json-file שבברירת מחדל לא עושה רוטציה. קונטיינר פטפטן יכול למלא דיסק לבד.
• Volumes של מסדי נתונים. זה המידע שבאמת חשוב לכם, והוא גדל בהתמדה.

הגדירו רוטציית לוגים פעם אחת, ב-/etc/docker/daemon.json, ואז הפעילו מחדש את Docker:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" }
}

התבנית שמחזיקה מעמד על שרת ציבורי: reverse proxy אחד חושף את פורטים 80 ו-443 ומטפל ב-TLS, כל השאר נשאר ברשת הפנימית של Compose, המידע יושב ב-named volumes, ותגי האימג'ים נעולים על גרסה. כך זה נראה עם Caddy, אפליקציה ו-Postgres:

name: myapp
services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports: ["80:80", "443:443"]
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
  app:
    image: ghcr.io/you/myapp:1.4.2
    restart: unless-stopped
    env_file: .env
    expose: ["3000"]
    depends_on:
      db:
        condition: service_healthy
  db:
    image: postgres:17
    restart: unless-stopped
    env_file: .env
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app"]
      interval: 5s
      retries: 10
volumes:
  caddy_data:
  db_data:

ה-Caddyfile הוא שתי שורות (app.example.com ו-reverse_proxy app:3000), ו-Caddy מנפיק ומחדש את התעודה לבד. שימו לב שהאפליקציה ומסד הנתונים משתמשים ב-expose ולא ב-ports: חוץ מה-proxy, שום דבר לא נגיש מבחוץ. לגרסה מלאה ואמיתית של התבנית הזו, ראו איך אנחנו מריצים n8n עם Postgres ו-Caddy במדריך להתקנת n8n על VPS.

הדמון של Docker עצמו קל; מה שקובע את הגודל הוא סכום הקונטיינרים ברגע העמוס ביותר שלהם, ועוד ה-page cache שמסדי הנתונים נשענים עליו. מסדי נתונים ושירותי JVM או Node.js קובעים את הרצפה הרבה יותר ממספר הקונטיינרים.

הרגל אחד שחוסך מדרגת חבילה: לבנות אימג'ים ב-CI ולמשוך אותם לשרת. קומפילציה של פרונטאנד או התקנת תלויות בתוך docker build על VPS קטן היא לרוב הקפיצה הגדולה ביותר בזיכרון וב-CPU שהשרת יראה אי פעם. להרצת כמה אתרים נפרדים על שרת Docker אחד, המדריך שלנו לאירוח כמה אתרים על VPS אחד מכסה בידוד וניתוב.

קודם עושים את ההקשחה הכללית, כמו בצ'קליסט ההקשחה שלנו ל-VPS: רק מפתחות SSH, חומת אש שחוסמת כברירת מחדל, ועדכוני אבטחה אוטומטיים. אחר כך הנקודות שייחודיות ל-Docker, שתופסות גם אנשים שעשו את כל השאר נכון:

• פורטים שחושפים עוקפים את UFW. ‏Docker כותב חוקי iptables משלו עבור ports:, כך שפורט שחשפתם נגיש מהאינטרנט גם אם UFW אומר deny. חשפו רק את ה-proxy; לכל השאר השתמשו ב-expose, או קשרו ל-127.0.0.1:port כשאתם צריכים גישה מהשרת עצמו.
• קבוצת docker שווה root. כל מי שיכול לדבר עם ה-socket של Docker יכול למפות את מערכת הקבצים של השרת. הוסיפו רק משתמשים שאתם סומכים עליהם, ואל תמפו את /var/run/docker.sock לקונטיינר שפתוח לאינטרנט אלא אם אתם מבינים בדיוק מה הקונטיינר הזה יכול לעשות אחר כך.
• נעלו תגי אימג'ים ועדכנו בכוונה. ‏latest יחד עם pull אוטומטי זה בדיוק איך שינוי שובר מגיע בשלוש בלילה. קוראים release notes, ואז מעלים את התג.
• סודות לא נכנסים לאימג'ים. מעבירים אותם בקובץ .env עם chmod 600 או ב-Docker secrets, לא צרובים ב-Dockerfile.

כל VPS ב-Devoster כולל גיבוי לילי של כל השרת, כש-3 הימים האחרונים נשמרים, ועוד Snapshot אחד שאתם יכולים לצלם בעצמכם מהפאנל (‏Snapshots מהפאנל פגים אחרי 7 ימים). הם מכסים את המקרה של "להחזיר את כל המכונה אחורה": שדרוג שהשתבש, volume שנמחק, עדכון מערכת שבור. צלמו Snapshot רגע לפני docker compose pull על כל דבר חשוב.

הם לא מחליפים גיבוי ברמת האפליקציה. גיבוי של שרת שלם שנלקח בזמן שמסד נתונים כותב הוא לא אותו דבר כמו dump נקי, ו-3 ימי היסטוריה לא יעזרו אם תגלו בעיה בשבוע השני. תעשו dump למסדי הנתונים לפי לוח זמנים (‏pg_dump, ‏mysqldump), תארזו volumes שמחזיקים קבצים, ותעתיקו את שניהם מחוץ לשרת.

• אתם צריכים autoscaling או זמינות גבוהה על כמה מכונות. ‏VPS יחיד הוא נקודת כשל יחידה. אם נפילה של שרת אחד לא מקובלת עליכם, אתם צריכים כמה שרתים ו-orchestrator, או פלטפורמת קונטיינרים מנוהלת.
• אתם לא רוצים לתחזק שרת. חבילות ה-VPS של Devoster לא מנוהלות. שדרוגי Docker, עדכוני מערכת, ‏TLS וגיבויים עליכם. אם אתם רק רוצים לדחוף קוד ושירוץ, PaaS יתאים יותר.
• אתם צריכים GPU. החבילות האלה הן CPU בלבד.
• המידע שלכם חייב להישאר באירופה או בישראל. שרתי ה-VPS של Devoster נמצאים ביוטה, ארה״ב.
• מדובר באתר וורדפרס אחד. להכניס התקנת וורדפרס יחידה לקונטיינרים מוסיף עבודה בלי הרבה תועלת; אחסון האתרים של Devoster פשוט יותר לזה.

אחרת, השוו את כל שמונה חבילות ה-VPS של Devoster; ‏Starter הוא המקום שבו נוחתים רוב ה-stacks של Compose.