{"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\/ro\/blog\/administrirovanie\/rekomendatsii-po-zapusku-buildah-vnutri-kontejnera","title":{"rendered":"Recomand\u0103ri pentru rularea Buildah \u00een interiorul containerului","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ce este interesant \u00een separarea mediului de execu\u021bie al containerelor \u00een componente instrumentale separate? \u00cen special, este faptul c\u0103 aceste instrumente pot fi combinate pentru a se proteja reciproc.<\/p>\n

\"Recomand\u0103ri
\n
\nMul\u021bi sunt atra\u0219i de ideea de a construi imagini OCI de containere \u00een cadrul Kubernetes<\/a><\/noindex> sau a unui sistem similar. S\u0103 presupunem c\u0103 avem un CI\/CD care construie\u0219te constant imagini, atunci ceva de genul 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. Am demonstrat cu c\u00e2\u021biva ani \u00een urm\u0103<\/a><\/noindex>, c\u0103 este foarte nesigur, de fapt, este chiar mai r\u0103u dec\u00e2t a oferi acces root sau sudo f\u0103r\u0103 parol\u0103.
\n<\/a><\/noindex>
\nDe aceea, oamenii \u00eencearc\u0103 constant s\u0103 ruleze Buildah \u00een container. Pe scurt, am creat exemplu<\/a><\/noindex> ceea ce consider\u0103m c\u0103 este cea mai bun\u0103 metod\u0103 de a rula Buildah \u00een interiorul containerului \u0219i am publicat imaginile corespunz\u0103toare pe quay.io\/buildah<\/a><\/noindex>. S\u0103 \u00eencepem...<\/p>\n

Configurare<\/h3>\n

\nAceste imagini sunt construite din Dockerfiles pe care le pute\u021bi g\u0103si \u00een depozitul Buildah \u00een folderul buildahimage<\/a><\/noindex>.
\nAici vom analiza versiunea stabil\u0103 a 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
\n\u00cen loc de OverlayFS, implementat la nivelul nucleului Linux al gazdei, folosim \u00een interiorul containerului programul fuse-overlay<\/a><\/noindex>, deoarece \u00een acest moment OverlayFS poate monta doar dac\u0103 \u00eei oferi privilegii SYS_ADMIN prin capabilit\u0103\u021bile Linux. Iar noi dorim s\u0103 rul\u0103m containerele noastre Buildah f\u0103r\u0103 privilegii de nivel root. Fuse-overlay func\u021bioneaz\u0103 destul de repede \u0219i are o performan\u021b\u0103 mai bun\u0103 dec\u00e2t driverul de stocare VFS. Re\u021bine\u021bi c\u0103, la rularea unui container Buildah care utilizeaz\u0103 Fuse, este necesar s\u0103 se ofere dispozitivul \/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
\nApoi, cre\u0103m un director pentru stoc\u0103ri suplimentare. Container\/storage<\/a><\/noindex> sus\u021bine concep\u021bia de conectare a unor stoc\u0103ri de imagini read-only suplimentare. De exemplu, se poate configura o zon\u0103 de stocare overlay pe o ma\u0219in\u0103, iar apoi prin NFS se poate monta aceast\u0103 stocare pe o alt\u0103 ma\u0219in\u0103 \u0219i folosi imaginile din ea f\u0103r\u0103 a le desc\u0103rca prin pull. Avem nevoie de aceast\u0103 stocare pentru a putea monta ca volum o stocare de imagini de pe gazd\u0103 \u0219i a o folosi \u00een interiorul containerului.<\/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
\n\u0218i, \u00een cele din urm\u0103, folosind variabila de mediu BUILDAH_ISOLATION, spunem c\u0103, \u00een mod implicit, containerul Buildah trebuie s\u0103 fie pornit cu izolare chroot. O izolare suplimentar\u0103 nu este necesar\u0103 deoarece deja lucr\u0103m \u00een interiorul unui container. Pentru ca Buildah s\u0103 creeze propriile sale containere cu separarea spa\u021biilor de nume, este nevoie de privilegiul SYS_ADMIN, iar pentru aceasta va trebui s\u0103 relax\u0103m regulile SELinux \u0219i SECCOMP pentru container, ceea ce contravine configura\u021biei noastre de a construi dintr-un container sigur.<\/p>\n
Pornim Buildah \u00een interiorul unui container<\/h3>\n
\nSchema containerului Buildah discutat\u0103 mai sus permite varierea flexibil\u0103 a modurilor de a porni astfel de containere.<\/p>\n
Vitez\u0103 versus securitate<\/h4>\n
\nSecuritatea computerului este \u00eentotdeauna un compromis \u00eentre viteza de execu\u021bie a procesului \u0219i nivelul de protec\u021bie aplicat. Aceast\u0103 afirma\u021bie este adev\u0103rat\u0103 \u0219i \u00een cazul construirii containerelor, de aceea mai jos vom examina op\u021biunile acestui compromis.<\/p>\n
Imaginea de container discutat\u0103 mai sus \u00ee\u0219i va p\u0103stra stocarea \u00een \/var\/lib\/containers. Prin urmare, trebuie s\u0103 mont\u0103m con\u021binutul \u00een aceast\u0103 folder \u0219i modul \u00een care facem acest lucru va influen\u021ba semnificativ viteza de construire a imaginilor de containere.<\/p>\n
S\u0103 lu\u0103m \u00een considerare trei op\u021biuni.<\/p>\n
Op\u021biunea 1.<\/b> Dac\u0103 se cere securitate maxim\u0103, atunci pentru fiecare container se poate crea un folder propriu pentru containers\/image \u0219i se poate monta \u00een container prin volume-mount. \u00cen plus, directorul de context poate fi plasat \u00een interiorul containerului, \u00een folderul \/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
\nSecuritate.<\/i> Utiliz\u00e2nd un container de acest tip, Buildah ofer\u0103 un nivel maxim de securitate: nu i se atribuie privilegii de root prin intermediul capabilit\u0103\u021bilor, iar toate restric\u021biile SECOMP \u0219i SELinux sunt aplicate. Acest tip de container poate fi chiar rulat cu izolarea User Namespace, ad\u0103ug\u00e2nd o op\u021biune precum \u2014uidmap 0:100000:10000.<\/p>\n
Performan\u021b\u0103.<\/i> Dar performan\u021ba aici este minim\u0103, deoarece orice imagini din registrele de containere sunt copiate pe gazd\u0103 de fiecare dat\u0103, iar caching-ul nu func\u021bioneaz\u0103 deloc. La finalizarea func\u021bion\u0103rii, containerul Buildah trebuie s\u0103 trimit\u0103 imaginea \u00een registru \u0219i s\u0103 distrug\u0103 con\u021binutul pe gazd\u0103. C\u00e2nd imaginea de container va fi construit\u0103 din nou, va trebui s\u0103 fie desc\u0103rcat\u0103 din nou din registru, deoarece pe gazd\u0103 nu va mai r\u0103m\u00e2ne nimic.<\/p>\n
Op\u021biunea 2.<\/b> Dac\u0103 ai nevoie de performan\u021b\u0103 la nivel de Docker, po\u021bi monta storage-ul containerului\/host-ului direct \u00een container.<\/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
\nSecuritate.<\/i> Aceasta este cea mai pu\u021bin sigur\u0103 metod\u0103 de construire a containerelor, deoarece permite containerului s\u0103 modifice storage-ul de pe host, ceea ce ar putea permite introducerea unei imagini mali\u021bioase \u00een Podman sau CRI-O. \u00cen plus, va trebui s\u0103 dezactivezi separarea SELinux, astfel \u00eenc\u00e2t procesele din containerul Buildah s\u0103 poat\u0103 interac\u021biona cu storage-ul de pe host. Re\u021bine c\u0103 aceast\u0103 op\u021biune este totu\u0219i mai bun\u0103 dec\u00e2t socket-ul Docker, deoarece containerul este blocat de func\u021biile r\u0103mase de securitate \u0219i nu poate pur \u0219i simplu s\u0103 porneasc\u0103 un container pe host.<\/p>\n
Performan\u021b\u0103.<\/i> Aici este maxim\u0103, deoarece se utilizeaz\u0103 complet caching-ul. Dac\u0103 Podman sau CRI-O au reu\u0219it deja s\u0103 descarce imaginea necesar\u0103 pe host, procesul Buildah din interiorul containerului nu va trebui s\u0103 o descarce din nou, iar construc\u021biile ulterioare bazate pe aceast\u0103 imagine vor putea, de asemenea, s\u0103 ia ceea ce le trebuie din cache.<\/p>\n
Op\u021biunea 3.<\/b> Ideea acestei metode este de a combina mai multe imagini \u00eentr-un singur proiect cu un folder comun pentru imaginile containerelor.<\/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
\n\u00cen acest exemplu, nu elimin\u0103m folderul proiectului (\/var\/lib\/project3) \u00eentre rul\u0103ri, astfel c\u0103 toate construc\u021biile ulterioare \u00een cadrul proiectului beneficiaz\u0103 de avantajele caching-ului.<\/p>\n
Securitate.<\/i> O combina\u021bie \u00eentre op\u021biunile 1 \u0219i 2. Pe de o parte, containerele nu au acces la con\u021binutul de pe host \u0219i, prin urmare, nu pot introduce nimic r\u0103u \u00een storage-ul imaginilor Podman\/CRI-O. Pe de alt\u0103 parte, \u00een cadrul propriului s\u0103u proiect, containerul poate interveni \u00een construc\u021bia altor containere.<\/p>\n
Performan\u021b\u0103.<\/i> Aici este mai slab dec\u00e2t utilizarea unui cache comun la nivel de host, deoarece nu pot fi folosite imaginile deja desc\u0103rcate anterior prin intermediul Podman\/CRI-O. Cu toate acestea, dup\u0103 ce Buildah descarc\u0103 imaginea, aceasta poate fi utilizat\u0103 \u00een orice construc\u021bii ulterioare \u00een cadrul proiectului.<\/p>\n
Stoc\u0103ri suplimentare<\/h4>\n
\n\u00cen containers\/storage<\/a><\/noindex> Exist\u0103 o func\u021bionalitate foarte interesant\u0103 numit\u0103 stoc\u0103ri suplimentare (additional stores), care permite ca, la pornirea \u0219i construirea containerelor, motoarele de container s\u0103 utilizeze stoc\u0103ri externe de imagini \u00een modul read-only overlay. Practic, \u00een fi\u0219ierul storage.conf se pot ad\u0103uga una sau mai multe stoc\u0103ri \u201edoar pentru citire\u201d, astfel \u00eenc\u00e2t, la lansarea unui container, motorul de container s\u0103 caute imaginea necesar\u0103 \u00een acestea. Aceasta va desc\u0103rca imaginea din registru doar \u00een cazul \u00een care nu o g\u0103se\u0219te \u00een niciuna dintre aceste stoc\u0103ri. Motorul de container va putea scrie doar \u00een stoc\u0103rile disponibile pentru scriere\u2026<\/p>\n
Dac\u0103 derul\u0103m \u00een sus \u0219i ne uit\u0103m la Dockerfile-ul pe care \u00eel folosim pentru a construi imaginea quay.io\/buildah\/stable, vom g\u0103si urm\u0103toarele linii:<\/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
\n\u00cen prima linie modific\u0103m \/etc\/containers\/storage.conf din interiorul imaginii containerului, spun\u00e2nd driverului de stocare s\u0103 foloseasc\u0103 \u201eadditionalimagestores\u201d din folderul \/var\/lib\/shared. Apoi, \u00een urm\u0103toarea linie, cre\u0103m un folder comun \u0219i ad\u0103ug\u0103m c\u00e2teva fi\u0219iere de blocare pentru a evita conflictele cu containers\/storage. Practic, cre\u0103m doar un depozit gol pentru imagini de container. <\/p>\n
Dac\u0103 mont\u0103m containers\/storage la un nivel superior acestui folder, Buildah va putea utiliza imaginile.<\/p>\n
Acum ne \u00eentoarcem la Variantele 2 discutate anterior, \u00een care containerul Buildah poate citi \u0219i scrie \u00een containers\/store pe gazde, av\u00e2nd astfel cea mai mare performan\u021b\u0103 datorit\u0103 cache-ului imaginilor la nivelul Podman\/CRI-O, dar oferind un minim de securitate, deoarece poate scrie direct \u00een stoc\u0103ri. \u0218i acum, s\u0103 ad\u0103ug\u0103m stoc\u0103ri suplimentare \u0219i vom ob\u021bine cele mai bune p\u0103r\u021bi din ambele lumi.<\/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
\nRe\u021bine\u021bi c\u0103 \/var\/lib\/containers\/storage al gazdelor este montat \u00een \/var\/lib\/shared din interiorul containerului \u00een modul read-only. De aceea, lucr\u00e2nd \u00een container, Buildah poate folosi orice imagini care au fost deja desc\u0103rcate prin intermediul Podman\/CRI-O (salut, vitez\u0103), dar poate scrie doar \u00een propriul s\u0103u depozit (salut, securitate). De asemenea, re\u021bine\u021bi c\u0103 acest lucru se realizeaz\u0103 f\u0103r\u0103 a dezactiva separarea SELinux pentru container.<\/p>\n
Un detaliu important<\/h4>\n
\n\u00cen niciun caz nu trebuie s\u0103 \u0219terge\u021bi imagini din depozitul de baz\u0103. \u00cen caz contrar, containerul Buildah poate s\u0103 se blocheze.<\/p>\n
\u0218i acestea nu sunt toate avantajele<\/h4>\n
\nFunc\u021bionalit\u0103\u021bile suplimentare de stocare nu se limiteaz\u0103 doar la scenariul descris anterior. De exemplu, toate imaginile containerelor pot fi stocate \u00eentr-un spa\u021biu de stocare de re\u021bea comun, oferind acces tuturor containerelor Buildah. S\u0103 presupunem c\u0103 avem sute de imagini pe care sistemul nostru CI\/CD le folose\u0219te \u00een mod regulat pentru a construi imagini de containere. Concentr\u0103m toate aceste imagini pe un singur host de stocare \u0219i apoi, folosind solu\u021bii preferate de stocare \u00een re\u021bea (NFS, Gluster, Ceph, ISCSI, S3\u2026), deschidem accesul comun la aceast\u0103 stocare tuturor nodurilor Buildah sau Kubernetes.<\/p>\n
Acum, este suficient s\u0103 mont\u0103m aceast\u0103 stocare de re\u021bea \u00een containerul Buildah pe \/var\/lib\/shared \u0219i gata \u2013 containerele Buildah nu vor mai trebui s\u0103 downloadeze imaginile prin pull. Astfel, elimin\u0103m faza de pre-populating \u0219i suntem imediat gata s\u0103 lans\u0103m containere.<\/p>\n
\u0218i, desigur, acest lucru poate fi folosit \u00een cadrul unei sisteme Kubernetes existente sau a unei infrastructuri de containere pentru a rula \u0219i gestiona containere \u00een orice loc, f\u0103r\u0103 a fi necesar s\u0103 desc\u0103rc\u0103m imagini prin pull. \u00cen plus, registrul de containere, primind o cerere push pentru a \u00eenc\u0103rca o imagine actualizat\u0103, poate trimite automat aceast\u0103 imagine \u00een stocarea de re\u021bea comun\u0103, unde devine instantaneu disponibil\u0103 tuturor nodurilor.<\/p>\n
Dimensiunile imaginilor containerelor pot ajunge uneori la c\u00e2\u021biva gigabytes. Func\u021bionalitatea stoc\u0103rilor suplimentare permite evitarea clon\u0103rii acestor imagini pe noduri \u0219i face lansarea containerelor aproape instantanee.<\/p>\n
\u00cen plus, \u00een acest moment lucr\u0103m la o nou\u0103 func\u021bie de montare a volumelor overlay, care va accelera \u0219i mai mult procesul de construc\u021bie a containerelor.<\/p>\n
Concluzie<\/h3>\n
\nExecutarea Buildah \u00een interiorul unui container \u00een medii Kubernetes\/CRI-O, Podman sau chiar \u00een Docker este complet realizabil\u0103, mai ales c\u0103 este simpl\u0103 \u0219i mult mai sigur\u0103 dec\u00e2t utilizarea docker.socket. Am crescut semnificativ flexibilitatea lucrului cu imagini, permi\u021b\u00e2nd acum rularea acestora \u00een diverse moduri pentru un echilibru optim \u00eentre securitate \u0219i performan\u021b\u0103.<\/p>\n
Func\u021bionalitatea stoc\u0103rilor suplimentare permite accelerarea sau chiar eliminarea complet\u0103 a desc\u0103rc\u0103rii imaginilor pe noduri.
\n
Sursa: 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\udd47Recomand\u0103ri pentru rularea Buildah \u00een interiorul containerului | ProHoster","description":"Care este frumuse\u021bea de a separa mediu de execu\u021bie al containerelor \u00een componente instrumentale distincte?","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/rekomendatsii-po-zapusku-buildah-vnutri-kontejnera","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/38785","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=38785"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/38785\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/29093"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=38785"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=38785"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=38785"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}