{"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 in werf und was hat das mit Docker Registry zu tun","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Unterst\u00fctzung
\n
\nDas Thema Monorepository wurde bereits mehrfach diskutiert und f\u00fchrt in der Regel zu sehr aktiven Debatten. Bei der Erstellung werf<\/a><\/noindex> als Open Source-Tool, das die Prozesse der Codeerstellung von Anwendungen aus Git in Docker-Images (und deren anschlie\u00dfender Bereitstellung in Kubernetes) verbessern soll, denken wir wenig dar\u00fcber nach, welche Wahl die bessere ist. F\u00fcr uns ist es prim\u00e4r, alles Notwendige f\u00fcr die Unterst\u00fctzer verschiedener Meinungen bereitzustellen (sofern dies nicht dem gesunden Menschenverstand widerspricht, nat\u00fcrlich).<\/p>\n

Die k\u00fcrzlich hinzugef\u00fcgte Unterst\u00fctzung von Mono-Repo in werf ist ein gutes Beispiel daf\u00fcr. Aber lassen Sie uns zun\u00e4chst kl\u00e4ren, wie diese Unterst\u00fctzung \u00fcberhaupt mit der Verwendung von werf verbunden ist und was Docker Registry damit zu tun hat\u2026<\/a><\/noindex><\/p>\n

Problemstellung<\/h2>\n

\nStellen wir uns eine solche Situation vor. In einem Unternehmen gibt es zahlreiche Entwicklerteams, die an unabh\u00e4ngigen Projekten arbeiten. Die meisten Anwendungen laufen in Kubernetes und sind somit containerisiert. Zur Speicherung von Containern und Images ist ein Registry erforderlich. Als solcher Registry wird im Unternehmen Docker Hub mit einem einzigen Konto verwendet COMPANY<\/code>. \u00c4hnlich wie die meisten Systeme zur Speicherung von Quellcode erlaubt Docker Hub keine verschachtelte Hierarchie von Repositories<\/b>, wie etwa COMPANY\/PROJECT\/IMAGE<\/code>. In diesem Fall\u2026 wie kann man mit 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 lasst uns die Frage der Organisationsstruktur von Anwendungen im Allgemeinen betrachten, das hei\u00dft, ohne an das oben beschriebene Beispiel und Docker Hub gebunden zu sein.<\/p>\n

L\u00f6sungswege<\/h3>\n

\nWenn die Anwendung monolithisch<\/b>, wird sie in einem Image bereitgestellt, dann gibt es keine Fragen und wir speichern einfach die Images im Registry der Anwendung.<\/p>\n

Wenn die Anwendung aus mehreren Komponenten besteht, Mikroservices<\/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. Bilder in separaten verschachtelten Repositories speichern:\n

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

  2. Alles in einem Repository speichern, wobei der Name des Images z.B. wie folgt im Tag ber\u00fccksichtigt wird:\n

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

    \nNB<\/b>: Eigentlich gibt es noch eine M\u00f6glichkeit, die Speicherung in verschiedenen Repositories zu organisieren, PROJECT-frontend<\/code> und PROJECT-backend<\/code>, aber diese werden wir wegen der Komplexit\u00e4t der Unterst\u00fctzung, Organisation und Verteilung der Rechte zwischen den Benutzern 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 M\u00f6glichkeit. Ab Version v1.0.4-alpha.3<\/a><\/noindex>, wurde die Unterst\u00fctzung f\u00fcr Registries hinzugef\u00fcgt, in denen keine Verschachtelung unterst\u00fctzt wird<\/b>, einschlie\u00dflich Docker Hub. Von diesem Zeitpunkt an hatten Benutzer die Wahl, wie sie die Anwendungsbilder speichern m\u00f6chten.<\/p>\n

    Die Implementierung ist im Rahmen der Option --images-repo-mode=multirepo|monorepo<\/code> (Standardm\u00e4\u00dfig multirepo<\/code>, d.h. Lagerung in verschachtelten Repositories). Diese definiert die Muster, nach denen die Bilder im Registry gespeichert werden. Es gen\u00fcgt, den gew\u00fcnschten Modus bei der Verwendung der Hauptbefehle auszuw\u00e4hlen, alles andere bleibt unver\u00e4ndert.<\/p>\n

    Da die meisten werf-Optionen \u00fcber Umgebungsvariablen<\/b>festgelegt werden k\u00f6nnen, ist der Speicher-Modus in CI\/CD-Systemen in der Regel einfach global f\u00fcr das gesamte Projekt festzulegen. Zum Beispiel, im Falle von GitLab<\/b> muss lediglich eine Umgebungsvariable in den Projekteinstellungen hinzugef\u00fcgt werden: Einstellungen -> CI \/ CD -> Variablen: WERF_IMAGES_REPO_MODE: multirepo|monorepo<\/code><\/i>.<\/p>\n

    Wenn es um die Ver\u00f6ffentlichung von Bildern und die Bereitstellung von Anwendungen geht (\u00fcber diese Prozesse kann man detailliert in den entsprechenden Artikeln der Dokumentation lesen: Ver\u00f6ffentlichungsprozess<\/a><\/noindex> und Bereitstellungsprozess<\/a><\/noindex>), definiert der Modus ausschlie\u00dflich das Muster, mit dem man mit dem Bild arbeiten kann.<\/p>\n

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

    \nDer Unterschied und die Hauptschwierigkeit bei der Hinzuf\u00fcgung einer neuen Speichermethode liegt im Prozess der Bereinigung des Registrys (die in werf unterst\u00fctzten Bereinigungsm\u00f6glichkeiten siehe Reinigungsprozess<\/a><\/noindex>)<\/i>.<\/p>\n

    ). Bei der Bereinigung ber\u00fccksichtigt werf die in Kubernetes-Clustern verwendeten Bilder sowie die vom Benutzer festgelegten Richtlinien. Grundlage der Richtlinien ist die Unterteilung der Tags in Strategien. Derzeit unterst\u00fctzte Strategien:<\/p>\n

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

      \nDie Informationen \u00fcber die Tag-Strategie werden bei der Ver\u00f6ffentlichung des Bildes in den Labels des Endbildes gespeichert. Der Wert selbst \u2013 das sogenannte Metatag<\/b> \u2013 ist erforderlich, um einen Teil der Richtlinien anzuwenden. Beispielsweise ist es sinnvoll, die zugeh\u00f6rigen nicht verwendeten<\/i> Bilder aus dem Registry zu l\u00f6schen, wenn ein Branch oder Tag aus dem Git-Repository gel\u00f6scht wird, was durch einen Teil unserer Richtlinien abgedeckt wird.<\/p>\n

      Bei der Speicherung in einem einzigen Repository (monorepo<\/code>), kann im Tag des Bildes neben dem Metatag auch der Bildname gespeichert werden: PROJEKT:frontend<\/b>-META-TAG<\/code>. Um sie zu trennen, haben wir keinen spezifischen Trenner eingef\u00fchrt, sondern einfach den erforderlichen Wert im Label des endg\u00fcltigen Images beim Publishen hinzugef\u00fcgt.<\/p>\n

      NB<\/b>: Wenn Sie interessiert sind, alles, was im Quellcode von werf beschrieben ist, zu sehen, kann ein Ausgangspunkt sein PR 1684<\/a><\/noindex>.<\/i><\/p>\n

      In diesem Artikel werden wir nicht weiter auf die Problematik und die Begr\u00fcndung unseres Ansatzes eingehen: \u00fcber Tagging-Strategien, Datenspeicherung in Labels und den Ver\u00f6ffentlichungsprozess insgesamt \u2014 all dies wurde ausf\u00fchrlich in einem k\u00fcrzlich gehaltenen Vortrag von Dmitry Stolyarov behandelt: \u201ewerf \u2013 unser Werkzeug f\u00fcr CI\/CD in Kubernetes<\/a><\/noindex>\u00bb.<\/p>\n

      Zusammenfassend<\/h2>\n

      \nDas Fehlen der Unterst\u00fctzung von Registries ohne Verschachtelung war f\u00fcr uns oder die uns bekannten werf-Nutzer kein ausschlaggebender Faktor \u2014 schlie\u00dflich kann immer ein separater Image-Registry aufgesetzt oder auf eine hypothetische Container Registry in Google Cloud umgestiegen werden\u2026 Dennoch schien es logisch, eine solche Einschr\u00e4nkung aufzuheben, um das Tool f\u00fcr eine breitere DevOps-Community zug\u00e4nglicher zu machen. Bei der Umsetzung stie\u00dfen wir auf die gr\u00f6\u00dfte Schwierigkeit bei der \u00dcberarbeitung des Mechanismus zur Reinigung des Container-Registries. Jetzt, wo alles bereit ist, ist es sch\u00f6n zu wissen, dass es f\u00fcr jemanden einfacher geworden ist, und dass wir (als die Hauptentwickler des Projekts) keine nennenswerten Schwierigkeiten bei der weiteren Unterst\u00fctzung dieses Features erwarten.<\/p>\n

      Bleiben Sie dran, und bald werden wir \u00fcber weitere Neuerungen in werf<\/a><\/noindex>!<\/p>\n

      P.S.<\/h2>\n

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