Subiectul unui depozit mono a fost discutat de mai multe ori și, de regulă, provoacă controverse foarte active. Prin crearea ca instrument open source conceput pentru a îmbunătăți procesul de construire a codului aplicației de la imaginile Git la Docker (și apoi să le livreze către Kubernetes), nu ne gândim prea mult la alegerea cea mai bună. Pentru noi, este primordial să oferim tot ceea ce este necesar pentru susținătorii de opinii diferite (dacă acest lucru nu contrazice bunul simț, desigur).
Recentul suport mono-repo al werf este un bun exemplu în acest sens. Dar mai întâi, să ne dăm seama cum acest suport este în general legat de utilizarea werf și ce legătură are Registrul Docker cu el...
Probleme
Să ne imaginăm o astfel de situație. Compania are multe echipe de dezvoltare care lucrează pe proiecte independente. Majoritatea aplicațiilor rulează pe Kubernetes și, prin urmare, sunt containerizate. Pentru a stoca containere, imagini, aveți nevoie de un registru (registru). Ca un astfel de registru, compania folosește Docker Hub cu un singur cont COMPANY. Similar cu majoritatea sistemelor de stocare a codului sursă, Docker Hub nu permite ierarhia depozitelor imbricate, ca COMPANY/PROJECT/IMAGE. În acest caz... cum puteți stoca aplicații non-monolitice în registru cu această limitare fără a crea un cont separat pentru fiecare proiect?
Poate că situația descrisă este familiară cuiva, dar să luăm în considerare problema organizării stocării aplicațiilor în general, de exemplu. fără referire la exemplul de mai sus și la Docker Hub.
Soluții
Dacă cererea monolitic, vine într-o singură imagine, atunci nu există întrebări și pur și simplu salvăm imaginile în registrul de containere al proiectului.
Când o aplicație este prezentată ca mai multe componente, microservicii, atunci este necesară o anumită abordare. Pe exemplul unei aplicații web tipice constând din două imagini: frontend и backend - optiunile posibile sunt:
- Stocați imaginile în depozite imbricate separate:
- Stocați totul într-un singur depozit și luați în considerare numele imaginii din etichetă, de exemplu, după cum urmează:
NB: De fapt, există o altă opțiune cu salvarea în diferite depozite, PROJECT-frontend и PROJECT-backend, dar nu o vom lua în considerare din cauza complexității suportului, organizării și distribuirii drepturilor între utilizatori.
suport werf
Inițial, werf s-a limitat la depozitele imbricate - din fericire, majoritatea registrelor acceptă această caracteristică. Pornind de la versiune , a adăugat lucru cu registre în care imbricarea nu este acceptată, iar Docker Hub este unul dintre ele. Din acel moment, utilizatorul are posibilitatea de a alege cum să stocheze imaginile aplicației.
Implementare disponibilă sub opțiune --images-repo-mode=multirepo|monorepo (Mod implicit multirepo, adică stocare în depozite imbricate). Acesta definește tiparele după care imaginile sunt stocate în registru. Este suficient să selectați modul dorit atunci când utilizați comenzile de bază și totul va rămâne neschimbat.
Pentru că majoritatea opțiunilor werf pot fi setate variabile de mediu, în sistemele CI/CD, modul de stocare este de obicei ușor de setat global pentru întregul proiect. De exemplu, în cazul GitLab doar adăugați o variabilă de mediu în setările proiectului: Setări -> CI / CD -> Variabile: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Dacă vorbim despre publicarea imaginilor și lansarea aplicațiilor (puteți citi despre aceste procese în detaliu în articolele relevante din documentație: и ), atunci modul determină numai șablonul prin care puteți lucra cu imaginea.
Diavolul sta in detalii
Diferența și principala dificultate atunci când adăugați o nouă metodă de stocare este în procesul de curățare a registrului (pentru funcțiile de purjare acceptate de werf, vezi ).
La curățare, werf ia în considerare imaginile utilizate în clusterele Kubernetes, precum și politicile configurate de utilizator. Politicile se bazează pe împărțirea etichetelor în strategii. Strategii suportate în prezent:
- 3 strategii legate de primitive Git, cum ar fi tag, branch și commit;
- 1 strategie pentru etichete personalizate arbitrare.
Salvăm informații despre strategia de etichetă atunci când publicăm imaginea în etichetele imaginii finale. Sensul în sine este așa-numitul metaetichetă - Este necesar să se aplice unele dintre politici. De exemplu, atunci când ștergeți o ramură sau o etichetă dintr-un depozit Git, este logic să ștergeți aferente nefolosit imagini din registru, care este acoperit de o parte din politicile noastre.
Când este salvat într-un singur depozit (monorepo), în eticheta de imagine, pe lângă metaeticheta, poate fi stocat și numele imaginii: PROJECT:frontend-META-TAG. Pentru a le separa, nu am introdus niciun separator anume, ci pur și simplu am adăugat valoarea necesară etichetei imaginii finale în momentul publicării.
NB: Dacă sunteți interesat să priviți tot ce este descris în codul sursă werf, atunci punctul de plecare poate fi .
În acest articol, nu vom acorda mai multă atenție problemelor și justificării abordării noastre: despre strategiile de etichetare, stocarea datelor în etichete și procesul de publicare în ansamblu - toate acestea sunt descrise în detaliu într-un raport recent al lui Dmitri Stolyarov: „".
A rezuma
Lipsa suportului pentru registrele neimbricate nu a fost un factor de blocare pentru noi sau pentru utilizatorii werf cunoscuți de noi - la urma urmei, puteți oricând să creați un registru de imagini separat (sau să treceți la un registru de containere condiționat în Google Cloud) ... Cu toate acestea, eliminarea unei astfel de restricții părea logică pentru ca instrumentul să fie mai convenabil comunității DevOps mai largi. Implementând-o, ne-am confruntat cu principala dificultate în reelaborarea mecanismului de curățare a registrului containerelor. Acum că totul este gata, este plăcut să ne dăm seama că a devenit mai ușor pentru cineva, iar noi (în calitate de dezvoltatori principali ai proiectului) nu vom avea dificultăți vizibile în a susține în continuare această caracteristică.
Rămâneți alături de noi și foarte curând vă vom spune despre alte inovații în !
PS
Citește și pe blogul nostru:
- «»;
- «".
Sursa: www.habr.com