{"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\/pl\/blog\/administrirovanie\/problema-umnoj-ochistki-obrazov-kontejnerov-i-eyo-reshenie-v-werf","title":{"rendered":"Problem z \"inteligentnym\" czyszczeniem obraz\u00f3w kontener\u00f3w oraz jego rozwi\u0105zanie w werf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Problem
\n
\nArtyku\u0142 omawia problematyk\u0119 usuwania obraz\u00f3w, kt\u00f3re gromadz\u0105 si\u0119 w rejestrach kontener\u00f3w (Docker Registry i jego odpowiednikach) w kontek\u015bcie nowoczesnych pipeline'\u00f3w CI\/CD dla aplikacji cloud native dostarczanych do Kubernetes. Przedstawiono g\u0142\u00f3wne kryteria aktualno\u015bci obraz\u00f3w oraz zwi\u0105zane z nimi trudno\u015bci przy automatyzacji czyszczenia, oszcz\u0119dzania miejsca i zaspokajania potrzeb zespo\u0142\u00f3w. Wreszcie, na przyk\u0142adzie konkretnego projektu Open Source przedstawimy, jak mo\u017cna przezwyci\u0119\u017cy\u0107 te trudno\u015bci.<\/p>\n

Wprowadzenie<\/h2>\n

\nLiczba obraz\u00f3w w rejestrze kontener\u00f3w mo\u017ce szybko rosn\u0105\u0107, zajmuj\u0105c coraz wi\u0119cej miejsca w magazynie, a tym samym znacznie zwi\u0119kszaj\u0105c jego koszt. Aby kontrolowa\u0107, ogranicza\u0107 lub utrzymywa\u0107 akceptowalny wzrost zajmowanego miejsca w rejestrze, przyj\u0119to:<\/p>\n

    \n
  1. u\u017cywa\u0107 sta\u0142ej liczby tag\u00f3w dla obraz\u00f3w;<\/li>\n
  2. w jaki\u015b spos\u00f3b czy\u015bci\u0107 obrazy.<\/li>\n<\/ol>\n

    <\/a><\/noindex>
    \nPierwsze ograniczenie jest czasami dopuszczalne dla ma\u0142ych zespo\u0142\u00f3w. Je\u015bli programi\u015bci wystarczaj\u0105co cz\u0119sto korzystaj\u0105 z sta\u0142ych tag\u00f3w (latest<\/code>, main<\/code>, test<\/code>, boris<\/code> itp.), rejestr nie b\u0119dzie si\u0119 powi\u0119ksza\u0142 w rozmiarze i przez d\u0142ugi czas mo\u017cna w og\u00f3le nie my\u015ble\u0107 o czyszczeniu. Wszystkie przestarza\u0142e obrazy s\u0105 nadpisywane, a do czyszczenia po prostu nie zostaje \u017cadna praca (wszystko robi standardowy zbieracz \u015bmieci).<\/p>\n

    Jednak\u017ce takie podej\u015bcie znacznie ogranicza rozw\u00f3j i rzadko znajduje zastosowanie w CI\/CD nowoczesnych projekt\u00f3w. Niezb\u0119dnym elementem rozwoju sta\u0142a si\u0119 automatyzacja<\/strong>, kt\u00f3ra pozwala znacznie szybciej testowa\u0107, wdra\u017ca\u0107 i dostarcza\u0107 nowe funkcje u\u017cytkownikom. Na przyk\u0142ad, w naszych wszystkich projektach przy ka\u017cdym commitcie automatycznie tworzony jest pipeline CI. W nim zbierany jest obraz, testowany, wdra\u017cany do r\u00f3\u017cnych kontur\u00f3w Kubernetes do debugowania i pozosta\u0142ych kontroli, a je\u015bli wszystko dobrze \u2014 zmiany trafiaj\u0105 do ko\u0144cowego u\u017cytkownika. I to ju\u017c dawno przesta\u0142o by\u0107 rocket science, a sta\u0142o si\u0119 codzienno\u015bci\u0105 dla wielu \u2014 prawdopodobnie i dla Ciebie, skoro czytasz ten artyku\u0142.<\/p>\n

    Poniewa\u017c eliminacja b\u0142\u0119d\u00f3w i rozw\u00f3j nowych funkcji odbywa si\u0119 r\u00f3wnolegle, a wydania mog\u0105 mie\u0107 miejsce kilka razy dziennie, oczywiste jest, \u017ce proces rozwoju towarzyszy znaczna liczba commit\u00f3w, a wi\u0119c \u2014 du\u017ca liczba obraz\u00f3w w rejestrze<\/strong>. W rezultacie, pilnie rodzi si\u0119 pytanie o organizacj\u0119 efektywnego czyszczenia rejestru, tzn. usuwania przestarza\u0142ych obraz\u00f3w.<\/p>\n

    Jak w og\u00f3le okre\u015bli\u0107, czy obraz jest aktualny?<\/p>\n

    Kryteria aktualno\u015bci obrazu<\/h2>\n

    \nW przewa\u017caj\u0105cej wi\u0119kszo\u015bci przypadk\u00f3w g\u0142\u00f3wne kryteria b\u0119d\u0105 nast\u0119puj\u0105ce:<\/p>\n

    1. Pierwsze (najs\u0142ynniejsze i najbardziej krytyczne z wszystkich) \u2014 to obrazy, kt\u00f3re s\u0105 obecnie u\u017cywane w Kubernetes<\/strong>. Usuni\u0119cie tych obraz\u00f3w mo\u017ce prowadzi\u0107 do powa\u017cnych koszt\u00f3w zwi\u0105zanych z przestojami produkcji (na przyk\u0142ad obrazy mog\u0105 by\u0107 potrzebne podczas replikacji) lub uniewa\u017cni\u0107 wysi\u0142ki zespo\u0142u zajmuj\u0105cego si\u0119 debugowaniem w jednym z obszar\u00f3w. (Z tego powodu stworzyli\u015bmy nawet specjalny <\/i>eksporter Prometheus<\/i><\/a><\/noindex>, kt\u00f3ry monitoruje brak takich obraz\u00f3w w dowolnym klastrze Kubernetes.)<\/i><\/p>\n

    2. Drugie (mniej oczywiste, ale r\u00f3wnie\u017c bardzo wa\u017cne i ponownie zwi\u0105zane z eksploatacj\u0105) \u2014 to obrazy, kt\u00f3re s\u0105 potrzebne do rollbacku w przypadku wykrycia powa\u017cnych problem\u00f3w<\/strong> w aktualnej wersji. Na przyk\u0142ad w przypadku Helm to obrazy, kt\u00f3re s\u0105 u\u017cywane w zapisanych wersjach release'u. (Swoj\u0105 drog\u0105, domy\u015blnie w Helm jest limit 256 rewizji, ale czy ktokolwiek naprawd\u0119 potrzebuje zachowa\u0107 tak du\u017c\u0105<\/i> liczb\u0119 wersji?..) W ko\u0144cu przechowujemy wersje, aby mo\u017cna je by\u0142o p\u00f3\u017aniej wykorzysta\u0107, to znaczy 'wraca\u0107' do nich w razie potrzeby.<\/p>\n

    3. Trzecie \u2014 potrzeby deweloper\u00f3w<\/strong>: wszystkie obrazy, kt\u00f3re s\u0105 zwi\u0105zane z ich aktualnymi pracami. Na przyk\u0142ad je\u015bli rozwa\u017camy PR, warto pozostawi\u0107 obraz, kt\u00f3ry odpowiada ostatniemu commitowi i powiedzmy poprzedniemu commitowi: dzi\u0119ki temu deweloper b\u0119dzie m\u00f3g\u0142 szybko powr\u00f3ci\u0107 do dowolnego zadania i pracowa\u0107 z najnowszymi zmianami. <\/p>\n

    4. Czwarte \u2014 obrazy, kt\u00f3re odpowiadaj\u0105 wersjom naszej aplikacji<\/strong>, to znaczy s\u0105 ko\u0144cowym produktem: v1.0.0, 20.04.01, sierra itd.<\/p>\n

    NB: Kryteria okre\u015blone tutaj zosta\u0142y sformu\u0142owane na podstawie do\u015bwiadcze\u0144 z pracy z dziesi\u0105tkami zespo\u0142\u00f3w deweloperskich z r\u00f3\u017cnych firm. Jednak oczywi\u015bcie w zale\u017cno\u015bci od charakterystyki proces\u00f3w deweloperskich i u\u017cywanej infrastruktury (na przyk\u0142ad, je\u015bli Kubernetes nie jest u\u017cywany), kryteria te mog\u0105 si\u0119 r\u00f3\u017cni\u0107. <\/p>\n

    Zgodno\u015b\u0107 z kryteriami i istniej\u0105ce rozwi\u0105zania<\/h2>\n

    \nPopularne us\u0142ugi z rejestrem kontener\u00f3w zazwyczaj oferuj\u0105 w\u0142asne zasady usuwania obraz\u00f3w: mo\u017cna w nich okre\u015bla\u0107 warunki, na jakich tag jest usuwany z rejestru. Mo\u017cliwo\u015bci tych warunk\u00f3w ograniczaj\u0105 si\u0119 jednak do takich parametr\u00f3w, jak nazwy, czas utworzenia i liczba tag\u00f3w*.<\/p>\n

    * Zale\u017cy to od konkretnych realizacji rejestru kontener\u00f3w. Rozwa\u017cali\u015bmy mo\u017cliwo\u015bci nast\u0119puj\u0105cych rozwi\u0105za\u0144: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io \u2014 stan na wrzesie\u0144 2020.<\/i><\/p>\n

    Taki zestaw parametr\u00f3w jest w zupe\u0142no\u015bci wystarczaj\u0105cy, aby spe\u0142ni\u0107 czwarty kryterium \u2014 czyli do selekcji obraz\u00f3w odpowiadaj\u0105cych wersjom. Jednak dla wszystkich pozosta\u0142ych kryteri\u00f3w trzeba wybiera\u0107 jakie\u015b kompromisowe rozwi\u0105zanie (bardziej rygorystyczn\u0105 lub, przeciwnie, \u0142agodniejsz\u0105 polityk\u0119) \u2014 w zale\u017cno\u015bci od oczekiwa\u0144 i mo\u017cliwo\u015bci finansowych.<\/p>\n

    Na przyk\u0142ad trzecie kryterium \u2014 zwi\u0105zane z potrzebami deweloper\u00f3w \u2014 mo\u017cna rozwi\u0105za\u0107 poprzez organizacj\u0119 proces\u00f3w wewn\u0105trz zespo\u0142\u00f3w: specyficzne nazewnictwo obraz\u00f3w, prowadzenie specjalnych list dozwolonych oraz wewn\u0119trzne ustalenia. Ale ostatecznie to i tak trzeba zautomatyzowa\u0107. A je\u015bli mo\u017cliwo\u015bci gotowych rozwi\u0105za\u0144 s\u0105 niewystarczaj\u0105ce, trzeba stworzy\u0107 co\u015b w\u0142asnego.<\/p>\n

    Podobna sytuacja dotyczy dw\u00f3ch pierwszych kryteri\u00f3w: nie mo\u017cna ich zaspokoi\u0107 bez uzyskania danych z zewn\u0119trznego systemu \u2014 tego samego, w kt\u00f3rym odbywa si\u0119 wdra\u017canie aplikacji (w naszym przypadku jest to Kubernetes).<\/p>\n

    Ilustracja workflow w Git<\/h3>\n

    \nZak\u0142adaj\u0105c, \u017ce pracujesz mniej wi\u0119cej wed\u0142ug takiego schematu w Git:<\/p>\n

    \"Problem
    \n
    \nIkona z g\u0142ow\u0105 na schemacie oznacza obrazy kontener\u00f3w, kt\u00f3re w danym momencie s\u0105 wdro\u017cone w Kubernetes dla jakichkolwiek u\u017cytkownik\u00f3w (u\u017cytkownik\u00f3w ko\u0144cowych, tester\u00f3w, mened\u017cer\u00f3w itd.) lub u\u017cywane przez deweloper\u00f3w do debugowania i podobnych cel\u00f3w.<\/i><\/p>\n

    Co si\u0119 stanie, je\u015bli zasady usuwania pozwalaj\u0105 na pozostawienie (nieusuni\u0119cie) obraz\u00f3w tylko po okre\u015blonych nazwach tag\u00f3w<\/b>?<\/p>\n

    \"Problem
    \n
    \nOczywi\u015bcie, taki scenariusz nikogo nie ucieszy.<\/p>\n

    Co si\u0119 zmieni, je\u015bli zasady pozwalaj\u0105 na nieusuwanie obraz\u00f3w po okre\u015blonym przedziale czasowym \/ liczbie ostatnich commit\u00f3w<\/b>?<\/p>\n

    \"Problem
    \n
    \nWynik sta\u0142 si\u0119 znacznie lepszy, jednak wci\u0105\u017c jest daleki od idea\u0142u. Przecie\u017c mamy wci\u0105\u017c deweloper\u00f3w, kt\u00f3rzy potrzebuj\u0105 obraz\u00f3w w rejestrze (lub nawet wdro\u017conych w K8s) do debugowania b\u0142\u0119d\u00f3w\u2026<\/p>\n

    Podsumowuj\u0105c sytuacj\u0119 na rynku: dost\u0119pne w rejestrach kontener\u00f3w funkcje nie oferuj\u0105 wystarczaj\u0105cej elastyczno\u015bci przy czyszczeniu, a g\u0142\u00f3wnym powodem jest brak mo\u017cliwo\u015bci interakcji ze \u015bwiatem zewn\u0119trznym<\/strong>. Okazuje si\u0119, \u017ce zespo\u0142y, kt\u00f3re potrzebuj\u0105 takiej elastyczno\u015bci, s\u0105 zmuszone do samodzielnego realizowania usuwania obraz\u00f3w \u201ena zewn\u0105trz\u201d, korzystaj\u0105c z Docker Registry API (lub natywnego API odpowiedniej implementacji).<\/p>\n

    Szukali\u015bmy jednak uniwersalnego rozwi\u0105zania, kt\u00f3re automatyzowa\u0142oby czyszczenie obraz\u00f3w dla r\u00f3\u017cnych zespo\u0142\u00f3w korzystaj\u0105cych z r\u00f3\u017cnych rejestr\u00f3w\u2026<\/p>\n

    Nasza droga do uniwersalnego czyszczenia obraz\u00f3w<\/h2>\n

    \nSk\u0105d taka potrzeba? Sprawa polega na tym, \u017ce nie jeste\u015bmy oddzieln\u0105 grup\u0105 programist\u00f3w, ale zespo\u0142em, kt\u00f3ry obs\u0142uguje wiele takich grup, pomagaj\u0105c kompleksowo rozwi\u0105zywa\u0107 problemy CI\/CD. A g\u0142\u00f3wnym narz\u0119dziem technicznym w tym celu jest Open Source-owa aplikacja werf<\/a><\/noindex>. Jej cech\u0105 charakterystyczn\u0105 jest to, \u017ce nie wykonuje jednej funkcji, ale towarzyszy procesom ci\u0105g\u0142ej dostawy na wszystkich etapach: od budowy po wdro\u017cenie.<\/p>\n

    Publikacja w rejestrze* obraz\u00f3w (zaraz po ich zbudowaniu) \u2014 oczywista funkcja takiej aplikacji. A poniewa\u017c obrazy s\u0105 tam przechowywane, to \u2014 je\u017celi twoje miejsce przechowywania nie jest nieograniczone \u2014 musisz r\u00f3wnie\u017c odpowiada\u0107 za ich p\u00f3\u017aniejsze czyszczenie. O tym, jak osi\u0105gn\u0119li\u015bmy sukces w tej kwestii, spe\u0142niaj\u0105c wszystkie zadane kryteria, b\u0119dzie mowa dalej.<\/p>\n

    * Chocia\u017c same rejestry mog\u0105 by\u0107 r\u00f3\u017cne (Docker Registry, GitLab Container Registry, Harbor itp.), ich u\u017cytkownicy napotykaj\u0105 te same problemy. Uniwersalne rozwi\u0105zanie w naszym przypadku nie zale\u017cy od implementacji rejestru, poniewa\u017c wykonuje si\u0119 poza samymi rejestrami i oferuje jednolite zachowanie dla wszystkich.<\/i><\/p>\n

    Mimo \u017ce u\u017cywamy werf jako przyk\u0142ad implementacji, mamy nadziej\u0119, \u017ce zastosowane podej\u015bcia b\u0119d\u0105 przydatne r\u00f3wnie\u017c innym zespo\u0142om, kt\u00f3re napotka\u0142y podobne trudno\u015bci.<\/p>\n

    Zaj\u0119li\u015bmy si\u0119 zewn\u0119trzn\u0105<\/i> implementacj\u0105 mechanizmu do czyszczenia obraz\u00f3w \u2014 zamiast tych mo\u017cliwo\u015bci, kt\u00f3re s\u0105 ju\u017c wbudowane w rejestry dla kontener\u00f3w. Pierwszym krokiem by\u0142o u\u017cycie Docker Registry API do stworzenia tych samych prostych polityk dotycz\u0105cych liczby tag\u00f3w i czasu ich stworzenia (wspomnianych wcze\u015bniej). Do nich dodano list\u0119 dozwolon\u0105 na podstawie obraz\u00f3w u\u017cywanych w wdro\u017conej infrastrukturze<\/strong>, czyli Kubernetes. Dla tego ostatniego wystarczy\u0142o, aby przeszuka\u0107 wszystkie wdro\u017cone zasoby za pomoc\u0105 Kubernetes API i uzyska\u0107 list\u0119 warto\u015bci. image<\/code>.<\/p>\n

    To trywialne rozwi\u0105zanie zamkn\u0119\u0142o najwa\u017cniejszy problem (kryterium nr 1), ale by\u0142o tylko pocz\u0105tkiem naszej drogi do poprawy mechanizmu oczyszczania. Kolejnym \u2014 i znacznie ciekawszym \u2014 krokiem by\u0142o rozwi\u0105zanie po\u0142\u0105czenia publikowanych obraz\u00f3w z histori\u0105 Git.<\/strong>.<\/p>\n

    Schematy tagowania<\/h3>\n

    \nNa pocz\u0105tek wybrali\u015bmy podej\u015bcie, w kt\u00f3rym ko\u0144cowy obraz musi przechowywa\u0107 niezb\u0119dne informacje do oczyszczania, i opracowali\u015bmy proces oparty na schematach tagowania. Podczas publikacji obrazu u\u017cytkownik wybiera\u0142 okre\u015blon\u0105 opcj\u0119 tagowania (git-branch<\/code>, git-commit<\/code> lub git-tag<\/code>) i u\u017cywa\u0142 odpowiedniej warto\u015bci. W systemach CI te warto\u015bci by\u0142y ustawiane automatycznie na podstawie zmiennych \u015brodowiskowych. W istocie ko\u0144cowy obraz by\u0142 powi\u0105zany z okre\u015blonym Gitem-prymitywem<\/strong>, przechowuj\u0105c niezb\u0119dne dane do oczyszczania w etykietach.<\/p>\n

    W ramach tego podej\u015bcia powsta\u0142 zbi\u00f3r polityk, kt\u00f3re pozwala\u0142y u\u017cywa\u0107 Git jako jedynego \u017ar\u00f3d\u0142a prawdy:<\/p>\n