{"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 seine L\u00f6sung in werf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Das
\n
\nIn diesem Artikel wird das Problem der Bereinigung von Images er\u00f6rtert, die in Container-Registries (wie Docker Registry und anderen) in den modernen CI\/CD-Pipelines f\u00fcr cloud-native Anwendungen, die in Kubernetes bereitgestellt werden, angesammelt werden. Es werden die grundlegenden Kriterien f\u00fcr die Relevanz von Images sowie die daraus resultierenden Schwierigkeiten bei der Automatisierung der Bereinigung, dem Platzverbrauch und der Erf\u00fcllung der Bed\u00fcrfnisse der Teams vorgestellt. Schlie\u00dflich zeigen wir anhand eines konkreten Open-Source-Projekts auf, wie diese Herausforderungen \u00fcberwunden werden k\u00f6nnen.<\/p>\n

Einf\u00fchrung<\/h2>\n

\nDie Anzahl der Images in der Container-Registry kann schnell ansteigen, was mehr Speicherplatz beansprucht und somit die Kosten erheblich erh\u00f6ht. Um das Wachstum des Speicherplatzes in der Registry zu kontrollieren, zu begrenzen oder auf einem akzeptablen Niveau zu halten, ist es \u00fcblich:<\/p>\n

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

    <\/a><\/noindex>
    \nDie erste Einschr\u00e4nkung ist manchmal f\u00fcr kleine Teams akzeptabel. Wenn die Entwickler mit den konstanten Tags auskommen (

    , , ...),latest<\/code>, main<\/code>, test<\/code>, boris<\/code> und so weiter), das Register wird nicht aufgebl\u00e4ht, und man muss lange Zeit \u00fcberhaupt nicht an eine Bereinigung denken. Denn alle veralteten Images werden verdr\u00e4ngt, und f\u00fcr die Reinigung bleibt einfach keine Arbeit \u00fcbrig (alles wird vom regul\u00e4ren Garbage Collector erledigt).<\/p>\n

    Dennoch schr\u00e4nkt dieser Ansatz die Entwicklung stark ein und ist selten auf CI\/CD moderner Projekte anwendbar. Ein unverzichtbarer Bestandteil der Entwicklung ist Automatisierung<\/strong>, die es erm\u00f6glicht, neuen Funktionalit\u00e4ten viel schneller zu testen, bereitzustellen und den Nutzern zur Verf\u00fcgung zu stellen. Zum Beispiel wird in all unseren Projekten bei jedem Commit automatisch eine CI-Pipeline erstellt. Dort wird ein Image erstellt, getestet und in verschiedene Kubernetes-Umgebungen zur Fehlerbehebung und weiteren Pr\u00fcfungen bereitgestellt, und wenn alles gut l\u00e4uft, gelangen die \u00c4nderungen an den Endnutzer. Und das ist l\u00e4ngst keine Raketenwissenschaft mehr, sondern f\u00fcr viele ganz normal \u2013 wahrscheinlich auch f\u00fcr Sie, da Sie diesen Artikel lesen.<\/p>\n

    Da das Beheben von Bugs und die Entwicklung neuer Funktionalit\u00e4ten parallel erfolgen und Releases mehrmals t\u00e4glich durchgef\u00fchrt werden k\u00f6nnen, ist offensichtlich, dass der Entwicklungsprozess mit einer erheblichen Anzahl von Commits verbunden ist, und das bedeutet \u2013 eine gro\u00dfe Anzahl von Abbildungen im Registry<\/strong>. Infolgedessen stellt sich die dringende Frage nach der effektiven Bereinigung des Registrys, d.h. der Entfernung nicht aktueller Abbildungen.<\/p>\n

    Aber wie l\u00e4sst sich \u00fcberhaupt bestimmen, ob eine Abbildung aktuell ist?<\/p>\n

    Kriterien f\u00fcr die Aktualit\u00e4t von Abbildungen<\/h2>\n

    \nIn den \u00fcberwiegenden meisten F\u00e4llen sind die Hauptkriterien wie folgt:<\/p>\n

    1. Das erste (das offensichtlichste und kritischste von allen) \u2014 sind die Abbildungen, die aktuell in Kubernetes verwendet werden.<\/strong>Das L\u00f6schen dieser Abbildungen kann ernsthafte Kosten aufgrund von Produktionsausfall verursachen (z.B. k\u00f6nnen diese Abbildungen bei der Replikation ben\u00f6tigt werden) oder die Bem\u00fchungen des Teams, das an der Fehlerbehebung in einem der Konturen arbeitet, zunichte machen. (Aus diesem Grund haben wir sogar einen speziellen <\/i>Prometheus-Exporter<\/i><\/a><\/noindex>, der das Fehlen solcher Abbildungen in jedem Kubernetes-Cluster \u00fcberwacht.)<\/i><\/p>\n

    2. Das zweite (weniger offensichtlich, aber ebenfalls sehr wichtig und erneut betrieblich relevant) \u2014 sind Abbildungen, die f\u00fcr einen Rollback ben\u00f6tigt werden, wenn ernsthafte Probleme auftreten.<\/strong> in der aktuellen Version. Zum Beispiel betrifft es bei Helm die Abbilder, die in den gespeicherten Versionen des Releases verwendet werden. (\u00dcbrigens liegt das Standardlimit in Helm bei 256 Revisionen, aber ich bezweifle, dass jemand tats\u00e4chlich einen so hohen Bedarf an der Aufbewahrung hat. so vieler<\/i> Versionen?..) Schlie\u00dflich speichern wir Versionen unter anderem, um sie sp\u00e4ter nutzen zu k\u00f6nnen, d.h. um im Bedarfsfall \"zur\u00fcckzurollen\".<\/p>\n

    3. Der dritte \u2014 Bed\u00fcrfnisse der Entwickler<\/strong>: alle Abbilder, die mit ihren aktuellen Arbeiten in Verbindung stehen. Wenn wir beispielsweise einen PR betrachten, ist es sinnvoll, das Abbild des letzten Commits und, sagen wir, des vorherigen Commits zu behalten: So kann der Entwickler schnell zu jeder Aufgabe zur\u00fcckkehren und mit den letzten \u00c4nderungen arbeiten. <\/p>\n

    4. Der vierte \u2014 Abbilder, die entsprechend den Versionen unserer Anwendung<\/strong>, d.h. die Endprodukte darstellen: v1.0.0, 20.04.01, sierra usw.<\/p>\n

    Hinweis: Die hier definierten Kriterien basieren auf Erfahrungen aus der Zusammenarbeit mit Dutzenden von Entwicklerteams verschiedener Unternehmen. Allerdings k\u00f6nnen diese Kriterien je nach den spezifischen Entwicklungsprozessen und der verwendeten Infrastruktur (z. B. wenn Kubernetes nicht eingesetzt wird) variieren. <\/p>\n

    Einhaltung der Kriterien und bestehende L\u00f6sungen<\/h2>\n

    \nBeliebte Dienste mit Container-Registries bieten in der Regel eigene Richtlinien zur Bereinigung von Images an: In diesen k\u00f6nnen Sie festlegen, unter welchen Bedingungen ein Tag aus der Registry entfernt wird. Die M\u00f6glichkeiten dieser Bedingungen sind jedoch durch Parameter wie Namen, Erstellungszeit und Anzahl der Tags* begrenzt.<\/p>\n

    * Abh\u00e4ngig von den spezifischen Implementierungen des Container-Registrys. Wir haben die M\u00f6glichkeiten der folgenden L\u00f6sungen gepr\u00fcft: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io \u2013 Stand September 2020.<\/i><\/p>\n

    Dieses Set an Parametern reicht aus, um das vierte Kriterium zu erf\u00fcllen \u2013 also um Images auszuw\u00e4hlen, die mit den Versionen \u00fcbereinstimmen. F\u00fcr alle anderen Kriterien muss jedoch eine Art Kompromissl\u00f6sung gefunden werden (eine strengere oder eher mildere Politik), abh\u00e4ngig von den Erwartungen und finanziellen M\u00f6glichkeiten.<\/p>\n

    Das dritte Kriterium \u2013 das mit den Bed\u00fcrfnissen der Entwickler zusammenh\u00e4ngt \u2013 kann durch die Organisation der internen Teamprozesse gel\u00f6st werden: spezifische Namensgebungen von Images, F\u00fchrung spezieller Allow-Listen und interne Vereinbarungen. Letztendlich muss es jedoch auch automatisiert werden. Wenn die vorhandenen L\u00f6sungen nicht ausreichen, bleibt oft nur, etwas Eigenes zu schaffen.<\/p>\n

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

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

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

    \"Das
    \n
    \nDie Symbole mit dem Kopf in dem Diagramm kennzeichnen die Container-Images, die derzeit in Kubernetes f\u00fcr verschiedene Benutzer (Endbenutzer, Tester, Manager usw.) bereitgestellt oder von Entwicklern zu Debugging- und \u00e4hnlichen Zwecken verwendet werden.<\/i><\/p>\n

    Was passiert, wenn die Aufbewahrungsrichtlinien erlauben, Images nur bei bestimmten Tag-Namen zu belassen (nicht zu l\u00f6schen)? offensichtlich wird ein solches Szenario niemanden erfreuen.<\/b>?<\/p>\n

    \"Das
    \n
    \nWas \u00e4ndert sich, wenn die Richtlinien das Behalten von Images erlauben?<\/p>\n

    basierend auf einem bestimmten Zeitintervall \/ der Anzahl der letzten Commits? Das Ergebnis hat sich deutlich verbessert, bleibt jedoch nach wie vor weit vom Ideal entfernt. Immerhin gibt es weiterhin Entwickler, die Images im Repository (oder sogar in K8s bereitgestellt) ben\u00f6tigen, um Bugs zu debuggen\u2026<\/b>?<\/p>\n

    \"Das
    \n
    \nZusammenfassend l\u00e4sst sich sagen, dass die in den Container-Repositories verf\u00fcgbaren Funktionen nicht die notwendige Flexibilit\u00e4t beim Cleanup bieten, und der Hauptgrund daf\u00fcr ist,<\/p>\n

    dass keine M\u00f6glichkeit besteht, mit der Au\u00dfenwelt zu interagieren. keine M\u00f6glichkeit, mit der Au\u00dfenwelt zu interagieren<\/strong>. Das bedeutet, dass Teams, die solche Flexibilit\u00e4t ben\u00f6tigen, gezwungen sind, das L\u00f6schen von Images \u201evon au\u00dfen\u201c selbst umzusetzen, indem sie die Docker Registry API (oder die native API der entsprechenden Implementierung) verwenden.<\/p>\n

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

    Unser Weg zur universellen Image-Bereinigung<\/h2>\n

    \nWarum besteht diese Notwendigkeit? Wir sind nicht eine isolierte Gruppe von Entwicklern, sondern ein Team, das viele solche Gruppen unterst\u00fctzt und hilft, CI\/CD-Fragen umfassend zu l\u00f6sen. Das wichtigste technische Tool daf\u00fcr ist eine Open Source-Anwendung werf<\/a><\/noindex>. Ihre Besonderheit ist, dass sie nicht nur eine einzige Funktion erf\u00fcllt, sondern die kontinuierlichen Lieferprozesse in allen Phasen begleitet: von der Erstellung bis zur Bereitstellung.<\/p>\n

    Die Ver\u00f6ffentlichung in einem Registry* (sofort nach der Erstellung) ist eine offensichtliche Funktion eines solchen Tools. Da die Images dort gespeichert werden, m\u00fcssen\u2014falls Ihr Speicher nicht unbegrenzt ist\u2014auch deren anschlie\u00dfende Bereinigung gew\u00e4hrleistet sein. Im Folgenden wird erl\u00e4utert, wie wir dies erfolgreich umgesetzt haben, w\u00e4hrend wir alle festgelegten Kriterien erf\u00fcllt haben.<\/p>\n

    * Auch wenn die Registries unterschiedlich sein k\u00f6nnen (Docker Registry, GitLab Container Registry, Harbor usw.), stehen ihre Benutzer vor \u00e4hnlichen Herausforderungen. Eine universelle L\u00f6sung in unserem Fall h\u00e4ngt nicht von der Implementierung der Registry ab, da sie au\u00dferhalb der Registries selbst durchgef\u00fchrt wird und f\u00fcr alle dasselbe Verhalten bietet.<\/i><\/p>\n

    Obwohl wir werf als Beispiel f\u00fcr die Implementierung nutzen, hoffen wir, dass die verwendeten Ans\u00e4tze auch anderen Teams, die vor \u00e4hnlichen Schwierigkeiten stehen, n\u00fctzlich sein werden.<\/p>\n

    Also haben wir uns mit externen<\/i> Implementierung eines Mechanismus zur Bereinigung von Images besch\u00e4ftigt \u2013 anstelle der bereits in den Registries f\u00fcr Container integrierten M\u00f6glichkeiten. Der erste Schritt war die Nutzung der Docker Registry API zur Erstellung einfacher Richtlinien hinsichtlich der Anzahl der Tags und ihrer Erstellungszeit (wie oben erw\u00e4hnt). Dazu wurde eine Allow-Liste basierend auf den Images, die in der bereitgestellten Infrastruktur verwendet werden, hinzugef\u00fcgt<\/strong>, d.h. Kubernetes. F\u00fcr letzteres gen\u00fcgte es, \u00fcber die Kubernetes API alle bereitgestellten Ressourcen zu durchlaufen und eine Liste der Werte zu erhalten, image<\/code>.<\/p>\n

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

    Tagging-Schemata<\/h3>\n

    \nZu Beginn w\u00e4hlten wir einen Ansatz, bei dem das endg\u00fcltige Image die notwendige Information f\u00fcr die Reinigung speichern sollte, und wir bauten den Prozess auf Tagging-Schemata auf. Bei der Ver\u00f6ffentlichung eines 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 Grunde genommen wurde das endg\u00fcltige Image mit einem bestimmten Git-Primitiv verkn\u00fcpft<\/strong>, wobei die erforderlichen Daten f\u00fcr die Reinigung in Labels gespeichert wurden.<\/p>\n

    Im Rahmen dieses Ansatzes entstand ein Satz von Richtlinien, die es erm\u00f6glichten, Git als einzige Quelle der Wahrheit zu verwenden:<\/p>\n