Docker או Podman: Rootless חוסך הרשאות, לא תמיד זיכרון

לשרת Linux שמנהל קונטיינרים כשירותי systemd ומפריד בין חשבונות משתמשים, Podman היא בחירה מתאימה. בפרויקט שתלוי בהתנהגות של Docker Compose ובכלים שניגשים ל־Docker socket, הישארות עם Docker עשויה לחסוך התאמות. גם Docker תומכת ב־rootless: לפי תיעוד Docker, ה־daemon והקונטיינרים יכולים לפעול כמשתמש שאינו root בתוך user namespace.

הבחירה אינה מוכרעת על פי צריכת הזיכרון במצב סרק. במבחן VoxiHost על VPS, שבו רק Podman תוארה במפורש כ־rootless, נמדדו ללא קונטיינרים כ־25 MB ל־Podman מול כ־75 MB ל־Docker, אך עם 50 קונטיינרי Nginx סרק נמדדו כ־460 MB ל־Podman מול כ־320 MB ל־Docker. אלה תוצאות של תצורות ועומסים מסוימים, ולכן היתרון במצב סרק אינו מבטיח יתרון כאשר השירותים פועלים.

הרשאות: מה נותן rootless בכל מנוע

Podman מפעילה פקודות מקומיות ללא daemon מרכזי, וקונטיינרים יכולים להשתייך לחשבון המשתמש שהפעיל אותם. במארח משותף, המבנה הזה מאפשר להפריד את סביבת העבודה של משתמשים שונים בלי להעניק לכולם גישה לאותו שירות ניהול מרכזי. ההפרדה עדיין תלויה בהרשאות של ספריות המארח, ב־volumes שמחברים לקונטיינר ובגישה לשקעים ולרשת.

ב־Docker, מצב rootless משנה גם את הרשאות ה־daemon עצמו; הוא אינו רק שינוי של המשתמש בתוך הקונטיינר. הדבר חשוב במיוחד כאשר מטרת המעבר היא לצמצם את ההרשאות הדרושות להפעלת המנוע, ולא להחליף את הפקודות או את קובצי Compose. התקנת המצב דורשת הכנה של מיפוי מזהי משתמש וקבוצה, ול־daemon של המשתמש יש שקע משלו. לפיכך צוות שכבר עובד היטב עם Docker יכול לבחון את מודל ההרשאות הזה לפני שהוא מחליף מנוע.

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

ביצועים: מצב סרק ועומס פעיל מספרים סיפורים שונים

מנוע שאינו מחזיק daemon מרכזי עשוי לצרוך פחות זיכרון כשהמארח ריק, אבל בשירות פעיל נכללים בחשבון גם תהליכי ניטור, אחסון ורשת. תוצאות ה־VPS שבפתיחה אינן השוואה מבוקרת בין שתי התקנות rootless: המצב הזה צוין במפורש רק עבור Podman. אי אפשר להסיק מהן כמה זיכרון תצרוך כל אחת מהאפשרויות בשרת אחר או באותו יישום לאחר הגירה.

מדריך הביצועים של Podman מונה את ה־OCI runtime, מערכת הקבצים, תמונת הקונטיינר וההגדרות כגורמים שמשנים ביצועים, ומציין שרשת pasta מוסיפה תקורה בהפעלה ללא root. משום כך מדידת זמן build או משיכת image לבדה אינה מתארת שירות שמבלה את רוב זמנו בטיפול בבקשות רשת. גם תוצאה טובה במצב סרק אינה מספרת מה קורה כשהצוות מפעיל את מספר השירותים הרגיל שלו.

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

Compose ו־socket: היכן הגירה דורשת התאמה

דמיון בין פקודות Docker ו־Podman אינו מבטיח שקובץ Compose יתנהג באופן זהה. לפי תיעוד podman compose, הפקודה מפעילה ספק Compose חיצוני, כגון docker-compose או podman-compose, ומאפשרת לו לתקשר עם השקע המקומי של Podman. לכן זהות הספק המותקן היא חלק מהתצורה: אותו קובץ שירותים עלול לעבור דרך מימוש אחר במחשב הפיתוח ובשרת.

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

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

systemd: ניהול השירות בשרת יחיד

בשרת Linux שבו systemd כבר אחראית להפעלת שירותים, Quadlet נותנת ל־Podman דרך להגדיר גם קונטיינרים כחלק מאותו מחזור חיים. תיעוד Quadlet מתאר קובצי הגדרה שמהם נוצרות יחידות systemd לקונטיינרים, לרשתות ול־volumes, וכן נתיבים נפרדים ליחידות של משתמשים ללא root. כך אפשר לקשור את הפעלת הקונטיינר לחשבון וליחידת השירות שאחראים לו.

המעבר מפקודת הפעלה ידנית ליחידת שירות דורש להחליט מי מחזיק את ההגדרה, תחת איזה משתמש היא פועלת ומה יקרה לאחר אתחול המארח או כשל של היישום. אלה גם המקומות שבהם יש לבדוק שהנתונים נשמרים ושהשירות חוזר לפעולה כמצופה. Docker יכולה לפעול לצד systemd, אך צוות שמנהל את שירותי השרת באמצעות יחידות systemd עשוי למצוא ב־Quadlet דרך ישירה יותר לבטא את התלות ביניהם.

הבחירה לפי סביבת העבודה

• שרת Linux יחיד: כאשר לכל יישום יש חשבון ייעודי והשירותים מנוהלים דרך systemd, Podman עם Quadlet מתאימה לניסוי ראשון. אם כלי התפעול הקיימים תלויים ב־Docker API או ב־Compose, יש לכלול את התאמתם במחיר המעבר; Docker במצב rootless עשויה לספק את שינוי ההרשאות המבוקש עם פחות שינוי בכלים.
• מחשב פיתוח: בפרויקט שחי סביב Docker Compose, סקריפטים וכלי אבחון קיימים, יתרון התאימות של סביבת Docker חשוב יותר מהבטחה כללית לחיסכון בזיכרון. Podman היא חלופה סבירה כאשר פרויקט הניסוי פועל עם ספק ה־Compose שנבחר, והכלים שנדרשים לשקע הניהול ממשיכים לעבוד.
• מארח מרובה משתמשים: Podman rootless מתאימה להפרדת קונטיינרים לפי חשבונות בלי שירות ניהול מרכזי משותף. גם Docker rootless אפשרית, ולכן הבחירה תלויה בשאלה מי יקבל גישה לשקע של כל משתמש, אילו ספריות נתונים יחוברו לקונטיינרים וכיצד יופעלו השירותים לאחר אתחול.

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

קראו גם:

• Docker או Podman: הביצועים כמעט זהים, ההרשאות לא
• הודעות חוזרות ב־Slack: Workflow חוסך בניית בוט, לא ניהול הרשאות
• Langfuse או LangSmith: אחסון עצמי חוסך נעילה, לא תחזוקה