{"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\/pt\/blog\/administrirovanie\/rekomendatsii-po-zapusku-buildah-vnutri-kontejnera","title":{"rendered":"Recomenda\u00e7\u00f5es para executar o Buildah dentro de um cont\u00eainer","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Qual \u00e9 a vantagem de separar o ambiente de execu\u00e7\u00e3o de cont\u00eaineres em componentes de ferramenta distintas? Em particular, o fato de que essas ferramentas podem ser combinadas para se protegerem mutuamente.<\/p>\n

\"Recomenda\u00e7\u00f5es
\n
\nMuitos se sentem atra\u00eddos pela ideia de compilar imagens OCI de cont\u00eaineres dentro de Kubernetes<\/a><\/noindex> ou um sistema semelhante. Suponha que temos um CI\/CD que est\u00e1 constantemente criando imagens, ent\u00e3o algo como 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. Mostramos h\u00e1 alguns anos<\/a><\/noindex>, que isso \u00e9 muito inseguro, de fato, \u00e9 at\u00e9 pior do que dar acesso root ou sudo sem senha.
\n<\/a><\/noindex>
\nPortanto, as pessoas est\u00e3o constantemente tentando rodar o Buildah dentro de um cont\u00eainer. Resumindo, criamos exemplo<\/a><\/noindex> nossa vis\u00e3o sobre a melhor forma de executar o Buildah dentro de um cont\u00eainer e disponibilizamos as imagens correspondentes em quay.io\/buildah<\/a><\/noindex>. Vamos come\u00e7ar\u2026<\/p>\n

Configura\u00e7\u00e3o<\/h3>\n

\nEssas imagens foram constru\u00eddas a partir de Dockerfiles que podem ser encontrados no reposit\u00f3rio do Buildah na pasta buildahimage<\/a><\/noindex>.
\nAqui vamos examinar a vers\u00e3o est\u00e1vel do 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
\nEm vez de OverlayFS, implementado no n\u00edvel do kernel Linux do host, usamos dentro do cont\u00eainer o programa fuse-overlay<\/a><\/noindex>, uma vez que, no momento, o OverlayFS s\u00f3 consegue montar se lhe forem dadas permiss\u00f5es SYS_ADMIN atrav\u00e9s das capacidades do Linux. E queremos executar nossos cont\u00eaineres Buildah sem quaisquer privil\u00e9gios de root. O fuse-overlay funciona bem rapidamente e tem melhor desempenho do que o driver de armazenamento VFS. Note que ao executar um cont\u00eainer Buildah usando o Fuse, \u00e9 necess\u00e1rio fornecer o 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
\nEm seguida, criamos um diret\u00f3rio para reposit\u00f3rios adicionais. Container\/storage<\/a><\/noindex> suporta o conceito de montagem de reposit\u00f3rios adicionais somente leitura de imagens. Por exemplo, \u00e9 poss\u00edvel configurar uma \u00e1rea de armazenamento overlay em uma m\u00e1quina e, em seguida, mont\u00e1-la em outra m\u00e1quina usando NFS, utilizando as imagens dela sem precisar baixar via pull. Precisamos desse armazenamento para poder conectar um reposit\u00f3rio de imagens do host como um volume e utiliz\u00e1-lo dentro do cont\u00eainer.<\/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 finalmente, ao usar a vari\u00e1vel de ambiente BUILDAH_ISOLATION, dizemos que, por padr\u00e3o, o cont\u00eainer Buildah deve ser executado com isolamento chroot. Um isolamento adicional n\u00e3o \u00e9 necess\u00e1rio aqui, j\u00e1 que j\u00e1 estamos trabalhando em um cont\u00eainer. Para que o Buildah crie seus pr\u00f3prios cont\u00eaineres com separa\u00e7\u00e3o de namespaces, \u00e9 necess\u00e1rio privil\u00e9gios SYS_ADMIN, e para isso teremos que relaxar as regras do SELinux e SECCOMP para o cont\u00eainer, o que contradiz nossa configura\u00e7\u00e3o de realizar a constru\u00e7\u00e3o em um cont\u00eainer seguro.<\/p>\n
Executando Buildah dentro do cont\u00eainer<\/h3>\n
\nO esquema de imagem do cont\u00eainer Buildah discutido acima permite variar de forma flex\u00edvel as maneiras de iniciar tais cont\u00eaineres.<\/p>\n
Velocidade versus seguran\u00e7a<\/h4>\n
\nA seguran\u00e7a da computa\u00e7\u00e3o \u00e9 sempre um compromisso entre a velocidade de execu\u00e7\u00e3o do processo e a quantidade de prote\u00e7\u00e3o em torno dele. Esta afirma\u00e7\u00e3o \u00e9 verdadeira tamb\u00e9m na constru\u00e7\u00e3o de cont\u00eaineres, portanto, abaixo veremos as op\u00e7\u00f5es para esse compromisso.<\/p>\n
A imagem de cont\u00eainer discutida acima manter\u00e1 seu armazenamento em \/var\/lib\/containers. Portanto, precisamos montar o conte\u00fado nessa pasta, e a forma como faremos isso afetar\u00e1 bastante a velocidade de constru\u00e7\u00e3o das imagens dos cont\u00eaineres.<\/p>\n
Vamos considerar tr\u00eas op\u00e7\u00f5es.<\/p>\n
Op\u00e7\u00e3o 1.<\/b> Se a m\u00e1xima seguran\u00e7a for necess\u00e1ria, pode-se criar uma pasta pr\u00f3pria para cada cont\u00eainer para containers\/image e conect\u00e1-la ao cont\u00eainer via volume-mount. Al\u00e9m disso, colocar o diret\u00f3rio de contexto dentro do pr\u00f3prio cont\u00eainer, na pasta \/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
\nSeguran\u00e7a.<\/i> Trabalhar em um cont\u00eainer Buildah proporciona m\u00e1xima seguran\u00e7a: ele n\u00e3o recebe privil\u00e9gios de root por meio de capabilities, e todas as restri\u00e7\u00f5es do SECOMP e SELinux s\u00e3o aplicadas. Este cont\u00eainer pode at\u00e9 ser executado com isolamento de User Namespace, adicionando uma op\u00e7\u00e3o como \u2014uidmap 0:100000:10000.<\/p>\n
Desempenho.<\/i> No entanto, o desempenho aqui \u00e9 m\u00ednimo, pois qualquer imagem de registros de cont\u00eainer \u00e9 copiada para o host a cada vez, e o cache n\u00e3o funciona de forma nenhuma. Ao concluir seu trabalho, o cont\u00eainer Buildah deve enviar a imagem ao registro e destruir o conte\u00fado no host. Quando a imagem do cont\u00eainer for constru\u00edda novamente, ser\u00e1 necess\u00e1rio baix\u00e1-la novamente do registro, pois at\u00e9 l\u00e1 j\u00e1 n\u00e3o restar\u00e1 nada no host.<\/p>\n
Op\u00e7\u00e3o 2.<\/b> Se for necess\u00e1rio um desempenho a n\u00edvel do Docker, \u00e9 poss\u00edvel montar diretamente o container\/storage do host dentro do cont\u00eainer.<\/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
\nSeguran\u00e7a.<\/i> Este \u00e9 o m\u00e9todo menos seguro de montar cont\u00eaineres, pois permite que o cont\u00eainer modifique o armazenamento no host, potencialmente inserindo uma imagem maliciosa no Podman ou CRI-O. Al\u00e9m disso, ser\u00e1 necess\u00e1rio desabilitar a separa\u00e7\u00e3o do SELinux para que os processos no cont\u00eainer Buildah possam interagir com o armazenamento no host. Vale a pena notar que esta op\u00e7\u00e3o ainda \u00e9 melhor que o soquete do Docker, pois o cont\u00eainer \u00e9 bloqueado pelas demais fun\u00e7\u00f5es de seguran\u00e7a e n\u00e3o pode simplesmente iniciar qualquer cont\u00eainer no host.<\/p>\n
Desempenho.<\/i> Aqui, ela \u00e9 m\u00e1xima, pois o cache \u00e9 totalmente utilizado. Se o Podman ou CRI-O j\u00e1 baixaram a imagem necess\u00e1ria no host, o processo Buildah dentro do cont\u00eainer n\u00e3o precisar\u00e1 baix\u00e1-la novamente, e as compila\u00e7\u00f5es subsequentes com base nessa imagem tamb\u00e9m poder\u00e3o utilizar o que est\u00e1 no cache.<\/p>\n
Op\u00e7\u00e3o 3.<\/b> A ess\u00eancia desse m\u00e9todo \u00e9 combinar v\u00e1rias imagens em um \u00fanico projeto com uma pasta compartilhada para as imagens do cont\u00eainer.<\/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
\nNeste exemplo, n\u00e3o estamos removendo a pasta do projeto (\/var\/lib\/project3) entre as execu\u00e7\u00f5es, ent\u00e3o todas as compila\u00e7\u00f5es subsequentes no projeto se beneficiam do cache.<\/p>\n
Seguran\u00e7a.<\/i> Algo intermedi\u00e1rio entre as op\u00e7\u00f5es 1 e 2. Por um lado, os cont\u00eaineres n\u00e3o t\u00eam acesso ao conte\u00fado no host e, consequentemente, n\u00e3o podem inserir algo negativo no armazenamento de imagens do Podman\/CRI-O. Por outro lado, dentro de seu projeto, o cont\u00eainer pode interferir na constru\u00e7\u00e3o de outros cont\u00eaineres.<\/p>\n
Desempenho.<\/i> Aqui, \u00e9 pior do que usar um cache compartilhado no n\u00edvel do host, pois n\u00e3o \u00e9 poss\u00edvel usar imagens que j\u00e1 foram baixadas anteriormente por meio do Podman\/CRI-O. No entanto, depois que o Buildah baixar a imagem, essa imagem pode ser usada em quaisquer constru\u00e7\u00f5es subsequentes dentro do projeto.<\/p>\n
Armazenamentos adicionais<\/h4>\n
\nNa containers\/storage<\/a><\/noindex> H\u00e1 uma coisa incr\u00edvel chamada armaz\u00e9ns adicionais (additional stores), que permite que, ao iniciar e montar cont\u00eaineres, os motores de cont\u00eaineres possam usar armaz\u00e9ns externos de imagens em modo somente leitura. Basicamente, \u00e9 poss\u00edvel adicionar um ou mais armaz\u00e9ns 's\u00f3 para leitura' ao arquivo storage.conf, para que, ao iniciar o cont\u00eainer, o motor de cont\u00eaineres possa procurar a imagem necess\u00e1ria neles. Ele far\u00e1 o download da imagem do registro apenas se n\u00e3o encontr\u00e1-la em nenhum desses armaz\u00e9ns. O motor de cont\u00eaineres poder\u00e1 gravar apenas nos armaz\u00e9ns que t\u00eam permiss\u00e3o para escrita...<\/p>\n
Se voc\u00ea rolar para cima e olhar o Dockerfile que estamos usando para construir a imagem quay.io\/buildah\/stable, encontrar\u00e1 as seguintes linhas:<\/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
\nNa primeira linha, modificamos \/etc\/containers\/storage.conf dentro da imagem do cont\u00eainer, instruindo o driver de armazenamento a usar 'additionalimagestores' na pasta \/var\/lib\/shared. Na linha seguinte, criamos uma pasta compartilhada e adicionamos alguns arquivos de bloqueio para evitar conflitos com containers\/storage. Basicamente, estamos criando um armaz\u00e9m vazio de imagens de cont\u00eaineres. <\/p>\n
Se montarmos containers\/storage um n\u00edvel acima dessa pasta, o Buildah poder\u00e1 usar as imagens.<\/p>\n
Agora, voltemos \u00e0 Variante 2 discutida anteriormente, onde o cont\u00eainer Buildah pode ler e gravar em containers\/store nos hosts e, consequentemente, tem o m\u00e1ximo de desempenho devido ao cache das imagens no n\u00edvel do Podman\/CRI-O, mas oferece seguran\u00e7a m\u00ednima, uma vez que pode escrever diretamente nos armaz\u00e9ns. Agora, ao adicionar armaz\u00e9ns adicionais, teremos o melhor dos dois mundos.<\/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
\nObserve que \/var\/lib\/containers\/storage do host est\u00e1 montado em \/var\/lib\/shared dentro do cont\u00eainer em modo somente leitura. Portanto, ao trabalhar no cont\u00eainer, o Buildah pode usar quaisquer imagens que j\u00e1 foram baixadas pelos meios do Podman\/CRI-O (ol\u00e1, velocidade), mas pode gravar apenas em seu pr\u00f3prio armaz\u00e9m (ol\u00e1, seguran\u00e7a). Tamb\u00e9m note que isso \u00e9 feito sem desativar a separa\u00e7\u00e3o do SELinux para o cont\u00eainer.<\/p>\n
Ponto importante<\/h4>\n
\nDe forma alguma deve-se remover quaisquer imagens do armaz\u00e9m subjacente. Caso contr\u00e1rio, o cont\u00eainer Buildah pode falhar.<\/p>\n
E isso n\u00e3o \u00e9 tudo, h\u00e1 muitas outras vantagens.<\/h4>\n
\nAs capacidades de armazenamento adicionais n\u00e3o se limitam apenas ao cen\u00e1rio descrito acima. Por exemplo, \u00e9 poss\u00edvel hospedar todas as imagens de cont\u00eainer em um armazenamento de rede compartilhado e conceder acesso a todos os cont\u00eaineres Buildah. Suponhamos que temos centenas de imagens que nosso sistema CI\/CD utiliza regularmente para construir imagens de cont\u00eainer. Concentremos todas essas imagens em um \u00fanico host de armazenamento e, em seguida, usando solu\u00e7\u00f5es de armazenamento em rede preferenciais (NFS, Gluster, Ceph, ISCSI, S3\u2026), abrimos o acesso compartilhado a esse armazenamento para todos os n\u00f3s Buildah ou Kubernetes.<\/p>\n
Agora, basta montar esse armazenamento de rede no cont\u00eainer Buildah em \/var\/lib\/shared e pronto, os cont\u00eaineres Buildah n\u00e3o precisar\u00e3o mais baixar imagens via pull. Assim, eliminamos a fase de pr\u00e9-preenchimento e estamos prontos para implantar cont\u00eaineres imediatamente.<\/p>\n
E claro, isso pode ser utilizado dentro de um sistema Kubernetes ou infraestrutura de cont\u00eainer j\u00e1 existente, permitindo executar e rodar cont\u00eaineres em qualquer lugar sem ter que baixar imagens via pull. Al\u00e9m disso, o registro de cont\u00eainer, ao receber um pedido de push para o upload de uma imagem atualizada, pode automaticamente enviar essa imagem para o armazenamento de rede compartilhado, onde se torna instantaneamente acess\u00edvel a todos os n\u00f3s.<\/p>\n
Os tamanhos das imagens de cont\u00eainer podem \u00e0s vezes alcan\u00e7ar v\u00e1rios gigabytes. A funcionalidade de armazenamento adicional permite evitar a clonagem dessas imagens nos n\u00f3s e torna o lan\u00e7amento de cont\u00eaineres praticamente instant\u00e2neo.<\/p>\n
Al\u00e9m disso, neste momento estamos trabalhando em uma nova fun\u00e7\u00e3o de montagens de volume overlay, que tornar\u00e1 a constru\u00e7\u00e3o de cont\u00eaineres ainda mais r\u00e1pida.<\/p>\n
Conclus\u00e3o<\/h3>\n
\nExecutar Buildah dentro de um cont\u00eainer em um ambiente Kubernetes\/CRI-O, Podman ou at\u00e9 mesmo no Docker \u00e9 absolutamente vi\u00e1vel, al\u00e9m de ser simples e muito mais seguro do que usar docker.socket. Aumentamos consideravelmente a flexibilidade ao trabalhar com imagens, e agora voc\u00ea pode execut\u00e1-las de v\u00e1rias maneiras para otimizar a seguran\u00e7a e o desempenho.<\/p>\n
A funcionalidade de armazenamento adicional permite acelerar ou at\u00e9 mesmo eliminar completamente o download de imagens nos n\u00f3s.
\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\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\udd47Recomenda\u00e7\u00f5es para executar Buildah dentro de um cont\u00eainer | ProHoster","description":"Qual \u00e9 a vantagem de dividir o ambiente de execu\u00e7\u00e3o de cont\u00eaineres em componentes de ferramentas distintas?","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/rekomendatsii-po-zapusku-buildah-vnutri-kontejnera","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/38785","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=38785"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/38785\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/29093"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=38785"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=38785"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=38785"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}