L'argomento del monorepo è stato già discusso più volte e, di norma, suscita dibattiti piuttosto attivi. Creando come strumento Open Source, progettato per migliorare i processi di build del codice delle applicazioni da Git in immagini Docker (e la loro successiva distribuzione in Kubernetes), raramente riflettiamo su quale scelta sia migliore. Per noi è fondamentale fornire tutto il necessario per i sostenitori di diverse opinioni (a patto che non contrasti con il buon senso, ovviamente).
Il recente supporto per mono-repo in werf è un buon esempio. Ma prima di tutto, vediamo come questo supporto sia collegato all'uso di werf e qual è il legame con Docker Registry…
Problematiche
Immaginiamo una situazione. In azienda ci sono numerosi team di sviluppatori che lavorano a progetti indipendenti. La maggior parte delle applicazioni funziona in Kubernetes, quindi sono containerizzate. Per memorizzare i container e le immagini, è necessario un registro (registry). In azienda si utilizza Docker Hub con un unico account COMPANY. Analogamente alla maggior parte dei sistemi di archiviazione del codice sorgente, Docker Hub non consente di creare una gerarchia di repository annidati, come COMPANY/PROJECT/IMAGE. In questo caso... come possiamo gestire questa limitazione per memorizzare applicazioni non monolitiche, senza creare un account separato per ogni progetto?
È possibile che la situazione descritta sia familiare a qualcuno, ma esaminiamo la questione dell'organizzazione della memorizzazione delle applicazioni in generale, cioè senza fare riferimento al precedente esempio e a Docker Hub.
Soluzioni
Se l'applicazione è monolitica, viene fornita in un'unica immagine, non ci sono domande e salviamo semplicemente le immagini nel registro dei contenitori del progetto.
Quando l'applicazione è presentata come più componenti, microservizi, è necessario scegliere un approccio specifico. Usando come esempio un'applicazione web tipica, composta da due immagini: frontend e backend — le opzioni possibili sono:
- Memorizzare le immagini in repository annidati separati:
- Memorizzare tutto in un unico repository, considerando il nome dell'immagine nel tag, ad esempio, nel seguente modo:
NB: In effetti, c'è anche un'opzione per salvare in repository diversi, PROJECT-frontend e PROJECT-backend, ma non lo considereremo a causa della complessità del supporto, dell'organizzazione e della distribuzione dei diritti tra gli utenti.
Supporto in werf
Inizialmente werf si era limitato ai repository annidati - fortunatamente, la maggior parte dei registri supporta questa possibilità. A partire dalla versione , è stata introdotta la funzionalità per i registri in cui non è supportato l'annidamento, e Docker Hub è tra questi. Da questo momento, l'utente ha potuto scegliere come archiviare le immagini dell'applicazione.
L'implementazione è disponibile nell'ambito dell'opzione --images-repo-mode=multirepo|monorepo (per impostazione predefinita multirepo, cioè archiviazione in repository annidati). Questa definisce i modelli con cui le immagini vengono archiviate nel registro. È sufficiente scegliere la modalità desiderata quando si utilizzano i comandi principali, mentre tutto il resto rimarrà invariato.
Poiché gran parte delle opzioni di werf può essere impostata con variabili d'ambiente, nei sistemi CI/CD, la modalità di archiviazione può generalmente essere facile da impostare globalmente per l'intero progetto. Ad esempio, nel caso di GitLab , è sufficiente aggiungere una variabile d'ambiente nelle impostazioni del progetto: Impostazioni -> CI / CD -> Variabili: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Parlando della pubblicazione delle immagini e del rilascio delle applicazioni (puoi leggere in dettaglio su questi processi negli articoli соответствующей документации: e ), la modalità definisce esclusivamente il modello con cui si può lavorare con l'immagine.
Il diavolo è nei dettagli
La differenza e la principale difficoltà nell'aggiungere un nuovo metodo di storage riguardano il processo di pulizia del registry (le possibilità di pulizia supportate in werf possono essere trovate in ).
Durante la pulizia, werf tiene conto delle immagini utilizzate nei cluster Kubernetes, così come delle politiche impostate dall'utente. Le politiche si basano sulla suddivisione dei tag in strategie. Le strategie attualmente supportate sono:
- 3 strategie legate a primitivi Git come tag, branch e commit;
- 1 strategia per tag utente arbitrari.
Le informazioni sulla strategia del tag vengono salvate quando pubblichiamo l'immagine nelle etichette dell'immagine finale. Il valore stesso — il cosiddetto metatag — è necessario per l'applicazione di parte delle politiche. Ad esempio, quando si elimina un branch o un tag dal repository Git, è logico rimuovere anche le immagini non utilizzate dal registry, cosa che rientra in parte nelle nostre politiche.
Quando si salva in un unico repository (monorepo), nel tag dell'immagine, oltre al metatag può essere memorizzato anche il nome dell'immagine: PROGETTO:frontend-META-TAG. Per separarli, non abbiamo introdotto un delimitatore specifico, ma abbiamo semplicemente aggiunto il valore necessario all'etichetta dell'immagine finale durante la pubblicazione.
NB: Se sei interessato a vedere tutto ciò che è descritto nel codice sorgente di werf, il punto di partenza può essere .
In questo articolo non ci soffermeremo ulteriormente sulla problematica e sulla giustificazione del nostro approccio: sulle strategie di tagging, sulla memorizzazione dei dati nelle etichette e sul processo di pubblicazione in generale — di tutto questo è stato dettagliatamente discusso in una recente relazione di Dmitry Stolyarov: "».
In sintesi
L'assenza di supporto per registri senza nidificazione non ha rappresentato un fattore limitante per noi o per gli utenti noti di werf — dato che è sempre possibile creare un registro di immagini separato (o passare al Container Registry in Google Cloud)… Tuttavia, rimuovere tale limitazione sembrava logico affinché lo strumento fosse più accessibile a una comunità DevOps più ampia. Implementandolo, abbiamo affrontato la principale difficoltà nella revisione del meccanismo di pulizia del registro dei container. Ora che tutto è pronto, è gratificante sapere che il lavoro è diventato più semplice per qualcuno, e noi (come principali sviluppatori del progetto) non prevediamo difficoltà significative nel sostenere questa funzionalità in futuro.
Rimanete con noi e presto vi sveleremo altre novità in !
P.S.
Leggete anche nel nostro blog:
- «»;
- «».
Fonte: habr.com
