{"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 basi di 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 condizionati: quelli \"a favore\" e quelli \"contro\". E la questione pu\u00f2 riguardare qualsiasi argomento. Qual \u00e8 il miglior sistema operativo: Win o Linux? Smartphone Android o iOS? Conservare tutto nel cloud o caricare su freddi sistemi RAID e mettere i dischi in cassaforte? Gli sviluppatori PHP possono definirsi programmatori? Questi dibattiti sono, a volte, esclusivamente di natura esistenziale e non hanno alcuna base valida, se non un interesse puramente sportivo.<\/p>\n

\u00c8 successo che con l'arrivo dei container e di tutta questa nostra amata tecnologia con Docker e il noto k8s, sono iniziati anche i dibattiti \"a favore\" e \"contro\" l'uso delle nuove possibilit\u00e0 in vari ambiti del back-end. (Per chiarezza, va detto che anche se nella discussione il termine orchestratore solitamente designa Kubernetes, la scelta di questo strumento in particolare non ha importanza fondamentale. Al suo posto si pu\u00f2 utilizzare qualsiasi altro strumento che riteniate pi\u00f9 comodo e familiare.)<\/p>\n

E, a prima vista, potrebbe sembrare un semplice dibattito tra due lati della stessa medaglia. Una contrapposizione altrettanto insensata e spietata come il conflitto eterno tra Win e Linux, dove persone ragionevoli possono trovarsi a met\u00e0 strada. Tuttavia, nel caso della containerizzazione, le cose non sono cos\u00ec semplici. Di solito, in tali dispute non esiste un lato giusto, ma nel caso di \"utilizzare\" o \"non utilizzare\" i container per l'archiviazione dei database, la situazione si capovolge. Perch\u00e9, in un certo senso, sia i sostenitori che gli oppositori di tale approccio hanno ragione.
\n<\/a><\/noindex><\/p>\n

Lato Chiaro<\/h4>\n

\nRiassumere l'argomentazione del Lato Chiaro in una frase \u00e8 semplice: \u201cCiao, \u00e8 il 2k19 fuori!\u201d Suona un po' come populismo, indubbiamente, ma se si approfondisce la situazione, ci sono dei vantaggi. Ed \u00e8 di questi che parleremo ora.<\/p>\n

Supponiamo che tu abbia un grande progetto web. Potrebbe essere stato inizialmente costruito sulla base di un approccio a microservizi, oppure potrebbe essere arrivato a questo punto in modo evolutivo \u2014 in realt\u00e0 non \u00e8 molto importante. Hai suddiviso il nostro progetto in singoli microservizi, hai configurato l'orchestrazione, il bilanciamento del carico e la scalabilit\u00e0. E ora, con la coscienza tranquilla, ti godi un mojito nell'amaca durante gli effetti di Habr invece di sollevare i server caduti. Ma in tutte le azioni bisogna essere coerenti. Molto spesso si containerizza solo direttamente l'applicazione stessa \u2014 il codice. E cos'altro abbiamo oltre al codice?<\/p>\n

Esatto, i dati. Il cuore di qualsiasi progetto sono i suoi dati: possono essere un tipico DBMS come MySQL, Postgre, MongoDB, cos\u00ec come archivi utilizzati per la ricerca (ElasticSearch), archivi key-value per la memorizzazione nella cache \u2014 ad esempio, Redis, ecc. Oggi non parleremo delle implementazioni problematiche del backend, quando il DB cade a causa di query mal scritte, ma invece parleremo di garantire la resilienza di questo stesso DB sotto il carico dei client. Infatti, quando containerizziamo la nostra applicazione e le permettiamo di scalare liberamente per elaborare qualsiasi numero di richieste in ingresso, questo aumenta inevitabilmente il carico sul database.<\/p>\n

In effetti, il canale di accesso al database e il server su cui \u00e8 in esecuzione diventano un collo di bottiglia nel nostro fantastico backend containerizzato. In questo modo, il principale obiettivo della virtualizzazione a contenitori \u00e8 la mobilit\u00e0 e la flessibilit\u00e0 della struttura, che permette di organizzare la distribuzione del carico picco al meglio possibile su tutta l'infrastruttura disponibile. Cio\u00e8, se non containerizziamo e non distribuiamo nel cluster tutti gli elementi del sistema \u2014 commettiamo un errore molto grave.<\/p>\n

\u00c8 molto pi\u00f9 logico clusterizzare non solo l'applicazione stessa, ma anche i servizi responsabili della memorizzazione dei dati. Quando si clusterizzano e si distribuiscono server web che operano in modo indipendente e si distribuiscono il carico tra di loro in k8s, risolviamo gi\u00e0 il problema della sincronizzazione dei dati \u2014 come i commenti ai post, per esempio, se prendiamo in considerazione un media o una piattaforma di blog. In ogni caso, abbiamo una rappresentazione interna del cluster, anche se virtuale, del database come ExternalService. Il problema \u00e8 che il database stesso non \u00e8 ancora clusterizzato \u2014 i server web distribuiti nel cluster prelevano informazioni sulle modifiche dalla nostra base dati statica in produzione, che gira separatamente.<\/p>\n

Senti un tranello? Utilizziamo k8s o Swarm per distribuire il carico ed evitare il fallimento del principale web<\/a>, ma non facciamo lo stesso per il database. Se il database crolla, non ha senso per tutta la nostra infrastruttura clusterizzata \u2014 a cosa ci servono pagine web vuote che restituiscono un errore di accesso al database?<\/p>\n

\u00c8 proprio per questo che bisogna 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 in modo autonomo ma che sia pur sempre interconnessa. Anche se met\u00e0 del nostro backend dovesse 'crollare' sotto carico, l'altra met\u00e0 sopravviverebbe, e il sistema di sincronizzazione del database all'interno del cluster e la possibilit\u00e0 di scalabilit\u00e0 infinita e di distribuzione di nuovi cluster aiuter\u00e0 a raggiungere rapidamente la potenza necessaria \u2014 purch\u00e9 ci siano rack nel data center.<\/p>\n

Inoltre, il modello di database distribuito nei cluster consente di portare il database stesso dove \u00e8 necessario; se parliamo di un servizio globale, \u00e8 piuttosto illogico avere un cluster web da qualche parte vicino a San Francisco e inviare pacchetti per accedere al database a Podmoskov'e e ritorno.<\/p>\n

Inoltre, la containerizzazione del database consente di costruire tutti gli elementi del sistema su un unico livello di astrazione. Ci\u00f2, a sua volta, rende possibile gestire il sistema direttamente dal codice, dagli sviluppatori, senza il coinvolgimento attivo degli amministratori. Gli sviluppatori hanno pensato che fosse necessaria una nuova base di dati per un nuovo sottoprogetto \u2014 facile! Hanno scritto un file yaml, lo hanno caricato nel cluster ed \u00e8 pronto.<\/p>\n

E, naturalmente, l'utilizzo interno diventa notevolmente pi\u00f9 semplice. Dite, quante volte avete chiuso gli occhi nei momenti in cui un nuovo membro del team si \u00e8 intromesso nel database di produzione? Che in effetti \u00e8 l'unico che avete e che sta girando proprio adesso? Certo, siamo tutti adulti qui, e da qualche parte avremo un backup fresco, e ancora pi\u00f9 in l\u00e0, dietro uno scaffale di cetrioli della nonna e vecchi sci, un altro backup, forse anche su un'archiviazione a freddo, perch\u00e9 un giorno il vostro ufficio ha gi\u00e0 preso fuoco. Ma comunque, ogni introduzione di un nuovo membro del team che ha accesso all'infrastruttura di produzione e, naturalmente, al database di produzione \u00e8 un calice di valium per tutti intorno. Chi pu\u00f2 sapere, il novellino, forse \u00e8 maldestro? Fa paura, ammettetelo.<\/p>\n

La containerizzazione e, in sostanza, la topologia fisica distribuita del database del vostro progetto aiutano a evitare momenti del genere. Non vi fidate del nuovo arrivato? Va bene! Gli creeremo un cluster personale per lavorare e lo disconnetteremo dagli altri cluster del database: la sincronizzazione avverr\u00e0 solo tramite push manuale e la rotazione sincrona di due chiavi (una per il team leader, l'altra per l'amministratore). E tutti saranno felici.<\/p>\n

E ora \u00e8 tempo di passare a quelli che si oppongono alla clusterizzazione del database.<\/p>\n

Lato Oscuro<\/h4>\n

\nRagionando su perch\u00e9 non dovremmo containerizzare il database e continuare a farlo girare su un'unica centrale server<\/a>, non scenderemo a retoriche ortodosse e affermazioni del tipo \u00abi nonni facevano girare i database sull'hardware, e noi lo faremo!\u00bb Invece, proviamo a immaginare una situazione in cui la containerizzazione porterebbe davvero benefici tangibili.<\/p>\n

Ammettetelo, i progetti che hanno davvero bisogno di un database in container si possono contare sulle dita di una mano di un fresatore non proprio sopraffino. Nella maggior parte dei casi, persino l'uso di k8s o Docker Swarm \u00e8 eccessivo: molto spesso si ricorre a questi strumenti a causa dell'hype generale delle tecnologie e delle imposizioni \u00abdivine\u00bb da parte dei capi di spingere tutto verso il cloud e i container. Beh, perch\u00e9 ora \u00e8 di moda e tutti cos\u00ec fanno.<\/p>\n

In almeno la met\u00e0 dei casi, l'uso di Kubernetes o semplicemente di Docker nel progetto \u00e8 eccessivo. Il problema \u00e8 che non tutti i team o le aziende esterne assunte per gestire l'infrastruttura del cliente se ne rendono conto. Ancora peggio \u00e8 quando i container sono imposti, perch\u00e9 questo comporta un certo costo monetario per il cliente.<\/p>\n

In generale, c'\u00e8 un'opinione secondo cui la mafia di Docker\/Kubernetes sta semplicemente controllando i clienti che delegano queste questioni infrastrutturali a terzi. 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 la pubblicazione di Republic \u2014 l\u00ec abbiamo addestrato il team del cliente a lavorare con Kubernetes, e tutti sono stati soddisfatti. Ed \u00e8 stata una cosa ragionevole. Spesso, per\u00f2, gli 'implementatori' di k8s prendono in ostaggio l'infrastruttura del cliente \u2014 perch\u00e9 ora solo loro sanno come funziona tutto, non ci sono specialisti dalla parte del cliente.<\/p>\n

E ora immaginate che in questo modo non stiamo delegando solo la parte del server web a terzi, ma anche la gestione del database. Abbiamo detto che il database \u00e8 il cuore, e la perdita del cuore \u00e8 fatale per qualsiasi organismo vivente. Insomma, le prospettive non sono delle migliori. Quindi, invece di affidarci a Kubernetes da un lato di moda, molti progetti dovrebbero semplicemente non essere avari su una tariffa normale di AWS, che risolverebbe tutti i problemi di carico sul loro sito\/progetto. Ma AWS non \u00e8 pi\u00f9 di moda, e i bling costano pi\u00f9 dei soldi \u2014 purtroppo, anche nel settore IT.<\/p>\n

Ok. Forse la clusterizzazione \u00e8 veramente necessaria per il progetto, ma se con le applicazioni stateless \u00e8 tutto chiaro, come possiamo allora organizzare una connessione di rete adeguata per un database clusterizzato?<\/p>\n

Se parliamo di una soluzione ingegneristica senza interruzioni, che \u00e8 ci\u00f2 che implica la transizione a k8s, il nostro principale mal di testa \u00e8 la replica dei dati in un database clusterizzato. Alcuni DBMS tendono ad essere piuttosto indulgenti nella distribuzione dei dati tra le loro istanze. Molti altri, invece, non sono altrettanto accoglienti. E abbastanza spesso, l'argomento principale nella scelta del 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 era inizialmente previsto come un servizio micro, ma \u00e8 semplicemente evoluto in quella direzione. <\/p>\n

Pensiamo che non sia necessario spiegare la velocit\u00e0 dei dischi di rete: sono lenti. Cio\u00e8, non abbiamo davvero la possibilit\u00e0, in caso di necessit\u00e0, di riavviare un'istanza del DBMS da qualche parte, dove ci sono pi\u00f9, ad esempio, potenza di calcolo o memoria RAM libera. Ci impegneremo molto rapidamente nelle prestazioni del sistema di storage virtualizzato. Di conseguenza, il DBMS deve essere collegato al proprio set personale di macchine che si trovano in prossimit\u00e0. Oppure dobbiamo in qualche modo predisporre una sincronizzazione dei dati sufficientemente rapida per risorse previste. <\/p>\n

Continuando il tema dei file system virtuali: i Docker Volumes, sfortunatamente, non sono privi di problemi. In generale, in un campo come la conservazione a lungo termine dei dati, vorremmo utilizzare schemi tecnici il pi\u00f9 semplici possibile. L'aggiunta di un nuovo strato di astrazione da un file system del contenitore a quello dell'host padre \u00e8 gi\u00e0 di per s\u00e9 un rischio. Ma quando ci sono anche delle difficolt\u00e0 nel lavoro del sistema di containerizzazione nella trasmissione dei dati tra questi strati, allora \u00e8 davvero un disastro. Al momento, la maggior parte dei noti problemi affrontati dall'umanit\u00e0 sembra essere stata estirpata. Ma come sapete, pi\u00f9 complesso \u00e8 il meccanismo, pi\u00f9 \u00e8 facile che si rompa.<\/p>\n

Alla luce di tutte queste \u00abavventure\u00bb, \u00e8 molto pi\u00f9 vantaggioso e semplice tenere un DB in un unico posto, e anche se hai bisogno di containerizzare l'applicazione \u2014 lascia che funzioni da sola e attraverso un gateway distribuito ottenga una connessione simultanea al DB, che sar\u00e0 letta e scritta solo una volta e in un unico posto. Questo approccio riduce la probabilit\u00e0 di errori e desincronizzazioni ai minimi termini.<\/p>\n

Dove vogliamo arrivare? Al fatto che la containerizzazione del DB \u00e8 opportuna dove c'\u00e8 una reale necessit\u00e0. Non si pu\u00f2 infilare un database di un'app completa e farlo girare come se avessi due dozzine di microservizi \u2014 non funziona in questo modo. E questo va chiaramente compreso.<\/p>\n

Invece di un'uscita<\/h4>\n

\nSe stai aspettando una risposta chiara sul \u00abvirtualizzare o meno il DB\u00bb, purtroppo siamo costretti a deluderti: qui non ci sar\u00e0. Perch\u00e9 nella creazione di qualsiasi soluzione infrastrutturale bisogna guidarsi non dalla moda e dal progresso, ma prima di tutto dal buon senso.<\/p>\n

Ci sono progetti sui quali i principi e gli strumenti che vengono con Kubernetes si adattano perfettamente, e in tali progetti si raggiunge la pace almeno nell'area del backend. Ci sono per\u00f2 progetti che hanno bisogno non di containerizzazione, ma di una normale infrastruttura server, perch\u00e9 non possono fondamentalmente essere ridimensionati a un modello di cluster microservizi, altrimenti semplicemente crollano.
\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\udd47Vivono i database in Kubernetes? | ProHoster","description":"\u00c8 cos\u00ec che si \u00e8 storicamente strutturata 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}]}}