Nota. trad.: Con gli appassionati di Kubernetes del progetto ci siamo conosciuti a un recente evento dove ci hanno fatto una buona impressione. Questo loro materiale, scritto su un argomento tecnico attuale e con un notevole senso dell'umorismo, ne è una chiara conferma, e quindi abbiamo deciso di tradurlo.
Parla del principale (con lo stesso nome) un'azienda la cui idea è automatizzare i flussi di lavoro e semplificare lo sviluppo di applicazioni in Kubernetes. Per fare ciò, l'utility consente di distribuire facilmente (letteralmente con un comando) le nuove modifiche apportate al codice nel cluster di sviluppo e fornisce anche risorse / cache condivise per velocizzare l'assemblaggio e il test del codice da parte del team. Due settimane fa, il Garden ha ospitato , in cui è diventato possibile utilizzare non solo un cluster Kubernetes locale, ma anche uno remoto: a questo evento è dedicato questo articolo.
L'ultima cosa che mi piace fare è lavorare con Kubernetes sul mio portatile. Il pilota consuma il suo processore e la batteria, fa girare i dispositivi di raffreddamento senza sosta ed è difficile da mantenere.
Foto d'archivio in tema per un effetto intensificato
Minikube, kind, k3s, Docker Desktop, microk8s, ecc. — ottimi strumenti progettati per rendere l'utilizzo di Kubernetes il più conveniente possibile, e grazie a loro per questo. Sul serio. Ma non importa come la guardi, una cosa è chiara: Kubernetes non è progettato per funzionare sul mio laptop. E il laptop stesso non è progettato per funzionare con un cluster di contenitori sparsi su livelli di macchine virtuali. Il poveretto fa del suo meglio, ma ovviamente non gli piace, mostrando il suo dispiacere con l'ululato dei frigoriferi e cercando di bruciargli le cosce quando lo metto in ginocchio incautamente.
Diciamo: laptop - laptop.
è uno strumento per sviluppatori nella stessa nicchia di Skaffold e Draft. Semplifica e accelera lo sviluppo e il test delle applicazioni Kubernetes.
Fin dall'inizio del lavoro su Garden, circa 18 mesi fa, lo sapevamo Locale Lo sviluppo di sistemi distribuiti è una soluzione temporanea, quindi Garden ha molta flessibilità e una solida base.
Ora siamo pronti a supportare ambienti Kubernetes locali e remoti. È diventato molto più semplice lavorare: l'assemblaggio, la distribuzione e il test possono ora essere eseguiti in un cluster remoto.
In breve:
Con Garden v0.10, puoi dimenticare completamente il cluster Kubernetes locale e ottenere comunque una risposta rapida alle modifiche nel codice. Tutto questo è gratuito e open source.
Goditi la stessa comodità in ambienti locali e remoti
Hai la tua attenzione?
E ne sono contento, perché abbiamo molte altre funzioni interessanti! L'uso generale dei cluster di sviluppo ha implicazioni più ampie, in particolare per i team collaborativi e le pipeline CI.
In che modo?
Prima di tutto, il builder intra-cluster - sia esso il demone Docker standard o Kaniko - così come il registro intra-cluster sono condivisi per l'intero cluster. Il tuo team può condividere un cluster di sviluppo, con build cache e immagini disponibili per tutti gli sviluppatori. Poiché Garden assegna i tag alle immagini in base agli hash di origine, i tag e i livelli sono definiti in modo univoco e coerente.
Ciò significa che una volta che uno sviluppatore crea un'immagine, diventa a disposizione di tutta la squadra. Giorno dopo giorno, scarichiamo le stesse immagini di base e realizziamo le stesse build sui computer. Sei curioso di sapere quanto traffico ed elettricità vengono sprecati?..
Lo stesso si può dire dei test: i loro risultati sono disponibili per l'intero cluster e per tutti i membri del team. Se uno degli sviluppatori ha testato una determinata versione del codice, non è necessario eseguire nuovamente lo stesso test.
In altre parole, non è solo che non è necessario eseguire minikube. Questo salto apre la strada alla tua squadra molti opportunità di ottimizzazione: niente più build e test non necessari!
Che ne dici di CI?
La maggior parte di noi è abituata al fatto che CI e dev locale sono due mondi separati che devono essere configurati separatamente (e non utilizzano una cache condivisa). Ora puoi combinarli e sbarazzarti dell'eccesso:
Puoi eseguire gli stessi comandi in CI e durante lo sviluppo, oltre utilizzare un unico ambiente, cache e risultati dei test.
In sostanza, il tuo CI si trasforma in un bot sviluppatore che lavora nel tuo stesso ambiente.
Elementi del sistema; sviluppo e test senza soluzione di continuità
Puoi semplificare notevolmente le configurazioni delle pipeline CI. Per fare ciò, basta eseguire Garden da CI per build, test e distribuzioni. Poiché tu e CI utilizzate lo stesso ambiente, è molto meno probabile che si verifichino problemi con CI.
Scavando tra innumerevoli righe di configurazioni e script, poi spinte, attese, speranze e infinite ripetizioni ... Tutto questo è nel passato. Ti stai solo sviluppando. Nessuna mossa extra.
E per chiarire le cose: quando tu o un altro membro del team avete costruito o testato qualcosa con Garden, la stessa cosa è successa per CI. Se non hai cambiato nulla dall'esecuzione del test, non è necessario eseguire test (o persino build) per CI. Garden fa tutto da solo e poi passa ad altre attività come la creazione di un ambiente di pre-lancio, l'invio di artefatti e così via.
Sembra allettante. Come provare?
Benvenuto a ! Installa Garden e gioca con gli esempi. Per chi già utilizza Garden o vuole conoscerlo meglio, offriamo . Unisciti a noi sul canale se hai domande, dubbi o vuoi semplicemente chattare. Siamo sempre pronti ad aiutare e accogliere i feedback degli utenti.
PS da traduttore
Presto pubblicheremo anche una rassegna di utilità utili per gli sviluppatori di applicazioni che operano in Kubernetes, che, oltre a Garden, include altri progetti interessanti... Nel frattempo, leggi anche sul nostro blog:
- «";
- «";
- «";
- «'.
Fonte: habr.com