Das Thema Monorepository wurde bereits mehrfach diskutiert und führt in der Regel zu sehr aktiven Debatten. Bei der Erstellung als Open Source-Tool, das die Prozesse der Codeerstellung von Anwendungen aus Git in Docker-Images (und deren anschließender Bereitstellung in Kubernetes) verbessern soll, denken wir wenig darüber nach, welche Wahl die bessere ist. Für uns ist es primär, alles Notwendige für die Unterstützer verschiedener Meinungen bereitzustellen (sofern dies nicht dem gesunden Menschenverstand widerspricht, natürlich).
Die kürzlich hinzugefügte Unterstützung von Mono-Repo in werf ist ein gutes Beispiel dafür. Aber lassen Sie uns zunächst klären, wie diese Unterstützung überhaupt mit der Verwendung von werf verbunden ist und was Docker Registry damit zu tun hat…
Problemstellung
Stellen wir uns eine solche Situation vor. In einem Unternehmen gibt es zahlreiche Entwicklerteams, die an unabhängigen 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. Ähnlich wie die meisten Systeme zur Speicherung von Quellcode erlaubt Docker Hub keine verschachtelte Hierarchie von Repositories, wie etwa COMPANY/PROJECT/IMAGE. In diesem Fall… wie kann man mit dieser Einschränkung nicht-monolithische Anwendungen im Registry speichern, ohne für jedes Projekt ein separates Konto zu erstellen?
Möglicherweise ist die beschriebene Situation für einige bekannt, aber lasst uns die Frage der Organisationsstruktur von Anwendungen im Allgemeinen betrachten, das heißt, ohne an das oben beschriebene Beispiel und Docker Hub gebunden zu sein.
Lösungswege
Wenn die Anwendung monolithisch, wird sie in einem Image bereitgestellt, dann gibt es keine Fragen und wir speichern einfach die Images im Registry der Anwendung.
Wenn die Anwendung aus mehreren Komponenten besteht, Mikroservices, muss ein bestimmter Ansatz gewählt werden. Am Beispiel einer typischen Webanwendung, die aus zwei Images besteht: frontend und backend — mögliche Optionen sind:
- Bilder in separaten verschachtelten Repositories speichern:
- Alles in einem Repository speichern, wobei der Name des Images z.B. wie folgt im Tag berücksichtigt wird:
NB: Eigentlich gibt es noch eine Möglichkeit, die Speicherung in verschiedenen Repositories zu organisieren, PROJECT-frontend und PROJECT-backend, aber diese werden wir wegen der Komplexität der Unterstützung, Organisation und Verteilung der Rechte zwischen den Benutzern nicht betrachten.
Unterstützung in werf
Ursprünglich beschränkte sich werf auf verschachtelte Repositories – glücklicherweise unterstützen die meisten Registries diese Möglichkeit. Ab Version , wurde die Unterstützung für Registries hinzugefügt, in denen keine Verschachtelung unterstützt wird, einschließlich Docker Hub. Von diesem Zeitpunkt an hatten Benutzer die Wahl, wie sie die Anwendungsbilder speichern möchten.
Die Implementierung ist im Rahmen der Option --images-repo-mode=multirepo|monorepo (Standardmäßig multirepo, d.h. Lagerung in verschachtelten Repositories). Diese definiert die Muster, nach denen die Bilder im Registry gespeichert werden. Es genügt, den gewünschten Modus bei der Verwendung der Hauptbefehle auszuwählen, alles andere bleibt unverändert.
Da die meisten werf-Optionen über Umgebungsvariablenfestgelegt werden können, ist der Speicher-Modus in CI/CD-Systemen in der Regel einfach global für das gesamte Projekt festzulegen. Zum Beispiel, im Falle von GitLab muss lediglich eine Umgebungsvariable in den Projekteinstellungen hinzugefügt werden: Einstellungen -> CI / CD -> Variablen: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Wenn es um die Veröffentlichung von Bildern und die Bereitstellung von Anwendungen geht (über diese Prozesse kann man detailliert in den entsprechenden Artikeln der Dokumentation lesen: und ), definiert der Modus ausschließlich das Muster, mit dem man mit dem Bild arbeiten kann.
Der Teufel steckt im Detail
Der Unterschied und die Hauptschwierigkeit bei der Hinzufügung einer neuen Speichermethode liegt im Prozess der Bereinigung des Registrys (die in werf unterstützten Bereinigungsmöglichkeiten siehe ).
). Bei der Bereinigung berücksichtigt 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ützte Strategien:
- 3 Strategien, die mit Git-Primitiven wie Tag, Branch und Commit verbunden sind;
- 1 Strategie für benutzerdefinierte Tags.
Die Informationen über die Tag-Strategie werden bei der Veröffentlichung des Bildes in den Labels des Endbildes gespeichert. Der Wert selbst – das sogenannte Metatag – ist erforderlich, um einen Teil der Richtlinien anzuwenden. Beispielsweise ist es sinnvoll, die zugehörigen nicht verwendeten Bilder aus dem Registry zu löschen, wenn ein Branch oder Tag aus dem Git-Repository gelöscht wird, was durch einen Teil unserer Richtlinien abgedeckt wird.
Bei der Speicherung in einem einzigen Repository (monorepo), kann im Tag des Bildes neben dem Metatag auch der Bildname gespeichert werden: PROJEKT:frontend-META-TAG. Um sie zu trennen, haben wir keinen spezifischen Trenner eingeführt, sondern einfach den erforderlichen Wert im Label des endgültigen Images beim Publishen hinzugefügt.
NB: Wenn Sie interessiert sind, alles, was im Quellcode von werf beschrieben ist, zu sehen, kann ein Ausgangspunkt sein .
In diesem Artikel werden wir nicht weiter auf die Problematik und die Begründung unseres Ansatzes eingehen: über Tagging-Strategien, Datenspeicherung in Labels und den Veröffentlichungsprozess insgesamt — all dies wurde ausführlich in einem kürzlich gehaltenen Vortrag von Dmitry Stolyarov behandelt: „».
Zusammenfassend
Das Fehlen der Unterstützung von Registries ohne Verschachtelung war für uns oder die uns bekannten werf-Nutzer kein ausschlaggebender Faktor — schließlich kann immer ein separater Image-Registry aufgesetzt oder auf eine hypothetische Container Registry in Google Cloud umgestiegen werden… Dennoch schien es logisch, eine solche Einschränkung aufzuheben, um das Tool für eine breitere DevOps-Community zugänglicher zu machen. Bei der Umsetzung stießen wir auf die größte Schwierigkeit bei der Überarbeitung des Mechanismus zur Reinigung des Container-Registries. Jetzt, wo alles bereit ist, ist es schön zu wissen, dass es für jemanden einfacher geworden ist, und dass wir (als die Hauptentwickler des Projekts) keine nennenswerten Schwierigkeiten bei der weiteren Unterstützung dieses Features erwarten.
Bleiben Sie dran, und bald werden wir über weitere Neuerungen in !
P.S.
Lesen Sie auch in unserem Blog:
- «»;
- «».
Quelle: habr.com
