{"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\/it\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","title":{"rendered":"Le banche dati vivono in Kubernetes?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Le
\n
\nStoricamente, l'industria IT si \u00e8 divisa in due campi: quelli 'favoriscono' e quelli 'contrario'. Gli argomenti di discussione possono essere i pi\u00f9 disparati. Quale sistema operativo \u00e8 migliore: Win o Linux? Su uno smartphone, Android o iOS? Conservare tutto nel cloud o affidarsi a fredde memorie RAID? I programmatori PHP possono veramente definirsi tali? Queste discussioni a volte assumono un carattere puramente esistenziale e non si basano su nulla di pi\u00f9 che su un interesse sportivo.<\/p>\n

Con l'arrivo dei container e di tutta questa nostra amata tecnologia con Docker e Kubernetes, sono iniziati anche i dibattiti 'favorire' e 'contrario' sull'uso delle nuove opportunit\u00e0 in vari ambiti del backend. (Pre-annunciamo che, sebbene molto spesso in questa discussione si indichi Kubernetes come orchestratore, la scelta di questo strumento non \u00e8 fondamentale. Puoi sostituirlo con qualsiasi altro che ritieni pi\u00f9 conveniente e familiare.)<\/p>\n

E, a prima vista, sembrerebbe un semplice dibattito tra due fazioni della stessa medaglia. \u00c8 egualmente privo di senso e implacabile, come la eterna opposizione tra Win e Linux, dove persone ragionevoli esistono sicuramente a met\u00e0 strada. Eppure, nel caso della containerizzazione, le cose non sono cos\u00ec semplici. Solitamente in queste discussioni non ci sono vere e proprie parti giuste, ma nel caso di 'utilizzare' o 'non utilizzare' i container per la memorizzazione dei database, tutto si capovolge. Perch\u00e9, in un certo senso, sia i sostenitori che gli oppositori di questo approccio hanno il loro ragione.
\n<\/a><\/noindex><\/p>\n

Lato Luminoso<\/h4>\n

\nRiassumere l'argomentazione del Lato Luminoso pu\u00f2 essere fatto con una frase: \u201cEhi, 2k19 \u00e8 qui fuori!\u201d Suona certamente come populismo, ma se si esamina la situazione in dettaglio, ci sono dei vantaggi. Ed \u00e8 proprio ci\u00f2 che ora analizzeremo.<\/p>\n

Immagina di avere un grande progetto web. Potrebbe essere stato inizialmente costruito sulla base di un approccio a microservizi, oppure averci raggiunto in modo evolutivo \u2014 in realt\u00e0 questo non \u00e8 cos\u00ec importante. Hai suddiviso il tuo progetto in singoli microservizi, hai configurato l'orchestrazione, il bilanciamento del carico e la scalabilit\u00e0. E ora, con buona coscienza, ti godi un mojito in un'amaca durante gli effetti dell'Hubra, invece di dover ripristinare i server caduti. Ma in ogni azione bisogna essere coerenti. Spesso solo l'applicazione \u2014 il codice \u2014 viene containerizzata. E cosa abbiamo oltre al codice?<\/p>\n

Esatto, i dati. Il cuore di ogni progetto sono i suoi dati: possono essere un tipico DBMS \u2014 MySQL, Postgre, MongoDB, o archivi utilizzati per la ricerca (ElasticSearch), archivi chiave-valore per la cache \u2014 ad esempio, Redis, ecc. Oggi non parleremo delle implementazioni problematiche del backend, quando il database va gi\u00f9 a causa di query male scritte, ma invece discuteremo dell'assicurazione della resilienza del database sotto il carico client. Infatti, quando containerizziamo la nostra applicazione e le permettiamo di scalare liberamente per gestire qualsiasi numero di richieste in arrivo, questo inevitabilmente aumenta anche il carico sul database.<\/p>\n

In effetti, il canale per accedere al database e il server su cui \u00e8 in esecuzione diventano il collo di bottiglia nel nostro magnifico backend containerizzato. Il principale motivo della virtualizzazione dei container \u00e8 la mobilit\u00e0 e la flessibilit\u00e0 della struttura, che consente di organizzare la distribuzione del carico di picco su tutta l'infrastruttura disponibile nel modo pi\u00f9 efficiente. Cio\u00e8, se non containerizziamo e non distribuiamo nel cluster tutti gli elementi del sistema, stiamo commettendo un errore molto serio.<\/p>\n

\u00c8 molto pi\u00f9 logico clusterizzare non solo l'applicazione, ma anche i servizi responsabili della memorizzazione dei dati. Durante la clusterizzazione e il dispiegamento di server web indipendenti che si distribuiscono il carico tra loro in Kubernetes, stiamo gi\u00e0 affrontando il problema della sincronizzazione dei dati \u2014 come i commenti ai post, se vogliamo fare un esempio con un media o una piattaforma di blog. In ogni caso, si crea una rappresentazione interna al cluster, anche se virtuale, del database come ExternalService. La questione \u00e8 che il database non \u00e8 ancora clusterizzato \u2014 i server web distribuiti nel cluster raccolgono informazioni sulle modifiche dal nostro database operativo statico, che gira separatamente.<\/p>\n

Sentite l'inganno? Utilizziamo Kubernetes o Swarm per distribuire il carico ed evitare il crollo del principale. il server web.<\/a>, ma non facciamo questo per il database. Ma se il database si guasta, allora non ha senso per tutta la nostra infrastruttura clusterizzata \u2014 cosa ci facciamo con pagine web vuote che restituiscono errori di accesso al database?<\/p>\n

Ecco perch\u00e9 \u00e8 necessario clusterizzare non solo i server web, come di solito si fa, ma anche l'infrastruttura del database. Solo in questo modo possiamo garantire una struttura che funzioni a pieno regime ma resti indipendente l'una dall'altra. Anche se met\u00e0 del nostro backend crolla sotto il carico, la parte restante sopravvive e il sistema di sincronizzazione del database tra cluster e la possibilit\u00e0 di scalare indefinitamente e di distribuire nuovi cluster ci aiuteranno a raggiungere rapidamente la potenza necessaria \u2014 a patto che ci siano rack nel data center.<\/p>\n

Inoltre, il modello di database distribuito in cluster consente di spostare il database dove \u00e8 realmente necessario; se parliamo di un servizio globale, ha poco senso avere un cluster web da qualche parte vicino a San Francisco e far passare i pacchetti per accedere al database a Podmoskovye e ritorno.<\/p>\n

La containerizzazione del database consente inoltre di costruire tutti gli elementi del sistema su un unico livello di astrazione. Questo, a sua volta, rende possibile la gestione del sistema direttamente dal codice, dai programmatori, senza il bisogno di coinvolgere attivamente gli amministratori. Se i programmatori decidono che \u00e8 necessario un database separato per un nuovo sottoprogetto \u2014 fatto! Hanno scritto un file yaml, lo hanno caricato nel cluster ed \u00e8 pronto.<\/p>\n

Inoltre, la gestione interna diventa di gran lunga pi\u00f9 semplice. Diteci, quante volte vi siete tapparvi gli occhi quando un nuovo membro del team ha messo le mani nel database di produzione? Che \u00e8 l'unico che avete e sta funzionando in questo momento? Certo, siamo tutti adulti e abbiamo da qualche parte un backup fresco, e pi\u00f9 in l\u00e0 \u2014 dietro al barattolo di cetrioli di nonna e sugli sci vecchi \u2014 un altro backup, forse anche su uno storage a freddo, perch\u00e9 un giorno il vostro ufficio ha preso fuoco. Tuttavia, ogni nuovo membro del team con accesso all'infrastruttura di produzione e, naturalmente, al database di produzione \u00e8 un vero e proprio attacco di ansia per tutti gli altri. Chi conosce quel nuovo arrivato? Potrebbe essere maldestro? Spaventoso, ammettetelo.<\/p>\n

La containerizzazione e, fondamentalmente, la topologia fisica distribuita del database del vostro progetto aiutano a evitare momenti di ansia simili. Non vi fidate del nuovo arrivato? Va bene! Creiamo un cluster dedicato per il suo lavoro e lo scolleghiamo dagli altri cluster del database \u2014 la sincronizzazione sar\u00e0 solo tramite push manuale e la rotazione sincronizzata di due chiavi (una per il team leader e l'altra per l'amministratore). E tutti saranno felici.<\/p>\n

E ora \u00e8 arrivato il momento di cambiare prospettiva e diventare contrari alla clusterizzazione del database.<\/p>\n

Lato Oscuro<\/h4>\n

\nRiflettendo su perch\u00e9 non si dovrebbe containerizzare il database e continuare a farlo girare su un unico server centrale, server<\/a>, non scenderemo sul piano della retorica degli ortodossi e delle affermazioni come \"i nostri antenati usavano i server, e noi faremo lo stesso!\" Invece, proviamo a immaginare una situazione in cui la containerizzazione possa realmente portare benefici tangibili.<\/p>\n

D'accordo, i progetti che realmente hanno bisogno di un database in un container possono essere conteggiati sulle dita di una mano non particolarmente abile. Nella maggior parte dei casi, persino l'uso di k8s o Docker Swarm \u00e8 eccessivo \u2014 spesso questi strumenti vengono utilizzati a causa dell'hype generale e delle indicazioni \"superiori\" riguardo a mettere tutto nel cloud e nei container. Beh, perch\u00e9 ora \u00e8 di moda e cos\u00ec fanno tutti.<\/p>\n

In almeno met\u00e0 dei casi, l'uso di Kubernetes o semplicemente di Docker su un progetto \u00e8 superfluo. Il problema \u00e8 che non tutti i team o le aziende di outsourcing assunte per gestire l'infrastruttura del cliente ne sono consapevoli. Peggio ancora, quando i container vengono imposti, poich\u00e9 ci\u00f2 rappresenta un certo costo per il cliente.<\/p>\n

Si ritiene generalmente che Docker e la mafia di Kubernetes stiano semplicemente accaparrandosi i clienti che esternalizzano queste questioni infrastrutturali. Infatti, per lavorare con i cluster, sono necessari ingegneri capaci e che comprendano l'architettura della soluzione implementata. Abbiamo gi\u00e0 descritto il nostro caso con l'uscita di Republic \u2014 l\u00ec abbiamo addestrato il team del cliente a lavorare con Kubernetes, e tutti sono rimasti soddisfatti. E questo \u00e8 stato molto positivo. Tuttavia, spesso coloro che implementano k8s prendono in ostaggio l'infrastruttura del cliente \u2014 ora solo loro capiscono come funziona tutto, non ci sono specialisti nel cliente.<\/p>\n

E ora immaginate che in questo modo non stiamo solo delegando la parte server web a un fornitore esterno, ma anche la gestione del database. Abbiamo detto che il database \u00e8 il cuore, e perdere il cuore \u00e8 fatale per qualsiasi organismo vivente. In breve, le prospettive non sono delle migliori. Quindi, invece di affidarci a un Kubernetes iper-moderno, molti progetti dovrebbero semplicemente investire in un piano adeguato su AWS, che risolverebbe tutti i problemi di carico sul loro sito\/progetto. Ma AWS non \u00e8 pi\u00f9 in voga, e purtroppo, i vezzi costano pi\u00f9 dei soldi, anche nell'IT.<\/p>\n

Okay. Forse la clusterizzazione \u00e8 realmente necessaria per un progetto, ma se con le applicazioni stateless tutto \u00e8 chiaro, come si pu\u00f2 garantire una connettivit\u00e0 adeguata per un database clusterizzato?<\/p>\n

Se parliamo di una soluzione ingegneristica senza soluzione di continuit\u00e0, come quella proposta dal passaggio a k8s, la nostra principale preoccupazione \u00e8 la replica dei dati in un database clusterizzato. Alcuni DBMS sono inizialmente piuttosto favorevoli alla distribuzione dei dati tra le varie istanze. Molti altri, invece, non sono cos\u00ec accoglienti. E spesso, il principale argomento nella scelta di un DBMS per il nostro progetto non \u00e8 affatto la capacit\u00e0 di replicarsi con costi minimi in termini di risorse e ingegneria. Soprattutto se il progetto non \u00e8 stato inizialmente concepito come microservizio, ma \u00e8 semplicemente evoluto in questa direzione. <\/p>\n

Credo che non ci sia bisogno di raccontare di quanto siano lenti i dischi di rete. Cio\u00e8, non abbiamo realmente la possibilit\u00e0, se necessario, di ricollegare un'istanza DBMS altrove, dove ci sono, ad esempio, pi\u00f9 potenza di calcolo o RAM disponibile. Ci fermeremo molto rapidamente alle prestazioni del sistema di archiviazione virtualizzato. Pertanto, il DBMS deve essere legato al proprio set personale di macchine, che si trovano nelle immediate vicinanze. Oppure bisogna trovare un modo per garantire una sincronizzazione dei dati sufficientemente veloce verso le risorse di backup previste. <\/p>\n

Continuando il tema dei file system virtuali: i Docke Volumes, purtroppo, non sono privi di problemi. In generale, per qualcosa come l'archiviazione dati a lungo termine e affidabile, si vorrebbero utilizzare schemi tecnici il pi\u00f9 semplice possibile. E aggiungere un nuovo strato di astrazione dal file system del contenitore a quello dell'host principale \u00e8 gi\u00e0 di per s\u00e9 un rischio. Ma quando compaiono difficolt\u00e0 nella trasmissione dei dati tra questi strati nel sistema di supporto alla containerizzazione, allora \u00e8 davvero un disastro. Attualmente, la maggior parte dei problemi noti sembra essere stata risolta. Ma come ben sapete, pi\u00f9 il meccanismo \u00e8 complicato, pi\u00f9 \u00e8 facile che si rompa.<\/p>\n

Alla luce di tutte queste 'avventure', \u00e8 molto pi\u00f9 vantaggioso e semplice mantenere il database in un unico posto, e anche se avete bisogno della containerizzazione dell'applicazione, lasciate che essa operi autonomamente e comunichi simultaneamente con un database che verr\u00e0 letto e scritto solo una volta e in un unico luogo. Questo approccio riduce la probabilit\u00e0 di errori e de-sincronizzazioni al minimo.<\/p>\n

A cosa stiamo tentando di arrivare? Al fatto che la containerizzazione del database \u00e8 appropriata solo dove c'\u00e8 una reale necessit\u00e0. Non si pu\u00f2 mettere un database di un'app full-stack e farlo funzionare come se aveste una ventina di microservizi \u2014 cos\u00ec non funziona. E questo deve essere ben chiaro.<\/p>\n

Invece dell'output<\/h4>\n

\nSe state aspettando una chiara conclusione su 'virtualizzare o meno il database', vi deluder\u00f2: non ci sar\u00e0. Perch\u00e9 nella creazione di qualsiasi soluzione infrastrutturale bisogna seguire non le mode e i progressi, ma prima di tutto il buon senso.<\/p>\n

Ci sono progetti per i quali i principi e gli strumenti derivanti da Kubernetes si adattano perfettamente, e in tali progetti si ottiene almeno un certo livello di pace nell'area backend. E ci sono progetti che non hanno bisogno di containerizzazione, ma di un'infrastruttura server vera e propria, perch\u00e9 non possono essere riprogettati per un modello cluster di microservizi, altrimenti collasseranno.
\n
Fonte: 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\udd47Le basi di dati vivono in Kubernetes? | ProHoster","description":"Storicamente, \u00e8 cos\u00ec che si \u00e8 sviluppata l'industria IT.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/34596","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=34596"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/34596\/revisions"}],"predecessor-version":[{"id":159764,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/34596\/revisions\/159764"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=34596"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=34596"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=34596"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}