U tema di un mono-repositoriu hè statu discutitu più di una volta è, in regula, causa una cuntruversia assai attiva. Per creà cum'è un strumentu open source cuncepitu per migliurà u prucessu di custruisce u codice di l'applicazione da Git à l'imaghjini Docker (è poi trasmette à Kubernetes), ùn pensemu micca assai di quale scelta hè megliu. Per noi, hè primariu di furnisce tuttu ciò chì hè necessariu per i sustenidori di diverse opinioni (se questu ùn hè micca cuntraditu u sensu cumunu, sicuru).
U supportu mono-repo recente di werf hè un bon esempiu di questu. Ma prima, scopremu cumu questu supportu hè generalmente in relazione cù l'usu di werf è ciò chì u Docker Registry hà da fà cun ellu ...
I prublemi
Imaginemu una tale situazione. A cumpagnia hà parechje squadre di sviluppu chì travaglianu nantu à prughjetti indipendenti. A maiò parte di l'applicazioni funzionanu nantu à Kubernetes è sò dunque cuntainerized. Per almacenà cuntenituri, imagine, avete bisognu di un registru (registru). Cum'è un tali registru, a cumpagnia usa Docker Hub cù un cuntu unicu COMPANY. Simile à a maiò parte di i sistemi di almacenamentu di codice fonte, Docker Hub ùn permette micca a gerarchia di repository nidificata, cum'è COMPANY/PROJECT/IMAGE. In questu casu ... cumu pudete almacenà applicazioni non monolitiche in u registru cù questa limitazione senza creà un contu separatu per ogni prughjettu?
Forsi, a situazione descritta hè familiar à qualcunu in prima persona, ma cunsideremu u prublema di l'urganizazione di l'almacenamiento di l'applicazioni in generale, i.e. senza riferimentu à l'esempiu sopra è Docker Hub.
Soluzioni
Se l'applicazione monoliticu, vene in una maghjina, allora ùn ci sò micca dumande è simpricimenti salvemu l'imaghjini à u registru di u containeru di u prugettu.
Quandu una applicazione hè presentata cum'è parechje cumpunenti, microservices, allura un certu approcciu hè necessariu. Nantu à l'esempiu di una applicazione web tipica custituita da duie imagine: frontend и backend - l'opzioni pussibuli sò:
- Almacene l'imaghjini in repositori nidificati separati:
- Guardà tuttu in un repositoriu, è cunzidira u nome di l'imaghjini in l'etichetta, per esempiu, cum'è seguente:
NB: In realtà, ci hè un'altra opzione cù salvezza in diversi repositori, PROJECT-frontend и PROJECT-backend, ma ùn avemu micca cunsideratu per via di a cumplessità di supportu, urganizazione è distribuzione di diritti trà l'utilizatori.
sustegnu werf
Inizialmente, werf si limitava à i repositori nidificati - per furtuna, a maiò parte di i registri supportanu sta funzione. Partendu da a versione , hà aghjustatu u travagliu cù i registri in quale a nidificazione ùn hè micca supportata, è Docker Hub hè unu di elli. Da quellu puntu, l'utilizatore hà una scelta di cumu per almacenà l'imaghjini di l'applicazione.
Implementazione dispunibule sottu opzione --images-repo-mode=multirepo|monorepo (default multirepo, i.e. storage in repository nidificati). Definisce i mudelli per quale l'imaghjini sò guardati in u registru. Hè abbastanza per selezziunà u modu desideratu quandu si usa i cumandamenti basi, è tuttu u restu resta invariatu.
Perchè a maiò parte di l'opzioni di werf ponu esse stabilite variabili ambientali, in i sistemi CI / CD, u modu di almacenamento hè generalmente faciule da stabilisce in u mondu per tuttu u prughjettu. Per esempiu, in u casu di GitLab basta aghjunghje una variabile d'ambiente in i paràmetri di u prugettu: Settings -> CI / CD -> Variables: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Se parlemu di a publicazione di l'imaghjini è di l'applicazioni (pudete leghje nantu à sti prucessi in dettagliu in l'articuli di documentazione pertinenti: и ), allura u modu determina solu u mudellu da quale pudete travaglià cù l'imaghjini.
U diavulu hè in i dettagli
A diferenza è a principal difficultà quandu aghjunghje un novu metudu di almacenamiento hè in u prucessu di pulizia di u registru (per e funzioni di purga supportate da werf, vede ).
Quandu a pulizia, werf piglia in contu l'imaghjini utilizati in clusters Kubernetes, è ancu e pulitiche cunfigurate da l'utilizatore. I pulitichi sò basati nantu à a divisione di e tag in strategie. Strategie attualmente supportate:
- 3 strategie ligati da primitivi Git cum'è tag, branch, and commit;
- 1 strategia per tags persunalizati arbitrarie.
Salvemu l'infurmazioni nantu à a strategia di tag quandu pubblicà l'imaghjini in l'etichette di l'imaghjini finali. U significatu stessu hè u cusì chjamatu meta tag - Ubligatoriu per applicà alcune di e pulitiche. Per esempiu, quandu sguassate un ramu o tag da un repository Git, hè logicu per sguassà rilativi inutilizatu images da u registru, chì hè cupartu da parte di e nostre pulitiche.
Quandu hè salvatu in un repository (monorepo), in u tag di l'imaghjini, in più di a meta tag, u nome di l'imaghjini pò ancu esse guardatu: PROJECT:frontend-META-TAG. Per separà elli, ùn avemu micca introduttu un separatore specificu, ma solu aghjunghje u valore necessariu à l'etichetta di l'imaghjini finali in a publicazione.
NB: Sè vo site interessatu à guardà tuttu ciò chì hè descrittu in u codice fonte werf, allura u puntu di partenza pò esse .
In questu articulu, ùn faremu micca più attente à i prublemi è a ghjustificazione di u nostru approcciu: nantu à e strategie di tagging, l'almacenamiento di dati in l'etichette è u prucessu di publicazione in generale - tuttu questu hè descrittu in dettagliu in un rapportu recente di Dmitry Stolyarov: "».
Per riassume
A mancanza di supportu per i registri unnested ùn era micca un fattore di bloccu per noi o per l'utilizatori di werf cunnisciuti da noi - dopu tuttu, pudete sempre elevà un registru d'imaghjini separatu (o cambià à un Registru di Container cundizionale in Google Cloud) ... Tuttavia, caccià una tale restrizione pareva logica per chì l'uttellu sia più cunvene per a cumunità DevOps più larga. Implementendu, avemu affruntatu a difficultà principale in a riformulazione di u mecanismu di pulizia di u registru di u containeru. Avà chì tuttu hè prontu, hè piacevule per capisce chì hè diventatu più faciule per qualchissia, è noi (cum'è i sviluppatori principali di u prugettu) ùn averemu micca difficultà notevuli per sustene più sta funzione.
Resta cun noi è assai prestu vi parleremu di altre innovazioni in !
PS
Leghjite puru nant'à u nostru blog:
- «";
- «».
Source: www.habr.com