{"id":34596,"date":"2019-10-31T21:59:16","date_gmt":"2019-10-31T18:59:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/zhivut-li-bazy-dannyh-v-kubernetes\/"},"modified":"2019-10-31T21:59:16","modified_gmt":"2019-10-31T18:59:16","slug":"zhivut-li-bazy-dannyh-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","title":{"rendered":"\u00bfViven las bases de datos en Kubernetes?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\u00bfViven
\n
\nHist\u00f3ricamente, la industria de TI se ha dividido en dos campos condicionales: los que est\u00e1n \"a favor\" y los que est\u00e1n \"en contra\". Y el tema de disputas puede ser absolutamente arbitrario. \u00bfCu\u00e1l es el mejor sistema operativo: Win o Linux? \u00bfSmartphone Android o iOS? \u00bfAlmacenar todo en la nube o subirlo a fr\u00edos almacenamientos RAID y meter los discos en la caja fuerte? \u00bfTienen los desarrolladores de PHP derecho a llamarse programadores? Estas disputas son, a veces, de naturaleza exclusivamente existencial y no tienen ninguna base tangible, m\u00e1s all\u00e1 del inter\u00e9s deportivo.<\/p>\n

As\u00ed result\u00f3 que con la aparici\u00f3n de los contenedores y toda esta querida cocina con Docker y el condicional k8s, comenzaron tambi\u00e9n las disputas \"a favor\" y \"en contra\" del uso de nuevas capacidades en varias \u00e1reas del backend. (Aclaramos de antemano que aunque ese razonamiento suele referirse a Kubernetes como orquestador, la elecci\u00f3n de esta herramienta en particular no tiene importancia. Puedes sustituirla por cualquier otra que te parezca m\u00e1s conveniente y familiar.)<\/p>\n

Y, a primera vista, podr\u00eda parecer un simple debate entre dos lados de una misma moneda. Tan sin sentido e implacable como la eterna confrontaci\u00f3n Win vs Linux, donde personas razonables se encuentran en alg\u00fan punto intermedio. Pero en el caso de la contenedorizaci\u00f3n, no todo es tan simple. Normalmente, en tales disputas no hay un lado correcto, pero en el caso de \"utilizar\" o \"no utilizar\" contenedores para almacenar bases de datos, todo se complica. Porque en cierto sentido, tanto los defensores como los detractores de este enfoque tienen raz\u00f3n.
\n<\/a><\/noindex><\/p>\n

Lado Luminoso<\/h4>\n

\nSe puede resumir la argumentaci\u00f3n del Lado Luminoso en una frase: \u201c\u00a1Hola, 2k19 afuera!\u201d Suena a populismo, ciertamente, pero si se analiza la situaci\u00f3n en detalle, hay sus ventajas. Eso es lo que vamos a desglosar ahora.<\/p>\n

Supongamos que tienes un gran proyecto web. Podr\u00eda haberse construido inicialmente con un enfoque de microservicios, o quiz\u00e1s lleg\u00f3 a ello de manera evolutiva en alg\u00fan momento\u2014esto no es muy importante, en realidad. Has distribuido nuestro proyecto en microservicios individuales, configurado la orquestaci\u00f3n, la equilibraci\u00f3n de carga y la escalabilidad. Y ahora, con la conciencia tranquila, disfrutas de un mojito en la hamaca durante los efectos de Habr, en vez de levantar servidores ca\u00eddos. Pero en todas las acciones debes ser consistente. Muy a menudo, solo se contenedoriza directamente la aplicaci\u00f3n en s\u00ed: el c\u00f3digo. \u00bfY qu\u00e9 m\u00e1s tenemos adem\u00e1s del c\u00f3digo?<\/p>\n

Correcto, los datos. El coraz\u00f3n de cualquier proyecto son sus datos: puede ser una base de datos t\u00edpica como MySQL, Postgre, MongoDB, as\u00ed como almacenes utilizados para b\u00fasqueda (ElasticSearch), almacenes key-value para cach\u00e9\u2014por ejemplo, redis, etc. Ahora no vamos a hablar de implementaciones defectuosas del backend, donde la base de datos falla debido a consultas mal escritas, sino que hablaremos sobre c\u00f3mo asegurar la tolerancia a fallos de esa base de datos ante la carga del cliente. Es que cuando contenedorizamos nuestra aplicaci\u00f3n y le permitimos escalar libremente para manejar cualquier cantidad de solicitudes entrantes, esto naturalmente aumenta tambi\u00e9n la carga en la base de datos.<\/p>\n

De hecho, el canal de acceso a la base de datos y el servidor donde esta se ejecuta se convierten en un cuello de botella en nuestro maravilloso backend contenedorizado. Con esto, el principal objetivo de la virtualizaci\u00f3n de contenedores\u2014ser una estructura flexible y din\u00e1mica\u2014permite organizar la distribuci\u00f3n de la carga m\u00e1xima a trav\u00e9s de toda la infraestructura que tenemos disponible de manera m\u00e1s eficiente. Es decir, si no contenedorizamos y no distribuimos por cl\u00faster todos los elementos del sistema que tenemos, estamos cometiendo un error muy grave.<\/p>\n

Es mucho m\u00e1s l\u00f3gico agrupar no solo la aplicaci\u00f3n en s\u00ed, sino tambi\u00e9n los servicios responsables del almacenamiento de datos. Al agrupar y desplegar servidores web independientes y distribuidos entre s\u00ed en k8s, ya resolvemos el problema de la sincronizaci\u00f3n de datos, como por ejemplo los comentarios en publicaciones, si tomamos como ejemplo un medio de comunicaci\u00f3n o una plataforma de blogs. En cualquier caso, se establece una representaci\u00f3n interna de la base de datos, aunque sea virtual, como un ExternalService. La cuesti\u00f3n es que la propia base de datos a\u00fan no est\u00e1 agrupada; los servidores web desplegados en el cl\u00faster obtienen informaci\u00f3n sobre cambios desde nuestra base de datos de producci\u00f3n est\u00e1tica, que opera de forma separada.<\/p>\n

\u00bfSientes un truco? Usamos k8s o Swarm para distribuir la carga y evitar la ca\u00edda de lo principal, de un servidor web<\/a>, pero no hacemos esto para la base de datos. Pero si la base de datos cae, no tiene sentido en nuestra infraestructura agrupada; \u00bfde qu\u00e9 sirve tener p\u00e1ginas web vac\u00edas que devuelven un error de acceso a la base de datos?<\/p>\n

Por eso es importante agrupar no solo los servidores web, como se suele hacer, sino tambi\u00e9n la infraestructura de la base de datos. Solo as\u00ed podemos garantizar una estructura que funcione plenamente en una sola unidad, pero que sea independiente entre s\u00ed. De este modo, incluso si 'colapsa' la mitad de nuestro backend bajo carga, el resto sobrevivir\u00e1, y el sistema de sincronizaci\u00f3n de bases de datos dentro del cl\u00faster, junto con la posibilidad de escalado infinito y despliegue de nuevos cl\u00fasteres, ayudar\u00e1 a alcanzar r\u00e1pidamente la capacidad necesaria, siempre que haya bastidores en el centro de datos.<\/p>\n

Adem\u00e1s, el modelo de base de datos distribuido en cl\u00fasteres permite llevar dicha base de datos a donde se necesite; si hablamos de un servicio global, no tiene mucho sentido tener un cl\u00faster web en alg\u00fan lugar de San Francisco y enviar paquetes para acceder a la base de datos en la regi\u00f3n de Mosc\u00fa y de vuelta.<\/p>\n

La contenedorizaci\u00f3n de la base de datos tambi\u00e9n permite construir todos los elementos del sistema en el mismo nivel de abstracci\u00f3n. Lo que, a su vez, hace posible gestionar este sistema directamente desde el c\u00f3digo, por parte de los desarrolladores, sin necesidad de involucrar activamente a los administradores. A los desarrolladores se les ocurri\u00f3 que necesitaban una base de datos separada para un nuevo subproyecto: \u00a1f\u00e1cil! Escribieron un archivo yaml, lo cargaron en el cl\u00faster y listo.<\/p>\n

Y por supuesto, la operaci\u00f3n interna se simplifica enormemente. Diga, \u00bfcu\u00e1ntas veces ha cerrado los ojos en momentos en que un nuevo miembro del equipo se ha introducido en la base de datos en producci\u00f3n? Esa que, de hecho, es la \u00fanica que est\u00e1 en uso en este momento. Claro, todos somos adultos aqu\u00ed, y seguramente tenemos un respaldo reciente, y m\u00e1s all\u00e1, detr\u00e1s de los pepinos de la abuela y los esqu\u00eds viejos, hay otro respaldo, posiblemente incluso en almacenamiento fr\u00edo, porque una vez su oficina se incendi\u00f3. Pero aun as\u00ed, cada nueva incorporaci\u00f3n al equipo que tiene acceso a la infraestructura de producci\u00f3n y, por supuesto, a la base de datos en vivo, es un verdadero dolor de est\u00f3mago para todos. \u00bfQui\u00e9n sabe c\u00f3mo es, el principiante? Da miedo, \u00bfno cree?<\/p>\n

La contenedorizaci\u00f3n y, de hecho, la topolog\u00eda f\u00edsica distribuida de la base de datos de su proyecto ayudan a evitar momentos de ansiedad como esos. \u00bfNo conf\u00eda en el nuevo? \u00a1Est\u00e1 bien! Le levantaremos un cl\u00faster propio para trabajar y lo desconectaremos de los dem\u00e1s cl\u00fasteres de base de datos: la sincronizaci\u00f3n ser\u00e1 solo por un push manual y la rotaci\u00f3n simult\u00e1nea de dos llaves (una para el l\u00edder de equipo y otra para el administrador). Y todos estar\u00e1n felices.<\/p>\n

Y ahora es momento de cambiar de opini\u00f3n sobre la cl\u00fasterizaci\u00f3n de bases de datos.<\/p>\n

El Lado Oscuro<\/h4>\n

\nAl reflexionar por qu\u00e9 no se debe contenedizar una base de datos y continuar oper\u00e1ndola en una central \u00fanica, servidor<\/a>, no vamos a caer en la ret\u00f3rica de los ortodoxos y afirmaciones como \"nuestros ancestros operaban bases de datos en hardware, \u00a1y nosotros tambi\u00e9n lo haremos!\" En lugar de eso, intentemos crear una situaci\u00f3n en la que la contenedorizaci\u00f3n realmente traiga beneficios tangibles.<\/p>\n

Acept\u00e9moslo, los proyectos que realmente necesitan una base de datos en un contenedor se pueden contar con los dedos de una mano de un fresador no muy competente. En su mayor\u00eda, incluso el uso de k8s o Docker Swarm puede ser excesivo; a menudo se utilizan estas herramientas debido a la moda general de vender la tecnolog\u00eda y las directrices de los superiores para llevar todo a la nube y los contenedores. Bueno, porque ahora est\u00e1 de moda y todos lo est\u00e1n haciendo.<\/p>\n

En al menos la mitad de los casos, usar Kubernetes o simplemente Docker en un proyecto es redundante. La cuesti\u00f3n es que no todos los equipos o las empresas de outsourcing contratadas para gestionar la infraestructura del cliente se dan cuenta de esto. Lo peor es cuando se imponen contenedores, ya que esto representa un cierto coste para el cliente.<\/p>\n

En general, existe la opini\u00f3n de que Docker\/Kube-mafia simplemente acapara a los clientes que externalizan estas cuestiones de infraestructura. Para trabajar con cl\u00fasteres, se necesitan ingenieros que sean capaces de hacerlo y que comprendan la arquitectura de la soluci\u00f3n implementada. Ya hemos descrito nuestro caso con la publicaci\u00f3n de Republic: all\u00ed entrenamos al equipo del cliente para trabajar en el contexto de Kubernetes, y todos quedaron satisfechos. Y fue bastante razonable. Sin embargo, a menudo los 'implementadores' de k8s toman la infraestructura del cliente como reh\u00e9n: ahora solo ellos entienden c\u00f3mo funciona todo, mientras que en el lado del cliente no hay especialistas.<\/p>\n

Ahora imagina que de esta manera no solo estamos delegando la parte del servidor web al outsourcing, sino tambi\u00e9n el mantenimiento de la base de datos. Decimos que la base de datos es el coraz\u00f3n, y perder el coraz\u00f3n es fatal para cualquier organismo vivo. En resumen, las perspectivas no son las mejores. As\u00ed que, en lugar del 'hype' de Kubernetes, muchos proyectos deber\u00edan simplemente no ser taca\u00f1os y elegir un plan decente en AWS, que resolver\u00e1 todos los problemas de carga en su sitio\/proyecto. Pero AWS ya no est\u00e1 de moda, y las apariencias son m\u00e1s caras que el dinero; lamentablemente, tambi\u00e9n en el entorno de TI.<\/p>\n

Est\u00e1 bien. Quiz\u00e1s la agrupaci\u00f3n sea realmente necesaria para el proyecto, pero si con las aplicaciones sin estado todo est\u00e1 claro, \u00bfc\u00f3mo entonces organizar un suministro adecuado de conectividad en una base de datos cl\u00fasterizada?<\/p>\n

Si hablamos de una soluci\u00f3n de ingenier\u00eda sin costuras, que es lo que representa la transici\u00f3n a k8s, nuestra principal preocupaci\u00f3n es la replicaci\u00f3n de datos en una base de datos cl\u00fasterizada. Algunas bases de datos son bastante permisivas respecto a la distribuci\u00f3n de datos entre sus diferentes instancias. Sin embargo, muchas otras no son tan amables. A menudo, el argumento principal para elegir una base de datos para nuestro proyecto no radica en su capacidad de replicarse con el m\u00ednimo de recursos y costos de ingenier\u00eda. Especialmente si el proyecto no se planific\u00f3 desde el principio como microservicio, sino que simplemente evolucion\u00f3 en esa direcci\u00f3n. <\/p>\n

No es necesario hablar de la velocidad de los discos de red: son lentos. Es decir, no tenemos la posibilidad real de, en caso necesario, levantar una instancia de base de datos en un lugar donde haya, por ejemplo, m\u00e1s potencia de procesamiento o m\u00e1s memoria RAM disponible. R\u00e1pidamente nos toparemos con el rendimiento del subsistema de disco virtualizado. Por lo tanto, la base de datos debe estar atada a su propio conjunto personal de m\u00e1quinas que se encuentren en estrecha proximidad. O bien, se debe encontrar una manera de garantizar una sincronizaci\u00f3n de datos lo suficientemente r\u00e1pida hacia las reservas previstas. <\/p>\n

Continuando con el tema de los sistemas de archivos virtuales: los vol\u00famenes de Docker, desafortunadamente, no est\u00e1n exentos de problemas. En general, en cuestiones de almacenamiento de datos a largo plazo y de manera confiable, preferir\u00edamos ce\u00f1irnos a esquemas t\u00e9cnicos lo m\u00e1s simples posible. A\u00f1adir un nuevo nivel de abstracci\u00f3n desde el sistema de archivos del contenedor al sistema de archivos del host parental ya es en s\u00ed mismo un riesgo. Pero cuando, adem\u00e1s, surgen dificultades en el funcionamiento del sistema de contenedores para transmitir datos entre estas capas, la situaci\u00f3n empeora a\u00fan m\u00e1s. Actualmente, la mayor\u00eda de los problemas conocidos que incomodan a la humanidad parecen haber sido erradicados. Pero ya comprendemos que cuanto m\u00e1s complejo es el mecanismo, m\u00e1s f\u00e1cil es que se rompa.<\/p>\n

A la luz de todas estas \"aventuras\", es mucho m\u00e1s rentable y sencillo mantener la base de datos en un solo lugar, y aunque necesites la containerizaci\u00f3n de la aplicaci\u00f3n, que funcione por s\u00ed sola y reciba una conexi\u00f3n simult\u00e1nea a la base de datos a trav\u00e9s de un gateway, que se leer\u00e1 y escribir\u00e1 una sola vez y en un solo lugar. Este enfoque reduce la probabilidad de errores y desincronizaciones al m\u00ednimo.<\/p>\n

\u00bfA d\u00f3nde queremos llegar? A que la containerizaci\u00f3n de base de datos es pertinente donde existe una necesidad real. No se puede meter la base de datos de una aplicaci\u00f3n completa y hacerla funcionar como si tuvieras una veintena de microservicios; eso no funciona. Y esto necesita estar claro.<\/p>\n

En lugar de la salida<\/h4>\n

\nSi esperas una conclusi\u00f3n clara sobre si \"virtualizar o no la base de datos\", te decepcionaremos: no la habr\u00e1 aqu\u00ed. Porque al crear cualquier soluci\u00f3n de infraestructura, hay que guiarse no por la moda y el progreso, sino, sobre todo, por el sentido com\u00fan.<\/p>\n

Existen proyectos para los cuales los principios y herramientas que vienen con Kubernetes encajan perfectamente, y en tales proyectos se establece la paz, al menos en el \u00e1mbito del backend. Y hay proyectos que no necesitan containerizaci\u00f3n, sino una infraestructura de servidor adecuada, porque no pueden escalar bajo un modelo de cl\u00faster de microservicios; de lo contrario, colapsar\u00e1n.
\n
Fuente: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041a\u0430\u043a-\u0442\u043e \u0442\u0430\u043a \u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438 \u0441\u043b\u043e\u0436\u0438\u043b\u043e\u0441\u044c, \u0447\u0442\u043e IT-\u0438\u043d\u0434\u0443\u0441\u0442\u0440\u0438\u044f \u043f\u043e \u043b\u044e\u0431\u043e\u043c\u0443 \u043f\u043e\u0432\u043e\u0434\u0443 \u0440\u0430\u0437\u0431\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u043d\u0430 \u0434\u0432\u0430 \u0443\u0441\u043b\u043e\u0432\u043d\u044b\u0445 \u043b\u0430\u0433\u0435\u0440\u044f: \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u00ab\u0437\u0430\u00bb \u0438 \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u00ab\u043f\u0440\u043e\u0442\u0438\u0432\u00bb. \u041f\u0440\u0438\u0447\u0435\u043c \u043f\u0440\u0435\u0434\u043c\u0435\u0442 \u0441\u043f\u043e\u0440\u043e\u0432 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u0430\u0431\u0441\u043e\u043b\u044e\u0442\u043d\u043e \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u043b\u044c\u043d\u044b\u043c. \u041a\u0430\u043a\u0430\u044f \u041e\u0421 \u043b\u0443\u0447\u0448\u0435: Win \u0438\u043b\u0438 Linux? \u041d\u0430 \u0441\u043c\u0430\u0440\u0442\u0444\u043e\u043d\u0435 Android \u0438\u043b\u0438 iOS? \u0425\u0440\u0430\u043d\u0438\u0442\u044c \u0432\u0441\u0435 \u0432 \u043e\u0431\u043b\u0430\u043a\u0430\u0445 \u0438\u043b\u0438 \u0437\u0430\u043b\u0438\u0432\u0430\u0442\u044c \u043d\u0430 \u0445\u043e\u043b\u043e\u0434\u043d\u044b\u0435 RAID-\u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u0438 \u043a\u043b\u0430\u0441\u0442\u044c \u0432\u0438\u043d\u0442\u044b \u0432 \u0441\u0435\u0439\u0444? \u0418\u043c\u0435\u044e\u0442 \u043b\u0438 PHP-\u0448\u043d\u0438\u043a\u0438 \u043f\u0440\u0430\u0432\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34596","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47\u00bfViven las bases de datos en Kubernetes? | ProHoster","description":"De alguna manera, hist\u00f3ricamente, ha sido as\u00ed en la industria de TI.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","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\u0416\u0438\u0432\u0443\u0442 \u043b\u0438 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 Kubernetes? | ProHoster","og:description":"\u041a\u0430\u043a-\u0442\u043e \u0442\u0430\u043a \u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438 \u0441\u043b\u043e\u0436\u0438\u043b\u043e\u0441\u044c, \u0447\u0442\u043e IT-\u0438\u043d\u0434\u0443\u0441\u0442\u0440\u0438\u044f \u043f\u043e.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","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-31T18:59:16+00:00","article:modified_time":"2019-10-31T18:59:16+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34596","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-02-09 21:46:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:18:36","updated":"2026-02-09 21:46:19","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\/34596","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=34596"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/34596\/revisions"}],"predecessor-version":[{"id":159764,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/34596\/revisions\/159764"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=34596"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=34596"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=34596"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}