{"id":82244,"date":"2020-05-20T13:42:45","date_gmt":"2020-05-20T11:42:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov"},"modified":"2020-05-20T13:42:45","modified_gmt":"2020-05-20T11:42:45","slug":"luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","title":{"rendered":"Beste Praktiken f\u00fcr Kubernetes. Erstellen kleiner Container","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Beste
\n
\nDer erste Schritt beim Deployment in Kubernetes besteht darin, Ihre Anwendung in einem Container zu platzieren. In dieser Reihe werden wir untersuchen, wie man ein Image eines kleinen und sicheren Containers erstellt.
\nDank Docker war es noch nie so einfach, Container-Images zu erstellen. Geben Sie das Basis-Image an, f\u00fcgen Sie Ihre \u00c4nderungen hinzu und erstellen Sie den Container.<\/p>\n

\"Beste
\n
\nObwohl dieser Ansatz hervorragend geeignet ist, um loszulegen, kann die Verwendung von Standardbasis-Images zu unsicheren gro\u00dfen Images f\u00fchren, die voller Schwachstellen sind.<\/a><\/noindex><\/p>\n

Au\u00dferdem verwenden die meisten Docker-Images Debian oder Ubuntu als Basis-Image, und obwohl dies eine hervorragende Kompatibilit\u00e4t und einfache Anpassung gew\u00e4hrleistet (die Docker-Datei besteht nur aus zwei Codezeilen), k\u00f6nnen Basis-Images Hunderte von Megabyte zus\u00e4tzlicher Last in Ihren Container hinzuf\u00fcgen. Zum Beispiel ben\u00f6tigt eine einfache Node.js-Anwendung in Go namens \"hello-world\" etwa 700 Megabyte, w\u00e4hrend die Gr\u00f6\u00dfe Ihrer eigentlichen Anwendung nur einige Megabyte betr\u00e4gt.<\/p>\n

\"Beste
\n
\nDiese zus\u00e4tzliche Last ist daher eine reine Verschwendung digitaler Ressourcen und ein hervorragendes Versteck f\u00fcr Schwachstellen und Sicherheitsfehler. Lassen Sie uns also zwei M\u00f6glichkeiten zur Verringerung der Gr\u00f6\u00dfe des Container-Images betrachten. <\/p>\n

Die erste M\u00f6glichkeit besteht darin, kleine Basis-Images zu verwenden, und die zweite besteht darin, das Builder Pattern zu verwenden. Die Verwendung kleinerer Basis-Images ist wahrscheinlich der einfachste Weg, um die Gr\u00f6\u00dfe Ihres Containers zu reduzieren. H\u00f6chstwahrscheinlich bietet Ihre verwendete Sprache oder Ihr Stack ein urspr\u00fcngliches Anwendungs-Image, das deutlich kleiner ist als das Standard-Image. Lassen Sie uns unseren Node.js-Container betrachten. <\/p>\n

\"Beste
\n
\nStandardm\u00e4\u00dfig betr\u00e4gt die Gr\u00f6\u00dfe des Docker-Basisbildes node:8 670 MB, w\u00e4hrend die Gr\u00f6\u00dfe von node:8-alpine nur 65 MB betr\u00e4gt, also zehnmal kleiner. Durch die Verwendung des kleineren Basisbildes Alpine reduzieren Sie die Gr\u00f6\u00dfe Ihres Containers erheblich. Alpine ist eine kleine und leichte Linux-Distribution, die bei Docker-Nutzern sehr beliebt ist, da sie mit vielen Anwendungen kompatibel ist und dabei die Containergr\u00f6\u00dfe gering h\u00e4lt. Im Gegensatz zum Standard-Docker-Bild \u201enode\u201c entfernt \u201enode:alpine\u201c viele Dienstdateien und Programme und l\u00e4sst nur die erforderlichen Elemente f\u00fcr den Betrieb Ihrer Anwendung \u00fcbrig.<\/p>\n

Um auf ein kleineres Basisbild zu wechseln, aktualisieren Sie einfach die Docker-Datei, um mit dem neuen Basisbild zu beginnen:<\/p>\n

\"Beste
\n
\nJetzt, im Gegensatz zum alten onbuild-Bild, m\u00fcssen Sie Ihren Code in den Container kopieren und alle Abh\u00e4ngigkeiten installieren. In der neuen Docker-Datei beginnt der Container mit dem Bild node:alpine, dann wird ein Verzeichnis f\u00fcr den Code erstellt, die Abh\u00e4ngigkeiten mit dem Paketmanager NPM installiert und schlie\u00dflich wird server.js gestartet.<\/p>\n

\"Beste
\n
\nMit diesem Update erhalten Sie einen Container, der zehnmal kleiner ist. Wenn Ihre Programmiersprache oder Ihr Stack keine M\u00f6glichkeit zur Verringerung des Basisbildes bietet, verwenden Sie Alpine Linux. Dadurch erhalten Sie auch die M\u00f6glichkeit, den Inhalt des Containers vollst\u00e4ndig zu verwalten. Die Verwendung kleiner Basisbilder ist eine hervorragende M\u00f6glichkeit, schnell kleine Container zu erstellen. Doch es ist noch mehr Einsparung m\u00f6glich, wenn Sie das Builder Pattern verwenden.<\/p>\n

\"Beste
\n
\nIn interpretierten Sprachen wird der Quellcode zun\u00e4chst an den Interpreter \u00fcbergeben und dann direkt ausgef\u00fchrt. In kompilierbaren Sprachen wird der Quellcode zuerst in kompilierten Code umgewandelt. Dabei nutzen Kompilationen oft Werkzeuge, die f\u00fcr die Ausf\u00fchrung des Codes tats\u00e4chlich nicht ben\u00f6tigt werden. Das bedeutet, dass Sie diese Werkzeuge vollst\u00e4ndig aus dem endg\u00fcltigen Container entfernen k\u00f6nnen. Daf\u00fcr kann das Builder Pattern verwendet werden.<\/p>\n

\"Beste
\n
\nDer Code wird im ersten Container erstellt und kompiliert. Dann wird der kompilierte Code ohne Compiler und Werkzeuge, die f\u00fcr die Kompilierung dieses Codes ben\u00f6tigt werden, in den endg\u00fcltigen Container verpackt. Lassen Sie uns diesen Prozess mit einer Go-Anwendung durchlaufen. Zuerst wechseln wir vom onbuild-Bild zu Alpine Linux.<\/p>\n

\"Beste
\n
\nIn der neuen Docker-Datei beginnt der Container mit dem Bild golang:alpine. Dann wird ein Verzeichnis f\u00fcr den Code erstellt, der Quellcode wird hineinkopiert, dieser Quellcode wird erstellt und die Anwendung wird gestartet. Dieser Container ist viel kleiner als der onbuild-Container, enth\u00e4lt jedoch immer noch den Compiler und andere Go-Tools, die wir eigentlich nicht ben\u00f6tigen. Lassen Sie uns daher einfach das kompilierte Programm extrahieren und in unseren eigenen Container packen.<\/p>\n

\"Beste
\n
\nVielleicht f\u00e4llt Ihnen etwas Seltsames in dieser Docker-Datei auf: Sie enth\u00e4lt zwei FROM-Zeilen. Der erste Abschnitt aus vier Zeilen sieht genau so aus wie die vorherige Docker-Datei, mit der Ausnahme, dass er das Schl\u00fcsselwort AS verwendet, um dieser Phase einen Namen zu geben. Im n\u00e4chsten Abschnitt gibt es eine neue FROM-Zeile, die es erm\u00f6glicht, mit einem neuen Bild zu beginnen, wobei wir anstelle des Bildes golang:alpine das Raw Alpine verwenden.<\/p>\n

Raw Alpine Linux hat keine installierten SSL-Zertifikate, was die meisten API-Aufrufe \u00fcber das HTTPS-Protokoll zum Scheitern bringen wird. Lass uns also ein paar Root-CA-Zertifikate installieren.<\/p>\n

Und jetzt kommt das Interessante: Um den kompilierte Code vom ersten Container in den zweiten zu kopieren, kann einfach der COPY-Befehl in Zeile 5 des zweiten Abschnitts verwendet werden. Er wird nur eine Datei der Anwendung kopieren und die Go-Werkzeuge unber\u00fchrt lassen. Die neue mehrstufige Docker-Datei wird ein Containerbild mit nur 12 Megabyte Gr\u00f6\u00dfe enthalten, w\u00e4hrend das urspr\u00fcngliche Containerbild 700 Megabyte betrug, was einen gro\u00dfen Unterschied ausmacht!
\nSo sind die Verwendung kleiner Basisbilder und das Builder Pattern hervorragende M\u00f6glichkeiten, Container mit deutlich geringeren Gr\u00f6\u00dfen zu erstellen, ohne viel Aufwand.
\nEs ist m\u00f6glich, dass je nach Anwendungsstacks zus\u00e4tzliche M\u00f6glichkeiten zur Reduzierung der Gr\u00f6\u00dfe von Bildern und Containern bestehen, aber haben wirklich kleine Container messbare Vorteile? Lassen Sie uns zwei Aspekte betrachten, in denen kleine Container \u00e4u\u00dferst effizient sind \u2013 Leistung und Sicherheit.<\/p>\n

Um das Wachstum der Leistung zu bewerten, betrachten wir die Dauer des Container-Erstellungsprozesses, das Pushen in das Registry und das anschlie\u00dfende Pullen daraus. Sie werden feststellen, dass ein kleinerer Container einen unbestreitbaren Vorteil gegen\u00fcber einem gr\u00f6\u00dferen Container hat.<\/p>\n

\"Beste
\n
\nDocker wird die Schichten zwischenspeichern, sodass nachfolgende Builds sehr schnell durchgef\u00fchrt werden. In vielen CI-Systemen, die zum Erstellen und Testen von Containern verwendet werden, werden die Schichten jedoch nicht zwischengespeichert, was hier zu einer erheblichen Zeitersparnis f\u00fchrt. Wie zu sehen ist, betr\u00e4gt die Bauzeit eines gro\u00dfen Containers abh\u00e4ngig von der Leistung Ihres Ger\u00e4ts zwischen 34 und 54 Sekunden, w\u00e4hrend der Einsatz eines kleineren Containers, der durch das Builder Muster optimiert wurde, zwischen 23 und 28 Sekunden liegt. Bei solchen Operationen liegt der Leistungszuwachs bei 40-50%. Denken Sie einfach daran, wie oft Sie Ihren Code erstellen und testen.<\/p>\n

Nachdem der Container gebaut wurde, m\u00fcssen Sie das Container-Image in das Container-Registry pushen, um es dann in Ihrem Kubernetes-Cluster zu verwenden. Ich empfehle, das Google Container Registry zu verwenden.<\/p>\n

\"Beste
\n
\nBei Verwendung des Google Container Registry (GCR) zahlen Sie nur f\u00fcr den \"rohen\" Speicher und das Netzwerk, es fallen keine zus\u00e4tzlichen Geb\u00fchren f\u00fcr die Containerverwaltung an. Es ist vertraulich, sicher und sehr schnell. GCR verwendet viele Tricks, um den Pull-Vorgang zu beschleunigen. Wie Sie sehen k\u00f6nnen, dauert das Pushen des Docker Container Image bei der Verwendung von go:onbuild abh\u00e4ngig von der Leistung des Computers zwischen 15 und 48 Sekunden, w\u00e4hrend dasselbe bei einem kleineren Container zwischen 14 und 16 Sekunden dauert. F\u00fcr weniger leistungsf\u00e4hige Maschinen steigt der Geschwindigkeitsvorteil der Operation um das Dreifache. F\u00fcr gro\u00dfe Maschinen ist die Zeit ungef\u00e4hr gleich, da GCR einen globalen Cache f\u00fcr die gesamte Bildbasis verwendet, d.h. Sie m\u00fcssen sie \u00fcberhaupt nicht herunterladen. Bei schwach leistungsf\u00e4higen Computern ist die CPU der Engpass, daher ist der Vorteil der Verwendung kleiner Container hier viel sp\u00fcrbarer.<\/p>\n

Wenn Sie GCR verwenden, empfehle ich dringend, den Google Container Builder (GCB) als Teil Ihres Build-Systems zu verwenden.<\/p>\n

\"Beste
\n
\nWie Sie sehen, erm\u00f6glicht die Nutzung eine deutlich bessere Reduzierung der Build+Push-Dauer als selbst bei einem leistungsf\u00e4higen Rechner \u2013 in diesem Fall wird der Prozess des Erstellens und Sendens von Containern auf den Host um nahezu das Zweifache beschleunigt. Dar\u00fcber hinaus erhalten Sie jeden Tag 120 Minuten kostenlose Builds, was in den meisten F\u00e4llen den Anforderungen an die Containererstellung entspricht. <\/p>\n

Als N\u00e4chstes kommt die wichtigste Leistungsmetrik \u2013 die Geschwindigkeit des Pulls, also das Herunterladen von Containern. Und wenn es Sie nicht besonders st\u00f6rt, wie lange der Push dauert, so beeinflusst die Dauer des Pull-Vorgangs erheblich die Gesamtleistung des Systems. Angenommen, Sie haben einen Cluster aus drei Knoten und einer davon f\u00e4llt aus. Wenn Sie ein Management-System wie Google Kubernetes Engine verwenden, wird der nicht funktionierende Knoten automatisch durch einen neuen ersetzt. Dieser neue Knoten wird jedoch ganz leer sein, und Sie m\u00fcssen alle Ihre Container dorthin \u00fcbertragen, damit er arbeiten kann. Wenn der Pull-Vorgang lang genug dauert, wird Ihr Cluster die gesamte Zeit mit verminderter Leistung arbeiten.<\/p>\n

Es gibt viele Szenarien, in denen so etwas geschehen kann: das Hinzuf\u00fcgen eines neuen Knotens zum Cluster, das Aktualisieren von Knoten oder sogar das Wechseln zu einem neuen Container f\u00fcr das Deployment. Daher wird die Minimierung der Pull-Zeit zu einem entscheidenden Faktor. Es ist unbestreitbar, dass ein kleiner Container viel schneller heruntergeladen wird als ein gro\u00dfer. Wenn Sie mehrere Container in einem Kubernetes-Cluster verwenden, kann die Zeitersparnis erheblich sein.<\/p>\n

\"Beste
\n
\nSchauen Sie sich den folgenden Vergleich an: Der Pull-Vorgang bei kleinen Containern dauert je nach Rechnerleistung 4-9 Mal k\u00fcrzer als derselbe Vorgang mit go:onbuild. Die Verwendung von gemeinsam genutzten Basis-Containern in kleiner Gr\u00f6\u00dfe beschleunigt erheblich die Zeit und Geschwindigkeit, mit der neue Kubernetes-Knoten bereitgestellt und ins Internet gehen k\u00f6nnen.<\/p>\n

Lassen Sie uns die Frage der Sicherheit betrachten. Es wird angenommen, dass kleinere Container viel sicherer sind als gro\u00dfe, da sie eine geringere Angriffsoberfl\u00e4che haben. Stimmt das wirklich? Eine der n\u00fctzlichsten Funktionen des Google Container Registry ist die M\u00f6glichkeit, Ihre Container automatisch auf Schwachstellen zu scannen. Vor einigen Monaten habe ich sowohl onbuild- als auch mehrstufige Container erstellt, also schauen wir uns an, ob es dort verletzliche Stellen gibt. <\/p>\n

\"Beste
\n
\nDas Ergebnis ist beeindruckend: In einem kleinen Container wurden nur 3 mittlere Schwachstellen gefunden, w\u00e4hrend in einem gro\u00dfen Container 16 kritische und 376 weitere Schwachstellen entdeckt wurden. Wenn wir den Inhalt des gro\u00dfen Containers betrachten, wird deutlich, dass die meisten Sicherheitsprobleme nichts mit unserer Anwendung zu tun haben, sondern mit Programmen, die wir nicht einmal nutzen. Daher, wenn Menschen von einer gro\u00dfen Angriffsfl\u00e4che sprechen, meinen sie genau das. <\/p>\n

\"Beste
\n
\nDie Erkenntnis ist klar: Erstellen Sie kleine Container, denn sie bieten echte Vorteile in Bezug auf die Leistung und Sicherheit Ihres Systems. <\/p>\n

Beste Praktiken f\u00fcr Kubernetes. Organisation von Kubernetes mit Namensr\u00e4umen<\/a><\/noindex><\/p>\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Ein wenig Werbung \ud83d\ude42<\/h3>\n

\nDanke, dass Sie bei uns bleiben. Gefallen Ihnen unsere Artikel? M\u00f6chten Sie mehr interessante Inhalte sehen? Unterst\u00fctzen Sie uns, indem Sie eine Bestellung aufgeben oder uns Freunden empfehlen, Cloud-VPS f\u00fcr Entwickler ab 4,99 $<\/a><\/noindex>, ein einzigartiges \u00c4quivalent zu Einsteigerservern, das wir f\u00fcr Sie entwickelt haben:<\/b> Die ganze Wahrheit \u00fcber VPS (KVM) E5-2697 v3 (6 Kerne) 10GB DDR4 480GB SSD 1Gbps ab 19 $ oder wie man einen Server richtig teilt?<\/a><\/noindex> (es sind Optionen mit RAID1 und RAID10 bis zu 24 Kernen und bis zu 40GB DDR4 verf\u00fcgbar).<\/p>\n

Dell R730xd ist im Equinix Tier IV Rechenzentrum in Amsterdam doppelt so g\u00fcnstig?<\/b> Nur bei uns 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB ab $199<\/a><\/noindex> in den Niederlanden! Dell R420 \u2014 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB \u2014 ab $99!<\/b><\/b> Lesen Sie, wie man eine Unternehmensinfrastruktur der Klasse C mit Dell R730xd E5-2650 v4-Servern f\u00fcr 9000 Euro im Preis-Leistungs-Verh\u00e4ltnis aufbaut?<\/a><\/noindex>
\n
Quelle: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041f\u0435\u0440\u0432\u044b\u0439 \u0448\u0430\u0433 \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u0432 Kubernetes \u2013 \u044d\u0442\u043e \u0440\u0430\u0437\u043c\u0435\u0449\u0435\u043d\u0438\u0435 \u0432\u0430\u0448\u0435\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0435. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0435\u0440\u0438\u0438 \u043c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0441\u043e\u0437\u0434\u0430\u0442\u044c \u043e\u0431\u0440\u0430\u0437 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0433\u043e \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430. \u0411\u043b\u0430\u0433\u043e\u0434\u0430\u0440\u044f Docker, \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0435 \u043e\u0431\u0440\u0430\u0437\u043e\u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 \u043d\u0438\u043a\u043e\u0433\u0434\u0430 \u0435\u0449\u0435 \u043d\u0435 \u0431\u044b\u043b\u043e \u043d\u0430\u0441\u0442\u043e\u043b\u044c\u043a\u043e \u043f\u0440\u043e\u0441\u0442\u044b\u043c. \u0423\u043a\u0430\u0436\u0438\u0442\u0435 \u0431\u0430\u0437\u043e\u0432\u044b\u0439 \u043e\u0431\u0440\u0430\u0437, \u0434\u043e\u0431\u0430\u0432\u044c\u0442\u0435 \u0441\u0432\u043e\u0438 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0438 \u0441\u043e\u0437\u0434\u0430\u0439\u0442\u0435 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440. \u041d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u0442\u043e, \u0447\u0442\u043e \u0434\u0430\u043d\u043d\u044b\u0439 \u043f\u0440\u0438\u0435\u043c \u043e\u0442\u043b\u0438\u0447\u043d\u043e \u043f\u043e\u0434\u0445\u043e\u0434\u0438\u0442 \u0434\u043b\u044f \u043d\u0430\u0447\u0430\u043b\u0430 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":82245,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-82244","post","type-post","status-publish","format-standard","has-post-thumbnail","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\n","aioseo_head_json":{"title":"\ud83e\udd47 Beste Praktiken f\u00fcr Kubernetes. Erstellung kleiner Container | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\u041b\u0443\u0447\u0448\u0438\u0435 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 Kubernetes. \u0421\u043e\u0437\u0434\u0430\u043d\u0438\u0435 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 | ProHoster","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","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":"2020-05-20T11:42:45+00:00","article:modified_time":"2020-05-20T11:42:45+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"82244","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":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:41:28","updated":"2022-09-28 11:52:01","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/82244","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=82244"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/82244\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/82245"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=82244"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=82244"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=82244"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}