{"id":82244,"date":"2020-05-20T13:42:45","date_gmt":"2020-05-20T11:42:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov"},"modified":"2020-05-20T13:42:45","modified_gmt":"2020-05-20T11:42:45","slug":"luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","title":{"rendered":"Mejores pr\u00e1cticas de Kubernetes. Creaci\u00f3n de contenedores peque\u00f1os","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Mejores
\n
\nEl primer paso para desplegar en Kubernetes es colocar tu aplicaci\u00f3n en un contenedor. En esta serie, exploraremos c\u00f3mo puedes crear una imagen de un contenedor peque\u00f1o y seguro.
\nGracias a Docker, crear im\u00e1genes de contenedores nunca ha sido tan f\u00e1cil. Especifica una imagen base, a\u00f1ade tus cambios y crea el contenedor.<\/p>\n

\"Mejores
\n
\nA pesar de que este enfoque es excelente para empezar, utilizar im\u00e1genes base predeterminadas puede llevar a un funcionamiento inseguro con im\u00e1genes grandes que est\u00e1n llenas de vulnerabilidades.<\/a><\/noindex><\/p>\n

Adem\u00e1s, la mayor\u00eda de las im\u00e1genes en Docker utilizan Debian o Ubuntu como imagen base, y aunque esto proporciona una excelente compatibilidad y f\u00e1cil adaptaci\u00f3n (el archivo Docker ocupa solo dos l\u00edneas de c\u00f3digo), las im\u00e1genes base pueden a\u00f1adir cientos de megabytes de carga adicional a tu contenedor. Por ejemplo, un simple archivo de aplicaci\u00f3n node.js 'hello-world' ocupa alrededor de 700 megabytes, mientras que el tama\u00f1o real de tu aplicaci\u00f3n es solo de unos pocos megabytes.<\/p>\n

\"Mejores
\n
\nAs\u00ed, toda esta carga adicional es un desperdicio de espacio digital y un excelente escondite para vulnerabilidades y fallos en el sistema de seguridad. Por lo tanto, veamos dos maneras de reducir el tama\u00f1o de la imagen del contenedor. <\/p>\n

La primera es utilizar im\u00e1genes base de tama\u00f1o peque\u00f1o, la segunda es implementar el patr\u00f3n de dise\u00f1o Builder Pattern. Usar im\u00e1genes base m\u00e1s peque\u00f1as es probablemente la forma m\u00e1s sencilla de reducir el tama\u00f1o de tu contenedor. Es probable que tu lenguaje o stack que est\u00e1s utilizando proporcione una imagen original de la aplicaci\u00f3n mucho m\u00e1s peque\u00f1a que la imagen predeterminada. Echemos un vistazo a nuestro contenedor node.js. <\/p>\n

\"Mejores
\n
\nPor defecto, el tama\u00f1o de la imagen base node:8 en Docker es de 670 MB, mientras que el tama\u00f1o de node:8-alpine es de solo 65 MB, es decir, 10 veces menos. Al usar una imagen base m\u00e1s peque\u00f1a como Alpine, reducir\u00e1s significativamente el tama\u00f1o de tu contenedor. Alpine es una distribuci\u00f3n de Linux peque\u00f1a y ligera, muy popular entre los usuarios de Docker, ya que es compatible con muchas aplicaciones manteniendo un tama\u00f1o reducido de los contenedores. A diferencia de la imagen est\u00e1ndar de Docker 'node', 'node:alpine' elimina muchos archivos y programas innecesarios, dejando solo lo esencial para ejecutar tu aplicaci\u00f3n.<\/p>\n

Para cambiar a una imagen base m\u00e1s peque\u00f1a, simplemente actualiza tu archivo Docker para comenzar a trabajar con la nueva imagen base:<\/p>\n

\"Mejores
\n
\nAhora, a diferencia de la antigua imagen onbuild, necesitas copiar tu c\u00f3digo al contenedor e instalar las dependencias. En el nuevo archivo Docker, el contenedor comienza con la imagen node:alpine, luego crea un directorio para el c\u00f3digo, instala las dependencias usando el gestor de paquetes NPM y, finalmente, ejecuta server.js.<\/p>\n

\"Mejores
\n
\nCon esta actualizaci\u00f3n se obtiene un contenedor 10 veces m\u00e1s peque\u00f1o. Si tu lenguaje de programaci\u00f3n o stack no dispone de una funci\u00f3n para reducir la imagen base, utiliza Alpine Linux. Esto tambi\u00e9n te dar\u00e1 la posibilidad de gestionar completamente el contenido del contenedor. Usar im\u00e1genes base de peque\u00f1o tama\u00f1o es una excelente forma de crear contenedores peque\u00f1os r\u00e1pidamente. Pero se puede lograr una reducci\u00f3n a\u00fan mayor utilizando el Patr\u00f3n de Builder.<\/p>\n

\"Mejores
\n
\nEn los lenguajes interpretados, el c\u00f3digo fuente se pasa primero al int\u00e9rprete y luego se ejecuta directamente. En los lenguajes compilados, el c\u00f3digo fuente se convierte previamente en c\u00f3digo compilado. Este proceso de compilaci\u00f3n a menudo utiliza herramientas que en realidad no son necesarias para ejecutar el c\u00f3digo. Esto significa que puedes eliminar completamente estas herramientas del contenedor final. Para esto, se puede usar el Patr\u00f3n de Builder.<\/p>\n

\"Mejores
\n
\nEl c\u00f3digo se crea en el primer contenedor y se compila. Luego, el c\u00f3digo compilado se empaqueta en el contenedor final sin los compiladores y herramientas necesarias para compilar ese c\u00f3digo. Pasemos por este proceso con una aplicaci\u00f3n de Go. Primero, pasaremos de la imagen onbuild a Alpine Linux.<\/p>\n

\"Mejores
\n
\nEn el nuevo archivo Docker, el contenedor comienza con la imagen golang:alpine. Luego, crea un directorio para el c\u00f3digo, copia el c\u00f3digo fuente en \u00e9l, compila este c\u00f3digo y ejecuta la aplicaci\u00f3n. Este contenedor es mucho m\u00e1s peque\u00f1o que el contenedor onbuild, pero a\u00fan contiene el compilador y otras herramientas de Go que realmente no necesitamos. As\u00ed que simplemente extraigamos el programa compilado y lo coloquemos en nuestro propio contenedor.<\/p>\n

\"Mejores
\n
\nPuede notar algo curioso en este archivo Docker: contiene dos l\u00edneas FROM. La primera secci\u00f3n de 4 l\u00edneas se ve exactamente igual que el archivo Docker anterior, salvo que utiliza la palabra clave AS para darle un nombre a esta etapa. En la siguiente secci\u00f3n hay una nueva l\u00ednea FROM, que permite iniciar una nueva imagen, utilizando Raw alpine como imagen base en lugar de golang:alpine.<\/p>\n

Raw Alpine Linux no tiene certificados SSL instalados, lo que causar\u00e1 fallos en la mayor\u00eda de las llamadas API a trav\u00e9s del protocolo HTTPS, as\u00ed que instalemos algunos certificados ra\u00edz CA.<\/p>\n

Y ahora lo m\u00e1s interesante: para copiar el c\u00f3digo compilado del primer contenedor al segundo, se puede usar simplemente el comando COPY, ubicado en la l\u00ednea 5 de la segunda secci\u00f3n. Este copiar\u00e1 solo un archivo de aplicaci\u00f3n y no tocar\u00e1 las herramientas auxiliares de Go. El nuevo archivo Docker de m\u00faltiples etapas tendr\u00e1 una imagen del contenedor de solo 12 megabytes, mientras que la imagen original del contenedor era de 700 megabytes, \u00a1una gran diferencia!
\nPor lo tanto, el uso de im\u00e1genes base peque\u00f1as y el patr\u00f3n de Builder son excelentes maneras de crear contenedores mucho m\u00e1s peque\u00f1os sin un gran esfuerzo.
\nEs posible que, dependiendo de la pila de la aplicaci\u00f3n, existan formas adicionales de reducir el tama\u00f1o de la imagen y el contenedor, pero \u00bfrealmente tienen las peque\u00f1as contendores una ventaja medible? Consideremos dos aspectos en los que los contenedores peque\u00f1os son extremadamente efectivos: el rendimiento y la seguridad.<\/p>\n

Para evaluar el aumento del rendimiento, consideremos la duraci\u00f3n del proceso de creaci\u00f3n del contenedor, su inserci\u00f3n en el registro (push) y la posterior recuperaci\u00f3n (pull). Puede ver que un contenedor de menor tama\u00f1o tiene una ventaja indiscutible sobre un contenedor de mayor tama\u00f1o.<\/p>\n

\"Mejores
\n
\nDocker cachear\u00e1 las capas, por lo que las compilaciones posteriores se realizar\u00e1n muy r\u00e1pidamente. Sin embargo, en muchos sistemas de CI que se utilizan para compilar y probar contenedores, las capas no se almacenan en cach\u00e9, por lo que aqu\u00ed hay un ahorro de tiempo significativo. Como puede ver, el tiempo de construcci\u00f3n de un contenedor grande, dependiendo de la potencia de su m\u00e1quina, var\u00eda de 34 a 54 segundos, mientras que al usar un contenedor reducido con el Builder Pattern, el tiempo es de entre 23 y 28 segundos. Para operaciones de este tipo, el aumento de rendimiento ser\u00e1 del 40-50%. As\u00ed que solo piense en cu\u00e1ntas veces crea y prueba su c\u00f3digo.<\/p>\n

Despu\u00e9s de que el contenedor se construye, necesita insertar su imagen de contenedor (push container image) en el registro de contenedores para luego usarla en su cl\u00faster de Kubernetes. Recomiendo usar el registro de contenedores de Google.<\/p>\n

\"Mejores
\n
\nAl usar Google Container Registry (GCR), solo paga por el almacenamiento y la red 'en bruto', y no se cobra una tarifa adicional por la gesti\u00f3n de contenedores. Es confidencial, seguro y muy r\u00e1pido. GCR utiliza muchos trucos para acelerar la operaci\u00f3n de pull. Como puede ver, la inserci\u00f3n de la imagen del contenedor Docker Container Image al usar go:onbuild, dependiendo del rendimiento de la computadora, tomar\u00e1 entre 15 y 48 segundos, mientras que la misma operaci\u00f3n con un contenedor de menor tama\u00f1o tomar\u00e1 entre 14 y 16 segundos, y para m\u00e1quinas menos potentes, la ventaja en la velocidad de operaci\u00f3n es tres veces mayor. Para m\u00e1quinas grandes, el tiempo es aproximadamente el mismo, ya que GCR utiliza una cach\u00e9 global para la base com\u00fan de im\u00e1genes, lo que significa que no necesita descargarlas en absoluto. En una computadora de baja potencia, la CPU es el cuello de botella, por lo que la ventaja de usar contenedores peque\u00f1os es mucho m\u00e1s evidente.<\/p>\n

Si utiliza GCR, le recomiendo encarecidamente que use Google Container Builder (GCB) como parte de su sistema de compilaci\u00f3n.<\/p>\n

\"Mejores
\n
\nComo pueden ver, su uso permite lograr resultados mucho mejores en la reducci\u00f3n de la duraci\u00f3n de la operaci\u00f3n Build+Push, incluso mejor que en una m\u00e1quina potente: en este caso, el proceso de construcci\u00f3n y env\u00edo de contenedores al host se acelera casi al doble. Adem\u00e1s, todos los d\u00edas obtienen 120 minutos de compilaci\u00f3n gratuitos, lo que en la mayor\u00eda de los casos satisface las necesidades de creaci\u00f3n de contenedores. <\/p>\n

A continuaci\u00f3n se presenta la m\u00e9trica de rendimiento m\u00e1s importante: la velocidad de extracci\u00f3n o descarga de contenedores Pull. Y si no le importa mucho el tiempo dedicado a la operaci\u00f3n push, la duraci\u00f3n del proceso pull influye seriamente en el rendimiento general del sistema. Supongamos que tiene un cl\u00faster de tres nodos y uno de ellos falla. Si utiliza un sistema de gesti\u00f3n, como Google Kubernetes Engine, este reemplazar\u00e1 autom\u00e1ticamente el nodo defectuoso por uno nuevo. Sin embargo, este nuevo nodo estar\u00e1 completamente vac\u00edo y tendr\u00e1 que transferir todos sus contenedores a \u00e9l para que comience a funcionar. Si la operaci\u00f3n pull es lo suficientemente larga, durante todo ese tiempo su cl\u00faster funcionar\u00e1 con menor rendimiento.<\/p>\n

Hay muchos casos en los que puede ocurrir esto: la adici\u00f3n de un nuevo nodo al cl\u00faster, la actualizaci\u00f3n de nodos o incluso el cambio a un nuevo contenedor para la implementaci\u00f3n. Por lo tanto, la minimizaci\u00f3n del tiempo de extracci\u00f3n pull se convierte en un factor clave. Es indiscutible que un contenedor peque\u00f1o se descarga mucho m\u00e1s r\u00e1pido que uno grande. Si utiliza varios contenedores en un cl\u00faster de Kubernetes, el ahorro de tiempo puede ser muy significativo.<\/p>\n

\"Mejores
\n
\nMire la comparaci\u00f3n presentada: la operaci\u00f3n pull al trabajar con contenedores peque\u00f1os toma de 4 a 9 veces menos tiempo, dependiendo de la potencia de la m\u00e1quina, que la misma operaci\u00f3n utilizando go:onbuild. El uso de im\u00e1genes base de contenedores de tama\u00f1o peque\u00f1o acelera significativamente el tiempo y la velocidad con las que los nuevos nodos de Kubernetes pueden desplegarse y salir a Internet.<\/p>\n

Examinemos el tema de la seguridad. Se cree que los contenedores m\u00e1s peque\u00f1os son mucho m\u00e1s seguros que los grandes, debido a su menor superficie de ataque. \u00bfEs esto realmente cierto? Una de las funciones m\u00e1s \u00fatiles de Google Container Registry es la capacidad de escanear autom\u00e1ticamente sus contenedores en busca de vulnerabilidades. Hace unos meses, cre\u00e9 tanto contenedores onbuild como multietapa, as\u00ed que veamos si hay alg\u00fan punto d\u00e9bil all\u00ed. <\/p>\n

\"Mejores
\n
\nLos resultados son sorprendentes: se encontraron solo 3 vulnerabilidades medias en un contenedor peque\u00f1o, mientras que en uno grande se encontraron 16 cr\u00edticas y 376 otras vulnerabilidades. Al revisar el contenido del contenedor grande, se puede ver que la mayor\u00eda de los problemas de seguridad no est\u00e1n relacionados con nuestra aplicaci\u00f3n, sino con programas que ni siquiera usamos. Por lo tanto, cuando las personas hablan de una gran superficie de ataque, se refieren precisamente a esto. <\/p>\n

\"Mejores
\n
\nLa conclusi\u00f3n es clara: crea contenedores peque\u00f1os, ya que ofrecen verdaderas ventajas en rendimiento y seguridad para tu sistema. <\/p>\n

Mejores pr\u00e1cticas de Kubernetes. Organizaci\u00f3n de Kubernetes con el espacio de nombres<\/a><\/noindex><\/p>\n

\r\n \"Reproducir\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Un poco de publicidad \ud83d\ude42<\/h3>\n

\nGracias por permanecer con nosotros. \u00bfTe gustan nuestros art\u00edculos? \u00bfQuieres ver m\u00e1s contenido interesante? Ap\u00f3yanos haciendo un pedido o recomendando a tus conocidos, VPS en la nube para desarrolladores desde $4.99<\/a><\/noindex>, un an\u00e1logo \u00fanico de servidores entry-level que hemos dise\u00f1ado para Ti:<\/b> Toda la verdad sobre VPS (KVM) E5-2697 v3 (6 n\u00facleos) 10GB DDR4 480GB SSD 1Gbps desde $19, o c\u00f3mo dividir correctamente un servidor?<\/a><\/noindex> (disponibles opciones con RAID1 y RAID10, hasta 24 n\u00facleos y hasta 40GB DDR4).<\/p>\n

\u00bfDell R730xd a mitad de precio en el centro de datos Equinix Tier IV en \u00c1msterdam?<\/b> Solo aqu\u00ed 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB desde $199<\/a><\/noindex> \u00a1en los Pa\u00edses Bajos! Dell R420 \u2014 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB \u2014 \u00a1desde $99!<\/b><\/b> Lee sobre c\u00f3mo Construir infraestructura de clase empresarial usando servidores Dell R730xd E5-2650 v4 que cuestan 9000 euros a un precio asequible?<\/a><\/noindex>
\n
Fuente: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041f\u0435\u0440\u0432\u044b\u0439 \u0448\u0430\u0433 \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u0432 Kubernetes \u2013 \u044d\u0442\u043e \u0440\u0430\u0437\u043c\u0435\u0449\u0435\u043d\u0438\u0435 \u0432\u0430\u0448\u0435\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0435. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0435\u0440\u0438\u0438 \u043c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0441\u043e\u0437\u0434\u0430\u0442\u044c \u043e\u0431\u0440\u0430\u0437 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0433\u043e \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430. \u0411\u043b\u0430\u0433\u043e\u0434\u0430\u0440\u044f Docker, \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0435 \u043e\u0431\u0440\u0430\u0437\u043e\u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 \u043d\u0438\u043a\u043e\u0433\u0434\u0430 \u0435\u0449\u0435 \u043d\u0435 \u0431\u044b\u043b\u043e \u043d\u0430\u0441\u0442\u043e\u043b\u044c\u043a\u043e \u043f\u0440\u043e\u0441\u0442\u044b\u043c. \u0423\u043a\u0430\u0436\u0438\u0442\u0435 \u0431\u0430\u0437\u043e\u0432\u044b\u0439 \u043e\u0431\u0440\u0430\u0437, \u0434\u043e\u0431\u0430\u0432\u044c\u0442\u0435 \u0441\u0432\u043e\u0438 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0438 \u0441\u043e\u0437\u0434\u0430\u0439\u0442\u0435 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440. \u041d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u0442\u043e, \u0447\u0442\u043e \u0434\u0430\u043d\u043d\u044b\u0439 \u043f\u0440\u0438\u0435\u043c \u043e\u0442\u043b\u0438\u0447\u043d\u043e \u043f\u043e\u0434\u0445\u043e\u0434\u0438\u0442 \u0434\u043b\u044f \u043d\u0430\u0447\u0430\u043b\u0430 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":82245,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-82244","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\n","aioseo_head_json":{"title":"\ud83e\udd47Mejores pr\u00e1cticas de Kubernetes. Creaci\u00f3n de contenedores peque\u00f1os | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","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\u041b\u0443\u0447\u0448\u0438\u0435 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 Kubernetes. \u0421\u043e\u0437\u0434\u0430\u043d\u0438\u0435 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 | ProHoster","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","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":"2020-05-20T11:42:45+00:00","article:modified_time":"2020-05-20T11:42:45+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"82244","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":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:41:28","updated":"2022-09-28 11:52:01","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\/82244","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=82244"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/82244\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/82245"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=82244"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=82244"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=82244"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}