{"id":96065,"date":"2020-10-07T13:42:09","date_gmt":"2020-10-07T11:42:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/problema-umnoj-ochistki-obrazov-kontejnerov-i-eyo-reshenie-v-werf"},"modified":"2020-10-07T13:42:09","modified_gmt":"2020-10-07T11:42:09","slug":"problema-umnoj-ochistki-obrazov-kontejnerov-i-eyo-reshenie-v-werf","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/problema-umnoj-ochistki-obrazov-kontejnerov-i-eyo-reshenie-v-werf","title":{"rendered":"Das Problem der \"intelligenten\" Bereinigung von Container-Images und dessen L\u00f6sung in werf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Das
\n
\nIn dem Artikel wird die Problematik der Bereinigung von Images behandelt, die in den Registries von Containern (Docker Registry und \u00e4hnlichen) im Kontext moderner CI\/CD-Pipelines f\u00fcr Cloud-native Anwendungen gespeichert werden, die in Kubernetes bereitgestellt werden. Es werden die Hauptkriterien f\u00fcr die Relevanz von Images und die daraus resultierenden Schwierigkeiten bei der Automatisierung der Bereinigung, der Platzersparnis und der Erf\u00fcllung der Anforderungen der Teams beschrieben. Schlie\u00dflich zeigen wir am Beispiel eines konkreten Open Source-Projekts, wie man diese Schwierigkeiten \u00fcberwinden kann.<\/p>\n

Einf\u00fchrung<\/h2>\n

\nDie Anzahl der Images in der Container-Registry kann rasant ansteigen, wodurch mehr Speicherplatz beansprucht wird, was wiederum die Kosten erheblich erh\u00f6ht. Um das Wachstum des in der Registry belegten Speicherplatzes zu kontrollieren, zu begrenzen oder auf einem akzeptablen Niveau zu halten, wird Folgendes empfohlen:<\/p>\n

    \n
  1. eine feste Anzahl von Tags f\u00fcr Images zu verwenden;<\/li>\n
  2. auf irgendeine Weise Images zu bereinigen.<\/li>\n<\/ol>\n

    <\/a><\/noindex>
    \nDiese erste Einschr\u00e4nkung ist manchmal f\u00fcr kleine Teams akzeptabel. Wenn den Entwicklern die konstanten Tags (latest<\/code>, main<\/code>, test<\/code>, boris<\/code> usw.) ausreichen, wird die Registry nicht wachsen und man muss lange Zeit nicht an die Bereinigung denken. Alle nicht mehr relevanten Images werden \u00fcberschrieben, und es bleibt einfach keine Arbeit f\u00fcr die Bereinigung (das geschieht alles durch den integrierten Garbage Collector).<\/p>\n

    Dennoch schr\u00e4nkt dieser Ansatz die Entwicklung stark ein und ist nur selten auf CI\/CD in modernen Projekten anwendbar. Ein wesentlicher Teil der Entwicklung ist geworden Automatisierung<\/strong>, was es erm\u00f6glicht, neuen Funktionen viel schneller zu testen, bereitzustellen und an die Benutzer zu liefern. Zum Beispiel wird in all unseren Projekten bei jedem Commit automatisch eine CI-Pipeline erstellt. Dort wird ein Image erstellt, getestet, in verschiedenen Kubernetes-Umgebungen f\u00fcr Debugging und weitere Pr\u00fcfungen bereitgestellt, und wenn alles gut ist \u2013 gelangen die \u00c4nderungen zum Endbenutzer. Und das ist l\u00e4ngst keine Raketenwissenschaft mehr, sondern Alltag f\u00fcr viele \u2013 wahrscheinlich auch f\u00fcr Sie, da Sie diesen Artikel lesen.<\/p>\n

    Da die Behebung von Fehlern und die Entwicklung neuer Funktionen parallel vor sich gehen und Releases mehrere Male am Tag durchgef\u00fchrt werden k\u00f6nnen, ist es offensichtlich, dass der Entwicklungsprozess mit einer erheblichen Anzahl von Commits begleitet wird, was bedeutet \u2013 eine gro\u00dfe Anzahl von Images in der Registry<\/strong>. Infolgedessen stellt sich die dringende Frage der Organisation einer effektiven Bereinigung der Registry, d.h. der Entfernung nicht mehr relevanter Images.<\/p>\n

    Aber wie kann man \u00fcberhaupt feststellen, ob ein Image relevant ist?<\/p>\n

    Kriterien der Relevanz von Images<\/h2>\n

    \nIn der \u00fcberwiegenden Mehrzahl der F\u00e4lle werden die Hauptkriterien wie folgt aussehen:<\/p>\n

    1. Das erste (das offensichtlichste und kritischste von allen) sind die Images, die momentan in Kubernetes verwendet werden<\/strong>. Das Entfernen dieser Images kann zu erheblichen Kosten durch Ausfallzeiten in der Produktion f\u00fchren (zum Beispiel k\u00f6nnen Images bei der Replikation ben\u00f6tigt werden) oder die Bem\u00fchungen des Teams, das an der Fehlerbehebung in einer der Umgebungen arbeitet, zunichte machen. (Aus diesem Grund haben wir sogar einen speziellen <\/i>Prometheus-Exporter<\/i><\/a><\/noindex>, der das Fehlen solcher Images in jedem Kubernetes-Cluster \u00fcberwacht.)<\/i><\/p>\n

    2. Das zweite (weniger offensichtlich, aber ebenfalls sehr wichtig und wieder relevant f\u00fcr den Betrieb) sind die Images, die f\u00fcr Rollbacks im Falle schwerwiegender Probleme<\/strong> in der aktuellen Version erforderlich sind. Beispielsweise sind dies im Falle von Helm die Images, die in den gespeicherten Versionen des Releases verwendet werden. (\u00dcbrigens hat Helm standardm\u00e4\u00dfig ein Limit von 256 Revisionen, aber es bezweifelt jemand ernsthaft, dass es einen Bedarf gibt, so viele Versionen zu speichern?..) Schlie\u00dflich speichern wir Versionen, damit wir sie sp\u00e4ter verwenden k\u00f6nnen, das hei\u00dft, um \"zur\u00fcckzuspringen\", falls notwendig.<\/i> 3. Das dritte sind die<\/p>\n

    Bed\u00fcrfnisse der Entwickler: alle Images, die mit ihren aktuellen Arbeiten zusammenh\u00e4ngen. Wenn wir beispielsweise einen PR betrachten, macht es Sinn, das Image zu behalten, das dem letzten Commit und, sagen wir, dem vorherigen Commit entspricht: So kann der Entwickler schnell zu jeder Aufgabe zur\u00fcckkehren und mit den letzten \u00c4nderungen arbeiten.<\/strong>4. Das vierte sind die Images, die <\/p>\n

    den Versionen unserer Anwendung entsprechen , d.h. das Endprodukt sind: v1.0.0, 20.04.01, sierra usw.<\/strong>NB: Die hier definierten Kriterien wurden auf der Grundlage der Erfahrungen mit Dutzenden von Entwicklungsteams aus verschiedenen Unternehmen formuliert. Allerdings k\u00f6nnen diese Kriterien je nach den Besonderheiten in den Entwicklungsprozessen und der verwendeten Infrastruktur (zum Beispiel wenn Kubernetes nicht verwendet wird) variieren.<\/p>\n

    Erf\u00fcllung der Kriterien und bestehende L\u00f6sungen <\/p>\n

    Beliebte Services mit Container-Registrys bieten in der Regel ihre eigenen Richtlinien zur Bereinigung von Images an: Dort k\u00f6nnen Sie Bedingungen definieren, unter denen ein Tag aus dem Registry entfernt wird. Allerdings sind die M\u00f6glichkeiten f\u00fcr diese Bedingungen auf Parameter wie Namen, Erstellungszeit und Anzahl der Tags* beschr\u00e4nkt.<\/h2>\n

    \nBeliebte Dienste mit Container-Registries bieten in der Regel ihre eigenen Richtlinien zur Bereinigung von Images an: Sie k\u00f6nnen darin die Bedingungen festlegen, unter denen ein Tag aus der Registry gel\u00f6scht wird. Die M\u00f6glichkeiten dieser Bedingungen sind jedoch auf Parameter wie Namen, Erstellungszeit und Anzahl der Tags* beschr\u00e4nkt.<\/p>\n

    * \u0417\u0430\u0432\u0438\u0441\u0438\u0442 \u043e\u0442 \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u044b\u0445 \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0439 container registry. \u041c\u044b \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u043b\u0438 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0438\u0445 \u0440\u0435\u0448\u0435\u043d\u0438\u0439: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io \u2014 \u043f\u043e \u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u044e \u043d\u0430 \u0441\u0435\u043d\u0442\u044f\u0431\u0440\u044c’2020.<\/i><\/p>\n

    Ein solches Set an Parametern reicht aus, um das vierte Kriterium zu erf\u00fcllen \u2013 das hei\u00dft, um Images auszuw\u00e4hlen, die den Versionen entsprechen. F\u00fcr alle anderen Kriterien muss jedoch eine Kompromissl\u00f6sung gew\u00e4hlt werden (eine strengere oder im Gegenteil eine nachsichtige Politik) \u2013 abh\u00e4ngig von den Erwartungen und finanziellen M\u00f6glichkeiten.<\/p>\n

    Das dritte Kriterium \u2013 das mit den Bed\u00fcrfnissen der Entwickler verkn\u00fcpft ist \u2013 kann beispielsweise durch die Organisation von Prozessen innerhalb der Teams gel\u00f6st werden: spezifische Namensgebung von Images, F\u00fchrung spezieller Allow-Listen und interne Vereinbarungen. Letztendlich muss es jedoch dennoch automatisiert werden. Wenn die M\u00f6glichkeiten vorhandener L\u00f6sungen nicht ausreichen, muss man etwas Eigenes entwickeln.<\/p>\n

    \u00c4hnlich verh\u00e4lt es sich mit den zwei ersten Kriterien: Diese k\u00f6nnen nicht ohne die Erfassung von Daten aus einem externen System erf\u00fcllt werden \u2013 n\u00e4mlich dem System, in dem die Anwendungen bereitgestellt werden (in unserem Fall Kubernetes).<\/p>\n

    Illustration des Workflows in Git<\/h3>\n

    \nAngenommen, Sie arbeiten ungef\u00e4hr nach folgendem Schema in Git:<\/p>\n

    \"Das
    \n
    \nAuf dem Diagramm sind die Container-Images mit K\u00f6pfen markiert, die derzeit in Kubernetes f\u00fcr beliebige Benutzer (Endanwender, Tester, Manager usw.) bereitgestellt oder von Entwicklern zur Fehlersuche und \u00e4hnlichen Zwecken verwendet werden.<\/i><\/p>\n

    Was passiert, wenn die Aufr\u00e4umpolitiken zulassen, dass Images nur nach bestimmten Tag-Namen<\/b>?<\/p>\n

    \"Das
    \n
    \noffengelassen (nicht gel\u00f6scht) werden?<\/p>\n

    Offensichtlich wird ein solches Szenario niemanden erfreuen. Was w\u00fcrde sich \u00e4ndern, wenn die Politiken erlauben, Images nicht zu l\u00f6schen<\/b>?<\/p>\n

    \"Das
    \n
    \nnach einem bestimmten Zeitintervall \/ der Anzahl der letzten Commits?<\/p>\n

    Das Ergebnis wurde deutlich besser, ist jedoch immer noch weit von ideal entfernt. Immerhin haben wir immer noch Entwickler, die Images im Repository (oder sogar in K8s bereitgestellt) zur Fehlersuche ben\u00f6tigen ... Zusammenfassend l\u00e4sst sich sagen, dass die im Container-Repository verf\u00fcgbaren Funktionen nicht gen\u00fcgend Flexibilit\u00e4t bei der Bereinigung bieten, und der Hauptgrund daf\u00fcr ist, dass es nicht m\u00f6glich ist, mit der Au\u00dfenwelt zu interagieren.<\/strong>Das bedeutet, dass Teams, die eine solche Flexibilit\u00e4t ben\u00f6tigen, gezwungen sind, das L\u00f6schen von Images \"von au\u00dfen\" selbst zu implementieren, indem sie die Docker Registry API (oder die native API der entsprechenden Implementierung) verwenden.<\/p>\n

    Wir haben jedoch nach einer universellen L\u00f6sung gesucht, die die Bereinigung von Images f\u00fcr verschiedene Teams automatisiert, die unterschiedliche Registries verwenden ...<\/p>\n

    Unser Weg zur universellen Bereinigung von Images<\/h2>\n

    \nWoher kommt diese Notwendigkeit? Wir sind keine isolierte Gruppe von Entwicklern, sondern ein Team, das mehreren solchen Gruppen dient und ihnen hilft, Fragen zu CI\/CD umfassend zu l\u00f6sen. Das wichtigste technische Werkzeug daf\u00fcr ist das Open Source-Tool werf<\/a><\/noindex>. Sein Merkmal ist, dass es nicht nur eine einzelne Funktion ausf\u00fchrt, sondern die kontinuierlichen Lieferprozesse in allen Phasen begleitet: von der Erstellung bis zur Bereitstellung.<\/p>\n

    Die Ver\u00f6ffentlichung in der Registry* von Images (unmittelbar nach ihrer Erstellung) ist eine offensichtliche Funktion eines solchen Tools. Da die Images dort zur Speicherung abgelegt werden, muss man\u2014 falls der Speicher nicht unbegrenzt ist\u2014 auch f\u00fcr deren anschlie\u00dfende Bereinigung sorgen. Im Folgenden wird erl\u00e4utert, wie wir darin erfolgreich waren und alle vorgegebenen Kriterien erf\u00fcllt haben.<\/p>\n

    * Obwohl die Registries unterschiedlich sein k\u00f6nnen (Docker Registry, GitLab Container Registry, Harbor usw.), sehen sich ihre Benutzer denselben Problemen gegen\u00fcber. Die universelle L\u00f6sung h\u00e4ngt in unserem Fall nicht von der Implementierung der Registry ab, da sie au\u00dferhalb der Registries selbst ausgef\u00fchrt wird und f\u00fcr alle das gleiche Verhalten bietet.<\/i><\/p>\n

    Obwohl wir werf als Beispiel f\u00fcr die Implementierung verwenden, hoffen wir, dass die verwendeten Ans\u00e4tze auch anderen Teams, die \u00e4hnlichen Herausforderungen gegen\u00fcberstehen, von Nutzen sein werden.<\/p>\n

    Also haben wir uns mit der externen<\/i> Implementierung eines Mechanismus zur Bereinigung von Images besch\u00e4ftigt \u2014 anstelle der bereits in die Registries f\u00fcr Container integrierten M\u00f6glichkeiten. Der erste Schritt war die Verwendung der Docker Registry API zur Erstellung der oben erw\u00e4hnten grundlegenden Richtlinien hinsichtlich der Anzahl von Tags und deren Erstellungszeit. Dies wurde durch eine Allow-Liste basierend auf den in der bereitgestellten Infrastruktur verwendeten Images erg\u00e4nzt<\/strong>, d.h. Kubernetes. Daf\u00fcr gen\u00fcgte es, \u00fcber die Kubernetes-API alle bereitgestellten Ressourcen zu durchlaufen und eine Liste von Werten zu erhalten. Image<\/code>.<\/p>\n

    Diese triviale L\u00f6sung hat das kritischste Problem (Kriterium Nr. 1) behoben, war jedoch nur der Anfang unseres Weges zur Verbesserung des Reinigungsmechanismus. Der n\u00e4chste \u2013 und weitaus interessantere \u2013 Schritt war die Entscheidung, die ver\u00f6ffentlichten Images mit der Geschichte von Git zu verkn\u00fcpfen.<\/strong>.<\/p>\n

    Tagging-Schemata<\/h3>\n

    \nZu Beginn w\u00e4hlten wir einen Ansatz, bei dem das endg\u00fcltige Image die erforderlichen Informationen f\u00fcr die Reinigung speichern sollte, und wir bauten den Prozess auf Tagging-Schemata auf. Bei der Ver\u00f6ffentlichung des Images w\u00e4hlte der Benutzer eine bestimmte Tagging-Option (git-branch<\/code>, git-commit<\/code> oder git-tag<\/code>), und verwendete den entsprechenden Wert. In CI-Systemen wurden diese Werte automatisch basierend auf Umgebungsvariablen gesetzt. Im Wesentlichen wurde das endg\u00fcltige Image mit einem bestimmten Git-Primitiv verkn\u00fcpft<\/strong>, das die notwendigen Daten f\u00fcr die Bereinigung in Labels speichert.<\/p>\n

    Im Rahmen eines solchen Ansatzes entstand ein Satz von Richtlinien, der es erm\u00f6glichte, Git als einzige Informationsquelle zu verwenden:<\/p>\n