{"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\/hr\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","title":{"rendered":"\u017dive li baze podataka u Kubernetesu?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\u017dive
\n
\nNa neki na\u010din, historijski se razvila situacija u kojoj se IT industrija po svemu razdvaja na dva uvjetna tabora: one 'za' i one 'protiv'. Tema sporova mo\u017ee biti apsolutno proizvoljna. Koji operativni sustav je bolji: Windows ili Linux? Na pametnom telefonu, Android ili iOS? Imati sve u oblaku ili pohraniti na hladne RAID ure\u0111aje i staviti diskove u sef? Imaju li PHP programeri pravo nazvati se programerima? Ovi sporovi \u010desto imaju isklju\u010divo egzistencijalnu prirodu i ne temelje se ni na \u010demu osim sportskog interesa.<\/p>\n

Naime, s pojavom kontejnera i svih ovih voljenih kuhinja s Dockerom i uvjetnim k8s zapo\u010deli su i sporovi 'za' i 'protiv' kori\u0161tenja novih mogu\u0107nosti u razli\u010ditim sferama backend-a. (Unaprijed se dogovaramo da \u0107e se u ovom razmatranju kao orkestrator naj\u010de\u0161\u0107e navoditi Kubernetes, ali izbor ovog alata nije od su\u0161tinskog zna\u010daja. Umjesto njega mo\u017ee se staviti bilo koji drugi koji vam se \u010dini najprikladnijim i najpoznatijim.)<\/p>\n

I, \u010dinilo bi se, bio bi to jednostavan spor izme\u0111u dvije strane jedne medalje. Isto tako besmislen i neumoljiv kao vje\u010dno suprotstavljanje Windows vs Linux, u kojem razboriti ljudi srame\u017eljivo postoje negdje na sredini. No, kod kontejnerizacije, stvari nisu tako jednostavne. Obi\u010dno u takvim sporovima nema prave strane, ali u slu\u010daju 'koristiti' ili 'ne koristiti' kontejnere za pohranu baza podataka, sve se preokrene naopa\u010dke. Jer u odre\u0111enom smislu, i pristalice i protivnici ovog pristupa su u pravu.
\n<\/a><\/noindex><\/p>\n

Svetla strana<\/h4>\n

\nKratko opisati argumentaciju Svetle strane mo\u017ee se jednom re\u010denicom: 'Halo, 2k19 je vani!' Zvu\u010di kao populizam, naravno, ali ako se detaljno razmotri situacija, postoje svoje prednosti. To \u0107emo sada i analizirati.<\/p>\n

Pretpostavimo da imate veliki web projekt. Mogao se izvorno graditi na temelju mikroservisnog pristupa, ili ste do njega do\u0161li evolucijskim putem \u2014 to u stvari nije toliko va\u017eno. Rasporedili ste na\u0161 projekt po pojedina\u010dnim mikroservisima, postavili orkestraciju, ravnote\u017eu optere\u0107enja, skaliranje. I sada s \u010distom savesti pijete mojito u le\u017ealjci tijekom habra-efekata umesto da podi\u017eete sru\u0161ene servere. No, u svemu se mora biti dosljedan. Vrlo \u010desto se containerizuje samo samo aplikacija \u2014 kod. A \u0161to jo\u0161 imamo osim koda?<\/p>\n

To\u010dno, podaci. Srce svakog projekta \u2014 su njegovi podaci: to mo\u017ee biti tipi\u010dna baza podataka \u2014 MySQL, Postgre, MongoDB, kao i skladi\u0161ta koja se koriste za pretra\u017eivanje (ElasticSearch), key-value skladi\u0161ta za ke\u0161iranje \u2014 na primjer, redis, itd. Sada ne\u0107emo govoriti o lo\u0161im varijantama implementacije backenda, kada se baza podataka sru\u0161i zbog lo\u0161e napisanih upita, ve\u0107 \u0107emo razgovarati o osiguravanju otpornosti te iste baze podataka pod klijentskim optere\u0107enjem. Kada containeriziramo na\u0161u aplikaciju i omogu\u0107imo joj slobodno skaliranje za obradu bilo kojeg broja ulaznih zahtjeva, to logi\u010dno pove\u0107ava i optere\u0107enje na bazi podataka.<\/p>\n

U su\u0161tini, kanal pristupa bazi podataka i server na kojem se ona vrti postaju iglene u\u0161i u na\u0161em prekrasnom containeriziranom backendu. Pri tome je osnovna motivacija containerne virtualizacije \u2014 pokretljivost i fleksibilnost strukture, \u0161to omogu\u0107ava organizaciju raspodjele vr\u0161nog optere\u0107enja u cijeloj dostupnoj infrastrukturi na naju\u010dinkovitiji na\u010din. Dakle, ako ne containeriziramo i ne raspore\u0111ujemo sve elemente sustava po klasteru \u2014 pravimo vrlo ozbiljnu gre\u0161ku.<\/p>\n

Mnogo je logi\u010dnije klasterizirati ne samo samo aplikaciju, ve\u0107 i usluge koje su odgovorne za pohranu podataka. Prilikom klasterizacije i implementacije neovisnih web poslu\u017eitelja koji raspore\u0111uju optere\u0107enje unutar k8s, ve\u0107 rje\u0161avamo problem sinhronizacije podataka \u2014 na primjer, komentara na objave, ako uzmemo u obzir neku medijsku ili blog platformu. U svakom slu\u010daju, unutar klastera imamo, iako virtualni, prikaz baze podataka kao ExternalService. Pitanje je to \u0161to sama baza podataka jo\u0161 nije klasterizirana \u2014 web poslu\u017eitelji raspore\u0111eni u klasteru povla\u010de informacije o promjenama iz na\u0161e stati\u010dne produkcijske baze koja radi odvojeno.<\/p>\n

Osje\u0107ate li sumnju? Koristimo k8s ili Swarm da bismo rasporedili optere\u0107enje i izbjegli pad glavnog web poslu\u017eitelja<\/a>, ali to ne radimo za bazu podataka. Ali ako padne baza podataka, cijela na\u0161a klasterizirana infrastruktura gubi smisao \u2014 kakva je korist od praznih web stranica koje vra\u0107aju gre\u0161ku pristupa bazi podataka?<\/p>\n

Zato klasterizirati trebamo ne samo web poslu\u017eitelje, kao \u0161to se obi\u010dno radi, ve\u0107 i infrastrukturu baze podataka. Samo na taj na\u010din mo\u017eemo osigurati potpuno funkcionalnu strukturu koja radi u jednoj ekipi, ali je pri tome neovisna jedna o drugoj. \u010cak i ako polovica na\u0161eg backend-a 'padne' pod optere\u0107enjem \u2014 ostatak \u0107e pre\u017eivjeti, a sustav sinhronizacije baza podataka unutar klastera i mogu\u0107nost beskona\u010dnog skaliranja i implementacije novih klastera pomo\u0107i \u0107e da brzo do\u0111emo do potrebnih kapaciteta \u2014 ako su rackovi u data centru.<\/p>\n

Osim toga, distribuirani klasterski model baze podataka omogu\u0107ava premje\u0161tanje te baze podataka na mjesta gdje je potrebna; ako govorimo o globalnoj usluzi, prili\u010dno je nelogi\u010dno imati web klaster negdje u blizini San Francisca i istodobno slati pakete prema bazi podataka u Podmoskovlju i natrag.<\/p>\n

Osim toga, kontejnerizacija baze podataka omogu\u0107ava izgradnju svih elemenata sustava na istoj razini apstrakcije. To, pak, omogu\u0107uje upravljanje tim sustavom iz koda, od strane programera, bez aktivnog uklju\u010divanja administratora. Programerima se u\u010dinilo da je potrebna posebna DBMS za novi podprojekt \u2014 lako! napisali su yaml datoteku, u\u010ditali je u klaster i gotovi.<\/p>\n

Naravno, unutarnje upravljanje postaje znatno jednostavnije. Recite mi, koliko ste puta zatvorili o\u010di kad je novi \u010dlan tima pru\u017eao ruke prema produkcijskoj bazi podataka? Koja vam, zapravo, jedina postoji i upravo se vrti? Naravno, svi smo mi ovdje odrasli ljudi, i negdje imamo svje\u017ei backup, a jo\u0161 dalje \u2014 iza police s bakinim krastavcima i starim skijama \u2014 jo\u0161 jedan backup, mo\u017eda \u010dak i na hladnom skladi\u0161tu, jer je jednom va\u0161a kancelarija gorjela. Ali bez obzira na to, svaki dolazak novog \u010dlana tima koji ima pristup produkcijskoj infrastrukturi i, naravno, produkcijskoj bazi podataka \u2014 to je za sve prisutne veliki stres. Tko zna, mo\u017eda je taj novajlija nespretan? Stra\u0161no, sla\u017eete se.<\/p>\n

Kontainerizacija i, u su\u0161tini, distribuirana fizi\u010dka topologija baze podataka va\u0161eg projekta poma\u017eu izbje\u0107i ovakve stresne trenutke. Ne vjerujete novajliji? U redu! Ovdje \u0107emo mu podi\u0107i vlastiti cluster za rad i isklju\u010diti ga od drugih databazelovskih klastera \u2014 sinkronizacija samo putem ru\u010dnog push-a i sinkronog okretanja klju\u010devima (jedan tim lideru, drugi administratoru). I svi su sretni.<\/p>\n

A sada je do\u0161lo vrijeme da se prebacimo na suprotstavljanje klasterizaciji baza podataka.<\/p>\n

Tamna strana<\/h4>\n

\nRazmatraju\u0107i za\u0161to ne bismo trebali kontainerizirati bazu podataka i nastaviti je pokretati na jednom centralnom serveru<\/a>, ne\u0107emo se spu\u0161tati na razinu retorike ortodoksa i tvrdnji tipa \"djedovi su pokretali baze na hardveru, pa \u0107emo i mi!\" Umjesto toga, poku\u0161ajmo smisliti situaciju u kojoj bi kontainerizacija zaista donijela opipljive dividende.<\/p>\n

Sla\u017eete se, projekata kojima zapravo treba baza u kontejneru mo\u017ee se prebrojati na prste jedne ruke ne ba\u0161 najspretnijeg frizera. U ve\u0107ini slu\u010dajeva, \u010dak i kori\u0161tenje k8s ili Docker Swarm mo\u017ee biti suvi\u0161no \u2014 prili\u010dno \u010desto se ti alati koriste zbog op\u0107e popularnosti tehnologija i smjernica \"sveznalica\" u liku menad\u017eera da sve stave u oblake i kontejnere. Pa, zato \u0161to je to sada popularno i svi to rade.<\/p>\n

U najmanje polovici slu\u010dajeva kori\u0161tenje Kubectl-a ili jednostavno Dockera na projektu je suvi\u0161no. Problem je \u0161to ne sve ekipe ili outsourcing kompanije zadu\u017eene za odr\u017eavanje infrastrukture klijenta shva\u0107aju to. Jo\u0161 gore - kada se kontejneri name\u0107u, jer to ko\u0161ta odre\u0111eni iznos novca klijentu.<\/p>\n

Op\u0107enito, postoji mi\u0161ljenje da Docker\/kubik-mafija jednostavno pod\u010dinjava klijente koji prepu\u0161taju ova infrastrukturna pitanja outsourcingu. Jer za rad s klastraima trebaju in\u017eenjeri koji to mogu i razumiju arhitekturu implementiranog rje\u0161enja. Ve\u0107 smo opisali na\u0161 slu\u010daj s publikacijom Republic - tamo smo obu\u010dili klijentovu ekipu da radi u stvarnosti Kubernetesa, i svi su bili zadovoljni. I to je bilo pravedno. \u010cesto \u201eimplementatori\u201c k8s uzimaju klijentovu infrastrukturu kao taoce - jer sada samo oni razumiju kako sve to funkcionira, dok na strani klijenta nema stru\u010dnjaka.<\/p>\n

A sada zamislite da time predajemo ne samo web-server dio u outsourcing, ve\u0107 i odr\u017eavanje baze podataka. Rekli smo da je baza podataka srce, a gubitak srca smrtonosan za svaki \u017eivi organizam. Ukratko, perspektive nisu najbolje. Dakle, umjesto hype-a Kubernetesa, mnogim projektima bi bilo bolje jednostavno ne \u0161tedjeti na normalnom tarifnom planu na AWS-u, koji bi rije\u0161io sve probleme s optere\u0107enjem na njihovoj web stranici\/projektu. No AWS vi\u0161e nije u modi, a pretencioznost je skuplja od novca - na\u017ealost, to va\u017ei i u IT okru\u017eenju.<\/p>\n

U redu. Mo\u017eda klasterizacija stvarno treba projektu, ali ako je s ne-stateless aplikacijama sve jasno, kako organizirati dostojno osiguranje mre\u017ene povezanosti klasterizirane baze podataka?<\/p>\n

Kada govorimo o be\u0161avnom in\u017eenjerskom re\u0161enju koje na\u0161a migracija na k8s predstavlja, na\u0161 najve\u0107i problem je replikacija podataka u klasterizovanoj bazi podataka. Neki DBMS-ovi su od samog po\u010detka prili\u010dno tolerantni prema distribuciji podataka me\u0111u svojim instancama. Me\u0111utim, mnogi drugi nisu tako ljubazni. \u010cesto je glavni argument pri izboru DBMS-a za na\u0161 projekat sposobnost replikacije sa minimalnim resursnim i in\u017eenjerskim tro\u0161kovima, posebno ako projekat nije izvorno zami\u0161ljen kao mikroservisni, ve\u0107 se samo razvio u tom pravcu. <\/p>\n

Ne mislimo da je potrebno obja\u0161njavati brzinu rada mre\u017enih diskova \u2014 oni su spori. U slu\u010daju potrebe, nemamo stvarnu mogu\u0107nost da podignemo instancu DBMS-a negde gde bi, na primer, bilo vi\u0161e procesorske snage ili slobodne RAM memorije. Veoma brzo \u0107emo nai\u0107i na ograni\u010denja performansi virtualizovanog diskovnog sistema. Shodno tome, DBMS mora biti vezan za svoj vlastiti set ma\u0161ina koje se nalaze u neposrednoj blizini. Ili se mora na neki na\u010din napraviti brza sinhronizacija podataka za pripremljene rezerve. <\/p>\n

Nastavljaju\u0107i temu virtualnih FS: Docker Volumes, na\u017ealost, nisu bez problema. U pravilu, kada je re\u010d o dugoro\u010dnom pouzdanom skladi\u0161tenju podataka, \u017eeleli bismo da se oslanjamo na \u0161to jednostavnije tehni\u010dke sheme. Dodavanje novog sloja apstrakcije iz FS-a kontejnera u FS roditeljskog hosta je ve\u0107 samo po sebi rizik. Ali kada se u radu sistema za obezbe\u0111ivanje kontejnerizacije suo\u010dimo sa problemima pri translatiranju podataka izme\u0111u ovih slojeva, to je ve\u0107 ozbiljna situacija. Trenutno se \u010dini da su ve\u0107ina poznatih problema tehni\u010dke zajednice otklonjena. No, kao \u0161to znate, \u0161to je mehanizam slo\u017eeniji, to je lak\u0161e da se pokvari.<\/p>\n

S obzirom na sve ove \"avanture\", daleko je isplativije i jednostavnije dr\u017eati bazu podataka na jednom mjestu. \u010cak i ako vam zatreba kontejnerizacija aplikacije, neka ona radi sama za sebe i putem distribucijskog pristupa ostvaruje istovremenu komunikaciju s bazom podataka, koja \u0107e se \u010ditati i pisati samo jednom i na jednom mjestu. Ovaj pristup smanjuje mogu\u0107nost gre\u0161aka i desinkronizacija na minimalne vrijednosti.<\/p>\n

Kamo mi idemo? Do toga da je kontejnerizacija baze podataka opravdana tamo gdje postoji stvarna potreba. Ne mo\u017eete ugurati bazu punog odgovora i vrtjeti je kao da imate dvije desetine mikroslu\u017ebi \u2014 to ne funkcionira tako. To treba jasno razumjeti.<\/p>\n

Umjesto izlaza<\/h4>\n

\nAko o\u010dekujete jasan odgovor na pitanje \"virtualizirati ili ne bazu podataka?\", moramo vas razo\u010darati: ovdje ga ne\u0107e biti. Jer pri stvaranju bilo kojeg infrastrukturnog rje\u0161enja treba se rukovoditi ne modom i napretkom, ve\u0107 prije svega, zdravim razumom.<\/p>\n

Postoje projekti na koje principi i alati koji dolaze s Kubernetesom savr\u0161eno odgovaraju, i u takvim projektima dolazi do mira barem u backend podru\u010dju. A postoje projekti kojima nije potrebna kontejnerizacija, ve\u0107 normalna serverska infrastruktura, jer se na\u010delno ne mogu prilagoditi za mikroslu\u017ebenu klastersku samotak, ina\u010de \u0107e propasti.
\n
Izvor: 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\udd47\u017dive li baze podataka u Kubernetesu? | ProHoster","description":"Osnovalo se tako historijski, da IT industrija radi.","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/zhivut-li-bazy-dannyh-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/34596","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=34596"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/34596\/revisions"}],"predecessor-version":[{"id":159764,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/34596\/revisions\/159764"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=34596"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=34596"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=34596"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}