อะไรคือข้อดีของการแยกรันไทม์ของคอนเทนเนอร์ออกเป็นส่วนประกอบเครื่องมือที่แยกจากกัน โดยเฉพาะอย่างยิ่ง เครื่องมือเหล่านี้สามารถเริ่มรวมเข้าด้วยกันเพื่อปกป้องซึ่งกันและกัน
หลายๆ คนสนใจแนวคิดในการสร้างอิมเมจ OCI แบบคอนเทนเนอร์ภายใน หรือระบบที่คล้ายกัน สมมติว่าเรามี CI/CD ที่รวบรวมภาพอย่างต่อเนื่อง /Kubernetes จะค่อนข้างมีประโยชน์ในแง่ของการปรับสมดุลโหลดระหว่างการสร้าง จนกระทั่งเมื่อไม่นานมานี้ คนส่วนใหญ่เพียงแค่ให้คอนเทนเนอร์เข้าถึงซ็อกเก็ต Docker และอนุญาตให้พวกเขาเรียกใช้คำสั่ง docker build สิ่งนี้ไม่ปลอดภัยมาก ที่จริงแล้วมันแย่ยิ่งกว่าการให้รูทหรือ sudo โดยไม่ต้องใช้รหัสผ่าน
นั่นเป็นสาเหตุที่ผู้คนพยายามเรียกใช้ 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 ของเราโดยไม่มีสิทธิ์รูทใดๆ ฟิวส์โอเวอร์เลย์ทำงานได้ค่อนข้างเร็วและมีประสิทธิภาพดีกว่าไดรเวอร์หน่วยเก็บข้อมูล 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 เพื่อติดตั้งพื้นที่จัดเก็บข้อมูลนี้บนเครื่องอื่น และใช้อิมเมจจากเครื่องนั้นโดยไม่ต้องดาวน์โหลดผ่านการดึง เราต้องการที่เก็บข้อมูลนี้เพื่อให้สามารถเชื่อมต่อที่เก็บข้อมูลรูปภาพบางส่วนจากโฮสต์เป็นโวลุ่มและใช้งานภายในคอนเทนเนอร์ได้
# 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 ภายในคอนเทนเนอร์จะไม่ต้องดาวน์โหลดอีกครั้ง และบิลด์ต่อๆ ไปที่ใช้อิมเมจนี้จะสามารถนำสิ่งที่ต้องการจากแคชได้เช่นกัน .
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 ภายในอิมเมจคอนเทนเนอร์ โดยบอกให้ไดรเวอร์หน่วยเก็บข้อมูลใช้ "เพิ่มเติมimagestores" ในโฟลเดอร์ /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 ไม่จำเป็นต้องดาวน์โหลดรูปภาพผ่านการดึงอีกต่อไป ดังนั้นเราจึงยกเลิกขั้นตอนก่อนการเติมประชากรและพร้อมที่จะเปิดตัวคอนเทนเนอร์ทันที
และแน่นอนว่า สามารถใช้ภายในระบบ Kubernetes แบบสดหรือโครงสร้างพื้นฐานคอนเทนเนอร์เพื่อเปิดใช้งานและรันคอนเทนเนอร์ได้ทุกที่โดยไม่ต้องดาวน์โหลดอิมเมจใดๆ ยิ่งไปกว่านั้น รีจีสทรีคอนเทนเนอร์ที่ได้รับคำขอแบบพุชเพื่ออัปโหลดรูปภาพที่อัปเดตไปนั้น จะสามารถส่งรูปภาพนี้ไปยังที่เก็บข้อมูลเครือข่ายที่ใช้ร่วมกันได้โดยอัตโนมัติ ซึ่งรูปภาพนั้นจะพร้อมใช้งานสำหรับทุกโหนดทันที
อิมเมจคอนเทนเนอร์บางครั้งอาจมีขนาดถึงหลายกิกะไบต์ ฟังก์ชันการทำงานของพื้นที่จัดเก็บเพิ่มเติมช่วยให้คุณหลีกเลี่ยงการโคลนอิมเมจดังกล่าวข้ามโหนด และทำให้การเปิดใช้คอนเทนเนอร์แทบจะในทันที
นอกจากนี้ เรากำลังพัฒนาฟีเจอร์ใหม่ที่เรียกว่า Overlay Volume Mounts ซึ่งจะทำให้การสร้างคอนเทนเนอร์เร็วขึ้นอีก
ข้อสรุป
การเรียกใช้ Buildah ภายในคอนเทนเนอร์ใน Kubernetes/CRI-O, Podman หรือแม้แต่ Docker นั้นเป็นไปได้ เรียบง่าย และปลอดภัยกว่าการใช้ docker.socket มาก เราได้เพิ่มความยืดหยุ่นในการทำงานกับอิมเมจอย่างมาก ดังนั้นคุณจึงสามารถเรียกใช้อิมเมจได้หลายวิธีเพื่อปรับสมดุลระหว่างความปลอดภัยและประสิทธิภาพให้เหมาะสม
ฟังก์ชั่นการจัดเก็บข้อมูลเพิ่มเติมช่วยให้คุณเพิ่มความเร็วหรือกำจัดการดาวน์โหลดรูปภาพไปยังโหนดได้อย่างสมบูรณ์
ที่มา: will.com