מה היופי בניתוק זמן הריצה של המכולה לרכיבי כלי עבודה נפרדים? בפרט, ניתן להתחיל לשלב כלים אלו כך שהם מגנים זה על זה.
אנשים רבים נמשכים לרעיון של בניית תמונות OCI מכולות בפנים או מערכת דומה. נניח שיש לנו CI/CD שכל הזמן אוסף תמונות, ואז משהו כמו /Kubernetes יהיה שימושי למדי במונחים של איזון עומסים במהלך בנייה. עד לאחרונה, רוב האנשים פשוט נתנו לקונטיינרים גישה לשקע Docker ואיפשרו להם להפעיל את פקודת ה-docker build. שזה מאוד לא בטוח, למעשה, זה אפילו יותר גרוע מאשר לתת שורש או סודו ללא סיסמה.
לכן אנשים מנסים כל הזמן להפעיל את Buildah בקונטיינר. בקיצור, יצרנו איך, לדעתנו, הכי טוב להפעיל את Buildah בתוך קונטיינר, ופרסם את התמונות המתאימות . בואו נתחיל...
התאמה
תמונות אלו בנויות מ-Dockerfiles, אותם ניתן למצוא במאגר Buildah שבתיקיה .
כאן נשקול .
# 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, מיושם ברמה Linuxליבת המארח, אנו משתמשים בתוכנית בתוך המכולה , מכיוון שכרגע OverlayFS יכול להיטען רק אם אתה מעניק לו הרשאות SYS_ADMIN דרך Linux יכולות. אנחנו רוצים להריץ את קונטיינרים של Buildah שלנו ללא הרשאות root. שכבת ה-Fuse מהירה למדי ומבצעת עבודה טובה יותר ממנהל ההתקן של אחסון 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, וזה דורש הקלה בכללי ה-SE עבור המכולה.Linux ו-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 הפועל במכולה כזו יש אבטחה מקסימלית: הוא לא מקבל הרשאות root על ידי יכולות, וכל המגבלות של SECOMP ו-SE חלות עליו.Linuxניתן להפעיל מכולה כזו אפילו עם בידוד מרחב שמות משתמש על ידי הוספת אפשרות כמו --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
אבטחה. זוהי הדרך הכי פחות מאובטחת לבנות קונטיינרים, מכיוון שהיא מאפשרת לקונטיינר לשנות את אחסון המארח ועלולה להזין לפודמן או ל-CRI-O תמונה זדונית. בנוסף, יש להשבית את SE.Linux הפרדה, כך שתהליכים הפועלים במכולת 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 (שלום, מהירות), אך הוא יכול לכתוב רק לאחסון שלו (שלום, אבטחה). כמו כן, שימו לב שניתן לעשות זאת מבלי להשבית את SE.Linux הפרדה עבור מיכל.
ניואנסים חשובים
בשום פנים ואופן אין למחוק תמונות מהמאגר הבסיסי. אחרת, מיכל 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
