🥇Suport pentru monorepo și multirepo în werf și ce legătura este cu Docker Registry

Tema monorepo-ului a fost discutată de mai multe ori și, de regulă, stârnește dispute foarte active. Când creăm werf un instrument Open Source destinat îmbunătățirii proceselor de construire a codului aplicațiilor din Git în imagini Docker (și livrarea lor ulterioară în Kubernetes), rareori ne gândim la alegerea optimă. Pentru noi, este esențial să asigurăm tot ce este necesar susținătorilor diferitelor opinii (dacă nu contravine bunului simț, desigur).

Sprijinul recent apărut pentru mono-repo în werf este un bun exemplu în acest sens. Dar, mai întâi, să analizăm cum este legat acest sprijin de utilizarea werf și ce legătură are cu Docker Registry...

Problematica

Să ne imaginăm o situație. În companie există numeroase echipe de dezvoltatori care lucrează la proiecte independente. Majoritatea aplicațiilor funcționează în Kubernetes, așadar - sunt containerizate. Pentru stocarea containerelor, imaginilor, este necesar un registru. Ca registru, compania folosește Docker Hub cu un singur cont COMPANY. La fel ca în majoritatea sistemelor de stocare a codului sursă, Docker Hub nu permite crearea unei ierarhii de registre înnodată, cum ar fi COMPANY/PROJECT/IMAGE. În acest caz… cum putem stoca aplicațiile nemonolitice în registru, fără a crea un cont separat pentru fiecare proiect?

Poate că situația descrisă este cunoscută unor persoane, dar să analizăm întrebarea organizării stocării aplicațiilor în general, adică fără a face referire la exemplul de mai sus și Docker Hub.

Modalități de soluție

Dacă aplicația este monolitică, livrată într-o singură imagine, atunci nu sunt întrebări și pur și simplu salvăm imaginile în registrul containerelor proiectului.

Când aplicația este reprezentată prin mai multe componente, microservicii, este necesar să alegem o abordare specifică. De exemplu, pentru o aplicație web tipică, formată din două imagini: frontend și backend — variantele posibile sunt:

A păstra imaginile în registre înnodată separate:
A păstra totul într-un singur registru, iar numele imaginii să fie luat în considerare în tag, de exemplu, astfel:

NB: De fapt, mai există o variantă cu păstrarea în diferite registre, PROJECT-frontend și PROJECT-backend, dar aceasta nu va fi tratată din cauza complexității întreținerii, organizării și distribuirii drepturilor între utilizatori.

Sprijinul în werf

Inițial, werf s-a limitat la depozitele încorporate — fiindcă majoritatea registrelor suportă această opțiune. Începând cu versiunea v1.0.4-alpha.3, a fost adăugată lucrul cu registe care nu suportă ierarhii, printre care se numără și Docker Hub. De la acest moment, utilizatorul a avut posibilitatea de a alege cum să stocheze imaginile aplicației.

Implementarea este disponibilă în cadrul opțiunii --images-repo-mode=multirepo|monorepo （implicit multirepo, adică stocare în depozite încorporate). Aceasta definește șabloanele conform cărora imaginile sunt stocate în registru. Este suficient să alegi modul dorit atunci când folosești comenzile de bază, iar tot restul va rămâne neschimbat.

Deoarece majoritatea opțiunilor werf pot fi setate prin variabile de mediu, în sistemele CI/CD, modul de stocare poate fi setat în general global pentru întregul proiect. De exemplu, în cazul GitLab , este suficient să adaugi o variabilă de mediu în setările proiectului: Settings -> CI / CD -> Variables: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

Când vine vorba de publicarea imaginilor și de desfășurarea aplicațiilor (despre aceste procese poți citi în detaliu în articolele corespunzătoare din documentație: Publicare proces și Desfășurare proces), modul determină exclusiv șablonul conform căruia se poate lucra cu imaginea.

Diavolul se află în detalii

Diferența și dificultatea principală în adăugarea unui nou mod de stocare este în procesul de curățare a registry-ului (posibilitățile de curățare suportate în werf, vezi în Proces de curățare).

La curățare, werf ia în considerare imaginile utilizate în clusterele Kubernetes, precum și politicile configurate de utilizator. La baza politicilor se află împărțirea etichetelor în strategii. Strategiile susținute în prezent sunt:

3 strategii legate de primitivele Git, cum ar fi eticheta, ramura și commit-ul;
1 strategie pentru etichete personalizate arbitrare.

Informațiile despre strategia etichetei sunt păstrate la publicarea imaginii în etichetele imaginii finale. Valoarea în sine — așa-numita metatag — este necesară pentru aplicarea unor politici. De exemplu, în cazul ștergerii unei ramuri sau a unei etichete din registrul Git, este logic să ștergi și imaginele asociate neutilizate din registru, ceea ce este acoperit de o parte din politicile noastre.

Când se salvează într-un singur registru (monorepo), în eticheta imaginii, pe lângă metatag, poate fi stocat și numele imaginii: PROIECT:frontend-META-TAG. Pentru a le separa, nu am introdus un separator specific, ci am adăugat pur și simplu valoarea necesară în eticheta imaginii finale la publicare.

NB: Dacă sunteți interesat să vizualizați tot ce este descris în codul sursă werf, un punct de plecare poate fi PR 1684.

În acest articol nu ne vom concentra mai mult asupra problematicii și justificării abordării noastre: despre strategiile de etichetare, stocarea datelor în etichete și procesul de publicare în ansamblu — despre toate acestea s-a discutat detaliat în raportul recent al lui Dmitri Stoliarov: „werf — instrumentul nostru pentru CI/CD în Kubernetes».

În concluzie

Lipsa suportului pentru registre fără poziționare nu a fost un factor blocant pentru noi sau pentru utilizatorii cunoscuți ai werf — deoarece întotdeauna este posibil să ridicați un registru distinct de imagini (sau să treceți la un registru de containere în Google Cloud)… Cu toate acestea, eliminarea unei astfel de restricții părea logică pentru a face instrumentul mai accesibil unei comunități DevOps mai largi. Implementând-o, ne-am confruntat cu principala dificultate în reproiectarea mecanismului de curățare a registrului de containere. Acum, când totul este pregătit, este plăcut să realizăm că cuiva i-a fost mai ușor, iar noi (ca dezvoltatori principali ai proiectului) nu ne așteptăm la dificultăți semnificative în suportul ulterior al acestei caracteristici.

Rămâneți cu noi și în curând vă vom povesti despre alte noutăți în werf!