{"id":37667,"date":"2019-10-31T22:18:58","date_gmt":"2019-10-31T19:18:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry\/"},"modified":"2019-10-31T22:18:58","modified_gmt":"2019-10-31T19:18:58","slug":"podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","title":{"rendered":"Unterst\u00fctzung von Monorepo und Multirepo im Werfer und was Docker Registry damit zu tun hat.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Unterst\u00fctzung
\n
\nDas Thema des Monorepositories wurde bereits mehrfach diskutiert und f\u00fchrt in der Regel zu lebhaften Kontroversen. Bei der Erstellung werf<\/a><\/noindex> eines Open Source-Tools, das darauf abzielt, die Prozesse des Code-Bauens von Anwendungen aus Git in Docker-Images (und deren anschlie\u00dfender Bereitstellung in Kubernetes) zu verbessern, machen wir uns selten Gedanken dar\u00fcber, welche Wahl die bessere ist. Es ist uns wichtig, alles Notwendige f\u00fcr Unterst\u00fctzer unterschiedlicher Meinungen bereitzustellen (sofern es nat\u00fcrlich dem gesunden Menschenverstand nicht widerspricht).<\/p>\n

Die k\u00fcrzlich eingef\u00fchrte Unterst\u00fctzung f\u00fcr Mono-Repo in werf ist ein gutes Beispiel. Aber lassen Sie uns zun\u00e4chst kl\u00e4ren, wie diese Unterst\u00fctzung \u00fcberhaupt mit der Nutzung von werf zusammenh\u00e4ngt und welche Rolle das Docker Registry dabei spielt...<\/a><\/noindex><\/p>\n

Problemstellung<\/h2>\n

\nStellen Sie sich die folgende Situation vor: In einem Unternehmen gibt es viele Entwicklungsteams, die an unabh\u00e4ngigen Projekten arbeiten. Die meisten Anwendungen laufen in Kubernetes und werden daher containerisiert. F\u00fcr die Speicherung der Container und Images ist ein Registry erforderlich. In diesem Unternehmen wird Docker Hub mit einem einzigen Konto als solches Registry verwendet. COMPANY<\/code>. \u00c4hnlich wie bei den meisten Systemen zur Speicherung von Quellcode erlaubt Docker Hub keine verschachtelte Hierarchie von Repositories<\/b>, wie zum Beispiel UNTERNEHMEN\/PROJEKT\/BILD<\/code>. In diesem Fall\u2026 wie kann man unter dieser Einschr\u00e4nkung nicht monolithische Anwendungen im Registry speichern, ohne f\u00fcr jedes Projekt ein separates Konto zu erstellen? <\/p>\n

\"Unterst\u00fctzung
\n
\nM\u00f6glicherweise ist die beschriebene Situation f\u00fcr einige bekannt, aber lassen Sie uns die Frage der Speicherung von Anwendungen allgemein betrachten, ohne an das oben beschriebene Beispiel und Docker Hub gebunden zu sein.<\/p>\n

L\u00f6sungswege<\/h3>\n

\nWenn die Anwendung monolithisch<\/b>, in einem einzigen Image bereitgestellt wird, gibt es keine Fragen, und wir speichern einfach die Images im Container-Registry des Projekts.<\/p>\n

Wenn die Anwendung aus mehreren Komponenten besteht, Mikrodiensten<\/b>, muss ein bestimmter Ansatz gew\u00e4hlt werden. Am Beispiel einer typischen Webanwendung, die aus zwei Images besteht: Frontend<\/code> und backend<\/code> \u2014 m\u00f6gliche Optionen sind:<\/p>\n

    \n
  1. Images in separaten, verschachtelten Repositories speichern:\n

    \"Unterst\u00fctzung<\/li>\n

  2. Alles in einem Repository speichern und den Namen des Images im Tag ber\u00fccksichtigen, zum Beispiel wie folgt:\n

    \"Unterst\u00fctzung<\/li>\n<\/ol>\n

    \nNB<\/b>: Eigentlich gibt es auch die M\u00f6glichkeit, in verschiedenen Repositories zu speichern, PROJEKT-frontend<\/code> und PROJEKT-backend<\/code>, aber dies werden wir aufgrund der Komplexit\u00e4t von Wartung, Organisation und Verteilung von Rechten zwischen den Nutzern nicht betrachten.<\/i><\/p>\n

    Unterst\u00fctzung in werf<\/h2>\n

    \nUrspr\u00fcnglich beschr\u00e4nkte sich werf auf verschachtelte Repositories \u2013 gl\u00fccklicherweise unterst\u00fctzen die meisten Registries diese Funktionalit\u00e4t. Seit Version v1.0.4-alpha.3<\/a><\/noindex>, ist die Arbeit mit Registries hinzugef\u00fcgt worden, in denen Verschachtelung nicht unterst\u00fctzt wird<\/b>, und Docker Hub z\u00e4hlt dazu. Ab diesem Zeitpunkt hat der Nutzer die Wahl, wie die Anwendungs-Images gespeichert werden.<\/p>\n

    Die Implementierung ist im Rahmen der Option --images-repo-mode=multirepo|monorepo<\/code> standardm\u00e4\u00dfig multirepo<\/code>, d.h. Speicherung in verschachtelten Repositories. Sie definiert die Vorlagen, nach denen die Images in der Registry gespeichert werden. Es gen\u00fcgt, den gew\u00fcnschten Modus bei der Verwendung der Hauptkommandos auszuw\u00e4hlen, w\u00e4hrend der Rest unver\u00e4ndert bleibt.<\/p>\n

    Da die meisten Optionen von werf als Umgebungsvariablen<\/b>festgelegt werden k\u00f6nnen, l\u00e4sst sich der Speicherungsmodus in CI\/CD-Systemen in der Regel global f\u00fcr das gesamte Projekt leicht festlegen. Beispielsweise im Fall von GitLab<\/b> reicht es aus, eine Umgebungsvariable in den Projekteinstellungen hinzuzuf\u00fcgen: Einstellungen -> CI \/ CD -> Variablen: WERF_IMAGES_REPO_MODE: multirepo|monorepo<\/code><\/i>.<\/p>\n

    Was die Ver\u00f6ffentlichung von Images und das Deployment von Anwendungen angeht (\u00fcber diese Prozesse kann in den entsprechenden Artikeln der Dokumentation ausf\u00fchrlich gelesen werden: Ver\u00f6ffentlichungsprozess<\/a><\/noindex> und Bereitstellungsprozess<\/a><\/noindex>), der Modus bestimmt ausschlie\u00dflich das Muster, nach dem man mit dem Image arbeiten kann.<\/p>\n

    Der Teufel steckt im Detail<\/h3>\n

    \nDer Unterschied und die Hauptherausforderung beim Hinzuf\u00fcgen neuer Speicheroptionen liegen im Bereinigungsprozess der Registry (f\u00fcr die in werf unterst\u00fctzten Bereinigungsm\u00f6glichkeiten siehe Bereinigungsprozess<\/a><\/noindex>)<\/i>.<\/p>\n

    Bei der Bereinigung ber\u00fccksichtigt werf die in den Kubernetes-Clustern verwendeten Images sowie vom Benutzer festgelegte Richtlinien. Die Richtlinien basieren auf der Trennung der Tags in Strategien. Momentan unterst\u00fctzte Strategien sind:<\/p>\n

      \n
    1. 3 Strategien, die mit Git-Primitiven wie Tag, Branch und Commit verbunden sind;<\/li>\n
    2. 1 Strategie f\u00fcr beliebige benutzerdefinierte Tags.<\/li>\n<\/ol>\n

      \nInformationen zur Tag-Strategie werden beim Ver\u00f6ffentlichen des Images in den Labels des Endimages gespeichert. Der Wert selbst ist der sogenannte Metatag<\/b> \u2014 notwendig f\u00fcr die Anwendung eines Teils der Richtlinien. Zum Beispiel macht es Sinn, beim L\u00f6schen eines Branches oder Tags aus dem Git-Repository auch die verbundenen unbenutzten<\/i> Images aus dem Registry zu entfernen, was durch einen Teil unserer Richtlinien abgedeckt wird.<\/p>\n

      Beim Speichern in einem einzigen Repository (monorepo<\/code>), kann im Tag des Images zus\u00e4tzlich zum Metatag auch der Name des Images gespeichert werden: PROJEKT:Frontend<\/b>-META-TAG<\/code>. Um sie zu trennen, haben wir keinen spezifischen Trennzeichen verwendet, sondern einfach den erforderlichen Wert im Label des endg\u00fcltigen Abbilds bei der Ver\u00f6ffentlichung hinzugef\u00fcgt.<\/p>\n

      NB<\/b>: Falls Sie interessiert sind, den gesamten beschriebenen Code von werf zu sehen, k\u00f6nnte der Ausgangspunkt sein PR 1684<\/a><\/noindex>.<\/i><\/p>\n

      In diesem Artikel werden wir nicht weiter auf die Problematik und Begr\u00fcndung unseres Ansatzes eingehen: zu Strategien der Tag-Generierung, der Datenspeicherung in Labels und dem Ver\u00f6ffentlichungsprozess insgesamt - all dies wurde ausf\u00fchrlich im aktuellen Bericht von Dmitri Stolyarov behandelt: \u00abwerf \u2013 unser Werkzeug f\u00fcr CI\/CD in Kubernetes<\/a><\/noindex>\u00bb.<\/p>\n

      Zusammenfassend<\/h2>\n

      \nDas Fehlen von unterst\u00fctzten Registries ohne Verschachtelung war f\u00fcr uns oder unseren bekannten Nutzern von werf kein Hindernis \u2013 schlie\u00dflich kann man immer ein separates Abbild-Registry erstellen (oder auf das Container Registry in Google Cloud umsteigen). Dennoch schien es logisch, solch eine Einschr\u00e4nkung aufzuheben, damit das Tool f\u00fcr eine breitere DevOps-Community zug\u00e4nglicher wird. Bei der Umsetzung stie\u00dfen wir auf die gr\u00f6\u00dfte Herausforderung: die \u00dcberarbeitung des Mechanismus zur Bereinigung des Container-Registries. Jetzt, wo alles bereit ist, erfreut es uns zu wissen, dass es jemandem leichter gefallen ist und wir (als Hauptentwickler des Projekts) keine wesentlichen Schwierigkeiten bei der weiteren Unterst\u00fctzung dieser Funktion erwarten.<\/p>\n

      Bleiben Sie bei uns, und bald werden wir \u00fcber weitere Neuerungen berichten. werf<\/a><\/noindex>!<\/p>\n

      P.S.<\/h2>\n

      \nLesen Sie auch in unserem Blog:<\/p>\n