{"id":38785,"date":"2019-10-31T22:25:55","date_gmt":"2019-10-31T19:25:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rekomendatsii-po-zapusku-buildah-vnutri-kontejnera\/"},"modified":"2019-10-31T22:25:55","modified_gmt":"2019-10-31T19:25:55","slug":"rekomendatsii-po-zapusku-buildah-vnutri-kontejnera","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/rekomendatsii-po-zapusku-buildah-vnutri-kontejnera","title":{"rendered":"Zalecenia dotycz\u0105ce uruchamiania Buildah wewn\u0105trz kontenera","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Jaka jest zaleta podzia\u0142u \u015brodowiska uruchomieniowego kontener\u00f3w na oddzielne elementy narz\u0119dziowe? Przede wszystkim polega on na tym, \u017ce te narz\u0119dzia mo\u017cna rozpocz\u0105\u0107 \u0142\u0105czy\u0107, aby mog\u0142y si\u0119 wzajemnie chroni\u0107.<\/p>\n

\"Zalecenia
\n
\nWielu os\u00f3b przyci\u0105ga pomys\u0142 kompilacji kontenerowych obraz\u00f3w OCI w ramach Kubernetes<\/a><\/noindex> lub podobnego systemu. Za\u0142\u00f3\u017cmy, \u017ce mamy CI\/CD, kt\u00f3re nieprzerwanie kompiluje obrazy, w\u00f3wczas co\u015b takiego jak Red Hat OpenShift<\/a><\/noindex>\/Kubernetes \u0431\u044b\u043b\u043e \u0431\u044b \u0432\u0435\u0441\u044c\u043c\u0430 \u043f\u043e\u043b\u0435\u0437\u043d\u043e \u0441 \u0442\u043e\u0447\u043a\u0438 \u0437\u0440\u0435\u043d\u0438\u044f \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u0438\u044f \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0438 \u043f\u0440\u0438 \u0441\u0431\u043e\u0440\u043a\u0435. \u0414\u043e \u043d\u0435\u0434\u0430\u0432\u043d\u0438\u0445 \u043f\u043e\u0440 \u0431\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043b\u044e\u0434\u0435\u0439 \u043f\u0440\u043e\u0441\u0442\u043e \u0434\u0430\u0432\u0430\u043b\u0438 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430\u043c \u0434\u043e\u0441\u0442\u0443\u043f \u043a Docker-\u0441\u043e\u043a\u0435\u0442\u0443 \u0438 \u0440\u0430\u0437\u0440\u0435\u0448\u0430\u043b\u0438 \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0442\u044c \u043a\u043e\u043c\u0430\u043d\u0434\u0443 docker build. Pokazywali\u015bmy ju\u017c kilka lat temu<\/a><\/noindex>, \u017ce jest to bardzo niebezpieczne, w rzeczywisto\u015bci nawet gorsze ni\u017c udost\u0119pnienie has\u0142a do roota czy sudo.
\n<\/a><\/noindex>
\nDlatego ludzie ci\u0105gle pr\u00f3buj\u0105 uruchamia\u0107 Buildah w kontenerze. Kr\u00f3tko m\u00f3wi\u0105c, stworzyli\u015bmy przyk\u0142ad<\/a><\/noindex> naszym zdaniem najlepszy spos\u00f3b uruchamiania Buildah wewn\u0105trz kontenera i udost\u0119pnili\u015bmy odpowiednie obrazy na quay.io\/buildah<\/a><\/noindex>. Zaczynajmy\u2026<\/p>\n

Konfiguracja<\/h3>\n

\nTe obrazy s\u0105 zbudowane na podstawie Dockerfile, kt\u00f3re mo\u017cna znale\u017a\u0107 w repozytorium Buildah w folderze buildahimage<\/a><\/noindex>.
\nTutaj przyjrzymy si\u0119 stabilnej wersji Dockerfile<\/a><\/noindex>.<\/p>\n

# stable\/Dockerfile\n#\n# Build a Buildah container image from the latest\n# stable version of Buildah on the Fedoras Updates System.\n# https:\/\/bodhi.fedoraproject.org\/updates\/?search=buildah\n# This image can be used to create a secured container\n# that runs safely with privileges within the container.\n#\nFROM fedora:latest\n\n# Don't include container-selinux and remove\n# directories used by dnf that are just taking\n# up space.\nRUN yum -y install buildah fuse-overlayfs --exclude container-selinux; rm -rf \/var\/cache \/var\/log\/dnf* \/var\/log\/yum.*\n\n# Adjust storage.conf to enable Fuse storage.\nRUN sed -i -e 's|^#mount_program|mount_program|g' -e '\/additionalimage.*\/a \"\/var\/lib\/shared\",' \/etc\/containers\/storage.conf\n<\/code><\/pre>\n
\nZamiast OverlayFS, kt\u00f3ry jest wdra\u017cany na poziomie j\u0105dra Linuxa gospodarza, u\u017cywamy wewn\u0105trz kontenera programu fuse-overlay<\/a><\/noindex>, poniewa\u017c aktualnie OverlayFS mo\u017ce montowa\u0107, tylko je\u015bli otrzyma uprawnienia SYS_ADMIN za pomoc\u0105 mo\u017cliwo\u015bci Linux. A my chcemy uruchamia\u0107 nasze kontenery Buildah bez jakichkolwiek uprawnie\u0144 roota. Fuse-overlay dzia\u0142a do\u015b\u0107 szybko i pod wzgl\u0119dem wydajno\u015bci jest lepsze ni\u017c sterownik storage VFS. Nale\u017cy pami\u0119ta\u0107, \u017ce uruchamiaj\u0105c kontener Buildah, kt\u00f3ry u\u017cywa Fuse, trzeba udost\u0119pni\u0107 urz\u0105dzenie \/dev\/fuse.<\/p>\n
podman run --device \/dev\/fuse quay.io\/buildahctr ...\nRUN 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\n<\/code><\/pre>\n
\nNast\u0119pnie tworzymy katalog dla dodatkowych magazyn\u00f3w. Container\/storage<\/a><\/noindex> wspiera koncepcj\u0119 pod\u0142\u0105czania dodatkowych read-only magazyn\u00f3w obraz\u00f3w. Na przyk\u0142ad mo\u017cna skonfigurowa\u0107 obszar magazynowania overlay na jednej maszynie, a nast\u0119pnie podmontowa\u0107 ten magazyn na innej maszynie za pomoc\u0105 NFS i u\u017cywa\u0107 obraz\u00f3w z niego bez pobierania przez pull. Potrzebujemy tego magazynu, aby mie\u0107 mo\u017cliwo\u015b\u0107 pod\u0142\u0105czenia jako wolumenu jakiego\u015b magazynu obraz\u00f3w z gospodarza i u\u017cywania go wewn\u0105trz kontenera.<\/p>\n
# Set up environment variables to note that this is\n# not starting with user namespace and default to\n# isolate the filesystem with chroot.\nENV _BUILDAH_STARTED_IN_USERNS=\"\" BUILDAH_ISOLATION=chroot\n<\/code><\/pre>\n
\nNa koniec, u\u017cywaj\u0105c zmiennej \u015brodowiskowej BUILDAH_ISOLATION, m\u00f3wimy, \u017ce domy\u015blnie kontener Buildah powinien by\u0107 uruchamiany w izolacji chroot. Dodatkowa izolacja nie jest tutaj wymagana, poniewa\u017c pracujemy ju\u017c w kontenerze. Aby Buildah m\u00f3g\u0142 tworzy\u0107 w\u0142asne kontenery z podzia\u0142em przestrzeni nazw, wymagana jest zgoda SYS_ADMIN, co oznacza, \u017ce b\u0119dziemy musieli z\u0142agodzi\u0107 zasady SELinux i SECCOMP dla kontenera, co jest sprzeczne z naszym podej\u015bciem do budowy z bezpiecznego kontenera.<\/p>\n
Uruchamiamy Buildah wewn\u0105trz kontenera<\/h3>\n
\nRozwa\u017cony powy\u017cej schemat obrazu kontenera Buildah pozwala elastycznie dostosowa\u0107 sposoby uruchamiania takich kontener\u00f3w.<\/p>\n
Szybko\u015b\u0107 kontra bezpiecze\u0144stwo<\/h4>\n
\nBezpiecze\u0144stwo komputerowe to zawsze kompromis mi\u0119dzy szybko\u015bci\u0105 realizacji a ilo\u015bci\u0105 ochrony wok\u00f3\u0142. To stwierdzenie jest prawdziwe r\u00f3wnie\u017c podczas budowy kontener\u00f3w, dlatego poni\u017cej rozwa\u017cymy opcje takiego kompromisu.<\/p>\n
Rozwa\u017cony powy\u017cej obraz kontenera b\u0119dzie przechowywa\u0142 swoje magazyny w \/var\/lib\/containers. Dlatego musimy zamontowa\u0107 zawarto\u015b\u0107 w tym folderze, a to, jak to zrobimy, ma znacz\u0105cy wp\u0142yw na szybko\u015b\u0107 budowy obraz\u00f3w kontenerowych.<\/p>\n
Rozwa\u017cmy trzy opcje.<\/p>\n
Opcja 1.<\/b> Je\u015bli wymagana jest maksymalna ochrona, dla ka\u017cdego kontenera mo\u017cna stworzy\u0107 osobny folder dla containers\/image i pod\u0142\u0105czy\u0107 go do kontenera przez volume-mount. Dodatkowo, umieszczony kontekst katalogu w samym kontenerze, w folderze \/build:<\/p>\n
# mkdir \/var\/lib\/containers1\n# podman run -v .\/build:\/build:z -v \/var\/lib\/containers1:\/var\/lib\/containers:Z quay.io\/buildah\/stable\nbuildah  -t image1 bud \/build\n# podman run -v \/var\/lib\/containers1:\/var\/lib\/containers:Z quay.io\/buildah\/stable buildah  push  image1 registry.company.com\/myuser\n# rm -rf \/var\/lib\/containers1\n<\/code><\/pre>\n
\nBezpiecze\u0144stwo.<\/i> Praca w takim kontenerze Buildah zapewnia maksymalne bezpiecze\u0144stwo: nie maj\u0105 one \u017cadnych przywilej\u00f3w roota dzi\u0119ki mechanizmom capabilities, a do kontenera stosowane s\u0105 wszystkie ograniczenia SECOMP i SELinux. Taki kontener mo\u017cna nawet uruchomi\u0107 z izolacj\u0105 User Namespace, dodaj\u0105c opcj\u0119 typu --uidmap 0:100000:10000.<\/p>\n
Wydajno\u015b\u0107.<\/i> Wydajno\u015b\u0107 jest jednak minimalna, poniewa\u017c wszelkie obrazy z rejestr\u00f3w kontener\u00f3w s\u0105 za ka\u017cdym razem kopiowane na hosta, a pami\u0119\u0107 podr\u0119czna nie dzia\u0142a w og\u00f3le. Ko\u0144cz\u0105c swoj\u0105 prac\u0119, kontener Buildah powinien wys\u0142a\u0107 obraz do rejestru i usun\u0105\u0107 zawarto\u015b\u0107 na ho\u015bcie. Kiedy obraz kontenera b\u0119dzie budowany nast\u0119pnym razem, b\u0119dzie musia\u0142 by\u0107 pobierany ponownie z rejestru, poniewa\u017c na ho\u015bcie w tym czasie nie zostanie nic.<\/p>\n
Wariant 2.<\/b> Je\u015bli potrzebna jest wydajno\u015b\u0107 na poziomie Dockera, mo\u017cna pod\u0142\u0105czy\u0107 container\/storage hosta bezpo\u015brednio do kontenera.<\/p>\n
# 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\n# podman run -v \/var\/lib\/containers:\/var\/lib\/containers --security-opt label:disabled  quay.io\/buildah\/stable buildah push image2 registry.company.com\/myuser\n<\/code><\/pre>\n
\nBezpiecze\u0144stwo.<\/i> To najbezpieczniejszy spos\u00f3b budowania kontener\u00f3w, poniewa\u017c kontener ma mo\u017cliwo\u015b\u0107 modyfikacji zasob\u00f3w na ho\u015bcie i potencjalnie mo\u017ce wprowadzi\u0107 z\u0142o\u015bliwy obraz do Podmana lub CRI-O. Ponadto konieczne b\u0119dzie wy\u0142\u0105czenie separacji SELinux, aby procesy w kontenerze Buildah mog\u0142y komunikowa\u0107 si\u0119 z zasobami na ho\u015bcie. Nale\u017cy pami\u0119ta\u0107, \u017ce ta opcja wci\u0105\u017c jest lepsza od gniazda Dockera, poniewa\u017c kontener jest chroniony przez pozosta\u0142e funkcje bezpiecze\u0144stwa i nie mo\u017ce po prostu wzi\u0105\u0107 i uruchomi\u0107 jakiegokolwiek kontenera na ho\u015bcie.<\/p>\n
Wydajno\u015b\u0107.<\/i> Tutaj jest to maksymalne, poniewa\u017c ca\u0142kowicie wykorzystuje pami\u0119\u0107 podr\u0119czn\u0105. Je\u015bli Podman lub CRI-O zd\u0105\u017cy\u0142y ju\u017c pobra\u0107 potrzebny obraz na hosta, proces Buildah wewn\u0105trz kontenera nie b\u0119dzie musia\u0142 pobiera\u0107 go ponownie, a nast\u0119pne budowy na podstawie tego obrazu r\u00f3wnie\u017c b\u0119d\u0105 mog\u0142y skorzysta\u0107 z pami\u0119ci podr\u0119cznej.<\/p>\n
Opcja 3.<\/b> Istot\u0105 tego sposobu jest po\u0142\u0105czenie kilku obraz\u00f3w w jeden projekt z wsp\u00f3lnym folderem dla kontenerowych obraz\u00f3w.<\/p>\n
# mkdir \/var\/lib\/project3\n# podman run --security-opt label_level=s0:C100, C200 -v .\/build:\/build:z \n-v \/var\/lib\/project3:\/var\/lib\/containers:Z quay.io\/buildah\/stable buildah  -t image3 bud \/build\n# podman run --security-opt label_level=s0:C100, C200 \n-v \/var\/lib\/project3:\/var\/lib\/containers quay.io\/buildah\/stable buildah push image3  registry.company.com\/myuser\n<\/code><\/pre>\n
\nW tym przyk\u0142adzie nie usuwamy folderu projektu (\/var\/lib\/project3) mi\u0119dzy uruchomieniami, dlatego wszystkie nast\u0119pne budowy w ramach projektu korzystaj\u0105 z zalet pami\u0119ci podr\u0119cznej.<\/p>\n
Bezpiecze\u0144stwo.<\/i> Co\u015b pomi\u0119dzy opcjami 1 i 2. Z jednej strony, kontenery nie maj\u0105 dost\u0119pu do zawarto\u015bci na ho\u015bcie i nie mog\u0105 w zwi\u0105zku z tym wprowadzi\u0107 nic z\u0142ego do magazynu obraz\u00f3w Podmana\/CRI-O. Z drugiej strony, w ramach swojego projektu kontener mo\u017ce ingerowa\u0107 w budow\u0119 innych kontener\u00f3w.<\/p>\n
Wydajno\u015b\u0107.<\/i> Tutaj jest to gorsze ni\u017c w przypadku u\u017cycia wsp\u00f3lnej pami\u0119ci podr\u0119cznej na poziomie hosta, poniewa\u017c nie mo\u017cna korzysta\u0107 z obraz\u00f3w, kt\u00f3re ju\u017c wcze\u015bniej pobrano za pomoc\u0105 Podmana\/CRI-O. Jednak po tym, jak Buildah pobierze obraz, mo\u017ce on by\u0107 u\u017cyty w dowolnych kolejnych budowach w ramach projektu.<\/p>\n
Dodatkowe magazyny<\/h4>\n
\nU containers\/storage<\/a><\/noindex> Istnieje co\u015b takiego jak dodatkowe magazyny (additional stores), dzi\u0119ki kt\u00f3rym przy uruchamianiu i budowaniu kontener\u00f3w, silniki kontenerowe mog\u0105 u\u017cywa\u0107 zewn\u0119trznych magazyn\u00f3w obraz\u00f3w w trybie read-only overlay. W zasadzie, do pliku storage.conf mo\u017cna doda\u0107 jedno lub wi\u0119cej magazyn\u00f3w \u201etylko do odczytu\u201d, aby podczas uruchamiania kontenera silnik kontenerowy szuka\u0142 w nich potrzebnego obrazu. Oczywi\u015bcie pobierze obraz z rejestru tylko w przypadku, gdy nie znajdzie go w \u017cadnym z tych magazyn\u00f3w. Silnik kontenerowy b\u0119dzie m\u00f3g\u0142 pisa\u0107 tylko w dost\u0119pnych do zapisu magazynach\u2026<\/p>\n
Je\u015bli przewiniesz w g\u00f3r\u0119 i spojrzysz na Dockerfile, kt\u00f3ry u\u017cywamy do budowania obrazu quay.io\/buildah\/stable, to znajdziesz tam takie linie:<\/p>\n
# Adjust storage.conf to enable Fuse storage.\nRUN sed -i -e 's|^#mount_program|mount_program|g' -e '\/additionalimage.*\/a \"\/var\/lib\/shared\",' \/etc\/containers\/storage.conf\nRUN 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\n<\/code><\/pre>\n
\nW pierwszej linii modyfikujemy \/etc\/containers\/storage.conf wewn\u0105trz obrazu kontenera, informuj\u0105c sterownik storage, aby u\u017cywa\u0142 \u2018additionalimagestores\u2019 w folderze \/var\/lib\/shared. A w nast\u0119pnej linii tworzymy wsp\u00f3lny folder i dodajemy par\u0119 plik\u00f3w blokad, aby unikn\u0105\u0107 konflikt\u00f3w ze strony containers\/storage. W istocie, po prostu tworzymy pusty magazyn obraz\u00f3w kontener\u00f3w. <\/p>\n
Je\u015bli zamontowa\u0107 containers\/storage wy\u017cej w hierarchii tego folderu, Buildah b\u0119dzie mog\u0142o u\u017cywa\u0107 obraz\u00f3w.<\/p>\n
Teraz wr\u00f3\u0107my do rozwa\u017canego powy\u017cej wariantu 2, gdy kontener Buildah mo\u017ce czyta\u0107 i pisa\u0107 w containers\/store na hostach i, w konsekwencji, ma maksymaln\u0105 wydajno\u015b\u0107 dzi\u0119ki buforowaniu obraz\u00f3w na poziomie Podman\/CRI-O, ale daje minimalne bezpiecze\u0144stwo, poniewa\u017c mo\u017ce pisa\u0107 bezpo\u015brednio do magazyn\u00f3w. A teraz dodajmy do tego dodatkowe magazyny i uzyskamy to, co najlepsze z dw\u00f3ch \u015bwiat\u00f3w.<\/p>\n
# mkdir \/var\/lib\/containers4\n# 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 \n buildah  -t image4 bud \/build\n# podman run -v \/var\/lib\/containers\/storage:\/var\/lib\/shared:ro  \n-v >\/var\/lib\/containers4:\/var\/lib\/containers:Z quay.io\/buildah\/stable buildah push image4  registry.company.com\/myuser\n# rm -rf \/var\/lib\/continers4\n<\/code><\/pre>\n
\nZauwa\u017c, \u017ce \/var\/lib\/containers\/storage hosta jest zamontowane w \/var\/lib\/shared wewn\u0105trz kontenera w trybie read-only. Dlatego pracuj\u0105c w kontenerze, Buildah mo\u017ce u\u017cywa\u0107 wszelkich obraz\u00f3w, kt\u00f3re wcze\u015bniej zosta\u0142y pobrane za pomoc\u0105 Podman\/CRI-O (cze\u015b\u0107, szybko\u015b\u0107), ale mo\u017ce pisa\u0107 tylko w swoim w\u0142asnym magazynie (cze\u015b\u0107, bezpiecze\u0144stwo). Zauwa\u017c r\u00f3wnie\u017c, \u017ce odbywa si\u0119 to bez wy\u0142\u0105czania separacji SELinux dla kontenera.<\/p>\n
Wa\u017cny szczeg\u00f3\u0142<\/h4>\n
\nW \u017cadnym wypadku nie nale\u017cy usuwa\u0107 \u017cadnych obraz\u00f3w z ni\u017cszego magazynu. W przeciwnym razie kontener Buildah mo\u017ce si\u0119 wywali\u0107.<\/p>\n
I to wcale nie wszystkie zalety<\/h4>\n
\nMo\u017cliwo\u015bci dodatkowych magazyn\u00f3w nie ograniczaj\u0105 si\u0119 tylko do wcze\u015bniej opisanych scenariuszy. Na przyk\u0142ad, mo\u017cna umie\u015bci\u0107 wszystkie obrazy kontener\u00f3w w og\u00f3lnym magazynie sieciowym i udost\u0119pni\u0107 go wszystkim kontenerom Buildah. Za\u0142\u00f3\u017cmy, \u017ce mamy setki obraz\u00f3w, kt\u00f3re nasz system CI\/CD regularnie u\u017cywa do budowy obraz\u00f3w kontenerowych. Koncentrujemy wszystkie te obrazy na jednym ho\u015bcie-magazynie, a nast\u0119pnie, korzystaj\u0105c z preferowanych \u015brodk\u00f3w przechowywania sieciowego (NFS, Gluster, Ceph, ISCSI, S3\u2026), otwieramy wsp\u00f3lny dost\u0119p do tego magazynu dla wszystkich w\u0119z\u0142\u00f3w Buildah lub Kubernetes.<\/p>\n
Teraz wystarczy podmontowa\u0107 to sieciowe magazyn w kontenerze Buildah w \/var\/lib\/shared i wszystko \u2013 kontenery Buildah nie b\u0119d\u0105 musia\u0142y ju\u017c w og\u00f3le pobiera\u0107 obraz\u00f3w przez pull. W ten spos\u00f3b eliminujemy etap wst\u0119pnego wype\u0142niania (pre-population) i od razu jeste\u015bmy gotowi do wdro\u017cenia kontener\u00f3w.<\/p>\n
Oczywi\u015bcie, mo\u017cna to wykorzysta\u0107 w ramach dzia\u0142aj\u0105cego systemu Kubernetes lub infrastruktury kontenerowej, aby uruchamia\u0107 i wykonywa\u0107 kontenery wsz\u0119dzie bez \u017cadnego pobierania obraz\u00f3w przez pull. Co wi\u0119cej, rejestr kontener\u00f3w, otrzymuj\u0105c zapytanie push o za\u0142adowanie zaktualizowanego obrazu, mo\u017ce automatycznie wysy\u0142a\u0107 ten obraz do wsp\u00f3lnego magazynu sieciowego, gdzie natychmiast staje si\u0119 dost\u0119pny dla wszystkich w\u0119z\u0142\u00f3w.<\/p>\n
Rozmiary obraz\u00f3w kontener\u00f3w czasami mog\u0105 osi\u0105ga\u0107 wiele gigabajt\u00f3w. Funkcjonalno\u015b\u0107 dodatkowych magazyn\u00f3w pozwala unikn\u0105\u0107 klonowania takich obraz\u00f3w na w\u0119z\u0142y i praktycznie przyspiesza uruchamianie kontener\u00f3w.<\/p>\n
Ponadto w tej chwili pracujemy nad now\u0105 funkcj\u0105 montowania wolumen\u00f3w overlay, kt\u00f3ra uczyni budow\u0119 kontener\u00f3w jeszcze szybsz\u0105.<\/p>\n
Podsumowanie<\/h3>\n
\nWykonywanie Buildah wewn\u0105trz kontenera w \u015brodowisku Kubernetes\/CRI-O, Podman lub nawet w Dockerze jest ca\u0142kowicie mo\u017cliwe, a ponadto jest to proste i znacznie bezpieczniejsze ni\u017c u\u017cycie docker.socket. Znacznie zwi\u0119kszyli\u015bmy elastyczno\u015b\u0107 pracy z obrazami, wi\u0119c teraz mo\u017cna je uruchamia\u0107 na r\u00f3\u017cne sposoby dla optymalnej r\u00f3wnowagi mi\u0119dzy bezpiecze\u0144stwem a wydajno\u015bci\u0105.<\/p>\n
Funkcjonalno\u015b\u0107 dodatkowych magazyn\u00f3w pozwala przyspieszy\u0107 lub nawet ca\u0142kowicie wyeliminowa\u0107 pobieranie obraz\u00f3w na w\u0119z\u0142y.
\n
\u0179r\u00f3d\u0142o: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u0412 \u0447\u0435\u043c \u043f\u0440\u0435\u043b\u0435\u0441\u0442\u044c \u0440\u0430\u0437\u0434\u0435\u043b\u0435\u043d\u0438\u044f \u0441\u0440\u0435\u0434\u044b \u0438\u0441\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 \u043d\u0430 \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0435 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u0430\u043b\u044c\u043d\u044b\u0435 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u044e\u0449\u0438\u0435? \u0412 \u0447\u0430\u0441\u0442\u043d\u043e\u0441\u0442\u0438, \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b \u043c\u043e\u0436\u043d\u043e \u043d\u0430\u0447\u0430\u0442\u044c \u043a\u043e\u043c\u0431\u0438\u043d\u0438\u0440\u043e\u0432\u0430\u0442\u044c, \u0447\u0442\u043e\u0431\u044b \u043e\u043d\u0438 \u0437\u0430\u0449\u0438\u0449\u0430\u043b\u0438 \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0430. \u041c\u043d\u043e\u0433\u0438\u0445 \u043f\u0440\u0438\u0432\u043b\u0435\u043a\u0430\u0435\u0442 \u0438\u0434\u0435\u044f \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0442\u044c \u0441\u0431\u043e\u0440\u043a\u0443 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043d\u044b\u0445 OCI-\u043e\u0431\u0440\u0430\u0437\u043e\u0432 \u0432 \u0440\u0430\u043c\u043a\u0430\u0445 Kubernetes \u0438\u043b\u0438 \u043f\u043e\u0434\u043e\u0431\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b. \u0414\u043e\u043f\u0443\u0441\u0442\u0438\u043c, \u0443 \u043d\u0430\u0441 \u0435\u0441\u0442\u044c CI\/CD, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u0435\u0442 \u043e\u0431\u0440\u0430\u0437\u044b, \u0442\u043e\u0433\u0434\u0430 \u0447\u0442\u043e-\u0442\u043e \u0442\u0438\u043f\u0430 Red Hat OpenShift\/Kubernetes \u0431\u044b\u043b\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29093,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38785","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Zalecenia dotycz\u0105ce uruchamiania Buildah wewn\u0105trz kontenera | ProHoster","description":"Jaka jest zaleta podzia\u0142u \u015brodowiska wykonywania kontener\u00f3w na oddzielne elementy narz\u0119dziowe?","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/rekomendatsii-po-zapusku-buildah-vnutri-kontejnera","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0420\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u0430\u0446\u0438\u0438 \u043f\u043e \u0437\u0430\u043f\u0443\u0441\u043a\u0443 Buildah \u0432\u043d\u0443\u0442\u0440\u0438 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430 | ProHoster","og:description":"\u0412 \u0447\u0435\u043c \u043f\u0440\u0435\u043b\u0435\u0441\u0442\u044c \u0440\u0430\u0437\u0434\u0435\u043b\u0435\u043d\u0438\u044f \u0441\u0440\u0435\u0434\u044b \u0438\u0441\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 \u043d\u0430 \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0435 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u0430\u043b\u044c\u043d\u044b\u0435 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u044e\u0449\u0438\u0435?","og:url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/rekomendatsii-po-zapusku-buildah-vnutri-kontejnera","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:25:55+00:00","article:modified_time":"2019-10-31T19:25:55+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38785","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 23:24:21","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:03:14","updated":"2026-01-23 23:24:21","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/38785","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=38785"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/38785\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media\/29093"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=38785"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=38785"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=38785"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}