L'argomento di un mono-repository è stato discusso più di una volta e, di norma, provoca polemiche molto attive. Creando come strumento open source progettato per migliorare il processo di creazione del codice dell'applicazione da Git alle immagini Docker (e quindi consegnarle a Kubernetes), non pensiamo molto a quale sia la scelta migliore. Per noi è fondamentale fornire tutto il necessario per i sostenitori di opinioni diverse (se questo non contraddice il buon senso, ovviamente).
Il recente supporto mono-repo di werf ne è un buon esempio. Ma prima, scopriamo in che modo questo supporto è generalmente correlato all'utilizzo di werf e cosa c'entra il registro Docker con esso ...
Problemi
Immaginiamo una situazione del genere. L'azienda ha molti team di sviluppo che lavorano su progetti indipendenti. La maggior parte delle applicazioni viene eseguita su Kubernetes e sono quindi containerizzate. Per archiviare contenitori, immagini, è necessario un registro (registro). Come tale registro, l'azienda utilizza Docker Hub con un singolo account COMPANY. Simile alla maggior parte dei sistemi di archiviazione del codice sorgente, Docker Hub non consente la gerarchia di repository nidificati, ad esempio COMPANY/PROJECT/IMAGE. In tal caso... come puoi archiviare applicazioni non monolitiche nel registro con questa limitazione senza creare un account separato per ciascun progetto?
Forse la situazione descritta è familiare a qualcuno in prima persona, ma consideriamo la questione dell'organizzazione dell'archiviazione delle applicazioni in generale, ad es. senza riferimento all'esempio precedente e a Docker Hub.
Modi di soluzione
Se l'applicazione monolitico, arriva in un'unica immagine, quindi non ci sono domande e salviamo semplicemente le immagini nel registro contenitori del progetto.
Quando un'applicazione viene presentata come più componenti, microservizi, allora è necessario un certo approccio. Nell'esempio di una tipica applicazione web composta da due immagini: frontend и backend - le possibili opzioni sono:
- Memorizza le immagini in repository nidificati separati:
- Memorizza tutto in un repository e considera il nome dell'immagine nel tag, ad esempio, come segue:
NB: In realtà, c'è un'altra opzione con il salvataggio in diversi repository, PROJECT-frontend и PROJECT-backend, ma non lo prenderemo in considerazione a causa della complessità del supporto, dell'organizzazione e della distribuzione dei diritti tra gli utenti.
supporto werf
Inizialmente, werf si limitava ai repository nidificati: fortunatamente, la maggior parte dei registri supporta questa funzionalità. A partire dalla versione , ha aggiunto il lavoro con i registri in cui l'annidamento non è supportatoe Docker Hub è uno di questi. Da quel momento in poi, l'utente può scegliere come memorizzare le immagini dell'applicazione.
Implementazione disponibile in opzione --images-repo-mode=multirepo|monorepo (predefinito multirepo, cioè. archiviazione in repository nidificati). Definisce i modelli in base ai quali le immagini vengono memorizzate nel registro. È sufficiente selezionare la modalità desiderata quando si utilizzano i comandi di base e tutto il resto rimarrà invariato.
Perché la maggior parte delle opzioni werf possono essere impostate variabili ambientali, nei sistemi CI / CD, la modalità di archiviazione è generalmente facile da impostare a livello globale per l'intero progetto. Per esempio, nel caso di GitLab basta aggiungere una variabile d'ambiente nelle impostazioni del progetto: Impostazioni -> CI / CD -> Variabili: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Se parliamo di pubblicare immagini e implementare applicazioni (puoi leggere questi processi in dettaglio negli articoli di documentazione pertinenti: и ), quindi la modalità determina esclusivamente il modello con cui è possibile lavorare con l'immagine.
Il diavolo è nei dettagli
La differenza e la principale difficoltà quando si aggiunge un nuovo metodo di archiviazione è nel processo di pulizia del registro (per le funzionalità di eliminazione supportate da werf, vedere ).
Durante la pulizia, werf tiene conto delle immagini utilizzate nei cluster Kubernetes, nonché delle policy configurate dall'utente. Le politiche si basano sulla divisione dei tag in strategie. Strategie attualmente supportate:
- 3 strategie collegate da primitive Git come tag, branch e commit;
- 1 strategia per tag personalizzati arbitrari.
Salviamo le informazioni sulla strategia di tag quando pubblichiamo l'immagine nelle etichette dell'immagine finale. Il significato stesso è il cosiddetto metatag - Richiesto per applicare alcune delle politiche. Ad esempio, quando si elimina un ramo o un tag da un repository Git, è logico eliminare related non usato immagini dal registro, che è coperto da parte delle nostre politiche.
Quando salvato in un repository (monorepo), nel tag immagine, oltre al meta tag, può essere memorizzato anche il nome dell'immagine: PROJECT:frontend-META-TAG. Per separarli non abbiamo introdotto alcun separatore specifico, ma abbiamo semplicemente aggiunto il valore necessario all'etichetta dell'immagine finale in fase di pubblicazione.
NB: Se sei interessato a guardare tutto ciò che è descritto nel codice sorgente werf, allora il punto di partenza può essere .
In questo articolo, non presteremo più attenzione ai problemi e alla giustificazione del nostro approccio: sulle strategie di tagging, sull'archiviazione dei dati nelle etichette e sul processo di pubblicazione nel suo insieme - tutto questo è descritto in dettaglio in un recente rapporto di Dmitry Stolyarov: "'.
riassumendo
La mancanza di supporto per i registri non nidificati non è stato un fattore di blocco per noi o per gli utenti werf a noi noti: dopotutto, puoi sempre creare un registro immagini separato (o passare a un registro container condizionale in Google Cloud) ... Tuttavia, la rimozione di tale restrizione sembrava logica affinché lo strumento fosse più conveniente per la più ampia comunità DevOps. Implementandolo, abbiamo affrontato la principale difficoltà nella rielaborazione del meccanismo di pulizia del registro contenitori. Ora che tutto è pronto, è bello rendersi conto che è diventato più facile per qualcuno e noi (in quanto principali sviluppatori del progetto) non avremo difficoltà evidenti a supportare ulteriormente questa funzionalità.
Resta con noi e molto presto ti parleremo di altre novità in !
PS
Leggi anche sul nostro blog:
- «";
- «'.
Fonte: habr.com