{"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 l'avvio di Buildah all'interno del 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, il fatto che questi strumenti possano essere combinati in modo che si proteggano a vicenda.<\/p>\n

\"Raccomandazioni
\n
\nMolti sono attratti dall'idea di eseguire la costruzione di immagini container OCI nell'ambito di Kubernetes<\/a><\/noindex> o un sistema simile. Supponiamo di avere un CI\/CD che costruisce costantemente immagini, quindi 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 mostrato diversi anni fa<\/a><\/noindex>, che questo \u00e8 molto insicuro, infatti \u00e8 anche peggio che fornire accesso root senza password o sudo.
\n<\/a><\/noindex>
\nPerci\u00f2, le persone cercano costantemente di eseguire Buildah in un container. In breve, abbiamo creato un esempio<\/a><\/noindex> la nostra visione su come sia meglio eseguire Buildah all'interno di un container e abbiamo pubblicato le relative immagini su quay.io\/buildah<\/a><\/noindex>. Iniziamo\u2026<\/p>\n

Configurazione<\/h3>\n

\nQueste immagini sono state costruite da Dockerfile, che possono essere trovati nel repository Buildah nella cartella buildahimage<\/a><\/noindex>.
\nQui esamineremo la versione stabile del 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 concessi privilegi SYS_ADMIN tramite le capacit\u00e0 Linux. E noi vogliamo eseguire i nostri container Buildah senza alcun privilegio di root. Fuse-overlay \u00e8 abbastanza rapido e offre prestazioni migliori rispetto al driver di archiviazione VFS. Si noti che quando si esegue un container 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 i repository aggiuntivi. Container\/storage<\/a><\/noindex> supporta il concetto di collegamento di repository immagine aggiuntivi in modalit\u00e0 sola lettura. Ad esempio, \u00e8 possibile configurare un'area di archiviazione overlay su una macchina e poi montarla su un'altra macchina tramite NFS, utilizzando le immagini senza doverle scaricare tramite pull. Questo repository \u00e8 necessario per poter collegare come volume un repository di immagini dall'host e utilizzarlo all'interno del container.<\/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
\nE infine, utilizzando la variabile d'ambiente BUILDAH_ISOLATION, diciamo che per impostazione predefinita il contenitore Buildah deve essere eseguito con isolamento chroot. Ulteriore isolamento non \u00e8 necessario qui, poich\u00e9 stiamo gi\u00e0 lavorando all'interno di un contenitore. Per consentire a Buildah di creare i propri contenitori con separazione degli spazi dei nomi, \u00e8 necessaria l'autorizzazione SYS_ADMIN, e per questo dovremo allentare le regole SELinux e SECCOMP per il contenitore, il che \u00e8 contrario alla nostra impostazione di eseguire la build da un contenitore sicuro.<\/p>\n
Eseguiamo Buildah all'interno del contenitore<\/h3>\n
\nLo schema del contenitore Buildah sopra esaminato 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 quanto \u00e8 protetto intorno ad esso. Questa affermazione \u00e8 valida anche per la creazione di contenitori, quindi di seguito esamineremo le opzioni per tale compromesso.<\/p>\n
Il contenitore d'immagine sopra esaminato conserver\u00e0 il proprio archivio in \/var\/lib\/containers. Pertanto, dobbiamo montare il contenuto in questa cartella, e il modo in cui lo faremo influenzer\u00e0 notevolmente la rapidit\u00e0 di costruzione delle immagini dei contenitori.<\/p>\n
Consideriamo tre opzioni.<\/p>\n
Opzione 1.<\/b> Se \u00e8 richiesta la massima sicurezza, \u00e8 possibile creare una propria cartella per containers\/image per ogni contenitore e collegarla al contenitore tramite volume-mount. Inoltre, \u00e8 possibile posizionare il context directory all'interno dello stesso 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 contenitore Buildah offre la massima sicurezza: non vengono concessi privilegi di root tramite capabilities e vengono applicate tutte le restrizioni di SECOMP e SELinux. Questo contenitore pu\u00f2 persino essere eseguito con isolamento User Namespace, aggiungendo un'opzione come --uidmap 0:100000:10000.<\/p>\n
Prestazioni.<\/i> Tuttavia, le prestazioni qui sono minime, poich\u00e9 ogni immagine dai registri dei contenitori viene copiato ogni volta sull'host, e la cache non funziona affatto. Alla fine del suo lavoro, il contenitore Buildah deve inviare l'immagine al registro e distruggere il contenuto sull'host. Quando l'immagine del contenitore verr\u00e0 ricostruita la volta successiva, dovr\u00e0 essere nuovamente scaricata dal registro, poich\u00e9 a quel punto sull'host non rimarr\u00e0 nulla.<\/p>\n
Opzione 2.<\/b> Se hai bisogno di prestazioni a livello di Docker, puoi montare direttamente nel container il container\/storage dell'host.<\/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 creare container, poich\u00e9 al container \u00e8 permesso modificare lo storage dell'host e, potenzialmente, potrebbe iniettare un'immagine dannosa in Podman o CRI-O. Inoltre, sar\u00e0 necessario disabilitare la separazione di SELinux affinch\u00e9 i processi all'interno del container Buildah possano interagire con lo storage dell'host. Si noti che questa opzione \u00e8 comunque migliore del socket Docker, poich\u00e9 il container \u00e8 bloccato dalle altre funzionalit\u00e0 di sicurezza e non pu\u00f2 semplicemente avviare un qualsiasi container sull'host.<\/p>\n
Prestazioni.<\/i> In questo caso, \u00e8 massima, poich\u00e9 viene utilizzata completamente la cache. Se Podman o CRI-O hanno gi\u00e0 scaricato l'immagine necessaria sull'host, il processo Buildah all'interno del container non dovr\u00e0 scaricarla di nuovo, e le successive costruzioni basate su questa immagine potranno anche prendere ci\u00f2 che serve dalla cache.<\/p>\n
Opzione 3.<\/b> La sostanza di questo metodo \u00e8 combinare pi\u00f9 immagini in un unico progetto con una cartella comune per le immagini dei container.<\/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 ulteriori costruzioni all'interno del progetto beneficiano della cache.<\/p>\n
Sicurezza.<\/i> \u00c8 una via di mezzo tra le opzioni 1 e 2. Da un lato, i container non hanno accesso ai contenuti sull'host e, di conseguenza, non possono iniettare nulla di dannoso nello storage delle immagini di Podman\/CRI-O. Dall'altro lato, all'interno del proprio progetto, il container pu\u00f2 interferire nella costruzione di altri container.<\/p>\n
Prestazioni.<\/i> In questo caso \u00e8 peggiore rispetto all'utilizzo di una cache comune a livello di host, poich\u00e9 non \u00e8 possibile utilizzare immagini gi\u00e0 scaricate in precedenza tramite Podman\/CRI-O. Tuttavia, una volta che Buildah scarica l'immagine, questa immagine pu\u00f2 essere utilizzata in tutte le costruzioni successive all'interno del progetto.<\/p>\n
Storage aggiuntivi<\/h4>\n
\nA containers\/storage<\/a><\/noindex> Esiste una cosa fantastica chiamata archivi aggiuntivi (additional stores), grazie alla quale, durante l'avvio e la costruzione dei container, i motori dei container possono utilizzare archivi esterni di immagini in modalit\u00e0 di overlay read-only. In sostanza, nel file storage.conf si possono aggiungere uno o pi\u00f9 archivi \"solo lettura\", affinch\u00e9, al momento dell'avvio del container, il motore dei container cerchi l'immagine necessaria in essi. Inoltre, scaricher\u00e0 l'immagine dal registro solo se non la trova in nessuno di questi archivi. Il motore dei container potr\u00e0 scrivere solo negli archivi accessibili in scrittura\u2026<\/p>\n
Se scorriamo verso l'alto e guardiamo il Dockerfile che utilizziamo per costruire l'immagine quay.io\/buildah\/stable, troveremo queste righe:<\/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 container, dicendo al driver di storage di utilizzare \u201cadditionalimagestores\u201d nella cartella \/var\/lib\/shared. Nella riga successiva creiamo una cartella condivisa e aggiungiamo un paio di file di lock per evitare conflitti con containers\/storage. In sostanza, stiamo semplicemente creando un archivio vuoto di immagini dei container. <\/p>\n
Se montiamo containers\/storage a un livello superiore a questa cartella, Buildah potr\u00e0 utilizzare le immagini.<\/p>\n
Ora torniamo alla Variante 2 esaminata sopra, quando un container Buildah pu\u00f2 leggere e scrivere in containers\/store sugli host e, di conseguenza, ha la massima efficienza grazie alla memorizzazione nella cache delle immagini a livello di Podman\/CRI-O, ma offre il minimo di sicurezza, poich\u00e9 pu\u00f2 scrivere direttamente negli archivi. Aggiungendo qui archivi aggiuntivi, 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
\nNota che \/var\/lib\/containers\/storage dell'host \u00e8 montata in \/var\/lib\/shared all'interno del container in modalit\u00e0 read-only. Pertanto, lavorando nel container, Buildah pu\u00f2 utilizzare qualsiasi immagine che \u00e8 stata precedentemente scaricata tramite Podman\/CRI-O (salve, velocit\u00e0), ma pu\u00f2 scrivere solo nel proprio archivio (salve, sicurezza). Inoltre, nota che ci\u00f2 avviene senza disattivare la separazione di SELinux per il container.<\/p>\n
Un aspetto importante<\/h4>\n
\nIn nessun caso \u00e8 consigliabile rimuovere immagini dall'archivio sottostante. In caso contrario, il container Buildah potrebbe bloccarsi.<\/p>\n
E non sono affatto tutti i vantaggi<\/h4>\n
\nLe possibilit\u00e0 di archiviazioni aggiuntive non si limitano solo allo scenario descritto sopra. Ad esempio, \u00e8 possibile memorizzare tutte le immagini dei contenitori in uno storage di rete comune e fornire l'accesso a tutti i contenitori Buildah. Supponiamo di avere centinaia di immagini che il nostro sistema CI\/CD utilizza regolarmente per la creazione di immagini dei contenitori. Concordiamo tutte queste immagini su un unico host di archiviazione e poi, utilizzando i strumenti di archiviazione di rete preferiti (NFS, Gluster, Ceph, ISCSI, S3...), apriamo l'accesso condiviso a questo archiviazione a tutti i nodi Buildah o Kubernetes.<\/p>\n
Ora \u00e8 sufficiente montare questo spazio di archiviazione di rete nel container Buildah su \/var\/lib\/shared e il gioco \u00e8 fatto: i container Buildah non dovranno pi\u00f9 scaricare le immagini tramite pull. In questo modo si elimina la fase di pre-popolamento e si \u00e8 immediatamente pronte a distribuire i container.<\/p>\n
E naturalmente, questo pu\u00f2 essere utilizzato all'interno di un sistema Kubernetes attivo o di un'infrastruttura di container per eseguire e gestire i container ovunque senza dover scaricare immagini tramite pull. Inoltre, il registro dei container, ricevendo una richiesta push per caricare un'immagine aggiornata, pu\u00f2 automaticamente inviare quest'immagine allo spazio di archiviazione di rete comune, dove diventa 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 la clonazione di tali immagini sui nodi e rende l'avvio dei container praticamente istantaneo.<\/p>\n
Inoltre, attualmente stiamo lavorando su una nuova funzionalit\u00e0 di montaggio di volumi overlay 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 persino in Docker \u00e8 assolutamente fattibile, ed \u00e8 anche semplice e molto pi\u00f9 sicuro rispetto all'utilizzo di docker.socket. Abbiamo notevolmente aumentato la flessibilit\u00e0 nel lavoro con le immagini, e ora puoi eseguirle in vari modi per un equilibrio ottimale tra sicurezza e prestazioni.<\/p>\n
La funzionalit\u00e0 di archiviazione aggiuntiva 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\udd47Raccomandazioni per l'esecuzione di Buildah all'interno di un contenitore | ProHoster","description":"Qual \u00e8 il vantaggio di separare l'ambiente di esecuzione dei contenitori in componenti strumentali distinti?","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?","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}