ProHoster > Blogs > Administrācija > Konteineru attēlu "gudrās" tÄ«rÄ«Å”anas problēma un tās risinājums werf

Konteineru attēlu "gudrās" tÄ«rÄ«Å”anas problēma un tās risinājums werf

Konteineru attēlu "gudrās" tÄ«rÄ«Å”anas problēma un tās risinājums werf

Rakstā ir apskatÄ«tas konteineru reÄ£istros (Docker Registry un tā analogos) uzkrājuÅ”os attēlu tÄ«rÄ«Å”anas problēmas mÅ«sdienu CI/CD konveijeru realitātē mākoņdatoÅ”anas lietojumprogrammām, kas tiek piegādātas Kubernetes. Tiek doti galvenie kritēriji attēlu atbilstÄ«bai un no tā izrietoÅ”ajām grÅ«tÄ«bām tÄ«rÄ«Å”anas automatizācijā, vietas taupÄ«Å”anā un komandu vajadzÄ«bu apmierināŔanā. Visbeidzot, izmantojot konkrēta atvērtā koda projekta piemēru, mēs jums pastāstÄ«sim, kā Ŕīs grÅ«tÄ«bas var pārvarēt.

Ievads

Attēlu skaits konteineru reģistrā var strauji pieaugt, aizņemot vairāk vietas krātuvē un tādējādi ievērojami palielinot tā izmaksas. Lai kontrolētu, ierobežotu vai uzturētu pieņemamu reģistrā aizņemtās vietas pieaugumu, tiek pieņemts:

  1. izmantot fiksētu skaitu tagu attēliem;
  2. kaut kādā veidā notīriet attēlus.


Pirmais ierobežojums dažkārt ir pieņemams mazām komandām. Ja izstrādātājiem ir pietiekami daudz pastāvÄ«go atzÄ«mju (latest, main, test, boris utt.), reÄ£istrs nepalielināsies un ilgu laiku jums vispār nebÅ«s jādomā par tā tÄ«rÄ«Å”anu. Galu galā visi neatbilstoÅ”ie attēli tiek izdzēsti, un tÄ«rÄ«Å”anai vienkārÅ”i neatliek darba (visu dara parasts atkritumu savācējs).

Tomēr Ŕī pieeja ievērojami ierobežo attÄ«stÄ«bu un reti ir piemērojama mÅ«sdienu CI/CD projektiem. Neatņemama attÄ«stÄ«bas sastāvdaļa bija automatizācija, kas ļauj daudz ātrāk pārbaudÄ«t, izvietot un piegādāt lietotājiem jaunas funkcionalitātes. Piemēram, visos mÅ«su projektos CI konveijers tiek automātiski izveidots ar katru apņemÅ”anos. Tajā attēls tiek samontēts, testēts, izrullēts dažādās Kubernetes shēmās atkļūdoÅ”anai un atlikuÅ”ajām pārbaudēm, un, ja viss ir kārtÄ«bā, izmaiņas nonāk lÄ«dz gala lietotājam. Un tā vairs nav raÄ·eÅ”u zinātne, bet gan ikdiena daudziem ā€“ visticamāk, jums, jo lasāt Å”o rakstu.

Tā kā kļūdu laboÅ”ana un jaunas funkcionalitātes izstrāde tiek veikta paralēli un izlaidumus var veikt vairākas reizes dienā, ir acÄ«mredzams, ka izstrādes procesu pavada ievērojams skaits commit, kas nozÄ«mē liels skaits attēlu reÄ£istrā. Rezultātā rodas jautājums par efektÄ«vas reÄ£istra tÄ«rÄ«Å”anas organizÄ“Å”anu, t.i. neatbilstoÅ”u attēlu noņemÅ”ana.

Bet kā vispār noteikt, vai attēls ir atbilstoÅ”s?

Attēla atbilstības kritēriji

Lielākajā daļā gadījumu galvenie kritēriji būs:

1. Pirmais (visredzamākais un kritiskākais no visiem) ir attēli, kas paÅ”laik izmanto Kubernetes. Å o attēlu noņemÅ”ana var radÄ«t ievērojamas ražoÅ”anas dÄ«kstāves izmaksas (piemēram, attēli var bÅ«t nepiecieÅ”ami replikācijai) vai liegt komandai veikt atkļūdoÅ”anu jebkurā no cilpām. (Å Ä« iemesla dēļ mēs pat izveidojām Ä«paÅ”u Prometheus eksportētāji, kas izseko Ŕādu attēlu neesamÄ«bu nevienā Kubernetes klasterÄ«.)

2. Otrais (mazāk acÄ«mredzams, bet arÄ« ļoti svarÄ«gs un atkal saistÄ«ts ar ekspluatāciju) - attēli, kas nepiecieÅ”ama atcelÅ”anai nopietnu problēmu atklāŔanas gadÄ«jumā paÅ”reizējā versijā. Piemēram, Helm gadÄ«jumā tie ir attēli, kas tiek izmantoti saglabātajās laidiena versijās. (Starp citu, Helmā pēc noklusējuma ierobežojums ir 256 pārskati, taču maz ticams, ka kādam patieŔām bÅ«s jāsaglabā tāds liels skaits versiju?..) Galu galā mēs, jo Ä«paÅ”i, glabājam versijas, lai mēs tās varētu izmantot vēlāk, t.i. ā€œatgriezietiesā€ pie viņiem, ja nepiecieÅ”ams.

3. TreÅ”ais ā€” izstrādātāju vajadzÄ«bām: visi attēli, kas ir saistÄ«ti ar viņu paÅ”reizējo darbu. Piemēram, ja mēs apsveram PR, tad ir jēga atstāt attēlu, kas atbilst pēdējai un, teiksim, iepriekŔējai apņemÅ”anai: tādā veidā izstrādātājs var ātri atgriezties pie jebkura uzdevuma un strādāt ar jaunākajām izmaiņām.

4. Ceturtkārt - attēli, kas atbilst mūsu lietojumprogrammas versijām, t.i. ir gala produkts: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra utt.

NB: Å eit definētie kritēriji tika formulēti, pamatojoties uz pieredzi, sadarbojoties ar desmitiem izstrādes komandu no dažādiem uzņēmumiem. Taču, protams, atkarÄ«bā no specifikas izstrādes procesos un izmantotās infrastruktÅ«ras (piemēram, netiek izmantota Kubernetes), Å”ie kritēriji var atŔķirties.

Atbilstība un esoŔie risinājumi

Populārie pakalpojumi ar konteineru reÄ£istriem, kā likums, piedāvā savas attēlu tÄ«rÄ«Å”anas politikas: tajās varat definēt nosacÄ«jumus, kādos atzÄ«me tiek noņemta no reÄ£istra. Tomēr Å”os nosacÄ«jumus ierobežo tādi parametri kā nosaukumi, izveides laiks un tagu skaits*.

* AtkarÄ«gs no konkrēta konteinera reÄ£istra ievieÅ”anas. Mēs izskatÄ«jām Ŕādu risinājumu iespējas: Azure CR, Docker Hub, ECR, GCR, GitHub Packages, GitLab Container Registry, Harbor Registry, JFrog Artifactory, Quay.io ā€” no 2020. gada septembra.

Å is parametru kopums ir pilnÄ«gi pietiekams, lai izpildÄ«tu ceturto kritēriju - tas ir, lai atlasÄ«tu versijām atbilstoÅ”us attēlus. Taču visiem pārējiem kritērijiem ir jāizvēlas kāds kompromisa risinājums (stingrāka vai, tieÅ”i otrādi, pielaidÄ«gāka politika) ā€“ atkarÄ«bā no cerÄ«bām un finansiālajām iespējām.

Piemēram, treÅ”o ā€“ ar izstrādātāju vajadzÄ«bām saistÄ«to ā€“ kritēriju var atrisināt, organizējot procesus komandās: konkrētu attēlu nosaukÅ”anu, Ä«paÅ”u atļauju sarakstu un iekŔējo lÄ«gumu uzturÄ“Å”anu. Bet galu galā tas joprojām ir jāautomatizē. Un, ja ar gatavu risinājumu iespējām nepietiek, ir jādara kaut kas no paÅ”a.

Situācija ar pirmajiem diviem kritērijiem ir līdzīga: tos nevar apmierināt, nesaņemot datus no ārējas sistēmas - tās, kurā tiek izvietotas lietojumprogrammas (mūsu gadījumā Kubernetes).

Darbplūsmas Git ilustrācija

Pieņemsim, ka programmā Git strādājat Ŕādi:

Konteineru attēlu "gudrās" tÄ«rÄ«Å”anas problēma un tās risinājums werf

Ikona ar galviņu diagrammā norāda konteinera attēlus, kas paÅ”laik ir izvietoti Kubernetes jebkuram lietotājam (galalietotājiem, testētājiem, vadÄ«tājiem utt.) vai kurus izstrādātāji izmanto atkļūdoÅ”anai un lÄ«dzÄ«giem mērÄ·iem.

Kas notiek, ja tÄ«rÄ«Å”anas politikas ļauj tikai saglabāt attēlus (nevis dzēst) pēc dotajiem tagu nosaukumiem?

Konteineru attēlu "gudrās" tÄ«rÄ«Å”anas problēma un tās risinājums werf

Acīmredzot Ŕāds scenārijs nevienu neiepriecinās.

Kas mainÄ«sies, ja politikas atļauj attēlus nedzēst? atbilstoÅ”i noteiktajam laika intervālam / pēdējo saistÄ«bu skaitam?

Konteineru attēlu "gudrās" tÄ«rÄ«Å”anas problēma un tās risinājums werf

Rezultāts ir kļuvis daudz labāks, taču joprojām ir tālu no ideāla. Galu galā mums joprojām ir izstrādātāji, kuriem ir nepiecieÅ”ami attēli reÄ£istrā (vai pat tie ir izvietoti K8s), lai atkļūdotu kļūdas...

Rezumējot paÅ”reizējo tirgus situāciju: konteineru reÄ£istros pieejamās funkcijas nepiedāvā pietiekamu elastÄ«bu tÄ«rÄ«Å”anā, un galvenais iemesls tam ir nekādā veidā nevar sazināties ar ārpasauli. Izrādās, ka komandas, kurām nepiecieÅ”ama Ŕāda elastÄ«ba, ir spiestas patstāvÄ«gi ieviest attēlu dzÄ“Å”anu ā€œno ārpusesā€, izmantojot Docker Registry API (vai atbilstoŔās ievieÅ”anas vietējo API).

Tomēr mēs meklējām universālu risinājumu, kas automatizētu attēlu tÄ«rÄ«Å”anu dažādām komandām, izmantojot dažādus reÄ£istrus...

MÅ«su ceļŔ uz universālu attēla tÄ«rÄ«Å”anu

No kurienes rodas Ŕī vajadzÄ«ba? Fakts ir tāds, ka mēs neesam atseviŔķa izstrādātāju grupa, bet komanda, kas apkalpo daudzus no tiem vienlaikus, palÄ«dzot vispusÄ«gi atrisināt CI/CD problēmas. Un galvenais tehniskais rÄ«ks tam ir atvērtā koda utilÄ«ta werf. Tā Ä«patnÄ«ba ir tāda, ka tā neveic vienu funkciju, bet pavada nepārtrauktus piegādes procesus visos posmos: no montāžas lÄ«dz izvietoÅ”anai.

Attēlu publicÄ“Å”ana reÄ£istrā* (tÅ«lÄ«t pēc to izveides) ir acÄ«mredzama Ŕādas utilÄ«ta funkcija. Un tā kā attēli tur tiek ievietoti uzglabāŔanai, tad - ja jÅ«su krātuve nav neierobežota - jums ir jāatbild par to turpmāko tÄ«rÄ«Å”anu. Par to, kā mēs guvām panākumus Å”ajā jomā, izpildot visus noteiktos kritērijus, tiks apspriests tālāk.

* Lai gan paÅ”i reÄ£istri var atŔķirties (Docker Registry, GitLab Container Registry, Harbor u.c.), to lietotāji saskaras ar tādām paŔām problēmām. Universālais risinājums mÅ«su gadÄ«jumā nav atkarÄ«gs no reÄ£istra ievieÅ”anas, jo darbojas ārpus paÅ”iem reÄ£istriem un piedāvā tādu paÅ”u darbÄ«bu visiem.

Lai gan mēs izmantojam werf kā piemēru, mēs ceram, ka izmantotās pieejas būs noderīgas citām komandām, kuras saskaras ar līdzīgām grūtībām.

Tāpēc mēs bijām aizņemti ārējs attēlu tÄ«rÄ«Å”anas mehānisma ievieÅ”ana - to iespēju vietā, kas jau ir iebÅ«vētas konteineru reÄ£istros. Pirmais solis bija izmantot Docker Registry API, lai izveidotu tādas paÅ”as primitÄ«vas politikas tagu skaitam un to izveides laikam (minēts iepriekÅ”). Viņiem pievienots atļauju saraksts, pamatojoties uz attēliem, kas izmantoti izvietotajā infrastruktÅ«rā, t.i. Kubernetes. Pēdējam pietika ar Kubernetes API izmantoÅ”anu, lai atkārtotu visus izvietotos resursus un iegÅ«tu vērtÄ«bu sarakstu. image.

Å is triviālais risinājums atrisināja viskritiskāko problēmu (kritērijs Nr. 1), taču bija tikai sākums mÅ«su ceļojumam uz tÄ«rÄ«Å”anas mehānisma uzlaboÅ”anu. Nākamais ā€“ un daudz interesantāks ā€“ solis bija lēmums saistÄ«t publicētos attēlus ar Git vēsturi.

AtzÄ«mÄ“Å”anas shēmas

Sākumā mēs izvēlējāmies pieeju, kurā galÄ«gajā attēlā ir jāsaglabā tÄ«rÄ«Å”anai nepiecieÅ”amā informācija, un procesu veidojām uz marÄ·Ä“Å”anas shēmām. Publicējot attēlu, lietotājs izvēlējās konkrētu marÄ·Ä“Å”anas opciju (git-branch, git-commit vai git-tag) un izmantoja atbilstoÅ”o vērtÄ«bu. CI sistēmās Ŕīs vērtÄ«bas tika iestatÄ«tas automātiski, pamatojoties uz vides mainÄ«gajiem. PatiesÄ«bā gala attēls bija saistÄ«ts ar konkrētu Git primitÄ«vu, saglabājot tÄ«rÄ«Å”anai nepiecieÅ”amos datus etiÄ·etēs.

Šīs pieejas rezultātā tika izveidots politiku kopums, kas ļāva Git izmantot kā vienīgo patiesības avotu:

  • DzÄ“Å”ot filiāli/tagu pakalpojumā Git, saistÄ«tie attēli reÄ£istrā tika automātiski izdzēsti.
  • Ar Git tagiem un saistÄ«bām saistÄ«to attēlu skaitu var kontrolēt, izmantojot atlasÄ«tajā shēmā izmantoto tagu skaitu un laiku, kad tika izveidots saistÄ«tais apstiprinājums.

Kopumā izstrādātā ievieÅ”ana apmierināja mÅ«su vajadzÄ«bas, taču drÄ«z mÅ«s sagaidÄ«ja jauns izaicinājums. Fakts ir tāds, ka, izmantojot marÄ·Ä“Å”anas shēmas, kuru pamatā ir Git primitÄ«vi, mēs saskārāmies ar vairākiem trÅ«kumiem. (Tā kā to apraksts ir ārpus Ŕī raksta darbÄ«bas jomas, ikviens var iepazÄ«ties ar detaļām Å”eit.) Tāpēc, nolēmuÅ”i pāriet uz efektÄ«vāku tagu pievienoÅ”anas pieeju (satura iezÄ«mÄ“Å”anu), nācās pārskatÄ«t attēla tÄ«rÄ«Å”anas ievieÅ”anu.

Jauns algoritms

Kāpēc? Izmantojot uz saturu balstÄ«tu marÄ·Ä“Å”anu, katrs tags var apmierināt vairākas Git saistÄ«bas. TÄ«rot attēlus, jÅ«s vairs nevarat pieņemt tikai no apstiprināŔanas, kurā jaunais tags tika pievienots reÄ£istrā.

Jaunajam tÄ«rÄ«Å”anas algoritmam tika nolemts atteikties no marÄ·Ä“Å”anas shēmām un veidot metatēla process, katrā no kurām tiek glabāta virkne:

  • commit, kurā tika veikta publikācija (nav nozÄ«mes tam, vai attēls tika pievienots, mainÄ«ts vai palika nemainÄ«gs konteinera reÄ£istrā);
  • un mÅ«su iekŔējais identifikators, kas atbilst samontētajam attēlam.

Citiem vārdiem sakot, tas tika nodroÅ”ināts publicēto tagu saistÄ«Å”ana ar saistÄ«bām pakalpojumā Git.

Galīgā konfigurācija un vispārējais algoritms

Konfigurējot tÄ«rÄ«Å”anu, lietotājiem tagad ir piekļuve politikām, kas atlasa paÅ”reizējos attēlus. Katra Ŕāda politika ir definēta:

  • daudzas atsauces, t.i. Git tagi vai Git atzari, kas tiek izmantoti skenÄ“Å”anas laikā;
  • un meklēto attēlu ierobežojums katrai atsaucei no kopas.

Lai ilustrētu, noklusējuma politikas konfigurācija sāka izskatÄ«ties Ŕādi:

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

Šajā konfigurācijā ir iekļautas trīs politikas, kas atbilst Ŕādiem noteikumiem:

  1. Saglabājiet attēlu pēdējiem 10 Git tagiem (pēc taga izveides datuma).
  2. Saglabājiet ne vairāk kā 2 attēlus, kas publicēti pagājuÅ”ajā nedēļā, ne vairāk kā 10 pavedieniem ar aktivitātēm pēdējā nedēļā.
  3. Saglabājiet 10 attēlus filiālēm main, staging Šø production.

Pēdējais algoritms sastāv no Ŕādām darbÄ«bām:

  • Notiek manifestu izgÅ«Å”ana no konteinera reÄ£istra.
  • Izņemot Kubernetes izmantotos attēlus, jo Mēs jau esam tos iepriekÅ” atlasÄ«juÅ”i, aptaujājot K8s API.
  • Git vēstures skenÄ“Å”ana un attēlu izslēgÅ”ana, pamatojoties uz noteiktām politikām.
  • AtlikuÅ”o attēlu noņemÅ”ana.

Atgriežoties pie ilustrācijas, ar werf notiek Ŕādi:

Konteineru attēlu "gudrās" tÄ«rÄ«Å”anas problēma un tās risinājums werf

Tomēr pat tad, ja neizmantojat werf, lÄ«dzÄ«gu pieeju uzlabotai attēla tÄ«rÄ«Å”anai vienā vai otrā ievieÅ”anā (atbilstoÅ”i vēlamajai attēla marÄ·Ä“Å”anas pieejai) var izmantot arÄ« citām sistēmām/utilÄ«tiem. Lai to izdarÄ«tu, pietiek atcerēties raduŔās problēmas un savā kaudzē atrast tās iespējas, kas ļauj pēc iespējas raitāk integrēt to risinājumu. Mēs ceram, ka mÅ«su noietais ceļŔ palÄ«dzēs jums paskatÄ«ties uz jÅ«su konkrēto gadÄ«jumu ar jaunām detaļām un pārdomām.

Secinājums

  • Agrāk vai vēlāk lielākā daļa komandu saskaras ar reÄ£istra pārpildes problēmu.
  • Meklējot risinājumus, vispirms ir jānosaka attēla atbilstÄ«bas kritēriji.
  • Populāro konteineru reÄ£istra pakalpojumu piedāvātie rÄ«ki ļauj organizēt ļoti vienkārÅ”u tÄ«rÄ«Å”anu, neņemot vērā ā€œÄrpasauliā€: Kubernetes izmantotos attēlus un komandas darbplÅ«smu Ä«patnÄ«bas.
  • ElastÄ«gam un efektÄ«vam algoritmam ir jābÅ«t izpratnei par CI/CD procesiem un jādarbojas ne tikai ar Docker attēla datiem.

PS

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru