המלצות להפעלת Buildah בתוך מכולה

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

אנשים רבים נמשכים לרעיון של בניית תמונות OCI מכולות בפנים קוברנט או מערכת דומה. נניח שיש לנו CI/CD שכל הזמן אוסף תמונות, ואז משהו כמו רד האט/Kubernetes יהיה שימושי למדי במונחים של איזון עומסים במהלך בנייה. עד לאחרונה, רוב האנשים פשוט נתנו לקונטיינרים גישה לשקע Docker ואיפשרו להם להפעיל את פקודת ה-docker build. לפני מספר שנים הראינושזה מאוד לא בטוח, למעשה, זה אפילו יותר גרוע מאשר לתת שורש או סודו ללא סיסמה.

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

התאמה

תמונות אלו בנויות מ-Dockerfiles, אותם ניתן למצוא במאגר Buildah שבתיקיה buildahimage.
כאן נשקול גרסה יציבה של Dockerfile.

# stable/Dockerfile
#
# Build a Buildah container image from the latest
# stable version of Buildah on the Fedoras Updates System.
# https://bodhi.fedoraproject.org/updates/?search=buildah
# This image can be used to create a secured container
# that runs safely with privileges within the container.
#
FROM fedora:latest

# Don't include container-selinux and remove
# directories used by dnf that are just taking
# up space.
RUN yum -y install buildah fuse-overlayfs --exclude container-selinux; rm -rf /var/cache /var/log/dnf* /var/log/yum.*

# Adjust storage.conf to enable Fuse storage.
RUN sed -i -e 's|^#mount_program|mount_program|g' -e '/additionalimage.*/a "/var/lib/shared",' /etc/containers/storage.conf

במקום OverlayFS, המיושם ברמת ליבת לינוקס המארח, אנו משתמשים בתוכנית בתוך הקונטיינר שכבת פיוז, מכיוון שכרגע OverlayFS יכול לעלות רק אם אתה נותן לו הרשאות SYS_ADMIN באמצעות יכולות Linux. ואנחנו רוצים להפעיל את מכולות ה-Buildah שלנו ללא כל הרשאות שורש. שכבת נתיך עובדת די מהר ובעלת ביצועים טובים יותר מאשר מנהל התקן האחסון של VFS. שימו לב שכאשר מפעילים מיכל Buildah המשתמש ב-Fuse, עליכם לספק את התקן /dev/fuse.

podman run --device /dev/fuse quay.io/buildahctr ...
RUN mkdir -p /var/lib/shared/overlay-images /var/lib/shared/overlay-layers; touch /var/lib/shared/overlay-images/images.lock; touch /var/lib/shared/overlay-layers/layers.lock

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

# Set up environment variables to note that this is
# not starting with user namespace and default to
# isolate the filesystem with chroot.
ENV _BUILDAH_STARTED_IN_USERNS="" BUILDAH_ISOLATION=chroot

לבסוף, על ידי שימוש במשתנה הסביבה BUILDAH_ISOLATION, אנו אומרים למיכל Buildah לפעול עם בידוד chroot כברירת מחדל. כאן אין צורך בבידוד נוסף, כי אנחנו כבר עובדים במיכל. על מנת ש-Buildah תיצור קונטיינרים מופרדים במרחב שמות משלה, נדרשת הרשאת SYS_ADMIN, מה שתדרוש הקלה של כללי ה-SELinux ו-SECCOMP של הקונטיינר, מה שמנוגד להעדפה שלנו לבנות ממיכל מאובטח.

הפעלת Buildah בתוך מכולה

דיאגרמת תמונת המכולות של Buildah שנדונה לעיל מאפשרת לך לשנות בצורה גמישה את שיטות ההשקה של מיכלים כאלה.

מהירות מול בטיחות

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

תמונת המכולה שנדונה לעיל תשמור על האחסון שלה ב-/var/lib/containers. לכן, עלינו לעלות את התוכן לתיקייה הזו, והאופן שבו נעשה זאת ישפיע מאוד על מהירות בניית תמונות מיכל.

בואו נבחן שלוש אפשרויות.

אפשרות 1. אם נדרשת אבטחה מקסימלית, אז עבור כל קונטיינר אתה יכול ליצור תיקיה משלך עבור קונטיינרים/תמונה ולחבר אותה לקונטיינר באמצעות חיבור לנפח. וחוץ מזה, מקם את ספריית ההקשר במיכל עצמו, בתיקייה /build:

# mkdir /var/lib/containers1
# podman run -v ./build:/build:z -v /var/lib/containers1:/var/lib/containers:Z quay.io/buildah/stable
buildah  -t image1 bud /build
# podman run -v /var/lib/containers1:/var/lib/containers:Z quay.io/buildah/stable buildah  push  image1 registry.company.com/myuser
# rm -rf /var/lib/containers1

אבטחה. ל-Buildah שפועל בקונטיינר כזה יש אבטחה מקסימלית: לא ניתנות לו הרשאות שורש בשימוש ביכולות, וכל ההגבלות של SECOMP ו-SELinux חלות עליו. ניתן להפעיל קונטיינר כזה עם בידוד User Namespace על ידי הוספת אפשרות כמו —uidmap 0: 100000:10000.

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

אפשרות 2. אם אתה צריך ביצועים ברמת Docker, אתה יכול להרכיב את המכולה/אחסון המארח ישירות לתוך הקונטיינר.

# podman run -v ./build:/build:z -v /var/lib/containers:/var/lib/containers --security-opt label:disabled quay.io/buildah/stable buildah  -t image2 bud /build
# podman run -v /var/lib/containers:/var/lib/containers --security-opt label:disabled  quay.io/buildah/stable buildah push image2 registry.company.com/myuser

אבטחה. זו הדרך הכי פחות בטוחה לבנות קונטיינרים מכיוון שהיא מאפשרת למכולה לשנות את האחסון במארח ועלולה להאכיל את Podman או CRI-O בתמונה זדונית. בנוסף, תצטרך להשבית את הפרדת SELinux כדי שתהליכים במיכל Buildah יוכלו לקיים אינטראקציה עם האחסון במארח. שים לב שהאפשרות הזו עדיין עדיפה על שקע Docker מכיוון שהמכולה נעולה על ידי שאר תכונות האבטחה ולא יכולה פשוט להריץ קונטיינר על המארח.

ביצועים. כאן זה מקסימלי, מכיוון שהמטמון נמצא בשימוש מלא. אם Podman או CRI-O כבר הורידו את התמונה הנדרשת למארח, אז תהליך ה-Buildah בתוך הקונטיינר לא יצטרך להוריד אותה שוב, ו-builds עוקבים המבוססים על תמונה זו יוכלו גם לקחת את מה שהם צריכים מהמטמון .

אפשרות 3. המהות של שיטה זו היא לשלב מספר תמונות לפרויקט אחד עם תיקייה משותפת לתמונות מיכל.

# mkdir /var/lib/project3
# podman run --security-opt label_level=s0:C100, C200 -v ./build:/build:z 
-v /var/lib/project3:/var/lib/containers:Z quay.io/buildah/stable buildah  -t image3 bud /build
# podman run --security-opt label_level=s0:C100, C200 
-v /var/lib/project3:/var/lib/containers quay.io/buildah/stable buildah push image3  registry.company.com/myuser

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

אבטחה. משהו בין אפשרויות 1 ו-2. מצד אחד, לקונטיינרים אין גישה לתוכן במארח, ובהתאם לא ניתן להחליק משהו רע לאחסון התמונות של Podman/CRI-O. מאידך, כחלק מהעיצוב שלו, מיכל יכול להפריע להרכבה של מכולות אחרות.

ביצועים. כאן זה גרוע יותר מאשר בעת שימוש במטמון משותף ברמת המארח, מכיוון שלא ניתן להשתמש בתמונות שכבר הורדו באמצעות Podman/CRI-O. עם זאת, ברגע ש-Buildah מוריד את התמונה, ניתן להשתמש בתמונה בכל בנייה שלאחר מכן בתוך הפרויקט.

אחסון נוסף

У מיכלים/מחסן יש דבר מגניב כמו חנויות נוספות (חנויות נוספות), שבזכותן בעת ​​השקה ובניית מכולות, מנועי מכולות יכולים להשתמש בחנויות תמונות חיצוניות במצב שכבת-על לקריאה בלבד. בעיקרו של דבר, אתה יכול להוסיף אחסון לקריאה בלבד לקובץ storage.conf כך שכאשר אתה מפעיל את המיכל, מנוע המכולה יחפש בהם את התמונה הרצויה. יתר על כן, הוא יוריד את התמונה מהרישום רק אם הוא לא ימצא אותה באף אחד מהאחסוןים הללו. מנוע המכולה יוכל לכתוב רק לאחסון בר כתיבה...

אם תגללו למעלה ותסתכלו על ה-Dockerfile שאנו משתמשים בו כדי לבנות את התמונה quay.io/buildah/stable, ישנן שורות כמו זו:

# Adjust storage.conf to enable Fuse storage.
RUN sed -i -e 's|^#mount_program|mount_program|g' -e '/additionalimage.*/a "/var/lib/shared",' /etc/containers/storage.conf
RUN mkdir -p /var/lib/shared/overlay-images /var/lib/shared/overlay-layers; touch /var/lib/shared/overlay-images/images.lock; touch /var/lib/shared/overlay-layers/layers.lock

בשורה הראשונה, אנו משנים /etc/containers/storage.conf בתוך תמונת המיכל, ואומרים למנהל התקן האחסון להשתמש ב-"additionalimagestores" בתיקיה /var/lib/shared. ובשורה הבאה אנחנו יוצרים תיקיה משותפת ומוסיפים כמה קבצי נעילה כדי שלא תהיה שימוש לרעה ממכולות/אחסון. בעיקרו של דבר, אנחנו פשוט יוצרים חנות תמונות ריק.

אם תרכיב מכולות/אחסון ברמה גבוהה יותר מהתיקייה הזו, Buildah תוכל להשתמש בתמונות.

כעת נחזור לאופציה 2 שנידונה לעיל, כאשר הקונטיינר של Buildah יכול לקרוא ולכתוב לקונטיינרים/חנות במארחים, ובהתאם, יש לו ביצועים מקסימליים עקב אחסון תמונות במטמון ברמת Podman/CRI-O, אך מספק מינימום אבטחה מאז זה יכול לכתוב ישירות לאחסון. עכשיו בואו נוסיף כאן אחסון נוסף ונקבל את הטוב משני העולמות.

# mkdir /var/lib/containers4
# podman run -v ./build:/build:z -v /var/lib/containers/storage:/var/lib/shared:ro -v  /var/lib/containers4:/var/lib/containers:Z  quay.io/buildah/stable 
 buildah  -t image4 bud /build
# podman run -v /var/lib/containers/storage:/var/lib/shared:ro  
-v >/var/lib/containers4:/var/lib/containers:Z quay.io/buildah/stable buildah push image4  registry.company.com/myuser
# rm -rf /var/lib/continers4

שימו לב שה-/var/lib/containers/storage של המארח מותקן ל-/var/lib/shared בתוך הקונטיינר במצב קריאה בלבד. לכן, בעבודה בקונטיינר, Buildah יכולה להשתמש בכל תמונה שהורדה בעבר באמצעות Podman/CRI-O (שלום, מהירות), אך יכולה לכתוב רק לאחסון משלה (שלום, אבטחה). שים לב גם שזה נעשה מבלי לבטל את הפרדת SELinux עבור המיכל.

ניואנסים חשובים

בשום פנים ואופן אין למחוק תמונות מהמאגר הבסיסי. אחרת, מיכל Buildah עלול לקרוס.

ואלה לא כל היתרונות

האפשרויות לאחסון נוסף אינן מוגבלות לתרחיש הנ"ל. לדוגמה, אתה יכול למקם את כל תמונות הקונטיינר באחסון רשת משותף ולתת לו גישה לכל הקונטיינרים של Buildah. נניח שיש לנו מאות תמונות שמערכת ה-CI/CD שלנו משתמשת בהן באופן קבוע לבניית תמונות מיכל. אנו מרכזים את כל התמונות הללו על מארח אחסון אחד ולאחר מכן, באמצעות כלי האחסון המועדפים ברשת (NFS, Gluster, Ceph, ISCSI, S3...), אנו פותחים גישה כללית לאחסון זה לכל צמתי Buildah או Kubernetes.

עכשיו מספיק להרכיב את אחסון הרשת הזה לקונטיינר של Buildah ב-/var/lib/shared וזהו - קונטיינרים של Buildah כבר לא צריכים להוריד תמונות באמצעות pull. לפיכך, אנו זורקים את שלב טרום האכלוס ומוכנים מיד לגלגל את המכולות.

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

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

בנוסף, אנו עובדים כעת על תכונה חדשה הנקראת mounts overlay volume, אשר תהפוך את בניית המיכלים למהירה עוד יותר.

מסקנה

הפעלת Buildah בתוך קונטיינר ב-Kubernetes/CRI-O, Podman, או אפילו Docker היא ריאלית, פשוטה ומאובטחת הרבה יותר מאשר שימוש ב-docker.socket. הגדלנו מאוד את הגמישות בעבודה עם תמונות, כך שתוכל להפעיל אותן במגוון דרכים כדי לייעל את האיזון בין אבטחה לביצועים.

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

מקור: www.habr.com