Docker Compose ב-Homelab: ארגון, פרופילים ושיטות עבודה מומלצות

אינפורמטק דיגיטל » Recursos » Docker Compose ב-Homelab: ארגון, פרופילים ושיטות עבודה מומלצות

הקמת מעבדת יישומים מודרנית עם קונטיינרים הפכה לתחביב מועדף על אנשי טכנולוגיה רבים. Docker Compose כמעט תמיד נמצא בלב ההתקנה הזו : הגדירו את השירותים שלכם ב-YAML, גרסו אותם עם Git, והפעילו את כל הסביבה שלכם עם פקודה אחת.

עם זאת, כשמתחילים לצמוח, דברים משתנים: עוברים משתיים או שלוש קונטיינרים לעשרות שירותים, רשתות פנימיות, פרוקסי הפוכים, מסדי נתונים ורצים של CI . ואז עולה השאלה הגדולה: מופע ענק אחד של Docker Compose או הרבה קבצים קטנים? כיצד ניתן לארגן פרופילים, רשתות, גיבויים, אבטחה, ובנוסף לכך, להקל על ההגירה?

גישות מהעולם האמיתי להקמת Docker Compose במעבדה ביתית

בפועל, אנשים שמשתמשים ב-Homelabs כבר זמן מה בדרך כלל עובדים עם שלושה מודלים ארגוניים שונים של Compose, שלכל אחד מהם יתרונות וחסרונות משלו. בחירת הגישה הנכונה חוסכת לכם הרבה צרות בעת הגדלה או מעבר למכונה חדשה.

מצד אחד, יש כאלה שהתחילו עם פקודות Docker Run עצמאיות, אחר כך עברו ל-Portainer, ולבסוף קפצו ל-Docker Compose . זהו תרחיש טיפוסי: Portainer מציע נראות מעולה, ממשק ידידותי למשתמש, תבניות וכו', אך בסופו של דבר, עריכת פרמטרים מורכבים או העברת תצורות הופכות לטרחה אם אין לך כלום בקבצים.

בקצה השני נמצא זה שאיגד הכל לקובץ docker-compose.yml "מגה" יחיד המסוגל להריץ את כל שירותי homelab: פרוקסי הפוך, מדיה, כלי עזר, ניטור, תוכניות לימודים לתואר שני, מסדי נתונים... הכל במחסנית אחת.

בין לבין, משתמשים רבים דבקים בגישה מעורבת: מספר קבצי docker-compose.yml קטנים המקובצים לפי הקשר (למשל, מדיה, תשתית, פרודוקטיביות, ניטור), כולם תחת אותו מאגר ובדרך כלל חולקים משתני סביבה גלובליים.

פתרון אלגנטי למדי משלב את שני העולמות: קובץ docker-compose "root" הכולל קבצים אחרים (כל אחד בתת-תיקייה של אפליקציות או שירותים). בדרך זו ניתן לשמור על תצוגה גלובלית של ה-homelab, אך מבלי לסבול מקובץ YAML בן אלף שורות שבלתי אפשרי לקריאה.

פרופילים, קיבוץ לפי פונקציה ומעבדות ביתיות גדולות

כאשר מעבדת הבית שלך מתחילה להתקרב ל -30, 40 או 50 שירותים (כולל שירותי גיבוי כמו מסדי נתונים, מטמונים או אינדקסים), חיוני לעשות בהם סדר. כאן נכנסים לתמונה גם קיבוץ לפי פונקציה וגם שימוש בפרופילי Docker Compose.

דפוס נפוץ מאוד הוא לקבץ הכל ל"פרויקט" אחד של Compose, אך מחולק באופן הגיוני לפי פרופילים. לדוגמה:

• פרופיל ליבהליבת homelab, עם Traefik כ-Reverse Proxy וספק זהויות (למשל, OAuth או Authentik) לאימות כל האפליקציות תחת אותו דומיין באמצעות HTTPS.
• פרופיל מדיהשירותים כמו Plex, Sonarr, Radarr, Ombi, SABnzbd או qBittorrent, אחראים על אצירה, הורדה והגשה של תוכן מולטימדיה.
• פרופיל שירותיםכלים כגון Portainer, Watchtower (אם משתמשים), Diun, dockcheck או דומים לניהול וניטור קונטיינרים ועדכונים.
• פרופיל תשתית/ניטורTraefik, cAdvisor, Prometheus, Grafana, Uptime Kuma, Dozzle וכל מה שקשור לניטור ורישום.
• פרופילים ניסיוניים או תואר ראשון במשפטים: ערימות ספציפיות עבור תלמידי LLM או אפליקציות מוזרות (ChatGPT Next Web local, LibreOffice Online וכו') שבדרך כלל מושבתות כברירת מחדל.

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

במאגרים מעוצבים היטב, בדרך כלל יש קובץ docker-compose.yml "master" בשורש הקובץ שמשתמש ב-include כדי לדחוף קבצים בודדים לתיקייה apps/ או services/ . בנוסף, כמעט כל השירותים מוגדרים באמצעות קובץ .env גלובלי יחיד, וחלק מהסודות מאוחסנים בתיקייה secrets/ , מה שמפשט מאוד את ההתקנה הראשונית.

בהתאם לדפוס זה, ניהול ה-homelab מסתכם בעיקרו בעריכת קובץ ה-.env והסודות, הפעלה או השבתה של פרופילים והחלטה אילו שירותים להפעיל בכל מארח . זה אידיאלי אם אתם מתכוונים לפרוס את אותה קבוצת יישומים על פני מספר מכונות.

קובץ docker-compose ענק אחד לעומת מספר קבצים קטנים

זהו הוויכוח הנצחי: קובץ docker-compose.yml יחיד המכיל הכל, או מספר קבצים לכל שירות/מחסנית? התשובה האמיתית היא בדרך כלל "זה תלוי מה אתה רוצה לתעדף: פשטות ההעברה או בהירות לכל שירות."

אלו התומכים בקובץ אב יחיד בדרך כלל מדגישים מספר יתרונות:

• העברת מארחים היא סופר קלהאתה משכפל את המאגר, מעתיק את קובץ ה-.env ואת הסודות, מעלה את הכרכים ומפעיל את `docker compose up -d`. אין צורך לעבור ספרייה אחר ספרייה.
• תשתית כקוד אמתכל הטופולוגיה של homelab (שירותים, רשתות, אמצעי אחסון, תלויות) נמצאת במקום אחד.
• עדכונים מרכזייםאתה משנה גרסת תמונה, מדיניות אתחול מחדש או רישום כלשהו, ​​ואתה יודע בדיוק היכן לגעת.

אבל יש לו גם חסרונות ברורים: קובץ YAML ענק קשה יותר לתחזוקה, ניגודי מיזוג גוברים, וכאשר מנקים באגים בבעיה ספציפית, מוצאים את עצמכם מנווטים בין מפלצת של מאות שורות. לא נדיר להרגיש קצת חרטה כשהכל נהיה גדול מדי.

הגישה השנייה היא שיהיה קובץ docker-compose.yml לכל אפליקציה או לכל מחסנית לוגית , בתוך מבנה כזה:

docker/
├── bookstack/
│   └── docker-compose.yml
├── dashy/
│   └── docker-compose.yml
└── traefik/
    └── docker-compose.yml

בכך, כל קונטיינר נקרא משהו כמו bookstack-app-1 או traefik-reverse-proxy-1 , מה שעוזר לך לאתר בעיות במהירות: אם הקונטיינר bookstack-app-1 קורס, אתה יודע בדיוק באיזו תיקייה לחפש.

מבחינה ויזואלית, זה הרבה יותר נקי ומאפשר לך לנהל כל שירות באופן עצמאי (הפעלה, עצירה או עדכון שלו מבלי להשפיע על האחרים). יתר על כן, יישומים כמו Dozzle מנצלים את היתרון של קיומם של מחסניות נפרדות כדי לארגן טוב יותר יומני רישום.

החיסרון הוא שאם מפרידים הכל יותר מדי, תיאום בין שירותים משותפים (כגון Traefik או רשתות משותפות) דורש קצת יותר זהירות : צריך להצהיר על רשתות חיצוניות, תוויות Traefik ספציפיות ולזכור את המינוח של רשתות שנוצרו על ידי docker-compose אחרים.

שיטות עבודה מומלצות עם .env, עקיפות ובקרת גרסאות

אחד הטריקים הכי פחות מוערכים הוא ריכוז הגדרות בקבצי .env . במקום להציף את docker-compose.yml במשתני סביבה, אתה מגדיר משהו כזה:

DB_USERNAME=myuser
DB_PASSWORD=secretpassword

ואז ב-YAML הם מסומנים כ- ${DB_USERNAME} או ${DB_PASSWORD} . זה הופך את Compose לקריא במבט חטוף, מאפשר לך לשתף משתנים בין שירותים מרובים , וחשוב מכל, שומר סיסמאות בקובץ נפרד (אותו תוכל להוציא מ-Git).

עבור סביבות שונות (ייצור, בדיקות, פיתוח), כדאי מאוד למנף את הקובץ docker-compose.override.yml . הרעיון הוא שיהיה קובץ docker-compose.yml בסיסי, וב-override, לעקוף רק את מה שמשתנה: פורטים, נתיבים, דגלי ניפוי שגיאות וכו'.

לדוגמה, בפיתוח ניתן לטעון override שבו חושפים פורט אחר, מאפשרים ניפוי שגיאות (debugging) ומעריכים את קוד המקור המקומי . לא נוגעים ב-YAML הראשי, אלא מתאימים את ה-stack לסביבה שבה מפעילים אותו.

ברור שגרסת הכל עם גיט היא חובה אם אתם רוצים שהמעבדה הביתית שלכם תהיה אפילו מקצועית . בדרך כלל יהיה לכם משהו כזה:

homelab-docker/
├── docker-compose.yml
├── .env.example
├── services/
│   ├── media/
│   ├── infra/
│   └── ...
└── scripts/

משם, אתם מאתחלים את המאגר, מבצעים את השינויים בתשתית, ואם משהו מתקלקל, אתם יכולים לחזור לגרסה קודמת של Compose שלכם תוך שניות . עבור מעבדות ביתיות שאפתניות, זו לא סתם אופציה; זוהי הדרך היחידה להימנע מלהשתגע.

רשתות, Traefik וחשיפת שירות מאובטחת

כמעט בכל מעבדות הבית המתקדמות במידה בינונית, מופיע אותו שילוב: Traefik כ-Reverse Proxy וספק זהויות מרכזי (Auth או Authentik) . זה מאפשר חשיפת אפליקציות רבות תחת תת-דומיינים עם HTTPS ו-SSO.

גישה קלאסית היא להקים רשת Docker ייעודית, כגון reverse_proxy או דומה, שבה Traefik וכל שירותי האינטרנט שתגישו חיצונית מחוברים. שאר הקונטיינרים (מסדי נתונים, מטמונים וכו') נשארים ברשתות פנימיות מבודדות.

אם אתם משתמשים ב-Traefik ומפרידים את השירותים שלכם למופעים שונים של Docker Compose, עליכם להגדיר רשת חיצונית משותפת . משהו כזה:

services:
  bookstack:
    image: lscr.io/linuxserver/bookstack
    networks:
      - traefik-net
    labels:
      - "traefik.docker.network=traefik_default"

networks:
  traefik-net:
    name: traefik_default
    external: true

כאן, רשת traefik_default נוצרת על ידי מחסנית Traefik, והשירותים האחרים מתווספים אליה דרך רשת חיצונית בשם traefik-net. תוויות מציינות ל-Traefik באיזו רשת להשתמש לניתוב תעבורה.

כאשר מחסנית בודדת כוללת שירותי backend (לדוגמה, מיכל אינטרנט ומסד הנתונים שלו), ניתן לחבר אותם לרשת ברירת מחדל משותפת, ולהעניק רק למכולת האינטרנט גישה לרשת Traefik . למסד הנתונים תהיה תווית המוגדרת כ- `traefik.enable=false` כך ש-Traefik יתעלם ממנה.

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

שמירה על נתונים, נפחים ומבנה דיסק

מעבדה ביתית ללא נתונים קבועים אינה שימושית במיוחד: מסדי נתונים, תצורות, מדיה, מסמכים... הכל חייב לשרוד תקלה ב-Docker Compose Down. אמצעי אחסון וחיבורי חיבור הם חבל ההצלה שלך.

אנשים רבים מארגנים את האחסון שלהם באמצעות מבנה כזה:

/mnt/storage/
├── downloads/
│   ├── movies/
│   └── tv/
├── media/
│   ├── movies/
│   ├── tv/
│   └── music/
└── srv/
    └── 

הרעיון הוא שמורידים (qBittorrent, SABnzbd וכו') רואים רק את תיקיית ההורדות , מנהלים כמו Radarr/Sonarr מקבלים גישה גם להורדות וגם למדיה (כדי להעביר/ליצור קישורים קשיחים), ושרתים כמו Plex או Jellyfin רואים רק את תיקיית המדיה.

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

ספריית srv משמשת בדרך כלל לאחסון תצורות אפליקציות (לדוגמה, /srv/jellyfin/config, /srv/traefik, /srv/paperless וכו'). בדרך כלל, ספריית זו עוברת גרסאות חלקיות (תבניות, Caddyfile וכו'), ומשמיטה כל דבר קריטי או עתיר משאבים.

במקרים מסוימים, כדאי להשתמש בקישורים קשיחים בשרשרת ההורדה: שירותים כמו Radarr או Sonarr יכולים לקשר קבצים שהורדו כדי לשמור על זריעה מבלי לשכפל שטח דיסק. מבנה הספריות המוצע על ידי מדריכים כמו TRaSHGuides מבוסס בדיוק על עיקרון זה.

אוטומציה של פריסות עם GitHub Actions ורצים מקומיים

אם אתם רוצים לקחת את הדברים צעד קדימה, תוכלו להפוך את עדכוני homelab לאוטומטיים בעזרת CI/CD . מספר משתמשים החליפו את Jenkins וכלים דומים בתהליך עבודה המשתמש ב-GitHub Actions ורץ המאוחסן באופן עצמאי בתוך homelab עצמו.

המנגנון פשוט: בכל פעם שאתה עובר לענף הראשי של מאגר ה-homelab שלך, מופעלת זרימת עבודה של GitHub Actions שמפעילה בדיקות, מבצעת פעולות (linters), ואם הכל ילך כשורה, פורסת את השינויים בשרת.

תהליך עבודה טיפוסי כולל שלבים כגון:

• סורק סודי מסוג Gitleaksבמקרה שהעלית בטעות סיסמאות או טוקנים למאגר.
• מוך של YAML או קוד תשתית, כדי לשמור על פורמט קריא ועקבי.
• עדכון המאגר בתוך המעבדה הביתית עצמה: git pull בשרת היעד.
• שחזור מבוקר של מכולות: לעצור את הישנים, להפעיל את החדשים ולבדוק את הסטטוס.

יתרונות: אבטחה נוספת (אתה שולט בדליפות של סודות), איכות קוד טובה יותר ופריסות חוזרות בלחיצה אחת . ומכיוון שאתה משתמש ב-runner מקומי, התמונות והנפחים לא עוזבים את הרשת שלך; אתה פשוט ממנפ את ממשק GitHub כדי להמחיש את הצינורות.

למה Docker Compose הופך את החיים להרבה יותר קלים במעבדה ביתית

אנשים רבים בילו שנים בהסתמכות על Docker Run ו-Portainer עד שבעקבות תקרית או הגירה, הם נאלצו להעריך מחדש את גישתם. כאשר מאבדים מארח או צריכים להעביר שירותים למכונה אחרת, הסתמכות על פקודות או תצורות מבודדות אך ורק בתוך Portainer היא מלכודת.

ההבדל הגדול כשעוברים ל-Compose הוא שכל הגדרת השירות הופכת לטקסט : אמצעי אחסון, פורטים, רשתות, תוויות, משתנים... הכל בקובץ YAML שניתן להעתיק, לשתף, ליצור גרסאות ולעשות בו שימוש חוזר.

עריכת שירות כבר אינה עוסקת ב"בנייה מחדש ידנית של קונטיינר"; כעת מדובר בשינוי שורה בקובץ, שמירה והרצה של `docker compose up -d` . אינך צריך לזכור את הפקודה המקורית או ללחוץ על מספר מסכי Portainer.

יתר על כן, אם אתם עובדים עם מספר שרתים (מיני PC, NAS, מחשבים שולחניים), נוח מאוד להיות מסוגלים להעתיק את אותו קובץ Compose למחשב אחר, להתאים ארבעה נתיבים ולהריץ את אותה מחסנית על חומרה שונה . למעשה, אנשים רבים מכירים בכך שאחרי תקלה הכרוכה באובדן נתונים או העברות כאוטיות, Compose חסך להם זמן רב באירועים עתידיים.

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

אופטימיזציה: הקשר בנייה, בניות מרובות שלבים ומשאבים

למרות שרבים מהמכולות של Homelab מגיעות מתמונות ציבוריות, במקרים מסוימים תצטרכו לקמפל תמונות משלכם. במקרים אלה, חשוב לנהל את הקשר הבנייה שלכם : אל תעלו את כל המאגר ללא סינון, אלא הגבילו את עצמכם לתיקיית הפרויקט שלכם (תוך שימוש בהוראת `.dockerignore` חזקה) כדי להבטיח בניות מהירות וקלות משקל.

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

בצד של Compose, יש לך אפשרות להגדיר מגבלות CPU ו-RAM (במיוחד בסביבות Swarm או כאשר Docker מכבד פרמטרים אלה) כדי למנוע מאפליקציות עתירות משאבים לצרוך משאבים. ב-Homelabs, זה עוזר למנוע משירות שתצורתו אינה נכונה לשתק את שאר המערכת.

אל תשכחו את מדיניות ההפעלה מחדש (הפעלה מחדש: תמיד, אלא אם כן מופסק, בעת כשל): בעזרתן אתם מבטיחים ששירותים קריטיים (פרוקסי הפוך, VPN, מסדי נתונים מרכזיים) יופעלו מחדש באופן אוטומטי לאחר אתחול מחדש או כשל חד פעמי.

לבסוף, מומלץ לתזמן משימות ניקוי תקופתיות עם פקודות כגון docker image prune, docker container prune ו-docker volume prune כדי להסיר שאריות של בניות ישנות, מכולות שהופסקו או אמצעי אחסון יתומים ובכך לשחזר שטח דיסק.

שירותי בריאות, רישום וניטור

כדי למנוע מהמעבדה הביתית שלך להפוך לקופסה שחורה, חשוב לעבוד על שלושה היבטים מרכזיים: בדיקות תקינות, רישום מבוקר וניטור . Docker Compose מאפשר לך להצהיר על בדיקות תקינות לכל שירות (באמצעות פקודות כמו `curl -f http://localhost` או סקריפטים ספציפיים) שקובעים האם מכולה תקינה.

זה מאפשר לך להבטיח שרק קונטיינרים "תקינים" יקבלו תעבורה (לדוגמה, דרך Traefik) ושאם הם מפסיקים להגיב, הם יופעלו מחדש בהתאם למדיניות שהוגדרה. זה מגביר משמעותית את החוסן במאמץ מינימלי.

בנוגע ללוגים, התאמת מנהל ההתקן של קובץ ה-json עם מגבלות הגודל המקסימלי והקובץ המקסימלי מונעת מהדיסק להתמלא בגיגה-בייט של לוגים שנשכחו. כלי אינטרנט כמו Dozzle עוזרים לך לדפדף בלוגים של כל המכולות מדפדפן, וזה מאוד נוח לאיתור באגים בשירותים ספציפיים.

עבור מדדים וניטור רציף, השילוב הקלאסי הוא cAdvisor + Prometheus + Grafana . cAdvisor חושף סטטיסטיקות של שימוש במעבד, זיכרון, דיסק ורשת לכל קונטיינר; Prometheus אוסף אותן מעת לעת, ו-Grafana מציג אותן בלוחות מחוונים אטרקטיביים, עם התראות אם משהו עולה.

מעבדת אחסון ביתית מסודרת היטב כוללת בדרך כלל את Uptime Kuma לבדיקות זמינות (HTTP, ICMP, TCP וכו') ומערכת גיבוי אוטומטית כמו Duplicati להעתקת נתונים קריטיים לדיסקים אחרים או לענן. בדרך זו, אתם יודעים מה קורה, ואם משהו משתבש, אתם לא מאבדים את מה שחשוב.

אבטחה וגישה מרחוק למעבדה הביתית

למרות שבאופן שבו ההתקנה מבוצעת בעצמך, אבטחה אינה אופציונלית. אנשים רבים בוחרים לא לחשוף את ה-NAS שלהם או את שירותיו ישירות לעולם החיצון , מה שמגביל את הגישה מרחוק דרך VPN (WireGuard היא אופציה פופולרית מאוד בשל ביצועיה ופשטותה).

במודל זה, הנתב משמש כשער: רק פורט אקראי נפתח לשרת ה-VPN, ולאחר החיבור, כל הבקשות לשירותים פנימיים עוברות דרך מנהרה מוצפנת . לא Traefik ולא האפליקציות חשופות לאינטרנט ללא סינון מוקדם זה.

אלו שמעדיפים לא לנהל את ה-VPN שלהם פונים לפעמים ל- Cloudflare Tunnel או Tailscale כדי לגשת למעבדה הביתית שלהם מבלי לפתוח פורטים. אלו חלופות נוחות, אם כי אם פרטיות היא בראש סדר העדיפויות שלכם, תצטרכו לשקול אילו מטא-דאטה צדדים שלישיים אלה עשויים לאסוף.

נוהג טוב נוסף הוא להצפין את דיסקי השרת וה-NAS , להחיל תיקונים באופן קבוע ולהגביל עדכונים אוטומטיים (רבים נמנעים מ-Watchtower לטובת עדכונים ידניים מבוקרים). עדיף להיות קצת מאחור אבל עם שליטה מאשר להרוס חצי מ-Homelab בגלל עדכון שלא בדקתם.

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

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