— la nostra utility CLI GitOps open source per costruire e distribuire applicazioni in Kubernetes. Come promesso, ha segnato l'inizio dell'aggiunta di nuove funzionalità in werf e della revisione dei metodi consolidati. Siamo ora lieti di presentare il rilascio della versione v1.1, che rappresenta un grande passo avanti e un trampolino per il futuro. costruttore werf. La versione è attualmente disponibile nel .
Il fulcro di questo rilascio è una nuova architettura dello storage delle fasi e l'ottimizzazione del funzionamento di entrambi i costruttori (per Stapel e Dockerfile). La nuova architettura dello storage apre opportunità per implementare build distribuite da più host e build parallele su un singolo host.
L'ottimizzazione comporta l'eliminazione di calcoli superflui nella fase di calcolo delle firme delle fasi e la modifica dei meccanismi di calcolo delle somme di controllo dei file per renderli più efficaci. Questa ottimizzazione riduce il tempo medio di build del progetto utilizzando werf. E le build vuote, quando tutte le fasi esistono nella cache stages-storage, ora sono realmente rapide. Nella maggior parte dei casi, il riavvio di una build avverrà più rapidamente di 1 secondo! Questo vale anche per le procedure di verifica delle fasi durante il lavoro dei team werf deploy e werf run.
In questo rilascio è stata anche introdotta una strategia di tagging delle immagini basata sul contenuto — tagging basato sul contenuto, che ora è abilitata per impostazione predefinita e è l'unica raccomandata.
Esaminiamo in dettaglio le principali novità in werf v1.1 e parliamo anche dei piani futuri.
Cosa è cambiato in werf v1.1?
Nuovo formato di denominazione delle fasi e algoritmo di selezione delle fasi dalla cache
Una nuova regola per la generazione del nome della fase. Ora ogni build della fase genera un nome unico che consiste di 2 parti: la firma (come in v1.0) più un identificativo temporale unico.
Ad esempio, il nome completo dell'immagine della fase può apparire così:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
… o in forma generale:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Qui:
-
SIGNATURE— è la firma della fase, che rappresenta l'identificativo del contenuto della fase e dipende dalla storia delle modifiche in Git che ha portato a quel contenuto; -
TIMESTAMP_MILLISEC— è l'identificativo garantito unico dell'immagine, generato nel momento della build di una nuova immagine.
L'algoritmo di selezione delle fasi dalla cache è basato sul controllo della parentela dei commit Git:
- Werf calcola la firma di una certa fase.
- In stages-storage possono esistere più fasi con questa firma. Werf seleziona tutte le fasi corrispondenti alla firma.
- Se la fase attuale è collegata a Git (git-archive, fase personalizzata con patch Git:
installare,beforeSetup,setup; o git-latest-patch), allora werf seleziona solo le fasi collegate al commit che è un antenato del commit attuale (per cui è stata richiesta la build). - Delle rimanenti fasi corrispondenti, se ne seleziona una — la più vecchia per data di creazione.
Una fase per diversi rami Git può avere la stessa firma. Ma werf impedirà l'uso della cache collegata a rami diversi, anche se le firme coincidet.
.
Nuovo algoritmo di creazione e salvataggio delle fasi nello storage delle fasi
Se durante la selezione delle fasi dalla cache werf non trova una fase corrispondente, inizia il processo di costruzione di una nuova fase.
Si noti che più processi (su uno o più host) possono iniziare a costruire la stessa fase circa nello stesso momento. Werf utilizza un algoritmo di blocco ottimistico stages-storage al momento del salvataggio della nuova immagine in stages-storage. Pertanto, quando la costruzione della nuova fase è pronta, werf blocca stages-storage e salva lì l'immagine appena costruita solo se non esiste già un'immagine corrispondente (secondo la firma e altri parametri — vedi il nuovo algoritmo di selezione delle fasi dalla cache).
L'immagine appena costruita avrà sicuramente un identificatore unico secondo TIMESTAMP_MILLISEC (vedi il nuovo formato di denominazione delle fasi). Nel caso in cui in stages-storage venga trovata un'immagine corrispondente, werf scarterà l'immagine appena costruita e utilizzerà l'immagine dalla cache.
In altre parole: il primo processo che termina la costruzione dell'immagine (il più veloce) ottiene il diritto di salvarlo in stages-storage (e poi solo quest'unica immagine sarà utilizzata per tutte le build). Tuttavia, il processo di costruzione più lento non bloccherà mai il processo più veloce dal salvare i risultati della build della fase attuale e dal passare alla costruzione della successiva.
.
Migliorata la performance del costruttore Dockerfile
Attualmente la pipeline di fasi per l'immagine costruita da un Dockerfile consiste in una sola fase — dockerfile. Nel calcolo della firma viene considerato il checksum dei file. context, che verranno utilizzati durante la compilazione. Prima di questo miglioramento, werf eseguiva una scansione ricorsiva di tutti i file e calcolava un checksum sommando il contesto e il modulo di ogni file. A partire dalla versione v1.1, werf può utilizzare i checksum calcolati memorizzati nel repository Git.
Alla base dell'algoritmo c'è . L'algoritmo considera le registrazioni in .dockerignore e attraversa ricorsivamente l'albero dei file solo se necessario. In questo modo, ci siamo distaccati dalla lettura del file system e la dipendenza dell'algoritmo dalla dimensione context non è significativa.
L'algoritmo verifica anche i file non tracciati e, se necessario, li include nel checksum.
Migliorata la performance durante l'importazione dei file
Nelle versioni di werf v1.1 viene utilizzato un server rsync durante . In precedenza, l'importazione avveniva in due passaggi utilizzando il montaggio della directory dal sistema host.
Le performance degli import su macOS non sono più limitate dai volumi Docker e gli import vengono eseguiti nello stesso tempo che su Linux e Windows.
Tagging basato sul contenuto
Werf v1.1 supporta quello che viene chiamato il tagging basato sul contenuto dell'immagine — tagging basato sul contenuto. I tag delle immagini Docker risultanti dipendono dal contenuto di queste immagini.
Eseguendo il comando werf publish --tags-by-stages-signature o werf ci-env --tagging-strategy=stages-signature saranno taggate le immagini pubblicate con la cosiddetta firma delle fasi dell'immagine. Ogni immagine è taggata con la propria firma specifica delle fasi di quell'immagine, calcolata secondo le stesse regole della firma regolare di ciascuna fase separatamente, ma è un identificatore generale dell'immagine.
La firma delle fasi dell'immagine dipende da:
- il contenuto di quest'immagine;
- la cronologia delle modifiche in Git che hanno portato a questo contenuto.
Nel repository Git ci sono sempre commit vuoti, che non modificano il contenuto dei file dell'immagine. Ad esempio, commit solo con commenti o merge commit, oppure commit che modificano file in Git che non verranno importati nell'immagine.
Utilizzando il content-based tagging, si risolvono i problemi legati ai riavvii non necessari dei pod dell'applicazione in Kubernetes a causa delle modifiche nel nome dell'immagine, anche se il contenuto dell'immagine non è cambiato. Questo è, infatti, uno dei motivi che ostacolano la conservazione di numerosi microservizi di un'unica applicazione in un singolo repository Git.
Inoltre, il content-based tagging è un metodo di tagging più affidabile rispetto al tagging basato sui rami Git, poiché il contenuto delle immagini risultanti non dipende dall'ordine di esecuzione dei pipeline nei sistemi CI per la compilazione di più commit dello stesso ramo.
Importante: a partire da questo momento stages-signature — rappresenta l'unica strategia di tagging consigliata. Essa sarà utilizzata per impostazione predefinita nel comando werf ci-env (se non viene specificato esplicitamente un altro schema di tagging).
. Questa funzionalità sarà oggetto di una pubblicazione separata. AGGIORNATO (3 aprile): Articolo con dettagli .
Livelli di logging
L'utente ha ora la possibilità di controllare l'output, impostare il livello di logging e lavorare con informazioni di debug. Sono state aggiunte opzioni --log-quiet, --log-verbose, --log-debug.
Per impostazione predefinita, l'output contiene un'informazione minima:
Con l'uso dell'output dettagliato (--log-verbose) è possibile osservare come funziona werf:
L'output dettagliato (--log-debug), oltre alle informazioni di debug di werf, contiene anche i log delle librerie utilizzate. Ad esempio, è possibile vedere come avviene l'interazione con il Docker Registry e registrare i punti in cui viene speso un tempo significativo:
Piani futuri
Attenzione! Le funzionalità descritte di seguito contrassegnate come v1.1 saranno disponibili già in questa versione, molte di esse — a breve. Gli aggiornamenti arriveranno tramite aggiornamenti automatici . Queste funzionalità non influenzano la parte stabile delle funzioni v1.1; il loro arrivo non richiederà interventi manuali da parte dell'utente nelle configurazioni esistenti.
Supporto completo per varie implementazioni del Docker Registry (NUOVO)
- Versione: v1.1
- Tempi: marzo
Obiettivo: l'utente deve poter utilizzare qualsiasi implementazione senza restrizioni con werf.
Attualmente abbiamo identificato il seguente insieme di soluzioni per cui intendiamo garantire il completo supporto:
- Default (library/registry)*,
- AWS ECR,
- Azure*,
- Docker Hub,
- GCR*,
- GitHub Packages,
- GitLab Registry*,
- Harbor*,
- Quay.
Con l'asterisco sono indicate le soluzioni già completamente supportate da werf. Per le altre c'è supporto, ma con limitazioni.
Si possono evidenziare due problemi principali:
- Alcune soluzioni non supportano l'eliminazione dei tag tramite l'API del Docker Registry, il che non consente agli utenti di utilizzare la pulizia automatica implementata in werf. Questo è vero per AWS ECR, Docker Hub e GitHub Packages.
- Alcuni delle soluzioni non supportano i cosiddetti repository annidati (Docker Hub, GitHub Packages e Quay) oppure li supportano, ma l'utente deve crearli manualmente utilizzando l'interfaccia utente o l'API (AWS ECR).
Ci proponiamo di affrontare questi e altri problemi utilizzando le API native delle soluzioni. Questo compito include anche la copertura con test dell'intero ciclo di lavoro di werf per ognuna di esse.
Build distribuita delle immagini (↑)
- Versione: v1.2 v1.1 (la priorità per l'implementazione di questa funzionalità è stata aumentata)
- Scadenze: marzo-aprile marzo
Attualmente, werf v1.0 e v1.1 possono essere utilizzati solo su un singolo host dedicato per le operazioni di build e pubblicazione delle immagini e per il deploy delle applicazioni in Kubernetes.
Per aprire le potenzialità del lavoro distribuito di werf, quando la build e il deploy delle applicazioni in Kubernetes vengono avviati su più host arbitrari e questi host non mantengono il loro stato tra le build (runner temporanei), werf è richiesto di implementare la possibilità di utilizzare il Docker Registry come storage delle fasi.
In passato, quando il progetto werf era ancora chiamato dapp, questa possibilità era presente. Tuttavia, abbiamo affrontato una serie di problemi che devono essere considerati nell'implementazione di questa funzione in werf.
Nota. Questa funzionalità non prevede il funzionamento del builder all'interno dei pod Kubernetes, poiché ciò richiede di eliminare la dipendenza dal server Docker locale (all'interno del pod Kubernetes non c'è accesso al server Docker locale, in quanto il processo stesso è in esecuzione all'interno di un contenitore e werf non supporta e non supporterà il lavoro con il server Docker in rete). Il supporto per l'uso in Kubernetes sarà implementato separatamente.
Supporto ufficiale per GitHub Actions (NUOVO)
- Versione: v1.1
- Tempi: marzo
Include la documentazione di werf (sezioni reference e guida), e anche l'Action ufficiale di GitHub per lavorare con werf.
Inoltre, consentirà a werf di funzionare su runner efimeri.
La meccanica di interazione dell'utente con il sistema CI sarà basata sull'assegnazione di etichette ai pull request per avviare azioni specifiche relative alla compilazione e al rilascio dell'applicazione.
Sviluppo locale e deploy delle applicazioni con werf (↓)
- Versione: v1.1
- Scadenze: gennaio-febbraio aprile
L'obiettivo principale è ottenere una configurazione unificata per il deploy delle applicazioni sia localmente che in produzione, senza complicati passaggi, 'pronto all'uso'.
Da werf è richiesto anche un modo di lavoro in cui sia comodo modificare il codice dell'applicazione e ricevere istantaneamente feedback dall'applicazione funzionante per il debugging.
Nuovo algoritmo di pulizia (NUOVO)
- Versione: v1.1
- Scadenze: aprile
Nella versione attuale di werf v1.1 non è prevista la pulizia delle immagini per lo schema di tagging basato sul contenuto (content-based tagging) — queste immagini si accumuleranno. cleanup Inoltre, nella versione attuale di werf (v1.0 e v1.1) vengono utilizzate politiche di pulizia diverse per le immagini pubblicate secondo gli schemi di tagging: ramo Git, tag Git o commit Git.
È stato creato un nuovo algoritmo unificato per tutti gli schemi di tagging per la pulizia delle immagini basato sulla storia dei commit in Git:
Conservare non più di N1 immagini associate agli ultimi N2 commit per ciascun git HEAD (rami e tag).
- Conservare non più di N1 immagini di fase, associate agli ultimi N2 commit per ciascun git HEAD (rami e tag).
- Conservare non più di N1 immagini-stadio associate agli ultimi N2 commit per ogni git HEAD (branche e tag).
- Conservare tutte le immagini utilizzate in eventuali risorse del cluster Kubernetes (tutti i kube-contesti del file di configurazione e i namespace vengono scansionati; è possibile limitare questo comportamento con opzioni speciali).
- Conservare tutte le immagini utilizzate nei manifesti di configurazione delle risorse memorizzati nei rilasci Helm.
- Un'immagine può essere rimossa se non è collegata a nessun HEAD di git (ad esempio, perché l'HEAD corrispondente è stato eliminato) e non è utilizzata in nessuno dei manifesti nel cluster Kubernetes e nei rilasci Helm.
Build parallele delle immagini (↓)
- Versione: v1.1
- Scadenze: gennaio-febbraio aprile*
L'attuale versione di werf costruisce le immagini e gli artefatti descritti in werf.yaml, in modo sequenziale. È necessario parallelizzare il processo di build delle fasi e degli artefatti indipendenti, nonché garantire un output conveniente e informativo.
* Nota: la scadenza è stata spostata a causa dell'aumento della priorità per l'implementazione della build distribuita, che aggiungerà ulteriori potenzialità per la scalabilità orizzontale, oltre all'uso di werf con GitHub Actions. La build parallela è il passaggio successivo per l'ottimizzazione, che offre scalabilità verticale durante la build di un singolo progetto.
Transizione a Helm 3 (↓)
- Versione: v1.2
- Scadenze: febbraio-marzo maggio*
Include la transizione alla nuova base di codice e un metodo verificato e conveniente per migrare installazioni esistenti.
* Nota: la transizione a Helm 3 non aggiungerà funzionalità significative a werf, poiché tutte le principali funzionalità di Helm 3 (3-way-merge e assenza di tiller) sono già state implementate in werf. Inoltre, werf ha oltre a quelle indicate. Tuttavia, questo passaggio rimane nei nostri piani e sarà realizzato.
Jsonnet per la descrizione della configurazione Kubernetes (↓)
- Versione: v1.2
- Tempistiche: gennaio-febbraio aprile-maggio
Werf supporterà la descrizione della configurazione per Kubernetes in formato Jsonnet. Inoltre, werf rimarrà compatibile con Helm e sarà possibile scegliere il formato di descrizione.
Questo è dovuto al fatto che i modelli del linguaggio Go, secondo molti, hanno una soglia di accesso alta e la comprensibilità del codice di questi modelli ne risente.
È anche in fase di valutazione la possibilità di integrare altri sistemi di descrizione della configurazione Kubernetes (ad esempio, Kustomize).
Lavoro all'interno di Kubernetes (↓)
- Versione: v1.2
- Tempistiche: aprile-maggio maggio-giugno
Obiettivo: garantire la costruzione delle immagini e la distribuzione dell'applicazione utilizzando runner in Kubernetes. Cioè, la costruzione di nuove immagini, la loro pubblicazione, la pulizia e il deploy possono avvenire direttamente dai pod di Kubernetes.
Per implementare questa possibilità, è prima necessaria la capacità di costruzione distribuita delle immagini (vedi il punto precedente).
È anche necessaria la supporto per il funzionamento del builder senza server Docker (cioè, costruzione simile a Kaniko o costruzione in userspace).
Werf supporterà la costruzione in Kubernetes non solo tramite Dockerfile, ma anche con il proprio builder Stapel con ricostruzioni incrementali e Ansible.
Un passo verso lo sviluppo aperto
Amiamo la nostra comunità (, ) e vogliamo che sempre più persone ci aiutino a migliorare werf, comprendano in che direzione stiamo andando e partecipino allo sviluppo.
È stato deciso di passare a per aprire il processo di lavoro del nostro team. Ora è possibile visualizzare i piani a breve termine, così come i lavori attuali nelle seguenti aree:
- ;
- ;
- ;
- .
È stato fatto un grande lavoro con le issue:
- Sono state rimosse quelle obsolete.
- Le esistenti sono state uniformate a un formato comune con un numero sufficiente di dettagli e informazioni.
- Sono state aggiunte nuove issue con idee e proposte.
Come attivare la versione v1.1
La versione è attualmente disponibile in (nei canali stable e rock-solid le versioni appariranno man mano che si stabilizzano, tuttavia ea è già sufficientemente stabile per essere utilizzata, poiché ha attraversato i canali alpha e beta). Si attiva nel seguente modo:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Conclusione
La nuova architettura dello storage delle fasi e l'ottimizzazione del funzionamento del builder per Stapel e Dockerfile aprono opportunità per implementare costruzioni distribuite e parallele in werf. Queste funzioni appariranno presto nello stesso rilascio v1.1 e saranno automaticamente disponibili tramite il meccanismo di aggiornamento automatico (per gli utenti ).
In questo rilascio è stata aggiunta una strategia di tagging basata sul contenuto delle immagini — tagging basato sul contenuto, — che è diventata la strategia predefinita. È stata inoltre rielaborata la log delle principali comandi: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Il prossimo passo significativo sarà l'aggiunta delle costruzioni distribuite. Le costruzioni distribuite dalla versione v1.0 sono diventate un compito più prioritario rispetto alle costruzioni parallele, poiché aggiungono maggior valore a werf: scalabilità verticale dei builders e supporto per builders efimeri in vari sistemi CI/CD, oltre alla possibilità di fornire supporto ufficiale a GitHub Actions. Pertanto, le tempistiche per l'implementazione delle costruzioni parallele sono state spostate. Tuttavia, stiamo lavorando per implementare entrambe le funzionalità il prima possibile.
Segui gli aggiornamenti! E non dimenticare di visitare il nostro , per creare una issue, trovarne già esistente e votare, creare una PR o semplicemente osservare lo sviluppo del progetto.
P.S.
Leggete anche nel nostro blog:
- «»
- «»;
- Ciclo di note sulle novità in werf:
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
