{"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\/es\/blog\/administrirovanie\/rekomendatsii-po-zapusku-buildah-vnutri-kontejnera","title":{"rendered":"Recomendaciones para ejecutar Buildah dentro de un contenedor","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00bfCu\u00e1l es la ventaja de separar el entorno de ejecuci\u00f3n de contenedores en componentes instrumentales separados? En particular, que se pueden comenzar a combinar estos instrumentos para que se protejan entre s\u00ed.<\/p>\n

\"Recomendaciones
\n
\nA muchos les atrae la idea de construir im\u00e1genes OCI en el marco de Kubernetes<\/a><\/noindex> o un sistema similar. Supongamos que tenemos CI\/CD, que constantemente compila im\u00e1genes, entonces 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. Ya mostramos hace unos a\u00f1os<\/a><\/noindex>, que esto es muy inseguro, de hecho, es incluso peor que dar acceso root sin contrase\u00f1a o sudo.
\n<\/a><\/noindex>
\nPor eso la gente constantemente intenta ejecutar Buildah dentro de un contenedor. En resumen, creamos ejemplo<\/a><\/noindex> lo que, en nuestra opini\u00f3n, es la mejor manera de ejecutar Buildah dentro de un contenedor y publicamos las im\u00e1genes correspondientes en quay.io\/buildah<\/a><\/noindex>. Empecemos...<\/p>\n

Configuraci\u00f3n<\/h3>\n

\nEstas im\u00e1genes est\u00e1n construidas a partir de Dockerfiles que se pueden encontrar en el repositorio de Buildah en la carpeta buildahimage<\/a><\/noindex>.
\nAqu\u00ed revisaremos la versi\u00f3n estable de 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
\nEn lugar de OverlayFS, implementado en el nivel del n\u00facleo de Linux del host, usamos dentro del contenedor el programa fuse-overlay<\/a><\/noindex>, ya que en este momento OverlayFS solo puede montar si se le otorgan los permisos SYS_ADMIN a trav\u00e9s de las capacidades de Linux. Y queremos ejecutar nuestros contenedores Buildah sin ning\u00fan privilegio de nivel root. Fuse-overlay funciona bastante r\u00e1pido y tiene mejor rendimiento que el controlador de almacenamiento VFS. Note que al ejecutar un contenedor Buildah que usa Fuse, se debe proporcionar el 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
\nA continuaci\u00f3n, creamos un directorio para los almacenes adicionales. Container\/storage<\/a><\/noindex> soporta la concepto de adjuntar almacenes de im\u00e1genes de solo lectura adicionales. Por ejemplo, se puede configurar un \u00e1rea de almacenamiento en superposici\u00f3n en una m\u00e1quina y luego montarla en otra m\u00e1quina utilizando NFS y usar las im\u00e1genes de ella sin tener que descargarlas mediante pull. Necesitamos este almacenamiento para poder montar, como volumen, alg\u00fan almacenamiento de im\u00e1genes desde el host y utilizarlo dentro del contenedor.<\/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
\nY finalmente, utilizando la variable de entorno BUILDAH_ISOLATION, indicamos que por defecto el contenedor de Buildah debe ejecutarse con aislamiento chroot. No se requiere aislamiento adicional aqu\u00ed, ya que estamos trabajando en un contenedor. Para que Buildah pueda crear sus propios contenedores con separaci\u00f3n de espacios de nombres, se necesita privilegio SYS_ADMIN, y para ello ser\u00e1 necesario relajar las reglas de SELinux y SECCOMP para el contenedor, lo que contradice nuestra configuraci\u00f3n de realizar la construcci\u00f3n desde un contenedor seguro.<\/p>\n
Ejecutando Buildah dentro del contenedor<\/h3>\n
\nEl esquema de imagen del contenedor de Buildah considerado anteriormente permite variar de manera flexible las formas de ejecutar dichos contenedores.<\/p>\n
Velocidad frente a seguridad<\/h4>\n
\nLa seguridad inform\u00e1tica siempre es un compromiso entre la velocidad de ejecuci\u00f3n del proceso y cu\u00e1nta protecci\u00f3n se ha implementado a su alrededor. Esta afirmaci\u00f3n es cierta tambi\u00e9n al construir contenedores, por lo que a continuaci\u00f3n examinaremos las opciones para este tipo de compromiso.<\/p>\n
La imagen de contenedor discutida anteriormente mantendr\u00e1 su almacenamiento en \/var\/lib\/containers. Por lo tanto, necesitamos montar contenido en esta carpeta, y la forma en que lo haremos tendr\u00e1 un impacto significativo en la velocidad de construcci\u00f3n de las im\u00e1genes de contenedores.<\/p>\n
Consideremos tres opciones.<\/p>\n
Opci\u00f3n 1.<\/b> Si se requiere la m\u00e1xima seguridad, se puede crear una carpeta para cada contenedor para containers\/image y conectarla al contenedor a trav\u00e9s de un volumen montado. Adem\u00e1s, se puede ubicar el directorio de contexto dentro del contenedor, en la carpeta \/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
\nSeguridad.<\/i> Trabajar en un contenedor as\u00ed con Buildah proporciona la m\u00e1xima seguridad: no se le otorgan privilegios de root mediante capacidades, y se aplican todas las restricciones de SECOMP y SELinux. Incluso se puede ejecutar este contenedor con aislamiento de User Namespace, a\u00f1adiendo una opci\u00f3n como \u2014uidmap 0:100000:10000.<\/p>\n
Rendimiento.<\/i> Sin embargo, el rendimiento aqu\u00ed es m\u00ednimo, ya que cualquier imagen de los registros de contenedores se copia en cada ocasi\u00f3n al host, y la cach\u00e9 no funciona en absoluto. Al finalizar su trabajo, el contenedor de Buildah debe enviar la imagen al registro y destruir el contenido en el host. Cuando se construya la imagen del contenedor la pr\u00f3xima vez, deber\u00e1 descargarse nuevamente del registro, ya que para ese momento ya no quedar\u00e1 nada en el host.<\/p>\n
Opci\u00f3n 2.<\/b> Si se necesita rendimiento al nivel de Docker, se puede montar container\/storage del host directamente en el contenedor.<\/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
\nSeguridad.<\/i> Este es el m\u00e9todo menos seguro para construir contenedores, ya que aqu\u00ed se permite al contenedor modificar el almacenamiento en el host, lo que podr\u00eda potencialmente introducir una imagen maliciosa a Podman o CRI-O. Adem\u00e1s, ser\u00e1 necesario desactivar la separaci\u00f3n de SELinux para que los procesos en el contenedor de Buildah puedan interactuar con el almacenamiento en el host. Tenga en cuenta que esta opci\u00f3n sigue siendo mejor que el socket de Docker, ya que el contenedor est\u00e1 bloqueado por las funciones de seguridad restantes y no puede simplemente ejecutar alg\u00fan contenedor en el host.<\/p>\n
Rendimiento.<\/i> Aqu\u00ed es m\u00e1xima, ya que se utiliza completamente la cach\u00e9. Si Podman o CRI-O ya han descargado la imagen necesaria en el host, entonces el proceso de Buildah dentro del contenedor no necesitar\u00e1 descargarla nuevamente, y las siguientes construcciones basadas en esta imagen tambi\u00e9n podr\u00e1n tomar lo necesario de la cach\u00e9.<\/p>\n
Opci\u00f3n 3.<\/b> La esencia de este m\u00e9todo es combinar varias im\u00e1genes en un solo proyecto con una carpeta com\u00fan para las im\u00e1genes de contenedor.<\/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
\nEn este ejemplo, no eliminamos la carpeta del proyecto (\\\/var\\\/lib\\\/project3) entre ejecuciones, por lo que todas las siguientes construcciones dentro del proyecto se benefician de la cach\u00e9.<\/p>\n
Seguridad.<\/i> Algo intermedio entre las opciones 1 y 2. Por un lado, los contenedores no tienen acceso al contenido en el host y, por lo tanto, no pueden introducir algo malo en el almacenamiento de im\u00e1genes de Podman\\\/CRI-O. Por otro lado, dentro de su proyecto, el contenedor puede interferir en la construcci\u00f3n de otros contenedores.<\/p>\n
Rendimiento.<\/i> Aqu\u00ed es peor que al usar cach\u00e9 compartida a nivel de host, ya que no se pueden usar im\u00e1genes que ya se hayan descargado anteriormente por Podman\\\/CRI-O. Sin embargo, una vez que Buildah descarga la imagen, esta imagen se puede utilizar en cualquier construcci\u00f3n posterior dentro del proyecto.<\/p>\n
Almacenes adicionales<\/h4>\n
\nEn containers\\\/storage<\/a><\/noindex> Hay una cosa genial llamada almacenes adicionales (additional stores), gracias a la cual, al iniciar y construir contenedores, los motores de contenedores pueden utilizar almacenes externos de im\u00e1genes en modo de superposici\u00f3n de solo lectura. En esencia, se puede agregar uno o varios almacenes 'solo lectura' en el archivo storage.conf, para que luego, al iniciar un contenedor, el motor de contenedores busque la imagen necesaria en ellos. De hecho, solo descargar\u00e1 la imagen del registro si no la encuentra en ninguno de estos almacenes. El motor de contenedores podr\u00e1 escribir solo en almacenes accesibles para escritura...<\/p>\n
Si desplazamos hacia arriba y miramos el Dockerfile que estamos utilizando para construir la imagen quay.io\/buildah\/stable, hay l\u00edneas como estas:<\/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
\nEn la primera l\u00ednea, modificamos \/etc\/containers\/storage.conf dentro de la imagen del contenedor, indicando al controlador de almacenamiento que use 'additionalimagestores' en la carpeta \/var\/lib\/shared. En la siguiente l\u00ednea, creamos una carpeta compartida y a\u00f1adimos un par de archivos de bloqueo para evitar conflictos con containers\/storage. En esencia, simplemente estamos creando un almac\u00e9n vac\u00edo de im\u00e1genes de contenedores. <\/p>\n
Si montamos containers\/storage un nivel por encima de esta carpeta, Buildah podr\u00e1 usar las im\u00e1genes.<\/p>\n
Ahora regresemos a la Opci\u00f3n 2 mencionada anteriormente, donde el contenedor de Buildah puede leer y escribir en containers\/store en los hosts y, por tanto, tiene un rendimiento m\u00e1ximo gracias a la cach\u00e9 de im\u00e1genes a nivel de Podman\/CRI-O, pero ofrece m\u00ednimo seguridad, ya que puede escribir directamente en los almacenes. Y ahora sumemos almacenes adicionales y obtengamos lo mejor de ambos 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
\nTenga en cuenta que \/var\/lib\/containers\/storage del host est\u00e1 montada en \/var\/lib\/shared dentro del contenedor en modo de solo lectura. Por lo tanto, al trabajar en el contenedor, Buildah puede usar cualquier imagen que haya sido descargada previamente a trav\u00e9s de Podman\/CRI-O (hola, velocidad), pero puede escribir solo en su propio almac\u00e9n (hola, seguridad). Tambi\u00e9n tenga en cuenta que esto se hace sin desactivar la separaci\u00f3n de SELinux para el contenedor.<\/p>\n
Un detalle importante<\/h4>\n
\nDe ninguna manera se deben eliminar im\u00e1genes del almac\u00e9n subyacente. De lo contrario, el contenedor de Buildah podr\u00eda fallar.<\/p>\n
Y estas no son todas las ventajas<\/h4>\n
\nLas capacidades de los almacenes adicionales no se limitan solo al escenario mencionado anteriormente. Por ejemplo, se pueden alojar todas las im\u00e1genes de contenedor en un almacenamiento de red com\u00fan y dar acceso a todos los contenedores de Buildah. Supongamos que tenemos cientos de im\u00e1genes que nuestro sistema CI\/CD utiliza regularmente para construir im\u00e1genes de contenedor. Concentramos todas estas im\u00e1genes en un \u00fanico host-almacenamiento y luego, utilizando las herramientas de almacenamiento en red preferidas (NFS, Gluster, Ceph, ISCSI, S3\u2026), otorgamos acceso compartido a este almacenamiento a todos los nodos de Buildah o Kubernetes.<\/p>\n
Ahora solo es necesario montar este almac\u00e9n de red en el contenedor de Buildah en \/var\/lib\/shared y listo: los contenedores de Buildah ya no tendr\u00e1n que descargar im\u00e1genes a trav\u00e9s de pull. As\u00ed, eliminamos la fase de pre-poblaci\u00f3n y estamos listos para desplegar contenedores de inmediato.<\/p>\n
Y, por supuesto, esto se puede utilizar en el marco de un sistema Kubernetes existente o una infraestructura de contenedores, para ejecutar y operar contenedores en cualquier lugar sin descargar im\u00e1genes a trav\u00e9s de pull. Adem\u00e1s, el registro de contenedores, al recibir una petici\u00f3n push para cargar una imagen actualizada, puede enviar autom\u00e1ticamente esta imagen al almac\u00e9n de red compartido, donde se hace disponible de inmediato a todos los nodos.<\/p>\n
Los tama\u00f1os de las im\u00e1genes de los contenedores a veces pueden alcanzar varios gigabytes. La funcionalidad de almacenes adicionales permite evitar la clonaci\u00f3n de estas im\u00e1genes en los nodos y hace que el lanzamiento de contenedores sea pr\u00e1cticamente instant\u00e1neo.<\/p>\n
Adem\u00e1s, actualmente estamos trabajando en una nueva funci\u00f3n de montajes de vol\u00famenes superpuestos, que har\u00e1 que la construcci\u00f3n de contenedores sea a\u00fan m\u00e1s r\u00e1pida.<\/p>\n
Conclusi\u00f3n<\/h3>\n
\nEjecutar Buildah dentro de un contenedor en un entorno Kubernetes\/CRI-O, Podman o incluso en Docker es completamente posible; adem\u00e1s, es simple y mucho m\u00e1s seguro que usar docker.socket. Hemos aumentado significativamente la flexibilidad en el trabajo con im\u00e1genes, y ahora puede ejecutarlas de varias maneras para lograr un equilibrio \u00f3ptimo entre seguridad y rendimiento.<\/p>\n
La funcionalidad de almacenes adicionales permite acelerar o incluso eliminar por completo la descarga de im\u00e1genes en los nodos.
\n
Fuente: 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\udd47Recomendaciones para ejecutar Buildah dentro de un contenedor | ProHoster","description":"\u00bfCu\u00e1l es la ventaja de dividir el entorno de ejecuci\u00f3n de contenedores en componentes de herramientas separados?","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/rekomendatsii-po-zapusku-buildah-vnutri-kontejnera","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/38785","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=38785"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/38785\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/29093"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=38785"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=38785"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=38785"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}