{"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\/da\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","title":{"rendered":"Lever databaser i Kubernetes?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Lever
\n
\nHistorisk set har IT-industrien delt sig i to lejre: dem, der er 'for', og dem, der er 'imod'. Emnet for debatten kan v\u00e6re helt vilk\u00e5rligt. Hvilket operativsystem er bedst: Windows eller Linux? Skal man have en smartphone med Android eller iOS? Skal man gemme alt i skyen eller lagre p\u00e5 kolde RAID-opbevaringsenheder og l\u00e6gge harddiskene i et pengeskab? Har PHP-udviklere ret til at kalde sig programm\u00f8rer? Disse diskussioner er til tider udelukkende eksistentielle og mangler enhver anden, bortset fra en sportlig interesse, base.<\/p>\n

Det er sket, at med fremkomsten af containere og al den elskede teknologi omkring Docker og Kubernetes, er debatter om 'for' og 'imod' brugen af nye muligheder i forskellige omr\u00e5der af backend begyndt. (P\u00e5 forh\u00e5nd skal det siges, at selvom Kubernetes oftest n\u00e6vnes som orkestrator, har valget af netop dette v\u00e6rkt\u00f8j ikke principiel betydning. Man kan i stedet inds\u00e6tte ethvert andet, man finder mest praktisk og velkendt.)<\/p>\n

Og det ville umiddelbart v\u00e6re en simpel debat mellem to sider af samme m\u00f8nt. Liges\u00e5 meningsl\u00f8s og n\u00e5desl\u00f8s som det evige opg\u00f8r mellem Windows og Linux, hvor der findes fornuftige mennesker et sted imellem. Men i tilf\u00e6lde af containerisering er det ikke s\u00e5 enkelt. I s\u00e5danne diskussioner er der normalt ikke en 'rigtig' side, men n\u00e5r det kommer til at 'anvende' eller 'ikke anvende' containere til lagring af databaser, bliver det hele vendt p\u00e5 hovedet. For i en vis forstand har b\u00e5de fortalere og modstandere af denne tilgang ret.
\n<\/a><\/noindex><\/p>\n

Den Lyse Side<\/h4>\n

\nMan kan kort beskrive argumentationen for Den Lyse Side med \u00e9n s\u00e6tning: \u201cHej, 2019 st\u00e5r lige udenfor!\u201d Det lyder som populisme, uden tvivl, men hvis man dykker ned i situationen, er der fordele ved det. Dem skal vi nu se n\u00e6rmere p\u00e5.<\/p>\n

Antag at du har et stort webprojekt. Det kan v\u00e6re bygget p\u00e5 en mikrotjeneste-tilgang fra starten, eller det kan v\u00e6re kommet til det evolution\u00e6rt p\u00e5 et tidspunkt \u2014 det er faktisk ikke s\u00e5 vigtigt. Du har opdelt dit projekt i separate mikrotjenester, konfigureret orkestrering, belastningsbalancering og skalerbarhed. Og nu nyder du med god samvittighed en mojito i h\u00e6ngek\u00f8jen under bes\u00f8get af habra-effekter i stedet for at skulle genstarte nedfaldne servere. Men i alle handlinger er det vigtigt at v\u00e6re konsekvent. Meget ofte containeriseres kun selve applikationen \u2014 koden. Og hvad har vi ellers udover koden?<\/p>\n

Rigtigt, data. Hjertet i ethvert projekt er dets data: det kan v\u00e6re en typisk DBMS \u2014 MySQL, Postgre, MongoDB, s\u00e5vel som lagringsl\u00f8sninger, der bruges til s\u00f8gning (ElasticSearch), key-value lagringsl\u00f8sninger til caching \u2014 for eksempel Redis, og s\u00e5 videre. Nu vil vi ikke tale om de sk\u00e6ve implementeringsmuligheder for backend, hvor databasen fejler p\u00e5 grund af d\u00e5rligt skrevne foresp\u00f8rgsler, men i stedet tale om, hvordan man sikrer, at denne database er fejltolerant under klientbelastning. For n\u00e5r vi containeriserer vores applikation og tillader den at skalere frit for at h\u00e5ndtere et vilk\u00e5rligt antal indg\u00e5ende foresp\u00f8rgsler, \u00f8ger det ogs\u00e5 belastningen p\u00e5 databasen.<\/p>\n

Faktisk bliver adgangen til databasen og serveren, p\u00e5 hvilken den k\u00f8rer, en flaskehals i vores sk\u00f8nne containeriserede backend. Den prim\u00e6re motivation for container-virtualisering er mobilitet og fleksibilitet i strukturen, der giver mulighed for at organisere fordelingen af peakbelastningen p\u00e5 tv\u00e6rs af al den tilg\u00e6ngelige infrastruktur s\u00e5 effektivt som muligt. Det vil sige, hvis vi ikke containeriserer og implementerer alle systemelementerne i klusteret \u2014 s\u00e5 laver vi en meget alvorlig fejl.<\/p>\n

Det er langt mere logisk at klarg\u00f8re ikke kun applikationen, men ogs\u00e5 de tjenester, der st\u00e5r for dataopbevaring, i et cluster. N\u00e5r vi klarg\u00f8r og implementerer uafh\u00e6ngigt fungerende og belastningsfordelende webservere i k8s, l\u00f8ser vi allerede synkroniseringsproblemet med data \u2014 for eksempel kommentarer til indl\u00e6g, hvis vi tager et medie eller blogplatform som eksempel. Vi opretter under alle omst\u00e6ndigheder en intern-klynge, selvom det kun er en virtuel, pr\u00e6sentation af databasen som ExternalService. Sp\u00f8rgsm\u00e5let er, at databasen endnu ikke er klargjort \u2014 de udrulende webservere i klyngen henter oplysninger om \u00e6ndringer fra vores statiske produktionsdatabase, der k\u00f8rer separat.<\/p>\n

Fornemmer du en f\u00e6lde? Vi bruger k8s eller Swarm til at fordele belastningen og undg\u00e5 nedbrud af hovedsystemet, webserver<\/a>, men vi g\u00f8r ikke det samme for databasen. Men hvis databasen g\u00e5r ned, har hele vores klusterinfrastruktur ikke mening \u2014 hvad nytter det os med tomme websteder, der returnerer en fejl ved adgang til databasen?<\/p>\n

Derfor skal vi klarg\u00f8re ikke kun webservere, som det normalt g\u00f8res, men ogs\u00e5 databaseinfrastrukturen. Kun p\u00e5 den m\u00e5de kan vi sikre en fuldt fungerende struktur, der er uafh\u00e6ngig af hinanden men stadig arbejder sammen. Selv hvis halvdelen af vores backend 'faller' under belastning, vil den resterende overleve, og systemet til synkronisering af databaserne i klyngen sammen med muligheden for uendelig skalering og oprettelse af nye klynger vil hj\u00e6lpe os med hurtig adgang til n\u00f8dvendige ressourcer \u2014 hvis der blot er plads i datacentret.<\/p>\n

Desuden g\u00f8r den distribuerede klynge-database model det muligt at flytte denne database dertil, hvor den er n\u00f8dvendig; hvis vi taler om en global service, s\u00e5 er det ret ulogisk at k\u00f8re webklyngen et sted i San Francisco og samtidig sende pakker frem og tilbage til databasen i Moskva.<\/p>\n

Containerisering af databasen muligg\u00f8r, at alle systemelementer kan placeres p\u00e5 et ensartet abstraktionsniveau. Dette g\u00f8r det muligt at administrere systemet direkte fra koden af udviklerne, uden aktiv involvering af administratorer. Udviklerne t\u00e6nkte, at der var behov for en separat database til et nyt projekt \u2014 det er nemt! De skrev en yaml-fil, uploadede den til klyngen, og s\u00e5 var det klart.<\/p>\n

Og selvf\u00f8lgelig g\u00f8r intern driftsbrug det meget lettere. Sig mig, hvor mange gange har du lukket \u00f8jnene, n\u00e5r et nyt teammedlem stak h\u00e6nderne ind i den aktive database? Den, som I i virkeligheden kun har \u00e9n af, og som k\u00f8rer lige nu? Selvf\u00f8lgelig er vi alle voksne mennesker her, og vi har et friskt backup et sted, og endnu l\u00e6ngere bag hylden med bedstemorens syltede agurker og gamle ski - en anden backup, m\u00e5ske endda p\u00e5 kold opbevaring, fordi dit kontor br\u00e6ndte engang. Men alligevel, hver gang et nyt teammedlem f\u00e5r adgang til den aktive infrastruktur og selvf\u00f8lgelig den aktive database \u2013 det er en spand validol for alle omkring. Hvem kender ham, den nyankomne, m\u00e5ske er han klodsede? Skr\u00e6mmende, ikke sandt?<\/p>\n

Containerisering og i bund og grund den distribuerede fysiske topologi af databasen i dit projekt hj\u00e6lper med at undg\u00e5 s\u00e5danne validol-momenter. Stoler du ikke p\u00e5 nybegynderen? Okay! Lad os oprette en egen klynge til ham at arbejde i og frakoble fra de andre databaser \u2013 synkronisering kun ved manuel push og synkron drejning af to n\u00f8gler (en til teamlederen, den anden til administratoren). Og s\u00e5 er alle glade.<\/p>\n

Og nu er det tid til at skifte kurs og g\u00e5 imod databaseklyngning.<\/p>\n

Den M\u00f8rke Side<\/h4>\n

\nOvervej, hvorfor man ikke b\u00f8r containerisere databasen og forts\u00e6tte med at k\u00f8re den p\u00e5 en central serveren<\/a>, lad os ikke falde ned p\u00e5 retorik fra ortodokserne og udsagn som \"de gamle k\u00f8rte databaser p\u00e5 hardware, og vi skal ogs\u00e5!\" I stedet lad os pr\u00f8ve at finde en situation, hvor containerisering faktisk ville give m\u00e6rkbare fordele.<\/p>\n

Enig, projekter, der virkelig har brug for en database i en container, kan t\u00e6lles p\u00e5 fingrene af \u00e9n h\u00e5nd af en ikke alt for dygtig fr\u00e6ser. I de fleste tilf\u00e6lde er endda brugen af k8s eller Docker Swarm overfl\u00f8dig \u2013 det er ret ofte, at man griber til disse v\u00e6rkt\u00f8jer p\u00e5 grund af den generelle hype omkring teknologierne og p\u00e5buddene fra \"h\u00f8je\u201c ledere om at f\u00e5 alt ind i skyen og i containere. Fordi det er trendy nu, og alle g\u00f8r det.<\/p>\n

I mange tilf\u00e6lde er brugen af Kubernetes eller blot Docker i et projekt overfl\u00f8dig. Problemet er, at ikke alle teams eller outsourcing-virksomheder, der er ansat til at h\u00e5ndtere kundens infrastruktur, er klar over dette. Det bliver v\u00e6rre, n\u00e5r containere p\u00e5tvinges, fordi det koster kunden et bestemt bel\u00f8b.<\/p>\n

Generelt er der en opfattelse af, at Docker\/kube-mafiaen simpelthen underkaster sig kunderne, der outsourcer disse infrastrukturelle sp\u00f8rgsm\u00e5l. For at arbejde med klynger er der behov for ingeni\u00f8rer, som kan dette og forst\u00e5r selve arkitekturen af den implementerede l\u00f8sning. Vi har allerede beskrevet vores case med udgivelsen af Republic \u2014 der tr\u00e6nede vi kundeteamet i at arbejde i Kubernetes, og alle var tilfredse. Og det var en ordentlig indsats. Ofte tager de, der implementerer k8s, kundens infrastruktur som gidsel \u2014 for kun de forst\u00e5r, hvordan det hele fungerer, da der ingen specialister er p\u00e5 kundens side.<\/p>\n

Forestil dig nu, at vi ikke kun overlader webserverdelen til outsourcing, men ogs\u00e5 vedligeholdelsen af databasen. Vi sagde, at databasen er hjertet, og at tab af hjertet er fatal for enhver levende organisme. Med andre ord, fremtidsudsigterne er ikke de bedste. S\u00e5 i stedet for det hypede Kubernetes ville mange projekter nyde godt af at investere i en rimelig plan p\u00e5 AWS, som ville l\u00f8se alle problemer med belastningen p\u00e5 deres hjemmeside\/projekt. Men AWS er allerede ikke in, og status symboliserer mere end penge \u2014 desv\u00e6rre g\u00e6lder det ogs\u00e5 i IT-milj\u00f8et.<\/p>\n

Okay. M\u00e5ske er klyngeteknologi faktisk n\u00f8dvendig for projektet, men hvis det er klart med stateless-applikationer, hvordan skal man s\u00e5 organisere en ordentlig netv\u00e6rksforbindelse til en klyngedatabase?<\/p>\n

N\u00e5r vi taler om den s\u00f8ml\u00f8se ingeni\u00f8rl\u00f8sning, som overgangen til k8s repr\u00e6senterer, er vores st\u00f8rste hovedpine datarapplikation i en klyngede database. Nogle databasesystemer har fra starten v\u00e6ret ret tolerante over for datafordeling mellem deres forskellige instanser. Mange andre er dog ikke s\u00e5 venlige. Og ofte bliver den prim\u00e6re faktor i valget af databasesystem til vores projekt ikke evnen til at replikere med minimale ressourcer og ingeni\u00f8romkostninger. Is\u00e6r hvis projektet oprindeligt ikke var planlagt som en mikrotjeneste, men blot har udviklet sig i den retning. <\/p>\n

Vi mener, at det ikke er n\u00f8dvendigt at tale om hastigheden af netv\u00e6rksdrev \u2014 de er langsomme. Det vil sige, vi har stadig ikke en reel mulighed for hurtigt at genoprette en instans af databasen et sted, hvor der er mere processorstyrke eller gratis RAM. Vi vil hurtigt st\u00f8de ind i begr\u00e6nsningerne af det virtualiserede disk-system. Derfor skal databasen v\u00e6re knyttet til sit eget personlige s\u00e6t af maskiner, som befinder sig i umiddelbar n\u00e6rhed. Alternativt skal vi finde en m\u00e5de at implementere en hurtig datasyngronisering til de planlagte reserver. <\/p>\n

I forl\u00e6ngelse af emnet om virtuelle filsystemer: Docker-volumes er desv\u00e6rre ikke problemfri. Generelt set ville vi i et projekt som langtidssikret datalagring helst arbejde med s\u00e5 enkelt teknisk opbygning som muligt. At tilf\u00f8je et nyt abstractionslag fra containerens filsystem til v\u00e6rtsmaskinens filsystem er allerede i sig selv en risiko. Men n\u00e5r der ogs\u00e5 opst\u00e5r problemer i containeriseringssystemets drift med at overf\u00f8re data mellem disse lag, s\u00e5 er det virkelig problematisk. Indtil videre synes st\u00f8rstedelen af de problemer, som menneskeheden kender, at v\u00e6re udbedret. Men som du ved, jo mere komplekst mekanismen er, desto lettere g\u00e5r den i stykker.<\/p>\n

I lyset af alle disse \"eventyr\" er det meget mere fordelagtigt og enklere at holde databasen \u00e9t sted, og selv hvis du har brug for at containerisere applikationen \u2013 lad den k\u00f8re for sig selv og f\u00e5 simultan forbindelse til databasen gennem en distributionsgateway, som kun vil blive l\u00e6st og skrevet \u00e9t sted. Denne tilgang reducerer risikoen for fejl og desynkroniseringer til et minimum.<\/p>\n

Hvor vil vi hen med dette? Det er vigtigt at forst\u00e5, at containerisering af databasen kun er relevant, n\u00e5r der er en reel n\u00f8dvendighed for det. Man kan ikke tage en fuld applikationsdatabase og k\u00f8re den, som om man havde et dusin mikrotjenester \u2013 det fungerer simpelthen ikke. Dette skal v\u00e6re helt klart.<\/p>\n

I stedet for output<\/h4>\n

\nHvis du venter p\u00e5 et klart svar om \"at virtualisere databasen eller ej\", s\u00e5 m\u00e5 vi skuffe dig: der vil ikke v\u00e6re et. Fordi, n\u00e5r man skaber enhver infrastrukturl\u00f8sning, skal man ikke f\u00f8lge modet og teknologiske fremskridt, men i stedet forholde sig til sund fornuft.<\/p>\n

Der findes projekter, hvor principperne og v\u00e6rkt\u00f8jerne fra Kubernetes passer perfekt, og i s\u00e5danne projekter opn\u00e5s der ofte harmoni, \u00e5tminstone i backend-omr\u00e5det. Men der er ogs\u00e5 projekter, som har brug for en normal serverinfrastruktur snarere end containerisering, fordi de principielt ikke kan skaleres til en mikrotjeneste- eller cluster-model, da de vil kollapse.
\n
Kilde: 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\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\udd47Lever databaser i Kubernetes? | ProHoster","description":"Det er historisk set s\u00e5dan, at IT-branchen er.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/34596","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=34596"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/34596\/revisions"}],"predecessor-version":[{"id":159764,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/34596\/revisions\/159764"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=34596"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=34596"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=34596"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}