— la nostra CLI GitOps open source per la costruzione e distribuzione di applicazioni in Kubernetes. Come promesso, ha segnato l'inizio dell'aggiunta di nuove funzionalità a werf e della revisione degli approcci consolidati. Siamo ora lieti di presentare il rilascio v1.1, che rappresenta un grande passo avanti nello sviluppo e una base per il futuro del costruttore werf. Al momento, la versione è disponibile su .
Il fulcro del rilascio è una nuova architettura di archiviazione delle fasi e l'ottimizzazione del lavoro di entrambi i costruttori (per Stapel e Dockerfile). La nuova architettura di archiviazione apre opportunità per implementare costruzioni distribuite da più host e costruzioni parallele su un solo host.
L'ottimizzazione del lavoro include l'eliminazione di calcoli non necessari nella fase di calcolo delle firme e la modifica dei meccanismi di calcolo delle somme di controllo dei file in modi più efficienti. Questa ottimizzazione riduce il tempo medio delle costruzioni di progetto tramite werf. E le costruzioni a vuoto, quando tutte le fasi esistono nella cache stages-storage, ora sono davvero veloci. Nella maggior parte dei casi, il riavvio della costruzione sarà più veloce di 1 secondo! Questo vale anche per le procedure di verifica delle fasi durante l'attività delle squadre werf deploy e werf run.
Inoltre, in questo rilascio è stata introdotta una strategia di tagging delle immagini basata sul contenuto — tagging basato sul contenuto, che ora è abilitata per impostazione predefinita ed è l'unica raccomandata.
Esaminiamo più da vicino le principali novità in werf v1.1 e parleremo anche dei piani per il futuro.
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 delle fasi. Ora ogni costruzione di fase genera un nome unico, composto da 2 parti: firma (come era in v1.0) più un identificatore temporale unico.
Ad esempio, il nome completo dell'immagine della fase potrebbe essere:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
… oppure in forma generale:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Qui:
-
SIGNATURE— è la firma della fase, che rappresenta l'identificatore del contenuto della fase e dipende dalla cronologia delle modifiche in Git che hanno portato a quel contenuto; -
TIMESTAMP_MILLISEC— è un identificatore dell'immagine garantito unico, generato al momento della costruzione di una nuova immagine.
L'algoritmo di selezione delle fasi dalla cache si basa sul controllo della parentela dei commit Git:
- Werf calcola la firma di una certa fase.
- In stages-storage Possono esistere più fasi con la stessa firma. Werf seleziona tutte le fasi idonee in base alla firma.
- Se la fase attuale è associata a Git (git-archive, fase personalizzata con patch Git:
install,beforeSetup,setup; o git-latest-patch), werf seleziona solo le fasi associate a un commit che è un antenato del commit corrente (per il quale è stata avviata la raccolta). - Tra le fasi idonee rimanenti, viene selezionata una — la più vecchia in base alla data di creazione.
Le fasi per ramificazioni Git diverse possono avere la stessa firma. Ma werf impedirà l'uso della cache associata a diverse ramificazioni tra queste ramificazioni, anche se le firme coincidono.
.
Nuovo algoritmo per la creazione e il salvataggio delle fasi nel deposito delle fasi
Se durante la selezione delle fasi dalla cache werf non trova una fase adatta, viene avviato 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 più o meno allo stesso tempo. Werf utilizza un algoritmo di blocco ottimista stages-storage al momento del salvataggio di un'immagine appena creata in stages-storage. Pertanto, quando la costruzione di una nuova fase è pronta, werf blocca stages-storage e salva l'immagine appena creata solo se non esiste già un'immagine adatta (in base alla firma e altri parametri — si veda il nuovo algoritmo di selezione delle fasi dalla cache).
L'immagine appena creata avrà sicuramente un identificatore unico in base a TIMESTAMP_MILLISEC (si veda il nuovo formato di denominazione delle fasi). Nel caso in cui venga trovata un'immagine adatta in stages-storage , werf scarterà l'immagine appena creata e utilizzerà l'immagine dalla cache.
In altre parole: il primo processo che termina di costruire l'immagine (quello più veloce) avrà il diritto di salvarla nello storage delle fasi (e quindi questa unica immagine sarà utilizzata per tutte le costruzioni). Tuttavia, il processo di costruzione più lento non bloccherà mai il processo più veloce dal salvare i risultati della costruzione della fase corrente e passare alla costruzione della successiva.
.
Migliorata la performance del costruttore Dockerfile
Attualmente, il processo delle fasi per l'immagine costruita da un Dockerfile consiste in una fase — dockerfile. Nella calcolo della firma viene considerato il checksum dei file context, che verranno utilizzati durante l'assemblaggio. Fino a questo miglioramento, werf eseguiva un passaggio ricorsivo su tutti i file e calcolava la somma di controllo, sommando il contesto e il modulo di ogni file. A partire dalle versioni v1.1, werf può utilizzare le somme di controllo calcolate archiviate nel repository Git.
Alla base dell'algoritmo c'è . L'algoritmo tiene conto delle voci in .dockerignore e attraversa ricorsivamente l'albero dei file solo se necessario. In questo modo, ci siamo liberati dalla lettura del file system, e la dipendenza dell'algoritmo dalla dimensione context non è significativa.
L'algoritmo verifica anche i file non tracciati e li include nella somma di controllo se necessario.
È stata migliorata la performance durante l'importazione dei file
Nelle versioni di werf v1.1 viene utilizzato un server rsync durante . In precedenza, l'importazione veniva eseguita in due passaggi utilizzando il montaggio della directory dal sistema host.
Le performance delle importazioni su macOS non sono più limitate ai volumi Docker, e le importazioni vengono effettuate nello stesso tempo che in Linux e Windows.
Tagging basato sul contenuto
Werf v1.1 supporta il cosiddetto tagging basato sul contenuto dell'immagine — tagging basato sul contenuto. I tag delle immagini Docker risultanti dipendono dal contenuto di queste immagini.
Quando si esegue il comando werf publish --tags-by-stages-signature o werf ci-env --tagging-strategy=stages-signature saranno etichettate le immagini pubblicate con quella che viene definita firma delle fasi dell'immagine. Ogni immagine viene etichettata con la propria firma delle fasi di questa immagine, che viene calcolata secondo le stesse regole della firma regolare di ciascuna fase separatamente, ma rappresenta un identificatore generale dell'immagine.
La firma delle fasi dell'immagine dipende da:
- il contenuto di questa 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, i commit con solo commenti o commit di fusione, o commit che modificano quei file in Git che non saranno importati nell'immagine.
Utilizzando il tagging basato sul contenuto, si risolvono i problemi dei 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 è, peraltro, uno dei motivi che ostacolano la memorizzazione di numerosi microservizi di una stessa applicazione in un unico repository Git.
Il tagging basato sul contenuto è un metodo di tagging più affidabile rispetto al tagging delle branche Git, poiché il contenuto delle immagini risultanti non dipende dall'ordine di esecuzione delle pipeline nel sistema CI per costruire più commit della stessa branca.
Importante: a partire da questo momento stages-signature è l'unica strategia di tagging raccomandata. Sarà utilizzata per impostazione predefinita nel team werf ci-env (a meno che non venga specificato esplicitamente un altro schema di tagging).
. A questa funzionalità sarà dedicata anche una pubblicazione separata. AGGIORNATO (3 aprile): Articolo con i dettagli .
Livelli di logging
L'utente ha la possibilità di controllare l'output, impostare il livello di logging e lavorare con le informazioni di debug. Sono state aggiunte le opzioni --log-quiet, --log-verbose, --log-debug.
Per impostazione predefinita, l'output contiene informazioni minime:
Utilizzando un output dettagliato (--log-verbose) è possibile seguire come funziona werf:
L'output dettagliato (--log-debug), oltre alle informazioni di debug di werf, include anche i log delle librerie utilizzate. Ad esempio, è possibile vedere come avviene l'interazione con Docker Registry, oltre a registrare i punti in cui viene speso un tempo considerevole:
Piani futuri
Attenzione! Le funzionalità descritte di seguito con l'etichetta v1.1 saranno disponibili già in questa versione, molte di esse — a breve. Gli aggiornamenti arriveranno tramite autoaggiornamenti . Queste funzionalità non influenzano la parte stabile delle funzioni v1.1, la loro comparsa non richiederà l'intervento manuale dell'utente nelle configurazioni già esistenti.
Supporto completo per diverse implementazioni di Docker Registry (NUOVO)
- Versione: v1.1
- Scadenze: marzo
Obiettivo — l'utente deve poter utilizzare qualsiasi implementazione senza limiti nell'uso di werf.
Attualmente abbiamo identificato il seguente insieme di soluzioni per le quali siamo pronti a garantire un supporto completo:
- Default (library/registry)*,
- AWS ECR,
- Azure*,
- Docker Hub,
- GCR*,
- GitHub Packages,
- GitLab Registry*,
- Harbor*,
- Quay.
Le soluzioni contrassegnate con asterisco sono quelle attualmente già completamente supportate da werf. Per le altre esiste supporto, ma con limitazioni.
Possiamo evidenziare due problemi principali:
- Alcune soluzioni non supportano la rimozione dei tag tramite l'API di 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.
- Alcune soluzioni non supportano, così dette, repository annidate (Docker Hub, GitHub Packages e Quay) o le supportano, ma l'utente deve crearle manualmente utilizzando l'interfaccia utente o l'API (AWS ECR).
Queste e altre problematiche intendiamo affrontare utilizzando le API native delle soluzioni. Questa attività include anche la copertura con test dell'intero ciclo di lavoro di werf per ciascuna di esse.
Costruzione distribuita delle immagini (↑)
- Versione: v1.2 v1.1 (la priorità per l'implementazione di questa funzionalità è stata aumentata)
- Tempistiche: marzo-aprile marzo
Attualmente, werf v1.0 e v1.1 possono essere utilizzati solo su un singolo host dedicato per le operazioni di costruzione e pubblicazione delle immagini e il deployment delle applicazioni in Kubernetes.
Per abilitare le funzionalità di lavoro distribuito di werf, quando la costruzione e il deployment delle applicazioni in Kubernetes vengono eseguiti su più host arbitrari e questi host non mantengono il proprio stato tra le costruzioni (runner temporanei), werf richiede l'implementazione della possibilità di utilizzare Docker Registry come archivio delle fasi.
In precedenza, quando il progetto werf era ancora chiamato dapp, questa possibilità esisteva. Tuttavia, abbiamo incontrato una serie di problemi che è necessario considerare nell'implementazione di questa funzione in werf.
Nota. Questa possibilità non prevede il funzionamento del costruttore all'interno dei pod di Kubernetes, poiché per questo è necessario eliminare la dipendenza dal server Docker locale (nel pod di Kubernetes non c'è accesso al server Docker locale, perché il processo stesso è in esecuzione in un contenitore, e werf non supporta e non supporterà l'accesso al server Docker in rete). Il supporto per l'operatività in Kubernetes sarà implementato separatamente.
Supporto ufficiale per GitHub Actions (NUOVO)
- Versione: v1.1
- Scadenze: marzo
Include documentazione werf (sezioni reference e guida), oltre a un'azione ufficiale di GitHub per lavorare con werf.
Inoltre, consentirà a werf di funzionare su runner effimeri.
La meccanica di interazione dell'utente con il sistema CI si baserà sulla definizione di etichette alle pull request per innescare determinate azioni di costruzione/rollout dell'applicazione.
Sviluppo locale e deployment delle applicazioni con werf (↓)
- Versione: v1.1
- Tempistiche: gennaio-febbraio aprile
L'obiettivo principale è ottenere una configurazione unificata per il deployment delle applicazioni sia in locale che in produzione, senza operazioni complesse, "pronto all'uso".
Da werf è richiesto anche un regime di lavoro in cui sia comodo modificare il codice dell'applicazione e ricevere immediatamente feedback dall'applicazione in esecuzione per il debug.
Nuovo algoritmo di pulizia (NUOVO)
- Versione: v1.1
- Scadenze: aprile
Nella versione corrente di werf v1.1 nella procedura ripulire non è prevista la pulizia delle immagini per lo schema di tagging basato sul contenuto (content-based tagging) — queste immagini si accumuleranno.
Nella versione attuale di werf (v1.0 e v1.1) sono utilizzate politiche di pulizia diverse per le immagini pubblicate secondo gli schemi di tagging: Git-branch, Git-tag o Git-commit.
È stato ideato un nuovo algoritmo di pulizia unificato per tutti gli schemi di tagging basato sulla cronologia dei commit in Git:
- Mantenere non più di N1 immagini associate agli ultimi N2 commit per ciascun git HEAD (branch e tag).
- Mantenere non più di N1 immagini-stadio associate agli ultimi N2 commit per ciascun git HEAD (branch e tag).
- Mantenere tutte le immagini utilizzate in risorse del cluster Kubernetes (tutti i kube-contesti nel file di configurazione e i namespace saranno esaminati; questo comportamento può essere limitato da opzioni speciali).
- Mantenere tutte le immagini utilizzate nei manifest di configurazione delle risorse salvati nei rilasci Helm.
- Un'immagine può essere rimossa se non è associata a nessun HEAD di git (ad esempio, perché l'HEAD corrispondente è stato eliminato) e non viene utilizzata in alcun manifest nel cluster Kubernetes e nei rilasci Helm.
Build parallele delle immagini (↓)
- Versione: v1.1
- Scadenze: gennaio-febbraio aprile*
La versione corrente di werf costruisce immagini e artefatti, descritti in werf.yaml, in modo sequenziale. È necessario parallelizzare il processo di costruzione di stadi indipendenti delle immagini e artefatti, e fornire un output chiaro e informativo.
* Nota: la scadenza è stata spostata a causa dell'aumento della priorità nell'implementazione della build distribuita, che aggiungerà ulteriori possibilità di scalabilità orizzontale, nonché l'uso di werf con GitHub Actions. La build parallela è il prossimo passo nell'ottimizzazione, che fornisce scalabilità verticale durante la costruzione di un singolo progetto.
Transizione a Helm 3 (↓)
- Versione: v1.2
- Scadenze: febbraio-marzo maggio*
Include la transizione a una nuova base di codice e un modo collaudato e semplice per migrare installazioni esistenti.
* Nota: il passaggio a Helm 3 non aggiungerà funzionalità significative a werf, poiché tutte le funzionalità chiave di Helm 3 (3-way-merge e assenza di tiller) sono già state implementate in werf. Inoltre, werf possiede oltre a quelle menzionate. Tuttavia, questo passaggio rimane nei nostri piani e sarà realizzato.
Jsonnet per descrivere la configurazione di Kubernetes (↓)
- Versione: v1.2
- Tempistiche: gennaio-febbraio aprile-maggio
Werf supporterà la descrizione della configurazione per Kubernetes nel formato Jsonnet. Allo stesso tempo, werf rimarrà compatibile con Helm e ci sarà la possibilità di scelta del formato di descrizione.
La ragione è che i template del linguaggio Go, secondo molti, hanno una soglia di accesso elevata e la comprensibilità del codice di questi template ne soffre.
Si sta anche considerando la possibilità di implementare altri sistemi di descrizione della configurazione di Kubernetes (ad esempio, Kustomize).
Lavoro all'interno di Kubernetes (↓)
- Versione: v1.2
- Tempistiche: aprile-maggio maggio-giugno
Obiettivo: garantire la creazione di immagini e la distribuzione dell'applicazione utilizzando runner in Kubernetes. Cioè, la creazione di nuove immagini, la loro pubblicazione, la pulizia e il deploy possono avvenire direttamente dai pod di Kubernetes.
Per realizzare questa possibilità, è prima richiesta la funzionalità di creazione distribuita di immagini (vedi punto sopra).
È inoltre necessaria la supporto della modalità di funzionamento del builder senza server Docker (cioè, creazione simile a Kaniko o creazione in userspace).
Werf supporterà la creazione in Kubernetes non solo tramite Dockerfile, ma anche tramite 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 aiutino a rendere werf migliore, comprendano in quale direzione ci stiamo muovendo e partecipino allo sviluppo.
Recentemente è stata presa la decisione di passare a per aprire il processo di lavoro del nostro team. Ora è possibile vedere i piani a breve termine, nonché i lavori attuali nelle seguenti aree:
- ;
- ;
- ;
- .
È stato fatto un grande lavoro con le issues:
- Sono state rimosse quelle non più rilevanti.
- Le esistenti sono state portate a un formato unico, con un numero sufficiente di dettagli e informazioni.
- Sono state aggiunte nuove issues 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 stabilizzano, tuttavia ea essa stessa è già sufficientemente stabile per l'uso, poiché è passata attraverso i canali alpha e beta). Si attiva nel seguente modo:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Conclusione
Una nuova architettura per il deposito degli stati e l'ottimizzazione del funzionamento del builder per Stapel e Dockerfile aprono la possibilità di realizzare build distribuite e parallele in werf. Queste funzionalità saranno presto disponibili nella stessa release v1.1 e saranno automaticamente accessibili tramite il meccanismo degli aggiornamenti automatici (per gli utenti ).
In questa release è stata aggiunta una strategia di tagging basata sul contenuto delle immagini — tagging basato sul contenuto, — che è diventata la strategia predefinita. Inoltre, è stata rivista la logica dei comandi principali: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Il prossimo passo significativo sarà l'aggiunta di build distribuite. Le build distribuite sono diventate un compito più prioritario rispetto alle build parallele da v1.0, poiché aggiungono maggiore valore a werf: scalabilità verticale dei builder e supporto per builder effimeri in vari sistemi CI/CD, oltre alla possibilità di offrire supporto ufficiale per GitHub Actions. Pertanto, i tempi per l'implementazione delle build parallele sono stati posticipati. Tuttavia, stiamo lavorando per implementare entrambe le funzionalità il prima possibile.
Rimanete aggiornati! E non dimenticate di farci visita a , per creare un issue, trovare uno già esistente e mettere un like, creare un PR o semplicemente osservare l'evoluzione del progetto.
P.S.
Leggi anche nel nostro blog:
- «»
- «»;
- Ciclo di note sulle novità in werf:
- «»;
- «»;
- «»;
- «».
Fonte: habr.com
