{"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 cosa c'entra Docker Registry","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Supporto
\n
\nIl tema del monorepo \u00e8 stato gi\u00e0 discusso molte volte e, di solito, solleva vivaci dibattiti. Creando werf<\/a><\/noindex> uno strumento Open Source, destinato a migliorare i processi di compilazione del codice delle applicazioni da Git in immagini Docker (e la loro successiva consegna in Kubernetes), riflettiamo poco sulla questione di quale scelta sia la migliore. Per noi, \u00e8 fondamentale garantire tutto il necessario per i sostenitori di opinioni diverse (se ci\u00f2 non contraddice il buon senso, ovviamente).<\/p>\n

Il recente supporto per mono-repo in werf \u00e8 un buon esempio in tal senso. Ma prima, cerchiamo di capire come questo supporto sia effettivamente collegato all'uso di werf e quale sia il ruolo di Docker Registry...<\/a><\/noindex><\/p>\n

Problematica<\/h2>\n

\nImmaginiamo una situazione del genere. In un'azienda ci sono numerosi team di sviluppatori che lavorano su progetti indipendenti. La maggior parte delle applicazioni funziona in Kubernetes e, di conseguenza, vengono containerizzate. Per memorizzare i contenitori e le immagini, \u00e8 necessario un registro (registry). L'azienda 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 annidata<\/b>, come COMPANY\/PROJECT\/IMAGE<\/code>. In tal caso... come possiamo memorizzare applicazioni non monolitiche nel registro senza creare un account separato per ogni progetto? <\/p>\n

\"Supporto
\n
\n\u00c8 possibile che la situazione descritta sia nota a qualcuno, ma analizziamo la questione dell'organizzazione della memorizzazione delle applicazioni in generale, ossia senza fare riferimento all'esempio sopra descritto e a Docker Hub.<\/p>\n

Vie di soluzione<\/h3>\n

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

Quando l'applicazione \u00e8 rappresentata da pi\u00f9 componenti, microservizi<\/b>, \u00e8 necessario scegliere un approccio specifico. Per esempio, prendiamo un'applicazione web tipica, composta da due immagini: frontend<\/code> e backend<\/code> \u2014 le possibili opzioni 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 modo seguente:\n

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

    \nNB<\/b>: In realt\u00e0, c'\u00e8 anche l'opzione di salvare in vari repository, PROJECT-frontend<\/code> e PROJECT-backend<\/code>, ma non la esamineremo a causa della difficolt\u00e0 nel supportarla, nel gestire e distribuire i diritti tra gli utenti.<\/i><\/p>\n

    Supporto in werf<\/h2>\n

    \nInizialmente werf si era limitato ai repository annidati, poich\u00e9 la maggior parte dei registri supporta questa possibilit\u00e0. A partire dalla versione v1.0.4-alpha.3<\/a><\/noindex>, \u00e8 stata aggiunta la gestione dei registri che non supportano l'annidamento<\/b>, incluso Docker Hub. Da questo momento, l'utente ha la possibilit\u00e0 di scegliere come memorizzare le immagini dell'applicazione.<\/p>\n

    L'implementazione \u00e8 disponibile attraverso l'opzione --images-repo-mode=multirepo|monorepo<\/code> (predefinito multirepo<\/code>, ovvero memorizzazione in repository annidati). Essa definisce i modelli secondo cui le immagini sono memorizzate nel registro. \u00c8 sufficiente selezionare la modalit\u00e0 desiderata durante l'uso dei comandi principali, e tutto il resto rimarr\u00e0 invariato.<\/p>\n

    Poich\u00e9 la maggior parte delle opzioni di werf possono essere impostate tramite variabili d'ambiente<\/b>, nelle piattaforme CI\/CD, la modalit\u00e0 di memorizzazione pu\u00f2 generalmente essere impostata 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 deployment delle applicazioni (su questi processi \u00e8 possibile leggere in dettaglio negli articoli pertinenti della documentazione: Processo di pubblicazione<\/a><\/noindex> e Processo di deploy<\/a><\/noindex>), la modalit\u00e0 definisce esclusivamente il modello secondo 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 memorizzazione sono nel processo di pulizia del registry (le possibilit\u00e0 di pulizia, supportate in werf, sono descritte in Processo di pulizia<\/a><\/noindex>)<\/i>.<\/p>\n

    ) Quando si pulisce, werf considera le immagini utilizzate nei cluster Kubernetes, cos\u00ec come le politiche impostate dall'utente. Alla base delle politiche c'\u00e8 la suddivisione dei tag in strategie. Le strategie attualmente supportate sono:<\/p>\n

      \n
    1. 3 strategie legate ai 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 sono conservate quando si pubblica l'immagine nelle etichette dell'immagine finale. Il valore stesso \u2014 il cosiddetto metatags<\/b> \u2014 \u00e8 necessario per applicare parte delle politiche. Ad esempio, quando si elimina un branch o un tag da un repository Git, \u00e8 logico rimuovere anche le immagini non utilizzate<\/i> dal registro, cosa coperta parte delle nostre politiche.<\/p>\n

      Quando si salva in un unico repository (monorepo<\/code>), nel tag dell'immagine, oltre al metatag, \u00e8 possibile memorizzare anche il nome dell'immagine: PROGETTO:frontend<\/b>-META-TAG<\/code>. Per separare, non abbiamo introdotto un delimitatore specifico, ma abbiamo semplicemente aggiunto il valore necessario all'etichetta dell'immagine finale al momento della 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 potrebbe essere PR 1684<\/a><\/noindex>.<\/i><\/p>\n

      In questo articolo non approfondiremo ulteriormente la problematica e la giustificazione del nostro approccio: sulle strategie di tagging, sulla conservazione dei dati nelle etichette e sul processo di pubblicazione in generale \u2014 tutto questo \u00e8 stato ampiamente trattato nel recente rapporto di Dmitrij Stoljarev: \u00abwerf \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 \u00e8 stata un fattore bloccante per noi o per i comuni utenti di werf \u2014 infatti \u00e8 sempre possibile avviare un registro separato di immagini (o passare a un Container Registry in Google Cloud)\u2026 Tuttavia, rimuovere tale restrizione appariva logico affinch\u00e9 lo strumento fosse pi\u00f9 utile a una community DevOps pi\u00f9 ampia. Implementandolo, ci siamo scontrati con la principale difficolt\u00e0 nel ripensare il meccanismo di pulizia del registro dei container. Ora che tutto \u00e8 pronto, \u00e8 piacevole sapere che per qualcuno \u00e8 diventato pi\u00f9 facile, e per noi (come sviluppatori principali del progetto) non prevediamo difficolt\u00e0 significative nel mantenere questa funzionalit\u00e0 in futuro.<\/p>\n

      Resta con noi e presto ti parleremo di altre novit\u00e0 in werf<\/a><\/noindex>!<\/p>\n

      P.S.<\/h2>\n

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