🥇Versione Werf 1.1: miglioramenti nel raccoglitore oggi e piani per il futuro

werf è la nostra utility CLI GitOps open source per la creazione e la distribuzione di applicazioni su Kubernetes. Come promesso, rilascio della versione v1.0 ha segnato l'inizio dell'aggiunta di nuove funzionalità al werf e della revisione degli approcci tradizionali. Ora siamo lieti di presentare la versione v1.1, che rappresenta un grande passo avanti nello sviluppo e una base per il futuro collettore werf. La versione è attualmente disponibile in canale 1.1 cad.

La base del rilascio è la nuova architettura dello storage dello stage e l'ottimizzazione del lavoro di entrambi i raccoglitori (per Stapel e Dockerfile). La nuova architettura di storage apre la possibilità di implementare gruppi distribuiti da più host e gruppi paralleli sullo stesso host.

L'ottimizzazione del lavoro include l'eliminazione di calcoli non necessari nella fase di calcolo delle firme delle fasi e la modifica dei meccanismi per il calcolo dei checksum dei file in meccanismi più efficienti. Questa ottimizzazione riduce il tempo medio di realizzazione del progetto utilizzando werf. E build inattive, quando tutte le fasi esistono nella cache fasi-immagazzinamento, ora sono davvero veloci. Nella maggior parte dei casi, il riavvio della build richiederà meno di 1 secondo! Ciò vale anche per le procedure di verifica delle fasi del processo di lavoro dei team. werf deploy и werf run.

Anche in questa versione è apparsa una strategia per taggare le immagini in base al contenuto: tagging basato sul contenuto, che ora è abilitato per impostazione predefinita e l'unico consigliato.

Diamo uno sguardo più da vicino alle principali innovazioni di werf v1.1 e allo stesso tempo vi parliamo dei piani per il futuro.

Cosa è cambiato in werf v1.1?

Nuovo formato di denominazione delle fasi e algoritmo per la selezione delle fasi dalla cache

Nuova regola per la generazione dei nomi d'arte. Ora ogni fase di build genera un nome di fase univoco, composto da 2 parti: una firma (come era nella versione 1.0) più un identificatore temporaneo univoco.

Ad esempio, il nome completo dell'immagine dello stage potrebbe assomigliare a questo:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

...o in generale:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

Qui:

SIGNATURE è una firma dello stage, che rappresenta l'identificatore del contenuto dello stage e dipende dalla cronologia delle modifiche in Git che hanno portato a questo contenuto;
TIMESTAMP_MILLISEC è un identificatore di immagine univoco garantito che viene generato nel momento in cui viene creata una nuova immagine.

L'algoritmo per la selezione delle fasi dalla cache si basa sul controllo della relazione dei commit Git:

Werf calcola la firma di un determinato stadio.
В fasi-immagazzinamento Potrebbero esserci diverse fasi per una determinata firma. Werf seleziona tutte le fasi che corrispondono alla firma.
Se la fase corrente è collegata 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 viene chiamata la build).
Dalle rimanenti fasi idonee ne viene selezionata una: la più vecchia per data di creazione.

Una fase per diversi rami Git può avere la stessa firma. Ma werf impedirà che la cache associata a rami diversi venga utilizzata tra questi rami, anche se le firme corrispondono.

→ Documentazione.

Nuovo algoritmo per la creazione e il salvataggio degli stage nell'archivio stage

Se, quando si selezionano gli stadi dalla cache, werf non trova uno stadio adatto, viene avviato il processo di assemblaggio di un nuovo stadio.

Tieni presente che più processi (su uno o più host) possono iniziare a costruire la stessa fase all'incirca nello stesso momento. Werf utilizza un algoritmo di blocco ottimistico fasi-immagazzinamento al momento di salvare l'immagine appena raccolta in fasi-immagazzinamento. In questo modo, quando la nuova costruzione dello stage è pronta, werf blocca fasi-immagazzinamento e salva lì un'immagine appena raccolta solo se lì non esiste più un'immagine adatta (per firma e altri parametri - vedi il nuovo algoritmo per la selezione delle fasi dalla cache).

Un'immagine appena assemblata avrà sicuramente un identificatore univoco tramite TIMESTAMP_MILLISEC (vedi il nuovo formato di denominazione delle fasi). Nel caso in fasi-immagazzinamento verrà trovata un'immagine adatta, werf scarterà l'immagine appena compilata e utilizzerà l'immagine dalla cache.

In altre parole: il primo processo che termina di costruire l'immagine (quello più veloce) otterrà il diritto di memorizzarla in stage-storage (e quindi sarà questa singola immagine che verrà utilizzata per tutte le build). Un processo di compilazione lento non impedirà mai a un processo più veloce di salvare i risultati di compilazione della fase corrente e passare alla build successiva.

→ Documentazione.

Prestazioni del generatore Dockerfile migliorate

Al momento, la pipeline di fasi per un'immagine creata da un Dockerfile è costituita da una fase: dockerfile. Quando si calcola la firma, viene calcolata la somma di controllo dei file context, che verrà utilizzato durante il montaggio. Prima di questo miglioramento, werf esaminava ricorsivamente tutti i file e otteneva un checksum sommando il contesto e la modalità di ciascun file. A partire dalla versione 1.1, werf può utilizzare checksum calcolati archiviati in un repository Git.

L'algoritmo è basato su git ls-albero. L'algoritmo tiene conto dei record in .dockerignore e attraversa ricorsivamente l'albero dei file solo quando necessario. Pertanto, abbiamo disaccoppiato la lettura del file system e la dipendenza dell'algoritmo dalla dimensione context non è significativo.

L'algoritmo controlla anche i file non tracciati e, se necessario, li tiene in considerazione nel checksum.

Prestazioni migliorate durante l'importazione di file

Le versioni di werf v1.1 utilizzano un server rsync quando importare file da artefatti e immagini. In precedenza, l'importazione veniva eseguita in due passaggi utilizzando il montaggio di directory dal sistema host.

Le prestazioni di importazione su macOS non sono più limitate dai volumi Docker e le importazioni vengono completate nello stesso tempo di Linux e Windows.

Tagging basato sul contenuto

Werf v1.1 supporta il cosiddetto tagging in base al 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 immagini pubblicate dei cosiddetti firma scenica Immagine. Ogni immagine è contrassegnata con la propria firma delle fasi di questa immagine, che viene 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 questa immagine;
storie delle modifiche Git che hanno portato a questo contenuto.

Un repository Git ha sempre commit fittizi che non modificano il contenuto dei file immagine. Ad esempio, commit con solo commenti o commit di unione o commit che modificano i file in Git che non verranno importati nell'immagine.

Quando si utilizza il tagging basato sul contenuto, i problemi di riavvii non necessari dei pod dell'applicazione in Kubernetes dovuti a modifiche nel nome dell'immagine vengono risolti, anche se il contenuto dell'immagine non è cambiato. A proposito, questo è uno dei motivi che impedisce di archiviare molti microservizi di un'applicazione in un unico repository Git.

Inoltre, il tagging basato sul contenuto è un metodo di tagging più affidabile rispetto al tagging sui rami Git, perché il contenuto delle immagini risultanti non dipende dall'ordine in cui le pipeline vengono eseguite nel sistema CI per assemblare più commit dello stesso ramo.

È importante: a partire da adesso tappe-firma - E ' l'unica strategia di tagging consigliata. Verrà utilizzato per impostazione predefinita nel comando werf ci-env (a meno che tu non specifichi esplicitamente uno schema di tagging diverso).

→ Documentazione. A questo aspetto sarà dedicata anche una pubblicazione a parte. AGGIORNATO (3 aprile): articolo con dettagli pubblicato.

Livelli di registrazione

L'utente ora ha l'opportunità di controllare l'output, impostare il livello di registrazione e lavorare con le informazioni di debug. Opzioni aggiunte --log-quiet, --log-verbose, --log-debug.

Per impostazione predefinita, l'output contiene le informazioni minime:

Quando si utilizza un output dettagliato (--log-verbose) puoi vedere come funziona werf:

Risultati dettagliati (--log-debug), oltre alle informazioni di debugging werf, contiene anche i log delle librerie utilizzate. Ad esempio, puoi vedere come avviene l'interazione con il Docker Registry e anche registrare i luoghi in cui viene trascorsa una quantità significativa di tempo:

Ulteriori piani

Attenzione! Le opzioni descritte di seguito sono contrassegnate v1.1 saranno disponibili in questa versione, molti di loro nel prossimo futuro. Gli aggiornamenti arriveranno tramite aggiornamenti automatici quando si utilizza multiwerf. Queste funzionalità non influiscono sulla parte stabile delle funzioni v1.1; il loro aspetto non richiederà l'intervento manuale dell'utente nelle configurazioni esistenti.

Supporto completo per varie implementazioni del registro Docker (NOVITÀ)

Versione: v1.1
Date: marzo
Problema

L'obiettivo è che l'utente utilizzi un'implementazione personalizzata senza restrizioni quando utilizza werf.

Attualmente abbiamo identificato il seguente insieme di soluzioni per le quali garantiremo il pieno supporto:

Predefinito (libreria/registro)*,
AWSREC
Azzurro*,
Hub Docker
GCR*,
Pacchetti GitHub
Registro GitLab*,
Porto*,
Banchina.

Le soluzioni attualmente completamente supportate da werf sono contrassegnate da un asterisco. Per altri c'è supporto, ma con limitazioni.

Si possono identificare due problemi principali:

Alcune soluzioni non supportano la rimozione dei tag utilizzando l'API Docker Registry, impedendo agli utenti di utilizzare la pulizia automatica di werf. Questo vale per AWS ECR, Docker Hub e i pacchetti GitHub.
Alcune soluzioni non supportano i cosiddetti repository nidificati (Docker Hub, GitHub Packages e Quay) o lo fanno, ma l'utente deve crearli manualmente utilizzando l'interfaccia utente o l'API (AWS ECR).

Risolveremo questi e altri problemi utilizzando le API native delle soluzioni. Questo compito include anche la copertura dell'intero ciclo di funzionamento del werf con test per ciascuno di essi.

Creazione di immagini distribuite (↑)

Versione: v1.2 v1.1 (la priorità per l'implementazione di questa funzionalità è stata aumentata)
Date: marzo-aprile marzo
Problema

Al momento, werf v1.0 e v1.1 possono essere utilizzati solo su un host dedicato per operazioni di creazione e pubblicazione di immagini e distribuzione dell'applicazione su Kubernetes.

Per aprire le possibilità del lavoro distribuito di werf, quando la creazione e la distribuzione di applicazioni in Kubernetes vengono avviate su diversi host arbitrari e questi host non salvano il loro stato tra build (corridori temporanei), werf è tenuto a implementare la capacità di utilizzare il Docker Registry come archivio scenico.

In precedenza, quando il progetto werf si chiamava ancora dapp, aveva questa opportunità. Tuttavia, abbiamo riscontrato una serie di problemi di cui tenere conto durante l'implementazione di questa funzionalità in werf.

Nota. Questa funzionalità non richiede che il raccoglitore funzioni all'interno dei pod Kubernetes, perché Per fare ciò, è necessario eliminare la dipendenza dal server Docker locale (nel pod Kubernetes non c'è accesso al server Docker locale, perché il processo stesso è in esecuzione in un contenitore e werf non supporta e non supporterà lavorare con il server Docker in rete). Il supporto per l'esecuzione di Kubernetes verrà implementato separatamente.

Supporto ufficiale per GitHub Actions (NUOVO)

Versione: v1.1
Date: marzo
Problema

Include la documentazione del werf (sezioni riferimento и guida), così come GitHub Action ufficiale per lavorare con werf.

Inoltre, consentirà a Werf di lavorare su corridori effimeri.

La meccanica dell'interazione dell'utente con il sistema CI sarà basata sull'inserimento di etichette sulle richieste pull per avviare determinate azioni per creare/distribuire l'applicazione.

Sviluppo locale e distribuzione di applicazioni con werf (↓)

Versione: v1.1
Date: gennaio-febbraio aprile
Problema

L'obiettivo principale è ottenere un'unica configurazione unificata per la distribuzione delle applicazioni sia localmente che in produzione, senza azioni complesse, fuori dagli schemi.

werf deve inoltre avere una modalità operativa in cui sarà conveniente modificare il codice dell'applicazione e ricevere immediatamente feedback dall'applicazione in esecuzione per il debug.

Nuovo algoritmo di pulizia (NUOVO)

Versione: v1.1
Date: aprile
Problema

Nella versione attuale di werf v1.1 nella procedura cleanup Non è prevista la pulizia delle immagini per lo schema di tagging basato sul contenuto: queste immagini si accumuleranno.

Inoltre, la versione attuale di werf (v1.0 e v1.1) utilizza diverse politiche di pulizia per le immagini pubblicate con schemi di tagging: ramo Git, tag Git o commit Git.

È stato inventato un nuovo algoritmo per la pulizia delle immagini basato sulla cronologia dei commit in Git, unificato per tutti gli schemi di tagging:

Conserva non più di N1 immagini associate agli N2 commit più recenti per ogni git HEAD (rami e tag).
Memorizza non più di N1 immagini di stage associate agli N2 commit più recenti per ogni git HEAD (rami e tag).
Archivia tutte le immagini utilizzate in qualsiasi risorsa del cluster Kubernetes (vengono scansionati tutti i contesti kube del file di configurazione e degli spazi dei nomi; puoi limitare questo comportamento con opzioni speciali).
Archivia tutte le immagini utilizzate nei manifesti di configurazione delle risorse salvati nelle versioni Helm.
Un'immagine può essere eliminata se non è associata ad alcun HEAD da git (ad esempio, perché l'HEAD corrispondente stesso è stato eliminato) e non viene utilizzata in nessun manifest nel cluster Kubernetes e nelle versioni Helm.

Costruzione di immagini parallele (↓)

Versione: v1.1
Date: gennaio-febbraio aprile*

La versione attuale di werf raccoglie le immagini e gli artefatti descritti in werf.yaml, in sequenza. È necessario parallelizzare il processo di assemblaggio di fasi indipendenti di immagini e artefatti, nonché fornire output convenienti e informativi.

* Nota: la scadenza è stata spostata a causa della maggiore priorità per l'implementazione dell'assemblaggio distribuito, che aggiungerà ulteriori funzionalità di ridimensionamento orizzontale, nonché l'uso di werf con GitHub Actions. L'assemblaggio parallelo è il passaggio successivo dell'ottimizzazione, fornendo scalabilità verticale durante l'assemblaggio di un progetto.

Transizione al timone 3 (↓)

Versione: v1.2
Date: febbraio-marzo maggio*

Include la migrazione alla nuova codebase Timone 3 e un modo comprovato e conveniente per migrare le installazioni esistenti.

* Nota: il passaggio a Helm 3 non aggiungerà funzionalità significative a werf, poiché tutte le funzionalità chiave di Helm 3 (unione a 3 vie e assenza di timone) sono già implementate in werf. Inoltre, Werf ha caratteristiche aggiuntive oltre a quelli indicati. Tuttavia, questa transizione rimane nei nostri piani e verrà implementata.

Jsonnet per descrivere la configurazione di Kubernetes (↓)

Versione: v1.2
Date: gennaio-febbraio aprile-maggio

Werf supporterà le descrizioni di configurazione per Kubernetes in formato Jsonnet. Allo stesso tempo, werf rimarrà compatibile con Helm e sarà possibile scegliere il formato della descrizione.

Il motivo è che i modelli Go, secondo molte persone, hanno un'elevata barriera all'ingresso e anche la comprensibilità del codice di questi modelli ne risente.

Si sta valutando anche la possibilità di introdurre altri sistemi di descrizione della configurazione di Kubernetes (ad esempio Kustomize).

Lavorare all'interno di Kubernetes (↓)

Versione: v1.2
Date: aprile-maggio maggio-giugno

Obiettivo: garantire che le immagini vengano create e che l'applicazione venga distribuita utilizzando i runner in Kubernetes. Quelli. È possibile creare, pubblicare, pulire e distribuire nuove immagini direttamente dai pod Kubernetes.

Per implementare questa funzionalità, devi prima essere in grado di creare immagini distribuite (vedi punto sopra).

Richiede inoltre il supporto per la modalità operativa del builder senza un server Docker (ad esempio build simile a Kaniko o build nello spazio utente).

Werf supporterà la creazione su Kubernetes non solo con Dockerfile, ma anche con il suo builder Stapel con ricostruzioni incrementali e Ansible.

Un passo verso lo sviluppo aperto

Amiamo la nostra comunità (GitHub, Telegram) e vogliamo che sempre più persone contribuiscano a migliorare Werf, comprendano la direzione in cui ci stiamo muovendo e partecipino allo sviluppo.

Di recente si è deciso di passare a Schede di progetto GitHub per rivelare il processo di lavoro del nostro team. Ora puoi vedere i piani immediati, nonché il lavoro attuale nelle seguenti aree:

È stato fatto molto lavoro sui problemi:

Rimossi quelli irrilevanti.
Quelli esistenti vengono portati in un unico formato, con un numero sufficiente di dettagli e dettagli.
Sono stati aggiunti nuovi numeri con idee e suggerimenti.

Come abilitare la versione v1.1

La versione è attualmente disponibile in canale 1.1 cad (nei canali stabile и roccia solida Tuttavia, i rilasci appariranno man mano che si verifica la stabilizzazione ea stesso è già abbastanza stabile per l'uso, perché passato per i canali alfa и beta). Attivato tramite multiwerf nel seguente modo:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

conclusione

La nuova architettura di storage degli stage e le ottimizzazioni dei builder per Stapel e Dockerfile aprono la possibilità di implementare build distribuite e parallele in werf. Queste funzionalità appariranno presto nella stessa versione v1.1 e diventeranno automaticamente disponibili attraverso il meccanismo di aggiornamento automatico (per gli utenti multiwerf).

In questa versione è stata aggiunta una strategia di tagging basata sul contenuto dell'immagine: tagging basato sul contenuto, che è diventata la strategia predefinita. Anche il registro dei comandi principale è stato rielaborato: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Il prossimo passo significativo consiste nell'aggiungere assembly distribuiti. Le build distribuite sono diventate una priorità più alta rispetto alle build parallele dalla versione 1.0 perché aggiungono più valore a werf: scalabilità verticale dei builder e supporto per builder temporanei in vari sistemi CI/CD, nonché la possibilità di fornire supporto ufficiale per le azioni GitHub . Pertanto, i termini di attuazione per le assemblee parallele sono stati spostati. Stiamo comunque lavorando per implementare entrambe le possibilità il prima possibile.

Segui le notizie! E non dimenticare di venirci a trovare GitHubper creare un problema, trovarne uno esistente e aggiungere un plus, creare un PR o semplicemente osservare lo sviluppo del progetto.

Versione werf 1.1: miglioramenti al builder oggi e piani per il futuro