{"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 Werfer 1.1: Verbesserungen im heutigen Werfer und Pl\u00e4ne f\u00fcr die Zukunft.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Release von Werfer 1.1: Verbesserungen im heutigen Werfer 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\/\">markierte die Ver\u00f6ffentlichung von Version v1.0<\/a><\/noindex> den Beginn der Einf\u00fchrung neuer Funktionen in werf und einer \u00dcberarbeitung gewohnter Ans\u00e4tze. Jetzt freuen wir uns, die Version v1.1 vorzustellen, die einen bedeutenden Schritt in der Entwicklung darstellt und die Grundlage f\u00fcr die Zukunft bildet. <i>Compiler<\/i> werf. Die Version ist derzeit im <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">Kanal 1.1 ea<\/a><\/noindex>.<\/p>\n<p>verf\u00fcgbar. Die Grundlage dieser Ver\u00f6ffentlichung ist eine neue Architektur f\u00fcr die Stages-Speicherung und eine Optimierung der Funktionsweise beider Compiler (f\u00fcr Stapel und Dockerfile). Die neue Architektur der Speicherung er\u00f6ffnet M\u00f6glichkeiten f\u00fcr verteilte Builds von mehreren Hosts und parallele Builds auf einem Host.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Die Optimierung umfasst die Eliminierung unn\u00f6tiger Berechnungen w\u00e4hrend der Berechnung der Stages-Signaturen und die Umstellung auf effizientere Mechanismen zur Berechnung von Pr\u00fcfziffern f\u00fcr Dateien. Diese Optimierung verringert die durchschnittliche Build-Zeit von Projekten mit werf. Und Leerlauf-Bauten, bei denen alle Stufen im Cache vorhanden sind, <i>stages-storage<\/i>, jetzt wirklich schnell. In den meisten F\u00e4llen wird der Wiederaufbau schneller als in 1 Sekunde abgeschlossen sein! Dies gilt auch f\u00fcr die \u00dcberpr\u00fcfungsverfahren der Phasen w\u00e4hrend der Teamarbeit. <code>werf deploy<\/code> und <code>werf run<\/code>.<\/p>\n<p>In diesem Release wurde zudem eine Strategie zur inhaltsbasierten Tagging von Images eingef\u00fchrt \u2014 <i>inhaltsbasiertes Tagging<\/i>, die jetzt standardm\u00e4\u00dfig aktiviert ist und die einzige empfohlene Methode darstellt.<\/p>\n<p>Lassen Sie uns die wichtigsten Neuerungen in werf v1.1 im Detail betrachten und zugleich \u00fcber zuk\u00fcnftige Pl\u00e4ne sprechen.<\/p>\n<h2>Was hat sich in werf v1.1 ge\u00e4ndert?<\/h2>\n<p><\/p>\n<h3>Ein neues Format zur Benennung von Phasen und ein Algorithmus zur Auswahl von Phasen aus dem Cache<\/h3>\n<p>\nNeue Regel zur Generierung des Phasennamens. Jetzt wird f\u00fcr jede Phasenbuild ein eindeutiger Phasename generiert, der aus zwei Teilen besteht: einer Signatur (wie in v1.0) plus einer einzigartigen Zeitidentifikation.<\/p>\n<p>Zum Beispiel k\u00f6nnte der vollst\u00e4ndige Name des Phasenimages so aussehen:<\/p>\n<p><code>werf-stages-storage\/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835<\/code><\/p>\n<p>\u2026 oder allgemein wie folgt:<\/p>\n<p><code>werf-stages-storage\/PROJEKT:SIGNATUR-ZEITSTEMPEL_MILLISEC<\/code><\/p>\n<p>Hier:<\/p>\n<ul>\n<li> <code>SIGNATUR<\/code> \u2014 dies ist die Signatur der Phase, die den Inhaltsidentifikator der Phase darstellt und von der Geschichte der Bearbeitungen in Git abh\u00e4ngt, die zu diesem Inhalt f\u00fchrten;<\/li>\n<li> <code>ZEITSTEMPEL_MILLISEC<\/code> \u2014 ist eine garantiert eindeutige Identifikation eines Images, die beim Erstellen eines neuen Images generiert wird.<\/li>\n<\/ul>\n<p>\nDer Algorithmus zur Auswahl der Stufen aus dem Cache basiert auf der \u00dcberpr\u00fcfung der Zugeh\u00f6rigkeit von Git-Commits:<\/p>\n<ol>\n<li> Werf berechnet die Signatur einer bestimmten Stufe.<\/li>\n<li> In <i>stages-storage<\/i> Es k\u00f6nnen mehrere Stufen mit dieser Signatur existieren. Werf w\u00e4hlt alle passenden Stufen mit dieser Signatur aus.<\/li>\n<li> Wenn die aktuelle Stufe mit Git verbunden ist (git-archive, benutzerdefinierte Stufe mit Git-Patches: <code>install<\/code>, <code>beforeSetup<\/code>, <code>setup<\/code>; oder git-latest-patch), w\u00e4hlt werf nur die Stufen aus, die mit dem Commit verbunden sind, der der Vorg\u00e4nger des aktuellen Commits ist (f\u00fcr den der Build aufgerufen wird).<\/li>\n<li> Aus den verbleibenden passenden Stufen wird eine ausgew\u00e4hlt \u2013 die \u00e4lteste nach Erstellungsdatum.<\/li>\n<\/ol>\n<p>\nEine Stufe kann f\u00fcr verschiedene Git-Branches die gleiche Signatur haben. Aber werf verhindert die Verwendung von Cache, das mit verschiedenen Branches verbunden ist, zwischen diesen Branches, 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 Stufen im Stufenspeicher<\/h3>\n<p>\nWenn w\u00e4hrend der Auswahl der Stufen aus dem Cache werf keine passende Stufe findet, wird der Prozess zum Erstellen einer neuen Stufe initiiert.<\/p>\n<p>Beachten Sie, dass mehrere Prozesse (auf einem oder mehreren Hosts) zur gleichen Zeit mit dem Zusammenstellen der gleichen Phase beginnen k\u00f6nnen. Werf nutzt einen Algorithmus zur optimistischen Sperrung. <i>stages-storage<\/i> zum Zeitpunkt der Speicherung des neu erstellten Images in <i>stages-storage<\/i>. Somit sperrt Werf, wenn die neue Phase bereit ist, <i>stages-storage<\/i> und speichert das neu erstellte Image nur, wenn dort noch kein passendes Image vorhanden ist. <i>(basierend auf Signature und anderen Parametern \u2013 siehe den neuen Algorithmus zur Auswahl von Phasen aus dem Cache)<\/i>.<\/p>\n<p>Das neu erstellte Image wird garantiert eine eindeutige Kennung haben nach <code>ZEITSTEMPEL_MILLISEC<\/code> <i>(siehe das neue Format zur Benennung der Phasen).<\/i>Falls in <i>stages-storage<\/i> ein passendes Image gefunden wird, verwirft Werf das neu erstellte Image und verwendet das Image aus dem Cache.<\/p>\n<p>Anders gesagt: Der erste Prozess, der das Image fertigstellt (der schnellste), erh\u00e4lt das Recht, es im stages-storage zu speichern (und genau dieses einzige Image wird f\u00fcr alle Builds verwendet). Ein langsamerer Build-Prozess wird niemals einen schnelleren Prozess daran hindern, die Ergebnisse des aktuellen Builds zu speichern und mit dem n\u00e4chsten Build 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>Die Leistung des Dockerfile-Builders wurde verbessert.<\/h3>\n<p>\nDerzeit besteht die Pipeline-Stufen f\u00fcr das aus Dockerfile erstellte Image aus einer einzigen Stufe \u2014 <code>dockerfile<\/code>. Bei der Berechnung der Signatur wird die Pr\u00fcfziffer der Dateien ber\u00fccksichtigt, <code>context<\/code>, die beim Bauen verwendet werden. Vor dieser Verbesserung hat werf rekursiv alle Dateien durchlaufen und die Pr\u00fcfziffer ermittelt, indem er den Kontext und die Modi jeder Datei summierte. Ab Version v1.1 kann werf die berechneten Pr\u00fcfziffern nutzen, die im Git-Repository gespeichert sind.<\/p>\n<p>Der Algorithmus basiert auf <noindex><a rel=\"nofollow\" href=\"https:\/\/git-scm.com\/docs\/git-ls-tree\">git ls-tree<\/a><\/noindex>. Der Algorithmus ber\u00fccksichtigt die Eintr\u00e4ge in <code>.dockerignore<\/code> und durchsucht das Dateibaum nur bei Bedarf rekursiv. Dadurch haben wir uns von der Dateisystemauslesung getrennt, und die Abh\u00e4ngigkeit des Algorithmus von der Gr\u00f6\u00dfe <code>context<\/code> spielt keine wesentliche Rolle.<\/p>\n<p>Der Algorithmus \u00fcberpr\u00fcft auch untracked Dateien und ber\u00fccksichtigt sie bei Bedarf in der Pr\u00fcfziffer.<\/p>\n<h3>Die Leistung beim Importieren von Dateien wurde verbessert.<\/h3>\n<p>\nIn den Versionen von werf v1.1 kommt ein rsync-Server zum Einsatz 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.<\/a><\/noindex>Zuvor wurde der Import in zwei Schritten unter Verwendung der Montageverzeichnisse aus dem Hosts-System durchgef\u00fchrt.<\/p>\n<p>Die Importleistung in macOS ist nicht mehr auf Docker-Volumes beschr\u00e4nkt, und die Importe erfolgen jetzt in der gleichen Zeit wie unter Linux und Windows.<\/p>\n<h3>Inhaltsbasiertes Tagging<\/h3>\n<p>\nWerf v1.1 unterst\u00fctzt das sogenannte Tagging nach Inhaltsbasis des Images \u2014 <i>inhaltsbasiertes 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> die ver\u00f6ffentlichten Images werden mit dem sogenannten <b>Stadien-Signatur<\/b> des Images. Jedes Image wird mit seiner eigenen Stadien-Signatur dieses Images getaggt, die nach denselben Regeln berechnet wird wie die regul\u00e4re Signatur jeder einzelnen Phase, aber als aggregierender Identifier des Images dient.<\/p>\n<p>Die Stadien-Signatur eines Images h\u00e4ngt ab von:<\/p>\n<ol>\n<li> dem Inhalt dieses Images;<\/li>\n<li> der Geschichte 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 Image-Dateien nicht \u00e4ndern. Zum Beispiel Commits nur mit Kommentaren oder Merge-Commits, oder Commits, die die Dateien in Git \u00e4ndern, die nicht in das Image importiert werden.<\/p>\n<p>\u041f\u0440\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0438 content-based tagging \u0440\u0435\u0448\u0430\u044e\u0442\u0441\u044f \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b \u043b\u0438\u0448\u043d\u0438\u0445 \u043f\u0435\u0440\u0435\u0437\u0430\u043f\u0443\u0441\u043a\u043e\u0432 pod&#8217;\u043e\u0432 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0432 Kubernetes \u0438\u0437-\u0437\u0430 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439 \u0438\u043c\u0435\u043d\u0438 \u043e\u0431\u0440\u0430\u0437\u0430, \u0434\u0430\u0436\u0435 \u0435\u0441\u043b\u0438 \u0441\u043e\u0434\u0435\u0440\u0436\u0438\u043c\u043e\u0435 \u043e\u0431\u0440\u0430\u0437\u0430 \u043d\u0435 \u043f\u043e\u043c\u0435\u043d\u044f\u043b\u043e\u0441\u044c. \u041a\u0441\u0442\u0430\u0442\u0438, \u044d\u0442\u043e \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0434\u043d\u043e\u0439 \u0438\u0437 \u043f\u0440\u0438\u0447\u0438\u043d, \u043c\u0435\u0448\u0430\u044e\u0449\u0438\u0445 \u0445\u0440\u0430\u043d\u0438\u0442\u044c \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0432 \u0435\u0434\u0438\u043d\u043e\u043c Git-\u0440\u0435\u043f\u043e\u0437\u0438\u0442\u043e\u0440\u0438\u0438.<\/p>\n<p>\u0422\u0430\u043a\u0436\u0435 content-based tagging \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u0435\u0435 \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u043c \u043c\u0435\u0442\u043e\u0434\u043e\u043c \u0442\u0435\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f, \u0447\u0435\u043c \u0442\u0435\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043f\u043e Git-\u0432\u0435\u0442\u043a\u0430\u043c, \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u0441\u043e\u0434\u0435\u0440\u0436\u0438\u043c\u043e\u0435 \u0440\u0435\u0437\u0443\u043b\u044c\u0442\u0438\u0440\u0443\u044e\u0449\u0438\u0445 \u043e\u0431\u0440\u0430\u0437\u043e\u0432 \u043d\u0435 \u0437\u0430\u0432\u0438\u0441\u0438\u0442 \u043e\u0442 \u043f\u043e\u0440\u044f\u0434\u043a\u0430 \u0438\u0441\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f pipeline&#8217;\u043e\u0432 \u0432 CI-\u0441\u0438\u0441\u0442\u0435\u043c\u0435 \u0434\u043b\u044f \u0441\u0431\u043e\u0440\u043a\u0438 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u043a\u043e\u043c\u043c\u0438\u0442\u043e\u0432 \u043e\u0434\u043d\u043e\u0439 \u0438 \u0442\u043e\u0439 \u0436\u0435 \u0432\u0435\u0442\u043a\u0438.<\/p>\n<p><b>Wichtig<\/b>: ab jetzt <i>stages-signature<\/i> \u2014 ist <b>die einzig empfohlene Tagging-Strategie<\/b>. Diese wird standardm\u00e4\u00dfig im Befehl <code>werf ci-env<\/code> verwendet (es sei denn, es wird ausdr\u00fccklich ein anderes Tagging-Schema angegeben).<\/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>. Eine separate Ver\u00f6ffentlichung wird dieser Funktion gewidmet sein. <b>AKTUALISIERT<\/b> (3. April): Artikel mit Details <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/495112\/\">ver\u00f6ffentlicht<\/a><\/noindex>.<\/p>\n<h3>Loglevel<\/h3>\n<p>\nBenutzer haben die M\u00f6glichkeit, die Ausgabe zu steuern, den Loglevel zu setzen und mit Debug-Informationen zu arbeiten. Optionen wurden 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 Werfer 1.1: Verbesserungen im heutigen Werfer und Pl\u00e4ne f\u00fcr die Zukunft.\" src=\"\/wp-content\/uploads\/2020\/04\/58e981b2e0c579ddde817eadc1732874.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBei Verwendung der detaillierten Ausgabe (<code>--log-verbose<\/code>) kann nachvollzogen werden, wie werf funktioniert:<\/p>\n<p><img decoding=\"async\" alt=\"Release von Werfer 1.1: Verbesserungen im heutigen Werfer und Pl\u00e4ne f\u00fcr die Zukunft.\" src=\"\/wp-content\/uploads\/2020\/04\/487ed5dfc5df0178f7c09f8da697ceff.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie detaillierte Ausgabe (<code>--log-debug<\/code>), neben den Debug-Informationen von werf, enth\u00e4lt auch die Protokolle der verwendeten Bibliotheken. Zum Beispiel kann man sehen, wie die Interaktion mit dem Docker Registry erfolgt, sowie die Stellen festhalten, an denen erhebliche Zeit verbraucht wird:<\/p>\n<p><img decoding=\"async\" alt=\"Release von Werfer 1.1: Verbesserungen im heutigen Werfer 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>Zuk\u00fcnftige Pl\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 in naher Zukunft. Updates werden durch 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 v1.1, ihr Auftreten erfordert keine manuelle Eingreifung des Benutzers in bestehende Konfigurationen.<\/p>\n<h3>Komplette 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>Zeitplan: M\u00e4rz<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2199\">Problem<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nZiel \u2014 der Benutzer soll eine beliebige Implementierung ohne Einschr\u00e4nkungen bei der Verwendung von werf nutzen k\u00f6nnen. <\/p>\n<p>Derzeit haben wir den folgenden Satz von L\u00f6sungen ausgew\u00e4hlt, f\u00fcr die wir vollst\u00e4ndige Unterst\u00fctzung garantieren m\u00f6chten:<\/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 gekennzeichnet sind L\u00f6sungen, die derzeit vollst\u00e4ndig von werf unterst\u00fctzt werden. F\u00fcr die anderen besteht zwar Unterst\u00fctzung, jedoch mit Einschr\u00e4nkungen.<\/p>\n<p>Es gibt zwei Hauptprobleme:<\/p>\n<ul>\n<li> Einige L\u00f6sungen unterst\u00fctzen das Entfernen von Tags \u00fcber die Docker Registry API nicht, was es den Nutzern 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 so genannte Nested Repositories (Docker Hub, GitHub Packages und Quay) nicht oder unterst\u00fctzen sie nur, wenn der Nutzer diese manuell \u00fcber die Benutzeroberfl\u00e4che oder API (AWS ECR) erstellt.<\/li>\n<\/ul>\n<p>\nDiese und weitere Probleme beabsichtigen wir, mit den nativen APIs der L\u00f6sungen zu beheben. Diese Aufgabe umfasst auch das Testen des vollst\u00e4ndigen Arbeitszyklus von werf f\u00fcr jede L\u00f6sung.<\/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 Funktionalit\u00e4t wurde erh\u00f6ht)<\/i><\/li>\n<li> <i>Zeitrahmen: M\u00e4rz-April M\u00e4rz<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1614\">Problem<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nDerzeit kann werf v1.0 und v1.1 nur auf einem dedizierten Host f\u00fcr Build-, Ver\u00f6ffentlichungs- und Anwendungs-Deployment-Betrieb in Kubernetes verwendet werden.<\/p>\n<p>Um die M\u00f6glichkeiten des verteilten Arbeitens mit werf zu er\u00f6ffnen, wenn der Aufbau und das Deployment von Anwendungen in Kubernetes auf mehreren beliebigen Hosts startet und diese Hosts ihren Zustand zwischen den Builds nicht speichern (tempor\u00e4re Runner), ben\u00f6tigt werf die Implementierung der Nutzung eines Docker Registrys als Speicher f\u00fcr Stufen.<\/p>\n<p>Fr\u00fcher, als das Projekt werf noch dapp hie\u00df, gab es diese M\u00f6glichkeit. Wir sind jedoch auf verschiedene Probleme gesto\u00dfen, die bei der Umsetzung dieser Funktion in werf ber\u00fccksichtigt werden m\u00fcssen.<\/p>\n<p><b>Hinweis<\/b>. \u0414\u0430\u043d\u043d\u0430\u044f \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u043d\u0435 \u043f\u0440\u0435\u0434\u043f\u043e\u043b\u0430\u0433\u0430\u0435\u0442 \u0440\u0430\u0431\u043e\u0442\u0443 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0430 \u0432\u043d\u0443\u0442\u0440\u0438 pod&#8217;\u043e\u0432 Kubernetes, \u0442.\u043a. \u0434\u043b\u044f \u044d\u0442\u043e\u0433\u043e \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e \u0438\u0437\u0431\u0430\u0432\u0438\u0442\u044c\u0441\u044f \u043e\u0442 \u0437\u0430\u0432\u0438\u0441\u0438\u043c\u043e\u0441\u0442\u0438 \u043e\u0442 \u043b\u043e\u043a\u0430\u043b\u044c\u043d\u043e\u0433\u043e Docker-\u0441\u0435\u0440\u0432\u0435\u0440\u0430 (\u0432 pod&#8217;\u0435 Kubernetes \u043d\u0435\u0442 \u0434\u043e\u0441\u0442\u0443\u043f\u0430 \u043a \u043b\u043e\u043a\u0430\u043b\u044c\u043d\u043e\u043c\u0443 Docker-\u0441\u0435\u0440\u0432\u0435\u0440\u0443, \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u0441\u0430\u043c \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0437\u0430\u043f\u0443\u0449\u0435\u043d \u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0435, \u0430 \u0440\u0430\u0431\u043e\u0442\u0443 \u0441 Docker-\u0441\u0435\u0440\u0432\u0435\u0440\u043e\u043c \u043f\u043e \u0441\u0435\u0442\u0438 werf \u043d\u0435 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442 \u0438 \u043d\u0435 \u0431\u0443\u0434\u0435\u0442 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0442\u044c). \u041f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0430 \u0440\u0430\u0431\u043e\u0442\u044b \u0432 Kubernetes \u0431\u0443\u0434\u0435\u0442 \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u0430 \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u043e.<\/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>Zeitplan: M\u00e4rz<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2210\">Problem<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nUmfasst die werf-Dokumentation (Abschnitte <i>Referenz<\/i> und <i>guide<\/i>), sowie die offizielle GitHub Action zur Zusammenarbeit mit werf.<\/p>\n<p>\u041a\u0440\u043e\u043c\u0435 \u0442\u043e\u0433\u043e, \u043f\u043e\u0437\u0432\u043e\u043b\u0438\u0442 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c werf \u043d\u0430 \u044d\u0444\u0435\u043c\u0435\u0440\u043d\u044b\u0445 runner&#8217;\u0430\u0445.<\/p>\n<p>\u041c\u0435\u0445\u0430\u043d\u0438\u043a\u0430 \u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044f \u0441 CI-\u0441\u0438\u0441\u0442\u0435\u043c\u043e\u0439 \u0431\u0443\u0434\u0435\u0442 \u043e\u0441\u043d\u043e\u0432\u0430\u043d\u0430 \u043d\u0430 \u0432\u044b\u0441\u0442\u0430\u0432\u043b\u0435\u043d\u0438\u0438 label&#8217;\u043e\u0432 \u043d\u0430 pull-request&#8217;\u044b \u0434\u043b\u044f \u0438\u043d\u0438\u0446\u0438\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0445 \u0434\u0435\u0439\u0441\u0442\u0432\u0438\u0439 \u043f\u043e \u0441\u0431\u043e\u0440\u043a\u0435\/\u0432\u044b\u043a\u0430\u0442\u0443 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f.<\/p>\n<h3>Lokale Entwicklung und Deployment 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\">Problem<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nDas Hauptziel ist es, eine einheitliche, standardisierte Konfiguration f\u00fcr das Deployment von Anwendungen sowohl lokal als auch in der Produktion zu erreichen, ohne komplizierte Aktionen, direkt 'out of the box'.<\/p>\n<p>Von werf wird auch ein Arbeitsmodus gefordert, in dem es bequem ist, den Anwendungscode zu bearbeiten und sofortige R\u00fcckmeldungen von der laufenden Anwendung f\u00fcr das Debugging zu erhalten.<\/p>\n<h3>Neuer Bereinigungsalgorithmus (NEU)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.1<\/i><\/li>\n<li> <i>Zeitraum: April<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2212\">Problem<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nIn der aktuellen Version von werf v1.1 gibt es im Verfahren <code>cleanup<\/code> keine Bereinigung von Images f\u00fcr das content-basierte Tagging \u2014 diese Images werden sich ansammeln.<\/p>\n<p>In der aktuellen Version von werf (v1.0 und v1.1) werden zudem unterschiedliche Bereinigungspolitiken f\u00fcr Images verwendet, die nach Tagging-Schemata ver\u00f6ffentlicht wurden: Git-Branch, Git-Tag oder Git-Commit.<\/p>\n<p>Ein neuer einheitlicher Bereinigungsalgorithmus f\u00fcr alle Tagging-Schemata wurde basierend auf der Historie der Git-Commits entwickelt:<\/p>\n<ul>\n<li> Speichern Sie maximal N1 Images, die mit den letzten N2 Commits f\u00fcr jedes git HEAD (Branches und Tags) verbunden sind.<\/li>\n<li> Speichern Sie maximal N1 Stufen-Images, die mit den letzten N2 Commits f\u00fcr jedes git HEAD (Branches und Tags) verbunden sind.<\/li>\n<li> \u0425\u0440\u0430\u043d\u0438\u0442\u044c \u0432\u0441\u0435 \u043e\u0431\u0440\u0430\u0437\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0442\u0441\u044f \u0432 \u043a\u0430\u043a\u0438\u0445-\u043b\u0438\u0431\u043e \u0440\u0435\u0441\u0443\u0440\u0441\u0430\u0445 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 Kubernetes (\u0441\u043a\u0430\u043d\u0438\u0440\u0443\u044e\u0442\u0441\u044f \u0432\u0441\u0435 kube-\u043a\u043e\u043d\u0442\u0435\u043a\u0441\u0442\u044b \u0444\u0430\u0439\u043b\u0430 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438 \u0438 namespace&#8217;\u044b; \u043c\u043e\u0436\u043d\u043e \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0438\u0442\u044c \u0442\u0430\u043a\u043e\u0435 \u043f\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u044b\u043c\u0438 \u043e\u043f\u0446\u0438\u044f\u043c\u0438).<\/li>\n<li> Speichern Sie alle Images, die in den Konfigurationsmanifesten von Ressourcen gespeichert sind, die in Helm-Releases gespeichert wurden.<\/li>\n<li> Ein Image kann gel\u00f6scht werden, wenn es mit keinem HEAD aus git verbunden ist (z.B. weil das entsprechende HEAD selbst gel\u00f6scht wurde) und in keinem Manifest im Kubernetes-Cluster und in den Helm-Releases verwendet wird.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Paralleles Bauen von Images (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.1<\/i><\/li>\n<li> <i>Zeitr\u00e4ume: 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 sequentiell. Es ist notwendig, den Bauprozess der unabh\u00e4ngigen Stufen von Images und Artefakten zu parallelisieren und einen ansprechenden sowie informativen Output zu gew\u00e4hrleisten.<\/p>\n<p><i>* Hinweis: Der Zeitraum wurde aufgrund der erh\u00f6hten Priorit\u00e4t der Implementierung von verteilten Builds verschoben, die mehr M\u00f6glichkeiten f\u00fcr horizontale Skalierung sowie die Verwendung von werf mit GitHub Actions bieten. Paralleles Bauen ist der n\u00e4chste Schritt der Optimierung, der vertikale Skalierbarkeit beim Bauen eines einzelnen Projekts bietet.<\/i><\/p>\n<h3>\u00dcbergang zu Helm 3 (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.2<\/i><\/li>\n<li> <i>Zeitraum: Februar - M\u00e4rz Mai*<\/i><\/li>\n<\/ul>\n<p>\nUmfasst den \u00dcbergang zu einer neuen Codebasis <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/news\/t\/475722\/\">Helm 3<\/a><\/noindex> und eine erprobte, benutzerfreundliche M\u00f6glichkeit zur Migration bestehender Installationen.<\/p>\n<p><i>* Hinweis: Der Wechsel zu Helm 3 wird keine wesentlichen neuen M\u00f6glichkeiten in werf hinzuf\u00fcgen, da alle Schl\u00fcsselmerkmale von Helm 3 (3-Wege-Merge und kein Tiller) bereits in werf implementiert sind. Dar\u00fcber hinaus hat werf <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. Dennoch bleibt dieser \u00dcbergang in unseren Pl\u00e4nen und wird durchgef\u00fchrt.<\/i><\/p>\n<h3>Jsonnet zur Beschreibung der Kubernetes-Konfiguration (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.2<\/i><\/li>\n<li> <i>Zeitraum: Januar - Februar April - Mai<\/i><\/li>\n<\/ul>\n<p>\nWerf wird die Beschreibung der Konfiguration f\u00fcr Kubernetes im Jsonnet-Format unterst\u00fctzen. Gleichzeitig bleibt werf mit Helm kompatibel und es wird die M\u00f6glichkeit geben, das Format der Beschreibung auszuw\u00e4hlen.<\/p>\n<p>Ein Grund daf\u00fcr ist, dass viele Menschen der Meinung sind, dass die Templates der Programmiersprache Go eine hohe Einstiegsh\u00fcrde aufweisen und die Verst\u00e4ndlichkeit des Codes dieser Templates ebenfalls leidet.<\/p>\n<p>Es wird auch die M\u00f6glichkeit in Betracht gezogen, weitere Konfigurationsbeschreibungs-Systeme f\u00fcr Kubernetes zu implementieren (zum Beispiel Kustomize).<\/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>Zeitrahmen: April-Mai, Mai-Juni<\/i><\/li>\n<\/ul>\n<p>\nZiel: Bereitstellung von Build-Images und 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, wird zun\u00e4chst die M\u00f6glichkeit einer verteilten Image-Bereitstellung ben\u00f6tigt. <i>(siehe Punkt oben)<\/i>.<\/p>\n<p>Au\u00dferdem ist die Unterst\u00fctzung eines Modus erforderlich, der den Builder ohne Docker-Server betreibt (d.h. \u00e4hnlich wie Kaniko oder Build im Userspace).<\/p>\n<p>Werf wird die Build-Option in Kubernetes nicht nur mit Dockerfile, sondern auch mit seinem Builder Stapel unterst\u00fctzen, der inkrementelle Neu-Distributionen und Ansible umfasst.<\/p>\n<h2>Ein Schritt in Richtung Open Source Entwicklung<\/h2>\n<p>\nWir sch\u00e4tzen 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 daran mitwirken, werf besser zu machen, verstehen, in welche Richtung wir gehen, 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 Arbeitsablauf unseres Teams zu \u00f6ffnen. Aktuell k\u00f6nnen Sie die n\u00e4chsten Pl\u00e4ne sowie die laufenden Arbeiten in den folgenden Bereichen einsehen:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/9\">Dokumentation und Site<\/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\">Bugs 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 mit Issues geleistet:<\/p>\n<ul>\n<li> Nicht mehr relevante wurden entfernt.<\/li>\n<li> Vorhandene wurden in ein einheitliches Format mit ausreichenden Details und Informationen gebracht.<\/li>\n<li> Neue Issues mit Ideen und Vorschl\u00e4gen wurden hinzugef\u00fcgt.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Wie Sie die Version v1.1 aktivieren<\/h2>\n<p>\nDie Version ist derzeit verf\u00fcgbar in <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">Kanal 1.1 ea<\/a><\/noindex> (in den Kan\u00e4len <i>\"stable\"<\/i> und <i>rock-solid<\/i> die Releases werden mit der Stabilisierung erscheinen, jedoch <i>\"ea\"<\/i> ist sie bereits stabil genug f\u00fcr den Einsatz, da sie durch die Kan\u00e4le gegangen ist <i>Alpha-Zustand<\/i> und <i>Beta<\/i>). Aktivierung <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 des Staging-Speichers und die Optimierung des Builders f\u00fcr Stapel und Dockerfile-Builder er\u00f6ffnen M\u00f6glichkeiten f\u00fcr verteilte und parallele Builds in werf. Diese M\u00f6glichkeiten werden bald in demselben Release v1.1 verf\u00fcgbar sein und automatisch \u00fcber das Auto-Update-System zug\u00e4nglich gemacht werden (f\u00fcr Benutzer von <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 Tagging-Strategie basierend auf dem Inhalt der Images hinzugef\u00fcgt \u2014 <i>inhaltsbasiertes Tagging<\/i>, \u2014 die zur Standardstrategie geworden ist. Auch das Log 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 wesentliche Schritt wird die Einf\u00fchrung verteilter Builds sein. Seit Version 1.0 haben sich verteilte Builds zu einer priorisierten Aufgabe entwickelt, die mehr Wert f\u00fcr werf bietet: vertikale Skalierung von Builds und Unterst\u00fctzung f\u00fcr fl\u00fcchtige Builds in verschiedenen CI\/CD-Systemen, sowie die M\u00f6glichkeit, offizielle Unterst\u00fctzung f\u00fcr GitHub Actions zu implementieren. Daher wurden die Zeitpl\u00e4ne f\u00fcr die Umsetzung paralleler Builds verschoben. Wir arbeiten jedoch daran, beide Funktionalit\u00e4ten so schnell wie m\u00f6glich bereitzustellen.<\/p>\n<p>Bleiben Sie auf dem Laufenden! Vergessen Sie nicht, auch bei uns vorbeizuschauen <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, um ein Issue zu erstellen, ein bereits vorhandenes zu finden und einen Pluspunkt zu setzen, einen PR zu erstellen oder einfach den Fortschritt des Projekts zu beobachten.<\/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 freuen uns, werf 1.0 stable vorzustellen: 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\/\">werf \u2014 unser Tool f\u00fcr CI\/CD in Kubernetes (\u00dcbersicht und Video des Vortrags)<\/a><\/noindex>\u00bb;<\/li>\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\/476646\/\">3-Wege-Merge im Werfer: Deployment in Kubernetes mit Helm 'auf Steroiden'<\/a><\/noindex>\u00bb;<\/li>\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<\/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 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"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\" \/>\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) 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\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:description\" content=\"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\" \/>\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\udd47 Ver\u00f6ffentlichung von werf 1.1: Verbesserungen bei der Assemblierung heute und Pl\u00e4ne f\u00fcr die Zukunft | ProHoster","description":"werf \u2014 unser Open-Source-GitOps-CLI-Tool zur Erstellung und Bereitstellung von Anwendungen in Kubernetes. Wie versprochen markiert die Ver\u00f6ffentlichung von Version v1.0 den Beginn der Einf\u00fchrung neuer Funktionen in werf und eine \u00dcberarbeitung gewohnter Ans\u00e4tze. Jetzt freuen wir uns, die Version v1.1 vorzustellen, die einen gro\u00dfen Schritt in der Entwicklung darstellt und die Grundlage f\u00fcr die Zukunft des werf-Assemblers bildet. Diese Version ist derzeit verf\u00fcgbar.","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:description":"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","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"},"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}]}}