Das Thema Monorepository wurde mehr als einmal diskutiert und löst in der Regel eine sehr aktive Debatte aus.
Wenn wir werf als Open Source-Tool
erstellen , um den Prozess des
Kompilierens von Anwendungscode von Git zu Docker-Images (und deren anschließende Übermittlung an Kubernetes) zu verbessern, denken wir nicht viel darüber nach, welche Auswahl besser ist. Für uns ist es wichtig, alles Notwendige für Unterstützer unterschiedlicher Meinungen bereitzustellen (wenn dies natürlich nicht dem gesunden Menschenverstand widerspricht).
Die jüngste Unterstützung für Mono-Repo in werf ist ein gutes Beispiel. Aber zuerst wollen wir sehen, wie diese Unterstützung im Allgemeinen mit der Verwendung von werf verbunden ist und was die Docker-Registrierung damit zu tun hat ...
Problem
Stellen Sie sich diese Situation vor. Das Unternehmen hat viele Entwicklungsteams, die an unabhängigen Projekten beteiligt sind. Die meisten Anwendungen laufen auf Kubernetes und sind dementsprechend containerisiert. Zum Speichern von Containern und Bildern ist eine Registrierung erforderlich. Das Unternehmen verwendet den Docker Hub mit einem einzigen
COMPANY Konto als solche Registrierung. Ähnlich wie bei den meisten Quellcode-Speichersystemen können Sie mit
Docker Hub keine verschachtelte Hierarchie von Repositorys wie
COMPANY/PROJECT/IMAGE erstellen . In diesem Fall ... wie kann man nicht monolithische Anwendungen mit dieser Einschränkung in der Registrierung behalten, ohne für jedes Projekt ein eigenes Konto zu erstellen?
Vielleicht ist die beschriebene Situation jemandem aus erster Hand bekannt, aber lassen Sie uns das Problem der Organisation des Anwendungsspeichers im Allgemeinen betrachten, d. H. ohne Bezug auf das obige Beispiel und den Docker Hub.
Lösungen
Wenn die Anwendung
monolithisch ist und in einem Bild
vorliegt , stellen sich keine Fragen und wir speichern die Bilder einfach im Projekt-Repository.
Wenn eine Anwendung in Form mehrerer Komponenten,
Microservices , präsentiert wird, muss ein bestimmter Ansatz gewählt werden. Anhand eines Beispiels einer typischen Webanwendung, die aus zwei Bildern besteht:
frontend und
backend , stehen folgende Optionen zur Verfügung:
- Speichern Sie Bilder in separaten verschachtelten Repositorys:
- Speichern Sie alles in einem Repository und nehmen Sie den Bildnamen wie folgt in das Tag auf:
NB : Eigentlich gibt es immer noch die Möglichkeit, PROJECT-frontend und PROJECT-backend in verschiedenen Repositorys zu speichern, aber wir werden dies aufgrund der Komplexität des Supports, der Organisation und der Verteilung von Rechten zwischen Benutzern nicht berücksichtigen.Werf Unterstützung
Anfänglich beschränkte sich werf auf verschachtelte Repositorys - glücklicherweise unterstützen die meisten Registries diese Funktion. Ab Version
v1.0.4-alpha.3 wurde die Arbeit mit Registern hinzugefügt, in denen die
Verschachtelung nicht unterstützt wird , und Docker Hub unter ihnen. Von diesem Moment an hatte der Benutzer die Wahl, wie Anwendungsbilder gespeichert werden sollen.
Die Implementierung ist als Teil der Option
--images-repo-mode=multirepo|monorepo (standardmäßig
multirepo , d. H. Speicherung in verschachtelten Repositorys)
multirepo . Es definiert die Muster, nach denen Bilder in der Registrierung gespeichert werden. Es reicht aus, den gewünschten Modus zu wählen, wenn Sie die Basisbefehle verwenden, und alles andere bleibt unverändert.
Da die meisten werf-Optionen
mit Umgebungsvariablen festgelegt werden können, ist der Speichermodus in CI / CD-Systemen normalerweise einfach global für das gesamte Projekt festzulegen.
WERF_IMAGES_REPO_MODE: multirepo|monorepo im Fall von GitLab beispielsweise einfach die Umgebungsvariable in den Projekteinstellungen hinzu:
Einstellungen -> CI / CD -> Variablen: WERF_IMAGES_REPO_MODE: multirepo|monorepo .
Wenn wir über das Veröffentlichen von Bildern und das Ausrollen von Anwendungen sprechen (weitere Informationen zu diesen Prozessen finden Sie in den entsprechenden Artikeln der Dokumentation:
Veröffentlichungsprozess und
Bereitstellungsprozess ), bestimmt der Modus ausschließlich die Vorlage, mit der Sie mit dem Bild arbeiten können.
Teufel im Detail
Der Unterschied und die Hauptschwierigkeit beim Hinzufügen einer neuen Speichermethode liegt während des Registrierungsbereinigungsprozesses
(Reinigungsoptionen, die von werf unterstützt werden, finden Sie unter Reinigungsprozess ) .
Bei der Bereinigung berücksichtigt werf die in Kubernetes-Clustern verwendeten Images sowie vom Benutzer konfigurierte Richtlinien. Richtlinien basieren auf der Aufteilung von Tags in Strategien. Derzeit unterstützte Strategien:
- 3 Strategien im Zusammenhang mit Git-Grundelementen wie Tag, Branch und Commit;
- 1 Strategie für benutzerdefinierte Tags.
Wir speichern Informationen über die Tag-Strategie, wenn wir das Bild in den Beschriftungen des endgültigen Bildes veröffentlichen. Die Bedeutung selbst - das sogenannte
Meta-Tag - ist für die Anwendung einiger Richtlinien erforderlich. Wenn Sie beispielsweise einen Zweig oder ein Tag aus dem Git-Repository löschen, ist es logisch, verwandte
nicht verwendete Bilder aus der Registrierung zu löschen, die in einem Teil unserer Richtlinien behandelt wird.
Beim Speichern in einem Repository (
monorepo ) kann neben dem Meta-Tag auch der
PROJECT: frontend -META-TAG im Bild-Tag gespeichert werden:
PROJECT: frontend -META-TAG . Um sie zu trennen, haben wir kein bestimmtes Trennzeichen eingeführt, sondern beim Veröffentlichen einfach den erforderlichen Wert zum Etikett des endgültigen Bildes hinzugefügt.
NB : Wenn Sie sich alles ansehen möchten, was im werf-Quellcode beschrieben ist, kann PR 1684 als Ausgangspunkt dienen.In diesem Artikel werden wir uns nicht mehr mit den Problemen und der Rechtfertigung unseres Ansatzes befassen: mit Kennzeichnungsstrategien, dem Speichern von Daten in Etiketten und dem gesamten Veröffentlichungsprozess - all dies wird in einem kürzlich veröffentlichten Bericht von Dmitry Stolyarov ausführlich beschrieben: „
werf ist unser Werkzeug für CI / CD in Kubernetes . "
Zusammenfassen
Der Mangel an Registrierungsunterstützung ohne Verschachtelung war kein Blockierungsfaktor für uns oder die uns bekannten werf-Benutzer. Sie können jederzeit eine separate Image-Registrierung erstellen (oder zur bedingten Container-Registrierung in der Google Cloud wechseln). Das Entfernen dieser Einschränkung schien jedoch logisch, um das Tool komfortabler zu gestalten breite DevOps-Community. Bei der Implementierung hatten wir die Hauptschwierigkeiten bei der Verarbeitung des Mechanismus zum Bereinigen der Containerregistrierung. Jetzt, da alles fertig ist, ist es schön zu wissen, dass es für jemanden einfacher geworden ist, und wir (als Hauptentwickler des Projekts) haben keine wesentlichen Schwierigkeiten, diese Funktion weiter zu unterstützen.
Bleiben Sie bei uns und wir werden Sie sehr bald über weitere Innovationen in
werf informieren !
PS
Lesen Sie auch in unserem Blog: