{"id":53120,"date":"2019-11-24T00:00:00","date_gmt":"2019-11-23T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/3-way-merge-v-werf-deploj-v-kubernetes-s-helm-na-steroidah"},"modified":"2020-02-18T14:00:59","modified_gmt":"2020-02-18T11:00:59","slug":"3-way-merge-v-werf-deploj-v-kubernetes-s-helm-na-steroidah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/3-way-merge-v-werf-deploj-v-kubernetes-s-helm-na-steroidah","title":{"rendered":"3-Wege-Zusammenf\u00fchrung in werf: Deployment in Kubernetes mit Helm \u00abauf Steroiden\u00bb","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Es ist passiert, worauf wir (und nicht nur wir) lange gewartet haben: <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/\">werf<\/a><\/noindex>, unser Open Source-Tool zum Erstellen und Bereitstellen von Anwendungen in Kubernetes unterst\u00fctzt jetzt die Anwendung von \u00c4nderungen mit 3-Wege-Zusammenf\u00fchrungs-Patches! Dar\u00fcber hinaus gibt es jetzt die M\u00f6glichkeit, bestehende K8s-Ressourcen in Helm-Releases zu \u00fcbernehmen, ohne diese Ressourcen neu erstellen zu m\u00fcssen.<\/p>\n<p><img decoding=\"async\" alt=\"3-Wege-Zusammenf\u00fchrung in werf: Deployment in Kubernetes mit Helm \u00abauf Steroiden\u00bb\" src=\"\/wp-content\/uploads\/2019\/11\/e5be3544c201f7b2c97fba216a49506d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKurz gesagt, wir setzen <code>WERF_THREE_WAY_MERGE=enabled<\/code> \u2014 und erhalten ein Deployment \u00abwie in <code>kubectl apply<\/code>\u00bb, das mit bestehenden Installationen auf Helm 2 und sogar etwas mehr kompatibel ist.<\/p>\n<p>Aber lass uns mit der Theorie beginnen: Was genau sind 3-Wege-Zusammenf\u00fchrungs-Patches, wie sind die Leute zu diesem Ansatz gekommen und warum sind sie wichtig in CI\/CD-Prozessen mit Kubernetes-basierter Infrastruktur? Danach schauen wir uns an, was die 3-Wege-Zusammenf\u00fchrung in werf ist, welche Modi standardm\u00e4\u00dfig verwendet werden und wie man damit umgeht.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Was ist ein 3-Wege-Zusammenf\u00fchrungs-Patch?<\/h2>\n<p>\nBeginnen wir mit der Aufgabe, Ressourcen, die in YAML-Manifests beschrieben sind, in Kubernetes bereitzustellen.<\/p>\n<p>Um mit Ressourcen zu arbeiten, bietet die Kubernetes-API die grundlegenden Operationen: create, patch, replace und delete. Diese sollen dazu dienen, einen kontinuierlichen Rollout von Ressourcen in den Cluster bequem zu gestalten. Wie?<\/p>\n<h3>Imperative Befehle von kubectl<\/h3>\n<p>\nDer erste Ansatz zur Verwaltung von Objekten in Kubernetes ist die Verwendung von imperativen kubectl-Befehlen zum Erstellen, \u00c4ndern und L\u00f6schen dieser Objekte. Einfacher ausgedr\u00fcckt:<\/p>\n<ul>\n<li> mit dem Befehl <code>kubectl run<\/code> hiermit k\u00f6nnen Sie ein Deployment oder Job starten:\n<pre><code class=\"bash\">kubectl run --generator=deployment\/apps.v1 DEPLOYMENT_NAME --image=IMAGE<\/code><\/pre>\n<\/li>\n<li> mit dem Befehl <code>kubectl scale<\/code> \u2013 \u00e4ndern Sie die Anzahl der Replikate:\n<pre><code class=\"bash\">kubectl scale --replicas=3 deployment\/mysql<\/code><\/pre>\n<\/li>\n<li>usw.<\/li>\n<\/ul>\n<p>\nDieser Ansatz scheint auf den ersten Blick praktisch zu sein. Es gibt jedoch Probleme: <\/p>\n<ol>\n<li> Es ist schwierig, <b>diesen Prozess zu automatisieren. Er \u00fcberwacht die Historie der CPU- und Speicherauslastung und passt neue Requests und Limits basierend auf diesen Informationen an.<\/b>.<\/li>\n<li> Wie <b>die Konfiguration<\/b> in Git zu reflektieren? Wie f\u00fchren Sie eine \u00dcberpr\u00fcfung der \u00c4nderungen durch, die am Cluster vorgenommen werden?<\/li>\n<li> Wie stellen Sie sicher, dass <b>die Konfiguration<\/b> bei einem Neustart reproduzierbar ist?<\/li>\n<li>\u2026<\/li>\n<\/ol>\n<p>\nEs ist klar, dass dieser Ansatz schlecht mit der Speicherung von Anwendungscode und Infrastructure as Code (IaC; oder sogar <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/458878\/\">GitOps<\/a><\/noindex> als die modernere Variante, die in der Kubernetes-\u00d6kosystem an Popularit\u00e4t gewinnt) kombiniert wird. Daher haben diese Befehle in kubectl keine weitere Entwicklung erfahren.<\/p>\n<h3>Operationen create, get, replace und delete<\/h3>\n<p>\nMit der ersten <b>Erstellung<\/b> ist alles einfach: wir senden das Manifest an die Operation <code>create<\/code> an die kube API und die Ressource wird erstellt. Die YAML-Darstellung des Manifests kann in Git gespeichert werden, und zur Erstellung verwenden wir den Befehl <code>kubectl create -f manifest.yaml<\/code>.<\/p>\n<p>E <b>L\u00f6schung<\/b> ist ebenfalls einfach: wir setzen dasselbe <code>manifest.yaml ein<\/code> aus Git in das Team <code>kubectl delete -f manifest.yaml<\/code>.<\/p>\n<p>Operation <b><code>ersetzen<\/code><\/b> erm\u00f6glicht es, die Konfiguration einer Ressource vollst\u00e4ndig durch eine neue zu ersetzen, ohne die Ressource neu zu erstellen. Das bedeutet, dass es sinnvoll ist, vor einer \u00c4nderung an der Ressource die aktuelle Version mit einem <code>get<\/code>, sie zu \u00e4ndern und mit einem <code>ersetzen<\/code>zu aktualisieren. Im Kube API-Server ist <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Optimistic_concurrency_control\">optimistische Sperrung<\/a><\/noindex> integriert, und wenn sich das Objekt nach der Operation <code>get<\/code> ge\u00e4ndert hat, schl\u00e4gt die Operation <code>ersetzen<\/code> fehl.<\/p>\n<p>Um die Konfiguration in Git zu speichern und mit replace zu aktualisieren, muss man die Operation <code>get<\/code>, die Konfiguration aus Git mit dem, was wir erhalten haben, mergen und <code>ersetzen<\/code>ausf\u00fchren. Standardm\u00e4\u00dfig erlaubt kubectl nur die Verwendung des Befehls <code>kubectl replace -f manifest.yaml<\/code>, wobei <code>manifest.yaml ein<\/code> \u2014 bereits vollst\u00e4ndig vorbereiteter (in unserem Fall \u2014 gemergter) Manifest, der installiert werden muss. Das bedeutet, dass der Benutzer das Merging der Manifeste durchf\u00fchren muss, was keine triviale Aufgabe ist\u2026<\/p>\n<p>Es ist auch erw\u00e4hnenswert, dass, obwohl <code>manifest.yaml ein<\/code> in Git gespeichert wird, wir im Voraus nicht wissen k\u00f6nnen, ob wir ein Objekt erstellen oder aktualisieren m\u00fcssen \u2014 das muss die Benutzeranwendung \u00fcbernehmen.<\/p>\n<p>Insgesamt: <b>k\u00f6nnen wir eine kontinuierliche Ausrollung<\/b> nur mit create, replace und delete erreichen, indem wir die Infrastrukturkonfiguration zusammen mit dem Code und einem benutzerfreundlichen CI\/CD in Git speichern?<\/p>\n<p>Im Prinzip k\u00f6nnen wir... Daf\u00fcr <b>muss eine Merge-Operation durchgef\u00fchrt werden<\/b> f\u00fcr die Manifeste und eine Art Wrapper, die:<\/p>\n<ul>\n<li> die Existenz des Objekts im Cluster \u00fcberpr\u00fcft,<\/li>\n<li> die Erstcreation der Ressource durchf\u00fchrt,<\/li>\n<li> es aktualisiert oder l\u00f6scht.<\/li>\n<\/ul>\n<p>\nBei der Aktualisierung muss man ber\u00fccksichtigen, dass <i>sich die Ressource seit dem letzten<\/i> \u00c4nderungsvorgang ver\u00e4ndert haben k\u00f6nnte <code>get<\/code> und automatisch den Fall des optimistischen Lockings behandeln \u2014 es m\u00fcssen Wiederholungsversuche zur Aktualisierung gemacht werden.<\/p>\n<p>Aber warum das Rad neu erfinden, wenn der kube-apiserver einen anderen Weg anbietet, um Ressourcen zu aktualisieren: die Operation <code>patch<\/code>, die dem Benutzer einige der beschriebenen Probleme abnimmt?<\/p>\n<h3>Patch<\/h3>\n<p>\nHier sind wir also bei den Patches angekommen.<\/p>\n<p>Patches sind der Hauptweg, um \u00c4nderungen an bestehenden Objekten in Kubernetes anzuwenden. Die Operation <code>patch<\/code> funktioniert so, dass:<\/p>\n<ul>\n<li> der Benutzer des kube-apiserver ein Patch im JSON-Format senden und das Objekt angeben muss,<\/li>\n<li> w\u00e4hrend sich der apiserver selbst um den aktuellen Zustand des Objekts k\u00fcmmert und es in den gew\u00fcnschten Zustand bringt.<\/li>\n<\/ul>\n<p>\nOptimistisches Locking ist in diesem Fall nicht erforderlich. Diese Operation ist deklarativer als replace, auch wenn es zun\u00e4chst anders erscheinen mag.<\/p>\n<p>Somit:<\/p>\n<ul>\n<li> mit Hilfe der Operation <code>create<\/code> erstellen wir ein Objekt aus dem Manifest von Git,<\/li>\n<li> mit Hilfe von <code>l\u00f6schen<\/code> \u2014 entfernt, wenn das Objekt nicht mehr ben\u00f6tigt wird,<\/li>\n<li> mit Hilfe von <code>patch<\/code> \u2014 \u00e4ndern Sie das Objekt, um es in den im Git beschriebenen Zustand zu bringen.<\/li>\n<\/ul>\n<p>\nUm dies zu tun, ist es jedoch notwendig, <i>einen korrekten Patch zu erstellen<\/i>!<\/p>\n<h3>So funktionieren Patches in Helm 2: 2-Wege-Merge<\/h3>\n<p>\nBei der ersten Installation des Releases f\u00fchrt Helm die Operation aus, <code>create<\/code> f\u00fcr die Ressourcen des Charts.<\/p>\n<p>Beim Aktualisieren des Releases: Helm betrachtet f\u00fcr jede Ressource,<\/p>\n<ul>\n<li> den Patch zwischen der Version der Ressource aus dem vorherigen Chart und der aktuellen Version des Charts,<\/li>\n<li> und wendet diesen Patch an.<\/li>\n<\/ul>\n<p>\nSo einen Patch nennen wir <b>2-Wege-Merge-Patch<\/b>, weil bei seiner Erstellung zwei Manifeste beteiligt sind:<\/p>\n<ul>\n<li> das Manifest der Ressource aus dem vorherigen Release,<\/li>\n<li> das Manifest der Ressource aus der aktuellen Ressource.<\/li>\n<\/ul>\n<p>\nBei der L\u00f6schung wird die Operation <code>l\u00f6schen<\/code> im kube-apiserver f\u00fcr Ressourcen aufgerufen, die im vorherigen Release deklariert wurden, jedoch im aktuellen nicht deklariert sind.<\/p>\n<p>Der Ansatz mit dem 2-Wege-Merge-Patch hat ein Problem: er f\u00fchrt zu <b>eine Asynchronit\u00e4t zwischen dem tats\u00e4chlichen Zustand der Ressource im Cluster und dem Manifest im Git.<\/b>.<\/p>\n<h3>Veranschaulichung des Problems am Beispiel<\/h3>\n<p><\/p>\n<ul>\n<li> Im Git befindet sich im Chart ein Manifest, in dem das Feld <code>image<\/code> des Deployments den Wert hat <code>ubuntu:18.04.<\/code>.<\/li>\n<li> Der Benutzer hat \u00fcber <code>kubectl edit<\/code> den Wert dieses Feldes auf <code>ubuntu:19.04 ge\u00e4ndert.<\/code>.<\/li>\n<li> Bei der Neu-Deployment des Helm-Charts <i>wird kein Patch generiert,<\/i>weil das Feld <code>image<\/code> In der vorherigen Version des Releases und im aktuellen Chart sind sie identisch.<\/li>\n<li> Nach dem erneuten Deployment <code>image<\/code> bleibt <code>ubuntu:19.04 ge\u00e4ndert.<\/code>, obwohl im Chart steht <code>ubuntu:18.04.<\/code>.<\/li>\n<\/ul>\n<p>\nWir haben eine Desynchronisation erhalten und die Deklarativit\u00e4t verloren.<\/p>\n<h3>Was ist eine synchronisierte Ressource?<\/h3>\n<p>\nIm Allgemeinen <i>vollst\u00e4ndige<\/i> \u00dcbereinstimmung des Ressourcenmanifests im laufenden Cluster mit dem Manifest aus Git ist unm\u00f6glich. Denn im echten Manifest k\u00f6nnen servicebezogene Annotations\/Labels, zus\u00e4tzliche Container und andere Daten enthalten sein, die dynamisch von bestimmten Controllern zu Ressourcen hinzugef\u00fcgt oder entfernt werden. Diese Daten m\u00f6chten wir nicht im Git f\u00fchren. Wir wollen jedoch, dass bei der Bereitstellung die Felder, die wir ausdr\u00fccklich in Git angegeben haben, die entsprechenden Werte annehmen.<\/p>\n<p>Es ergibt sich also eine allgemeine <b>Regel f\u00fcr die synchronisierte Ressource<\/b>: Bei der Bereitstellung der Ressource d\u00fcrfen nur die Felder ge\u00e4ndert oder gel\u00f6scht werden, die ausdr\u00fccklich im Manifest aus Git angegeben sind (oder die in der vorherigen Version angegeben waren und nun entfernt wurden).<\/p>\n<h3>3-Wege-Merge-Patch<\/h3>\n<p>\nDie Grundidee <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Merge_(version_control)#Three-way_merge\">3-Wege-Merge-Patch<\/a><\/noindex>: Wir generieren einen Patch zwischen der zuletzt angewendeten Manifestversion aus Git und der Zielversion des Manifests aus Git, unter Ber\u00fccksichtigung der aktuellen Manifestversion aus dem laufenden Cluster. Der endg\u00fcltige Patch muss der Regel f\u00fcr synchronisierte Ressourcen entsprechen:<\/p>\n<ul>\n<li> neue Felder, die in die Zielversion aufgenommen wurden, werden durch den Patch hinzugef\u00fcgt;<\/li>\n<li> bereits vorhandene Felder in der letzten angewendeten Version, die in der Zielversion nicht existieren, werden durch den Patch auf null gesetzt;<\/li>\n<li> Felder in der aktuellen Objektversion, die von der Zielversion des Manifests abweichen, werden durch den Patch aktualisiert.<\/li>\n<\/ul>\n<p>\nNach diesem Prinzip werden die Patches erstellt. <code>kubectl apply<\/code>:<\/p>\n<ul>\n<li> Die letzte angewendete Version des Manifests wird in der Annotation des Objekts gespeichert, <\/li>\n<li> die Zielversion wird aus der angegebenen YAML-Datei entnommen,<\/li>\n<li> die aktuelle Version stammt aus dem laufenden Cluster.<\/li>\n<\/ul>\n<p>\nNachdem wir nun die Theorie gekl\u00e4rt haben, ist es an der Zeit, zu erz\u00e4hlen, was wir in werf gemacht haben.<\/p>\n<h2>Anwendung von \u00c4nderungen in werf<\/h2>\n<p>\nFr\u00fcher verwendete werf, \u00e4hnlich wie Helm 2, 2-way-merge-Patches.<\/p>\n<h3>Repair-Patch<\/h3>\n<p>\nUm auf die neue Art von Patches \u2014 3-way-merge \u2014 umzusteigen, haben wir als ersten Schritt die sogenannten <b>Repair-Patches eingef\u00fchrt.<\/b>.<\/p>\n<p>Beim Deployment wird ein Standard-2-Wege-Merge-Patch verwendet, aber werf generiert zus\u00e4tzlich einen Patch, der den aktuellen Status der Ressource mit dem synchronisiert, was in Git geschrieben steht (dieser Patch wird unter Verwendung der gleichen Synchronisationsregel erstellt, die oben beschrieben wurde).<\/p>\n<p>Im Falle eines Desynchronisierungsproblems erh\u00e4lt der Benutzer am Ende des Deployments eine WARNUNG mit einer entsprechenden Nachricht und einem Patch, der angewendet werden muss, um die Ressource in einen synchronisierten Zustand zu bringen. Au\u00dferdem wird dieser Patch in einer speziellen Annotation aufgezeichnet. <code>werf.io\/repair-patch<\/code>. Es wird davon ausgegangen, dass der Benutzer diesen Patch manuell <b>selbst<\/b> anwenden wird: werf wird dies grunds\u00e4tzlich nicht automatisch tun.<\/p>\n<p>Die Generierung von Reparatur-Patches ist eine vor\u00fcbergehende Ma\u00dfnahme, die es erm\u00f6glicht, die Erstellung von Patches nach dem 3-Wege-Merge-Prinzip praktisch zu testen, aber diese Patches nicht automatisch anzuwenden. Derzeit ist dieser Arbeitsmodus standardm\u00e4\u00dfig aktiviert.<\/p>\n<h3>3-Wege-Merge-Patch nur f\u00fcr neue Releases<\/h3>\n<p>\nAb dem 1. Dezember 2019 beginnen die Beta- und Alpha-Versionen von werf. <b>standardm\u00e4\u00dfig verwendet<\/b> Nutzen Sie vollwertige 3-Wege-Merge-Patches, um \u00c4nderungen nur auf neue Helm-Releases anzuwenden, die \u00fcber werf ausgerollt werden. Bereits bestehende Releases verwenden weiterhin den Ansatz mit 2-Wege-Merge + Repair-Patches.<\/p>\n<p>Dieser Betriebsmodus kann durch die folgende Einstellung explizit aktiviert werden: <code>WERF_THREE_WAY_MERGE_MODE=onlyNewReleases<\/code> bereits jetzt.<\/p>\n<p><i><b>Hinweis<\/b>: Diese Funktion war in werf \u00fcber mehrere Releases hinweg verf\u00fcgbar: Im Alpha-Kanal war sie ab Version <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/releases\/tag\/v1.0.5-alpha.19\">v1.0.5-alpha.19<\/a><\/noindex>, im Beta-Kanal jedoch ab <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/releases\/tag\/v1.0.4-beta.20\">v1.0.4-beta.20<\/a><\/noindex>.<\/i><\/p>\n<h3>3-Wege-Merge-Patch f\u00fcr alle Releases<\/h3>\n<p>\nSeit dem 15. Dezember 2019 verwenden Beta- und Alpha-Versionen von werf standardm\u00e4\u00dfig vollwertige 3-Wege-Merge-Patches zur Anwendung von \u00c4nderungen f\u00fcr alle Releases.<\/p>\n<p>Dieser Betriebsmodus kann durch die folgende Einstellung explizit aktiviert werden: <code>WERF_THREE_WAY_MERGE_MODE=enabled<\/code> bereits jetzt.<\/p>\n<h3>Wie steht es um die automatisierte Skalierung von Ressourcen?<\/h3>\n<p>\nIn Kubernetes gibt es 2 Arten der automatischen Skalierung: HPA (horizontal) und VPA (vertikal).<\/p>\n<p>Das horizontale Skalieren w\u00e4hlt automatisch die Anzahl der Replikate aus, das vertikale die Menge der Ressourcen. Sowohl die Anzahl der Replikate als auch die Ressourcenspezifikationen werden im Ressourcenmanifest angegeben (siehe: <code>spec.replicas<\/code> oder <code>spec.containers[].resources.limits.cpu<\/code>, <code>spec.containers[].resources.limits.memory<\/code> und <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/configuration\/manage-compute-resources-container\/#resource-requests-and-limits-of-pod-and-container\">andere<\/a><\/noindex>).<\/p>\n<p>Problem: Wenn ein Benutzer die Ressource im Chart so konfiguriert, dass bestimmte Werte f\u00fcr Ressourcen oder Replikate angegeben werden und f\u00fcr diese Ressource Autoscaler aktiviert sind, werden bei jedem Deployment werf diese Werte auf die im Manifest des Charts angegebenen zur\u00fcckgesetzt.<\/p>\n<p>Es gibt zwei L\u00f6sungen f\u00fcr das Problem. Zun\u00e4chst sollte man am besten auf die explizite Angabe autoskalierbarer Werte im Manifest des Charts verzichten. Sollte diese Option aus irgendeinem Grund nicht geeignet sein (zum Beispiel, weil es im Chart praktisch ist, anf\u00e4ngliche Ressourcengrenzen und die Anzahl der Replikate festzulegen), bietet werf die folgenden Annotationsm\u00f6glichkeiten an:<\/p>\n<ul>\n<li> <code>werf.io\/set-replicas-only-on-creation=true<\/code><\/li>\n<li> <code>werf.io\/set-resources-only-on-creation=true<\/code><\/li>\n<\/ul>\n<p>\nMit einer solchen Annotation wird werf die entsprechenden Werte bei jedem Deployment nicht zur\u00fccksetzen, sondern nur bei der erstmaligen Erstellung der Ressource festlegen.<\/p>\n<p>F\u00fcr weitere Informationen \u2013 siehe die Projektdokumentation zu <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/resources_update_methods_and_adoption.html#deal-with-hpa\">HPA<\/a><\/noindex> und <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/resources_update_methods_and_adoption.html#deal-with-vpa\">VPA<\/a><\/noindex>.<\/p>\n<h3>Vermeiden Sie die Verwendung von 3-Way-Merge-Patches<\/h3>\n<p>\nDer Benutzer kann vorerst die Verwendung neuer Patches in werf \u00fcber die Umgebungsvariable unterbinden <code>WERF_THREE_WAY_MERGE_MODE=disabled<\/code>. Ab dem <b>1. M\u00e4rz 2020 wird dieses Verbot jedoch nicht mehr wirksam sein.<\/b> Und es wird m\u00f6glicherweise nur die Verwendung von 3-Wege-Merge-Patches m\u00f6glich sein.<\/p>\n<h2>Ressourcenenadaption in werf<\/h2>\n<p>\nDie Beherrschung der Methode zur Anwendung von 3-Wege-Merge-Patches hat es uns erm\u00f6glicht, sofort eine Funktion wie die Adoption bestehender Ressourcen im Cluster in Helm-Releases zu implementieren.<\/p>\n<p>Helm 2 hat ein Problem: Es ist nicht m\u00f6glich, eine Ressource, die bereits im Cluster existiert, ohne deren vollst\u00e4ndige Neuerschaffung zu den Chart-Manifests hinzuzuf\u00fcgen (siehe <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/issues\/6031#issuecomment-531579500\">#6031<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/issues\/3275\">#3275<\/a><\/noindex>). Wir haben werf beigebracht, vorhandene Ressourcen in einen Release zu integrieren. Dazu muss eine Anmerkung zur aktuellen Version der Ressource aus dem laufenden Cluster hinzugef\u00fcgt werden (zum Beispiel mithilfe von <code>kubectl edit<\/code>):<\/p>\n<pre><code class=\"plaintext\">\"werf.io\/allow-adoption-by-release\": RELEASE_NAME<\/code><\/pre>\n<p>\nJetzt muss die Ressource im Chart beschrieben werden, und beim n\u00e4chsten Deployment des werf-Releases mit dem entsprechenden Namen wird die bestehende Ressource in diesen Release aufgenommen und unter dessen Verwaltung bleiben. Dar\u00fcber hinaus wird werf beim Prozess der Ressourcenauswahl den aktuellen Zustand der Ressource aus dem laufenden Cluster an den im Chart beschriebenen Zustand anpassen, indem die gleichen 3-Wege-Merge-Patches verwendet werden und die Regel f\u00fcr synchronisierte Ressourcen angewendet wird.<\/p>\n<p><i><b>Hinweis<\/b>: Konfiguration <code>WERF_THREE_WAY_MERGE_MODE<\/code> beeinflusst nicht die Adoption von Ressourcen \u2013 im Falle der Adoption wird immer ein 3-Wege-Merge-Patch verwendet.<\/i><\/p>\n<p>Details \u2013 in <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/resources_update_methods_and_adoption.html#resources-adoption\">Dokumentation.<\/a><\/noindex>.<\/p>\n<h2>Schlussfolgerungen und zuk\u00fcnftige Pl\u00e4ne<\/h2>\n<p>\nIch hoffe, dass nach diesem Artikel klarer geworden ist, was 3-way-merge-Patches sind und warum wir sie eingef\u00fchrt haben. Aus praktischer Sicht hinsichtlich der Weiterentwicklung des Projekts werf stellt ihre Implementierung einen weiteren Schritt zur Verbesserung der Helm-\u00e4hnlichen Bereitstellung dar. Jetzt k\u00f6nnen die Probleme mit der Synchronisierung der Konfiguration, die h\u00e4ufig bei der Verwendung von Helm 2 auftraten, vergessen werden. Zudem wurde eine neue n\u00fctzliche Funktion f\u00fcr die \u00dcbernahme bereits heruntergeladener Kubernetes-Ressourcen in das Helm-Release hinzugef\u00fcgt.<\/p>\n<p>Im Helm-\u00e4hnlichen Bereitstellungsprozess bestehen weiterhin einige Probleme und Herausforderungen, wie die Verwendung von Go-Templates, und wir werden weiterhin daran arbeiten, diese zu l\u00f6sen.<\/p>\n<p>Informationen zu den Methoden zur Aktualisierung von Ressourcen und zur \u00dcbernahme finden Sie auch auf <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/resources_update_methods_and_adoption.html\">dieser Dokumentationsseite<\/a><\/noindex>.<\/p>\n<h3>Helm 3<\/h3>\n<p>\nBesonders erw\u00e4hnenswert ist die <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/news\/t\/475722\/\">vor Kurzem ver\u00f6ffentlichte<\/a><\/noindex> neue Hauptversion von Helm \u2013 v3 \u2013, die ebenfalls 3-way-merge-Patches verwendet und Tiller entfernt. Die neue Helm-Version erfordert <noindex><a rel=\"nofollow\" href=\"https:\/\/helm.sh\/docs\/topics\/v2_v3_migration\/\">eine Migration<\/a><\/noindex> der bereits bestehenden Installationen, um sie in das neue Format der Release-Speicherung zu konvertieren.<\/p>\n<p>Werf hat seinerseits bereits die Verwendung von Tiller eingestellt, ist auf 3-way-merge umgestiegen und hat hinzugef\u00fcgt <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/differences_with_helm.html\">und vieles mehr<\/a><\/noindex>, w\u00e4hrend es mit bestehenden Installationen von Helm 2 kompatibel bleibt (es sind keine Migrationsskripte erforderlich). Daher verlieren Benutzer von werf, solange es nicht auf Helm 3 umgestellt wird, nicht die wesentlichen Vorteile von Helm 3 gegen\u00fcber Helm 2 (diese sind auch in werf vorhanden).<\/p>\n<p>Dennoch ist der Wechsel von werf zur Codebasis von Helm 3 unvermeidlich und wird in naher Zukunft stattfinden. Voraussichtlich wird dies in werf 1.1 oder werf 1.2 geschehen (derzeit ist die Hauptversion von werf 1.0; weitere Informationen zur Versionsstruktur von werf finden Sie in <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">hier<\/a><\/noindex>). In der Zwischenzeit wird Helm 3 stabiler werden.<\/p>\n<h2>P.S.<\/h2>\n<p>\nLesen Sie auch in unserem Blog:<\/p>\n<ul>\n<li> Notizen zu den Neuerungen in werf:\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">Die Verwendung von werf zur Bereitstellung komplexer Helm-Charts<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Unterst\u00fctzung von Monorepo und Multirepo im Werfer und was Docker Registry damit zu tun hat.<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Docker-Images k\u00f6nnen jetzt auch in werf aus einer normalen Dockerfile gesammelt werden<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">werf \u2014 unser Tool f\u00fcr CI\/CD in Kubernetes (\u00dcbersicht und Video des Vortrags)<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/469541\/\">Der Aufbau und das Deployment \u00e4hnlicher Mikrodienste mit werf und GitLab CI<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/453734\/\">Einf\u00fchrung in Helm 3<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/476646\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0421\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c \u0442\u043e, \u0447\u0435\u0433\u043e \u043c\u044b (\u0438 \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u043c\u044b) \u0434\u043e\u043b\u0433\u043e \u0436\u0434\u0430\u043b\u0438: werf, \u043d\u0430\u0448\u0430 Open Source-\u0443\u0442\u0438\u043b\u0438\u0442\u0430 \u0434\u043b\u044f \u0441\u0431\u043e\u0440\u043a\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0438 \u0438\u0445 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u0432 Kubernetes, \u0442\u0435\u043f\u0435\u0440\u044c \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e 3-way-merge-\u043f\u0430\u0442\u0447\u0435\u0439! \u0412 \u0434\u043e\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u0435 \u043a \u044d\u0442\u043e\u043c\u0443, \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c adoption\u2019\u0430 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 K8s-\u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432 \u0432 Helm-\u0440\u0435\u043b\u0438\u0437\u044b \u0431\u0435\u0437 \u043f\u0435\u0440\u0435\u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u044d\u0442\u0438\u0445 \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432. \u0415\u0441\u043b\u0438 \u0441\u043e\u0432\u0441\u0435\u043c \u043a\u043e\u0440\u043e\u0442\u043a\u043e, \u0442\u043e \u0441\u0442\u0430\u0432\u0438\u043c WERF_THREE_WAY_MERGE=enabled \u2014 \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u043c \u0434\u0435\u043f\u043b\u043e\u0439 \u00ab\u043a\u0430\u043a \u0432 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":53121,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-53120","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0421\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c \u0442\u043e, \u0447\u0435\u0433\u043e \u043c\u044b (\u0438 \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u043c\u044b) \u0434\u043e\u043b\u0433\u043e \u0436\u0434\u0430\u043b\u0438: werf, \u043d\u0430\u0448\u0430 Open Source-\u0443\u0442\u0438\u043b\u0438\u0442\u0430 \u0434\u043b\u044f \u0441\u0431\u043e\u0440\u043a\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0438 \u0438\u0445 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u0432 Kubernetes, \u0442\u0435\u043f\u0435\u0440\u044c \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e 3-way-merge-\u043f\u0430\u0442\u0447\u0435\u0439! \u0412 \u0434\u043e\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u0435 \u043a \u044d\u0442\u043e\u043c\u0443, \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c adoption\u2019\u0430 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 K8s-\u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432 \u0432 Helm-\u0440\u0435\u043b\u0438\u0437\u044b \u0431\u0435\u0437 \u043f\u0435\u0440\u0435\u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u044d\u0442\u0438\u0445 \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432. \u0415\u0441\u043b\u0438 \u0441\u043e\u0432\u0441\u0435\u043c \u043a\u043e\u0440\u043e\u0442\u043a\u043e, \u0442\u043e \u0441\u0442\u0430\u0432\u0438\u043c WERF_THREE_WAY_MERGE=enabled \u2014 \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u043c \u0434\u0435\u043f\u043b\u043e\u0439 \u00ab\u043a\u0430\u043a \u0432\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/3-way-merge-v-werf-deploj-v-kubernetes-s-helm-na-steroidah\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"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\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd473-way merge \u0432 werf: \u0434\u0435\u043f\u043b\u043e\u0439 \u0432 Kubernetes \u0441 Helm \u00ab\u043d\u0430 \u0441\u0442\u0435\u0440\u043e\u0438\u0434\u0430\u0445\u00bb | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0421\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c \u0442\u043e, \u0447\u0435\u0433\u043e \u043c\u044b (\u0438 \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u043c\u044b) \u0434\u043e\u043b\u0433\u043e \u0436\u0434\u0430\u043b\u0438: werf, \u043d\u0430\u0448\u0430 Open Source-\u0443\u0442\u0438\u043b\u0438\u0442\u0430 \u0434\u043b\u044f \u0441\u0431\u043e\u0440\u043a\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0438 \u0438\u0445 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u0432 Kubernetes, \u0442\u0435\u043f\u0435\u0440\u044c \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e 3-way-merge-\u043f\u0430\u0442\u0447\u0435\u0439! \u0412 \u0434\u043e\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u0435 \u043a \u044d\u0442\u043e\u043c\u0443, \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c adoption\u2019\u0430 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 K8s-\u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432 \u0432 Helm-\u0440\u0435\u043b\u0438\u0437\u044b \u0431\u0435\u0437 \u043f\u0435\u0440\u0435\u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u044d\u0442\u0438\u0445 \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432. \u0415\u0441\u043b\u0438 \u0441\u043e\u0432\u0441\u0435\u043c \u043a\u043e\u0440\u043e\u0442\u043a\u043e, \u0442\u043e \u0441\u0442\u0430\u0432\u0438\u043c WERF_THREE_WAY_MERGE=enabled \u2014 \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u043c \u0434\u0435\u043f\u043b\u043e\u0439 \u00ab\u043a\u0430\u043a \u0432\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/3-way-merge-v-werf-deploj-v-kubernetes-s-helm-na-steroidah\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-11-23T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:00:59+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd473-way Merge in werf: Deployment in Kubernetes mit Helm \"auf Steroiden\" | ProHoster","description":"Es ist geschehen, wonach wir (und nicht nur wir) lange gewartet haben: werf, unser Open Source-Tool f\u00fcr das Erstellen von Anwendungen und deren Bereitstellung in Kubernetes, unterst\u00fctzt jetzt die Anwendung von \u00c4nderungen mit 3-way-merge-Patches! Dar\u00fcber hinaus k\u00f6nnen bestehende K8s-Ressourcen ohne deren Neuschaffung in Helm-Releases implementiert werden. Kurz gesagt, setzen Sie WERF_THREE_WAY_MERGE=enabled \u2013 und Sie erhalten Deployments \"wie in\"","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/3-way-merge-v-werf-deploj-v-kubernetes-s-helm-na-steroidah","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\udd473-way merge \u0432 werf: \u0434\u0435\u043f\u043b\u043e\u0439 \u0432 Kubernetes \u0441 Helm \u00ab\u043d\u0430 \u0441\u0442\u0435\u0440\u043e\u0438\u0434\u0430\u0445\u00bb | ProHoster","og:description":"\u0421\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c \u0442\u043e, \u0447\u0435\u0433\u043e \u043c\u044b (\u0438 \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u043c\u044b) \u0434\u043e\u043b\u0433\u043e \u0436\u0434\u0430\u043b\u0438: werf, \u043d\u0430\u0448\u0430 Open Source-\u0443\u0442\u0438\u043b\u0438\u0442\u0430 \u0434\u043b\u044f \u0441\u0431\u043e\u0440\u043a\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0438 \u0438\u0445 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u0432 Kubernetes, \u0442\u0435\u043f\u0435\u0440\u044c \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e 3-way-merge-\u043f\u0430\u0442\u0447\u0435\u0439! \u0412 \u0434\u043e\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u0435 \u043a \u044d\u0442\u043e\u043c\u0443, \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c adoption\u2019\u0430 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 K8s-\u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432 \u0432 Helm-\u0440\u0435\u043b\u0438\u0437\u044b \u0431\u0435\u0437 \u043f\u0435\u0440\u0435\u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u044d\u0442\u0438\u0445 \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432. \u0415\u0441\u043b\u0438 \u0441\u043e\u0432\u0441\u0435\u043c \u043a\u043e\u0440\u043e\u0442\u043a\u043e, \u0442\u043e \u0441\u0442\u0430\u0432\u0438\u043c WERF_THREE_WAY_MERGE=enabled \u2014 \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u043c \u0434\u0435\u043f\u043b\u043e\u0439 \u00ab\u043a\u0430\u043a \u0432","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/3-way-merge-v-werf-deploj-v-kubernetes-s-helm-na-steroidah","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-11-23T21:00:00+00:00","article:modified_time":"2020-02-18T11:00:59+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"53120","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-01-24 06:11:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:31:28","updated":"2026-01-24 06:11:19"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/53120","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=53120"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/53120\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/53121"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=53120"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=53120"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=53120"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}