ຄໍາແນະນໍາສໍາລັບການແລ່ນ Buildah ພາຍໃນຖັງ

ຄວາມງາມຂອງການ decoupling container runtime ເຂົ້າໄປໃນອົງປະກອບເຄື່ອງມືແຍກຕ່າງຫາກແມ່ນຫຍັງ? ໂດຍສະເພາະ, ເຄື່ອງມືເຫຼົ່ານີ້ສາມາດເລີ່ມຕົ້ນປະສົມປະສານເພື່ອໃຫ້ພວກເຂົາປົກປ້ອງກັນແລະກັນ.

ປະ​ຊາ​ຊົນ​ຈໍາ​ນວນ​ຫຼາຍ​ແມ່ນ​ດຶງ​ດູດ​ຄວາມ​ຄິດ​ຂອງ​ການ​ກໍ່​ສ້າງ​ຮູບ​ພາບ OCI containerized ພາຍ​ໃນ Kubernetes ຫຼືລະບົບທີ່ຄ້າຍຄືກັນ. ໃຫ້ເວົ້າວ່າພວກເຮົາມີ CI / CD ທີ່ເກັບກໍາຮູບພາບຢ່າງຕໍ່ເນື່ອງ, ຫຼັງຈາກນັ້ນບາງສິ່ງບາງຢ່າງເຊັ່ນ: RedHat OpenShift/ Kubernetes ຈະເປັນປະໂຫຍດຫຼາຍໃນແງ່ຂອງການດຸ່ນດ່ຽງການໂຫຼດໃນລະຫວ່າງການສ້າງ. ຈົນກ່ວາບໍ່ດົນມານີ້, ຄົນສ່ວນໃຫຍ່ພຽງແຕ່ໃຫ້ containers ເຂົ້າເຖິງ socket Docker ແລະອະນຸຍາດໃຫ້ພວກເຂົາດໍາເນີນການຄໍາສັ່ງສ້າງ docker. ຫຼາຍປີກ່ອນຫນ້ານີ້ພວກເຮົາໄດ້ສະແດງໃຫ້ເຫັນວ່ານີ້ແມ່ນບໍ່ປອດໄພຫຼາຍ, ໃນຄວາມເປັນຈິງ, ມັນກໍ່ຮ້າຍແຮງກວ່າການໃຫ້ root ທີ່ບໍ່ມີລະຫັດຜ່ານຫຼື sudo.

ນັ້ນແມ່ນເຫດຜົນທີ່ຄົນພະຍາຍາມແລ່ນ Buildah ຢູ່ໃນຖັງ. ໃນສັ້ນ, ພວກເຮົາສ້າງ ຕົວຢ່າງ ວິທີການ, ໃນຄວາມຄິດເຫັນຂອງພວກເຮົາ, ແມ່ນດີທີ່ສຸດທີ່ຈະດໍາເນີນການ Buildah ພາຍໃນບັນຈຸ, ແລະຈັດພີມມາຮູບພາບທີ່ສອດຄ້ອງກັນ quay.io/buildah. ມາເລີ່ມກັນເລີຍ...

ການປັບ

ຮູບພາບເຫຼົ່ານີ້ແມ່ນສ້າງຂຶ້ນຈາກ Dockerfiles, ເຊິ່ງສາມາດພົບໄດ້ໃນ Buildah repository ໃນໂຟນເດີ 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, ປະຕິບັດຢູ່ໃນລະດັບໂຮດ Linux kernel, ພວກເຮົາໃຊ້ໂຄງການພາຍໃນບັນຈຸ. fuse-overlay, ເນື່ອງຈາກວ່າໃນປັດຈຸບັນ OverlayFS ສາມາດຕິດຕັ້ງໄດ້ພຽງແຕ່ຖ້າທ່ານໃຫ້ມັນ SYS_ADMIN ອະນຸຍາດໂດຍໃຊ້ຄວາມສາມາດ Linux. ແລະພວກເຮົາຕ້ອງການທີ່ຈະດໍາເນີນການບັນຈຸ Buildah ຂອງພວກເຮົາໂດຍບໍ່ມີການສິດທິພິເສດຮາກ. Fuse-overlay ເຮັດວຽກຂ້ອນຂ້າງໄວແລະມີປະສິດຕິພາບດີກ່ວາໄດເວີບ່ອນເກັບຂໍ້ມູນ 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 container ໃຫ້ແລ່ນດ້ວຍ chroot isolation ໂດຍຄ່າເລີ່ມຕົ້ນ. ທີ່ນີ້ບໍ່ຈໍາເປັນຕ້ອງມີ insulation ເພີ່ມເຕີມ, ເນື່ອງຈາກວ່າພວກເຮົາກໍາລັງເຮັດວຽກຢູ່ໃນບັນຈຸ. ເພື່ອໃຫ້ Buildah ສ້າງກ່ອງບັນຈຸທີ່ແຍກດ້ວຍ namespace ຂອງຕົນເອງ, ຕ້ອງມີສິດທິພິເສດ SYS_ADMIN, ເຊິ່ງຮຽກຮ້ອງໃຫ້ມີການຜ່ອນຄາຍກົດລະບຽບ SELinux ແລະ SECOMP ຂອງຕູ້ຄອນເທນເນີ, ເຊິ່ງກົງກັນຂ້າມກັບຄວາມມັກຂອງພວກເຮົາທີ່ຈະສ້າງຈາກຖັງທີ່ປອດໄພ.

ແລ່ນ Buildah ພາຍໃນຖັງ

ແຜນວາດຮູບພາບຕູ້ຄອນເທນເນີ Buildah ທີ່ສົນທະນາຂ້າງເທິງນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດປ່ຽນແປງວິທີການເປີດຕົວຖັງດັ່ງກ່າວໄດ້.

ຄວາມໄວທຽບກັບຄວາມປອດໄພ

ຄວາມ​ປອດ​ໄພ​ຂອງ​ຄອມ​ພິວ​ເຕີ​ແມ່ນ​ສະ​ເຫມີ​ໄປ​ປະ​ນີ​ປະ​ນອມ​ລະ​ຫວ່າງ​ຄວາມ​ໄວ​ຂອງ​ຂະ​ບວນ​ການ​ແລະ​ການ​ປົກ​ປັກ​ຮັກ​ສາ​ຫຼາຍ​ປານ​ໃດ​ໄດ້​ຖືກ​ຫຸ້ມ​ຫໍ່​ມັນ​. ຄໍາຖະແຫຼງການນີ້ແມ່ນຄວາມຈິງເຊັ່ນດຽວກັນໃນເວລາທີ່ປະກອບພາຊະນະ, ດັ່ງນັ້ນຂ້າງລຸ່ມນີ້ພວກເຮົາຈະພິຈາລະນາທາງເລືອກສໍາລັບການປະນີປະນອມດັ່ງກ່າວ.

ຮູບພາບຕູ້ຄອນເທນເນີທີ່ສົນທະນາຂ້າງເທິງນີ້ຈະເຮັດໃຫ້ການເກັບຮັກສາຂອງມັນຢູ່ໃນ /var/lib/containers. ດັ່ງນັ້ນ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ mount ເນື້ອໃນເຂົ້າໄປໃນໂຟນເດີນີ້, ແລະວິທີການທີ່ພວກເຮົາເຮັດນີ້ຈະມີຜົນກະທົບຢ່າງຫຼວງຫຼາຍຕໍ່ຄວາມໄວຂອງການສ້າງຮູບພາບພາຊະນະ.

ໃຫ້ພິຈາລະນາສາມທາງເລືອກ.

Option 1 ຖ້າຕ້ອງການຄວາມປອດໄພສູງສຸດ, ຫຼັງຈາກນັ້ນສໍາລັບແຕ່ລະຕູ້ຄອນເທນເນີ, ທ່ານສາມາດສ້າງໂຟເດີຂອງທ່ານເອງສໍາລັບຕູ້ຄອນເທນເນີ / ຮູບພາບແລະເຊື່ອມຕໍ່ມັນກັບຖັງຜ່ານ volume-mount. ແລະນອກຈາກນັ້ນ, ວາງ directory context ໃນ container ຕົວຂອງມັນເອງ, ໃນ /build folder:

# 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 ຕ້ອງສົ່ງຮູບພາບໄປຍັງທະບຽນແລະທໍາລາຍເນື້ອຫາໃນເຈົ້າພາບ. ໃນຄັ້ງຕໍ່ໄປການສ້າງຮູບພາບຕູ້ຄອນເທນເນີ, ມັນຈະຕ້ອງໄດ້ຮັບການດາວໂຫຼດຈາກລີຈິດຊີອີກເທື່ອຫນຶ່ງ, ເພາະວ່າໃນເວລານັ້ນຈະບໍ່ມີຫຍັງເຫຼືອຢູ່ໃນເຈົ້າພາບ.

Option 2 ຖ້າທ່ານຕ້ອງການການປະຕິບັດລະດັບ Docker, ທ່ານສາມາດຕິດຕັ້ງ host container/storage ໂດຍກົງໃສ່ຖັງ.

# 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 ພາຍໃນກ່ອງບັນຈຸຈະບໍ່ຕ້ອງດາວໂຫລດມັນອີກເທື່ອຫນຶ່ງ, ແລະການສ້າງຕໍ່ມາໂດຍອີງໃສ່ຮູບພາບນີ້ກໍ່ຈະສາມາດເອົາສິ່ງທີ່ພວກເຂົາຕ້ອງການຈາກ cache. .

Option 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 folder. ແລະໃນແຖວຕໍ່ໄປພວກເຮົາສ້າງໂຟນເດີທີ່ແບ່ງປັນແລະເພີ່ມສອງສາມໄຟລ໌ລັອກເພື່ອບໍ່ໃຫ້ມີການລ່ວງລະເມີດຈາກຕູ້ຄອນເທນເນີ / ການເກັບຮັກສາ. ໂດຍພື້ນຖານແລ້ວ, ພວກເຮົາພຽງແຕ່ສ້າງບ່ອນເກັບຮູບພາບຖັງເປົ່າ.

ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ຕິດ​ບັນ​ຈຸ / ການ​ເກັບ​ຮັກ​ສາ​ໃນ​ລະ​ດັບ​ທີ່​ສູງ​ກ​່​ວາ​ໂຟ​ເດີ​ນີ້​, 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 ພາຍໃນ container ໃນໂໝດອ່ານເທົ່ານັ້ນ. ດັ່ງນັ້ນ, ການເຮັດວຽກຢູ່ໃນຕູ້ຄອນເທນເນີ, Buildah ສາມາດນໍາໃຊ້ຮູບພາບໃດໆທີ່ໄດ້ຖືກດາວໂຫຼດກ່ອນຫນ້ານີ້ໂດຍໃຊ້ Podman / CRI-O (ສະບາຍດີ, ຄວາມໄວ), ແຕ່ພຽງແຕ່ສາມາດຂຽນໃສ່ບ່ອນເກັບມ້ຽນຂອງຕົນເອງ (ສະບາຍດີ, ຄວາມປອດໄພ). ໃຫ້ສັງເກດວ່າອັນນີ້ແມ່ນເຮັດໄດ້ໂດຍບໍ່ມີການປິດການແຍກ SELinux ສໍາລັບບັນຈຸ.

nuance ທີ່​ສໍາ​ຄັນ​

ພາຍໃຕ້ສະຖານະການໃດກໍ່ຕາມທ່ານຄວນລຶບຮູບພາບໃດໆອອກຈາກບ່ອນເກັບມ້ຽນທີ່ຢູ່ເບື້ອງຫຼັງ. ຖ້າບໍ່ດັ່ງນັ້ນ, ຕູ້ຄອນເທນເນີ Buildah ອາດຈະລົ້ມລົງ.

ແລະສິ່ງເຫຼົ່ານີ້ບໍ່ແມ່ນຂໍ້ໄດ້ປຽບທັງຫມົດ

ຄວາມເປັນໄປໄດ້ຂອງການເກັບຮັກສາເພີ່ມເຕີມແມ່ນບໍ່ຈໍາກັດກັບສະຖານະການຂ້າງເທິງ. ຕົວຢ່າງ, ທ່ານສາມາດວາງຮູບພາບບັນຈຸທັງຫມົດໃສ່ບ່ອນເກັບຂໍ້ມູນເຄືອຂ່າຍທີ່ໃຊ້ຮ່ວມກັນແລະໃຫ້ການເຂົ້າເຖິງມັນກັບຖັງ Buildah ທັງຫມົດ. ສົມມຸດວ່າພວກເຮົາມີຫຼາຍຮ້ອຍຮູບທີ່ລະບົບ CI/CD ຂອງພວກເຮົາໃຊ້ເປັນປະຈໍາເພື່ອສ້າງຮູບພາບບັນຈຸ. ພວກເຮົາສຸມໃສ່ຮູບພາບທັງຫມົດເຫຼົ່ານີ້ຢູ່ໃນໂຮດເກັບຂໍ້ມູນຫນຶ່ງແລະຫຼັງຈາກນັ້ນ, ໂດຍໃຊ້ເຄື່ອງມືເກັບຮັກສາເຄືອຂ່າຍທີ່ຕ້ອງການ (NFS, Gluster, Ceph, ISCSI, S3 ...), ພວກເຮົາເປີດການເຂົ້າເຖິງທົ່ວໄປໃນການເກັບຮັກສານີ້ກັບທຸກ Buildah ຫຼື Kubernetes nodes.

ດຽວນີ້ມັນພຽງພໍທີ່ຈະຕິດບ່ອນເກັບຂໍ້ມູນເຄືອຂ່າຍນີ້ເຂົ້າໄປໃນຖັງ Buildah ໃນ /var/lib/shared ແລະນັ້ນແມ່ນມັນ - ກ່ອງບັນຈຸ Buildah ບໍ່ຈໍາເປັນຕ້ອງດາວໂຫລດຮູບພາບໂດຍການດຶງ. ດັ່ງນັ້ນ, ພວກເຮົາຖິ້ມໄລຍະທາງສ່ວນຫນ້າຂອງປະຊາກອນແລະທັນທີພ້ອມທີ່ຈະມ້ວນອອກບັນຈຸ.

ແລະແນ່ນອນ, ນີ້ສາມາດຖືກນໍາໃຊ້ພາຍໃນລະບົບ Kubernetes ທີ່ມີຊີວິດຊີວາຫຼືໂຄງສ້າງພື້ນຖານຂອງຕູ້ຄອນເທນເນີເພື່ອເປີດຕົວແລະແລ່ນຕູ້ຄອນເທນເນີຢູ່ທຸກບ່ອນໂດຍບໍ່ມີການດຶງການດາວໂຫລດຮູບພາບ. ຍິ່ງໄປກວ່ານັ້ນ, ການລົງທະບຽນຕູ້ຄອນເທນເນີ, ໄດ້ຮັບການຮ້ອງຂໍການຊຸກຍູ້ໃຫ້ອັບໂຫລດຮູບພາບທີ່ປັບປຸງໃຫ້ມັນ, ສາມາດສົ່ງຮູບພາບນີ້ໂດຍອັດຕະໂນມັດໄປຫາບ່ອນເກັບຂໍ້ມູນເຄືອຂ່າຍທີ່ແບ່ງປັນ, ບ່ອນທີ່ມັນສາມາດໃຊ້ໄດ້ກັບທຸກ nodes.

ຮູບພາບຕູ້ຄອນເທນເນີບາງຄັ້ງສາມາດບັນລຸຫຼາຍ gigabyte ໃນຂະຫນາດ. ການທໍາງານຂອງການເກັບຮັກສາເພີ່ມເຕີມອະນຸຍາດໃຫ້ທ່ານເພື່ອຫຼີກເວັ້ນການ cloning ຮູບພາບດັ່ງກ່າວໃນທົ່ວ nodes ແລະເຮັດໃຫ້ການເປີດຕົວ containers ເກືອບທັນທີທັນໃດ.

ນອກຈາກນັ້ນ, ພວກເຮົາປະຈຸບັນກໍາລັງເຮັດວຽກກ່ຽວກັບຄຸນສົມບັດໃຫມ່ທີ່ເອີ້ນວ່າ overlay volume mounts, ເຊິ່ງຈະເຮັດໃຫ້ການກໍ່ສ້າງ containers ໄວຂຶ້ນ.

ສະຫລຸບ

ການແລ່ນ Buildah ພາຍໃນກ່ອງບັນຈຸໃນ Kubernetes/CRI-O, Podman, ຫຼືແມ້ກະທັ້ງ Docker ແມ່ນເປັນໄປໄດ້, ງ່າຍດາຍ, ແລະປອດໄພກວ່າການໃຊ້ docker.socket. ພວກເຮົາໄດ້ເພີ່ມຄວາມຍືດຫຍຸ່ນຂອງການເຮັດວຽກກັບຮູບພາບຢ່າງຫຼວງຫຼາຍ, ດັ່ງນັ້ນທ່ານສາມາດດໍາເນີນການໃຫ້ເຂົາເຈົ້າໃນຫຼາຍວິທີທີ່ຈະເພີ່ມປະສິດທິພາບຄວາມສົມດູນລະຫວ່າງຄວາມປອດໄພແລະການປະຕິບັດ.

ການທໍາງານຂອງການເກັບຮັກສາເພີ່ມເຕີມອະນຸຍາດໃຫ້ທ່ານເພື່ອເລັ່ງຫຼືແມ້ກະທັ້ງການລົບລ້າງການດາວໂຫຼດຮູບພາບກັບ nodes.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com