Docker או Podman: הביצועים כמעט זהים, ההרשאות לא

מעבר מ־Docker ל־Podman אינו צפוי ליצור פער ביצועים גדול רק בגלל החלפת מנוע המכולות. עבודת הגמר מאוניברסיטת אומאו מ־2020 מצאה פערים קטנים במבחני מעבד, זיכרון ודיסק, לרוב עם יתרון קל ל־Podman; היא נערכה על Dell Latitude E7440 עם מעבד Intel Core i5-4310U וזיכרון של 8 GB, ובדוח רשומות גרסאות Docker 1.3.4 ו־Podman 1.9.1. הניסוי אינו מדידה של שרת ייצור או של יישום מסוים, ולכן הוא מפחית את החשש מפער גדול אך אינו מבטיח תוצאה זהה בעומס שלכם.

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

מה באמת נמדד בביצועים

הניסוי השתמש ב־Y-cruncher למעבד, ב־STREAM לזיכרון וב־Bonnie++ לדיסק והשווה כל מנוע להרצה ישירה על אותה מכונה. התוצאות הוצגו כממוצע של הרצות חוזרות, ובין קבוצות הניסוי המחשב אותחל. Podman הקדים במעט בחלק ניכר מהמבחנים, אבל הפערים קטנים מכדי להסיק יתרון מעשי קבוע בשרת אחר. המדידה לא כללה ביצועי רשת או עומס של שירותים תלויים זה בזה.

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

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

Docker בהתקנה רגילה מפעיל daemon בעל הרשאות root, ואילו מצב rootless בתיעוד Docker מריץ גם את ה־daemon וגם את המכולות בתוך user namespace של משתמש שאינו root. Podman יכול להריץ מכולות מקומיות תחת משתמש רגיל ללא daemon מרכזי קבוע. לפיכך בדיקת ההרשאות צריכה להבחין בין Docker רגיל, Docker rootless ו־Podman rootless; הפעלת פקודת docker בלי sudo לבדה אינה מספרת באיזה מצב השרת פועל.

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

Compose: בחרו ספק לפני בדיקת הקובץ

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

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

Volumes ופורטים: היכן המעבר משנה התנהגות

ב־rootless, UID ו־GID בתוך המכולה עשויים להיות ממופים לערכים אחרים במארח. תיעוד podman run מסביר ש־:U משנה בעלות על מקור ה־volume באופן רקורסיבי, וש־:z ו־:Z משנים תוויות SELinux לשיתוף או לשימוש פרטי. לכן אין להוסיף :U לנתיב נתוני ייצור כפתרון אוטומטי לבעיית כתיבה: הוא משנה את קובצי המארח עצמם, ועלול להשפיע על גיבוי או על שירות אחר שמשתמש בהם.

בדיקת אחסון טובה מתחילה בנתונים קיימים: פתחו אותם מתוך המכולה, כתבו שינוי, הפעילו מחדש ובדקו שהבעלות והגישה עדיין מתאימות. הפרידו בין bind mount של ספריית מארח לבין volume בעל שם; אלה מקורות שונים, עם בעלות ומחזור חיים שונים. בשרת שמפעיל SELinux, שגיאת גישה עשויה לנבוע מתווית ולא מ־UID, ולכן בדקו את שניהם לפני שינוי הרשאות גורף.

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

CI: ה־socket הוא חלק ממודל ההרשאות

כלי בנייה שמשתמש ב־Docker API אינו חייב לעבוד ללא התאמה עם Podman. תיעוד שירות ה־API של Podman מתאר שכבת תאימות ל־Docker, socket נפרד להפעלה rootless וגישה מלאה לפעולות Podman תחת המשתמש שמריץ את השירות. חיבור socket ל־runner או למכולת build מאפשר להם לבצע פעולות בשם אותו משתמש; שינוי DOCKER_HOST לבדו אינו תחליף לבדיקת גבול הגישה הזה.

הריצו בצינור ה־CI את הרצף האמיתי: בניית image, שליחה ל־registry, העלאת שירותי הבדיקה, בדיקות וניקוי. בדקו באיזו זהות רץ ה־runner, לאיזה socket הוא מתחבר והאם האימות מול ה־registry זמין גם בלי התחברות אינטראקטיבית. לאחר אתחול המארח, ודאו ששירות ה־API או תהליך ה־runner זמינים בדרך שבה הצינור מצפה להם. מעבר שעובד בתחנת פיתוח אך נכשל בשלב ניקוי או הפעלה מחדש עדיין אינו מוכן לשרת.

מתי המעבר כדאי

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