{"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\/it\/blog\/administrirovanie\/rekomendatsii-po-zapusku-buildah-vnutri-kontejnera","title":{"rendered":"Raccomandazioni per eseguire Buildah all'interno di un contenitore","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Qual \u00e8 il vantaggio di suddividere l'ambiente di esecuzione dei container in componenti strumentali separati? In particolare, che questi strumenti possono essere combinati per proteggersi a vicenda.<\/p>\n

\"Raccomandazioni
\n
\nMolti sono attratti dall'idea di eseguire la build delle immagini OCI dei container all'interno di Kubernetes<\/a><\/noindex> o un sistema simile. Supponiamo di avere un CI\/CD che costruisce costantemente le immagini, allora qualcosa come 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. Abbiamo gi\u00e0 dimostrato qualche anno fa<\/a><\/noindex>, che questo \u00e8 molto insicuro, in effetti, \u00e8 addirittura peggio che concedere accesso root o sudo senza password.
\n<\/a><\/noindex>
\nPertanto, le persone cercano costantemente di eseguire Buildah in un container. In breve, abbiamo creato esempio<\/a><\/noindex> un modo, a nostro avviso, per eseguire al meglio Buildah all'interno di un container e abbiamo reso disponibili le relative immagini su quay.io\/buildah<\/a><\/noindex>. Cominciamo...<\/p>\n

Impostazione<\/h3>\n

\nQueste immagini sono state compilate da Dockerfile, che possono essere trovati nel repository di Buildah nella cartella buildahimage<\/a><\/noindex>.
\nQui esamineremo la versione stabile di 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
\nInvece di OverlayFS, implementato a livello del kernel Linux dell'host, utilizziamo all'interno del container il programma fuse-overlay<\/a><\/noindex>, poich\u00e9 al momento OverlayFS pu\u00f2 montare solo se gli vengono concesse le autorizzazioni SYS_ADMIN tramite le capacit\u00e0 di Linux. E vogliamo eseguire i nostri contenitori Buildah senza alcun privilegio di root. Fuse-overlay funziona abbastanza velocemente e offre migliori prestazioni rispetto al driver di storage VFS. Si noti che, quando si esegue un contenitore Buildah che utilizza Fuse, \u00e8 necessario fornire il dispositivo \/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
\nSuccessivamente creiamo una directory per gli storage aggiuntivi. Container\/storage<\/a><\/noindex> supporta il concetto di collegamento di storage immagine aggiuntivi in sola lettura. Ad esempio, \u00e8 possibile configurare un'area di overlay di storage su una macchina e poi montare questa storage tramite NFS su un'altra macchina e utilizzare le immagini senza scaricarle tramite pull. Abbiamo bisogno di questo storage per poter collegare come volume uno storage immagine dall'host e usarlo all'interno del contenitore.<\/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
\nInfine, utilizzando la variabile d'ambiente BUILDAH_ISOLATION, indichiamo che per impostazione predefinita il contenitore Buildah deve essere avviato con isolamento chroot. Ulteriore isolamento non \u00e8 necessario, poich\u00e9 stiamo gi\u00e0 operando all'interno di un contenitore. Per consentire a Buildah di creare i propri contenitori con separazione dei namespace, \u00e8 necessaria la privilegio SYS_ADMIN, e questo comporterebbe l'allentamento delle regole SELinux e SECCOMP per il contenitore, il che sarebbe in contraddizione con la nostra configurazione di eseguire costruzioni in un contenitore sicuro.<\/p>\n
Avviamo Buildah all'interno del contenitore<\/h3>\n
\nLo schema del contenitore Buildah discusso sopra consente di variare in modo flessibile i modi di avviare tali contenitori.<\/p>\n
Velocit\u00e0 contro sicurezza<\/h4>\n
\nLa sicurezza informatica \u00e8 sempre un compromesso tra la velocit\u00e0 di esecuzione del processo e il livello di protezione che si \u00e8 deciso di applicare. Questa affermazione \u00e8 vera anche durante la costruzione dei contenitori, quindi di seguito esamineremo le opzioni per tale compromesso.<\/p>\n
L'immagine del contenitore esaminata in precedenza manterr\u00e0 i propri dati in \/var\/lib\/containers. Pertanto, dobbiamo montare il contenuto in questa cartella, e il modo in cui lo faremo influenzer\u00e0 notevolmente la velocit\u00e0 di costruzione delle immagini dei contenitori.<\/p>\n
Esaminiamo tre opzioni.<\/p>\n
Opzione 1.<\/b> Se \u00e8 necessaria la massima sicurezza, \u00e8 possibile creare una propria cartella per containers\/image per ogni contenitore e collegarla al contenitore tramite il volume-mount. Inoltre, si pu\u00f2 posizionare la directory di contesto direttamente nel contenitore, nella cartella \/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
\nSicurezza.<\/i> Lavorare in un container del tipo Buildah offre la massima sicurezza: non ha alcun privilegio root tramite i capabilities, e sono imposte tutte le restrizioni di SECOMP e SELinux. Questo tipo di container pu\u00f2 essere avviato anche con isolamento User Namespace, aggiungendo un'opzione come \u2014uidmap 0:100000:10000.<\/p>\n
Prestazioni.<\/i> Tuttavia, le prestazioni qui sono minime, poich\u00e9 ogni immagine dai registri dei container viene copiata ogni volta sull'host e la memorizzazione nella cache non funziona affatto. Una volta completato il suo lavoro, il container Buildah deve inviare l'immagine al registro e distruggere il contenuto sull'host. Quando l'immagine del container sar\u00e0 ricostruita, dovr\u00e0 essere scaricata di nuovo dal registro, poich\u00e9 sull'host non rimarr\u00e0 pi\u00f9 nulla.<\/p>\n
Opzione 2.<\/b> Se hai bisogno di prestazioni a livello di Docker, puoi montare direttamente il container\/storage dell'host all'interno del 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
\nSicurezza.<\/i> Questo \u00e8 il modo meno sicuro per costruire container, poich\u00e9 qui al container \u00e8 permesso modificare lo storage sull'host e potrebbe potenzialmente introdurre un'immagine dannosa a Podman o CRI-O. Inoltre, sar\u00e0 necessario disattivare la separazione di SELinux affinch\u00e9 i processi all'interno del container Buildah possano interagire con lo storage sull'host. Tieni presente che questa opzione \u00e8 comunque migliore del socket Docker, poich\u00e9 il container \u00e8 bloccato dalle rimanenti funzionalit\u00e0 di sicurezza e non pu\u00f2 semplicemente avviare un qualsiasi container sull'host.<\/p>\n
Prestazioni.<\/i> Qui \u00e8 massima, poich\u00e9 viene utilizzata completamente la memorizzazione nella cache. Se Podman o CRI-O hanno gi\u00e0 scaricato l'immagine necessaria sull'host, il processo di Buildah all'interno del contenitore non dovr\u00e0 scaricarla nuovamente, e le successive compilazioni basate su quest'immagine potranno anche attingere quanto necessario dalla cache.<\/p>\n
Opzione 3.<\/b> L'idea di questo metodo \u00e8 di unire pi\u00f9 immagini in un unico progetto con una cartella condivisa per le immagini dei contenitori.<\/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
\nIn questo esempio non eliminiamo la cartella del progetto (\/var\/lib\/project3) tra i lanci, quindi tutte le successive compilazioni all'interno del progetto traggono vantaggio dalla memorizzazione nella cache.<\/p>\n
Sicurezza.<\/i> Qualcosa a met\u00e0 tra le opzioni 1 e 2. Da un lato, i contenitori non hanno accesso ai contenuti sull'host e, di conseguenza, non possono inserire nulla di dannoso nello storage delle immagini di Podman\/CRI-O. Dall'altro lato, all'interno del proprio progetto, il contenitore pu\u00f2 interferire nella compilazione di altri contenitori.<\/p>\n
Prestazioni.<\/i> Qui \u00e8 peggiore rispetto all'utilizzo della cache condivisa a livello host, poich\u00e9 non \u00e8 possibile utilizzare immagini gi\u00e0 scaricate con Podman\/CRI-O. Tuttavia, una volta che Buildah scarica un'immagine, questa pu\u00f2 essere utilizzata in tutte le compilazioni successive all'interno del progetto.<\/p>\n
Archivi aggiuntivi<\/h4>\n
\nA containers\/storage<\/a><\/noindex> C'\u00e8 una funzione interessante chiamata archivi aggiuntivi (additional stores), grazie alla quale, durante l'avvio e la creazione di contenitori, i motori dei contenitori possono utilizzare archivi esterni delle immagini in modalit\u00e0 read-only overlay. In pratica, \u00e8 possibile aggiungere uno o pi\u00f9 archivi 'solo in lettura' al file storage.conf, in modo che durante l'avvio del contenitore il motore dei contenitori cerchi l'immagine necessaria in essi. Scaricher\u00e0 l'immagine dal registro solo se non la trova in nessuno di questi archivi. Il motore dei contenitori potr\u00e0 scrivere solo negli archivi accessibili in scrittura...<\/p>\n
Se scorriamo verso l'alto e guardiamo il Dockerfile che utilizziamo per costruire l'immagine quay.io\/buildah\/stable, troveremo righe come queste:<\/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
\nNella prima riga modifichiamo \/etc\/containers\/storage.conf all'interno dell'immagine del contenitore, dicendo al driver di archiviazione di utilizzare 'additionalimagestores' nella cartella \/var\/lib\/shared. Nella riga successiva creiamo una cartella condivisa e aggiungiamo un paio di file lock, in modo da evitare conflitti da parte di containers\/storage. Fondamentalmente, stiamo solo creando uno spazio di archiviazione vuoto per le immagini dei contenitori. <\/p>\n
Se montiamo containers\/storage a un livello superiore a questa cartella, Buildah sar\u00e0 in grado di utilizzare le immagini.<\/p>\n
Torniamo alla Variante 2 esaminata in precedenza, in cui il contenitore Buildah pu\u00f2 leggere e scrivere in containers\/store sugli host e, di conseguenza, ha la massima prestazione grazie alla memorizzazione nella cache delle immagini a livello di Podman\/CRI-O, ma offre un minimo di sicurezza, poich\u00e9 pu\u00f2 scrivere direttamente negli archivi. Ora aggiungiamo archivi aggiuntivi e otteniamo il meglio di entrambi i mondi.<\/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
\nSi prega di notare che \/var\/lib\/containers\/storage dell'host \u00e8 montato in \/var\/lib\/shared all'interno del contenitore in modalit\u00e0 di sola lettura. Pertanto, mentre si lavora nel contenitore, Buildah pu\u00f2 utilizzare qualsiasi immagine che \u00e8 stata gi\u00e0 scaricata tramite Podman\/CRI-O (saluti, velocit\u00e0), ma pu\u00f2 scrivere solo nel proprio storage (saluti, sicurezza). Si prega di notare che questo avviene senza disattivare la separazione SELinux per il contenitore.<\/p>\n
Aspetto importante<\/h4>\n
\nIn nessun caso si devono eliminare immagini dallo storage sottostante. Altrimenti, il contenitore Buildah potrebbe chiudersi inavvertitamente.<\/p>\n
E questi non sono affatto tutti i vantaggi<\/h4>\n
\nLe funzionalit\u00e0 degli storage aggiuntivi non si limitano solo allo scenario descritto sopra. Ad esempio, \u00e8 possibile ospitare tutte le immagini container in uno storage di rete comune e consentire l'accesso a tutti i container Buildah. Supponiamo di avere centinaia di immagini che il nostro sistema CI\/CD utilizza regolarmente per generare immagini container. Centralizziamo tutte queste immagini su un singolo host di storage e poi, utilizzando strumenti di storage di rete preferiti (NFS, Gluster, Ceph, ISCSI, S3\u2026), rendiamo accessibile questo storage a tutti i nodi Buildah o Kubernetes.<\/p>\n
Ora \u00e8 sufficiente montare questo storage di rete nel container Buildah in \/var\/lib\/shared e il gioco \u00e8 fatto: i container Buildah non dovranno pi\u00f9 scaricare le immagini tramite pull. In questo modo eliminiamo la fase di pre-popolazione e siamo subito pronti a distribuire i container.<\/p>\n
E naturalmente, questo pu\u00f2 essere utilizzato all'interno di un sistema Kubernetes esistente o di un'infrastruttura basata su container, per eseguire e gestire container ovunque senza dover scaricare immagini tramite pull. Inoltre, il registro dei container, ricevendo una richiesta di push per caricare un'immagine aggiornata, pu\u00f2 inviare automaticamente quell'immagine a un'archiviazione di rete condivisa, rendendola immediatamente disponibile a tutti i nodi.<\/p>\n
Le dimensioni delle immagini dei container possono talvolta raggiungere diversi gigabyte. La funzionalit\u00e0 di archiviazione aggiuntiva consente di evitare il cloning di tali immagini tra i nodi, rendendo l'avvio dei container praticamente istantaneo.<\/p>\n
Inoltre, stiamo attualmente lavorando su una nuova funzionalit\u00e0 di overlay volume mounts, che render\u00e0 la costruzione dei container ancora pi\u00f9 veloce.<\/p>\n
Conclusione<\/h3>\n
\nEseguire Buildah all'interno di un container in un ambiente Kubernetes\/CRI-O, Podman o anche in Docker \u00e8 assolutamente realizzabile, ed \u00e8 molto pi\u00f9 semplice e sicuro rispetto all'uso di docker.socket. Abbiamo notevolmente aumentato la flessibilit\u00e0 nella gestione delle immagini, e ora puoi avviarle in vari modi per ottenere un equilibrio ottimale tra sicurezza e prestazioni.<\/p>\n
La funzionalit\u00e0 dei repository aggiuntivi consente di accelerare o addirittura eliminare completamente il download delle immagini sui nodi.
\n
Fonte: 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\udd47 Raccomandazioni per eseguire Buildah all'interno di un contenitore | ProHoster","description":"Qual \u00e8 il vantaggio di separare l'ambiente di esecuzione dei contenitori in componenti strumentali distinti? In particolare, il fatto che questi strumenti possono essere combinati tra loro per proteggersi reciprocamente. Molti sono attratti dall'idea di eseguire la build delle immagini OCI dei contenitori all'interno di Kubernetes o di un sistema simile. Supponiamo di avere un CI\/CD che costruisce costantemente le immagini, quindi qualcosa come Red Hat OpenShift\/Kubernetes sarebbe","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/rekomendatsii-po-zapusku-buildah-vnutri-kontejnera","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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? \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","og:url":"https:\/\/prohoster.info\/it\/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"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/38785","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=38785"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/38785\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/29093"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=38785"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=38785"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=38785"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}