{"id":37667,"date":"2019-10-31T22:18:58","date_gmt":"2019-10-31T19:18:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry\/"},"modified":"2019-10-31T22:18:58","modified_gmt":"2019-10-31T19:18:58","slug":"podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/podderzhka-monorepo-i-multirepo-v-werf-i-pri-chyom-zdes-docker-registry","title":{"rendered":"Supporto monorepo e multirepo in werf e qual \u00e8 il legame con Docker Registry","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Supporto
\n
\nL'argomento del monorepo \u00e8 stato gi\u00e0 discusso pi\u00f9 volte e, di norma, suscita dibattiti piuttosto attivi. Creando werf<\/a><\/noindex> 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 \u00e8 fondamentale fornire tutto il necessario per i sostenitori di diverse opinioni (a patto che non contrasti con il buon senso, ovviamente).<\/p>\n

Il recente supporto per mono-repo in werf \u00e8 un buon esempio. Ma prima di tutto, vediamo come questo supporto sia collegato all'uso di werf e qual \u00e8 il legame con Docker Registry\u2026<\/a><\/noindex><\/p>\n

Problematiche<\/h2>\n

\nImmaginiamo 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, \u00e8 necessario un registro (registry). In azienda si utilizza Docker Hub con un unico account COMPANY<\/code>. Analogamente alla maggior parte dei sistemi di archiviazione del codice sorgente, Docker Hub non consente di creare una gerarchia di repository annidati<\/b>, come COMPANY\/PROJECT\/IMAGE<\/code>. In questo caso... come possiamo gestire questa limitazione per memorizzare applicazioni non monolitiche, senza creare un account separato per ogni progetto? <\/p>\n

\"Supporto
\n
\n\u00c8 possibile che la situazione descritta sia familiare a qualcuno, ma esaminiamo la questione dell'organizzazione della memorizzazione delle applicazioni in generale, cio\u00e8 senza fare riferimento al precedente esempio e a Docker Hub.<\/p>\n

Soluzioni<\/h3>\n

\nSe l'applicazione \u00e8 monolitica<\/b>, viene fornita in un'unica immagine, non ci sono domande e salviamo semplicemente le immagini nel registro dei contenitori del progetto.<\/p>\n

Quando l'applicazione \u00e8 presentata come pi\u00f9 componenti, microservizi<\/b>, \u00e8 necessario scegliere un approccio specifico. Usando come esempio un'applicazione web tipica, composta da due immagini: frontend<\/code> e backend<\/code> \u2014 le opzioni possibili sono:<\/p>\n

    \n
  1. Memorizzare le immagini in repository annidati separati:\n

    \"Supporto<\/li>\n

  2. Memorizzare tutto in un unico repository, considerando il nome dell'immagine nel tag, ad esempio, nel seguente modo:\n

    \"Supporto<\/li>\n<\/ol>\n

    \nNB<\/b>: In effetti, c'\u00e8 anche un'opzione per salvare in repository diversi, PROJECT-frontend<\/code> e PROJECT-backend<\/code>, ma non lo considereremo a causa della complessit\u00e0 del supporto, dell'organizzazione e della distribuzione dei diritti tra gli utenti.<\/i><\/p>\n

    Supporto in werf<\/h2>\n

    \nInizialmente werf si era limitato ai repository annidati - fortunatamente, la maggior parte dei registri supporta questa possibilit\u00e0. A partire dalla versione v1.0.4-alpha.3<\/a><\/noindex>, \u00e8 stata introdotta la funzionalit\u00e0 per i registri in cui non \u00e8 supportato l'annidamento<\/b>, e Docker Hub \u00e8 tra questi. Da questo momento, l'utente ha potuto scegliere come archiviare le immagini dell'applicazione.<\/p>\n

    L'implementazione \u00e8 disponibile nell'ambito dell'opzione --images-repo-mode=multirepo|monorepo<\/code> (per impostazione predefinita multirepo<\/code>, cio\u00e8 archiviazione in repository annidati). Questa definisce i modelli con cui le immagini vengono archiviate nel registro. \u00c8 sufficiente scegliere la modalit\u00e0 desiderata quando si utilizzano i comandi principali, mentre tutto il resto rimarr\u00e0 invariato.<\/p>\n

    Poich\u00e9 gran parte delle opzioni di werf pu\u00f2 essere impostata con variabili d'ambiente<\/b>, nei sistemi CI\/CD, la modalit\u00e0 di archiviazione pu\u00f2 generalmente essere facile da impostare globalmente per l'intero progetto. Ad esempio, nel caso di GitLab<\/b> , \u00e8 sufficiente aggiungere una variabile d'ambiente nelle impostazioni del progetto: Impostazioni -> CI \/ CD -> Variabili: WERF_IMAGES_REPO_MODE: multirepo|monorepo<\/code><\/i>.<\/p>\n

    Parlando della pubblicazione delle immagini e del rilascio delle applicazioni (puoi leggere in dettaglio su questi processi negli articoli \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e\u0449\u0435\u0439 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438: Processo di pubblicazione<\/a><\/noindex> e Processo di distribuzione<\/a><\/noindex>), la modalit\u00e0 definisce esclusivamente il modello con cui si pu\u00f2 lavorare con l'immagine.<\/p>\n

    Il diavolo \u00e8 nei dettagli<\/h3>\n

    \nLa differenza e la principale difficolt\u00e0 nell'aggiungere un nuovo metodo di storage riguardano il processo di pulizia del registry (le possibilit\u00e0 di pulizia supportate in werf possono essere trovate in Processo di pulizia<\/a><\/noindex>)<\/i>.<\/p>\n

    Durante la pulizia, werf tiene conto delle immagini utilizzate nei cluster Kubernetes, cos\u00ec come delle politiche impostate dall'utente. Le politiche si basano sulla suddivisione dei tag in strategie. Le strategie attualmente supportate sono:<\/p>\n

      \n
    1. 3 strategie legate a primitivi Git come tag, branch e commit;<\/li>\n
    2. 1 strategia per tag utente arbitrari.<\/li>\n<\/ol>\n

      \nLe informazioni sulla strategia del tag vengono salvate quando pubblichiamo l'immagine nelle etichette dell'immagine finale. Il valore stesso \u2014 il cosiddetto metatag<\/b> \u2014 \u00e8 necessario per l'applicazione di parte delle politiche. Ad esempio, quando si elimina un branch o un tag dal repository Git, \u00e8 logico rimuovere anche le immagini non utilizzate<\/i> dal registry, cosa che rientra in parte nelle nostre politiche.<\/p>\n

      Quando si salva in un unico repository (monorepo<\/code>), nel tag dell'immagine, oltre al metatag pu\u00f2 essere memorizzato anche il nome dell'immagine: PROGETTO:frontend<\/b>-META-TAG<\/code>. Per separarli, non abbiamo introdotto un delimitatore specifico, ma abbiamo semplicemente aggiunto il valore necessario all'etichetta dell'immagine finale durante la pubblicazione.<\/p>\n

      NB<\/b>: Se sei interessato a vedere tutto ci\u00f2 che \u00e8 descritto nel codice sorgente di werf, il punto di partenza pu\u00f2 essere PR 1684<\/a><\/noindex>.<\/i><\/p>\n

      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 \u2014 di tutto questo \u00e8 stato dettagliatamente discusso in una recente relazione di Dmitry Stolyarov: \"werf \u2014 il nostro strumento per CI\/CD in Kubernetes<\/a><\/noindex>\u00bb.<\/p>\n

      In sintesi<\/h2>\n

      \nL'assenza di supporto per registri senza nidificazione non ha rappresentato un fattore limitante per noi o per gli utenti noti di werf \u2014 dato che \u00e8 sempre possibile creare un registro di immagini separato (o passare al Container Registry in Google Cloud)\u2026 Tuttavia, rimuovere tale limitazione sembrava logico affinch\u00e9 lo strumento fosse pi\u00f9 accessibile a una comunit\u00e0 DevOps pi\u00f9 ampia. Implementandolo, abbiamo affrontato la principale difficolt\u00e0 nella revisione del meccanismo di pulizia del registro dei container. Ora che tutto \u00e8 pronto, \u00e8 gratificante sapere che il lavoro \u00e8 diventato pi\u00f9 semplice per qualcuno, e noi (come principali sviluppatori del progetto) non prevediamo difficolt\u00e0 significative nel sostenere questa funzionalit\u00e0 in futuro.<\/p>\n

      Rimanete con noi e presto vi sveleremo altre novit\u00e0 in werf<\/a><\/noindex>!<\/p>\n

      P.S.<\/h2>\n

      \nLeggete anche nel nostro blog:<\/p>\n