{"id":76764,"date":"2020-04-04T13:42:24","date_gmt":"2020-04-04T11:42:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee"},"modified":"2020-04-04T13:42:24","modified_gmt":"2020-04-04T11:42:24","slug":"reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","title":{"rendered":"Release von werf 1.1: Verbesserungen im Assembler heute und Pl\u00e4ne f\u00fcr die Zukunft","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Release von werf 1.1: Verbesserungen im Assembler heute und Pl\u00e4ne f\u00fcr die Zukunft\" src=\"\/wp-content\/uploads\/2020\/04\/c7c26e4a0b7bddb90ba087a4db7175dc.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/\">werf<\/a><\/noindex> \u2014 unser Open-Source GitOps CLI-Tool zum Erstellen und Bereitstellen von Anwendungen in Kubernetes. Wie versprochen, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">wurde die Version v1.0<\/a><\/noindex> zum Beginn der Einf\u00fchrung neuer Funktionen in werf und der \u00dcberarbeitung gewohnter Ans\u00e4tze. Nun freuen wir uns, das Release v1.1 vorzustellen, das einen gro\u00dfen Schritt in der Entwicklung darstellt und die Grundlage f\u00fcr die Zukunft legt. <i>Builder<\/i> werf. Die Version ist derzeit verf\u00fcgbar auf <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">dem Kanal 1.1 ea<\/a><\/noindex>.<\/p>\n<p>Die Grundlage des Releases ist die neue Architektur des Stages-Speichers und die Optimierung der Arbeit beider Builder (f\u00fcr Stapel und Dockerfile). Die neue Architektur des Speichers er\u00f6ffnet die M\u00f6glichkeit, verteilte Builds von mehreren Hosts und parallele Builds auf einem Host zu realisieren.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Die Optimierung umfasst die Beseitigung \u00fcberfl\u00fcssiger Berechnungen w\u00e4hrend der Berechnung der Stages-Signaturen sowie \u00c4nderungen in den Mechanismen zur Berechnung von Pr\u00fcfziffern f\u00fcr Dateien auf effizientere Weise. Diese Optimierung verringert die durchschnittliche Bauzeit eines Projekts mit werf. Und leere Builds, bei denen alle Stufen im Cache vorhanden sind <i>stages-storage<\/i>, sind jetzt wirklich schnell. In den meisten F\u00e4llen wird der erneute Start eines Builds schneller als in 1 Sekunde erfolgen! Dies gilt auch f\u00fcr die Validierungsverfahren der Stufen w\u00e4hrend der Arbeit mit den Teams. <code>werf deploy<\/code> und <code>werf run<\/code>.<\/p>\n<p>In dieser Version wurde auch eine Strategie zur Tagging von Images nach Inhalt eingef\u00fchrt \u2014 <i>content-based tagging<\/i>, die nun standardm\u00e4\u00dfig aktiviert ist und die einzige empfohlene Methode ist.<\/p>\n<p>Lassen Sie uns die wichtigsten Neuerungen in werf v1.1 im Detail betrachten und gleichzeitig \u00fcber die Pl\u00e4ne f\u00fcr die Zukunft sprechen.<\/p>\n<h2>Was hat sich in werf v1.1 ge\u00e4ndert?<\/h2>\n<p><\/p>\n<h3>Neues Namensformat f\u00fcr Stufen und Algorithmus zur Auswahl von Stufen aus dem Cache<\/h3>\n<p>\nNeue Regel zur Generierung des Stufen-Namens. Nun generiert jede Build-Stufe einen einzigartigen Stufen-Namen, der aus 2 Teilen besteht: einer Signatur (wie in v1.0) plus einer einzigartigen zeitlichen Kennung.<\/p>\n<p>Zum Beispiel k\u00f6nnte der vollst\u00e4ndige Name des Stufen-Images so aussehen:<\/p>\n<p><code>werf-stages-storage\/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835<\/code><\/p>\n<p>\u2026 oder im allgemeinen Format:<\/p>\n<p><code>werf-stages-storage\/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC<\/code><\/p>\n<p>Hier:<\/p>\n<ul>\n<li> <code>SIGNATURE<\/code> \u2014 ist die Signatur der Stufe, die den Inhalt der Stufe identifiziert und von der Geschichte der \u00c4nderungen in Git abh\u00e4ngt, die zu diesem Inhalt gef\u00fchrt haben;<\/li>\n<li> <code>TIMESTAMP_MILLISEC<\/code> \u2014 ist ein garantiert einzigartiger Kennzeichner des Images, der zum Zeitpunkt des Builds eines neuen Images generiert wird.<\/li>\n<\/ul>\n<p>\nDer Algorithmus zur Auswahl von Stufen aus dem Cache basiert auf der \u00dcberpr\u00fcfung der Verwandtschaft von Git-Commits:<\/p>\n<ol>\n<li> Werf berechnet die Signatur einer bestimmten Phase.<\/li>\n<li> Im <i>stages-storage<\/i> Es kann mehrere Phasen mit dieser Signatur geben. Werf w\u00e4hlt alle passenden Phasen basierend auf der Signatur aus.<\/li>\n<li> Wenn die aktuelle Phase mit Git verbunden ist (git-archive, benutzerdefinierte Phase mit Git-Patches: <code>install<\/code>, <code>beforeSetup<\/code>, <code>setup<\/code>; oder git-latest-patch), w\u00e4hlt werf nur die Phasen aus, die mit dem Commit verbunden sind, der dem aktuellen Commit (f\u00fcr den der Build aufgerufen wurde) vorangeht.<\/li>\n<li> Von den verbleibenden passenden Phasen wird eine ausgew\u00e4hlt \u2013 die \u00e4lteste basierend auf dem Erstellungsdatum.<\/li>\n<\/ol>\n<p>\nEine Phase kann f\u00fcr verschiedene Git-Zweige dieselbe Signatur besitzen. Aber werf wird die Verwendung des Caches, der mit verschiedenen Zweigen verbunden ist, zwischen diesen Zweigen verhindern, selbst wenn die Signaturen \u00fcbereinstimmen.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/reference\/stages_and_images.html#%D0%B8%D0%BC%D0%B5%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D1%81%D1%82%D0%B0%D0%B4%D0%B8%D0%B9\">\u2192 Dokumentation<\/a><\/noindex>.<\/p>\n<h3>Neuer Algorithmus zur Erstellung und Speicherung von Phasen im Phasen-Repository<\/h3>\n<p>\nWenn beim Abrufen von Phasen aus dem Cache werf keine passende Phase findet, wird der Prozess zum Erstellen einer neuen Phase eingeleitet.<\/p>\n<p>Es ist zu beachten, dass mehrere Prozesse (auf einem oder mehreren Hosts) mit dem Erstellen derselben Phase nahezu gleichzeitig beginnen k\u00f6nnen. Werf verwendet einen Algorithmus f\u00fcr optimistische Sperrung <i>stages-storage<\/i> zum Zeitpunkt der Speicherung des frisch erstellten Images in <i>stages-storage<\/i>. Dadurch wird sichergestellt, dass, wenn die Erstellung einer neuen Phase abgeschlossen ist, werf <i>stages-storage<\/i> sperrt und das frisch erstellte Image dort nur speichert, wenn dort bereits kein passendes Image existiert <i>(basierend auf Signatur und anderen Parametern \u2013 siehe neuer Algorithmus zum Abrufen von Phasen aus dem Cache)<\/i>.<\/p>\n<p>Das frisch erstellte Image wird garantiert eine eindeutige ID basierend auf <code>TIMESTAMP_MILLISEC<\/code> <i>(siehe neues Namensschema f\u00fcr Phasen)<\/i>. Falls in <i>stages-storage<\/i> ein passendes Image gefunden wird, wird werf das frisch erstellte Image verwerfen und das Image aus dem Cache verwenden.<\/p>\n<p>Mit anderen Worten: Der erste Prozess, der die Erstellung des Images abschlie\u00dft (der schnellste), erh\u00e4lt das Recht, es im stages-storage zu speichern (und nur dieses eine Image wird dann f\u00fcr alle Builds verwendet). Ein langsamerer Erstellungsprozess wird niemals den schnelleren Prozess daran hindern, die Ergebnisse der Erstellung der aktuellen Phase zu speichern und mit der Erstellung der n\u00e4chsten Phase fortzufahren.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/reference\/stages_and_images.html#%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0-%D0%B8-%D1%81%D0%BE%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81%D1%82%D0%B0%D0%B4%D0%B8%D0%B9\">\u2192 Dokumentation<\/a><\/noindex>.<\/p>\n<h3>Verbesserte Leistung des Dockerfile-Builders<\/h3>\n<p>\nDerzeit besteht die Pipeline der Phasen f\u00fcr das aus Dockerfile erstellte Image aus einer Phase \u2013 <code>dockerfile<\/code>. Bei der Berechnung der Signatur wird die Pr\u00fcfziffer der Dateien ber\u00fccksichtigt. <code>context<\/code>, die bei der Erstellung verwendet werden. Vor dieser Verbesserung durchlief werf rekursiv alle Dateien und erhielt eine Pr\u00fcfziffer, indem der Kontext und der Mod von jeder Datei summiert wurden. Ab Version v1.1 kann werf die berechneten Pr\u00fcfziffern verwenden, die im Git-Repository gespeichert sind.<\/p>\n<p>Die Grundlage des Algorithmus bildet <noindex><a rel=\"nofollow\" href=\"https:\/\/git-scm.com\/docs\/git-ls-tree\">git ls-tree<\/a><\/noindex>. Der Algorithmus ber\u00fccksichtigt Eintr\u00e4ge in <code>.dockerignore<\/code> und durchl\u00e4uft rekursiv den Dateibaum nur bei Bedarf. Somit sind wir von der Dateisystemabfrage entkoppelt, und die Abh\u00e4ngigkeit des Algorithmus von der Gr\u00f6\u00dfe <code>context<\/code> ist nicht erheblich.<\/p>\n<p>Der Algorithmus \u00fcberpr\u00fcft auch untracked Dateien und ber\u00fccksichtigt sie bei Bedarf in der Pr\u00fcfziffer.<\/p>\n<h3>Die Leistungsf\u00e4higkeit beim Import von Dateien wurde verbessert<\/h3>\n<p>\nIn den Versionen von werf v1.1 wird beim <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/configuration\/stapel_image\/import_directive.html\">Import von Dateien aus Artefakten und Images ein rsync-Server verwendet.<\/a><\/noindex>Fr\u00fcher wurde der Import in zwei Schritten unter Verwendung der Verzeichnismontage aus dem Host-System durchgef\u00fchrt.<\/p>\n<p>Die Importgeschwindigkeit in macOS ist nicht mehr durch Docker-Volumes begrenzt, und die Importe werden in der gleichen Zeit wie in Linux und Windows durchgef\u00fchrt.<\/p>\n<h3>Inhaltsbasiertes Tagging<\/h3>\n<p>\nWerf v1.1 unterst\u00fctzt das sogenannte Tagging nach dem Inhalt des Images \u2014 <i>content-based tagging<\/i>. Die Tags der resultierenden Docker-Images h\u00e4ngen vom Inhalt dieser Images ab.<\/p>\n<p>Beim Ausf\u00fchren des Befehls <code>werf publish --tags-by-stages-signature<\/code> oder <code>werf ci-env --tagging-strategy=stages-signature<\/code> werden die ver\u00f6ffentlichten Images mit der sogenannten <b>Stufen-Signatur<\/b> des Images getaggt. Jedes Image wird mit seiner eigenen Stufen-Signatur dieses Images getaggt, die nach den gleichen Regeln berechnet wird wie die regul\u00e4re Signatur jeder Stufe einzeln, jedoch ein zusammenfassender Identifikator des Images ist.<\/p>\n<p>Die Stufen-Signatur des Images h\u00e4ngt ab von:<\/p>\n<ol>\n<li> dem Inhalt dieses Images;<\/li>\n<li> der Historie der \u00c4nderungen in Git, die zu diesem Inhalt gef\u00fchrt haben.<\/li>\n<\/ol>\n<p>\nIm Git-Repository gibt es immer leere Commits, die den Inhalt der Dateien im Image nicht ver\u00e4ndern. Zum Beispiel Commits, die nur Kommentare enthalten oder Merge-Commits, oder Commits, die Dateien in Git \u00e4ndern, die nicht in das Image importiert werden.<\/p>\n<p>Durch die Verwendung von content-based tagging werden Probleme mit unn\u00f6tigen Neustarts von Anwendungspods in Kubernetes aufgrund von \u00c4nderungen am Bildnamen gel\u00f6st, selbst wenn sich der Inhalt des Bildes nicht ge\u00e4ndert hat. \u00dcbrigens ist dies einer der Gr\u00fcnde, warum es schwierig ist, viele Mikrodienste einer Anwendung in einem einzigen Git-Repository zu speichern.<\/p>\n<p>Zudem ist content-based tagging eine zuverl\u00e4ssigere Methode des Taggings als das Tagging nach Git-Zweigen, da der Inhalt der resultierenden Bilder nicht von der Ausf\u00fchrungsreihenfolge der Pipelines im CI-System f\u00fcr mehrere Commits des gleichen Zweigs abh\u00e4ngt.<\/p>\n<p><b>Wichtig<\/b>: ab diesem Zeitpunkt <i>stages-signature<\/i> sind <b>die einzige empfohlene Tagging-Strategie<\/b>. Genau diese wird standardm\u00e4\u00dfig im Team verwendet <code>werf ci-env<\/code> (sofern nicht ausdr\u00fccklich ein anderes Tagging-Schema angegeben wird).<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/reference\/publish_process.html#%D1%82%D0%B5%D0%B3%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BE%D0%B2-%D0%BF%D0%BE-%D1%81%D0%BE%D0%B4%D0%B5%D1%80%D0%B6%D0%B8%D0%BC%D0%BE%D0%BC%D1%83\">\u2192 Dokumentation<\/a><\/noindex>. Dieser Funktion wird auch ein separater Beitrag gewidmet sein. <b>AKTUALISIERT<\/b> (3. April): Artikel mit Details <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/495112\/\">wurde ver\u00f6ffentlicht<\/a><\/noindex>.<\/p>\n<h3>Logging-Ebenen<\/h3>\n<p>\nDer Benutzer hat die M\u00f6glichkeit, die Ausgabe zu kontrollieren, das Log-Level festzulegen und mit Debug-Informationen zu arbeiten. Es wurden Optionen hinzugef\u00fcgt <code>--log-quiet<\/code>, <code>--log-verbose<\/code>, <code>--log-debug<\/code>.<\/p>\n<p>Standardm\u00e4\u00dfig enth\u00e4lt die Ausgabe minimale Informationen:<\/p>\n<p><img decoding=\"async\" alt=\"Release von werf 1.1: Verbesserungen im Assembler heute und Pl\u00e4ne f\u00fcr die Zukunft\" src=\"\/wp-content\/uploads\/2020\/04\/58e981b2e0c579ddde817eadc1732874.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDurch die Verwendung der detaillierten Ausgabe (<code>--log-verbose<\/code>) kann nachvollzogen werden, wie werf funktioniert:<\/p>\n<p><img decoding=\"async\" alt=\"Release von werf 1.1: Verbesserungen im Assembler heute und Pl\u00e4ne f\u00fcr die Zukunft\" src=\"\/wp-content\/uploads\/2020\/04\/487ed5dfc5df0178f7c09f8da697ceff.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDetaillierte Ausgabe (<code>--log-debug<\/code>) enth\u00e4lt neben Debug-Informationen von werf auch die Logs der verwendeten Bibliotheken. Zum Beispiel kann man sehen, wie die Interaktion mit dem Docker Registry abl\u00e4uft, sowie Stellen protokollieren, an denen erheblich Zeit aufgebracht wird:<\/p>\n<p><img decoding=\"async\" alt=\"Release von werf 1.1: Verbesserungen im Assembler heute und Pl\u00e4ne f\u00fcr die Zukunft\" src=\"\/wp-content\/uploads\/2020\/04\/99c1f3c2ab3803ff11fae1f2d5c9a5af.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Zukunftspl\u00e4ne<\/h2>\n<p>\n<b>Achtung!<\/b> Die nachfolgend beschriebenen Funktionen mit dem Hinweis <b>v1.1<\/b> werden bereits in dieser Version verf\u00fcgbar sein, viele von ihnen \u2013 in naher Zukunft. Aktualisierungen erfolgen \u00fcber Auto-Updates <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/guides\/installation.html#%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1-1-%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D1%83%D0%B5%D0%BC%D1%8B%D0%B9-multiwerf\">bei Verwendung von multiwerf<\/a><\/noindex>. Diese Funktionen betreffen nicht den stabilen Teil der Funktionen von v1.1, deren Einf\u00fchrung erfordert kein manuelles Eingreifen des Benutzers in bestehende Konfigurationen.<\/p>\n<h3>Vollst\u00e4ndige Unterst\u00fctzung verschiedener Implementierungen von Docker Registry (NEU)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.1<\/i><\/li>\n<li> <i>Zeitrahmen: M\u00e4rz<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2199\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nZiel \u2013 der Benutzer soll beliebige Implementierungen ohne Einschr\u00e4nkungen bei der Verwendung von werf nutzen k\u00f6nnen. <\/p>\n<p>Derzeit haben wir die folgende L\u00f6sungssatz ausgew\u00e4hlt, f\u00fcr den wir vollst\u00e4ndige Unterst\u00fctzung garantieren:<\/p>\n<ul>\n<li> Default (library\/registry)*,<\/li>\n<li> AWS ECR,<\/li>\n<li> Azure*,<\/li>\n<li> Docker Hub,<\/li>\n<li> GCR*,<\/li>\n<li> GitHub Packages,<\/li>\n<li> GitLab Registry*,<\/li>\n<li> Harbor*,<\/li>\n<li> Quay.<\/li>\n<\/ul>\n<p>\nMit einem Sternchen gekennzeichnete L\u00f6sungen werden derzeit bereits vollst\u00e4ndig von werf unterst\u00fctzt. F\u00fcr die \u00fcbrigen gibt es Unterst\u00fctzung, jedoch mit Einschr\u00e4nkungen.<\/p>\n<p>Es gibt zwei Hauptprobleme zu beachten:<\/p>\n<ul>\n<li> Einige L\u00f6sungen unterst\u00fctzen nicht das L\u00f6schen von Tags \u00fcber die Docker Registry API, was es den Benutzern nicht erm\u00f6glicht, die in werf implementierte automatische Bereinigung zu nutzen. Dies trifft auf AWS ECR, Docker Hub und GitHub Packages zu.<\/li>\n<li> Einige L\u00f6sungen unterst\u00fctzen die sogenannten verschachtelten Repositories (Docker Hub, GitHub Packages und Quay) nicht oder unterst\u00fctzen sie nur, wenn der Benutzer sie manuell \u00fcber die UI oder API (AWS ECR) erstellt.<\/li>\n<\/ul>\n<p>\nDiese und weitere Probleme m\u00f6chten wir mithilfe der nativen APIs der L\u00f6sungen angehen. Zu dieser Aufgabe geh\u00f6rt auch die Testabdeckung des vollst\u00e4ndigen Arbeitszyklus von werf f\u00fcr jede von ihnen.<\/p>\n<h3>Verteilte Bildbau (\u2191)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.2 v1.1 (die Priorit\u00e4t f\u00fcr die Umsetzung dieser Funktion wurde erh\u00f6ht)<\/i><\/li>\n<li> <i>Zeitraum: M\u00e4rz-April M\u00e4rz<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1614\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nDerzeit k\u00f6nnen werf v1.0 und v1.1 nur auf einem dedizierten Host f\u00fcr das Bauen und Ver\u00f6ffentlichen von Bildern sowie das Bereitstellen von Anwendungen in Kubernetes verwendet werden.<\/p>\n<p>Um die M\u00f6glichkeiten f\u00fcr die verteilte Arbeit von werf zu er\u00f6ffnen, wenn das Bauen und Bereitstellen von Anwendungen in Kubernetes auf mehreren beliebigen Hosts gestartet wird und diese Hosts ihren Zustand zwischen den Builds nicht speichern (tempor\u00e4re Runner), ist von werf die Umsetzung der M\u00f6glichkeit erforderlich, Docker Registry als Speicher f\u00fcr die Stufen zu verwenden.<\/p>\n<p>Fr\u00fcher, als das Projekt werf noch dapp hie\u00df, gab es diese M\u00f6glichkeit. Allerdings sind wir auf eine Reihe von Problemen gesto\u00dfen, die bei der Umsetzung dieser Funktion in werf ber\u00fccksichtigt werden m\u00fcssen.<\/p>\n<p><b>Hinweis<\/b>. Diese M\u00f6glichkeit erfordert nicht, dass der Builder innerhalb von Kubernetes-Pods arbeitet, da es notwendig ist, die Abh\u00e4ngigkeit vom lokalen Docker-Server zu beseitigen (im Kubernetes-Pod gibt es keinen Zugriff auf den lokalen Docker-Server, da der Prozess selbst in einem Container l\u00e4uft und die Arbeit mit dem Docker-Server \u00fcber das Netzwerk von werf nicht unterst\u00fctzt wird und nicht unterst\u00fctzt werden wird). Die Unterst\u00fctzung f\u00fcr die Arbeit in Kubernetes wird separat implementiert.<\/p>\n<h3>Offizielle Unterst\u00fctzung f\u00fcr GitHub Actions (NEU)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.1<\/i><\/li>\n<li> <i>Zeitrahmen: M\u00e4rz<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2210\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nBeinhaltet die Dokumentation von werf (Abschnitte <i>Referenz<\/i> und <i>Leitfaden<\/i>), sowie die offizielle GitHub-Aktion zur Arbeit mit werf.<\/p>\n<p>Dar\u00fcber hinaus wird es werf erm\u00f6glichen, auf ephemeral Runners zu arbeiten.<\/p>\n<p>Die Mechanik der Interaktion des Benutzers mit dem CI-System wird auf der Vergabe von Labels an Pull-Requests basieren, um bestimmte Aktionen beim Bauen\/Deployen der Anwendung zu initiieren.<\/p>\n<h3>Lokale Entwicklung und Bereitstellung von Anwendungen mit werf (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.1<\/i><\/li>\n<li> <i>Zeitraum: Januar-Februar April<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1940\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nDas Hauptziel besteht darin, eine einheitliche, standardisierte Konfiguration f\u00fcr die Bereitstellung von Anwendungen sowohl lokal als auch in der Produktion zu erreichen, ohne komplizierte Schritte, \u201eout of the box\u201c.<\/p>\n<p>Auch werf ben\u00f6tigt einen Betriebsmodus, in dem der Code der Anwendung bequem bearbeitet werden kann und sofortiges Feedback von der laufenden Anwendung f\u00fcr das Debugging bereitgestellt wird.<\/p>\n<h3>Neuer Reinigungsalgorithmus (NEU)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.1<\/i><\/li>\n<li> <i>Fristen: April<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2212\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nIn der aktuellen Version von werf v1.1 ist im Verfahren <code>Bereinigung<\/code> keine Reinigung von Images f\u00fcr das content-based tagging vorgesehen \u2014 diese Images werden sich ansammeln.<\/p>\n<p>In der aktuellen Version von werf (v1.0 und v1.1) werden zudem unterschiedliche Reinigungsrichtlinien f\u00fcr Images verwendet, die nach den Tagging-Schemata ver\u00f6ffentlicht werden: Git-Branch, Git-Tag oder Git-Commit.<\/p>\n<p>Ein neuer einheitlicher Reinigungsalgorithmus f\u00fcr alle Tagging-Schemata wurde auf der Grundlage der Commit-Historie in Git entwickelt:<\/p>\n<ul>\n<li> Es sollen nicht mehr als N1 Images gespeichert werden, die mit den letzten N2 Commits f\u00fcr jedes git HEAD (Branches und Tags) verkn\u00fcpft sind.<\/li>\n<li> Es sollen nicht mehr als N1 Stage-Images gespeichert werden, die mit den letzten N2 Commits f\u00fcr jedes git HEAD (Branches und Tags) verkn\u00fcpft sind.<\/li>\n<li> Alle Bilder, die in Ressourcen des Kubernetes-Clusters verwendet werden, werden gespeichert (alle kube-Kontexte der Konfigurationsdatei sowie Namespaces werden gescannt; dieses Verhalten kann mit speziellen Optionen eingeschr\u00e4nkt werden).<\/li>\n<li> Alle Images, die in den Konfigurationsmanifesten von Ressourcen, die in Helm-Releases gespeichert sind, verwendet werden, sollen gespeichert werden.<\/li>\n<li> Ein Image kann gel\u00f6scht werden, wenn es mit keinem HEAD aus git verkn\u00fcpft ist (zum Beispiel weil der entsprechende HEAD selbst gel\u00f6scht wurde) und in keinem der Manifesten im Kubernetes-Cluster und in den Helm-Releases verwendet wird.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Paralleler Aufbau von Images (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.1<\/i><\/li>\n<li> <i>Fristen: Januar-Februar April*<\/i><\/li>\n<\/ul>\n<p>\nDie aktuelle Version von werf baut die in <code>werf.yaml<\/code>beschriebenen Images und Artefakte nacheinander auf. Es ist notwendig, den Aufbau der unabh\u00e4ngigen Stufen von Images und Artefakten zu parallelisieren und einen benutzerfreundlichen sowie informativen Output zu gew\u00e4hrleisten.<\/p>\n<p><i>* Hinweis: Der Termin wurde aufgrund der Erh\u00f6hung der Priorit\u00e4t f\u00fcr die Implementierung des verteilten Builds verschoben, der mehr M\u00f6glichkeiten f\u00fcr horizontale Skalierung hinzuf\u00fcgen wird, sowie f\u00fcr die Verwendung von werf mit GitHub Actions. Parallelbau ist der n\u00e4chste Schritt in der Optimierung, der vertikale Skalierbarkeit beim Bau eines einzelnen Projekts bietet.<\/i><\/p>\n<h3>Umstellung auf Helm 3 (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.2<\/i><\/li>\n<li> <i>Fristen: Februar-M\u00e4rz Mai*<\/i><\/li>\n<\/ul>\n<p>\nBeinhaltet die Umstellung auf die neue Codebasis <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/news\/t\/475722\/\">Helm 3<\/a><\/noindex> und eine erprobte, benutzerfreundliche Methode zur Migration bestehender Installationen.<\/p>\n<p><i>* Hinweis: Der Umstieg auf Helm 3 bringt keine wesentlichen Vorteile f\u00fcr werf, da alle Schl\u00fcsselmerkmale von Helm 3 (3-way-merge und die Abwesenheit von Tiller) bereits in werf umgesetzt sind. Dar\u00fcber hinaus verf\u00fcgt werf \u00fcber <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/differences_with_helm.html\">zus\u00e4tzliche M\u00f6glichkeiten<\/a><\/noindex> neben den genannten. Dieser Umstieg bleibt jedoch in unseren Pl\u00e4nen und wird umgesetzt werden.<\/i><\/p>\n<h3>Jsonnet zur Beschreibung von Kubernetes-Konfigurationen (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.2<\/i><\/li>\n<li> <i>Fristen: Januar-Februar April-Mai<\/i><\/li>\n<\/ul>\n<p>\nWerf wird die Beschreibung von Konfigurationen f\u00fcr Kubernetes im Jsonnet-Format unterst\u00fctzen. Dabei bleibt werf mit Helm kompatibel und es wird die M\u00f6glichkeit bestehen, das Beschreibungsformat zu w\u00e4hlen.<\/p>\n<p>Der Grund daf\u00fcr ist, dass viele Menschen der Meinung sind, dass die Vorlagen der Go-Sprache eine hohe Einstiegsh\u00fcrde haben und die Verst\u00e4ndlichkeit des Codes dieser Vorlagen ebenfalls leidet.<\/p>\n<p>Es wird auch die M\u00f6glichkeit in Betracht gezogen, andere Systeme zur Beschreibung von Kubernetes-Konfigurationen (z.B. Kustomize) einzuf\u00fchren.<\/p>\n<h3>Arbeiten innerhalb von Kubernetes (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.2<\/i><\/li>\n<li> <i>Fristen: April-Mai Mai-Juni<\/i><\/li>\n<\/ul>\n<p>\nZiel: Gew\u00e4hrleistung des Bauens von Images und der Bereitstellung von Anwendungen unter Verwendung von Runnern in Kubernetes. Das hei\u00dft, der Bau neuer Images, deren Ver\u00f6ffentlichung, Reinigung und Deployment kann direkt aus den Pods von Kubernetes erfolgen.<\/p>\n<p>Um diese M\u00f6glichkeit zu realisieren, ist zuerst die M\u00f6glichkeit des verteilten Bauens von Images erforderlich <i>(vgl. Punkt oben)<\/i>.<\/p>\n<p>Es wird auch Unterst\u00fctzung f\u00fcr den Betrieb des Builders ohne Docker-Server ben\u00f6tigt (d.h. Kaniko-\u00e4hnlicher Build oder Build im Userspace).<\/p>\n<p>Werf wird den Build in Kubernetes nicht nur mit Dockerfile, sondern auch mit seinem Builder Stapel mit inkrementellen Neu-Bauten und Ansible unterst\u00fctzen.<\/p>\n<h2>Ein Schritt in Richtung offene Entwicklung<\/h2>\n<p>\nWir lieben unsere Community (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/werf_ru\">Telegram<\/a><\/noindex>) und m\u00f6chten, dass immer mehr Menschen helfen, werf besser zu machen, verstehen, in welche Richtung wir uns bewegen, und an der Entwicklung teilnehmen.<\/p>\n<p>Vor kurzem wurde beschlossen, auf <noindex><a rel=\"nofollow\" href=\"https:\/\/help.github.com\/en\/github\/managing-your-work-on-github\/about-project-boards\">GitHub-Projektboards<\/a><\/noindex> um den Arbeitsprozess unseres Teams ein wenig transparenter zu gestalten. Momentan k\u00f6nnen die n\u00e4chsten Pl\u00e4ne sowie die laufenden Arbeiten in folgenden Bereichen eingesehen werden:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/9\">Dokumentation und Website<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/7\">Testen<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/6\">Fehler und schlechte UX<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/5\">1.1<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nEs wurde viel Arbeit an Issues geleistet:<\/p>\n<ul>\n<li> Veraltete wurden entfernt.<\/li>\n<li> Bestehende wurden in ein einheitliches Format mit ausreichenden Details und Angaben gebracht.<\/li>\n<li> Neue Issues mit Ideen und Vorschl\u00e4gen wurden hinzugef\u00fcgt.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Wie man Version v1.1 aktiviert<\/h2>\n<p>\nDie Version ist derzeit verf\u00fcgbar in <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">dem Kanal 1.1 ea<\/a><\/noindex> (in den Kan\u00e4len <i>stable<\/i> und <i>rock-solid<\/i> Releases werden erscheinen, sobald sie stabil sind, jedoch <i>ea<\/i> ist bereits von sich aus ausreichend stabil f\u00fcr den Einsatz, da sie durch die Kan\u00e4le getestet wurde. <i>Alpha<\/i> und <i>beta<\/i>). Wird aktiviert <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/guides\/installation.html#%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1-1-%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D1%83%D0%B5%D0%BC%D1%8B%D0%B9-multiwerf\">\u00fcber multiwerf<\/a><\/noindex> auf folgende Weise:<\/p>\n<pre><code class=\"bash\">source $(multiwerf use 1.1 ea)\nwerf COMMAND ...<\/code><\/pre>\n<p><\/p>\n<h2>Fazit<\/h2>\n<p>\nDie neue Architektur der Stufenablage und die Optimierung des Build-Systems f\u00fcr Stapel- und Dockerfile-Builder erm\u00f6glichen verteilte und parallele Builds in werf. Diese Funktionen werden bald im selben Release v1.1 verf\u00fcgbar sein und automatisch \u00fcber den Auto-Update-Mechanismus bereitgestellt (f\u00fcr Benutzer <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/guides\/installation.html#%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1-1-%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D1%83%D0%B5%D0%BC%D1%8B%D0%B9-multiwerf\">multiwerf<\/a><\/noindex>). <\/p>\n<p>In diesem Release wurde eine Inhalts-basierte Tagging-Strategie hinzugef\u00fcgt \u2014 <i>content-based tagging<\/i>, \u2014 die zur Standardstrategie wurde. Auch das Logging der Hauptbefehle wurde \u00fcberarbeitet: <code>werf build<\/code>, <code>werf publish<\/code>, <code>werf deploy<\/code>, <code>werf dismiss<\/code>, <code>werf cleanup<\/code>.<\/p>\n<p>Der n\u00e4chste wichtige Schritt wird die Einf\u00fchrung von verteilten Builds sein. Verteilte Builds sind seit v1.0 eine priorisierte Aufgabe geworden, da sie mehr Wert f\u00fcr werf bieten: vertikale Skalierung der Builder und Unterst\u00fctzung f\u00fcr ephemeral Builders in verschiedenen CI\/CD-Systemen sowie die M\u00f6glichkeit, offizielle Unterst\u00fctzung f\u00fcr GitHub Actions bereitzustellen. Daher wurden die Fristen f\u00fcr die Implementierung paralleler Builds verschoben. Wir arbeiten jedoch daran, beide M\u00f6glichkeiten so schnell wie m\u00f6glich zu realisieren.<\/p>\n<p>Bleiben Sie dran! Und vergessen Sie nicht, uns in <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, zu besuchen, um ein Issue zu erstellen, ein bereits vorhandenes zu finden und zu liken, einen PR zu erstellen oder einfach der Entwicklung des Projekts zuzusehen.<\/p>\n<h2>P.S.<\/h2>\n<p>\nLesen Sie auch in unserem Blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">Wir pr\u00e4sentieren werf 1.0 stable: was hat das mit GitOps, Status und Pl\u00e4nen zu tun?<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">Release des Konsolen-XMPP\/Jabber-Clients profanity 0.7.0<\/a><\/noindex>\u00bb;<\/li>\n<li> Eine Serie von Notizen zu neuen Funktionen in werf:\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/476646\/\">3-Wege-Merge in werf: Deployment in Kubernetes mit Helm \u201eauf Steroiden\u201c<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">Verwendung von werf zum Bereitstellen 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 in werf und was hat das mit Docker Registry zu tun<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Docker-Images in werf k\u00f6nnen jetzt auch mit einem normalen Dockerfile gebaut werden.<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>werf \u2014 \u043d\u0430\u0448\u0430 GitOps CLI-\u0443\u0442\u0438\u043b\u0438\u0442\u0430 \u0441 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u043c \u043a\u043e\u0434\u043e\u043c \u0434\u043b\u044f \u0441\u0431\u043e\u0440\u043a\u0438 \u0438 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0432 Kubernetes. \u041a\u0430\u043a \u0438 \u043e\u0431\u0435\u0449\u0430\u043b\u0438, \u0432\u044b\u0445\u043e\u0434 \u0432\u0435\u0440\u0441\u0438\u0438 v1.0 \u0437\u043d\u0430\u043c\u0435\u043d\u043e\u0432\u0430\u043b \u043d\u0430\u0447\u0430\u043b\u043e \u0434\u043e\u0431\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0432 werf \u043d\u043e\u0432\u044b\u0445 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0435\u0439 \u0438 \u043f\u0435\u0440\u0435\u0441\u043c\u043e\u0442\u0440\u0430 \u043f\u0440\u0438\u0432\u044b\u0447\u043d\u044b\u0445 \u043f\u043e\u0434\u0445\u043e\u0434\u043e\u0432. \u0422\u0435\u043f\u0435\u0440\u044c \u043c\u044b \u0440\u0430\u0434\u044b \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0440\u0435\u043b\u0438\u0437 v1.1, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u0448\u0430\u0433\u043e\u043c \u0432 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0438 \u0438 \u0437\u0430\u0434\u0435\u043b\u043e\u043c \u043d\u0430 \u0431\u0443\u0434\u0443\u0449\u0435\u0435 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0430 werf. \u0412\u0435\u0440\u0441\u0438\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u0430 \u043d\u0430 \u0434\u0430\u043d\u043d\u044b\u0439 \u043c\u043e\u043c\u0435\u043d\u0442 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":76765,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-76764","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\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\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\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\udd47\u0420\u0435\u043b\u0438\u0437 werf 1.1: \u0443\u043b\u0443\u0447\u0448\u0435\u043d\u0438\u044f \u0432 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0435 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0438 \u043f\u043b\u0430\u043d\u044b \u043d\u0430 \u0431\u0443\u0434\u0443\u0449\u0435\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee\" \/>\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=\"2020-04-04T11:42:24+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-04-04T11:42:24+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\udd47Release werf 1.1: Verbesserungen im Builder heute und Pl\u00e4ne f\u00fcr die Zukunft | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","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\u0420\u0435\u043b\u0438\u0437 werf 1.1: \u0443\u043b\u0443\u0447\u0448\u0435\u043d\u0438\u044f \u0432 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0435 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0438 \u043f\u043b\u0430\u043d\u044b \u043d\u0430 \u0431\u0443\u0434\u0443\u0449\u0435\u0435 | ProHoster","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","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-04-04T11:42:24+00:00","article:modified_time":"2020-04-04T11:42:24+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"76764","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 17:30:23","updated":"2022-09-28 14:39:02","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\/76764","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=76764"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/76764\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/76765"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=76764"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=76764"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=76764"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}