Das Thema Mono-Repositorium wurde schon mehrfach diskutiert und sorgt in der Regel für sehr lebhafte Kontroversen. Durch das Schaffen Da es sich um ein Open-Source-Tool handelt, das den Prozess der Erstellung von Anwendungscode von Git zu Docker-Images (und deren anschließender Bereitstellung an Kubernetes) verbessern soll, denken wir nicht viel darüber nach, welche Wahl die beste ist. Für uns ist es vorrangig, den Anhängern anderer Meinungen alles Nötige zur Verfügung zu stellen (natürlich nur, wenn dies nicht dem gesunden Menschenverstand widerspricht).
Die jüngste Mono-Repo-Unterstützung von werf ist ein gutes Beispiel dafür. Aber lassen Sie uns zunächst herausfinden, wie diese Unterstützung im Allgemeinen mit der Verwendung von werf zusammenhängt und was die Docker-Registrierung damit zu tun hat ...
Probleme
Stellen wir uns eine solche Situation vor. Das Unternehmen verfügt über viele Entwicklungsteams, die an unabhängigen Projekten arbeiten. Die meisten Anwendungen laufen auf Kubernetes und sind daher containerisiert. Um Container und Bilder zu speichern, benötigen Sie eine Registrierung (Registrierung). Als solche Registry nutzt das Unternehmen Docker Hub mit einem einzigen Konto COMPANY. Ähnlich wie bei den meisten Quellcode-Speichersystemen, Docker Hub erlaubt keine verschachtelte Repository-Hierarchie, wie zum Beispiel COMPANY/PROJECT/IMAGE. In diesem Fall ... wie können Sie mit dieser Einschränkung nicht-monolithische Anwendungen in der Registrierung speichern, ohne für jedes Projekt ein separates Konto zu erstellen?
Vielleicht ist die beschriebene Situation jemandem aus erster Hand bekannt, aber betrachten wir die Frage der Organisation des Anwendungsspeichers im Allgemeinen, d. h. ohne Bezug auf das obige Beispiel und Docker Hub.
Wege zur Lösung
Wenn die Anwendung monolithisch, kommt in einem Bild, dann gibt es keine Fragen und wir speichern die Bilder einfach in der Container-Registrierung des Projekts.
Wenn eine Anwendung als mehrere Komponenten dargestellt wird, Mikrodienste, dann ist eine bestimmte Vorgehensweise erforderlich. Am Beispiel einer typischen Webanwendung bestehend aus zwei Bildern: frontend и backend - Die möglichen Optionen sind:
- Speichern Sie Bilder in separaten verschachtelten Repositorys:
- Speichern Sie alles in einem Repository und berücksichtigen Sie den Bildnamen im Tag beispielsweise wie folgt:
NB: Eigentlich gibt es noch eine andere Möglichkeit mit dem Speichern in verschiedenen Repositories, PROJECT-frontend и PROJECT-backend, aber wir werden es aufgrund der Komplexität der Unterstützung, Organisation und Verteilung der Rechte zwischen Benutzern nicht berücksichtigen.
werf-Unterstützung
Anfangs beschränkte sich werf auf verschachtelte Repositories – glücklicherweise unterstützen die meisten Registrys diese Funktion. Ab Version , Arbeit mit Registern hinzugefügt, in denen Verschachtelung wird nicht unterstützt, und Docker Hub ist einer davon. Ab diesem Zeitpunkt hat der Benutzer die Wahl, wie er die Anwendungsbilder speichern möchte.
Implementierung unter Option verfügbar --images-repo-mode=multirepo|monorepo (Default multirepo, d.h. Speicherung in verschachtelten Repositories). Es definiert die Muster, nach denen Bilder in der Registrierung gespeichert werden. Bei Verwendung der Grundbefehle reicht es aus, den gewünschten Modus auszuwählen, alles andere bleibt unverändert.
Weil die meisten werf-Optionen festgelegt werden können UmgebungsvariablenIn CI-/CD-Systemen lässt sich der Speichermodus in der Regel einfach global für das gesamte Projekt festlegen. Zum Beispiel, im Fall von GitLab Fügen Sie einfach eine Umgebungsvariable in den Projekteinstellungen hinzu: Einstellungen -> CI/CD -> Variablen: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Wenn es um das Veröffentlichen von Bildern und das Ausrollen von Anwendungen geht (diese Prozesse können Sie in den entsprechenden Dokumentationsartikeln ausführlich nachlesen): и ), dann bestimmt der Modus ausschließlich die Vorlage, nach der Sie mit dem Bild arbeiten können.
Der Teufel steckt im Detail
Der Unterschied und die Hauptschwierigkeit beim Hinzufügen einer neuen Speichermethode liegt in der Bereinigung der Registrierung (Informationen zu den von werf unterstützten Löschfunktionen finden Sie unter ).
Bei der Bereinigung berücksichtigt werf die in Kubernetes-Clustern verwendeten Images sowie die vom Benutzer konfigurierten Richtlinien. Richtlinien basieren auf der Unterteilung von Tags in Strategien. Derzeit unterstützte Strategien:
- 3 Strategien, die durch Git-Grundelemente wie Tag, Branch und Commit verknüpft sind;
- 1 Strategie für beliebige benutzerdefinierte Tags.
Wir speichern Informationen über die Tag-Strategie bei der Veröffentlichung des Bildes in den Labels des endgültigen Bildes. Die Bedeutung selbst ist die sogenannte Meta-Tag - Erforderlich, um einige der Richtlinien anzuwenden. Wenn Sie beispielsweise einen Zweig oder ein Tag aus einem Git-Repository löschen, ist es logisch, auch die zugehörigen zu löschen unbenutzt Bilder aus der Registrierung, was durch einen Teil unserer Richtlinien abgedeckt ist.
Beim Speichern in einem Repository (monorepo), im Bild-Tag kann neben dem Meta-Tag auch der Name des Bildes hinterlegt werden: PROJECT:frontend-META-TAG. Um sie zu trennen, haben wir kein spezielles Trennzeichen eingeführt, sondern bei der Veröffentlichung lediglich den erforderlichen Wert zur Beschriftung des endgültigen Bildes hinzugefügt.
NB: Wenn Sie daran interessiert sind, sich alles anzusehen, was im werf-Quellcode beschrieben ist, dann kann der Ausgangspunkt sein .
In diesem Artikel werden wir den Problemen und der Rechtfertigung unseres Ansatzes nicht mehr Aufmerksamkeit schenken: über Tagging-Strategien, die Speicherung von Daten in Etiketten und den Veröffentlichungsprozess als Ganzes – all dies wird in einem aktuellen Bericht von Dmitry Stolyarov ausführlich beschrieben: „".
zusammenfassend
Die mangelnde Unterstützung nicht verschachtelter Register war weder für uns noch für die uns bekannten werf-Benutzer ein blockierender Faktor – schließlich können Sie jederzeit eine separate Image-Registrierung erstellen (oder zu einer bedingten Container-Registrierung in Google Cloud wechseln) ... Allerdings Die Aufhebung einer solchen Einschränkung erschien logisch, um das Tool für die breitere DevOps-Community komfortabler zu machen. Bei der Implementierung standen wir vor der größten Schwierigkeit, den Mechanismus zur Bereinigung der Container-Registrierung zu überarbeiten. Jetzt, wo alles fertig ist, ist es schön zu erkennen, dass es für jemanden einfacher geworden ist und wir (als Hauptentwickler des Projekts) keine nennenswerten Schwierigkeiten haben werden, diese Funktion weiter zu unterstützen.
Bleiben Sie bei uns und schon bald werden wir Sie über weitere Neuerungen informieren !
PS
Lesen Sie auch auf unserem Blog:
- «";
- «".
Source: habr.com